Thank you! It looks almost correct now. I think I found one more thing.
There is something with primaries I guess. Maybe different chromatic adaptation, I don’t know. It’s different if I transform Alexa to ACES AP0 Linear (either with ACES Transform or Color Space Transform) and then add OpenDRT with ACES input, compared to just setting alexa as input in OpenDRT.
And I found a possible bug with ACES 1.2 (or just with Resolve implementation of it). If I go from Alexa to ACES using ACES Transform and then go back from ACES to csc Alexa, I get similar but not identical image. I mention this just in case. Maybe this is the reason.
By the way, I really like how it deals with those artifacts in the shadows with default ACES rec709 ODT, that can be seen after making image brighter with gamma operation.
I’m working on a music video right now. It has a lot of old VHS footage. So I use your awesome DRT in this project as inverse ODT to go from rec709 source to ACEScct. And then as a usual display rendering transform in the end.
This footage has gigantic colorful square blocks after compression. And it was a nightmare with default ACES rec709 ODT, if I tried to clip an image into the shadows in ACEScct. So I usually use k1s1 LUT based LUT as my ODT. But now I just changed this LUT to OpenDRT in the middle of the grading session
Yes I believe the difference you are seeing here is because of the different chromatic adaptation methods.
Path A (Arri LogC | Alexa Wide Gamut | D65 → Linear | ACES 2065-1 AP0 | D60 → OpenDRT) includes whatever chromatic adaptation method the resolve colorspace conversion node uses when converting alexa wide gamut to ACES AP0, and then a further chromatic adaptation performed in the OpenDRT node to convert input D60 whitepoint to output D65 whitepoint. OpenDRT uses scaling in Truelight LMS colorspace to perform chromatic adaptation.
Path B (Arri LogC | Alexa Wide Gamut | D65 → OpenDRT) has no chromatic adaptation performed because input whitepoint matches output whitepoint.
Very cool! Super curious to hear how this works out for you. Any and all feedback welcome
Just tested it with a lot of raw footage. From creative point of view, and I know that it is not what’s the goal of the new DRT, - it looks less “cinematic” than k1s1, or current ACES RRT+ODT, or DaVinci tone mapper. And I have no idea how could I emulate the same behavior as a part of the look built under OpenDRT. I’m talking about nice effect on hue and saturation after S-curve highlights soft clip. So I hope there is a way to make somehow a good standard LMT, that could emulate this behavior and make it without any artifacts.
And for all the shots I’ve tested it with it looks better for me with perceptual dechroma turned on. Especially for the shot with bonfire at night. Otherwise it looks pink.
But since OpenDRT is not about artistic decisions, here are some artifacts I found. But probably it’s a too early stage of development to search for these artifacts. So I just wrote down everything I found just in case.
Noticeable transition from saturated highlights to clipped highlights. It can be hidden with stronger hi dechroma slider, but skin tone becomes too desaturated then.
In the darkest shadows blue becomes magenta before it clips into pure black. It can be visible after making image brighter with gamma. But at first I noticed it on a real footage, and only after that I checked it with LUT Stress Test image. This can be fixed with new gamut compressor applied before DRT though.
I’ve also made some stills with another display rendering tools, for comparison (and with brighter gamma as well). All the tools have AP1 ACEScct on their input and Rec709 on their output.
With perceptual dechroma turned on, there are artifacts in the shadows. It’s easier to inspect them with brighter gamma again. But even without it you can find a bright red dot in the shadows. And if I move hi dechroma slider to 0.0, they become way more visible.
RGB weights to zero gives you a zero length vector which cause a division by zero which in turn cause all values to go to infinity. Infinity is usually displayed as max value after clamping.
@jedsmith Is it intentional that defaults in params version are different compared to a regular OpenDRT version? Which one has “better” settings?
Thank you!
Hey @meleshkevich – The defaults in OpenDRT_params.dctl are approximately equivalent to the Rec.1886: 2.4 Power | Rec.709 preset. Unless you know what you are doing and want to experiment with the tonescale model, rgb weights, or other settings, I would strongly recommend that you do not use the _params version. OpenDRT is not a grading tool. The purpose is to provide a sensible and predictable set of defaults for rendering scene-referred images for different viewing conditions, which provides a good starting place for grading. Hope that helps. I am working on documentation that explains all this stuff… it just takes a lot of time
@jedsmith
Hi!
Could you please tell me if it works as it should?
Looks like OpenDRT DCDM Inverse ODT kills yellow colors.
At first there is Cineon to DCI XYZ 2383 LUT.
Then white point creative adjustment with simple gain applied over tonemapped image.
Then there are ACES 1.2 DCDM Inverse ODT and ACES 1.2 Rec709 ODT. Which gives a common figure on vectorscope for print film LUTs. So we got Cineon input and Rec709 output.
But with OpenDRT DCDM Inverse ODT yellow colors are gone. Actually they are gone after IDT stage with DCDM Inverse ODT. So OpenDRT Rec709 ODT there is just for comparison.
I am not sure I understand well what you are trying to do. So I will just respond with things that I do understand to be true.
Forward display transform + inverse display transform should yield something approximating a null-operation. The inverse will never be perfect because of the limitations of the display gamut volume.
There was a bug in a previous release with the inverse direction, so if you haven’t tried it maybe use the latest commit and see if it helps.
I don’t know what the input is to the inverse display transform, but based on your nodegraph I would raise my eyebrows and proceed with extreme caution. Inverting some display referred image into sensible scene-linear image data is non-trivial and dangerous in this human’s opinion.
The lenscap black checkbox (which I have since removed thinking it is another bad idea) adds a small value to the input image in order to compensate for shadow grain below zero. Since OpenDRT maps input zero to output zero, this can be problematic for digital cinema camera footage which subtracts lenscap black average value from the frame on debayer. I removed it because my checkbox is not sufficient to solve this problem. It is something that a colorist should manage.
If you are designing some transform to go in the inverse direction, mapping some display-referred input imagery to some scene-referred output, I would only say that yes it is important to map zero values correctly.
100% behind that. The DRT’s main job is to give a — ideally low or very low contrast — reasonable starting point for grading and to not break down on specific hues, specific luminance levels and when switching output targets. The first part of this last requirement is to avoid the need of informally shared fix LMTs (I am looking at you blue highlight fix*) and the last part is to avoid per-target display-referred trim passes for workflows where that isn’t an option (like game engines) at all or in part.
*Other examples would be forced Hue vs Hue, Hue vs Lum and Hue vs Sat nodes before the DRT
Thanks! Looks better now, but I still get solid black colors here and there even if I try to use it with the image that has rec709 gamut only (converted to DCI XYZ) and doesn’t even touch blacks or whites. So for me this still looks like something is probably wrong with this inverse ODT.
But I found another thing. Looks like DCDM ODT has 2.4 gamma, not 2.6. Is it on purpose?
And if you don’t mind, I’d also like to ask you how is it going with OpenDRT progress? Is it more or less looks like ACES 2.0 will look or there is still a lot to be done and changed?
and what about Nayatani_HK? If it compensates the effect that should always be compensated, why not to put it in ODT (or OpenDRT?) also? Or this was just an experiment?
I would really like to test something new if there is anything new in DCTL format
Hm, that’s weird. I double-checked in the last version of my DCTL and I’m pretty sure it’s using a pure 2.6 power function for all DCI output presets including DCDM X’Y’Z’ – Can you give any more details for a reproduction?
It’s going well thanks open-display-transform is an experimental project I work in during my decreasing quantities of spare time. I have lots of ideas to test and experiments to do. I have been working on quite a few things lately. I’ll have a few posts coming up.
I recently pushed a few changes for an upcoming opendrt v0.0.90 release, simplifying tonescale and doing some experiments with different approaches for gamut compression.
I have no idea what ACES 2.0 will be. Based on the sentiment in the preceding vwg meetings, it’s sounding like it will be the same as ACES 1.2 but with a slightly reduced contrast for SDR outputs.
As for HK compensation it’s an interesting experiment but I don’t think the model makes sense to include in a display transform. HK describes a perceptual phenomena. The sensation of certain hues appear brighter to our eyes than the stimulus would indicate. Since a display transform maps one stimulus to another stimulus under different viewing conditions, perhaps there should be compensation for the different behaviors of the human visual system between the two viewing conditions. What roles HK plays in the differences here is unclear to me and I’m not sure that this model represents that well.
I just used it over linear gray gradient. Input was set to acescct. Waveform analyzer showed up a change in whitepoint with dci d65 output preset.
The same way I was judging gamma difference. DCI preset make curve “brighter” than 1886 preset. But DCDM (and even probably dci d65/d60) showed up the same curve (despite the different white point of course) as 1886 preset.
Great! Will check it out soon!
Oh, I was sure (and still hope) openDRT will be ACES 2.0 DRT but with slightly tweaked parameters.
What I really don’t like in current ACES DRT is how it clips saturated colors in the shadows. Still have no idea how to fix it in grading. And it’s noticable even by eye on oled screens or on inverse sRGB EOTF displays with rec709 ODT. (And just for statistics: I’m from power law 2.2 gamma club, all sRGB EOTF screens are evil )
Gosh it would be a shame to not have all of the good chroma stuff openDRT is doing I wonder if there was an LMT for OpenDRT that emulated ACES 1.2 if that would shift the tides?
)
I wonder if there was an LMT for OpenDRT that emulated ACES 1.2 if that would shift the tides?