User testing of possible Output Transform candidates

Discussions - ACESNext VWG – Output Transforms
1

As discussed during meeting #37 (12th Jan 2022) we plan to share the three possible candidate Output Transforms with a small group of colourists, to obtain preliminary feedback on their viability for grading under. The proposed candidates are:

  1. The current SSTS based transform (used for both SDR and HDR) with RRT sweeteners removed.
  2. Open DRT
  3. The ZCAM based DRT

In order to make these transforms easily distributable, we plan to bake them into LUTs, in two versions each – 100 nit BT.1886 / Rec. 709 and 1000 nit P3-D65 limited ST.2084 / Rec. 2020.

Baking LUTs will obviously mean that fixed parameter values need to be chosen. We would therefore like to hear from people who have tested the various renderings, with feedback on their preferred settings, and where applicable which version of a transform they prefer.

1 Like
2

I used SSTS for SDR 100 nits but I have never removed the RRT sweeteners. I was instead stacking the blue correction matrix which I then inverted right after applying the SSTS. I also used 4.8/100 instead of 10/100. I also had the dark to dim correction since it was for display on sRGB monitors. For HDR at 1000 nits, I had dark viewing conditions and didn’t use limiting primaries but I also had RRT sweeteners and the blue correction matrix (inverted later) on.

For OpenDRT, I used multiple versions. Currently, I have version 0.83b2 with the following modifications:

  • Weight vector is Red = 0.25, Green = 0.15, Blue = 0.13
  • Dechroma is 0.6

We talked about upgrading to the latest version of OpenDRT but we didn’t like how pink it made things look even with modifying the weight vector and adding a hue twist to fix fire VFX was out of the question because, while it did fix fire VFXs, it broke game areas with red-dominant lighting.

Preferred parameters for ZCAM model is a hard one for us since we just started trying it yesterday and had a meeting about it this morning. We also haven’t had time to test it in HDR yet. However, I have shown two versions to our tech art director :

  • Almost default but with dim viewing conditions.
  • The tweaked settings that I put in the ZCAM for Nuke thread. Since these are so custom for our content, I don’t think these are usable by anyone else.

It’s also worth noting that, before showing ZCAM to our tech art director, I did some slight grading to remove the blue->cyan hue shift that it introduces and tweak the highlight range so, while I think it’s a promising model, I also had to add sweeteners on top of it before running it in front of my leads and the results I got with it should probably be discounted :slight_smile:

1 Like
3

I think it’s useful to note that you were easily able to grade it to get to where you wanted. That’s assuming you were grading under it. rather than after it… And it will be good to know if those same tweaks are equally applicable to HDR.

4

Under it indeed. It’s easier to adjust things when you still have full colour and luminance information :slight_smile:

1 Like
5

Hey Nick,

thanks for bringing this up and apologies for the delay in replying.

From what I can remember, I have always tested the different prototypes with default settings.

The only parameter I changed was “dechroma” on OpenDRT which I pushed to a value of 1. I just checked today (with OpenDRT v0.0.90b4) on all my CG renders and it confirms what I recall from my tests six months ago : I prefer OpenDRT with a “dechroma” of 1. True, my Lego sailors won’t look as saturated but that’s the price to pay I guess.

I just checked ZCAMishDRT v006 and I also like the default settings, even if I see some weird stuff breaking in the blues that I think are worth pointing out (actually, I already posted about them, so I guess I won’t double post again).

For the record, a sRGB sphere lit by a distant light displayed with ZCAMishDRT v0.6, OpenDRT v0.0.90b4 and JzDT.
image

Update : I tried to play with the different the thresholds (Edge and Head) on ZCAMish DRT v0.6 to fix this blue artifact but I was loosing too much chroma. I could not find a sweet spot unfortunately.

I will try to test Mathias’ implementation this weekend.

Thanks,

Chris

6

Hello all,

I finally found some time to test “DRT_ZCAM_IzMh_v07_Blink” (sorry for the delay). I think it is an interesting prototype/candidate. It has less contrast than the current ACES Output Transform (I only compared the Rec.709 ODTs) and does not have the hue skews (at least on sRGB values) nor the clipping.

I found Mathias´ take on ZCAM DRT to bit a tiny bit more robust than ZCAMish DRT : it seems more “neutral” in terms of contrast, the ACEScg blue primary looks less green and the sRGB blue primary does not have the artifacts that I noticed previously. I tried to tweak a bit the parameters, but so far I found that the default settings worked pretty well.

Having checked all my CG examples, I would personally be interested to see this prototype chosen for ACES 2.0. It does a good job at maintaining both “chroma” and “luminance” at the same time (sorry for butchering the words).

Here are a few examples :

sRGB blue sphere artifact :

sunny_spheres_zcamish
sunny_spheres_zcamish1920×1080 341 KB

sRGB blue sphere “fix” :

sunny_spheres_zcam
sunny_spheres_zcam1920×1080 334 KB

ACEscg blue primary “looking” green :

blue_volumetric_zcamish
blue_volumetric_zcamish1920×1080 70.6 KB

ACEscg blue primary “looking” bluer :

blue_volumetric_zcam
blue_volumetric_zcam1920×1080 72.7 KB

Apart of double-checking all my CG examples, I also ran a couple of tests with some ramps. You may found this interesting (or completely useless) :

sRGB blue artifact :

srgb_ramp_zcamish
srgb_ramp_zcamish2048×1556 89.8 KB

sRGB blue “fix” :

srgb_ramp_zcam
srgb_ramp_zcam2048×1556 51.8 KB

Unfortunately it seems that the blue “artifact” is present in both implementations with an ACEScg blue primary :

acescg_ramp_zcamish
acescg_ramp_zcamish2048×1556 101 KB

