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?
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.
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.
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.
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.
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?
I always thought grading LMT IS actually a look (typically a LUT). Could you please explain me the difference?
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.
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.
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?
:
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.
