Starting to work up some tooling to create plots in JMh space.
J: is collapsed
M: is 0>100 from the center
h: is radial with 0 at the top
Outer hull is AP1, inner is 709.
Connections lines show the path AP1 values take towards the 709 boundry, as seen in JMh space.
In theory a straight projection towards the center of the image would represent perceptual hue preservation, while off angles represent a ‘hue skew’.
Whilst the CAM based compression approach looks more like this:
OK, I’ve added a Visualise_Mh node to the repo:
The center is neutral, with M radiating out around 360 degress.
Adjust the edgeZoom control to see more or less of the M range.
Might be useful to people?
I’ve rendered out a bunch of images through the CAM_DRT v023, with Yxy and Mh, before (top) and after (bottom).
On thing that’s interesting to me is how some images with lots of out of gamut values, due to near black noise, don’t nesseasaryly produce large M values. Whilst some other well constrained images produce large M values, due to their high brightness. (expected, but interesting to see actually see it visually)
The compression looks to work impressively and these SD rec.709 samples really look nicer than that from the original candidates. I would like to experience these in HDR P-3.
I have been having some difficulty getting things working in Nuke (Non-commercial) as I have little experience with that. I am, however, fluent in DaVinci Resolve and am looking forward to when this all will be available for such. When might this be put into a DCTL? (and I hope the programing fits as I understand transfer between Blink and DCLT can sometimes be one way.)
Following ramps show one of the main issues that CAM DRT (and Candidate C) has. The input is a gray ramp with whitepoint shifted from ACES whitepoint to D65. One would expect that if the DRT is neutral and doesn’t cause temperature shift the RGB ratios stay steady until the saturation roll-off kicks in.
First two images are ACES 1 and Candidate A:
Now the same ramp through CAM DRT v023 and ZCAM:
Now the same ramp through CAM DRT v023 and Hellwig:
In both cases we can see that the temperature changes. The way we’ve compensated this is with the highlight desat. The problem can be lessened by compressing more but then highlights won’t have much color left anymore. The issue is not seen in ACES 1 or Candidate A (or any other DRT I’ve looked at).
In doing the chroma compression, in effort to retain the colorfulness in the highlights longer, this problem causes the colors to shift, typically warmer. IMO, this should not be happening in a neutral DRT; this type of thing should happen in LMT. This I believe is also the reason why neutrals have that color cast I’ve mentioned a few times.
The following ramp shows what would come out if there was no highlight desat at all (Hellwig):
That’s pretty extreme considering the input is effectively a gray ramp (with tiny amount of color in it).
Hey @priikone, It’s definitely not intentional, I think I might have fixed the shift in v024.
Slightly goofy mixed up between discount_illuminant and discountIlluminant in the code.
I’ve also updated the LUT repo with this version, baked out for other apps:
v24 fixes the pure gray ramp case with Hellwig, but unfortunately it has no effect on the examples I posted above. They still behave the same way. The discontinuity when Hellwig hits display white is still also there. Following is gray ramp with ACES whitepoint shifted to DCI whitepoint and given as input to v24 Hellwig:
OK
So I think I’ve gotten the discontinuity under control.
It seemed to be rooted in HK mode, and also looks to be the same issue as “J collapse” issue I’ve been chasing.
The is a new v025 that does a better job of allowing the XYZ_to_JMH function to be passed HK_mode and discountIluminant modes inderpendantly depeding on where in the DRT we are. It also incorporates a number of changes from @priikone which massivly speed up compile time.
This first plot shows HK_mode enabled at every stage in the chain, resulting in the discontinuity.
Whilst if I leave HK_mode only enabled for the entry in, as in the first transform from scene linear XYZ to JMh, but off for all subsequent transforms, we get a smooth result.
This second comparison shows the difference when rendering @priikone’s dominant wavelength ramps, which was always the easiest place to see “J collapse”. (with a massive post transform gamma down to make it easier to see)
vs
Now, this does change the appearance of the rendering pretty significantly, as this series of images below shows.
Pure greyscale values render the same, as seen in the grey ramp, but blues in paticular have higher brightness. I feels like the is a bit iffy when looking at the full blue patch on a macbeth, but feels like a win when looking at the brightness of the fairy lights behind Terry Silver on frame 28, which previously felt like it was suffering form the “nagative light energy” feeling we often get around highly saturated blues.
I’ve also updated the LUT repo with v025, but also left in v024 for easier comparison:
Great job, quick test shows it does fix the issues.
Do we actually need the discount illuminant? When it’s enabled doesn’t it mean we don’t do the CAT anymore from ACES whitepoint to D65, which both models expect? Shouldn’t it be disabled by default?
I think we need it on the way in, so Unity values end up with a zero M value, but I’d have to check again.
I removed the seperate ApplyCAT from the code path coming into Hellwig at some point, as I never succeeded in getting M down to zero… But maybe that was the wrong move?
Yeah, I’m not sure either, I’ve never really understood what the discount illuminant does and when it should or shouldn’t be enabled.
One note about the v25 is that the HK mode has a huge impact on brigthness of colors. I dislike what it does to reds and greens. Greens great really bright, as if they’re not bright enough already, same for reds. It brings up more noise as well. The HK mode didn’t have this much of an effect with previous versions.
What is the HK mode supposed to change? What it seems to do is to brighten colors by a half a stop or so (compared to HK mode disabled). Seems really strange what it’s doing now, can’t imagine it should have that big of an impact. I like Hellwig colors better without the HK mode.
Edit: I think it’s wrong to apply HK only on the way in (XYZ_to_JMh) and then not do that on the way out (JMh_to_XYZ).
A few observations on ACES 2 candidates version 025
DaVinci Resolve 18.1.1
Using B: Stock DaVinci YRGB project with manual ACES node
with display LG OLED55C8PCA via BMD DeckLink 4K Extreme 12G
There might be an issue with the Chromaticity scope in Resolve as colors are not contained within spaces indicated as expected.
P3D65 vs P3D65(Rec709sim) - Display at SD
++ higher saturation than P3D65(Rec709sim) shown on scopes for all samples, and very noticeable in images such as 0058 (green-screen), 0060 (red x-mas), 0061 (2020 colors), 0062 (light sabers)
++ no change in grey ramp curve, but colors do change. For example, reds and greens in 0029 and others mentioned above.
Rec2100 vs Rec2100(Rec709sim) - Display at HDR
++ All colors from images with Rec2100 seem to become less saturated in some images (example:0074) while not in others (example:0062).
++ Blue shifts even further magenta from the P3D65 and Rec709 groups, best seen in 0057(blue screen)
ACES2.0 Rec709 vs ACES1.3 Rec709 - Display at SD
++ In comparison with ACES1.3 Rec709 with a grey ramp the gamma of the curve seems to be changing in several places, especially in the lower (darker) end. Would it be correct to assume that all this “bending” of the ramp’s curve is due to the saturation compression? But then, why would a neutral grey ramp even be compressed for saturation? I would think that the compression algorithm would work similar to a dynamic EQ in that it would compress where, when and as needed.
++ All images seem “better”, however I am not sure if this is because of various contrast changes throughout the dynamic range. I would rather have more accurate than better.
++ Blues and Cyans do lighten and the blue screen (image0057) goes toward magenta.
++ There is also a big change in the green screen (image0058).
Again, these observations are when using Resolve and am not sure if similar when using Nuke.
Good work and lots of progress. Looking forward to more as refinements are made.
I think something’s strange with the gamut mapper in v25:
v25:
v24:
This happens with or without HK mode enabled or any combination of them. It happens with ZCAM as well.
Testing my new chroma compression with rec2100 HDR in v25, I also saw purple extending to ACES max with reds, blues and magentas, and took a picture:
I haven’t tested Hellwig in HDR before so I don’t know whether that purple’s been there before, but it is not with ZCAM and v24.
Actually this was my bad in merging the chroma compression to v25. Will re-check the ACES ramps for that purple later…
One of the things I was really enjoying before 25 (with 24) was the darker and maybe truer blacks. Under about 7% luminance 25 has started to pump up the values. Both of these are made in Resolve.
Hi, for anyone playing along in Resolve using the ACES Transform FX plugin, I have found an issue where if you add the plugin directly to the node tree (instead of applying it to an existing node) the plugin/fx node is ignoring the 3DLUT interpolation method and always using trilinear.
Attached are screenshots showing the ACES Transform plugin using the latest v025 709 ODT when added to an existing node (and using tetrahedral interpolation), versus dragging the FX plugin from the palette to the node tree and creating a new node (still set to tetrahedral but gets ignored and uses trilinear instead).
I’ve reported this to the Resolve team (I’m from the cameras team) who will address it in a future release. For now, please add the FX plugin to an existing node to avoid this.
I’m generally in favour of a more soft start look. Being able to see more in to the blacks etc. as a starting point for a grade. ACES 1.0 was too contrasty in my taste (and many other colorists I know) and always had to fight against that when setting my look. I think it’s better to add contrast than having to reduce it.
And VFX supervisors I know also wants to have a more “technical” start look to able to see/judge your VFX work better.
I dont think the initial look of v25 vs v24 should be the benchmark of how they perform. I think doing grade testes, SDR vs. HDR, etc. should. But I’m coming from a place where we at our facility always have look/LMT in our pipeline for our ACES projects (dailies, VFX, starting point for grade) so its not so important to us.
I pushed v26 of CAM DRT to my prototype DRT repo (as well as opened a pull request for @alexfry).
That version now adds an invertible chroma compression mode, replacing the old one. The goal of this mode is to achieve following:
Have neutral rendering throughout the exposure range. In previous versions the rendering became typically warmer at higher exposures. This brought a warm color cast into the image. Colors near the achromatic axis also expanded as exposure goes up, bringing undesirable colorfulness to neutrals (whites and grays). This should now be mostly gone. Image appears less colorful as a result.
Have better match between SDR and HDR. In my testing I’ve managed to convince myself that the match is better now, but I am eager to hear how people now find the match. I’ve tested Rec.709, Rec.2100 P3 limited and Rec.2100 Rec.2020 limited. With Candidate C SDR was much more colorful than HDR. v26 SDR is now less colorful than Candidate C SDR.
Hopefully have better skin tones.
The technique itself is highly adjustable so it is easy to add more colorfulness or remove colorfulness. I was quite conservative and SDR, for example, doesn’t stay crazy colorful in the highlights. It is still significantly more compared to Candidate C. I also added a global saturation control to play with.
v26 disables HK mode by default. I did the compression on top of v24 which had broken HK mode, and I think HK mode in v25 has issues too.
A few more observations on ACES 2 candidates version 025
DaVinci Resolve 18.1.1
Using B: Stock DaVinci YRGB project with manual ACES node
Note: I am adding the ACES transform to an existing node.
computer 1)HDR
Windows10 with display LG OLED55C8PCA via BMD DeckLink 4K Extreme 12G
computer 2)SD
Windows10 with ASUS ProArt Monitor calibrated to Rec.709 and Decklink Mini Monitor 4K
ACES2 computer 1)
P3D65(Rec709sim) vs Rec709
++ in general each image shows some lift (enough that middle grey also lightens) and shows the compressed saturation
++ watching Vector Scopes the hues seem to stay constant.
++ in particular the Lapis blue hue looks to remain constant (even though luminosity is increased) while the blue screen (0057) shifts toward magenta.
R2100 HDR & Rec2100(Rec709sim)HDR on computer 1 vs Rec709 SD on computer 2
++ the Rec2100(Rec709sim)HDR image looks too dark even when the scopes say it reaches almost 100 nits … [the Rec2100 version looks consistent with what the scopes say.]
++ using a grey ramp Rec2100(Rec709sim) shows max of 48 nits and Rec2100 104 nits. I am puzzled as to why this is so. [Note that Rec709 SD approaches 100 nits with images that do so as expected.]
Yeah that makes sense too. I feel like I am always bringing the blacks down so it makes more sense to start with a crisp low end. This rev had a nice softer midtone and highlight feel, less contrasty than the old ODTs but still deep blacks.
ACES version 1 to 1.3 Rec709 output and Rec2100 PQ never felt like their blacks matched but Rev24 did have the same low end. I’m about to start post on a few shows and experimenting with these ODT revs to see if I can use some ACES 2 developments sooner. So far this one (24) is my pick for an HDR grade that can go with the least changes to SDR.
