Hi Nick,
Just reiterating to make sure I have a grasp of things.
When toggled on, the write ACES compliant EXR setting on a Nuke Writenode in Nuke 11.3:
-
will cause Nuke to write a (key, value) pair to the EXR header consisting of (exr/acesImageContainerFlag, 1), but this key/value pair doesn’t force the colourspace to an ACES colourspace in the EXR or during ingest elsewhere
-
will cause Nuke to force 16-bit-half datatype, and NO_COMPRESSION when the requested compression type is DWAB for the Nuke-rendered EXR and its related keys & values in the header
-
the Nuke-rendered EXRs will display information in RV 7.6.1 with a ColorSpace/Primaries key having an ACES value – leading me to believe that RV might be one of the programs that reads the exr/acesImageContainerFlag value in the EXR header. (Note that if the compliant toggle was off for the Nuke-renders in my tests, RV always shows Rec709 as the value for ColorSpace/Primaries, no matter what the colorspace setting is on the Writenode)
So as long as we have the colorspace setting of the Nuke Writenode set to ACES - ACES 2065-1, the write ACES compliant EXR setting toggled off, and compression set to DWAB, we should be good? We can trust what’s coming out of Nuke?