ZCAM for Nuke

[Thomas_Mansencal]

@Troy_James_Sobotka

I believe the Asano model used LMS plots for this reason? Using the CIE xy tristimulus plot, as a stimulus specification, is gravely misleading, and leads to completely incoherent, yet seductively logical, questions and problematic conclusions.

The Asano model provides both RGB and XYZ CMFs and someone reading his thesis will find out that he has no problem comparing the observers in CIE Lab space for example. I would suggest asking Mark and Asano why you think they are both wrong doing that!

Now, assuming that it is possible to compare observers, only a few percents increase in blue sensitivity are required to reach the AP1 blue primary for the Standard Observer. Somewhere there is likely an observer that would see it:

@Troy_James_Sobotka

“Not significant” implies that your measurement has led to a conclusion based on… something?

It is not based on “nothing/something”, but simple tests, one can encode an image with BT.2020 and another with AP1 and assess if he can make a visual difference. Here is a random blindest example:

I honestly would not be able to say which one is what! They might very well be the same images, who knows?

We can also compute Delta E on the colour checker, and directly measure the colour difference between the patches encoded in both RGB colourspaces:

[('dark skin', 0.0011419524692043341),
('light skin', 0.0033962236416911372),
('blue sky', 0.0036090355653960724),
('foliage', 0.0021312144064404947),
('blue flower', 0.0050948318536764899),
('bluish green', 0.0027797102041388065),
('orange', 0.0072347586036700063),
('purplish blue', 0.0071736115979037377),
('moderate red', 0.0033920583758162036),
('purple', 0.0021555866734024091),
('yellow green', 0.010202657482306884),
('orange yellow', 0.010127672244120979),
('blue', 0.0058280109434577397),
('green', 0.0047691284180629741),
('red', 0.0031879290573101839),
('yellow', 0.014413642744676864),
('magenta', 0.0044688435898245539),
('cyan', 0.0051040729312890141),
('white 9.5 (.05 D)', 0.00047139703700771376),
('neutral 8 (.23 D)', 0.00012077587856360507),
('neutral 6.5 (.44 D)', 0.00011996350929703285),
('neutral 5 (.70 D)', 4.1345601686671215e-05),
('neutral 3.5 (1.05 D)', 0.00010587071067308681),
('black 2 (1.5 D)', 4.2559679481020816e-05)]

With that in mind, I don’t think that talking about the AP1 blue primary colour is heretical: The two colourspaces are for practical purposes the same and if the blue laser of BT.2020 is visible and can produce a colour, I will certainly not blame anyone discussing about AP1. Can an admin s/AP1/BT.2020/g so that we can move on…

[priikone (Pekka Riikonen)]

@alexfry

As always, the question comes back to what did that liquid really look like to a human oberserver on the day?

I found some green liquid so I took a picture:

OpenDRT and ACES are closer to what I saw with my eyes. ZCAM DRT is entirely wrong color. Lit 100% with sun light.

The data is within P3.

[alexfry]

Interesting… I wonder what’s going on here then?

[Thomas_Mansencal]

If the colours are not clipped and within target display gamut, it should be easy to produce the ground truth for it, simply encode for your target display, no need for anything else.

ZCAM, vanilla, should produce the same values in output than that in input, i.e. it roundtrips, so I’m assuming that either there is a problem with the current implementation or the changes bolted-in do more than what they should. Might be worth looking at the chromatic adaptation too.

[priikone (Pekka Riikonen)]

The hue shift happens as a result of the gamut compression in the DRT ZCAM IzMh. Disabling that (or reducing the compression to around 1.03 from the default 1.2) makes the green match OpenDRT very closely.

1.2 compression:

1.03 compression:

So really the difference here is just that the 1.2 compression pulls in more stuff into the gamut.

[alexfry]

Yeah, my read on it is that what we’re seeing here in the clamp variations is in fact a “skew”. Both “Perceptual Hue Preserving” or “Chromaticity Angle Preserving” approaches would show similar results to what we see with ZCAM in this situation.

