I am finding that there is a difference between transforms done in either the ACES transform vs the Color transform OFX node in resolve.
I tried slog2->AcesCG and LogC->AcesCG and and there is always a difference in what those 2 nodes do despite them beign set to the same thing.
Am I forgetting something? I also checked with ocio in nuke and that result is the same as ACES transform.
Linear ramp input , acestransform does not change balance between RGB , same goes for Nuke OCIO but OCIO colorspace does change the RGB balance … as my ramp is R=G=B … I am not expeting the results of any gamut conversion to do anything (based on my knowledge of 3x3 matrixes… ) .
The reason for that is that the ACES Input Transforms include a chromatic adaptation from source white (usually D65 for cameras) to ACES white. This means the 3x3 matrices in the IDT have rows which add up to 1.0.
The Colour Space transform does not do any chromatic adaptation, so where R=G=B in e.g. LogC/AWG represents D65 white, when transformed to ACEScg the result is an absolute representation of D65 white in the ACES encoding, which has unequal RGB values.
I had noticed this and brushed this off as the usual “BMD doesn’t really care about ACES”. That being said I noticed the shift between the two are minimal and opted to use the OFX version as it was better workflow wise (I had used Paul Fire’s DCTLs also but that was problematic with AMD GPU). So which one is correct? I also tested with NUKE and it seems both we’re a little bit off.
Thanks!
Resolve’s ACES Transform is correct for ACES IDTs, and matches Nuke’s OCIOColorSpace with the appropriate ACES OCIO config.
Resolve’s Color Space Transform (or RCM) matches the Nuke Colorspace node with Bradford Matrix unchecked. These are both performing an absolute conversion, with no chromatic adaptation. This is not appropriate as an ACES IDT.
With Bradford Matrix checked Nuke’s Colorspace node will match an OCIOColorSpace transform to ACES2065-1, and a Resolve IDT/ACES Transform, as the Bradford matrix is a chromatic adaptation matrix. Strictly the match will not be perfect for all IDTs, as some (e.g. ARRI) use CAT02 chromatic adaptation, not Bradford. But you have to look very hard to see the difference.
Additional note: in older versions of Resolve there was a slight difference between the IDT applied for LogC with Resolve’s built in IDT and the one in the ACES Transform effect. This was a different issue (there was a thread here about it) and was because the ACES Transform used the EI400 LogC IDT, and the built in one used (in the absence of metadata) the EI800 LogC curve. This has now been fixed.
I just checked, and 15.3 does indeed use the EI400 curve, instead of EI800, in the ACES Transform. 16.1b3 has a drop-down in the ALEXA Input Transform in the ACES Transform effect which lets you choose 400 or 800.
I actually have an in-house DCTL ALEXA IDT with a slider control which lets me choose any EI from 160 to 3200. But the difference is very subtle. Between 400 and 800 you have to look very closely at the waveform.
Kinda weird that I cant run an inverse of the acestransform node while I can invert the stuff from the colorspace node, so stazing in resolve using acestransform I can never go back to the source if I have to…
so the difference is in different IDTs used… wouldnt this be considere a bug in resolve?
No, it’s not a bug. The Colour Space Transform does not claim to be an IDT. It is correct for what it’s intended to be. Conversion without chromatic adaptation is appropriate for some purposes (hence the check-box in Nuke). Indeed, Resolve 16 includes Chromatic adaptation as a separate effect, so you could build your own IDT if you really wanted to.
Thank you all for your replies! Really helped me clear things up in the resolve world… really wish they would add more of a explaination to whats happening and especially give me the inverse of the AcesTransform node…
Want to add to that, is there anyway one can reverse the chromatic adaptation? I need to make Log3G10 /RWG from nuke , plates have been conformed from r3d set to log3g10rwg using colorspace transform nodes (no adaptation) . so now my new files from nuke have that adaptation that I need to reverse before delivering files.
) .