ZCAM for Nuke

[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

[Alexander_Forsythe (Alex Forsythe)]

Thank @matthias.scharfenber!!! Awesome work

[matthias.scharfenber (Matthias Scharfenberg)]

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.

Tristimulus/aces_vwg_output_transform/blob/master/DRT_ZCAM_IzMh_v07_Blink.nk

[priikone (Pekka Riikonen)]

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 (Christophe Brejon)]

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.

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

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…

@ChrisBrejon

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”

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 (Christophe Brejon)]

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

@priikone

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.

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.

@priikone

I’m actually hopeful that OpenDRT could be improved a little bit more so that perhaps Default LMT isn’t even needed with it.

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.

@priikone

As far as “neutral DRT” goes, I have no idea what that means.

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