ZCAM for Nuke

[priikone (Pekka Riikonen)]

@nick

It probably makes sense that the dark-to-dim is not baked into the tone scale when using a CAM, since that is a crude attempt at an appearance match, and should probably be left for the CAM to do a better job of.

Right, that’s a good point. Presumably this will then have to be taken into account also in the LUT image generation.

[matthias.scharfenber (Matthias Scharfenberg)]

Hi.

For those of you who are interested in the alternative Nuke implementation of a ZCAM based DRT shown in todays (2021-12-15) meeting you can find my (very much work-in-progress) model here:

Tristimulus/aces_vwg_output_transform/blob/master/DRT_ZCAM_IzMh_v01.nk

[nick (Nick Shaw)]

Great work @matthias.scharfenber!

I know that @Thomas_Mansencal has said that he believes a two step chromatic adaptation should really be used. But in the absence of that, do you think the Bradford matrix check-box should be set on the input Colourspace conversion to CIE XYZ? Or have I missed something, and you have a two step adaptation to D65 constructed as part of the node tree?

EDIT: I see, on further investigation that the input ZCAM conversion uses ACES, rather than D65, as the reference white, so perhaps it is handled here and the Bradford CAT should not be enabled earlier.

[Derek]

I’ve got an HDR monitior (Macbook Pro M1) and have both @alexfry and @matthias.scharfenber flavors of the zCAMish DRT working via the “Enable macOS HDR Color Profile (Display P3) (Beta)” function. Looks amazing!

I’d like to compare this to ACES 1.2 and OpenDRT but am not having much luck with getting either of these to display in HDR.

ACES in HDR

For ACES I’m using the Nuke ACES 1.2 OCIO config with the view transform set to P3-D65 1000 nits (ACES), and it displays in SDR (i.e. it is clamping at 1). If I switch the view transform to Raw it does display in HDR.

OpenDRT

@jedsmith 's OpenDRT v90b4 is just showing pitch black. This is coming from the Display Scale node (i.e. disabling it make the image appear again).

Can some one point me in the right direction?

[jedsmith]

@Derek

OpenDRT v90b4 is just showing pitch black.

Looks like in Nuke 13 and in some scripts, a knob named s in the expression node was not returning the right value. I’ve pushed a fix.

[alexfry]

I’ve put together a clip with a bunch of example footage and still images running through the 3 DRTs.

Left Column: ZCAMishDRT Alpha 0.6
Middle Column: OpenDRT v0/0/90b2
Right Column: ACES 1.2

Top Row: -5 Stops
Middle Row: Standard Exposure
Bottow Row: +5 Stops

Still frames all do a -5 to +5 Exposure sweep over 51 frames.

ZCAMishDRTv06 vs OpenDRT & ACES 1.2

The idea with the -5 and +5 offsets is to give you something to compare when trying to get a sense of “does this image feel like the same image, or are the proportions shuffled around as exposure changes?”

Whilst ZCAMishDRT’s approach to gamut compression helps here, by always preferencing Brightness over Colour intensity, it can lead some images feeling like they desat too fast. The question there is, which matters more? The colour of the light, or the quantity of the light?

Currently, the area that looks the worst to me is ZCAMishDRT’s handling of very bright, but only moderately saturated, areas holding on to too much saturation as they approach the clipping point. This can most clearly be seen on the clips outside the Mercedes Benz museum. Perhaps it’s going to need an explict highlight desat tied to the tonemapping section, rather than the gamut volume compressor alone?

[alexfry]

@Derek

Can some one point me in the right direction?

Hey Derek

I’ve got a modified ACES 1.2 OCIO config here, that supports Nuke’s Display P3 Extended mode:

If you don’t want to download the whole thing, the only required files are:
config.ocio
/luts/srgbf.spi1d

Generally though, if you have a Rec2100 (Rec2020/ST2084) Image, the following nodes will flip it to Display P3 Extended.

• ST2084/Rec2020 → Linear P3 D65
• Mult down by .01 to convert 100 absolutle nits to 1.0
• Apply peicewise sRGB inverse EOTF (with the rest of the curve above 1.0 being exptrapolated out)

