Introduction

The careful reader may have noticed that around 2021 my analysis on ACES has changed quite a bit. It went from “ACES is awesome” to “ACES has issues and limitations“. But don’t get me wrong: the idea of ACES (a framework to help professionals) is great and ACES 1.X has been my entry point to color management.

Over the past five years (since September 2018, my first post), I have learned so much partly thanks to the ACES community. But I think ACES 1.X is a faulty color management workflow, especially the Output Transforms. This is an issue since they are the most critical part of the “Image Formation Chain“.

One of my concerns is that many artists who are not comfortable with color management have completely given up on actually trusting their eyes. There is like an “appeal to authority”: “if it has been done by the Academy and used on the Lego movies, then it MUST be good.” You don’t believe me ? Well, check this out:

Why on earth would a blue rabbit turn magenta ? These two images come from the Redshift and Unreal documentations, two respectable render engines. And the fact that ACES has been implemented in most DCCs just adds more fuel to this “trendy effect”: “if ACES is implemented everywhere, it HAS TO work.“

Nonetheless, rather than deleting this page from my website, I think it is more constructive and responsible to explain precisely what ACES is and what are the pitfalls to avoid. Even with the recent release of ACES 2.0, most of the challenges and processes described in this article are still valid.

ACES overview

ACES 1.X is a Color Management Workflow (CMW) developed by dozens of professionals under the auspices of the Academy of Motion Picture Arts and Sciences , whose goal is to set a standard to help professionals. Many VFX studios such as ILM, Framestore, Double Negative and Animal Logic use it to exchange files and officially more than 300 movies have been done using ACES.

After some investigation, I would be careful about the previous statement. It has been confirmed during one of the TAC meetings that some of the movies listed were not using the ACES Output Transform.

ACES is mostly used for exchanging files.

ACES is available for free through OCIO (here is the link to the official ACES configs), just like the spi-anim config. ACES has also been implemented in CTL in Resolve and GLSL / HLSL in Unreal and Unity.

You can check the contributors and the TAC members here (in the “CONTRIBUTORS” tab).

My first contact with ACES happened at Animal Logic in 2016. The artists were working on a beautiful and very saturated movie called “Lego Batman”. It was my first day and I saw this shot on a monitor (I think Nick Cross lit this shot):

I thought to myself: “Wow ! This looks good ! How did they get these crazy colors ?” The range of colors really seemed wider than in my previous studio. Here are a few reasons:

• First, Animal Logic uses “P3″ monitors which is the industry standard for cinema theaters.
• Also “Lego Batman” used ACES 0.1.1 which is a completely different version of ACES 1.X.
• Finally, the art direction by Grant Freckelton definitely helped to achieve this colorful result.

Why ACES ?

When cameras were analog, things were simple because there were only a couple of formats: 35mm and 70mm. The Original Print, shot on film, was available for eternity.

But with the digital revolution, multiple cameras and formats have emerged. These proprietary systems, used for Digital Source Master (DSM), can be outdated quite quickly or even worse, not sufficiently documented.

Issue is when these movies have to be remastered for new supports, the DSMs are not relevant anymore and the original creative intent is lost. So the original idea behind ACES was to encode these archives in a “standard” format to make them less ambiguous. The first name of ACES was indeed the “Image Interchange Framework” (IIF).

What is ACES2065-1 ?

ACES includes a series of color spaces and transforms that allows you to manipulate them. The reference color space developed by the Academy is called ACES2065-1:

• Ultra Wide Gamut (non-physically realizable primaries)
• Linear
• High Dynamic Range
• Standardized
• RGB

ACES2065-1, also called “the ACES color space“, is meant to be used for exchanging and archiving files. BUT it has been explained quite clearly in this post that there are still some uncertainty regarding the use of this format:

