2. Color management in Nuke

 

In compositing, we often need to combine multiple elements from different sources (film scans, digital photographs, CG renders, digital video…). It is likely that we'll need to use materials that are encoded in different colorspaces, so it is vital that we have the means to bring them all into the same colorspace so we know our color correction tools, filters, etc will behave consistently with all of them.

Shake is colorspace agnostic, and leaves it up to the user to choose when and where to perform colorspace conversions. It also leaves it up to the user to decide whether they want to change the bit-depth at any point in the tree (using the Bytes node)

Nuke, on the other hand, attempts to bring everything into a linear colorspace (also known as linear light space, true linear... I'll refer to it as simply 'linear'). Nuke also uses 32-bit floating point to process all image data, regardless of the bit depth of the input files. On paper, this means you won't have to worry about converting images back and forth (log to lin, lin to log...) and also guarantees your  will always be working with the highest possible precision (32 bit float) and not have to worry about things getting clamped unintentionally. However, as a (former) Shake user, you'll probably want to know what's going on under the hood, and how can you change this behaviour whenever you need to.

If you want to learn more about Nuke's color management, I strongly recommend watching the following video tutorials by Steve Wright, which cover the subject of Nuke's color management in a thorough yet friendly and easy-to-follow fashion.

http://www.thefoundry.co.uk/articles/2009/12/15/61/nuke-basic-workflows-colour-management/

In this guide, I'll just go through the key points to understanding where and how color transformations happen in Nuke, assuming you are familiar with handling different colorspaces and using viewer luts in Shake.

Nuke handles color management through 3 primary areas: colorspace conversions in Read nodes, colorspace conversions in Write nodes, and Viewer-only color transformations.

 

In a nutshell images encoded in different colorspaces may be read into Nuke, the Read node will handle the necessary conversion to bring them  into a common 32-bit float linear light colorspace. All processing happens in this linear colorspace. Then, when writing images out, the Write node will try to convert those images to the right colorspace when needed (depending on the file format and bit-depth chosen to render to).

Additionally, Nuke provides a layer of color manipulations for viewing purposes only. That's where Viewer luts, but also the gain and gamma controls in the viewer, come into play. These are all operations that are done for the viewer only, and won't affect the actual data in your tree.

These are the 3 basic areas to understand Nuke's color management. The following screenshot highlights what are the UI controls that correspond to eac one of those areas:

The 3 key areas of Nuke's color management

 

2.1 - Colorspace conversions in Read nodes:

 

By default, the Read node will try to determine the colorspace of its image/sequence, and convert it to a linear colorspace. To do so, it will follow the rules set under the Default LUT settings (Project Settings -> LUT tab). Here's how this works:

Each one of the pulldown knobs defines what lookup is being used when reading different kind of images to bring them into Nuke's linear colorspace. In this example, anything that Nuke recognises as a 32-bit floating point image will be treated as 'linear', and therefore Nuke won't introduce any change to those (remember linear is Nuke's colorspace of choice). Log files (dpx, cin) will be interpreted as log-encoded, and Nuke will apply the INVERSE of a log (Cineon) curve to them in order to bring them to linear (a log to lin lut). All other files (8 and 16 bit int) will be treated as if they were sRGB encoded, and Nuke will apply the INVERSE of a sRGB lut to linearise them. Note: the 'monitor' setting here might be a bit confusing. It drives the colorspace conversion of any image shown outside the 2D Viewer. Mainly postage stamps (thumbnails) and OpenGL textures in the 3D view.

Ok, so if these rules are set properly, you probably won't need to care about converting colorspaces back and forth when reading in images. However, it is important to know where you can do so if you ever need to. Each read node has a colorspace knob that will default to a certain LUT according to the rules we just mentioned. If you happen to know that the image encoding is different than what the rules say, feel free to change that by choosing the right option from the dropdown. For example, you may get a tiff file from your matte painter that's actually encoded in log, but because it's probably a 16-bit tiff, Nuke thinks it's a sRGB image (or whatever the 16-bit preference is set to). In this case you can always force it to be interpreted as log by choosing the Cineon LUT from the colorspace dropdown.

Also, if you want to make sure that no conversion at all is being done within the Read node, you can check the 'raw' knob, and force your image to be read raw, just like it would be in Shake. Here's a small diagram that shows the differences between Shake's and Nuke's workflow:

 

 

2.2 - Colorspace conversions in Write nodes:

 

Unsurprisingly, the Write node does just the opposite as the Read node :)

The processed image/composite will go into the write node as a 32-bit float, linear colorspace stream of data. Depending on the file format you choose to write to, that data will be converted to the colorspace of choice (once again, defaulting to the values set under the Default LUT Settings for each type of file).

Just like with Read nodes, you can override the default colorspace, or choose to render 'raw'.

It's worth mentioning that, even though the LUTs available for Write nodes are the same as for Read nodes, choosing the same LUT in a Write node actually applies the inverse of the curve applied in the Read node. So, when choosing a colorspace in a Read node think of it as the colorspace we're coming FROM, whereas on the Write node it means the colorspace we're going TO. Choosing the same LUT on Read and Write will actually do a roundtrip conversion, like in the following example:

 

Example of a roundtrip conversion log-lin-log handled by Read and Write nodes in Nuke

 

2.3 - Viewer-only color transformations:

 

Coming from Shake, you'll probable be familiar with the concept of Viewer Luts. The equivalent in Nuke would be the Viewer Process. There's also an Input Process viewer toggle that uses a given node or group in a script to be applied only to the viewer. However, this is a legacy option and in most cases should be superceded by the Viewer Process, which was introduced for the first time in Nuke 5.2. If you want to find out more these two viewer controls and their differences, please read the 'Input Process and Viewer Process Controls' section of the Nuke's User Guide (page 131 in Nuke 6.0).

Shake's Viewer LUT and Nuke's Viewer Process

Just like with Viewer Luts in Shake, you can define multiple Viewer Processes in Nuke. The most common use is for colorspace conversions intended for the viewer, like a 3d lut, or gamma corrections like the sRGB lut. However, it is possible to add any node/gizmo as a Viewer Process, so there's a lot more that can be done with them (like aspect ratio masks, quality control gizmos...)

To add Viewer Processes, new entries to the viewerProcess knob need to be registered through Python. This is a very convenient way to flexibly add Viewer Processes per facility, per show, per user. To find out how, check out the User Guide at page 880.

Apart from the Viewer Process, keep in mind that all the controls in the Viewer window that change the look of the image in any way (gain, gamma, cliptest) are also applied only to the Viewer. They are very convenient tools for quality control, checking matte densities, etc, but remember they won't affect the actual image data in your tree, so make sure you know when you're looking at something that's affected by those controls to avoid surprises with renders not matching what you see in your Viewer. Nuke will let you know that those controls are active by coloring their icon in red. Clicking on them will revert the control to its default value.

 

Identifying what Viewer controls are active

 

In case you want to know what order are the color transformations in the Viewer applied in, here's the logic they follow:

• Gain >> Input Process >> Viewer Process >> Gamma >> Cliptest (default)
• Gain >> Viewer Process >> Input Process >> Gamma >> Cliptest (if viewer input order has been set to after viewer process in the Viewer settings)

It's worth noting though, that the cliptest (zebra pattern showing values outside the 0-1 range) is drawn last, but calculated first. So, it will still show you a cliptest based on the input image, before being transformed by the other viewer controls.