set cut_paste_input [stack 0]
version 13.0 v3
push $cut_paste_input
Colorspace {
 colorspace_in st2084
 primary_in Rec.2020
 primary_out DCI-P3
 name Colorspace3
 label "Rec2100 to Linear P3 D65"
 selected true
 xpos 1531
 ypos -21
}
Multiply {
 value 0.01
 name Multiply2
 label "100nits -> 1.0"
 selected true
 xpos 1531
 ypos 11
}
Colorspace {
 primary_in DCI-P3
 colorspace_out sRGB
 primary_out DCI-P3
 name Colorspace4
 label "Linear P3 D65 -> Display P3 (sRGB EOTF extended)"
 selected true
 xpos 1531
 ypos 53
}

[Thomas_Mansencal]

Hi,

Just wanted to show a quick comparison between a few CAMs with sRGB.

• First Column: Uniform Lightness Ramp, Constant Chroma (Varying Per-Row), Varying Hue
• Second Column: Out-of-Gamut Colours
• Third Column: First Column Converted to Luminance

CIECAM02

CAM16

Kim et al. (2009)

ZCAM

A few quick notes:

• A significant portion of the visual artefacts are cause by OOG colours.
• CIECAM02 and its CAM16 child do not work well with dark colourful colours.
• Kim et al. (2009) exhibit some strange artefacts, there is no reference implementation so maybe we broke something.
• ZCAM behaves the best of the 4 models, simpler is better.

Colab Notebook: Google Colab

[priikone (Pekka Riikonen)]

That’s great video! Overall I really like the color that comes out of ZCAMishDRT but there’s also issues beyond the blues going towards cyan. As you noted there’s some issues with bright colors.

These are +2 stops. Notice how all reds, and oranges go kind of pink:

Here’s image with clipped sky:

But overall the color is great. But, wIth the SSTS and darkening of greens and reds it does plus the blues going toward cyan, the look out of this DRT is very filmic.

[Derek]

I’ve been experimenting with comparing the zCAMish DRT on and HDR and SDR monitor side by side. Wanted to share my observations.

One difference is that the SDR crushes the shadows, whereas the HDR does not. My understanding is that this is not so much an issue with the color, but with the tone scale, and precisely this crushing of shadows has been also noted of the ACES transform. It also makes sense that this “slightly less contrast” tone mapping is not an issue with HDR since it (by definition) has a bigger range between dark and light. So I guess the tone curve used for SDR should not be the same as for HDR?

The other thing I’m seeing is issues with clipped sky in the SDR, which does not happen with the HDR. Here’s the image in ACES:

Here it is in zCAM. Note how the blue in the sky is overwhelmed by the orange. This does not happen with zCAM in HDR, just in SDR:

Finally, here is zCAM with an adjustment using the ZoneSat:

This looks closer to how it appears in HDR, with the difference being that the saturated colors on the clouds are retained in the HDR, while the SDR they go to white.

If the goal is to have SDR and HDR look sort of similar, this can be done by applying the zoneSat with the same settings to the HDR which causes it to desat the highlights a bit, matching what the SDR is doing.

Hope that’s helpful.

[alexfry]

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:

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

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

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]

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.

iCloud.com

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

[alexfry]

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:

@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:

[Derek]

@alexfry

@matthias.scharfenber has been working on a completely independent implentation to mine, which now has an explicit highlight desat (which is helping the Yellow issue).

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

[priikone (Pekka Riikonen)]

@alexfry

@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:

@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 (Nick Shaw)]

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 (Pekka Riikonen)]

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 (Matthias Scharfenberg)]

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.

Tristimulus/aces_vwg_output_transform/blob/master/DRT_ZCAM_IzMh_v04_Blink.nk

[Derek]

Here are some further examples comparing the highlight desaturation.

[matthias.scharfenber (Matthias Scharfenberg)]

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!!

Tristimulus/aces_vwg_output_transform/blob/master/DRT_ZCAM_IzMh_v06_Blink.nk