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.
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:
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.
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.
I’ve been experimenting with this tool for a while, and want to suggest that a ZoneHueShift would be a really helpful addition. That is, I’m finding that I want to apply these hue shifts in the highlighlights, but do not necessarily want them to affect midtones or shadows.
Forgot to mention in https://community.acescentral.com/t/other-drts-as-real-lmts-in-aces-1-3/3891/3 that I also pushed in bunch of small LMT tools for Nuke I used with the LMT creation. There’s tools with similar capabilities (in RGB and HSV with luminance and/or saturation masks). Can’t take credit for all the tools, I put many of them together from what others have done.
Here’s some test images comparing ACES, OpenDRT with a linearGrade (contrast 1.25), and a “look” consisting the the same linearGrade plus ZoneSat and HueShift.
What I’ trying to do is skew pink to yellow in the highlights, not quite as much as ACES currently does, but attempting to emulate how sunshine appears to my eyes, especially in the highlights.
The reason for the desire for the control of this affecting highlights, mids, and shadows is that I don’t want that to effect the yellows on these lego guys or to affect skin tones. I’m getting it to look pretty good below, but its very sensitive currently, like angels on the head of a pin, trying to find a setting that works for the whole image.
A second thing I’m doing with the ZoneSat is getting skin to not look so “colorized” and flat, by boosting the saturation in the shadows and lowering it in the midtones.
Thank you!
Could you please check if NotoriousSix_HueShift.dctl works in Resolve? I’ve placed libDTColorMath.h into the same folder, but the sliders don’t change the image. And my friend also confirmed this on his PC.
And about OpenDRT - I still get non-neutral white point with P3-D65 preset
Also I’ve noticed you updated linear grade DCTL. And you removed linear extension and preserve chroma. If you don’t mind, I’ll give some feedback about it. I found linear extension option REALLY useful (at least for a per shot tool, not sure about the global look tool). And preserve chroma is also great! Way more accurate than Resolve new HDR pallete contrast knob.
But it produces artifacts if there is any signal below 0. So I’ve added low end hard clip into the code. But… it clips values below 0
And also what I would add (if I could) - is not preserving of saturation in the darkest parts of the image, where is basically just the noise.
I’ve also added RGB gain sliders and Temp and Tint sliders (actually just a R,G,B gains with different multipliers, not the correctly constrained kelvin slider).
And I tried to add to and from cat02 matrix for white balance gain sliders, but I have absolutely no skills in programming, so I left these in the previous and the next nodes. This is of course not the case for a look tool, but I modified it for use after IDT and before Gamut compressor (and that’s why I decided to remove the hard clip, I’ve added earlier).
Please don’t think of it like I just wrote down you a feature request. You for sure know what to do way better than me. I just wanted to share my thoughts. And thanks again for all the great tools you make!
I have a stupid question. What is a working space for NotoriousSix_HueShift?
Or, probably, what is the working encoding curve if any? I guess, primaries can be anything here?
Oh boy new toys! Looking forward to playing with it!
I recall you were working on a ZoneGrade tool. Did anything come of that? I wonder if the method you are using for the zone on the hueShift would work on the linearGrade?
The saturation and luminance masks are actually the S and V from HSV of the input image. I’ve used this in ACEScct so the masks represent in that case saturation and luminance from the ACEScct values. In Luminance mask 0.56 in ACEScct is already above 1.0 in linear so choosing a range that covers highlights is easy. It gets more tedious if you want to cover some specific range in mid tones for example. I haven’t found the “Luminance and Saturation” mask useful but the “Luminance then Saturation” has been convenient. Like being able to choose highlights but only colors that aren’t very saturated. For example:
Anyways, this is how I chose to do it and it was mostly ok for what I wanted to do. At times I was hoping for a “slider” approach to just quickly choose a range/zone…
Good question, yes I should have specified. The working space is linear RGB. So if your working space is some log encoding, you will need to linearize before this node and invert after. Perhaps I should make an “input curve” knob for this one as well. The algorithm for the hue shift is dumb as rocks, just shifting intensity from one channel to another (but even though it’s dumb it’s pretty robust and works pretty well, at least with the images i’ve tested it on). So yeah it will work in whatever tristimulus encoding your input is, theoretically.
When I move red to yellow in highlights to make skintone look I want, saturated red objects become orange before l reach the desired hue shift in skintone.
Here is the example of what I mentioned above. Red patches on saturation chart become orange, when I make the skin tone hue shift I want.
Zoned checkbox is active, zone range slider is 1.15 position and red slider is 0.313.
(By the way, I just noticed that Firefox bakes ICC display calibration result into the uploading images, so I had to change system ICC profile to sRGB, so it could upload the images as is)
Resolve Lum vs Sat curve always uses rec709 luminance weights for saturation (or at least the same as a regular saturation knob). So this kind of desaturation makes colors darker, when it’s applied to a log encoded image. Or it’s not a big deal when we are talking about desaturation of the highlights only?
UPD.
Replaced the second still and changed settings of the DCTL. Now zone range slider is set to select skin tone highlights only, but the red patches are still affected.
One thing I note about the tool like the Tetra_HSV_Masked is that it’s really easy to push colors out of gamut with that. That can be avoided with the masks but it’s something to be aware of. Dunno about the Jed’s tool, I haven’t tested yet.
Another thing to note about the chart in that image is that it’s the CML Stress Test Chart which has the most saturated colors on the top row DSC Labs were able to print (that was Geoff Boyle’s request), and they are much more saturated (at least the red) than any other color target, AFAIK. So issues with very saturated surface colors show up in that chart first. The red in the macbeth chart gets more orange too so I assume that’s the change you’re making…
Have you tried with RRT+ODT and see what happens? I’ve noticed that OpenDRT starts to desaturate earlier than I would like, and perhaps doesn’t move towards white as aggressive as I would like, and the color that desaturates “first” is yellow. I think this is in part because of the RGB weighting used, but perhaps also the dechroma “shape” itself. I’m not sure, I don’t feel like I know enough to know what exactly to say. But I seem to find the current dechroma being the culprit for most of the issues I see. I wish there were more options to tweak how the dechroma works…
This is also what I don’t want to get. So I would like to have a way to exclude high saturated colors.
You’re talking about the current ACES 1.2-1.3 display rendering? There already are these hue skews with skin tone, my clients expect from me.
This is also what I think could be tweaked somehow better. I get noticeable transition from very bright colors to the clipped solid white. I guess this is something about preserving saturation in the brightest highlights.
The sky changes but the red on the car is unchanged, which is exactly what I was desiring. Yay! FWIW, to get this to work I changed the zone range from 0 to 1. With it set to the default of zero I was getting hue shifts in the car and other darker parts of the image.
Then OpenDRT with the same linearGrade as always. Note how the face looks flat and “colorized” without tonality. I’m struggling with the vocab here, but a picture is worth a thousand words…
You can see that same “shine” in the ACES image if you carousel through the images. I did this by creating a luminance mask to affect mid-tones and raising the gain a bit. I’m not at all convinced that this is the best way to do this, and it’s a very crude implementation, but hopefully it illustrates the desired affect of getting skin to look less flat, and have more “shine” to it.
