Look Transforms

[Derek]

Here’s some experiments with the ZoneSat. First for reference this is OpenDRT (sat 1.2) where the skin is looking colorized due to the dechroma:

Then this is the same with the dechroma node disabled. This is my target for skin saturation:

Now for ZoneSat. The settings for ZoneSat are printed on the image (bottom left). This seems to be a pretty good match to the disabled dechroma.

However what I don’t like is the way the saturation handles hilights. For example the color of the clouds in this image is going from orange to white (with OpenDRT decroma 0.5 sat 1.0, ZoneSat hi sat 1.5):

This is where the No6Chroma node comes in. With its saturation I get golden sunlight in the clouds and I also get blue sky, as opposed to having the whole sky go pollution orange like it is above. Settings are on the bottom left corner of the image:

This combination of Chroma and ZoneSat also gives a nicer look to skin, giving it more shine.

Here is ZoneSat alone for comparison. Note how the skin colors looks more flat here:

Comparing the skin and clouds in the ZoneSat and Zonesat+chroma what seems to be the difference is that the combination Zonesat+chroma looks like its doing a nicer tone mapping compared to the flattening of ZoneSat. Not sure that’s technically the right description of what’s going on, but it definitely looks much nicer/more natural.

A byproduct of the combination of ZoneSat+Chroma is that both red and blue are darkened. Sort of an accidental HK compensation I guess! Additionally red gets saturated which is why I lowered the red on the No6Chroma node to counter balance this.

I’m thinking that it might be good to have these two nodes integrated into one node so we can keep the good things that are happening (skin shine, golden sunlight) but not the unwanted things (hue shifts) or at least have more control.

EDIT: Here are the two images with @priikone 's expression (and corresponding updated settings). What’s nice about this is that yellow is not getting desaturated like it was on the v1 ZoneSat. You can observe this in the yellow color checker swatch in this first image:

[jedsmith]

@priikone

changing the f0 expressions to max(r,g,b) > p.0 ? clamp((p.1-max(r,g,b))/(p.1-p.0)) : clamp((max(r,g,b) - p.0)/(p.1-p.0))

Hm, I’m not sure what the problem is that you are seeing. Your modified expression would have a hard cut at p.0. The expression in the original node is intended to extract a range to use as a lerp factor. The extracted range is intended to be from 0 to p.0 with a smoothstep falloff to p.1. Your expression will create a result that is 0 from 0 to p.0, with a cut to 1 at p.0, with a smoothstep falloff from p.0 to p.1.

If you are trying to create a smoothstep window function, which would extract a range with a falloff on each side, you could so something more like this:

# params controlling range
s0 = 0
e0 = 0.2
s1 = 0.3
e1 = 0.5

# linear extraction of falloff range
x0 = clamp((max(r,g,b)-s0)/(e0-s0))
x1 = clamp((max(r,g,b)-e1)/(s1-e1))
# smoothstep
x0s = x0*x0*(3-2*x0)
x1s = x1*x1*(3-2*x1)

# assemble
max(r,g,b)>s1?x1s:max(r,g,b)<e0?x0s:1

Here’s a nuke script with a demo:
smoothstep_window_demo.nk (9.3 KB)

[priikone (Pekka Riikonen)]

@jedsmith

Hm, I’m not sure what the problem is that you are seeing. Your modified expression would have a hard cut at p.0. The expression in the original node is intended to extract a range to use as a lerp factor.

Thanks, that’s useful example. Yes, I wanted to get explicit range. That’s what I thought the zone defined. Makes perfect sense now how it works.

[Troy_James_Sobotka (troy_s)]

A significant point of a chromaticity linear rendering approach is to enable creative choices by preserving the chromaticities in the image, and firewall some flourishes from further down the pipeline. There are plenty of times where one absolutely requires the chromaticity expressed to make it directly out the display, such as with media walls.

One is free to grade the resultant chromaticities as they see fit.

Adding warps / distortions / or other non-light transport manifestations are clearly in the creative domain, and would inhibit the ability to add the range of creative expression.

For example, if someone is obsessed with the digital gaudy rat piss skews, it is absolutely trivial to grab the range of chromaticities and skew / distort them as they see fit in the image. Resolve has a very good mesh distort for this, as well as the versus tools.

[Derek]

Posting an update to the skin look with the recently updated v83 OpenDRT and an updated ZoneSat. I’m feeling like skin tones are looking pretty great with these tools from Jed.

IPP-2

First image in each set is RED IPP-2 using a gamut convert from ACEScg to REDwide > RGB to Log3G10 > RWG_Log3G10 to REC709_BT1886 with HIGH_CONTRAST and R_4_VerySoft size_33 v1.13.cube (thanks to Jed for help with this workflow which works much better than the IPP-2 OCIO display from the VWG config I was using previously).

