I’ve updated the LUT repo with some 3 new versions:
- rev025 - CAM_DRT_v025.blink with HK_mode_in enabled
- rev026 - CAM_DRT_v026.blink with HK_mode_in disabled
- rev026b - CAM_DRT_v026.blink with HK_mode_in enabled
2 Likes
Yeah, I’m not totally convinced myself that this is the right move either.
I’m curious what you mean here.
“groundtruth” as in a different digital rendering of the same pixels? Or the real subject physically in front of you?
Images graded to match. But I do have colorchecker as well as a colorful bookshelf, so I could do live experiments…
1 Like
I too think that the effect of the HK boost is a little too much when used only on the way in, although it makes logical sense to me that it should only be used there. I’ve been playing with a modified version of the (v25) Blink where I have an additional parameter to scale the size of the HK modification. Totally non scientific, but splitting the difference between with and without it sits things in a comfortable place to my eyes.
It occurs to me that we might benefit from something similar for other aspects, like surround compensation, as the default change in the CAM is rather dramatic. It has been noted before that while a large modification may be appropriate to create an appearance match with solid colours, something smaller may be more appropriate for images.
On the question of when to apply H-K, conceptually we need to determine if we are trying to model a virtual device appearance, or if we want to model real life appearance, or both, i.e. do we expect to model the appearance at the known display intensity, and thus we may expect the modelling to need to know the absolute luminance to correctly calculate the effect, per output transform. That would suggest we should apply the effect once, in an unconstrained sense before applying gamut compression, etc, though obviously the application of the gamut compression plays with the effect.
I came across some more papers on H-K thought this one might be interesting - though not directly applicable to us
2 Likes
I downloaded during the meeting last night the new configs and just checked the three versions with the A fully red star on a fully cyan background... in ACES - #12 by TooDee image once again in Nuke. Here is the file just in case. (HiDrive)
I just added a Blur Node with a value of 100 and viewed the result with three different OCIO configs (all only for Display P3 on an iMac27").
This is a strange “client logo” with ACEScg primaries 
example.
I rendered out 4 jpgs with Rec.709 plus one display P3 screenshot from Nuke:
ACES 1.2 - Rec709 (halo as expected)
CAMDRT v025 - Rec.709 (a new dark halo)
CAMDRT v025 - Rec.709 (a new dark halo) screenshot - the P3 viewer shows me a different result
CAMDRT v026 - Rec.709 (no halo! dark or bright!)
CAMDRT v026b - Rec.709 (a new dark halo slightly different to v025)
I don’t what to make of it, but I am happy that v026 can render this unusual image without any dark or bright halos.
Maybe @priikone can explain why this suddenly works?
Thanks
Daniel
2 Likes
Not sure, probably by luck. It’s interesting input:
Exposure +2:
Exposure -2:
I would assume it’s the transition from red to cyan that causes the gray-ish band. in 3D (exposure -1):
1 Like
Here’s the red star with HK_mode_in enabled. Something’s fishy for sure with the HK mode:
That’s the reason for that strange gray band in v25. Same thing happens even if HK_mode_out is also enabled.
EDIT: same thing happens also in v24 with the “old” HK mode enabled. HK mode seems to do something near the achromatic axis.
It also shows that the question of bright band or dark band is the question of how reds transition to cyans through the achromatic and how close is the brightness of red and cyan near the achromatic. No idea what is perceptually correct, though.
2 Likes
Makes me think we need some ramp images from primary to complementary colours for the other channels too,
1 Like
Hmm, interesting.
As M is increasing, it’s boosting J.
Not attractive at all…
Hi Kevin,
here there are - all in one file - viewed here only through the EOTF (sRGB).
https://my.hidrive.com/lnk/OP0rFwEm
And the results with v026. The blue/yellow star gets a strange line in the transition area.
I can’t seem to reproduce that. Did you use LUT?
Hi Pekka,
yes, I use the OCIO.config. Maybe this is a limitation of the LUT?
Observations on ACES 2 candidates version 024, 025, 026, 026b
DaVinci Resolve 18.1.1
Using B: Stock DaVinci YRGB project with manual ACES node
Computer 1 - HDR
AMD Threadripper 1950X, Radeon Pro WX8200 GPU, Windows10 64-bit with display LG OLED55C8PCA via BMD DeckLink 4K Extreme 12G
Computer 2 - SDR
Intel Xenon E5-2650, FirePro W8100 GPU, Windows10 64-bit with ASUS ProArt Monitor calibrated to Rec.709 via Decklink Mini Monitor 4K
HDR Comparisons using:
rev 024 Rec2100
rev 026 Rec2100 (P3D65 1000nit limit)
rev 025 Rec2100
rev 026b Rec2100 (P3D65 1000nit limit)
rev 024 Rec2100 (Rec709 sim)
rev 026 Rec2100 (Rec709 sim)
SDR Comparisons using:
rev 024 Rec709
rev 026 Rec709
rev 025 Rec709
rev 026b Rec709
Rec709 (ACES1.3)
ISSUE 1:
For HDR I did not like the images with the suggested Resolve settings so I modified as follows:
Enabled Dolby Vision
ver 4.0
1000-nit, P3, D65, ST.2084, Full
Target Display Output at 600-nit, P3, D65, ST.2084, Full(HOME)
Analyzed all the images
Enabled Tone Mapping Preview
This gave a much better looking image.
The Rec709_sim versions looked to dark and were difficult to lighten.
ISSUE 2:
It felt as if 24 and 26 were nicer than 25 and 26b due to some hues being brighter in 25 and 26b.
I suspect that not only does the variation in the amount of brightness vary by hue, but also by saturation with higher saturation being brightened more.
To investigate this further I added nodes before and after the ODT node in which I used the RGB mixer to select monochrome.
These nodes were controlled by a three node binary switch. (Color Generator set Black, Invert, Invert with outputs of the Inverts to the mask inputs of the before and after B&W nodes.)
All the comparisons listed above were checked with the before B&W node which showed identical results, as was expected.
Then comparisons were made with B&W before and after for each listed and then between each other with the after B&W nodes on.
The variations are readily apparent using frame 0074.
All the after node B&W images varied with none even close to that of the ACES1.3 Rec709.
But, to some degree, this was to be expected as the apparent luminosity is going to vary from the actual luminosity. But I did use the RGB mixer for that reason.
But which is closest to reality, or actually apparent reality?
ISSUE 3:
The saturation of Yellow seemed a bit less than the other colors, especially when looking at the various charts in the sample images.
This was most apparent in SDR and very little to not in HDR.
ISSUE 4:
There is a difference of HDR and SDR as to changes in saturation values for various revisions.
In SDR the saturation, in general, reduces from 024 to 026 and from 025 to 026b.
In HDR the saturation, in general, reduces from 026 to 024 and from 026b to 025, the reverse of the SDR.
(as seen in the vector scopes)
ISSUE 5:
This issue is difficult because of comparing between two monitors and systems.
This issue involves darker skin.
I took into account variations seen in frame 0067 (Isabela) between HDR and SDR which were a close match.
The lighter skins in other frames looked to be a good relative match.
The darker skins looked to be a good brown color in HDR, but in SDR seemed to have a reddish hue.
(example frames 0005, 0073, 0074)
As a check on this I compared rev_024_Rec2100 with rev_024_Rec2100_(Rec709sim) on the HDR system as well as rev_026_Rec2100_ (P3D65 1000nit limit) with rev_026_Rec2100_(Rec709sim) and found similar results in that the Rec709sim had the more reddish hue in dark skin. Also in HDR, rev_0024 and rev_0026 differed in that the rev_026 HDR shows some reddishness but far less than SDR. In SDR all revisions showed the same amount of reddishness. (Note also that the Rec709sim versions had lower exposure which could have influenced color.)
ISSUE 6:
While the SDR images look to be an improvement over ACES1.3, I feel something not right with the HDR.
If I had to pick one thing I would say contrast of the lighting looks harsh, which is just the opposite of what HDR should provide.
Something is just not working as the SDR images look better. (image 0029 is one example of many)
And again I also checked this with the Rec709sim revisions all on HDR computer 1.
QUESTION:
Since there seems to be issues with perceptual luminance values for various hues and saturation, could a color model like OKlab help? or has this already been considered?
I have used this model successfully to get nice control of hue and saturation and perceived lightness.
Also note how OKlab handles the presentation of gradients.
COMMENTS:
I find the other work being done using the gradients interesting.
I don’t see SDR and HDR as working together yet with these revisions and intend to try more HDR grading.
2 Likes
Jeffrey, it would be useful if you could summarize how each revision compared to same revision in SDR vs HDR, for example, v26 SDR vs v26 HDR, in terms of appearance match, and then your opinion which revision had best overall SDR vs HDR match.
I never seem to get consistent result with rec.709 sim, so I don’t use it. I don’t know what’s up with the rec.709 sim.
Last summer I made Oklab based prototype DRT, OkishDRT, available at: GitHub - priikone/aces-display-transforms: Prototype ACES display rendering transforms
2 Likes
I’m curious to know more about what everyone is seeing with “Rec2100 (Rec709 sim)” Transform.
It’s been created through a pretty simple and non controversial setup:
- Render through the stock Rec709 transform
- Invert Gamma 2.4 encoding
- 3x3 matrix to convert from Rec709 primaries to Rec2020 primaries
- Multiply by 100 to place SDR 1.0 at 100nits
- Encode with PQ/ST.2084 curve
In my testing side by side with an SDR and a static HDR screen, I get a totally clean match.
If there additional tonemappers in play, especiually a dynamic one, the results are going to be unpredictable.
SDR vs HDR
only some of the images are compared as listed below
only difference of SDR vs HDR noted, sometimes both could be off
no comment means SDR and HDR where fairly close with HDR also doing what is expected
HDR used Dolby Vision as described in my last post.
++ ver024 ++
0001
0002
0004 SDR is more reddish, everyone
0005 HDR skin looks like real brown skin, SDR skin looks a bit orange-red
0024 HDR has much better shadows, shadows blocked in SDR
0029 HDR looks a bit harsh throughout image
0030 HDR looks a bit harsh, especially on lighting
0031 SDR skin a bit more orange (but could be that has more saturation than HDR)
0035 SDR sky and water blue looks fake, HDR looks natural
0051 skin looks better in HDR, to red in SDR
0052
0054 SDR has a bit more saturation overall
0058 SDR is more green, HDR yellowish
0061 HDR has more color in the brighter spheres, as to be expected
0062
0067 HDR shirt is a bit magenta, SDR shirt is power blue…ARRI blue is lighter in SDR… on chart the bottom 2 blues are more towards green in SDR (the corner one not as much) (and SDR has a bit more overall saturation)
0071
0073 the teal box on the chart (above black) is slightly toward green… dark skin is reddish in SDR, looks good in HDR, light skin a bit toward orange in SDR but could pass
0074 bricks are mud in SDR, dark skin reddish in SDR and great brown in HDR… interesting the the DuMonde seems rather close (maybe some saturation differences)
++ ver026 ++
0001
0002
0004 SDR is more reddish, everyone
0005 HDR skin looks like real brown skin, SDR skin looks a bit orange-red
0024 HDR has much better shadows, shadows blocked in SDR
0029 HDR looks a bit harsh throughout image
0030 HDR looks a bit harsh around highlights
0031 SDR skin slight more orange (but could be that has more saturation than HDR)
0035 SDR sky and water blue looks fake, HDR looks natural
0051 skin looks better in HDR, to red in SDR
0052
0054 SDR has a bit more saturation overall
0058 SDR is more green, HDR yellowish
0061 HDR has more color in the brighter spheres, as to be expected
0062
0067 HDR shirt is a bit magenta, SDR shirt is power blue…ARRI blue is lighter in SDR… on chart the bottom 2 blues are more towards green in SDR (the corner one not as much) (and SDR has a bit more overall saturation)
0071
0073 the teal box on the chart (above black) is slightly toward green… dark skin is reddish in SDR, looks good in HDR, light skin a bit toward orange in SDR but could pass
0074 bricks are mud in SDR, dark skin reddish in SDR and great brown in HDR… interesting the the DuMonde seems rather close (maybe some saturation differences)
Yes, ver0024 and 0026 even though they differ they do so the same for SDR or HDR
ver025
0001
0002 Campbell’s Red looks a bit light in SDR
0004 SDR is more redish, everyone
0005 HDR skin looks like real brown skin, SDR skin looks a bit orange-red
0024 HDR has much better shadows
0029 HDR looks a bit harsh throughout image
0030 HDR looks a bit harsh, especially in brighter areas
0031 SDR skin a bit more orange (but could be that has more saturation than HDR)
0035 SDR sky and water blue looks fake (not as bad as in 024), HDR looks natural
0051 skin looks better in HDR, to red in SDR
0052
0054 SDR has a bit more saturation overall
0058 SDR is more green, HDR yellowish
0061 HDR has more color in the brighter spheres, as to be expected… the three pinks in SDR are closer together in hue
0062 Red areas are lighter in SDR not looking balanced
0067 HDR shirt is a bit magenta, SDR shirt is power blue… on chart the bottom 2 blues are more towards green in SDR (the corner one not as much) (and SDR has a bit more overall saturation)
0071 just what HDR does
0073 the teal box on the chart (above black) is slightly toward green… dark skin is reddish in SDR, looks good in HDR, light skin a bit toward orange in SDR but could pass
0074 bricks are mud in SDR, dark skin reddish in SDR and great brown in HDR… interesting the the DuMonde seems rather close (maybe some saturation differences)
ver026b
0001
0002 Campbell’s Red looks a bit light in SDR
0004 SDR is more reddish in dark skin but not as much in lighter skins
0005 HDR skin looks like real brown skin, SDR skin looks a bit orange-red. but lesser than other versions
0024 HDR has much better shadows
0029 HDR looks a bit harsh throughout image
0030 HDR looks a bit harsh, especially in brighter areas
0031 SDR looks brighter overall (too bright)
0035 SDR sky and water blue looks fake (not as bad as in 024), HDR looks natural
0051 skin looks better in HDR, to red in SDR
0052 pinks may differ a bit but neither is better
0054 Red truck is lighter in SDR… SDR has a bit more saturation overall
0058 SDR is more green, HDR yellowish
0061 HDR has more color in the brighter spheres, as to be expected… the three pinks in SDR are closer together in hue
0062 Red areas are lighter in SDR not looking balanced
0067 HDR shirt is a bit magenta, SDR shirt is power blue… on chart the bottom 2 blues are more towards green in SDR (the corner one not as much) (and SDR has a bit more overall saturation)
0071 just what HDR does
0073 the teal box on the chart (above black) is slightly toward green… dark skin is reddish in SDR, looks good in HDR
0074 bricks are mud in SDR, dark skin reddish in SDR and great brown in HDR… interesting the the DuMonde seems rather close (maybe some saturation differences)
If the descriptions are repeated or similar it is because there are many consistent differences between SDR and HDR.
Differences are also found version to version, but that is not the comparison here.
I think there are issues with each version in the comparison of SDR vs HDR and many consistencies.
I would say that the versions are equally bad as far as being a good match of SDR and HDR, and they do this consistently. Although do note that I mentioned some inconsistencies between versions such as in ISSUE 4 in previous post.
As to the Rec709sim:
Alex, yes I did run those with additional tone mapping. I had trouble getting the HDR to look good until using Dolby Vision as in my last post. I will try them out without it, just plain.
@jeffrey.d.mathias Are you able to render out some images after they have passed through the DolbyVision step?
Just trying to get a clearer understanding of what you’re seeing.
I’m also a little unclear about this bit.
Are you manually remapping from the Rec2020 primaries that the example LUTs are transforming to, down to the P3 D65 encoding the Dolby Vision system us expecting in?
Whilst ACES2 Candidate CAMDRT rev026 Rec2100 (P3D65 1000nit Limited).dctl is gamut limited to P3 primaries, those values are sitting within a Rec2020 primary container.
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
3 Likes