Academy Color Encoding System
ACES2065-1/AP0, ACEScg and ACEScct/AP1, Input and Look Transforms, ACES 1.x and ACES 2 Output Transform, gamut compression, VFX interchange and DaVinci Resolve workflows.
ACES is not one huge colour profile and not a 'cinema LUT'. It is a standardised architecture: different cameras are brought into a common scene-referred context, work is represented in defined ACES encodings, and a separate Output Transform renders the result for a specific display.
Quick reference
Canonical interchange/archival encoding.
CG/compositing working encoding.
Grading-oriented working encoding.
D60-like reference white.
Scene-referred technical Look Transform for problematic out-of-gamut values.
Tone, chroma and gamut rendering are redesigned as a unified display-transform architecture.
ACES ARCHITECTURE
ACES contains standardised encodings, transforms, metadata and interchange conventions. The central idea is to remove ambiguity: a source camera state is converted by an Input Transform into an ACES reference representation; scene-referred work happens in agreed ACES spaces; viewing/delivery is created by an Output Transform. Saying 'the file is in ACES' without specifying ACES2065-1, ACEScg or ACEScct is therefore incomplete.
ACES2065-1 is a photometrically linear RGB encoding using AP0 primaries and the ACES white point x=0.32168, y=0.33767. AP0 is intentionally extremely wide and includes imaginary primaries; its purpose is to contain colourimetry for interchange/archival use rather than provide a convenient surface for ordinary grading controls. In production, ACES2065-1 is commonly associated with OpenEXR interchange between departments.
ACEScg and ACEScct use AP1 primaries. AP1 is smaller than AP0 and is more practical for image processing, CG and grading: it reduces extreme RGB relationships and makes many operations more stable. Importantly, AP1 does not mean values are automatically confined to the AP1 triangle — floating-point workflows can contain negative/out-of-gamut values.
ACEScg uses AP1 primaries with a linear transfer. The linear relationship makes it suitable for light transport, compositing, rendering and physically meaningful operations. But linear data is awkward for most manual grading controls because much of the useful exposure range occupies a small numerical region. ACEScg is therefore a typical VFX working/interchange state rather than a mandatory DI grading state.
ACEScct transforms linear ACES values with a piecewise linear/log function and uses AP1. It can preserve values above 1 and below 0 when the pipeline does not clamp them, and is intended to make colour-correction controls behave more conventionally. ACEScct is not a display gamma and should not be sent directly to a monitor as a finished image; it is viewed through an ACES Output Transform.
An ACES Input Transform maps camera-native encoding into ACES2065-1 relative exposure values. In a RAW pipeline, some camera characterisation may be performed by the decoder, but the resulting input state must still be known. The wrong camera transform creates a systematic error through the rest of the pipeline: white point, saturated colours and exposure response cannot then be 'fixed automatically by ACES'.
A Look Transform modifies scene-referred ACES imagery for a technical or creative purpose before final output rendering. This differs from an Input Transform, which interprets the source, and an Output Transform, which renders for the display. In a node-based application, a creative LUT/DCTL also needs a known expected state; formally, the term 'LMT' belongs to ACES architecture and is not a synonym for every LUT.
In ACES 1.x, highly saturated sources could produce negative/out-of-AP1 values and unpleasant artefacts, especially from bright LEDs. Reference Gamut Compression 1.3 was introduced as a scene-referred Look Transform that gently corrals extreme values before further processing. In ACES 2, display-rendering gamut compression is part of the new Output Transform architecture; do not confuse ACES 1.3 RGC with gamut compression inside the ACES 2 rendering transform.
Historically, ACES 1 described a Reference Rendering Transform and an Output Device Transform. From 1.1 onward their combination is generally treated as one Output Transform because tone scale and device mapping are tightly coupled. The practical lesson is important: output is not simply 'convert AP1 primaries to Rec.709'; it renders scene values into the capabilities of a display.
ACES 2 completely redesigned display rendering. Scene-referred ACES is converted to a JMh correlate space based on a simplified Hellwig 2022 CAM; the tone scale operates on J (lightness), chroma compression on M (colourfulness), gamut compression on J/M while preserving the hue correlate h, and the result is then encoded for the target display. The goal is more consistent SDR/HDR outputs, softer highlights and better hue preservation under strong gamut/dynamic-range compression.
ACES 1.2, 1.3 and 2.x can produce different display rendering and provide different transform sets. Project metadata, VFX turnovers and facility documentation should therefore record the system version, Input Transform IDs/definitions, working encoding and Output Transform. You cannot open an old project, switch ACES version and expect a pixel-identical result merely because the timeline grade did not change.
For a full ACES workflow, select ACES colour science in Project Settings, lock the ACES version, choose an ACEScc/ACEScct Timeline Colour Space as appropriate, assign Input Device Transforms/input tags and select the Output Transform. The ACES Transform Resolve FX is useful as a local conversion tool but does not replace the overall architecture. If the project is already ACES-managed, an additional ACES output/CST on the timeline can easily create double rendering.
ACES2065-1/AP0 is the canonical ACES interchange/archival encoding; ACEScg/AP1 is a practical linear working space for CG. A facility may receive a camera plate, convert it to ACEScg for comp/render and return EXR in an agreed state while viewing through a common Output Transform. The key is not to rely on the .exr extension: EXR is a container and does not automatically tell you whether the pixels are ACES2065-1, ACEScg or another linear space.
ACES is especially strong where standardised interchange, multi-vendor VFX, transform IDs/metadata and long-term archival conventions matter. DWG/Intermediate is deeply integrated into Resolve and is often simpler for single-application DI/finishing. Both approaches can be wide, scene-referred and multi-output. The choice should be driven by pipeline requirements, interoperability and predictability, not by the area of a triangle on a CIE diagram.
For a production project, record more than just 'ACES': at minimum ACES system version → source Input Transform → working encoding → Output Transform. Those are four separate decisions.
Technical definitions are anchored to standards bodies and primary specifications wherever that distinction matters.
Architecture of encodings, Input/Look/Output Transforms and metadata.
AP0 primaries, ACES white point and linear transfer.
AP1 and quasi-log grading encoding.
Evolution of RRT/ODT and the ACES 2 display-rendering structure.
Why RGC was introduced in ACES 1.3.
