OT Candidates discussion (split from other thread)

NOTE: The posts below have been moved from this thread

It’s interesting you brought up these slides because in my tests with the ACES exr set I didn’t feel as much the remaining issue of blue to magenta on Candidate A. While I think Can. A, and then C are the most potent of the three, here were a couple of my findings/opinions on them.
My focus was much more on camera scene captures than CG imagery. Keep in mind that I only evaluated in SDR Rec.709.

Skies/blues in C feel oversaturated againts other hues in day but bleak/ill, at night scenes vs A.

(left C, right A)



Near neturals feel quite colored quickly vs A. Overal saturation feels quite high for a display transform. Skin doesn’t render as nice as A. What I do like about C here is that the blue patch row1 column 2 feels more uniform with other patches like it’s lit by the same light source, but I don’t know if that chart looks like that IRL under those conditions.

left C, right A


For comparison I personally like DaVinciDRT which seems to treat that blue patch also more perceptually uniform to others but still has smoother skin tone and overall saturation.

DaVinciDRT Rec.709 Gamma 2.4

The rendering difference of skin was especially evident in this sample where I much more prefer A.

left C, right A

Lastly in the CG fire explosion scene I’d still prefer A over C because it’s skew of bright reds is still preferential in this case. But you could debate on whether this should be intrinsic in a display transform or that artists should control this to achieve such looks.

left C, right A

Overall I felt that A came with ‘more bonuses’ than C, putting me in a place where my grading operations would involve less corrections I’d want to do on every shot. Perhaps it could totally be the other way around should my work involve much more computer graphics or wider gamut/HDR content.

Regardless of which Candidate will make the cut, it’s going to be a step forward over the current transform which I’m happy about.

2 Likes

I like A a lot too, it’s more of a blank slate type of look while C is more “finished.” I only do CG so I usually end up wanting to pump some life into things with saturation and contrast, hence why I prefer C out of the box.

Those are all excellent points @Shebbe
Lots to chew on!

I was really struck by your observation about skin, and in general Candidate C feeling a bit over-saturated. So I took a stab at making an LMT for C to address that. It’s basically reducing saturation on the highlights using @jedsmith’s ZoneSat tool.

C-LMT.nk (20.7 KB)

You can toggle through the images to compare.





This also helps with sky



Regarding fire, I’m a little hesitant with that CG image as I believe it was made a while ago, and there have been some advances is how CG pyro is rendered. Or said differently, that image was rendered to take advantage of the skews in ACES. Here is @Thomas_Mansencal’s fireplace photo.

C feels a bit “salmon” to me.

A feels a bit… fluorescent. Yuck.

Here’s A with Gamut Compression. I vote that Candidate A should have the RGC applied to it, (C does).

Nice! I didn’t want to talk too much about it in my post. In the feedback form I filled I also explained that it was quite easy for me to address the high blue saturation for skies with simple Hue v Sat curves and the skin was also easily matched with the HDR palette in Resolve, which has a saturation slider per zone similar to ZoneSat I guess. This is great of course because it means the artist doesn’t have to do much if his/her taste differs from the default rendering. However skin and skies are quite important parts of an image so having to address them by default to me was enough reason to say that the other candidate is more preferred now that there’s still a choice. If C wins (and stays as is) I could of course create an LMT for my default template.

Is the image you used the same as ACES_OT_VWG_SampleFrames.0077.exr? (labeled 0076 on the image itself) My renderings show something very different.

Can. A

Can. C

I do agree on the “salmon” look of C however and I found it pretty hard to correct this to a ‘typical warm fire’ look because the hue stays quite monotone after adjustments.
Using RGC on Canidate A also diminishes the drift to yellow but it was quite natural to push them back there if you’d want to whilst keeping the darker parts more red.

Left Can. A RGC, Right Can. A RGC with adjustment

1 Like

In doing my experimentation with slightly modified version of ZCAM DRT I found it very easy to make the DRT match the overall saturation level of Candidate A in SDR. I can later push a new version of it that matches it. The current version in the repo is already closer to it than the Candidate C version.

