Hello everyone,
if anyone is interested I have created this albedo chart based on the answer from @Thomas_Mansencal and the chart from Sebastien Lagarde on his blog. I have also merged them with the macbeth color checker.
Luminosity values are linear and thumbnails are displayed with the ODT Rec.709 (ACES).
I hope this is helpful,
Chris
Hi everyone,
I have done a version of the albedo chart in sRGB. So that you can load as Utility - sRGB - texture.
Luminance (and not luminosity) values are linear.
Chris,
I believe that setting the color picker to the inverse of the view transform is undesirable because it can result in values above 1 which breaks PBR. I would instead set it to ACEScg i.e. to linear. For Maya I just commented out the color_picking roll in our ACES config and use the Maya “Rendering Space”. For Mari I also use the Mari color picker in raw, rather than the one in OCIO. For Substance I need to pick the color viewing in Base Color mode rather than in Material mode (with the ACES LUT applied) as the colors picked in Material view gives wrong results. Hope that helps.
Thanks Derek! I found it very interesting that you modified the OCIO config to set your own color picking role (or color space). I’ll give it a try! Thanks
@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 :
https://www.colour-science.org/posts/about-rendering-engines-colourspaces-agnosticism/
I have summed it all up on my website:
Hope that helps,
Chris
Oh and I forgot this post which was for me a big revelation. Check Thomas’ answer, it is enlightening.
Thanks !
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 (https://www.dropbox.com/sh/9xcfbespknayuft/AAA04zUZyBYeHRHLaFry2XfDa/ACES/SonyF35.StillLife.exr?dl=0) 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!
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.
Cheers,
Thomas
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 
Hello Mei, well that’s not a newbie question. 
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,
Chris
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. 
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?
Our guess is that the ODT actually struggles to bring back extreme values (like imaginary ACEScg primaries) into the P3 gamut… Still investigating. Thanks !
