After the discussions in the meeting today, I was curious to see how this looked in P3 vs 709.
There isn’t a great way to get ACESCentral to respect the embeded DisplayP3 ICC profile in this image, so you might need to download it, or reapply within your own environment. (P3 prim, D65, sRGB peicewise EOTF)
Left Column: ZCAM DRT v10
Right Column: OpenDRT 0.94b4
Top Row: 709
Bottom Row: P3
For me, visually I see ZCAM’s P3 version as a more colourful version of it’s 709 rendering, whilst OpenDRTs 709 reads as more yellow than it’s P3 rendering.
Edit - Just to clarify, the entire 4up is P3 encoded, but the top two images are 709 limited. So the whole image is intended to be viewed on a P3 display.
This is backed up by the plots, where ZCAM pushes in on it’s M axis, but to different degrees, whilst clamping folds in from different point, to a different point.
So here’s something unexpected… Lowering the saturation on the “blue blob dude” image viewed under zCAM takes it into magenta before it goes achromatic, and raising saturation takes it into cyan.
I tried this using Chris’ achromatic EXR for red and green, both of which behaved with saturation as expected under zCAM. So this appears to be only affecting blue. These images are with zCAM v11 (sorry the label is wrong), but the same thing happens in v10 too.
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).
), 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.
