The past few weeks I’ve been diving deeper into the ACES workflow within VFX, and one of the major hurdles is inconsistent terminology (I’m looking at you, Nuke).
In an attempt to wade through the complexities, I’d thought “Wouldn’t it be easier if I could just see the colourspace?”, and I had a plan.
I had a few ideas
I wanted to see the colours in a ‘data’ sense, overlay different versions to see how they move, and compare to a baseline of some sort. Nuke has a 3D viewport, so that would work for displaying RGB values along XYZ, and I could view it from different angles to make comparisons. I started out with a simple setup:
Nuke has a really handy node, the CMSTestPattern, normally used for generating lookup tables, essentially it contains a grid of all colour values with control over the quantization (how many values). Combining this image with a PositionToPoints node generates an array of points in 3D space where the coordinates of each colour is based on the individual RGB values: [0,0,0] for black, [1,1,1] and all inbetween.
While this looks pretty, by itself it isn’t much use for comparison, so I transposed the values into a more human-friendly colourspace – CIE Yxy.
“But that doesn’t look like anything useful!” I hear you say. It’s a matter of perspective. If we rotate it around a bit, and view from the top, it starts to look more familiar – sRGB on the CIE chromaticity diagram, accurately descibed by a colleague as “Rich’s favourite graph”.
Lets do some comparisons
So now we’ve got this litte setup running, we can start to do some comparisons. First, let’s plot some of Nuke’s colourspaces. In the colourspace node, the “In” option allows us to interpret the 0-1 of the CMS test pattern as different colourspaces. We don’t change the tone curve (slog, gamma, linear etc), just the colourspace.
Below is sRGB, DCI-P3 and Nuke’s unhelpfully generic “ACES”. To make it easier to read I’ve removed all but the border values with an expression – If any of the red, green or blue values are zero, then change to black.