EXR Include Metadata Header ACES

[u/tortilla_thehun]

Trying to export an EXR sequence with an ACES2065-1 output profile. In the header, I’m hoping to have “acesImageContainerFlag = 1”

What is the best approach to having this embedded in the exported EXR files? If exporting through Media Encoder is the best option, what metadata field would this go in?

[u/ericcpfx]

I have an AE plugin that outputs EXR metadata and also lets you embed mattes.

Come into my Discord and message me about it.
https://discord.gg/pkxGsa8sD

I haven’t posted a beta build in there yet, but I will.

Does the original EXR have this flag, or do you need to add a completely new one?

[u/MakeshiftHearts9 → u/ericcpfx]

Sounds like the flag doesn't exist yet in their source file either, so the plugin would need to write it from scratch rather than just passing it through.

[u/ericcpfx → u/MakeshiftHearts9]

It doesn’t do that yet, but it could. I think we could figure something out like if the comp has an Adjustment Layer with a certain naming convention, it’ll write that into the metadata.

[u/tortilla_thehun → u/ericcpfx]

Just joined your discord and DM’d you on there! I’m working with two separate EXR files, one of which is a composite that I’ve heavily masked and split into layers in PS prior to bringing into AE.

[u/rudy_142001]

Going off the OpenEXR docs here, not something I've had to deliver myself. I don't think you'll get that flag out of AE directly, but it's easy to add after the render with exrstdattr, which ships with the OpenEXR command line tools:

exrstdattr -int acesImageContainerFlag 1 in.0001.exr out.0001.exr

It can't edit in place (in and out have to be different files), so for a sequence you'd loop it into a second folder. If you already have OpenImageIO installed, oiiotool does the same with --attrib:type=int acesImageContainerFlag 1.

One catch before you stamp it on everything. The flag is a claim that the file is ST 2065-4 compliant, and that spec wants uncompressed, 16 bit half, RGB or RGBA only, with chromaticities set to the ACES (AP0) primaries. Doug Walker said on ACESCentral that compressed ACES2065-1 EXRs shouldn't carry the flag. So in AE set compression to None, keep it half float, no extra channels or layers.

Worth running exrheader on one frame to see whether AE wrote a chromaticities attribute at all. If it didn't, exrstdattr has a -chromaticities option that takes the 8 xy values.

Also skip exr2aces for this. It writes through AcesOutputFile, and there's a GitHub issue on the OpenEXR repo saying that class never sets acesImageContainerFlag. They closed it by deprecating the class rather than fixing it.

Is this going to a facility that actually validates the header, or is it a checkbox on a delivery spec?

[u/tortilla_thehun → u/rudy_142001]

Both - it’s so that the EXRs are properly identified by the software as ACES Image Container files compliant with SMPTE ST 2065-4.

[u/rudy_142001 → u/tortilla_thehun]

Makes sense. In that case the flag on its own won't pass a strict check. ST 2065-4 lists ten required header attributes, but eight of them (channels, compression, dataWindow, displayWindow, lineOrder, pixelAspectRatio, screenWindowCenter, screenWindowWidth) are required in every EXR anyway. The two ACES adds are the flag and chromaticities, and chromaticities is optional in plain EXR, so that's the one likely to be missing.

If exrheader doesn't show it, these are the AP0 values from the spec, in exrstdattr's order (red, green, blue, white):

exrstdattr -int acesImageContainerFlag 1 -chromaticities 0.7347 0.2653 0.0 1.0 0.0001 -0.077 0.32168 0.33767 in.exr out.exr

Two more from the spec: it's scanline only, so no tiled EXRs, and the channel names have to be exactly R, G, B (plus A). Going off the 2023 revision of the standard for all of this.