The ST2065-1 file format is far from unambiguous. […] If I give you a ST2065-1 file you don’t know if it was made with the ut33, 0.1.1, 0.2.1, 0.71, 1.03 or 1.1 version of ACES. Which all will produce quite a different version of the movie. […] What I am really afraid of for our future generation is that they will restore severely limited ST2065-1 files, because we rendered hacky LMTs into our masters which go to 709 and then back again, just because the actual system was not flexible enough.

The archiving purpose has not been achieved yet. Maybe the ACES Metadata File (AMF) will help in that regard.

ACES in one picture

ACES is composed of three main steps described in the following image:

• A. IDT is the import/conversion of the textures/images/renders to the ACEScg color space.
• B. ACEScg is the rendering/working space.
• C. RRT + ODT are the Output Transform to the monitor or video projector.

We used to say “RRT (Rendering Reference Transform)” and “ODT (Output Device Transform)”. I will refer to them as “Output Transform”.

RRT and ODT were merged for the HDR Output Transforms in ACES 1.1.

The idea behind ACES is to deal with any color transform you may need:

• Is your texture in sRGB from Internet ? Or is it in “linear” within the P3 gamut ? ACES provides all the matrixes and LUTs to convert one color space to another with the IDT (Input Device Transform).
• Is you monitor Rec.709 or P3 ? ACES provides all the LUTs to view your renders with the appropriate Output Transform.

This is why one of the important things about Color Management: you must know the color space (primaries, transfer function and white point) for each process (input, working space and output).

ACES tries to clarify that.

ACES color spaces

Here is a list of the main ACES color spaces:

• ACES 2065-1 is scene linear with AP0 primaries. It is the interchange and archival format (for DCDM).
• ACEScg is scene linear with AP1 primaries (the smaller “working” color space for Computer Graphics).
• ACEScc and ACEScct have AP1 primaries and their own specified logarithmic transfer functions.

	Primaries	White Point	Transfer functions	Usage
ACES2065-1	AP0 (non-physically realizable)	~D60	Linear	Interchange and archival space
ACEScc	AP1 (non-physically realizable)	~D60	Logarithmic	Working space (color grading)
ACEScct	AP1 (non-physically realizable)	~D60	Logarithmic (Cineon like)	Working space (color grading)
ACEScg	AP1 (non-physically realizable)	~D60	Linear	Working space (rendering, compositing)

The ACES White Point is not exactly D60 (many people are wrong about this actually). It was chosen to avoid any misunderstanding that ACES would only be compatible with scenes shot under CIE Daylight with a CCT of 6000K.

It’s all explained in the official documentation.

Why ACEScg ?

What about computer graphics ? Back in 2014 and 2016, some tests have been conducted by Steve Agland (Animal Logic) and Anders Langlands (Weta Digital) to render in ACES2065-1. An unexpected issue occurred when rendering in the ACES2065-1 color space: it was so big that it would mess up with energy conservation. Some color peeps refer to this event as “The Great Discovery“.

On top of that, grading on ACES2065-1 did not feel “natural“. Therefore, another color space has been created for computer graphics: ACEScg (AP1 primaries), which is similar to Rec. 2020. I will repeat in bold and with emphasis because it is CRITICAL: you should never render in ACES2065-1.

The creation of ACEScg is detailed in this post from Digipro 2015.

ACEScg: our working/rendering space

Why would we render in one color space and display in another ? What is the point ? Remember the rendering space and the display space from Chapter 1 ? We have already seen that they do not have to be the same.

But what if I told you that rendering within different primaries will NOT give the same result ? I’ll repeat for clarity: rendering in “Linear – sRGB” or “ACEScg” will not give the same “beauty” exr. The lighting calculation and therefore result will be different.

At Animal Logic, Lego Batman and Ninjago were rendered in “linear – P3-D60″, which was entirely down to the space the surfacing was done in. Peter Rabbit forward was rendered in ACEScg.

The choice of rendering primaries is definitely not a trivial decision…

