I’m trying to sort out if it is possible to write out EXRs from Nuke with both ACES 2065-1 and DWAB compression.
I know from both the Foundry documentation and local testing that Nuke Writenodes (and their sister Shotgun Writenodes) will guarantee ACES primaries in the resulting EXRs if write ACES compliant EXR is set on in the Writenode, but that they will be uncompressed.
I want DWAB compression, so I set write ACES compliant EXR to off, but then upon inspection of EXRs written with this setting I find that while the DWAB compression is there (in the metadata and based on the much smaller filesize), the primaries are now Rec709.
This is all very strange as the Nuke file that I’m using for testing has Project Settings that are all set to ACES - ACES2065-1 in the appropriate attributes (working space, 16-bit files, float files) under the OCIO config aces_1.0.3. Additionally, all the Writenodes are set to the ACES - ACES2065-1 colorspace.
I’m using RV to inspect the EXR metadata. When I use Nuke ViewMetadata nodes to compare compliant vs. non-complaint rendered EXRs, I see an additional exr/chromaticities attribute with values in the compliant version, and the exr/compression attribute is set to 0. (I’m going to use the OpenEXR python module to see if that provides any additional information.)
A compositor here suggested I try adding a ModifyMetaData node before the Writenode with an exr/acesImageContainerFlag key set to 1, but based on the following I’m led to understand that it’s just setting the same metadata flag in the EXR header (and in testing the Writenode setting clearly trumps it since the Writenode is last in the chain):
Writing this out made me think that maybe we could add the exr/chromaticities key in a ModifyMetaData node, set to the acesDefaultChromaticites value, but it’s starting to feel like down-the-rabbit-hole madness to me.
That is not my experience (see my post which you quoted). The write node still uses the colourspace chosen in the drop-down, and simply sets metadata to say it is ACES 2065-1 and has ACES primaries, even if it doesn’t.
You should not really do that if you are writing compressed data to the EXR, as the ACES EXR spec (currently) mandates no compression. So you would be flagging the EXR as ACES compliant when strictly it is not. Whether that would actually cause a problem for most software is a different issue.
You can indeed do that (you can copy the values from the metadata of an EXR written as ACES compliant) and it would be the more correct thing to do. Remember still to set the colorspace of the write node to ACES - ACES2065-1.
You should (of course) still test your pipeline, and ensure that any software intended to read the resulting EXRs interprets them correctly, and that notes are provided for those receiving them to ensure they can manually set the interpretation. The intent of the ACES Image Container flag is that it is possible for software to configure automatically, but this is certainly not guaranteed to happen. Try reading an ACES compliant EXR written by Nuke back into Nuke. It will not be automatically set as ACES - ACES2065-1. And setting chromaticities metadata is rarely anything more than a note for those who bother to look!
Just a heads up, I noticed some typos in my post, but when I went to edit them, I get an error “Sorry, new users can only put 2 links in a post”, even though when I created my first post I was allowed to include 3 links.
Anyone reading along should just know that I mean to say “chromaticities” wherever I type something not-quite-that in the OP.
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?
Hi Dean.
Thanks for your replies.
Explicitly writing chromaticities in EXR is possible and that is exactly something I was doing back in 2016/2017 for my studio’s pipline-customized Nuke Write nodes. Our pipeline had also been injecting timecodes, tapenames/clipnames and other production metadata into the VFX plates.
At that time the ACES compliant EXR flag in Nuke wasn’t there yet, so I had the ST2065-4 compliace acesImageContainer flag manually added by the customized Write node as well…
This is, indeed, when I started working with Foundry, and that Nuke flag was finally born.
As for your “core” question about DWAB, I totally second @nick. Since no compression is (unfortunately) currently allowed in the SMPTE standard ST2065-4, you cannot get EXRs that both comply to ACES and any kinds of compression.
Of course, one can possibly crank the EXR metadata up, but that is a dangerous workaround because it would break compatibility. Imagine some app honoring the ST2065-4 and, therefore, expecting uncompressed EXR but the files you feed the app with are compressed indeed. Bang– the app will possibly perform a plaggy playback, if not worst: crash down.
Therefore, my best suggestion for you is adding che chromaticties metadata to point to AP0 primaries --as well as any other metadata you need in your pipeline-- but just don’t look to get a ST2065-4 OpenEXR.
I hope in the future some compression algorithms will be allowed in future revisions of ST2065-4, therefore allowing compressed, ACES-compliant OpenEXR.