The current project I am in is using Red Helium but unfortunately I am super unfamiliar with it. Already had some study but still quite confused with RED its own colorspace. I ask these separately.
ACES:
It makes me so confused here. I select “Input - RED- REDLog3G10 - REDWideGamutRGB”, and I want to know the steps separately so I put an ociocolorspace to linearize it with “Input - RED - Curve - REDLog3G10” then other ociocolorspace to covert RWG to ACEScg with “Input - RED - Linear - REDWideGamutRGB”. In my understanding these two results should be the same but they don’t.
Linear-sRGB:
In some projects we stick with linear-sRGB space. So far what I know is bring the r3d in → set to “Log3G10” in colorspace → use colormatrix from RWG ro sRGB using online app(https://www.colour-science.org:8010/apps/rgb_colourspace_transformation_matrix)
And it is in linear-sRGB now. I’d like to know am I right with this.
When using ACES as colormanagement in Nuke the working space is set to linear/ACEScg. Any footage that comes in needs to have it’s proper input device transform selected. The ACES config will automatically convert from that to linear/ACEScg, no manual steps required. For raw files you will have to match what you’ve selected in the metadata to decode to however. I downloaded Helium sample footage and came to this setup.
If you want to perform that step manually you could check ‘raw data’ so OCIO doesn’t auto convert it and then use an OCIOColorSpace node to go from whatever you’ve set the R3D file to, to ACEScg.
(To double check that the footage is coming in as Log3G10/RWG you can set your viewer to Raw temporarily.)
For more modern RED camera’s it’s a bit easier because they’re set to REDLog3G10/RWG by default I think with the IPP2 system.
Don’t have much experience in that regard but from what I understood is that the Nuke default config only has transfer function conversions so your approach sounds correct.
Thanks for answering. According to your setting and what I know, my workflow seems to be correct. Back to my 1st question, I put an image here to describe it.
The viewer 1 shows exact process in your setting and I have no problem with it. But in the viewer 2 image, what I am doing just split into two steps: linearize it with Log3G10 then convert RWG to ACEScg.
Now it comes different result but in my understanding two images should be identical. I supposed I missed something or “Input - RED - REDLog3G10 - REDWideGamut” is not that simple just linearization and gamut conversion.
I see what you’re trying to do now. Most ACES color spaces are coupled transfer function + color space.
Never used the curve inputs for anything but it might be that it’s still converting something to ACEScg and then it gets converted again assuming it’s still RWG by the second node.
I guess to replicate the steps separately you would have to use a non aces transform node that can do only the transfer function like the normal colorspace node.
Overall it’s quite messy and totally unnecessary to set it up this way tho
You could change the R3D metadata to anything you’d like as long as that combo of transferfunction/colorspace exists as an IDT in the ACES config. No matter which you pick the working data will be the same.
Another valid way would be to keep the RWG color space in there making that part a non-operation in the first transform.
But again, ACES can do all this within one single transform so there’s really no point in doing so.
Thanks.
And yes I totally understand it’s unnecessarily to put two nodes and make things complicated instead of just one node simply and accurately. But it kinda a way help me understand the concept behind and how are these processes been simplified into one step with correct setting.
If you’d want to dive deeper you could look into the ocio.config file itself and see how the colorspaces are set up.
This for example is the Log3G10/RWG code
As you can see the file reference is a 1d lut converting log to linear which you could also use in a OCIOFileTransform.
Coupled with a matrix for RWG to ACEScg we get the same again.
You can see the “REDWideGamutRGB to ACES2065-1” matrix is the same. Unfortunately I have no idea about the decimals.
Btw, I found the reason why the result from Input - RED - Curve - REDWideGamutRGB is not identical. Because it actually requires three steps to interpret it.
It seems like none of the Chromatic Adaptation models in the website give the exact same decimals as the ACES or White Paper one but the inaccuracy is past 3 decimals so I wonder if that would ever matter.
I already remember why that is. Internally all transformations are done to and from AP0 eventhough the config’s workingspace is AP1 haha stupid oversight.