First of all, we shall all agree that RGB rendering is kind of broken from first principles (compared to spectral rendering). So we want to use a color space for rendering that makes it a bit less broken and ACEScg is a good candidate for that. By switching from “Linear – sRGB” to “ACEScg“, you will access Wide Gamut Rendering.

To perform a proper comparison between rendering color spaces, we’d need a reference called the “ground truth“. In our case, it would be an unbiased image generated by the spectral render engine Mitsuba. Otherwise we could not compare the renders properly !

The claim is not that BT2020 or ACEScg are the ultimate color spaces, in fact none is, the claim is that they tend to reduce error generally a bit better compared to others. They happen to have an orientation that is the jack-of-all-trades of all the major RGB color spaces.

Thomas Mansencal.

Comparison between Spectral, Rec.709 and Rec. 2020

Some interesting tests and research have been conducted by Anders Langlands and Thomas Mansencal. They are explained in this post. Three different renders have been done:

• sRGB/Rec.709 primaries, the smallest gamut of all.
• Spectral, the ground truth using wavelengths for its calculation.
• Rec. 2020 primaries, which are similar to ACEScg.

Then, you subtract them from one another. The darkest it gets, the closer it is to spectral ! So if you have a look at the bottom row the average value is overall darker, which means that Rec. 2020 gets us slightly “closer” to spectral rendering.

What is the difference between ACEScg and Rec. 2020 ? What is the advantage to have the three ACEScg primaries out of the CIE diagram ? To encompass P3 mostly, ACEScg is a gamut close to BT.2020 but that encompasses P3. This requires non-physically realizable primaries.

It is worth noting that the choice of the ACEScg primaries was controversial.

A closer look at ACEScg

From my personal experience, I can share that rendering in ACEScg:

• Is not “better” than rendering in “Linear – sRGB”. It is different and you should test by yourself to see if wide gamut rendering fits your needs.
• Gives a result which is slightly closer to spectral rendering, but this not suitable for all projects.
• Does not give access to more bright and saturated colors. These values do not make it to the display !

Wide gamut rendering has both pros and cons. And as always, you should test for yourself.

From Thomas Mansencal: On a strictly technical point of view, rendering engines are indeed color spaces agnostic. They just chew through whatever data you throw at them without making any consideration of the color space the data is stored into. However the choice of color space and its primaries is critical to achieve a faithful rendering. […]

This post on ACESCentral also explains it clearly.

Input Device Transform (IDT)

The IDT is the process to import the textures/images to your working/rendering space, which most likely will be ACEScg.

Cornell box example

Here are two renders of a Cornell Box in Guerilla Render. I have used the same “linear sRGB / BT.709 textures“ for both renders, with the following values:

1. Green sRGB primary at (0, 1, 0).
2. Red sRGB primary at (1, 0, 0).
3. Middle gray at (0.18, 0.18, 0.18).

The only difference between these Cornell boxes is the rendering space:

• In the first one, the rendering space is what many softwares call “linear“, which actually means “sRGB / BT.709” gamut with a linear transfer function (“Utility – Linear – Rec.709“).
• In the second one, the rendering space is ACEScg. I set the IDT accordingly to properly test the wide gamut rendering.

Main thing about this test to take in account is that I used some textures. If you use colors directly in your software, you may not get the same result. You must also be careful with your mipmap generation (tx files). If you switch your rendering space, it is safer to delete the existing tx files.

Why do we get a different global illumination ?

Let’s use OCIO in Nuke to analyze what is actually happening:

• On the left, we have a pure green constant at (0,1,0).
• We convert it from sRGB to ACEScg using an OCIOColorSpace node.
• The same color expressed in ACEScg has some information in the red and blue channels. It is really just a conversion: ACES does not “add” anything. It is the same chromaticity but expressed differently.

Here is another way of explaining it:

