ACES OCIO configs explained
Most OpenColorIO configs you'll meet in film and VFX are ACES configs. ACES (the Academy Color Encoding System) standardises the working and interchange spaces so a shot can move between vendors and look the same. When someone hands you a config.ocio, knowing the handful of ACES colorspaces and which roles should point where makes it quick to tell a healthy config from a broken one.
The core ACES colorspaces
ACES2065-1 (AP0) - the reference
ACES2065-1 is the wide-gamut, scene-linear interchange space built on the AP0 primaries. It's the space files are exchanged in (the OpenEXR ACES container) and, in an OCIO config, it's normally the reference - the hub that every other scene-referred colorspace converts to and from. The aces_interchange role points at it too.
ACEScg (AP1) - the working space
ACEScg is scene-linear on the tighter AP1 primaries, and it's what you actually render and composite in. In a config the scene_linear role - and often default - points to ACEScg, because AP1 behaves better than AP0 for lighting maths while staying wide enough for production.
ACEScct - grading
ACEScct is a logarithmic encoding of AP1 with a slight "toe" that lifts shadows, designed for colour grading. Configs typically map color_timing and compositing_log to ACEScct. (ACEScc is the toe-less sibling; either can appear.)
Raw / Non-Color - data
Non-colour passes - normals, masks, depth, IDs - live in a Raw (a.k.a. Non-Color or Utility - Raw) colorspace flagged isdata: true. The data flag tells OCIO never to colour-transform them. The data role points here.
Rule of thumb for a healthy ACES config: reference → ACES2065-1, scene_linear → ACEScg, color_timing / compositing_log → ACEScct, data → a Raw space with isdata: true.
Which config? Studio vs CG
The modern ACES reference configs (built with OpenColorIO v2 and its built-in transforms) come in two flavours. The CG config is a lean set - the ACES spaces plus common texture/utility spaces - aimed at CG and rendering. The Studio config is a superset that adds camera-vendor input transforms (ARRI, RED, Sony and friends) and more displays, for full production colour pipelines. Many studios then customise one of these, which is where drift and breakage creep in.
Common ACES-config pitfalls
- Reference not on ACES2065-1 - if
referencepoints at ACEScg or something else, exchange and interop assumptions break. OCIO Validator flags this as an advisory. - scene_linear not on ACEScg - renders in the wrong working space; another advisory worth heeding.
- Raw missing its data flag - utility passes get tone-mapped and corrupted.
- Renamed spaces after a config bump - the ACES 1.x "Utility - sRGB - Texture" style names vs the newer reference-config names (
sRGB - Texture,lin_ap1); a role written for the old name won't resolve against the new config. Aliases exist precisely to cushion this - and OCIO Validator resolves against aliases too. - Display/view drift - an
active_viewslist that still references a view you removed, so apps show a dead entry.
Check it in seconds
OCIO Validator detects an ACES config from the presence of ACES2065-1 / ACEScg and then advises when the reference or scene_linear roles differ from the usual choices - on top of the full structural check that every role, view, display and look resolves. Paste your config and you'll see the ACES advisories and any broken references immediately, without an OpenColorIO install.