I’m using IPP-2 as a reference for an example of what appealing skin looks like. I also looked at ALF and K1S1 which also render skin nicely. My intention is not to attempt to match any of these, but rather to identify what is nice about them in how they display skin and to attempt to get the same qualities in a look for OpenDRT without any unwanted “side-effects” such as skews or changes in color.

OpenDRT v83

Second image in each set is OpenDRT as is. This is using OpenDRT v83 with default settings (i.e. saturation 1.2, dechroma 0.5, EOTF sRGB Display).

What is looking great on the skin is that the midtones and shadows are not losing saturation in v83 like they were in v82. However, compared to IPP-2 the color/saturation is looking too uniform across the subject’s face, making it look like one does when their skin is caked in foundation makeup losing skin’s natural glow (subsurface scattering), which brings me to…

Log ZoneSat

Third image in each set adds the latest log ZoneSat from Jed upstream to OpenDRT. My aim of the ZoneSat is to address the saturation looking too uniform across the subject’s face as noted above. My understanding of why DRTs like RED IPP-2 does not do this is that this is a “happy accident” of the per-channel approach where highlight saturation is decreased and hues skew towards the secondaries, in this case skewing skin towards yellow.

I’d like to keep the good parts of that “happy accident” (the desaturated highlights) and “spit out the seeds” avoiding any color skews, as color fidelity is what I especially like as an artist about OpenDRT. I’m therefore desaturating the highlights with ZoneSat, while striving to not lose saturation elsewhere (for example in the color checker swatches), in particular I’m looking to preserve saturated yellow, which ACES notoriously has a hard time with, but is coming through nicely in OpenDRT.

I made the overall saturation in the ZoneSat 1.1, with the goal not to increase saturation, but rather to keep it looking the same as it did in OpenDRT. These settings are just my preliminary tinkerings, and certainly more experimentation is needed! I’m thinking now it may make more sense to make the overall sat 1.0 and instead make the low sat 1.2, which gives virtually identical results but perhaps in a more intuitive way.

Here’s some more image sets with skin, in the same order as above.

Finally, here are some other test images to show how they are affected by the look. I’m excluding IPP-2 from these and just showing OpenDRT and OpenDRT+look

[jedsmith]

ZoneSatLog is just another experimental prototype, which adjusts saturation over a certain zone or range in a log domain instead of in a linear domain. In case anyone was wondering what the heck Derek was talking about

ZoneSatLog.nk (20.6 KB)

[meleshkevich (Anton Meleshkevich)]

@jedsmith I’ve tested the v82 and v83 versions with a short film, I’ve recently graded for a theatrical release, that has a lot of dark scenes and where I had to deal with those colorful artifacts in the shadows from current ACES 1.2 ODT.
For sure, v82 was awesome for dealing with these artifacts. But in warm scenes with tungsten lighting, faces become a little bit dead with v82. So I definitely prefer v83 version with " remove toe dechroma. it was a bad idea. " for these shots and its overall look for any shots with faces.
But… are there any plans to compress saturation somehow in the darkest shadows, so it could deal with these artifacts? Is it possible at all?

[jedsmith]

@meleshkevich

Is it possible at all?

Anything is possible

My commit probably should have said “remove toe dechroma while I figure out a better way of doing this”. I do not think chroma compression in super dark shadows is a bad idea. That corner of the display gamut cube is just as sharp and unforgiving as the white corner, even though we see it less. Using the amount of flare compensation to control this was maybe just not the right approach.

[meleshkevich (Anton Meleshkevich)]

Thank you!

I like this explanation :

@jedsmith

just as sharp and unforgiving as the white corner, even though we see it less.

I also notice the transition from saturated to clipped highlights but never thought they have the same nature!

I would also like to ask about what LMT will look like for those who want to use or to create them?
Will it be something like a plugin with a contrast, saturation, maybe channel mixer, RGB curves tinting (or toning?) constrained to a few sliders, and let’s say HSV density controls? And also probably with a slot for loading a ACEScct LUT? And it will be able to export sort of a preset, that could be exported and used with the other apps with ACES support? Or it still will be just a code, so only people who know how to write code will be able to create it?

[Troy_James_Sobotka (troy_s)]

@meleshkevich

Or it still will be just a code, so only people who know how to write code will be able to create it?

It is really easy to create and order LUTs, once you get a few tools. ociolutimage is an excellent tool, and Looks in OpenColorIO always are returned to the open domain light data state. It also lets you apply LUTs in any order, including upon an image referred state, which is obviously critical if there is a proper image formation pass.

[meleshkevich (Anton Meleshkevich)]

Thank you! So, if I get it right, it will be basically a look up table with aces 2065-1 in and out. I thought everything is moving towards a sort of a CDL on steroids with math functions instead of look up tables.

[Troy_James_Sobotka (troy_s)]

Depends.

I’d think most folks would probably want to avoid negative light values, and may choose something like BT.2020 for the open domain, but I suppose that’s up to you.