• On the left, we have a green primary in the sRGB/Rec.709 color space.
• Using a Matrix 3×3 to modify the reference space from “sRGB” to “ACEScg“, this chromaticity with unique XY coordinates has been “converted”.
• The color is not a pure green anymore in the ACEScg color space (right image).

Because of the conversion process, the ray is no longer stopped by a zero on some channels (red and blue in this case). Light paths are therefore less likely to be stopped by a null channel.

IDT overview

ACES provides all the 3D LUTs and matrixes we need to process these transforms. Most common IDT for Computer Graphics are:

• Utility – sRGB – Texture: If your texture comes from Photoshop or Internet. Only for display-referred textures encoded with an sRGB OETF, like an albedo map.
• Utility – Linear – Rec.709: If your texture is linear within the sRGB / BT.709 primaries and you want to convert it to ACEScg, like an exr file.
• Utility – Raw: If you do NOT want any transform applied on your texture, like normal maps.

Please note that if your rendering space is ACEScg, in this particular case “Utility – Raw” and “ACEScg” are contextually the “same” IDT. No transforms are applied with both options.

To plot the gamut

Plotting the gamut of an image allows you to map its pixels against the CIE 1931 Chromaticity Diagram:

• On the first image, we have plotted a render done in sRGB. The pixels are within the sRGB gamut.
• On the second image, we have plotted a render done in ACEScg. The pixels have a wider coverage of the gamut.

This function is available in colour-science. There is also an app available on Windows and Mac called Color Spatioplotter if you want to plot the gamut of an image. I haven’t tried it myself but from the feedback I got, it seems to be working fine at a very affordable price.

As a conclusion on this IDT / ACEScg section, I would like to add that:

• The Cornell boxes examples are best-case scenarios. In real production, with much more complex stimuli, the differences are not that important.
• “Closer to Spectral” rendering should be interpreted as “the chromaticities after indirect bounces are closer“, which again does not necessarily look “better”.
• Wide gamut rendering adds an another layer of complexity when it comes to displaying these images, since a proper gamut compression (which ACES 1.X does not have) would be needed.

Again, test for yourself, trust your eyes and compare both pros and cons.

Output Transform

The ACES 1.X Output Transform is made of two separated steps called the Reference Rendering Transform (RRT) and the Output Device Transform (ODT). This is still true for all Output Transforms in ACES 1.0.X. But the release of ACES 1.1 introduced some new HDR Output Transforms as a single step, which is called Single Stage Tone Scale (SSTS).

The origin of the two steps Output Transform (RRT+ODT) can be found in this document by Ed Giorgianni:

• RRT: intermediate rendering to an idealized and hypothetical reference display. It is the “ACES look“, like a virtual film stock. The output of the RRT is called Output Color Encoding Specification (OCES).
• ODT: final rendering for a specific real-world display device (primaries, eotf and white point). It also takes in account the viewing environment (dark, dim or normal surround) and the nits.

In the next paragraphs, you will find a description of the ACES 1.X Output Transforms. Watch out for their limitations and issues !

Reference Rendering Transform (RRT)

In practice, the RRT + ODT process is combined for the user but I think it is worth to describe here some components of the RRT. I got particularly interested by the infamous “sweeteners“: glow module, red modifier and global desaturation. Here are a few quotes about their history:

[They] originally came from an aim to be “pseudo filmic” in the early days. [..] Glow came from perceived filmic look. […] Red modifier and glow are different. Glow is aesthetic.

Scott Dyer

I don’t consider [the red modifier] a “sweetener”. It’s compensating for saturation effect of RGB tone scale.[…] It is compensating for “hot” reds.

Doug Walker and Alex Forsythe

These “sweeteners” have generated much debate about where they belong and if they should be part of a Look Modification Transform (LMT). They also cause problems for invertibility.

Output Device Transform (ODT)

The ODT is the process to display the reference (OCES) on your monitor and the Academy recommends the use of an ODT adapted to your screen. It should be based on your project needs:

