Source for exr2aces claim?

[patrickhulce]

Hey team 👋

I'm looking for a source / further information on the claims in the exr2aces documentation (source)

What specifically is the scope suggested by the "ACES file format" on that page? Is it compatibility with specific software? Meeting some specific aspect of an industry spec? I ask because plenty of software seems to support ACES 2065-1 in EXRs without being subject to these restrictions, and I'm not sure whether this exr2aces information is still accurate and/or whether it's relevant to what I'm producing.

Is there a practical source for this I can refer to? e.g. SMPTE ST 2065-1 makes no mention of compression types / EXRs

[peterhillman]

The ACES container file format is defined by ST 2065-4 (currently SMPTE ST 2065-4:2023). 2065-1 defines the colorspace, independently of the way the image is stored.

You can write an OpenEXR file using the 2065-1 chromaticities, but if it doesn't follow the strict definition of 2065-4 it's simply an OpenEXR that happens to use the ACES chromaticities, not a 2065-4 aces file. Such a file can use OpenEXR features that are not part of the 2065-4 standard.

Interestingly though, the spec requires that no compression is used for ACES files (section 9.19), so the implementation of ACES files within libOpenEXR does seem to allow compression types that are not strictly permitted by ST 2065-4. I believe there is (or was) a desire to codify extra compression types into a SMPTE standard, but that has not happened.

[lgritz]

Think of it as "ACES files use a strict subset of OpenEXR as its container format". I suppose there are certain archival activities in which it is important for everything to be 100% conforming to the international standard.

Obviously, in practice inside a studio, we just use the ACES color spaces with ordinary OpenEXR files. The idea of having uncompressed files lying around is both laughable and very expensive at the scale in which we operate.

My understanding is that the reason no compression is described in the SMPTE standard is that standards like that (and ISO's, etc.) all have to 100% describe every last detail, or else refer to another recognized formal standard for some component. You can't just say "use zip compression" and call it a day. So if a compression technique isn't already fully spelled out in another SMPTE standard document, it's just too much trouble to create that full description just for ACES, say. That's my lay understanding of the situation, anyway.

[patrickhulce]

Thank you so much for the swift and informative responses @peterhillman and @lgritz 🙏, that's exactly what I was looking for.

I've opened #1963 that adds some of this color to the docs site.