Hello,
Haven’t followed in a while, too busy but here is what to expect from the HKE modelling of Hellwig and Fairchild (2022):
50% Luminance Reference RGB Stripe
J Lightness Correlate Set to 50%
J_{HK} Lightness Correlate Set to 50%
I think it is an improvement but there is still a discontinuity around pure blue.
The effect really applies automatically when using the J_{HK} or Q_{HK} correlates instead of J or Q.
Google Colab Notebook: Google Colab
Cheers,
Thomas
Minor update:
rev026 (only) OCIO configs now contain the inverse direction tranforms.
Still looking at the best way to handle it for Resolve and Baselight.
I found the issue in my workflow. It was not your sim LUT that was causing problems, it was one I was generating (incorrectly).
I’m seeing small overall saturation difference between SDR and HDR in v26. I’ll adjust that and try to get them a bit closer in a future version.
Alex,
here are exr files of frame0074 with Dolby at P3 and 2020, and without Dolby, and Rec709sim without Dolby for 024, 025, 026, and 026b. This link should give access to them in folder ACES2.
https://drive.google.com/drive/folders/1NwwL79gNcNRA9kmYDXE-cQm2y0MULzHV?usp=sharing
And yes, I was looking at them in Dolby 600nit P3 D65 ST.2084 Full(HOME) encoding.
I will also say that I may have had a workflow problem at beginning. I did a quick comparison with Dolby turned off and do see though that relative comparisons are still as reported above.
Ok, now we start over.
I think I now got the Rec2100_Rec709sim versions to work properly.
I am now looking at everything on Computer_1_HDR without Dolby, just PQ.
I have also found that even with calibration there are still differences with the displays.
One of the display issues gave the bad blue sky and water in frame0035.
Looking at the Rec2100_Rec709sim versions 024, 025, 026, 026b at the same time in split screen:
All four look consistent for the most part.
The blue chips get lighter from 24 to 26 to 25 to 26b [this differs from Rec2100]
Reds (0051_Coke & 0002_Campbell’s) are lighter in 025 and 026b, and seem better in 024 and 026.
[note: that Reds in 026 are only slightly darker than 024, unlike Rec2100]
The grey cards look a bit warmer in 026b than the other three which are close to each other.
Looking at the Rec2100 versions at the same time in split screen:
The blue chips get lighter from 26 to 24 to 25 to 26b [this differs from Rec709sim]
Reds (0051_Coke & 0002_Campbell’s) are lighter in 025 and 026b, and noticeably darkest in 026.
The reds in 026 are darkest of any, including Rec709sim
The grey cards look a bit warmer in 026b than the other three which are close to each other.
Comparing SDR to HDR is a bit tricky so what I did to help is adjust the Rec2100 groups by lowering gain and saturation a bit so as to generally match the respective Rec709sim.
Looking at all the groups in pairs, four and eight in split screen:
The darkest blue chips were from 024_Rec2100 and 026Rec-2100, and the slightly lightest from 025_Rec709sim and 026b_Rec709sim.
The darkest Red (Coke & Soup) was from 026_Rec2100, followed by 024_Rec2100, with the Red in 025_Rec709sim and 026b_Rec709sim the lightest.
The warmest grey card was from 026b_Rec2100.
Dark skin looked better in every Rec2100 pair, and best in 026_Rec2100, then 024Rec2100, then 026b_Rec2100 which started to show some redness but not as much as the others.
Lighter skin also seemed to have more redness in 026bRec2100
The Rec2100 groups were equally easy to grade so as to approximate the Rec709sim.
As to what might be best: Going on skin tone I would lean toward 026_Rec2100, but…
And as to what is best consistency for Rec709sim and Rec2100 together, by adjusting the temp of 026b_Rec2100 I could see 026b maybe being closest, but there are still the Red and Blue issues.
I started looking at what happens in the shadows in CAM DRT and discovered the following:
So I adjusted the gamut mapping compression parameters as follows. limit: 1.9, power: 1.8. All the following images have gamma adjusted to 7 in display linear to lift shadows.
Here’s a ramp with color before and after the parameter change:
I would assume the blue channel should, for best rendering, to smoothly hit the black point instead of clipping. It’s not perfect after the parameter change either. Before and after images follow:
Clear improvement and this is without any additional desaturation of blacks. I’ve started testing that as well but I don’t yet have a fully working solution.
Changing the compression parameters seems to have no effect in overall color rendering and only a small effect in images with pure colors. Blue lightens a bit.
Finally! For me this seems to be one of the most important improvements over ACES 1.x.
Curious to see the same comparison with more familiar images with skin tones and without raised gamma, to see how it preserves saturation in darker regions of a skin.
I probably missed something, but seems like .dctl inverse doesn’t work as it should. I mean inverse should go into IDT folder, but in this case it doesn’t look like an inverted S-curve that is expected (with the log csc on the other end of course), but almost like a horizontal line instead.
If I get it right, at first should be a LUT, and after that the conversion to Linear AP0, but it has the reversed order now.
I made pull request for @alexfry for v27. Also available in my fork. It brings the following:
Uses the “live from params” by default with the values set to new primaries that gets greens and yellows closer to Hellwig model (without Compress Mode), and improves blues. Blue gets lighter and the blue-magenta skew is reduced. Greens will get a bit darker and yellow/orange a bit more saturated.
Changes gamut mapping compression to use 1.7 for limit and 1.9 for power. This improves gamut mapping result especially in shadows, reducing the chance of skews. It does affect pure colors a bit, with blue and red getting a bit lighter.
Changes the shadow_boost control (inside the kernel) to automatically scale with peak luminance (affects SDR/HDR match)
The largest impact to color rendering comes from the new primaries. They skew especially greens more closer to where Hellwig model has them out of the box.
v27:
Yeah sorry, this got mentioned in the meeting, it’s nowhere in the readme.
The inverse transforms don’t do anything sensible in Resolve yet. Only Baselight and OCIO.
They
A: should live in the IDT folder, and
B: need to have their matrix and 1D pre luts inverted.
I’ll get to it in the next few days.
@meleshkevich I’ve updated the repo to now have proper inverse transforms for Resolve (Under the IDT subdir). Thanks to @nick for providing the DCTL structure.
Although I left my dongle a work, so if you’re able to give them a quick test that would be great.
Also added @priikone’s new v027, forward and inverse.
(Update: Forgot to hit save on the inverse DCTL template, updated repo, thanks @nick )
Thanks, Alex! It works as it should now!
I guess, these artifacts are coming from the implementation that uses LUT, and with the actual code it will be smoother?
It’s Inverse DRT to ACEScct to DRT
And regarding the DRT and reaching the edges of a display gamut, it’s still impossible (at least with the LUT implementation).
I haven’t checked that image recently but the current gamut mapping result is not entirely smooth. As for inverse it does invert Rec.709 display cube in and out. The question is whether the inversion is sensible in the working color space. One thing that the new gamut mapping compression params (in v27) do is that it increases compression, which will have negative impact for the inverse. Inverse will end up pushing values more outward. So I think the new params should be a temporary solution to the channel clipping in the shadows.
I doubt this stress testing is relevant at all, and for sure it is not something scientific, so this is just from a user perspective. I was curious how smooth is v27 in the highlights so I applied it to the image using ACES Transform with ACEScct set as input, and made the resulting image darker with gamma wheel.
Everything looks as expected for me, except for this region. It goes from the darker greens to the brighter, and then to the darker again.
Maybe this is what it should look like at the current stage of development, so I decided to mention it just in case.
Overall, V27 feels almost ready for the actual use in real projects. I’m talking about SDR only, don’t have an HDR display with the acceptable black and white levels.
I really like its “path-to-black”. Sometimes it behaves a bit unexpected, but adding RGC (in its default state) after all the grading and before DRT helps with those issues and the darkest regions become very nice and smooth.
But most important is that I can lower flare level now (with v27) without a need to constantly eyeball for the artifacts, that may become visible on some displays.
I have been looking at some smooth gradients, Grey, Resolve’s four color.
Concerning the most recent versions 026 and 027:
One thing I am noticing is that the versions for both 026 and 027,
Rec2100 (Rec709sim),
Rec2100 (P3D65 540nit limited),
Rec2100 (P3D65 1000nit limited),
all look to have banding, whereas the SDR Rec709 versions do not.
Also this banding is not noticeable (or very little if it is there) in previous versions 024, 025.
As to comparing the latest 026 and 027
Rec2100 (Rec709sim) vs Rec2100 (P3D65 540nit limited) [called HDR below]
as is with no grading, comparing 4 at a time in split screen:
027 might have an edge in overall look and matching, however there are still differences as the following:
0067(Isabela) - Both Rec709sim look to have a magenta cast in the shirt which seems to be closer to the intended blue in the HDR.
0005(trumpet player) - The dark skin and the Brass color look more real in the HDR than the Rec709sim. This seems to be a reddish tint in the Rec709sim.
0029(laundry) - All the colors vary in all four, but vary most between HDR and Rec709sim.
Also, another check using the two computers showed that the Rec2100(Rec709sim) and SDR Rec709 were fairly close for 0026 and 0027.
As to the inverse for both 026 and 027 with Rec2100 (Rec709sim), Rec2100 (P3D65 540nit limited) and Rec2100 (P3D65 1000nit limited):
Setting up a node with each of the six variations and then turning it on and off showed differences which would indicate that the inverse is not an exact inverse or there is some clipping somewhere.
Testing SDR/HDR match of v27, which I think is closer than older versions, I think I’ve noticed couple things related to the tonescale. I’m noticing that the lifting the middle gray from 100 nits to 1000 nits is maybe a bit too much. It’s a nit higher than where Jed’s original curve had it (though it matches ACES 1). Another thing I’m noticing is that shadows feel lifted in HDR in most images. I think the “flare” we have for 1000 nits is a bit too much compared to 100 nits. Ideally we’d have an offset control for flare but it’s currently driven mostly by the w_g. Higher the middle grey offset is more it lifts also the shadows.
The best compromise I was able to find is to lower w_g to 0.12 or 0.125 from the current 0.14. That brings the middle gray for 1000 nits where it was in Jed’s curve and lowers a bit the amount of lift in the shadows in HDR (SDR doesn’t change). To my eye it improves the match between the transforms, though I’d still like the lift to be less. I’m not necessarily suggesting that we change the tonescale anymore, this is more of a report of my testing.
When I look at v27 on my LG C1 48" OLED (admittedly not a reference monitor) I do not see any more shadow detail at 1000 nits than I do at 100. What monitor are you looking at @priikone? Is it possible that your monitor has some clipping at the bottom end, and simply lifting the mid grey point to 15 nits from 10 is raising some of the shadow detail out of the range that your monitor is clamping?
On a separate subject, I was thinking more about the discussion in last night’s meeting about gamut compression inverting Rec.709 to values outside AP1. It seems to me that this is an inevitable consequence of having a gamut compression in the DRT capable of bringing out of gamut values like those in Blue Bar to within the display gamut. Inevitably an inverse of this DRT is going to map values near the display gamut to extreme out of gamut values like those in Blue Bar.
For the same reason that it is hard (or impossible) for standard grading tools to bring those out of gamut values into AP1 (hence the need for the RGC) it is hard (or impossible) for those same tools to grade AP1 values to the extremes needed to render to the display boundary through the DRT.
So I come back to the thought I expressed in the meeting, that perhaps it is better to lean on the RGC to ensure that all values are within AP1 before the DRT. Then the DRT can have a less aggressive gamut compression, that only needs to map AP1 to the display gamut. This also means that colourists should be able to more easily hit the display gamut boundary, while grading positive AP1 values (and perhaps, where necessary, the small amount of negative range available in 0-1 ACEScct).
I obviously don’t have HDR reference monitor either. I’m using Samsung’s quantum dot OLED (S95B). I wanted something that isn’t WOLED. Actually I found I had PQ boost enabled unintentionally. I disabled that and re-did the test, this time in very dim room, and I’m much happier with it. Obviously things lift as exposure is changed, so in the end it depends on what one considers shadows. Blacks definitely are not lifted, AFAICS. We need someone with reference monitor to give the final verdict. Thanks for testing this, Nick. How did you find the match?
I’m still hopeful that inverse can be improved. I’ve been playing with a version of the chroma compression that addresses also shadows (which the current one doesn’t enough) so that the gamut mapper wouldn’t need to use as much compression as in v27 to deal with the channel clipping. It’s not ready yet, but it brings the inverse back to around what it was with v26 compression values (with the v27 primaries), and even improves the clipping issue from v27. The primaries seem to have very large impact as well…
My heuristic on invertibility:
If something in the pipeline is perfectly invertible without any consequences it does not move you forward in the pipeline.
I get what you are saying. But my point goes beyond invertibility.
Ignoring inversion, if a DRT maps a crazy out of gamut value to the display gamut boundary, then if you need to place a value on the display gamut boundary in grading, you need to push it to that same crazy out of gamut value. Traditional grading tools don’t generally have the ability to do that.
