What "ACES" means on a spec sheet
ACES - the Academy Color Encoding System - is a colour-management framework, not a single file format. When a delivery spec says "ACES EXR", it almost always means the interchange encoding ACES2065-1: scene-linear image data on the AP0 primaries, wrapped in an OpenEXR file. That is the neutral, device-independent master the recipient can grade, archive and re-derive everything else from. Getting the container right (an .exr) is the easy part; getting the colour encoding right is where deliveries bounce.
AP0 vs AP1: the primaries that trip people up
ACES defines two sets of RGB primaries, and mixing them up is the number-one ACES rejection.
| Primaries | Encoding | Role |
|---|---|---|
| AP0 | ACES2065-1 | The archival / interchange master. Primaries sit outside the visible locus so the gamut covers every real colour. This is what an "ACES EXR" deliverable should be. |
| AP1 | ACEScg | A working space for rendering, lighting and comp - a tighter gamut that behaves better in maths. Great to work in, wrong to deliver as "ACES2065-1". |
Almost every VFX artist comps and renders in ACEScg (AP1) because it is the sane space to do maths in. But the deliverable is usually ACES2065-1 (AP0). If you export straight out of your comp package without the ACEScg-to-ACES2065-1 conversion, you have handed over an AP1 image mislabelled as AP0. It may look identical in a viewer - and it will still fail an ingest that reads the header chromaticities.
Why it has to be linear
ACES2065-1 is scene-linear: pixel values are proportional to light in the scene, with no display or log transfer curve baked in. That linearity is the whole point - it is what lets any downstream facility apply its own grade, its own output transform, and its own display rendering without fighting a curve someone else already applied. An EXR that carries a log-encoded or Rec.709-display image is simply not ACES, no matter what the filename says. Float or half-float linear is the norm; a "gamma-corrected" EXR is a contradiction for this deliverable.
What an ACES EXR pull spec enforces
Beyond the colour encoding, an ACES EXR pull typically nails down the same mechanical attributes any EXR spec does:
- Compression: lossless only - usually PIZ or ZIP, sometimes uncompressed. Lossy DWAA/DWAB is excluded from masters because generational error compounds. (See OpenEXR compression explained.)
- Bit depth / channels: commonly 16-bit half float for the master; some archival specs demand 32-bit float. RGB with defined channel names, no stray channels or unexpected AOVs bundled in.
- Resolution & pixel aspect: the exact working resolution with a square (1.0) pixel aspect, no data window / display window mismatch.
- Colour attributes: AP0 chromaticities recorded in the header, and often an ACES-conformant flag the recipient's tools look for.
- Naming & frames: the usual contiguous, correctly padded frame range - an ACES master is still a sequence.
The common rejection causes
- AP1 delivered as AP0 - the ACEScg render was never converted to ACES2065-1.
- Non-linear encoding - a log or display transform baked into the "linear" EXR.
- Wrong compression - a DWAA preset left on one machine in the farm.
- Wrong bit depth - 32-bit float where the spec asked for half, or vice versa.
- Missing colour metadata - correct pixels, but no chromaticities in the header for the ingest to verify.