The Academy Color Encoding System (ACES)
ACES standardizes a scene-referred interchange encoding, working spaces, and input and output transforms. Multiple vendors can implement the same pipeline without negotiating a custom color workflow.
What ACES actually is
ACES is not a look, and it is not a LUT. It is four things:
- A scene-referred interchange encoding: ACES2065-1, standardized as SMPTE ST 2065-1.
- Working spaces derived from it for compositing and grading.
- Defined transforms at the input and output of the pipeline.
- A container for the image data, standardized as SMPTE ST 2065-4.
Everything converts to ACES2065-1. VFX round-trips through the interchange in ACEScg. Grading converts internally to ACEScct and back to ACES2065-1. That graded ACES2065-1 is the Graded Archival Master, and the Output Transform derives each deliverable from it. The ungraded interchange is the non-graded assembly master.1
Color primary sets
ACES defines two sets of primaries, and confusing them is the most common source of ACES-related pipeline errors.2
| Set | Role | Chromaticities (x, y) |
|---|---|---|
| AP0 | The ST 2065-1 encoding primaries. Encompasses the entire CIE 1931 visible spectrum. The primaries are non-physical. | R (0.73470, 0.26530) · G (0.00000, 1.00000) · B (0.00010, −0.07700) |
| AP1 | Working-space primaries, closer to achievable display primaries. Basis of ACEScg, ACEScc, and ACEScct. | R (0.713, 0.293) · G (0.165, 0.830) · B (0.128, 0.044) |
AP0 uses non-physical primaries so the interchange encoding can represent the visible spectrum without clipping. That makes it suitable for archival interchange but unsuitable for image processing. AP1 exists for rendering, compositing, and grading.
The most common ACES mistake
Rendering or compositing in AP0 because it is "the ACES space." Lighting and shading math performed against non-physical primaries produces hue shifts that look like a lighting bug and get chased as one. Composite in ACEScg (AP1). Reserve ACES2065-1 (AP0) for interchange, delivery between vendors, and archival.
Why ACES Is "D60" in a D65 World
All ACES encodings share a white point of x = 0.32168, y = 0.33767.
The ACES white point is D60-like but not CIE D60. It is an encoding neutral, not a required display or creative white. Grade to the calibrated display white. The Output Transform handles adaptation. See Academy TB-2018-001 §§3–4 for the derivation.
What it means in practice
- You do not grade to D60. Set your grading display to its calibrated white point (P3-D65 or DCI for theatrical, D65 for home video) and grade normally.
- The Output Transform handles the adaptation. Converting ACES to a D65 output applies a chromatic adaptation. That is expected behavior, not an error.
- When neutrals drift, look here first. If grays read warm or cool between the grading display and a deliverable, a mismatched or doubled white-point adaptation in the transform chain is the usual cause, more often than a monitor calibration fault.
- Do not "correct" the ACES white point. Productions occasionally try to force ACES to D65 by inserting an adaptation before the Output Transform. This double-adapts and produces exactly the neutral drift it was meant to fix.
- Use D60-sim only when D60 rendering is intentional. It preserves ACES white on a D65 display without adding an extra adaptation before the Output Transform.
Encodings
| Encoding | Primaries | Transfer | Use |
|---|---|---|---|
| ACES2065-1 | AP0 | Linear | Interchange between vendors and archival. The "full fidelity" exchange format. |
| ACEScg | AP1 | Linear | CGI rendering and compositing. |
| ACEScc | AP1 | Logarithmic | Color grading, where controls expect a log relationship to scene exposure. |
| ACEScct | AP1 | Logarithmic with a toe | As ACEScc, with a film-like toe near black that makes lift/offset behave the way colorists expect. |
| ACESproxy | AP1 | Log, integer | On-set look management and transmission over HD-SDI. Not for storage, production imagery, or final grading. |
ACES2065-1 values are 16-bit floating point, with 1 sign bit, 5 exponent bits, and 10 mantissa bits. They encode relative exposure values linearly.3
ACEScc vs ACEScct
Use ACEScct unless you have a specific reason not to. ACEScc is purely logarithmic to black, which makes a lift adjustment behave very differently from the log grading controls most colorists have muscle memory for. ACEScct adds the toe and is the usual choice for grading. Pick one and specify it in the workflow document. Mixing them across vendors produces subtle mismatches in the shadows that are painful to diagnose late.
Transforms
ACES 1.0 deliberately renamed the transforms in user-facing terms. TB-2014-012 records both the old and new names, and explicitly deprecates "RRT" in end-user documentation:
| Current name | Formerly | Does |
|---|---|---|
| Input Transform | Input Device Transform (IDT) | Converts camera-native data to ACES2065-1 |
| Look Transform | Look Modification Transform (LMT) | Applies a global, show-wide look upstream of the Output Transform |
| Output Transform | "RRT plus ODT" | Converts ACES data to display code values |
The Look Transform is a show-wide creative transformation analogous to a Show LUT. See Academy TB-2014-010 and Look Transforms.
Grade under the Output Transform. Do not bake it into the render. Keep the Graded Archival Master scene-referred and apply the display transform last.
Container
ACES image data is carried in the ACES Image Container, SMPTE ST 2065-4. It is OpenEXR-compatible but feature-restricted: a constrained profile of EXR rather than arbitrary EXR. It stores 16-bit half-float pixels and mandates a fixed set of header attributes. ST 2065-4:2023 lists ten required attributes, one of which is compression.4
ST 2065-4 containers are uncompressed
SMPTE ST 2065-4 applies only to ACES2065-1 (AP0, linear) interchange and archival files. It requires uncompressed 16-bit half-float EXR. ACEScg plates, renders, and working files are ordinary OpenEXR files and may use normal ZIP, PIZ, or DWA compression.
| File | Typical encoding | ST 2065-4 container? | Compression |
|---|---|---|---|
| Archival / source master | ACES2065-1 (AP0) | Yes | Uncompressed (mandated) |
| Full-fidelity vendor interchange | ACES2065-1 (AP0) | Yes | Uncompressed (mandated) |
| VFX plate pull | ACEScg or camera-log EXR | No | Compress freely (ZIP/PIZ/DWA) |
| VFX render back to the DI | ACEScg (AP1) EXR | No | Compress freely |
| Comp working files | ACEScg (AP1) EXR | No | Compress freely |
A compressed ACES2065-1 EXR may open normally but is not a conformant ST 2065-4 container.
Clip-level metadata travels in an ACES Metadata File (AMF specification). The earlier ACESclip form is described in Academy TB-2014-009. LUTs travel in the Academy-ASC Common LUT Format (CLF specification, S-2014-006).
The Reference Gamut Compression (RGC specification) added in ACES 1.3 handles out-of-gamut camera values. Use it when saturated practical lights or lasers produce artifacts outside AP1.
ACES 2.0
Pin your ACES version
ACES 2.0 is now the version named by the VFX Reference Platform for CY2025 and CY2026, and it ships in DaVinci Resolve 21 and Baselight v7, but plenty of in-flight shows and older OCIO configs are still pinned to 1.x. Confirm which version each vendor is actually running before committing a show, and verify specifics against the ACES documentation.
ACES 2.0 replaces the separate RRT and ODT with one Output Transform built on the Hellwig 2022 JMh color appearance model. It adds a unified tone scale, chroma compression, volumetric gamut compression, and improved invertibility.5
Version history: 1.0 (2014), 1.1 (2018), 1.2 (2020), 1.3 (2021), 2.0 (2024–25). Many existing projects and configs remain pinned to 1.3.
Do not switch versions mid-show
ACES 2.0 output does not match 1.x. Finish on the version used to start the show.
Whether a full color appearance model belongs inside a display rendering transform is an open argument in the field, with ACES 2.0 on one side and approaches like FilmLight's TCAM on the other. It is not a settled question.
Should an independent production use ACES?
Yes when:
- You are working with multiple camera systems and multiple VFX vendors. ACES gives everyone a specified pipeline to implement, so plates and renders interchange without a bespoke negotiation per vendor.
- You lack the color-science infrastructure or resources to produce and vet a custom workflow. A standardized, documented pipeline you can adopt is safer than a homemade one you cannot fully test.
Maybe not when:
- You have a single camera acquisition format. Much of what ACES buys you is interchange across disparate sources. With one source, a well-run camera-native workflow may be simpler.
- You have a strong creative reason to deviate from the ACES Output Transform. If the look you want fights the standard rendering, you are working against the system rather than with it.
- You have a fixed, well-understood set of deliverables and the preparation to accommodate them. If nothing about the job needs neutral interchange or archival, the setup cost may not pay for itself.
Adopting ACES badly is worse than a well-run camera-native pipeline. It costs setup, testing, and vendor discipline.
Choose the ACES version in pre-production, record it in the format specifications, and round-trip a confidence package before shot work.
Pitfalls
- Compositing in AP0. Use ACEScg instead.
- Two Output Transforms. Applying a display transform in the comp and again in the DI creates the classic double-tone-map. Renders delivered to the DI should be scene-referred, with the Output Transform applied by the colorist.
- An Input Transform that does not match the camera settings. Input Transforms are specific to camera, and often to color science version and recording mode. "ALEXA" is not a specification. "ALEXA 35, LogC4, AWG4" is.
- Assuming ACES removes the need for a look. ACES gives you a neutral rendering, not a look. Productions that skip look development and grade against the bare Output Transform tend to discover the film has no visual point of view somewhere around the DI.
- Treating "we're ACES" as a workflow document. It specifies neither resolution, nor bit depth, nor handle length, nor naming. Those still need to be written down.
-
The ACES documentation, the aces-aswf/aces repository (formerly ampas/aces-dev), and the SMPTE ACES standards: ST 2065-1 through ST 2065-5, normative and, since 2025, freely downloadable from the SMPTE library. ↩
-
Academy TB-2014-004 (informative notes on ST 2065-1) and S-2014-004, published as ACEScg. ↩
-
Academy TB-2014-004, §4.2.3. Encoding specifications: ACES2065-1 (ST 2065-1) · ACEScg (S-2014-004) · ACEScc (S-2014-003) · ACEScct (S-2016-001) · ACESproxy (S-2013-001). Component naming follows Academy TB-2014-012, except ACEScct, which postdates it and was defined in S-2016-001. ↩
-
SMPTE ST 2065-4:2023, ACES Image Container File Layout, §6.5.3 and Table 5 (required attributes). The 2023 edition revises ST 2065-4:2013. ↩
-
The
aces-aswf/acesrepository carries two non-prereleasev2.0.0tags:v2.0.0+2024.09.05andv2.0.0+2025.04.04, so "released in 2025" and "released in 2024" are both defensible depending on whether you mean the reference implementation or the public launch. ↩