ACES

ACES or the Academy Color Encoding System is an open color management and interchange system developed by the Academy Of Motion Picture Arts & Sciences (AMPAS) and industry partners.

ACES standardizes the color science used in projects of all types and is designed to give the industry a standardized color management system that encompasses production, post-production, presentation, and archiving.

The Goal Of ACES

In 2004 when the ACES project started, the Academy Of Motion Picture Arts & Sciences (AMPAS) and many industry experts realized a need for an open color management system that was suitable to handle the complexity of modern digital production.

In an industry with dozens of different camera systems, multiple encoding options, different display devices, etc, the Academy saw a need for a system like ACES to manage color in a precise, yet straightforward way, no matter the camera or display being used.

Many software developers have tackled color management in their own applications, but none of those solutions are industry-wide and open. ACES is an industry-standard color management solution that anyone can use to manage the color pipeline of any project.

Since ACES 1.0 was released in 2014, ACES pipelines have been used on dozens of Hollywood blockbusters, TV series and independent films. The ACES pipeline is available today in many applications including DaVinci Resolve, Filmlight’s Baselight, Nucoda, and many others.

Understanding Capture & Scene Referred Data

One of the most important things to understand about ACES is that its processing pipeline utilizes capture-referred data – i.e. the color science (and sometimes secret sauce) that each camera system uses and bakes into the signal. ACES reverse-engineers that data (through what’s known as an ACES Input Transform or IDT) back into the pure linear light information that was in the actual scene in front of the camera. Theoretically, without any camera bias.

This is why ACES is often discussed as being scene-referred or, with the more technical phrase, scene-linear. Abstracting away the camera’s bias allows us to get closer to the actual scene that the camera was pointing at.

Additionally, ACES color uses a color space so large it actually encompasses the entire visual locus (everything humans can see) and even light we can’t even see! And even the smaller working color spaces are also very large (the particulars of ACES color space(s) will be discussed in a later section).

ACES is a unifying standard – transforming captured referred data from many cameras into scene linear with a common starting point and shared color science.

ACES is also broad – in an ACES workflow you never run into the limitations of working in smaller color spaces. For client handoffs and archival purposes, the ACES color space is so large it is essentially ‘future proof’.

The scene linear approach of ACES is only part of the overall pipeline.

The human eye doesn’t work in a linear fashion and ultimately projects are viewed on TVs, projectors, etc., that assign gamma or EOTF (Electro Optical Transfer Function) curves that aren’t linear. These devices also have much more limited color spaces compared to ACES.

Because of this, ACES also incorporates display-referred color management as part of the overall pipeline. ACES data is parsed through different transforms for different color spaces and display devices.

When it comes to precision, ACES uses Open EXR 16-bit half-float processing which results in 30+ stops of scene referred exposure.

Keep in mind that even though EXR is used, often this processing is just internal to the app you’re using and no EXR files are created for you to manage – except in renders.

In sum, these are the benefits of ACES pipelines:

• Camera System Color Science Unification – Because of the capture-referred, scene-linear transform at the start of an ACES processing pipeline (no matter the camera(s) that were used on a project) there is a common color science starting point that all ACES capable applications can use and understand.
• No Guessing For VFX/CGI Workflows – one reason that ACES has been embraced by VFX/CGI heavy films is that they’re compositing and working in linear anyway! And that linear data can then be rendered back to whatever is appropriate to the project, or kept linear and given back to a colorist to simply re-apply their existing grade with no look shifting.
• Ready For Wide Gamut/High Dynamic Range – now and in the future. Because ACES is capable of retaining 30+ stops of image data and the gamuts are so large, it’s a great match for HDR, wide gamut projects, however those concepts may develop in the future.
• Evergreen Digital Master – One thing that the Academy pushes about ACES is that it allows for a true evergreen digital master because of the ultrawide/high dynamic range nature of the system.

The ‘Parts’ Of ACES

Even though ACES and its various transforms are mathematically complex, you can understand ACES better by understanding what each part or transform in the pipeline does.

Here’s the terminology for each of these transforms (after we define the transforms, in the next section, you’ll see how they work together in an ACES pipeline):

• ACES Input Transform (aka: IDT or Input Device Transform) – The Input Transform takes the capture-referred data of a camera and transforms it into scene linear, ACES color space. Camera manufacturers are responsible for developing IDTs for their cameras but the Academy tests and verifies the IDTs. In future versions of ACES, the Academy may take on more control in the development of IDTs. IDTs, like all ACES transforms, are written using the CTL (Color Transform Language) programming language. It’s also possible to utilize different IDTs for a camera system to compensate for different camera settings that might have been used.
• ACES Look Transform ( aka: LMT or Look Modification Transform) – The first part of what’s known as the ACES Viewing Transform (the Viewing Transform is a combination of LMT, RRT, & ODT transforms). Provides a way to apply a look to a shot in similar way to using a Look Up Table (LUT). It’s important to note that the LMT happens after color grading of ACES data and not every tool supports the use of LMTs.
• RRT (Reference Rendering Transform) – Think of the RRT as the render engine component of ACES. The RRT converts scene referred linear data to an ultrawide display-referred data set. The RRT works in combo with the ODT to create viewable data for displays and projectors. While the Academy publishes the standard RRT, some applications have the ability to use customized RRTs (written with CTL), but many color correction systems do not provide direct access to the RRT.
• ACES Output Transform (also known as the ODT or Output Device Transform) – The final step in the ACES processing pipeline is the ODT. This takes the ultrawide, high dynamic range data from the RRT and transforms it for different devices and color spaces like P3 or Rec 709, 2020, etc. ODTs like IDTs and RRTs are written with CTL

