I vote we call this SwizzleCAM 
1 Like
I’m not sure that sticking to ZCAM is that important. The LUT I gave my tech art lead used Matthias’ abney_abyss parameter in addition to modified cg and cb constants to try to get dark blues to behave in addition to blending v9 and v11 models. I kept v9 for the reds because it distorted bright reds to bright oranges in an useful way so yeah… production needs before anything else
Looks promising! Curious to see what it looks like with gradients on stress test synthetic images and negative values.
Do you have any plans to implement this version as a next rev. of Candidates or it’s just the first attempt of finding better values that should be improved at first?
Another part of the model is the pre-modification to the XYZ values that is done before applying the LMS matrix. It has a huge effect on the blues and a small one on the reds. There’s also the thing where it uses M only for J instead of L+M * 0.5 like JzAzBz and ICtCp. Lots of parameters to play with and maybe plug into an optimizer for re-fitting 
Btw, I have a DCTL port of v11 ZCAM model if anyone is interested. I don’t have it on Github and there are many hacks by yours truly in the code but it works and doesn’t crash Resolve.
4 Likes
Oh this would be great to see!
Ok. I’ll clean it up then put it on Github.
1 Like
@alexfry @matthias.scharfenber Hey guys, would you care to share your updates? On my side, I have added some experiments to my DCTL version which I will upload soon. An interesting one is scaling the XYZ after conversion from JMh to XYZ by JMcompressed.x / JMh.x instead of setting JMh.x = JMcompressed.x before conversion to XYZ. It seems to preserve blues better and is definitely less objectionable than not compressing J which is what I did when using the “Old HL desat” hack (removed in my current version) or the achromatic shadow hack (also removed).
Any chance of getting this as Nuke node too?
Hey, the most recent version of the ZCAM DRT (featuring the “relaxed” XYZ_TO_LMS_ZCAM matrix, and MM curve) can be found in the test candidates repo.
There is also a HDR YouTube clip comparing them with a bunch of exposure ramping stills.
It should only be viewed on a HDR display, as SDR playback will be passing through YouTube’s tonemapper, which dramatically effects the look.
1 Like
I am a bit concerned about that approach because it is taking a compression ratio calculated to be applied to non-linear J, and applying it instead to linear XYZ data. And since @matthias.scharfenber’s J compression is calculated to be focussed towards a particular point (compressing up or down, depending on the current value) I would also think that focus point would not mean anything with the linear data.
I am wary of something which has something of a “the result looks better in some cases, but I don’t really understand why” factor!
I think the issue lies in the compressing up dark blue values in non-linear space. This is what led me to add an option to not compress J further than what the SSTS had already done in the first place before I tried this as a middle ground and saw that there was some value in it, i.e. it’s slightly better than fully disabling extra J compression in the gamut mapping step. Another thing which should be taken into account when discussing the cyan thing is cusp smoothing because the higher that parameter goes, the more cyan deep dark blues become. Last but not least, it might have been worth mentioning while doing the demo at the meeting that there was a LMT applied to the images which saturated dark blues and desaturated bright cyans (in AP0 space) in addition to having the ACES gamut compression with non-default limit yellow (at 0.99) as a pre-step fix for blues and cyans before applying the DRT. I should probably start tabulating some data about what happens to key input values under various settings in a spreadsheet.
I wanted to share an observation I had about color picking under zCAM and OpenDRT. I’m finding it next to impossible to get high saturation blues or greens with zCAM. I’m thinking of this in the context of picking a material color for a CG asset.
Here’s a comparison or pure red, green and blue (ACEScg primaries)
Note that I have cleverly labeled each with a letter in this blind test so you could not possibly guess which one is which 
Z has a desaturated blue, and an even more desaturated (mint) green compared to O or A.
This desaturation in Z appears to be related to the gamut compression i.e. it goes away when it is disabled:
1 Like
Yes, the whole Fairy experiment (see above) showed that greens, too, appear more cyanish when doing pure hue preserving compression. There could perhaps be a middle ground of hue preserving and saturation preserving by compressing less and letting the more farther out colors clip (towards the green primary in this case). Hue-wise that ZCAM green is supposedly more accurate… But it just doesn’t look as expected.
Thanks that’s helpful. I do find that I can pick the colors I want by shifting the hue. A bit unintuitive perhaps, but workable.
Perhaps related is that I’m seeing that zCAM, compared to OpenDRT seems to have a drop in perceptual saturation across the hue spectrum. Note for example below with zCAM how in the greens (hue 122 and 142 in particular) appear to drop in saturation compared to the hues to the left or right. In comparison OpenDRT appears perceptually to have consistent saturation across the hue range.
I imagine that this is what you are referring to with zCAM being hue preserving, at the apparent expense of it being saturation preserving. I guess I’m just mentally catching up here, putting the pieces together for myself :).
From this I will tentatively say that to me OpenDRT looks like it is hue preserving and saturation preserving, whereas zCAM looks like it is not hue preserving (in that it does not give me the hue I would expect) and not saturation preserving (in that the saturation seems to drop for certain hues).
I stress the word looks here. I’m sure you are right that it is technically hue preserving. However from an artist’s/user’s perspective ideally you want to have the tool be a controllable and predictable means to get the colors to look the way you want. It seems to me that zCAM is doing a lot of stuff under the hood and is somewhat blackboxy thus resulting in some unwanted/unexpected stuff happening. OpenDRT seems to be more known in what it is doing mathematically, and thus controllable and predictable.
Just one opinion of a CG artist. I could be totally off base here. That’s what I love about these forums is there are so many folks that are waaaay smarter than me, and I’m constantly having my mind blown and learning. So I add a huge caveat of humility to the above.
Yeah, this is a subtle point, but OpenDRT is only hue preserving in it’s application of the tonescale, it doesn’t do anything to preserve hue when mapping down to the final display gamut.
So hue skews that were introduced by the application of the tonescale in an RGB space are avoided, but skews that are the result of the matrix+clamp down to the final display primaries are not.
The upside of this is sometimes (like in the case of jamming a colour slider to maximum green in AP1) you can end up with more green in 709 than you would see through a hue preserving system like ZCAM DRT. The down side is that when you compare OpenDRT’s 709 rendering to it’s P3 rendering, you don’t get a more saturated version of the same green, you get a different green.
Something that also should be noted here, is that despite it feeling this way through the older RRT (and other clipping final display mappings) Max AP1 Green is not just a more saturated version of Max 709 Green, it has a lot more cyan in it.
Should the underlying design of a new forward looking display transform take in account the biases and historical baggage of existing colour pickers, and the user expectations around them? I’d say that’s an open question. I have my opinions about how some of this should work, but I’m also aware that things have to work with the world that is, not what I might like it to be.
I still feel like there might be a middle ground somewhere between the two. Something with the simpler definition of hue that OpenDRT uses (as opposed to a complex CAM), but with an explicit target display gamut compressor like ZCAM DRT uses. As always, it’s a lot quicker to just say that than it is to actually sit down and string it together into a working prototype.
There may be some exceptions, but I think that’s an illusion for the most part. We’re all just fumbling through this together. If any of it was easy or obvious, we wouldn’t still be trying to work out which way to go.
2 Likes
@Derek
Could you explain how you have derived your hue steps?
Before we visually judge the result of a pattern we need to understand the origins of that pattern.
1 Like
@daniele
That was rendered in Maya. Here’s a version with 20 even hue steps. Nuke file is also attached. It is set to use the default ACES 1.2 OCIO config to put the swatches into ACEScg working space.
zCAM_hueSteps.nk (119.5 KB)
Hi,
had a look at the nuke script, I do not understand how you derived the swatch colour code values.
What kind of dimension are you trying to space out “evenly”?