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.