ZCAM for Nuke

alexfry · December 20, 2021, 8:08am

I’ve been trying to make some plots to better undertsand some of the current version’s quirks, especially at the top end.

This first one shows an input ramp originally defined in JMh, with the M value ramping over time:
ZCAMishDRT06_Rec709_JMh_rampingM_v003

This second one has constant 0 → 100 M lines, but with J ramping over time:
ZCAMishDRT06_Rec709_JMh_rampingJ_v001

Whilst the last one takes an nuke ColorWheel node with sRGB primaries, and ramps it from -5 to +5 stops:
ZCAMishDRT06_Rec709_rampingWheel_v001

I do wonder if the funny hammerhead shape that forms as it approaches the top might have something to do with exagerated yellows we’re seeing?

alexfry · December 21, 2021, 11:56pm

So I’ve given up on Youtube encoding the HDR version of the ZCAMishDRTv06 vs OpenDRT & ACES 1.2 video I posted above. I’ve put the h265 encoded HDR version up here if anyone wants to take a look before the next meeting.

I figure an iCloud drive link should at least be viewable for iPhone and iPad users without jumping through too many hoops.

alexfry · December 22, 2021, 4:45am

I’ve been working on a new visualisation to try and show JMh in 3D.

Left : Radial h, M distance from acromatic
Right: Mh collapsed, J in y axis
The lines represent the edges of the sRGB display cube when transformed into JMh (Some interesting shapes in there…):

This next one shows an sRGB colour wheel projected into JMh (quantized to show 5 degree lines in HLS):

And this next one adds ZCAMishDRT v0.6 into the chain. This specific frame is exposed 1.4 Stops up, which clearly shows the unnattractive Yellows. Cyan also seems to be boosted, whilst Blue appears dark:

And with the -5 to +5 sweep:

ZCAMishDRT06_Rec709_rampingWheel_JMhview_v001

@matthias.scharfenber has been working on a completely inderpendent implentation to mine, which now has an explicit highlight desat (which is helping the Yellow issue). The same ramp through it can be seen here:

DRT_ZCAM_IzMh_v03_Blink_Rec709_sRGBWheel_JMhview_v001

Derek · December 22, 2021, 7:38am

Ooooh! That looks great!
Here’s some SDR images showing that

priikone · December 22, 2021, 10:07am

@matthias.scharfenber I think the SSTS is a bit off in v03 as well. I couldn’t get them match no matter what (SSTS) parameters I changed. Notice also that the ramp has color now, so something happened with the CAT. Maybe I’m doing something wrong… (the first curve is DRT ZCAM v03 with default settings and sRGB, second one is ACES 1.2 sRGB).

nick · December 22, 2021, 5:55pm

Bear in mind that SSTS set to sRGB output will not match ACES 1.2. The SDR Output Transforms in ACES 1.2 do not use the SSTS.

priikone · December 22, 2021, 6:33pm

I’m using Jed’s nuke node for ACES. That plot was with the SegmentedSpline_c9 but I can’t get it match with SSTS either. It’s close to the “low” contrast SSTS preset in the node.

matthias.scharfenber · December 22, 2021, 8:51pm

Hi @priikone.

Thank you for flagging this.
I’ve had a look and I think I found the causes for the differences:

The first one was an error on my part. I must have clicked in the wrong place at some point and inadvertently set the “mix” knob of the “Multiply1” node to 0.74 instead of 1.0.
The bug has been corrected in v04 of the repo.

I’ve also noticed that the horizontal terms in the ZCAM X’Y’Z’ to RGB matrix do not add up to 1.0.
(I think these are some kind of cone fundamentals since in the 2017 Jzazbz paper the same matrix is used for X’Y’Z’ to LMS). And since G is used as the basis for Iz this applies a gain of 0.97224 which I was not correcting for. I’m not sure if it’s strictly needed, but I’m now applying a correction for this in v04.

Any remaining differences are due to the white point conversion if the input white is not D65 as well as my experimental and very handwavy attempt at adding a highlight de-sat - which still needs work as it’s causing some clipping.

