This article explains how colorspaces are used in Nuke and the basic workflow concepts behind them.
The basic idea behind using colorspaces is to allow recorded image data to be displayed correctly on a wide range of devices, by converting from one colorspace to another.
Nuke uses two types of color management to define the colorspace systems utilised, Nuke's native "colorspaces" and OpenColorIO(OCIO).
Nuke's native "colorspaces" are technically colour transformations, but in this article they will be referred to as colorspaces since the same principles apply. More information about Nuke's Native "colorspaces" can be found here: Q100327: How do Nuke's internal "colorspaces" work?
OCIO is an industry standard colour management system, developed by Sony, which allows compatible software to use the same colorspace configuration files to produce consistent results across products, while allowing for complex backend configuration options suitable for production usage. More information about OCIO can be found here: http://opencolorio.org/
As colorspaces are used to transform image data, if you apply the same operation to the same image in different colorspaces, then you will end up with different results.
The images below shows the same example image saved originally in Cineon colorspace (left) and sRGB colorspace (right). Inside Nuke this is being read in as RAW and the same ColorCorrect node is applied to both, before converting the result to Linear colorspace using a Colorspace node.
The results display differently as show here:
Cineon to Linear sRGB to Linear
This is one of the reasons why, when footage is read in, it uses an input colorspace which will be transformed to the working colorspace then previewed and written in the output colorspace so that when operations are applied, you get consistent results.
Nuke's working colorspace
After the image file has been read into Nuke in the correct inputs colorspace, it is converted to the working space as defined by the colour management settings. The default working space for Nuke's colour management, whether native or OCIO, while using the 'nuke-default' configuration, is linear. Other OCIO configurations may use different colorspaces for the working space.
What is common across all these working spaces is that they generally use very wide gamut colorspaces, so that when images from any other colorspaces are converted to the working space, they have colour values which can be contained within the working space value range. If this wasn't the case then colour data outside of the working space would become clipped and the image data would be lost.
For example, if you were to use Rec 709 as your working space from the diagram below, then when converting from any other colorspace with a wider gamut, such as Rec 2020, any colour values outside of the Rec 709 working space would become clipped.
Using wide gamut allows the data from other colorspaces to be converted correctly, however this also means that once the image data is converted to the working space, it will probably have a gamut which is too wide to display on a device/monitor, so it needs converting to the display colorspace of that device/monitor in order to display correctly.
For Nuke to preview the working space correctly on the users device/monitor, it applies a Viewer transform that allows you to preview the image as if converted from the working space to the correct output colorspace, but without actually affecting the image data (colour values).
To use the Viewer space correctly, it should be set to match the colourspace of the device/monitor you are viewing it on. For example if you are using an sRGB calibrated monitor, then you should use an sRGB monitor space, or for a DCI-P3 calibrated monitor, you should use a DCI-P3 space in order to display it correctly. If you then have these two correctly calibrated monitors side by side, then the image you perceive from each one should be the same.
Once the compositing work inside Nuke has been completed, the final image result can be written out.
The image colorspace needs to be explicitly converted to the display device/monitor native colorspace to modify the image data (colour values) and apply to the target use of the media.
The image below shows the basic colorspace workflow for Nuke:
Here's an example illustrating how this workflow would look and work inside Nuke:
- The green backdrops indicate the images being read in and their native colorspaces, Cineon (left) and sRGB (right).
- The Read node converts the images to the working space, which in this case is Linear.
- The various operations such as as the Grade, Merge and ColorCorrect are calculated and displayed in Linear colorspace
- In order to preview the image result on a rec709 monitor, the Viewer transform is set to the rec709 colorspace so that it displays correctly.
- The final image result needs to be coverted to rec709 colorspace before writing to disk and this can be done via a Write node
- If the final image should be worked on in another project, then the exported .exr needs to be set to Linear. (final step in example below)
We're sorry to hear thatPlease tell us why