There are also three main subsets of ACES used for finishing workflows called ACEScc, ACEScct and ACEScg:

• ACEScc uses logarithmic color encoding and has the advantage of making color grading tools feel much more like they do when working in a log space that many colorists prefer.
• ACEScct is just like ACEScc, but adds a ‘toe’ to the encoding so that when using lift operations the response feels more similar to traditional log film scans. This quasi-logarithmic behavior is described as being more ‘milky’, or ‘foggier’. ACEScct was added with the ACES 1.03 specification and is meant as an alternative to ACEScc based on the feedback of many colorists.
• ACEScg utilizes linear color encoding and is designed for VFX/CGI artists so their tools behave more traditionally.

While ACEScc, ACEScct and ACEScg and the transforms they use are what you’ll most often see when it comes to ACES, there are some additional terms you may encounter:

• APD (Academy Printing Density) – AMPAS supplied reference density for calibrating film scanners.
• ADX (Academy Density Exchange) – Used for scanning film and getting those scans into ACES – similar to the Cineon system for scanning.
• ACESproxy – uses logarithmic color encoding and is a integer, range limited version of ACEScc. ACESproxy is meant to be used on set with compatible equipment over SDI.

The ACES Pipeline

Now that we’ve defined the transforms used for ACES, understanding how the various transforms combine to form an ACES processing pipeline is pretty straightforward:

Camera Data -> Input Transform -> Color Grading -> Look Transform (optional) -> Reference Rendering Transform -> Output Transform

As mentioned, ACES is hybrid color management system of scene referred/scene linear and display referred data.

In the graphic below, the various ACES transforms fit into the scene referred (top section) and display referred (bottom section) part of the pipeline:

Understanding ACES Color Spaces

When ACES is discussed, you’ll often hear some highly technical phrases to describe ACES: 2065-1, AP0, AP1, Rec.2020+.

What do these terms mean?

SMPTE ST 2065-1 is the SMPTE standardization of ACES.

While this standard has many parts, in daily usage ACES 2065 has come to mean the full linear version of ACES that has a larger gamut than the visual locus set of primaries (red, green & blue). ACES 2065 has a set of primaries known as AP0 (ACES Primaries 0).

A standard CIE1931 plot is a good way to compare ACES to other gamuts. The horseshoe of colors represents the human visual locus – all the colors we can see. The plot on the left shows ACES AP0 primaries compared to other gamuts, you can also see it’s larger than the entire visual locus. The plot on the right shows ACES AP1 primaries compared to other color gamuts. AP1 primaries are used in ACEScc, ACEScct & ACEScg

2065-1 AP0 is mainly meant for archival and file exchange. In real-world usage – grading, vfx etc, 2065-1 AP0 is not used. Instead, a smaller set of primaries called AP1 (ACES Primaries 1) are used. Also known as Rec2020+, AP1 primaries are slightly larger than Rec. 2020 which is championed as an ultra wide gamut for the future, and it’s the AP1 Primaries that are used in ACEScc, ACEScct, and ACEScg.

ACES Versions & Open Source Development

Currently, the official version of ACES is 1.1 but many applications are not supporting that version yet, although version 1.03 is widely supported. Unless there are major future changes and/or needs for end users as determined by AMPAS, you will continue to see the major release versions in software and probably not the minor .0x releases even though software manufacturers behind the scenes may implement the .0X releases for performance and bug fixes.

Projects created using older versions of ACES can be opened using a newer version of ACES that an application uses, but this may cause some differences in image representation compared to the original project. Some applications offer the ability to switch the version of ACES being used to an older one to match the ACES version that was used in the original project.

It’s also worth noting that ACES development is ‘open source’. AMPAS manages and curates the development of the system but if you’re mathematically/color science inclined, you can contribute to the development of the system or observe the development process by visiting the GitHUB repository the Academy maintains for ACES:

https://github.com/ampas/aces-dev

Also, as mentioned, ACES transforms are written in CTL or Color Transform Language. The Academy also maintains a GitHub repository for CTL:

https://github.com/ampas/CTL

ACES Central

If you’re less technically-inclined, you can also visit ACES Central. ACES central is a site that AMPAS maintains geared towards discussion of ACES and is frequented by end users and ACES certified partners.