ACEScg for Animation feature and further questions

Tags: #<Tag:0x00007f117d6d4350> #<Tag:0x00007f117d6d4288> #<Tag:0x00007f117d6d41c0> #<Tag:0x00007f117d6d40d0>

@ChrisBrejon “Here’s the biggest point I have learned so far: ‘linear is gamut-dependent.’ Working in ACEScg (or Rec. 2020) will give better results for your render. Thanks Thomas Mansencal for your explanation.”

Can you link to the post where Thomas discusses this? Interested to learn, thanks!

Yes, of course !

Here are the posts :

I have summed it all up on my website:

Hope that helps,



Oh and I forgot this post which was for me a big revelation. Check Thomas’ answer, it is enlightening.

Thanks !

1 Like

Just wanted to also chime in and thank Christophe for that informative guide he has written. After reading his guide and other folks’ posts here, I feel much more comfortable using ACES. Now, trying to put all this knowledge together, I have a question combining ACES with OCIO. Is there any downside with using ACEScg with the smaller ap1 primaries as the reference space in OCIO? Normally, it probably wouldn’t be a problem if renders are being render out in ACEScg as well. However, in a vfx environment, there could be plates coming in in ACES2065 colourspace with ap0 primaries. Depending on the camera that shot the plate, but I supposed it’s generally unlikely that the plate contains colour outside of the ap1 primaries even if the file is denoted in ACES2065 right? Would there be colour degradation by using ap1 as the reference colourspace primaries?