• Do you work for TV and Internet ? You should display in sRGB or Rec.709.
• Are you working in Feature Film ? You should display in P3.

Rec. 2020 is the future but there are no projectors that are able to cover 100% of this color space. The technology is not there yet. But in ten years maybe, it will be the new norm. So as far as I know, in 2026, Rec.2020 is actually only used as a container for P3 deliveries.

Not there yet, unless you own a Christie.

Examples and comparison of Output Transforms

Here are some examples comparing the “nuke-default” OCIO setup with ACES 1.1:

Please note that Nuke is wrong in its OCIO config. The “rec709” View implemented in Nuke (approximatively a Gamma value of 1.95) is a camera encoding OETF ! Rec.709 (ACES) uses a BT.1886 EOTF (equivalent Power function of 2.4) and is in reference to an EOTF output display.

I have also done a test on the MacBeth chart to compare the “Film (sRGB)” from the spi-anim config with the ACES config:

I’ll just put it out there so that it is clear: there is no point in using a P3D65 ACES ODT if your monitor only covers sRGB. It won’t make your renders look prettier.

Your ODT should match your monitor characteristics basically.

More adequate and fair comparisons are provided below (“nuke-default” and “spi-anim” are not like the most advanced display transforms out there):

I have used this experimental OCIO config to compare different Output Transforms.

We can see in those examples that the path to white is just an “happy accident” where colors converge to primaries and their complements (light mixtures in the working space are not respected).

One issue that has often been noticed is what we call the Blue Light Artifact. It is described in this post from ACEScentral. A temporary fix has also been provided until a more long-term solution is found, such as the Gamut Compress by Jed Smith.

Output Transform clarification

Many artists have been confused by Nuke’s default display transform:

• Why does sRGB display transform and sRGB (ACES) do NOT match ?
• Because the sRGB (ACES) Output Transform includes some tone mapping !

In ACES, we call this the “rendering” step. Going from ACEScg (scene-referred) to your display is not a simple color space conversion. It is actually a “complex” (color and tonality) rendering operation.

Nick Shaw also explains it on ACEScentral.

Output Transform overview

Some people complained about the tone mapping included in the Output Transform. These answers were given on the forum:

• The ACES tone mapping is not “neutral”, it comes with a “look”. Its values are not arbitrary neither, but indeed subjective.
• The contrast of the RRT/ODT was validated by many very experienced industry professionals in a carefully setup projection environment.
• The tone mapping has much less shadow and highlight compression happening in the HDR ODTs.
• The ACES Viewing Transforms are a “do-your-best” on each device with different viewing conditions.

Some additional explanations about the RRT/ODT process from this post.

In fact, the ACES 1.X Output Transforms were created with “contradictory design requirements“ and a core technology (per-channel lookup) that has proven to be inadequate and overly complex (the SSTS is over a thousand lines of code). So all of the complaints above are valid in my opinion, especially the ones regarding a more “neutral” starting point and overall contrast.

For instance, as you can see in the screenshot below, the ACES 1.X Output Transform actually prevents us to reach certain colors on display:

This comparison with openDRT comes from this post originally.

Delivery

In animation studios, we generally deliver scene-linear exr files to a digital laboratory, such as this one. With ACES, it is pretty much the same concept with a few important notes since it is recommended to deliver ACES compliant EXR files.

This is the standard set by the Academy to exchange files between facilities. Your render output will be ACEScg (AP1) but your compositing output has to be ACES2065-1 (AP0) with the correct metadata.

Rendering in ACEScg uses color primaries that are closer to actual devices – a little bigger than Rec2020, but AP0 is the target for File Outputs (archive and interchange). When working completely within your own facility without sharing of files, ACEScg is sometimes used for convenience but using the format in the name of the file to distinguish it from the ACES standard (putting ACEScg in EXR with the primaries specified – a device or AP1 – means it is not an ACES file). The ACES flag in a header should not be set.

