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.
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).
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.
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?
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:
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.
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:
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.
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.
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…):
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:
@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).
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.
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.
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.