Which nuke node did you use to tweak the saturation ? Could you share the luminance weight of the node ? And the working space (I suspect ACEScg but it is always better to double-check) ?
I often tell my colleagues that saturation in a color management workflow is a challenge.
I took the Fairy bottle image with Sigma fp, shooting raw. Same sensor is also in Panasonic S1H. The 3x3 matrix is Sigma’s own. I can very well see this being an “IDT” issue with this particular image. Just for kicks I also created a version using Adobe’s 3x3 matrix for this camera
Thanks @Chris, the tests are using the Nuke saturation node with the luminance math set to the default Rec.709. Color management is set to Nuke (i.e. not OCIO) so the working space is linear Rec.709. Aware of the issue you are describing, I also tried this using Jed’s weighted saturation node testing all the luminance weights, and also changing to Nuke’s working space to ACEScg and testing those weights again. All combinations gave the same cyan results in zCAM with raised saturation.
Cool. Thanks for double-checking ! I think this confirms what Alex Fry has experienced in Resolve ? That grading under ZCAM in Resolve felt a bit “weird” ?
Following the very interesting meeting#41 and the comments about the Fairy’s green colour, I can confirm that “Fairy” is really common here in Spain and that the color we are used to see is the one displayed with OpenDRT and ACES in @priikone tests.
Edit : I could not resist the urge to take a few pics with my old phone of a Fairy bottle. What I really like about this simple example is that most of us know how a green Fairy looks like (a bit like the red Coke example). Arguably, we could say the same thing of blue skies even if it is a more complex (atmospheric) phenomenon. Let’s see if we can get to the bottom of this…
Essentially, Fairy and bright blue skies (because those do turn cyan too) give us extra data points that need to come out the correct colour no matter whether the target gamut is sRGB, P3 or Rec.2020 and whether the target display EOTF is gamma 2.2 (maybe with piecewise sRGB encoding but let’s not get into that argument again ), gamma 2.4 or ST.2084. OpenDRT gets Fairy right with sRGB/Rec.709 target gamut. Blue skies are wrong when targeting sRGB/Rec.709 will all DRTs except JzDt but let’s not bring an extra contender for ACES 2. For wider gamuts, OpenDRT seems to have the hue skew on Fairy and it definitely has it on blue skies too. I’m not sure about ZCAM in wider gamuts though.
Same here. I’m used to see Fairy as green green, not cyan green.
And regarding blue in ZCAM DRT:
I tried to use ACES2 ZCAM DRT Candidate rev4 rec709 with some footage that was shot by me on BMD URSA 4.6k Mini and almost completely lit by strong blue light. ZCAM DRT not even close to what I saw on set. It was a pure blue color on set. And ZCAM DRT made it cyan. RGC helped a little but still way too far from what was on set.
I hope I’ll be able to upload examples and EXRs in ACES2065-1 as well as original CinemaDNG RAW files tomorrow.
The difference though is enough to make the green appear as expected with the Adobe matrix. So OpenDRT and ACES are perhaps more forgiving to IDTs that aren’t exactly perfect, while hue preserving DRT is more unforgiving, and if IDT gets it wrong, it’ll be wrong. But IDTs using only 3x3 matrix are never perfect.
Yeah, this is why it would be great if someone could point a spectroradiometer at some Fairy so we had a ground truth to compare to.
[Edit: I’ve just realised Fairy is availible in Australia, maybe that person could be me]
Most IDTs seem to be heavily optimised for putting normalish reflective values in sensible positions, at the expense of the more distant extremes. We see the results of this all the time with cameras landing extreme colours completely outside the spectral locus in imaginary space.
Has clipping out of gamut colours (and the resulting skews) simply been masking issues with our underlying data up until now?
Jumping back to the CG faces that @ChrisBrejon posted.
As noted above, if the artists slams the slider into the “maximum green” position in ACEScg, we get a very cyan looking green on output. This clearly fights against user expectations.
If we add in Red, to find a position in ACEScg that lines up with the hue angle of Rec709’s green primary, we can hit maximum green, it’s just not in a super intuitive position. And not in the exact same position we would need to hit maximum P3 green.
As discussed above, it’s a bit imposible to talk about what ACEScg max green actually looks like, as it sits off in imaginary space. But Rec2020 green? same deal.
My half considered intuition has always been that where the locus hooks around at around 517nm would feel like the area of “maximum greenness”. But that’s been a pretty half baked intuition. And I’ve never seen a pure Rec2020 primary in reality either, and have no sense what hue it really feels like.
Interesting… So this YouTube video of a dude playing with lasers in his bathroom seems to suggest a Rec2020 Green is a bit bluer than Rec709 green (assuming you projected them both out to the edge.
He has 520nm laser (roughly the top of the spectral locus), and a 532nm laser (which coincides with the Rec2020 Green primary), and describes the 532nm ones as being significantly greener to the eye than the 520nm one (which is also backed up by the footage)
Rec709 green isn’t defined in terms of wavelength, but I’ve seen in tossed around that it coincides roughly with 555nm (assuming you projected out along the same hue line, might be a @Thomas_Mansencal question). So it does seem to make some sense that 532nm lands you in a bluer/cyaner position than 555nm.
The real question is though : does the problem lies with the IDT or with the DRT? The compression I saw in the Adobe 3x3 matrix took all colours in P3 gamut and brought them closer to Rec.709 gamut so less work is needed w.r.t. hue mapping. Considering mapping other gamuts into Rec.709 gamut, I was observing the shape of it in CIExy space (maybe I should have looked at CIEuv space too) and the angles created by the three primaries are very different than the ones created by the primaries of the other colour gamuts. Maybe we could try defining a modified Rec.709 (and slightly wider) gamut in order to align hues more properly. Just a thought.
The aligning of hue angles is discussed in Bt.2407 paper for improved gamut mapping between Rec.2020 and Rec.709. In that recommendation, the reason why it’s done is not for hitting maximum value in the smaller gamut but preserving expected hue. And I’m giving myself an idea : make a small program that goes from 0 to 1000 nits of each primary in PQ and shoot a raw video of it. Unfortunately the best I have is MotionCam which is a hack to allow Samsung phones to capture raw video but it will be better than nothing.
One thing to note about the studio shoot with Alexa is that it was lit with 3200K (I assume studio tungsten) while I shot in sun light. I just tested with real tungsten of ~3400K and with camera set to same WB the chromaticities come out even more cyan for the Fairy bottle.
It was shot on URSA Mini 4.6k and Carl Zeiss CP2 Lenses. Lit by Aputure White LED with cheap blue gel from ebay. There is also cheap led strip in some shots.
For converting into ACES2065-1 I tried all the possible combinations of Camera Raw color space settings, ACES Transform IDT, Color Space Transform, ACES color science in project settings and so on. EVERY combination gave me different result. Different matrices every time and clipping half of the time. So I ended up with (in my opinion) the most correct way of converting these Cinema DNG files into ACES2065-1: I set bmd film 4.6k log in Camera Raw tab and then converted it into AP0 Linear using Color Space Transform OFX, which uses the same primaries for bmdfilm 4.6K that are displayed in chromaticity analyzer in Resolve. I used CAT02 adaptation for white point. The rest settings in Raw were set to: Temperature 6500K, Tint 0, ISO 800 (Native), Sharpness 0.
Then I re-imported AP0 Linear EXRs into Resolve, set color science to ACES 1.3 and used Candidates Rev004 DRTs as Output Transform in project settings. RGC was turned on all the time, because ZCAM DRT looks even more cyan without it.
I’ve also added a shot with Macbeth color chart (after 2014) just in case. It was white balanced in Raw by the third patch from the right side.
Original color on set was strong blue light like it looks with OpenDRT or ACES 1.x modified DRT.
So for me ZCAM DRT is not even close to be accurate with blue colors. But it doesn’t kill reddish fog like OpenDRT does (which I noticed on the filmed footage, not only the footage from game that @jmgilbert showed at one of the meetings).
This is really useful data, and great that you’ve gone into detail as to how the pixel were generated.
My main thought look at this frame is what do we think should be happening here?
The data for the blue smoke is clusted in a position that’s not on, or line line with the 709 blue primary, and sits on a hue line that intersects the gamut boundary at a position a fair way along the border towards green.
Just formulating this out loud here, trying to piece this together in my brain… So if what was seen with eyes on set is blue, but what is in the raw file is cyan. However as far as “what we expect to happen” I think we expect to see on screen what we saw on set, and see that on every screen. As Thomas put it:
So with that in mind, we are trying to figure out what’s going astray in zCAM from scene to screen. I know folks were wondering of it might be in the IDT. Does the data from Anton help to isolate if that’s the culprit?
Just trying to follow along. This is a fascinating ride!
Yeah, I’m still trying to get it my head around it too.
The goal is defintely to have a system where if it looks blue on set, it looks blue on screen. The question at the moment is “is the shift coming from the DRT, or the camera/IDT?”
We think the DRT is doing what it should be doing, but we have green Fairy dish soap, and extreme blues that are coming out in ways that read as wrong to lots of people. So is the underlying data wrong in a way that’s simply been masked by hard gamut clamping in the past? Hard to know without hard measurments.
It would be great if we could measure the gels you’ve used with a spectro, to give us some hard data about what colour the light in that scene actually is. (easier said than done I know)
Same goes for the LED strip you used. Do you have any information on them? Sometimes spec sheets for LEDs have spectral distribution data included.
), gamma 2.4 or ST.2084. OpenDRT gets Fairy right with sRGB/Rec.709 target gamut. Blue skies are wrong when targeting sRGB/Rec.709 will all DRTs except JzDt but let’s not bring an extra contender for ACES 2. For wider gamuts, OpenDRT seems to have the hue skew on Fairy and it definitely has it on blue skies too. I’m not sure about ZCAM in wider gamuts though.
