Clarification about ACEScg vs ACES2065-1

Hi guys,

I am trying to make my company to adopt ACES, we have already made the switch on some extend but there is still blurred area that I didn’t get.
We are producing full CG film, occasionally integrated with live footage. We are rendering and comping in ACEScg. In various documents found here it says our delivery should be in ACES2065-1 color space.

My question would be quite simple. Why ? What is the benefits to store deliveries ACES2065-1 rather ACEScg ? ( We are using EXRs as a container )



As far as I understand it, it’s just to keep a standard.
If many years from now you need to view that files again, you just need to know that it’s ACES.
Not “which” ACES.
Although I really wonder if that will be the case if RRT and ODTs are changing with versions.


We are using ACEScg when rendering,because it is the default setting and not find a way how to rendering out as ACES2065-1 in Arnold , but using ACES2065-1 when write out exr from Nuke to Resolve

@Baiking: Generally, you should avoid rendering with ACES2065-1 because it is far from optimal for computer graphics rendering, some RGB colourspaces are performing better than others and ACEScg (AP-1) is greater than ACES2065-1 (AP-0) here. Some reading:



1 Like

Hi Thomas thanks for clarify

Hello guys,

sorry to bother you. But I am confused on this topic.

1- Does the option “write ACES compliant EXR” have anything to do with Primaries ?


I suspect it is only changing the metadata… Could anyone confirm ?

2- What is the point in rendering and compositing in ACEScg and then deliver to DI an ACES2065-1(AP0) exr ?

Thanks for your answer,


On 1) ACES-compliant EXR does have to do with AP0 primaries, but also includes metadata.

On 2) 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 (and archive and interchange). When working completely within your own facility without sharing of files, ACEScg is sometime 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.

Thanks Jim. That’s much appreciated. It really helps us clarify the topic.

That is correct.

The colorspace drop-down in the write node still needs to be set to ACES - ACES2065-1 (and the rest of the OCIO pipeline correctly set up) or the image data being written must be converted to ACES2065-1 in some other way. Checking the ACES compliant box will not change the image data to ACES2065-1, it will simply flag it as being that, even if in fact it is not.

1 Like

Finally we got it.

Thank you. That information was really helpful !