acescg_ramp_zcam
acescg_ramp_zcam2048×1556 66.1 KB

I also did the ramp test with P3 primaries and I could not see the artifact. They did appear though with BT.2020 primaries.

If I had to use “DRT_ZCAM_IzMh_v07_Blink” on a full CG production tomorrow, I would probably set my working/rendering space to “linear_sRGB” or “linear_P3D65”. I think that this way I would avoid the hue skews that are most noticeable on ACEScg primaries and still maintain a “high level” of chroma (as hopefully the four images below show).

JzDT :

sunny_spheres_JzDT
sunny_spheres_JzDT1920×1080 331 KB

DRT_ZCAM_IzMh_v07_Blink :

sunny_spheres_zcam
sunny_spheres_zcam1920×1080 334 KB

JzDT :

light_sabers_JzDT
light_sabers_JzDT1920×1080 182 KB

DRT_ZCAM_IzMh_v07_Blink :

light_sabers_zcam
light_sabers_zcam1920×1080 181 KB

If I understood Alex´s explanations correctly, the hue skews noticeable on ACEScg primaries (especially blue and green) are part of the ZCAM model. So only some fitting would help on this matter ? Sorry if I got that wrong.

I also wonder if JzDT should be evaluated. It is a quite simple algorithm that yields pretty good results out-of-the-box. And sorry for repeating myself, but ACES 2.0 being a major release, I have a hard time seeing a “SSTS for both SDR/HDR with the sweeteners removed” as a potential candidate. It sounds more like an ACES 1.4 version to me.

My tuppence,
Chris

3 Likes
7

I’m totally agree with that!

And regarding OpenDRT vs ZCAM DRT, I like how ZCAM DRT doesn’t make images look desaturated in the shadows. So this is why I probably prefer ZCAM DRT over OpenDRT as a more comfortable starting point for colorists. And if it can be fast enough even for very old computers, and blue colors can be fixed, I think ZCAM DRT is my preference.

And current ACES DRT look is the most common reason why a lot of colorists I know not switching to ACES. Awesome reference gamut compress, very simple to use IDT and ODT, simple and clear vfx roundtrip. Everything is perfect from the artist point of view, but… they don’t like its look and always back to familiar logC + ARRI LUT / Cineon + 2383 LUT.

1 Like
8

@Derek was kind enough to correct me on this quote. I will just add it to the thread for everyone :

Actually as Nick was noting in a recent VWG meeting, the blue hue skew is not coming from zCAM itself, but rather from the gamma compression in the DRT. You can verify this in Nuke by disabling the gamut compression section in the DRT_ZCAM_IzMh node.

Thanks Derek !

1 Like
9

Yeah, there is a slight difference in the tonecurves we picked when building them.

My older ZCAMishDRTv06 uses the currently shipping 48nit c9 two part SDR curve, as used in the existing ACES 1.2 SDR transforms. The intent here was to match the existing transforms, removing contrast from the conversation.

Mathias’s DRT_ZCAM_IzMh_v07_Blink uses the SSTS curve, in .0001/10/100nit mode. Despite the SSTS being used in the wild for HDR transforms, the SDR version of has never shipped in a standard ACES transform, and has a significantly lower contrast look that the older c9 SDR curve.

As I was showing the in the meeting last week, the SSTS in 0001/10/100nit mode tracks surprisingly close to @KevinJW 's SDR production LUT average data, so we might be able to use it without a ton of messing about, which would be nice.

@nick was pointing out, it may still make sense to rejigger all 3 candidate transforms to use the same curve as eachother, simply to remove contrast as a factor is discussions in which the rendering approach is meant to be the main point of discussion.

10

Thanks for the explanation Alex ! I think it is good to have this written down somewhere on AC. I did watch last meeting´s recording and heard your explanation. It all makes sense now.

Much appreciated,
Chris

11

I think this definitely makes sense. Personally I think SSTS in SDR is still too “high” of a contrast as a starting point (but not by much) and for later (or final) user testing it probably makes sense to offer couple contrast alternatives for all the candidates and ask users which they preferred most.

For OpenDRT my favorite is the latest version 0.0.90b4. Like many others it seems, I’d like the highlights to desat faster but I still usually lower the dechroma because I want also the saturation to be retained. A curve that retains (adds) saturation to shadows and keeps the saturation going for longer and then desaturates faster at the end would be the best. I can’t get that to a point I like with the knobs in the current implementation. So I prioritize the saturation and fix the highlight desat in LMT. For DRT ZCAM v07 I’ve only used default settings. The default surround should probably be changed.

Both DRT ZCAM and OpenDRT “feels” similar when grading, to me. Both have similar “issues”. Default LMT (or dare I say Reference Rendering) might be a good idea.

12

So quick morning notes from my a comparison done using my Resolve project that has nodes for tons of DRTs and settings for the ones that are customizable:

  • OpenDRT colorimetry is closer to the Alexa LUT that’s shipped with Resolve (the menu only calls it Alexa so no info if it’s K1S1 or ALF-2) while ZCAM colorimetry is closer to ACES especially in the purples.
  • A reference white of 200 on ZCAM DRT brings the highlights in the reds closer to one of the LUTs from RED’s SDK (High Contrast, R_4 Very Soft Size) and ACES while a reference white of 100 is closer to OpenDRT and the aforementioned Alexa LUT.
  • A Y_MAX of 120 on ZCAM in SDR will get you the same amount of clipping as ACES if that’s your thing. Something a bit higher than 100 but lower than 120 can give you some hue twists on reds without clipping too much. Reference white is 200 and highlight desat have been reduced to 1.75 in this test because that’s what looked the best on my image set so your mileage may vary with this.