After we noticed some heavy negative values in some plates we were comping in Nuke, I decided to take a deeper look at our ACES workflow, and ACES in general.
I hoped it would enlighten me, but I’m coming out of my reading with even more questions than before, and quite a bit of confusion. I am not even sure how to phrase some of the questions I have, so I’ll give a bit of backstory.
I’m coming from a Nuke/OCIO (pre-ACES) background, and feel all good with all the “regular” color-spaces, and going between linear/sRGB/rec709/AlexaLogC using ‘gamma transforms’ (that may not be straight gamma transforms, but do not involve shifting primaries).
Now, on this specific project I am working on, a plate shot on Alexa (LogC - EI800) has a very strong, very blue light. Using the old-school AlexaV3LogC to Linear, no problems, the plate looks quite good.
However, using ACES (via OCIO ACES 1.0.1) [Arri V3 LogC (EI800) >> ACEScg] the very strong blue highlights are causing the red and green pixels values to go into negative values.
Example: A pixel on the (LogC) plate with a value of (0.650, 0.752, 0.954) becomes (-0.294, -1.803, 37.875)
I am assuming this is due to the the shifting of the primaries. Is that correct? Is that supposed to happen? I found the following graphic to be helpful.
Now in terms of Primaries, it was my understanding that sRGB, rec709 and Linear all used the same RGB primaries, and a white point of D65. (Is that correct?)
I was also under the assumption that ACEScg and Linear were equivalent? (CG renders in Linear and ACEScg are 100% identical).
I have done a few tests in Nuke to try to understand better what is happening in all these color transforms,
(Left: Original Curves, Right: Color Transformed)
All of them use a Greyscale gradient as the base, which I grade different ways before running through the OCIOColorSpace node.
Test1: ACEScg to ACES - rec709
So far so good, things behave like I was expecting them to behave, similar to non-ACES
Test2: ACEScg to ACES - rec709
Gaining up my blue channel by 2 (R & G untouched) we start noticing some shift between red and green. Is that due to the shifting primaries?
Test3: ACEScg to ACES - rec709
Now I lift my blue channel by 0.7.
We still see red and green shifting from each other, plus red acting funky. The white point doesn’t seem to get affected though.
Test4: ARRI - V3 LogC (EI800) - Wide Gamut to ACEScg
(these are a bit confusing, as I’m giving a linear gradient input to a colorspace node that expects a logC input)
I’m getting negative and huge values, fair enough, as I feed it values from 0 to 1 that would be really extreme values to get in LogC.
Test5: ARRI - V3 LogC (EI800) - Wide Gamut to ACEScg
Now I gain down my Red and Green to 0.75. That green curve goes way into negative. That is where my issue is coming from. Now one could argue that my original curve doesn’t respect LogC values, so let’s do one more test.
Test6: ARRI - V3 LogC (EI800) - Wide Gamut to ACEScg
This gradient linear gradient is now mapped to the actual darkest and brighest pixels from my Alexa plate, meaning that in theory it’s entirely within the LogC Wide Gamut Once again Green and Red are dipping down.
Test7: AlexaLogCv3 [non ACES] to Linear [non ACES] to ACEScg (via Lin AP1)
This is more what I am used to, and gives me a result I can easily use,
Can anyone tell me if this is all expected behavior? If so how to deal with it? These are green-screen shots and need to be keyed, which we can’t do properly with these areas of negative values.
My workaround is to ignore ACES, key and comp in linear, then put back to LogC and finally apply the LogC to ACEScg lut to get back in the pipeline (internally using ACEScg for renders).