Here are some further examples comparing the highlight desaturation.
2 Likes
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!!
4 Likes
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.
3 Likes
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).
3 Likes
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
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.
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
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!
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!
2 Likes
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:
OpenDRT v0.0.90b4:
ACES 1.2:
Nuke script used to generate these: plot_hue.nk (348.0 KB)
What do these plots mean?
That’s a good question. I think this is just for comparing behavior of these DRTs. In practice what they show is what happens to those hues with 100% chroma from 0-14 stops (scene linear) as they go through those DRTs and come out as display linear values.
With OpenDRT we see how the chroma compressed “balloon” has popped over the cube, except yellow corner which the balloon didn’t cover. @jedsmith please correct me if I’ve misunderstood this part.
With ZCAM the cube was filled quite fully and the DRT then takes them towards the white (this is what I assume is happening based on what I see in that plot). I think the issue with the blue hue skew is also evident. It seems as the hue hits the edge of the blue corner (or thereabouts) it tweaks towards cyan.
With ACES we’re seeing what happens with per-channel DRT without some additional gamut compression (like RGC) applied. There would be nasty, but familiar, hue skews if this was shown as an image. The “path-to-white” is a by-product of the per-channel DRT.
Edit: just to add that the plots move because I’m rotating the hue 5 degrees every frame.
1 Like
Comparison like > < or =? If so, what is on the left and right side of the equation here in terms of domains?
I thought RGB was a stimulus encoding? Isn’t “hue” a sensation based encoding? I’m not sure the RGB stimulus encoding domain shows this?
Yes, this will show that we have device dependency because the values escape the destination RGB stimulus encoding, which whether we like it or not, will manifest in something we see, in terms of observer sensation. That will in fact vary between display outputs because of this. The only way to have it not vary would be to take the stimulus output from that specific display, whatever accident happens with those excursions, and then attempt to re-map those values.
I certainly think this is useful.
I think it would address @Troy_James_Sobotka’s points and help focus the “why’s” if you were to plot the perceptual correlates (JzAzBz?) values of the input ACES values and the corresponding perceptual correlates values out of the ZCam Model (perhaps both before and after any gamut compression / display code value conversion).
That could show the perceptual effects of the ZCam DRT on a given set of input stimuli and show what, if any, deviations in perceptual correlates are due to the ZCam portion of model vs. the gamut compression taking place in the conversion to display code values.
Isn’t this a tautological circular dependency?
I was thinking about that … I don’t think so particularly once you toss in the display code value conversion / gamut compression, but maybe use CIECAM02 as the comparison space. Point is, what’s the perceptual correlates before the model and after. Before the conversion to code values, and after.
Comparison, definitely wrong word. It’s just a visualization. Is one better than the other, objectively, I don’t know. I like the ZCAM behavior personally. I suppose that would be the water-fills-the-cube approach with some engineered path to white from the cube corners.
Another wrong word.
Couldn’t agree more.
In terms of image engineering though, does that model exist? I’m heavily skeptical. I believe Daniele made a more or less equivalent statement in one of the recent meetings as well?
You can probably guess which axis I have concerns over, as the whole house of cards rests atop that specific card when it comes to imagery.
We can plot with the models we have and then look at it to verify the plots make sense.