I was doing a test on this where I got the Sony F35 Still Life image from ACES’ GitHub ( which I believe is in ACES2065 colourspace. However, using ACEScg as the reference space to convert between ACES2065 to another colourspace and then back did not seem to cause any colour degradation. Do you guys have any thoughts about that here? Thanks for answering in advance!

1 Like

Hi Meimchu,

That surely would happen, and while it is unlikely you get colours outside AP1, this might happen too, e.g. hyper saturated light emiters such as LED lights or lasers would venture outside AP1. I don’t think it is a practical problem though because in the worst case scenario for theatrical exhibition you are bound by P3 gamut anyway and UHD TV is BT.2020, both are smaller than AP1.



Thank you for your answer! On top of that, I don’t see that we actually have a lin to log shaper that is compatible with ACES, do we? ACEScc and ACEScct both uses ap1 as well. So is using ap0 as reference space in OCIO even possible? One can write the OCIO config file to say ACES2065 is reference but without the shaper, that really isn’t happening, is it?

Got another newbie colour question for you guys! One thing that is confusing to me working in Nuke is that I have the working space set to ACEScg. All of my renders are coming in as ACEScg as well. I output into ACES2065 (AP0) colourspace. Please feel free to correct me if I’m wrong, but here’s my simplified understanding of all this conversion process. It’s remapping the ACEScg pixel values to its equivalence in ACES2065. Let’s say a pixel is RGB (1, 0, 0) in ACEScg, then it becomes ACES’s RGB (0.8, 0, 0) (Just randomly putting a number here to illustrate that ACES is bigger than ACEScg gamuts). So if I were to bring in the ACES2065 image into Nuke and read it in as ACEScg, it will be wrong because it’ll be mapping ACES2065’s (1, 0, 0) directly to ACEScg’s (1, 0, 0) instead of remapping it to its equivalence. With that in mind, I can understand going from a wider gamut of ACES2065 to smaller gamut ACEScg could lead to negative pixel value because of values outside of ACEScg’s gamuts. So if I read in the ACES2065 image as ACEScg, then I can potentially see negative pixel values. However, is there any possibility that ACEScg values become negative values in the wider ACES2065? Furthermore, if I were to add a OCIO Colorspace node after reading the ACES2065 image in (as ACES2065) and convert it from ACES2065 to ACEScg, why would it produce different colour look in the viewer, considering the sources going into the image write are all ACEScg anyways. It’s just the Write node writing to ACES2065, but considering the source of the image should not exceed ACEScg gamuts, why would using OCIO Colorspace node change the look? I would expect no change.

Once again, I appreciate any answers that you guys can provide my very newbie questions! Hopefully these questions make sense :slight_smile:

Hello Mei, well that’s not a newbie question. :wink:

That’s true.

Also true except for the value (1, 0, 0) which stays the same in ACEScg and ACES2065-1.

Yes that would be wrong to do so. An ACES2065-1 should be read as ACES2065-1.

That would be very surprising in my opinion.

You actually don’t need an OCIOColorspace node to convert. If your working space is set to ACEScg, just by importing your footage with the right IDT converts it automatically.
Hope that helps,

In fact (1, 0, 0) in ACEScg becomes (0.695452, 0.044795, -0.005526) in ACES2065-1, so negative values are possible. This is because the ACEScg red primary is (just) outside the ACES2065-1 gamut.

Thanks Nick! I did not think of the red primary indeed. Thanks for your help!

Hey Christophe, thanks for responding!

You actually don’t need an OCIOColorspace node to convert. If your working space is set to ACEScg, just by importing your footage with the right IDT converts it automatically.

That is true but I am doing this to “validate” what I think makes sense. So I’m purposely reading in the ACES2065 image in ACEScg. Then using a OCIO Colorspace node for ACES2065 in and ACEScg out. That should produce the exact same result as reading in the image as ACEScg.

Wow I think that’s exactly what I am seeing after outputting an ACEScg image into ACES2065. It’s a reddish colour that ended up with a negative blue value after conversion from ACEScg to ACES. Images of ACEScg and ACES2065’s gamuts on the internet may not always be the most accurate, so I thought AP0 encompasses all of AP1. Kind of like this… it’s super subtle that there’s a little bit of red AP1 sticking out of AP0!

Curious, is there a algorithm which I could plug in using RGB values from nuke’s pixel selector (in ACEScg space) and that will output its equivalence in ACES2065 in pixel value?

Hey @Derek , did you have any issue with your color picker set to ACEScg? Have you ever tried to put 1/0/0 in a color picker set to ACEScg? It is giving us some banding issue on our monitor. Apparently due the ODT not scaling properly the gamut. I was wondering if Utility - Linear - Rec.2020 would a better fit for color picking maybe? Thanks, Chris

Can you maybe post an image showing the banding with pure red? I have not encountered that.

rendering space is ACEScg
display space is P3D65 (it is a screenshot)
redcolor is 1/0/0 in Rec.2020

I’ll keep my investigations going. Thanks for your help. :wink:

Hmm, maybe I’m not understanding you correctly, but I think the color should not exceed 1/0/0 in raw. If it is 1/0/0 in Rec.2020 then I believe that would mean its above 1 in raw which would make it emissive.

Hum interesting… But what is raw? I had understood that there is no such thing as raw. Or should I ask: what color space is raw? :wink:
Our guess is that the ODT actually struggles to bring back extreme values (like imaginary ACEScg primaries) into the P3 gamut… Still investigating. Thanks !

@ChrisBrejon by raw I meant ACEScg (that is, the working/rendering space). You had said Rec.2020 which is of course close to ACEScg, but it struck me as odd. So I thought it may be something to check.

Then again, ACES does seem to have a hard time with saturated colors. We know it has a hard time with blue and yellow. So maybe you’ve discovered an issue with red…

ACES reminds me of driving a race car, where the slightest turn of the steering wheel can send you crashing into a wall. ACES likewise seems really sensitive. I think as it grows into more widespread use it will need to develop seat belts and bumpers so it’s not so easy to make errors.

One of those error prone places for me has been in picking colors. That’s why I set the color picking role in our OCIO config to ACEScg to prevent that. I really think they should change that in the official OCIO config. Having it set as Rec.709 makes it almost inevitable that users will pick colors with values above 1. Because the display transform applies a tone map curve to the output image, a value of 1 in sRGB or Rec.709 space will remap to a value of around 10 in ACEScg linear space. In other words, if you pick a color like pure red for your diffuse texture in Maya then the RGB values of <0,0,1> will actually give you pixel values in your render of <0,0,10> making your shaders light emitting which breaks the PBR rule of energy conservation which states that an object cannot reflect back more light that what is shining on it.

Check the pixel value of the red in your rendered image and see what it is. I bet it’s really high (like above 10) which is causing it to clip.

Thanks for your answer. :wink:

yes it seems to be the case.

I agree on this as well.

True. I think it is like this by default in the config so people pick the color they want to see.

I have done this test in Nuke. Working space is ACEScg. 1/1/1 values give 16.29/16.29/16.29 with the reversed ODT.

Another test here. Working space is ACEScg. 1/0/0 value give 1.24/0.10/0.01 with the reversed ODT.

It is 1/0/0. I have been not clear enough. The test I have provided is using a color picking role in Rec.2020. But the issue is the same with a color picking role set to ACEScg. There is no conversion involved here.

I do have issues of banding with a Red 1/0/0 set in Raw (ACEScg in this case). And since you use a color picking role set to ACEScg as well, I was wondering if you had faced the same issue.

Hope I have better explained this time. I am really not talking about a color picking conversion that would give values above 1. I am really talking about an ACEScg primary not displaying correctly in P3 once it is lit. No light emission here.

Thanks for your help!

Thanks for clarifying. I don’t have a monitor in P3 so I’m not able to test that. Hopefully someone else can jump in.

Thanks for your help. i am pretty sure we would have the same issue in Rec.709 or sRGB (ACES). Thanks !