It is about as simple as rolling the lattice through your particular node / transform chain, and generating the LUT based on whatever shaped data you prefer.

Bear in mind that any value that escapes the destination volume, either via a LUT on the open domain light data or the closed image, will lead to device dependency that would essentially break the whole idea of colour management. cough.

Where that “acceptable” line of device dependency is for an individual ultimately is a qualitative judgement, of course.

[jmgilbert (Jean-Michel Gilbert)]

Hear hear. For some use cases, like me, any device dependency is unacceptable and hue angles have to be preserved no matter:

• How much out of gamut the source colours are (after grading)
• The peak white of the target display device

and any look should be inserted between the grading LMT and the DRT. Why at this specific position? Because, it’s not a bad place to clip and/or compress out of gamut values since, if placed before, you’ll be grading compressed values. Of course, you could be wanting to do that.

[meleshkevich (Anton Meleshkevich)]

Is there any simple way, I (as a colorist, not a programmer) could bring those hue skews, that usually caused by S curve highlights tone-mapping, back? The only thing that comes to my mind is to soft select highlights that has some saturation (so neutral colors are excluded) and tint it to the yellow. But this creates some undesired hue alterations. For example, yellow colors, that are closer to the orange, at some point become more green, and then, when they even closer to the orange they again become yellow as they should. Actually I was surprised, I thought I would get even more artifacts. But anyway, is there any better way to emulate those hue skews?

@jmgilbert

any look should be inserted between the grading LMT and the DRT

I always thought grading LMT IS actually a look (typically a LUT). Could you please explain me the difference?

[jmgilbert (Jean-Michel Gilbert)]

It is but I was specifically referring to the part the look that one might want to bake into the DRT. Have a look (pun intended) at how Baselight does things when using E-gamut. It looks awful without the scene look part and which needs to be applied somewhere in the operator stack. I don’t have a license to validate where it applies it but it feels logical to me that it would apply it after creative grading and before the DRT.

[nick (Nick Shaw)]

@jmgilbert

I don’t have a license to validate where it applies it but it feels logical to me that it would apply it after creative grading and before the DRT.

Baselight’s Scene Look is just another operator available to the colourist. So Baselight applies it wherever the colourist puts it in the grading stack.

[zachlewis]

If I’m following, I think by “Scene Look”, Jean-Michel is actually referring to the LUT-based “Core Looks” and “Modifier Looks” that ship with Baselight, whose relationship with the TCam2 DRT is analogous to ACES LMTs and the ACES Output Transforms.

for example:

[...creative grading operations...] ---> [C-201 Vision look] ---> [TCam2 DRT]

ACES doesn’t ship with a library of LMTs, but many ACES productions employ bespoke “Show LMTs” that serve a similar purpose. For example, in my world, a pipeline we often see:

[shot CDL] ---> [Show LMT] ---> [ACES OT]

[nick (Nick Shaw)]

@zachlewis

If I’m following, I think by “Scene Look”, Jean-Michel is actually referring to the LUT-based “Core Looks” and “Modifier Looks” that ship with Baselight, whose relationship with the TCam2 DRT is analogous to ACES LMTs and the ACES Output Transforms.

Yes, that’s what I am assuming. The operator I called “Scene Look” is actually just called “Look”. But my point is that it is not set up at a project level. It just goes in the grading stack wherever you put it.

[jmgilbert (Jean-Michel Gilbert)]

@zachlewis

``

ACES doesn’t ship with a library of LMTs, but many ACES productions employ bespoke “Show LMTs” that serve a similar purpose. For example, in my world, a pipeline we often see:

[shot CDL] ---> [Show LMT] ---> [ACES OT]

Yes that’s it. This is exactly the pipeline I was referring to when I was talking about creative grading and scene look right before DRT.

[jedsmith]

@meleshkevich

Is there any simple way, I (as a colorist, not a programmer) could bring those hue skews, that usually caused by S curve highlights tone-mapping, back?

It might not be easy to perfectly re-create the hue and saturation byproducts of the per-channel approach. Even if we did do this we would be right back where we started. If this exact behavior is desired it would probably be best just to use a per-channel display transform.

However there are definitely things we can do to emulate the components of the look that we like.

The first would be emulating the effects on saturation from the per-channel approach: reduced saturation in highlights and increased saturation in midtones and shadows. (See the discussions above).

The second would perhaps be emulating some components of the hue distortion that occurs where hues skew towards secondary colors. For example, an orange skewing towards yellow as exposure increases. Or a blue skewing towards magenta.

I’ve pushed a new tool in the look folder in my open-display-transform project for performing hue shifts. It’s really simple, based on the “notorious six” primaries and secondaries in RGB colorspace: RGB, CMY. Accordingly it is named “NotoriousSix_HueShift”. There is a nuke and resolve implementation.

The tool affects all colors regardless of luminance level, so if you want to add more hue shifts as luminance increases you may need to do this in your grading application.