Hello. I’m testing the ACES 2.0 rev060 ODT for Rec.709 in DaVinci Resolve 19 beta 5 with some graded HLG source media, initially graded from ARRI ALEXA 35 sample media.
When comparing ACES 1.3 Rec.709 to ACES 2.0 rev060 Rec.709 ODT I see a massive hue shift towards red with ACES 2.0. Using DaVinci RCM/CST with DaVinci Tone Mapping I get better results than both ACES 1.3 and ACES 2.0 rev060.
Actually it’s the other way around. In ACES 1.3 you’re seeing a massive shift towards orange and eventually to yellow. ACES 2.0 being more hue preserving (more hue linear) it doesn’t do that. If you like that particular skew towards orange (and many people do) you’d have to do the skew yourself in the grade.
I notice that you’re doing inverse since you have input transform as Rec.2020 HLG 1000 nits (inverting ACES 1.3 HDR). So this comparison is a mishmash of different ACES versions going in inverse and forward directions. I suggest testing with scene referred material and not inverting.
I was thinking it could be related of the inverse HLG transform in ACES 1.3. Is this something that will be added for ACES 2.0 as well?
Did you look at the original HLG file I linked to on Google Drive? As I mentioned it is a file I already graded from ALEXA 35 source footage, precisely to test how HLG is handled in a ACES 2.0 pipeline.
HLG is also a scene-referred camera recording format used a lot for live HDR broadcast, so it will for sure be a format that will get into the mix in an ACES pipeline at some point.
Here is DaVinci Resolve CST for the conversion from HLG to DaVinci Wide Gamut Intermediate and then using JP 2499 DRT from DaVinci Wide Gamut Intermediate to 709.
Yeah, you’d want ACES 2.0 inverse when using ACES 2.0 output transform if you need to use inverse. HLG will be there in ACES 2.0.
Other than that, I believe what you’re seeing is that 100 nits transform is compressed more than the 1000 nits, so the red and especially yellow gets compressed earlier (and more as it’s Rec.709 rather than P3 limited). Here’s your example inverted and going through ACES 2.0. The triangles shown are Rec.709 and P3.
That depends if you are considering the HLG as display referred, and wanting to use an inverse output transform, or scene-referred and wanting to use an IDT (which is effectively what you are doing with the colour space transform, although in that case I would not include Resolve’s inverse OOTF). HLG can be a confusing beast!
Note:
HLG isn’t measured in nits like PQ. HLG is relative from 0-100%, just like Rec.709.
What are the principal differences between PQ and HLG?
HLG is a relative, scene-referred, signal. It is an evolutionary approach to HDR. Relative scene-referred signals are also used, for example, in Recommendations ITU-R BT.601 [4], ITU-R BT.709
[5] and ITU-R BT.2020 [6], and by Sony in S-Log, ARRI in Log C, and Panavision in Panalog.
PQ is an absolute, display-referred, signal. It is a new approach to video.
PQ and HLG are fundamentally different systems.
While HLG is notionally scene-referred and relative, according to the BBC, for conversion purposes it is normally best treated as 1000 nit display-referred (i.e. using the BT.2100 HLG EOTF with L_W=1000).
The HLG and PQ clips you posted are identical in display-referred terms if the HLG is anchored at 1000 nits, and you can cross-convert between them.
The best way to apply an inverse ODT to a P3-D65 limited Rec.2020 image is to convert it to P3-D65 PQ and then apply a P3-D65 PQ inverse Output Transform. If you do this, and then apply a forward Rec.709 Output Transform, this is the result:
Yes. Converting between HLG and PQ is easy. The final displayed light is the same on a 1000 nits display, which is what I have used the two files shared via Google Drive to test on two separate 1000 nits HDR displays set to HLG and PQ respectively.
That’s odd, because it would seem to exactly match my node tree, but your result does not match mine.
You don’t have any other colour management enabled that would be interfering with things? You should just be in DaVinci YRGB mode, with Output colour space set to Rec.709 Gamma 2.4. You should also set the Timeline colour space to ACEScct if you want the “HDR” grading operators to be properly colour space aware.
I have not tested my fully procedural DCTL implementations on a wide variety of systems, so there could be an issue there. But you have also used @alexfry’s v60 LUT based versions, which would seem to eliminate that.
Don’t think there’s anything wrong in the setup. I get the same result.
AFAIK DaVinci DRT does not have any mechanisms for hue preservation or gamut compression so easily skews. JP2499 also uses more intentional skews if I’m not mistaken, that can be partially controlled on the DCTL. ARRI Reveal looks quite similar to ACES2.0rc1. AgX looks different but also more hue preserving staying on the orange/red side rather than yellow.
If you set Resolve’s CST to Saturation Preserving and add Saturation Compression you also get something more akin to the other results.
I just wanted to make sure I got the ACES 2.0 rc1 709 transform working correctly, which is why I wonder how @nick got to his more yellow looking version that looks closer DaVinci HLG to 709 CST and JP 2499 DRT. Comparing DaVinci HLG to 709 CST and JP 2499 SDR versions again perceptually to the HDR HLG version on an HDR screen, they look a bit too yellow maybe. 2499 is quite easy to adjust skew a bit more towards red though.
This golden/warm sunset HDR HLG image turns out to be more tricky to perceptually match from HDR to SDR than I would have thought. Comparing again the graded HDR HLG an on HDR display to different SDR down-mappers, it’s a fine balance between looking too red/salmon and too yellow.
Different SDR tone-mappers tend skew these yellow/orange/red hues very differently.
Luminance Mapping in DaVinci CST with images of skin, fire or other yellow to orange hues also tend to just compress all yellow hues into orange/red, which “looks strange”, which is one reason I don’t like it for skin tones.
I guess there’s a reason there is so much research and development going on in this area of “tone mapping”.
For my own sanity, I tried to re-grade the source ARRI ALEXA35 sunset clip in ACEScct to see how ACES 1.3 Rec.709 and PQ ST2084 1000 nits P3D65 Limited is compared to ACES 2.0 rc1.
Grading under the ACES 2.0 rc1 ODT for both SDR and HDR PQ ST2084 1000 P3D65 Limited feels really strange. It is close to impossible to make that sunset golden. It just goes salmon red.
Considering that Nick got a very different Rec.709 image than me when doing the inverse ACES2 PQ P3D65 to ACEScct after converting the previous HLG HDR sample clip to P3D65 PQ ST2084, it seems to me like something is wrong with both rev060 and the rc1 DCTL’s for DaVinci Resolve?
For those who want to test, I have made ACES AP0 Lin EXR files available via the Dropbox link below. There are three files. The source frame from the ARRI ALEXA35 sample media, the graded SDR and the graded PQ HDR.
That is intended, the transform it’s basically chromaticity linear so you will get that look everytime, same happens with fires and sunsets under RCM using luminance mapping, there are ways to remove it by grading it out slightly, but the questions is if this starting look it’s a good idea in the first place ?
From my tests the DCTLs for the new transform seem to be work as intended by the developers . I haven’t tested Nick’s way, but I don’t see any reason to get a different result by copying what he did