@sdyer, maybe this candidate discussion should be moved to its own thread from this one just to keep track of it better?

2 Likes

Done.

I hope people are happy with which posts I moved.

2 Likes

Indeed. I was mistakenly using an older OCIO (rev007) so Candidate A was… something else. The current Candidate A (that you show) looks great with fire, and FWIW, looks a bit “salmony” with the Gamut Compression. I think that may be because rgbDT uses a different color gamut. Heck, maybe it has gamut compression already in it since Jed made it. I’m not sure. Do you know?

1 Like

I don’t know too much about the specifics of each candidate. Perhaps someone more closely involved can comment on that.

Awesome! Do you think something can be done about the salmon colored fire as well? I seem to recall that there was something in the Zcam model that addressed that in one of its incarnations.

I’m still doing some testing but overall I think this branch looks quite beautiful. It has a bit more saturation than A but not so much that you think it’s overdone for a DRT. The blues and reds sit in a much nicer place. On some stills it’s a bigger winner for me than Can. A!

Some quick examples screengrabbed from Nuke UI in order:

Can. A // DRT_ZCAM_IzMh_v12_deriv // Can. C







I’m not sure if a closer match to Can. A is even necessary. What would be it’s purpose if they look the same? Maybe if Can. C in return translates better to HDR I’d understand. I haven’t tested grading under it yet but my main points on Can C rev009 are addressed in this version (DRT_ZCAM_IzMh_v12_deriv) already. Maybe fire still renders slightly red-ish but at least it doesn’t feel as ‘salmony’ as the current Candidate C.

[edit] I was pointed out that on the DRT gamut compression was meant to be checked which in my tests wasn’t the case invalidating my findings/opinions.

In per-channel transform you get the orange and yellow because of the skews. In DRT ZCAM you don’t. So why is the fire salmon color then? I could be wrong, but to me this is about color accuracy. For some reason the DRT doesn’t render exactly the accurate color, and skews have nothing to do with it. If the color was more accurate, it would (and should) look fine. But it’s important to look real photographs of fire, and not only renders. Thomas’s fireplace is a nice example picture. I forget if he posted a version of how he perceived it…

I have a feeling that people preferred Candidate A in SDR because it’s less saturated and thus more of a good starting point, while Candidate C was already kind of a finished look. But, let’s wait for the full survey results.

Personally, I would lower the saturation of Candidate C in SDR approximately to the same level as Candidate A and then we don’t need Candidate A :sunglasses:

Yes, he does here (spoiler it’s not salmon):
Output Transform Tone Scale - #137 by Thomas_Mansencal

What are your thoughts about having a hue shift to engineer those “happy accidents” of the per-channel? Perhaps in a default LMT. Here’s for example the Zcam deriv with a shift from red to yellow using @jedsmith’s n6HueShift gizmo. The tricky part is the danger of having this make faces look jaundiced. I think if this was zoned so it only affected highlights that could solve it.

Wow the blue skies are really looking much better in the Zcam Deriv, especially notable is the night sky no longer being teal!

Again, I think it’s more about color accuracy (and again, I could be wrong). I also don’t think trying to skew it towards yellow is actually correct thing to do. If you look at the “reference” image of how Thomas perceived it, I would think you’d actually want to darken the reds and skew them towards magenta instead (ie. they’ve been rendered too bright and too orange). As for the bright middle part of the image, it would be interesting to see how it renders in HDR. Other thing to keep in mind is that the DRT has lower contrast and saturation than Thomas’s ground truth image, so it’s not supposed to render identical.

I don’t think that’s correct actually, it’s not supposed to be that different. @Shebbe might have wrong input primaries.

Discussing the Candidates during the evaluation defeats the idea of blind testing.
Your posts could bias other testers.

1 Like

I don’t think we’ve ever considered the testing to be genuinely blinded. The meetings are public and recorded, and the Nuke script to generate the candidates is in a public GitHub repo.

1 Like

Please tell me if these settings were correct? (Viewer set to Raw).
Sorry for the confusion if they weren’t. Don’t think I touched any of the other parameters exposed on the node.