Hello. I am running into some odd behavior when attempting to use Fusion in Davinci Resolve with ACES 2.0 color management. My understanding is that Fusion’s working space should be ACEScg (floating-point linear with AP1 primaries) and that these values should be converted to the output space for eventual rendering.
My question has to do with how these floating-point linear code values are mapped to absolute luminance values when using Rec.2020 ST.2084 (4000 nits) as the output transform. Since ACEScg deals with relative scene luminance but ST.2084 uses absolute luminance values (in nits) that are meant to come out of a reference display, it seems to me like the mapping between linear and PQ values should be somewhat arbitrary. A relative luminance of 0.5 could mean 50 nits, or it could just as easily mean 500 nits. Since the units are different, there’s no inherently “correct” mapping. At least, that’s my understanding. Please correct me if I’m wrong.
However, while it seems technically valid to have an arbitrary mapping like this, the actual mapping that’s used in Resolve’s implementation of ACES 2.0 seems very strange to me. As an example, let’s say I have a patch of diffuse white with a code value of 1.0 in linear. It seems sensible that, when converted to ST.2084, this patch of white could be sitting at, say, 100 nits. Or perhaps, if one wants to follow the ITU-R BT.2408 recommendation, then perhaps diffuse white could be mapped to 203 nits. Either of these would make sense to me. But instead, a value of 1.0 in linear seems to correspond to roughly 133 nits in PQ, which seems to me to be a very strange choice.
When I try to make text elements in linear that are meant to sit at the 203 nit graphics white level, I have to set their relative luminance to around 1.45. What was the rationale behind this choice of mapping? Is it something specific to Resolve, or is it baked into the ACES 2.0 spec somewhere?
Not Resolve specific. That is part of the tone-mapping of ACES. Where values map differs depending on your peak luminance. The tone-mapping was designed to put middle-gray at 10 nits for SDR. Middle gray luminance (and by effect, 1.0) increases slightly as a function of the peak luminance value. But it is also easy to limit to any lower dynamic range so that two representations in displays with different luminance dynamic range capabilities can easily be made to match, if that is the desired outcome.
How people want to use additional dynamic range of a display is up to them. One can utilize the additional headroom to make extreme specular highlights pop, to make the overall picture brighter, make things match exactly, or various combinations of the above. It’s a creative choice and all can be accomplished in various ways. Just because one can go brighter doesn’t mean one needs to.
However, the default in ACES is to roll off higher and to put the overall picture a little brighter. This does mean that in ACES, baking titles in to your image at a particular ACES value will create different output luminances between say 1000 nit and 4000 nit displays. But that is the case with any output-referred images (titles or otherwise) being inverted back into a scene-space. If you always want them to come out at the same output, then you will need to adjust where they sit in the scene-space for each output.
For reference, here are some key values out of ACES 2 transforms for the different preset luminances:
“The reference level, HDR Reference White, is defined in this Report as the nominal signal level obtained from an HDR camera and a 100% reflectance white card resulting in a nominal luminance of 203 cd/m^2 on a PQ display or on an HLG display that has a nominal peak luminance capability of 1000 cd/m^2.”
(Everything in this document tends to assume a 1000-nit display, including the conversion between PQ and HLG encodings.)
You said you’re using the 4000-nit transform, which as you stated, does require an ACES value of 1.458 to produce a PQ value of 0.58 through that transform.
For a 1000-nit rendering, however, you’d need an ACES value of 1.969 to get an equivalent PQ value of 0.58.
Thank you very much for the response. I’ve been looking through some of the ACES source code and I can see that the luminance tone mapping function is doing exactly what you describe.
I suppose my follow-up question would be: If ACES 2.0 assumes that 18% grey should sit at 10 nits SDR or up to 17 nits in PQ, does this mean that following ITU-R BT.2408 is not recommended practice when working in ACES? The recommendation specifies that 18% grey should sit at 26 nits HDR, which is meaningfully brighter than what ACES produces at any peak luminance level. Would it be fair to say that productions should choose to follow either BT.2408 or ACES conventions, but not try to do both at once?
That’s a good question and I don’t have an immediate answer. There’s a lot of complexities when trying to compare the ITU recommendations to the ACES assumptions. Even the definitions of “scene-referred” are not quite the same. Environmental surround, different assumptions from video-ish to DI-type workflows, and other factors make it so we’re not directly comparing apples to apples. There should be further discussion on this to see how people have been working with ACES with the ITU recs (if they have). This difference in approach is not new in ACES 2, but the exact values produced by the transforms are different from those in ACES 1.x.
I am working to publish some new documentation about how the ACES 2 transforms work and the expectations one can have when using them (such as the graph and table of values I posted).
However, it is clear that we should establish and publish additional recommendations about how one might try to reconcile the ITU and ACES recommendations.
The tone curve does not follow ITU-R BT 2408, obviously.
The values in 2408 are just rough guidelines for live broadcasting.
The origin of the 203 nits comes from this:
Take an HLG live feed, take a typical Luma Waveform.
See that a typical Luma Waveform has a guide raster line at 75%.
Take this for reference white as this is convenient to spot on a Luma Waveform.
Then to translate this to PQ take the 1000nits HLG to PQ bridge and calculate were 75% HLG lands.
This will give you 203 nits.
The problem I have with 203 nits is that the precision of that number suggests that there is some scientific procedure behind coming up with that number (why would it be otherwise such a strange number)
But really what it should be called is “around 200nits”.
Then the 200 nits for graphics white are chosen for compatibility with SDR in simultaneous live broadcast of HLG.
In simultaneous broadcast you have the issue that the same HLG signal is shown on an HLG and 2.4 gamma Rec.2020 monitor.
If you acknowledge the fact that SDR 2020 monitors are typically set to 200-300 nits peak you need to make the diffuse white in the HLG signal brighter.
Otherwise the signal would look darker on the HDR monitors compared to the SDR monitors.
All of this is not applicable to motion picture and hence we did not follow ITU-R BT 2408.