And yes, as @nick already mentioned, the SDR output transforms of ACES 1.2 (Rec.709, sRGB, etc.) are not using the SSTS and instead still use the classic RRT tone scales.

Still more work to be done here, for sure.

Thanks again for checking it out.

github.com

Tristimulus/aces_vwg_output_transform/blob/master/DRT_ZCAM_IzMh_v04_Blink.nk

set cut_paste_input [stack 0]
version 12.0 v8
push $cut_paste_input
Group {
 name DRT_ZCAM_IzMh_v04_Blink1
 label "\[value colorspace_out]/\[value illuminant_out]/\[value primary_out]\n\[value ssts_luminance.2]Cd/sqm"
 note_font "Bitstream Vera Sans"
 selected true
 xpos 1493
 ypos -25
 addUserKnob {20 User}
 addUserKnob {26 div_input l Input}
 addUserKnob {41 colorspace_in l colorspace T Colorspace1.colorspace_in}
 addUserKnob {41 illuminant_in l "" -STARTLINE T Colorspace1.illuminant_in}
 addUserKnob {41 primary_in l "" -STARTLINE T Colorspace1.primary_in}
 addUserKnob {26 div_ssts l SSTS}
 addUserKnob {78 ssts_luminance l luminance n 3}
 ssts_luminance {0.0001 10 100}
 addUserKnob {26 ssts_label l "" -STARTLINE T "  min / mid / peak"}
 addUserKnob {26 div_gamutmap l "Gamut Mapping"}

This file has been truncated. show original

Derek · December 22, 2021, 10:53pm

Here are some further examples comparing the highlight desaturation.

matthias.scharfenber · December 23, 2021, 4:33am

Hi Everyone.

Here is another update for my Nuke implementation of a ZCAM IzMh DRT:

v06 now features an inverse transform option. This required a few very minor changes to how much the gamut is compressed, especially near peak white to ensure reasonable results when inverting.

It now also uses bilinear interpolation for the gamut boundary lookup to reduce banding along gradients.

I’m looking forward to your comments and suggestions.

And Happy Holidays!!

github.com

Tristimulus/aces_vwg_output_transform/blob/master/DRT_ZCAM_IzMh_v06_Blink.nk

set cut_paste_input [stack 0]
version 12.0 v8
push $cut_paste_input
Group {
 name DRT_ZCAM_IzMh_v06_Blink1
 label "\[value colorspace_out]/\[value illuminant_out]/\[value primary_out]\n\[value ssts_luminance.2]Cd/sqm"
 note_font "Bitstream Vera Sans"
 selected true
 xpos -211
 ypos 81
 addUserKnob {20 User}
 addUserKnob {26 div_input l Input}
 addUserKnob {41 colorspace_in l colorspace T Colorspace1.colorspace_in}
 addUserKnob {41 illuminant_in l "" -STARTLINE T Colorspace1.illuminant_in}
 addUserKnob {41 primary_in l "" -STARTLINE T Colorspace1.primary_in}
 addUserKnob {26 div_ssts l SSTS}
 addUserKnob {78 ssts_luminance l luminance n 3}
 ssts_luminance {0.0001 10 100}
 addUserKnob {26 ssts_label l "" -STARTLINE T "  min / mid / peak"}
 addUserKnob {26 div_gamutmap l "Gamut Mapping"}

This file has been truncated. show original

Alexander_Forsythe · December 23, 2021, 4:35am

Thank @matthias.scharfenber!!! Awesome work

matthias.scharfenber · December 23, 2021, 8:10pm

Hi.

And here is one more update before the holidays:

I’ve simplified the needlessly complex highlight-desat section by removing the highlight boost which did not really contribute anything useful.

github.com

Tristimulus/aces_vwg_output_transform/blob/master/DRT_ZCAM_IzMh_v07_Blink.nk

set cut_paste_input [stack 0]
version 12.0 v8
push $cut_paste_input
Group {
 name DRT_ZCAM_IzMh_v07_Blink1
 label "\[value colorspace_out]/\[value illuminant_out]/\[value primary_out]\n\[value ssts_luminance.2]Cd/sqm"
 note_font "Bitstream Vera Sans"
 selected true
 xpos -371
 ypos -74
 addUserKnob {20 User}
 addUserKnob {26 div_input l Input}
 addUserKnob {41 colorspace_in l colorspace T Colorspace1.colorspace_in}
 addUserKnob {41 illuminant_in l "" -STARTLINE T Colorspace1.illuminant_in}
 addUserKnob {41 primary_in l "" -STARTLINE T Colorspace1.primary_in}
 addUserKnob {26 div_ssts l SSTS}
 addUserKnob {78 ssts_luminance l luminance n 3}
 ssts_luminance {0.0001 10 100}
 addUserKnob {26 ssts_label l "" -STARTLINE T "  min / mid / peak"}
 addUserKnob {26 div_gamutmap l "Gamut Mapping"}

This file has been truncated. show original

priikone · December 24, 2021, 9:58am

The v07 looks great! Here’s some images comparing DRT ZCAM IzMh, OpenDRT and ACES 1.2 all normalized for the sRGB SSTS 100nits contrast curve so that we can see only the color differences.

My observations after looking at bunch of images:

DRT ZCAM and OpenDRT are very close to each other. IMO they agree on hue much closer to each other than to RRT. The biggest difference is in blue and yellow, but that’s already the known issue in ZCAM.
OpenDRT looks great with SSTS.
ZCAM seems to brighten dark reds, and darken bright reds. OpenDRT does the opposite. It darkens already dark reds and (can) brighten already bright reds. I like the ZCAM behavior better.
OpenDRT desaturates the shadows way too much, doesn’t look natural. IMHO, this should be improved.
ZCAM can sometimes over-saturate the shadows (especially red).
OpenDRT and RRT has better saturation in highlights. DRT ZCAM desaturates too quickly and the color isn’t as pleasing (and the reds and oranges can still go a bit pink).

ChrisBrejon · December 30, 2021, 9:40pm

Hello,

I found some time to look at our different prototypes to do some comparison. Apologies in advance for the complete arbitrary/subjective comments I am about to make.

It has been noticed in this thread some weird behaviour about blues. Here are more examples that I thought were worth sharing.

Some sRGB spheres lit by a distant (or directional) light… displayed by OpenDRT v0.0.90b4.

Some sRGB spheres lit by a distant (or directional) light… displayed by JzDT.

Some sRGB spheres lit by a distant (or directional) light… displayed by ZCAMishDRT v0.6.

Do you notice the artefacts on the blue sphere in the first row ? Here is a close-up. From left to right : ZCAMishDRT v0.6, OpenDRT v0.0.90b4 and JzDT.
spheres_comparison_001

I also did some test with some sRGB sweeps using constant in Nuke.

sRGB sweeps from (0,0,1) to (1,0,1) with 0.1 step increment… displayed by OpenDRT v0.0.90b4.

sRGB sweeps from (0,0,1) to (1,0,1) with 0.1 step increment… displayed by JzDT.

sRGB sweeps from (0,0,1) to (1,0,1) with 0.1 step increment… displayed by ZCAMishDRT v0.6.

I thought the first two rows with ZCAMishDRT showed some weird “discrepancies”. I would expect a smoother transition between each row. With ACEScg primaries, this behaviour is exaggerated.

And this leads me to my final observation.

sRGB Light Sabers displayed by ZCAMishDRT v0.6.

ACEScg Light Sabers displayed by ZCAMishDRT v0.6.

Going from sRGB to ACEScg primaries in this render go against my expectations. I would expect a more saturated render and it seems to actually changes hues ? Don’t get me wrong, both images look “good” but I find this behaviour quite unsettling and I am not sure how CG artists would react to that.

To me, ZCAMishDRT is not neutral, it has a look embedded in it, which does not look half bad but sets us on a different path than “Neutral DRT + LMT to make it look good out-of-the-box”. The contrast is very pronounced compared to our other prototypes which makes it look quite “filmic” out-of-the-box.

Happy holidays everyone,

Chris

priikone · December 31, 2021, 9:24am

Here’s two of those images with contrast matched (think of it as the LMT for OpenDRT). To quote @gray.

It is an essential part of the new DRT workflow to use an LMT to create a Look which you then want to be retained by the DRT.

I actually appreciate that the ZCAM based DRTs use SSTS because it’s more realistic contrast to look at (even if it is perhaps too high) than the ultra-lowcon of OpenDRT.

The issue with the blue in ZCAM is evident…

I’m actually hopeful that OpenDRT could be improved a little bit more so that perhaps Default LMT isn’t even needed with it. As far as “neutral DRT” goes, I have no idea what that means. If it reproduces colors correctly and has a decent contrast (a bit higher than current OpenDRT), that would be neutral to me. Perhaps if the blue is fixed with ZCAM it could meet this definition of “neutral”.

And here’s @TooDee’s Shell image with DRT ZCAM, OpenDRT and ACES, contrast matched again.

ChrisBrejon · December 31, 2021, 2:53pm

Thanks for sharing your images and thoughts. Maybe I can add a few comments.

I am not sure what “more realistic contrast” means in this context but I do not think to qualify OpenDRT as “ultra-lowcon” is a fair statement.

It is not a question of “needing a LMT or not”. It is a question of architecture in my opinion. I see many benefits to keep LMTs and creative grading in the “Looks” stack. I don’t think a system is superior to another because it does not need a LMT. To me, it is more about having an architecture where each step is clearly defined and is doing what it is supposed to do.

If I look at it from a pure CG standpoint, it is really super powerful to be able to remove any look to go back to some sort of “neutral ground truth”. It is also more flexible and in my opinion allows more creativity.

Maybe it would be worth to define “neutral”. I have thought a bit about it and to me “neutral” would mean “what the DP and director saw on set”. That is a good entry point I think. Without mentioning the hue skews or gamut clipping that would by definition remove the “neutral” aspect I am referring to.

All I can hope at this point is that the TAC allows for more time to keep investigating the ZCAM DRTs. I think they’re quite promising. For instance, to have a “water bucket” approach to fill the display gamut volume is really nice. There has been also a very nice prototype of “tone scale” developed by Jed that is worth comparing against the SSTS. I am sure that ACES 2.0 can be a simpler and more powerful system than ACES 1.X.

Chris

priikone · December 31, 2021, 4:47pm

Okay, agreed, I shall withdraw the superlative ultra.

I can subscribe to that definition. If we can have that, without them hew skews, and the need for Default LMT, then that would be great. LMTs are already part of the architecture and I hope in ACES 2.0 they will become even more useful (as the DRT wouldn’t have strong look). Whether ACES as a system needs Default LMT, that is another matter. It remains to be seen. Maybe the DRT should have more knobs instead?

Happy new year!

Derek · January 1, 2022, 7:26am

The green in the light sabers render is also looking kind of turquoise in the zCam. Seems like OpenDRT is more faithful to the original colors. I do find the behavior of the highlight desat in zCAM IzMh to be more naturalistic. My dream team would be the colors of OpenDRT + the highlight desat of zCAM IzMh.

Happy new year!

priikone · January 3, 2022, 5:51pm

This is 24 hues from 0-14 stops through the sRGB DRT ZCAM, OpenDRT and ACES, and visualized in 3D from the display linear values. With ZCAM it shows how it fills the cube, and then takes the path towards white. If you look closely you see that the hues don’t actually seem to get to full white, unlike the two others. ACES is all wonky, but it would get a bit better if RGC is applied. With OpenDRT it’s evident how the yellow corner suffers. That ZCAM looks one smooth operator…

DRT ZCAM v07:
drtzcam

OpenDRT v0.0.90b4:
opendrt

ACES 1.2:
aces

Nuke script used to generate these: plot_hue.nk (348.0 KB)

Troy_James_Sobotka · January 3, 2022, 6:59pm

What do these plots mean?