The plot below winds on the compression used by ZCAM DRT (1.0 → 1.2) and OpenDRT (clamp mixed from 0 → 1.0)

[priikone (Pekka Riikonen)]

So then, the hue lines in the model are either not correct at all, or it’s an IDT problem?

[Thomas_Mansencal]

The hue lines are more or less correct as far as prediction goes, if you increase or decrease colourfulness (or chroma), the perceived hue will shift, i.e. Abney Effect. The model could also be over-predicting. The question (which I asked a few posts above and a few meetings ago) is whether it is desirable, i.e. do we want hues to shift as we compress colourfulness? We are not trying to predict the appearance of a colour, which the model does, we are trying to implement a DRT that behaves predictably.

[Alexander_Forsythe (Alex Forsythe)]

This, to me, is a very telling animation.

The ZCam model appears to be doing exactly what we hoped it would from a perspective of not rotating hues (I think, we should confirm numbers in JCh). The OpenDRT model’s behavior is different, but are the visual results more desirable?

Also, it’s worth thinking about how this will translate to other devices. Will be behavior of the ZCam model yield a more consistent results across display devices with different primaries and dynamic ranges vs. the behavior we’re seeing in OpenDRT, regardless which result produces a more desirable result on one particular display?

[jmgilbert (Jean-Michel Gilbert)]

@Derek

Lights by Chris in both sRGB and ACEScg primaries. I can see the cyan in the ACEScg, but not really in the sRGB:

I can see it in the sRGB too. It’s even more obvious in a scene with fake night post-processing applied.

[Troy_James_Sobotka (troy_s)]

@Thomas_Mansencal

Somewhere there is likely an observer that would see it:

False.

@Thomas_Mansencal

It is not based on “nothing/something”, but simple tests, one can encode an image with BT.2020 and another with AP1 and assess if he can make a visual difference. Here is a random blindest example

I see how this works.

A discussion about how to form an image and the relationship to values with no meaning to a standard observer, and what those values mean in terms of relationships, is countered by a formed image.

My goodness. I give up.

[Thomas_Mansencal]

@Troy_James_Sobotka

My goodness. I give up.

Thank you, it is ok to disagree, provided it is done respectfully, it won’t be the first nor the last!

[alexfry]

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.

[Derek]

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.

Here it is with saturation 1.0

Here it is with saturation lowered

and saturation raised

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.

Curiouser and curiouser

[alexfry]

I don’t have any conclusions here. Just trying to make more images to help myself understand whats happening.

Evenly spaced xy grid, clipped to spectral locus, then echoed as the compression/clamping is winding on.

6 axis AP1 saturation ramps, winding on the compression/clamping

[alexfry]

And one that was shown in the meeting, but is probablt worth having here for reference to.

ZCAM’s Hue lines overlayed on Yxy
Cyan = AP1
Red = 709

[Derek]

So, I was noodling around and changed the limiting primaries to AP0 in zCAM and the blue-cyan thing is gone.

I was afraid that this would mean there is no gamut compression, but it appears to be working just fine,

with a possible issue with red where there is not really any roll off from red to white.

Is that an edge case? Often folks have expressed a desire for red light to keep its color rather than going to white which is another word for pink.

So maybe this is great or maybe it fixes one thing and breaks another. I’ll leave it up to you all whether I’ve stumbled onto anything useful here…

[ChrisBrejon (Christophe Brejon)]

@Derek

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.

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.

Chris

[priikone (Pekka Riikonen)]

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

AP0 linear EXR with Sigma matrix
AP0 linear EXR with Adobe matrix

And chromaticities of these two images.

So which is “correct”?

[jmgilbert (Jean-Michel Gilbert)]

From the look of the chromaticity plots, it looks like there’s some compression in the Adobe matrix. Otherwise, they are very similar.