Explanation by Jim Houston.

The interchange and archival files should be written as OpenEXRs conforming to SMPTE 2065-4. In Nuke, you should set the Write node’s color space to ACES2065-1 and check the box “write ACES compliant EXR” to get the correct metadata.

As explained by Doug Walker on ACEScentral.

ACES 1.X limitations

Before we dive in, I would like you to know that I have written an article about display transforms (including ACES 1.x) in September 2021. This is a complementary and also more in-detail read than this chapter. Feel free to dive in at your own pace !

ACES Retrospective and Enhancements

In March 2017, a study has listed some possible improvements for ACES 1.X: ACES Retrospective and Enhancements, which got an official response from the ACES Leadership. A list of 48 points to improve was published on the forum and several Virtual Working Groups tried to come up with some possible “fixes” to the system.

Hue skews and Gamut Clipping

The two biggest issues I have encountered with ACES are called “Hue skews” and “Gamut Clipping“. Some image makers believe that the audience got used to it and are not bothered and some find them truly horrific. So I think it is best if I let you decide for yourselves:

In these slides I named the issue: “posterization”. It has been discussed on ACESCentral and described as “Gamut Clipping”.

There are different reasons for this kind of issues. They are pretty technical but I have listed them below:

• A 3×3 matrix can only model linear transformations which may induce Abney effect because they are straight lines (just like brute force gamut clips).
• Discrete per-channel lookups (also called “RGB tone mapping“) skew the intention. Any aesthetic transfer function that asymptotes at 1.0 suffers this.
• The aesthetic transfer function ends up collapsing lots of different values into the same one, hence Gamut Clipping. The non-physically realizable primaries of ACEScg may also be responsible.

The ODTs clip values

Most of these notions are eventually related to what we call gamut mapping. This is the key element missing in ACES 1.X (I have thought for a very long time that the ODT would remap the gamut it in a smart way). Unfortunately it is not the case, it just does a 3×3 matrix transform, a tone scale and a clamp !

As you can see in the code below, an ODT brings the values back into its gamut through a 3×3 matrix and a clamp which cause some Gamut Clipping. This is one of the issue we are facing with very saturated values:

// Handle out-of-gamut values
// Clip values < 0 or > 1 (i.e. projecting outside the display primaries)
linearCV = clamp_f3( linearCV, 0., 1.);

All ODTs clamp to the target gamut so it is impossible to have something outside of it. All values ​​are assumed to be between 0 and 1 after this process and it is the penultimate step before the transfer function.

We could say that the gamut mapping in ACES 1.X is very “crude” or completely missing. It really depends on how you see things…

Summary

Here are the key points we have seen in this chapter:

• ACES is an attempt at setting a standard Color Management Workflow.
• It is designed around three steps: the Input Transforms (for input/import), ACEScg (working/rendering space) and the Output Transforms (for display).
• ACES is composed of four different color spaces itself: ACES2065-1, ACEScc, ACEScct and ACEScg.
• ACES has issues such as Hue Skews and Gamut Clipping which are difficult to solve.

In the slides below, you will see the different steps of an ACES workflow:

As a personal exercise for myself, I have tried to untangle some of the ACES 1.X Output Transform. I was actually pleased with the result and shared it as an OCIO Config on my GitHub. Feel free to give it a try !

Conclusion

On paper, the idea of ACES is interesting: a standard for professionals to help them color managing. But in practice, it is an over-complex system that is actually not really recommended nor even used by color professionals (except for exchanging files).

Several aspects have been investigated for ACES 2.0 to make a more robust and reliable system. For instance, the lack of predictability between the SDR and HDR Output Transforms from ACES 1.X has been improved.

In June 2025, I have written a full study of ACES 2.0 in this article about Picture Formations. You may want to check it out for an updated analysis of the latest ACES major release. Thanks for reading !