Skip to content

Color Management and OpenColorIO

ACES defines the transforms. OpenColorIO (OCIO) distributes and applies them consistently across applications. A show can specify ACES correctly and still produce mismatched renders if one artist uses a different config.

What OCIO is

OpenColorIO is an open-source color management library, originally developed at Sony Pictures Imageworks and now an Academy Software Foundation project. It is embedded in Nuke, Maya, Houdini, Katana, Blender, RV, and most other tools in a VFX pipeline.

The unit of configuration is an OCIO config: a file (plus, historically, associated LUTs) that enumerates the color spaces a show uses, the transforms between them, and the named roles that applications look up:

  • Color spaces: ACEScg, ACEScct, ARRI LogC4 / AWG4, sRGB - Display, and so on.
  • Roles: abstract names that decouple applications from specific spaces. scene_linear, compositing_log, color_picking, data. An application asks for scene_linear. The config decides what that means on this show.
  • Displays and views: the viewing transforms available in an artist's viewer.

Roles allow a working space to change without editing every artist's scripts. Redefine scene_linear once in the config instead of changing it in each Nuke script.

How ACES is actually delivered

Facilities consume ACES as an OCIO config, not by implementing the CTL reference transforms directly.

The Academy publishes reference transforms in CTL. Artists receive an OCIO implementation, usually a smaller cg-config for CGI/compositing or a broader studio-config. See the OCIO ACES config project.

"The show is ACES" therefore requires every application to use the same OCIO config and version.

What to specify on a show

Alongside the three format specifications, a color-managed show needs these written down:

Item Example Why
Config identity and version studio-config-v4.0.0_aces-v2.0_ocio-v2.5.ocio Two artists on different config versions can produce different renders from identical scripts, and ACES 2.0's output transforms differ substantively from 1.x, so a 1.3 config and a 2.0 config are not two versions of the same render
Working space ACEScg See the AP0/AP1 warning
Grading space ACEScct ACEScc and ACEScct are not interchangeable
Plate color space ARRI LogC4 / AWG4 Must match what the plate pull actually produced
Delivery color space ACES2065-1, uncompressed EXR The DI's requirement, not the vendor's preference
Viewing transform Output Transform, P3-D65 or Rec.709 Artists must review under the same view the DI uses

Distribute the config with the plates in support_files/, alongside the Show LUT and CDLs. Do not ask vendors to source it independently.

Versions

OCIO 2.x replaces baked LUT approximations with native ACES transforms and matching GPU and CPU processing paths. Use the annual VFX Reference Platform to align ACES, OCIO, and OpenEXR versions across vendors. CY2026 specifies ACES 2.0, OCIO 2.5.x, and OpenEXR 3.4.x.

Checking that it works

Run these checks in a confidence package before shot work:

  1. Round-trip a plate. Convert to the working space and back without operations, then difference against the original. Allow only floating-point precision error.
  2. Round-trip an extreme. Repeat with a plate containing genuine highlight clipping and deep shadow. Faults that are invisible on a mid-tone chart show up here as clamping.
  3. Compare viewers. The same frame, under the same view transform, in Nuke and in the DI system. If they differ, resolve it before anyone grades anything.

Use a difference check for the first two tests.