[HDR/Windows] HLG shader uses a wrong transfer function
Categories
(Core :: Graphics: Color Management, defect)
Tracking
()
People
(Reporter: tcbbdddd, Unassigned, NeedInfo)
References
(Blocks 1 open bug)
Details
Attachments
(4 files)
In 2037689, we introduced a shader to deal with HLG videos (see DCLayerTree.cpp). Unfortunately, we did it wrong.
We only did the reverse OETF part, which maps HLG RGB values to HLG scene linear values. We still need to apply the OOTF to convert these values to display linear values. See Hybrid log-gamma for details. Note that the formula in wikipedia includes a black input offset, we don't need that.
The peak brightness is also wrong. Currently peak brightness is L_w = 12 * 80 = 960nit. It should be 1000nit if we want it to be a fixed number. Or maybe we can read the peak brightness of the monitor and use that as L_w. That's another story though, we should just pick 1000nit and fix the transfer function ASAP.
|
Reporter | |
Updated•20 days ago
|
|
|
Reporter | |
Comment 1•20 days ago
|
||
Also note that the gamma changes according to peak brightness. Wikipedia isn't clear on that. The formula is γ = 1.2 + 0.42 · log10(L_w / 1000). It is 1.2 on 1000nit peak. But if we choose another L_w, γ should be adjusted accordingly.
|
|
Reporter | |
Comment 2•17 days ago
|
||
I found that when Lw is outside of 400-2000 cd/m^2, we should use this formula: γ = 1.2 × κ^log2(Lw/1000)，κ = 1.111. This is mentioned in a footnote of the ITU-R BT.2100 spec. libplacebo uses this formula for HLG handling.
|
||
Comment 3•17 days ago
|
||
I based the implementation on Recommendation ITU-R BT.2100-3 Image parameter values for high dynamic range television for use in production and international programme exchange and did not implement the OOTF because I assumed it meant just the combination of OETF->EOTF yielding a non-neutral result in some pairings (BT709+BT1886 or sRGB+BT1886 are not neutral transfer functions).
On that assumption I also challenged the application of an OOTF in https://phabricator.services.mozilla.com/D324628 but it was landed before I had a chance to analyze whether it should have an OOTF.
Applying an OOTF of 1.2 gamma seems like it may explain the difference I saw between the PQ and HLG versions of the BT2111 test pattern I used in testing. However chromium seems to do something yet more different with HLG that I do not fully understand.
|
|
||
Comment 4•17 days ago
|
||
|
|
||
Comment 5•17 days ago
|
||
|
|
||
Comment 6•17 days ago
|
||
|
|
||
Comment 7•17 days ago
|
||
|
|
||
Comment 8•17 days ago
|
||
I've attached the sample videos we use for testing, the HLG and PQ versions look a lot more similar to eachother in Firefox than they do in Chrome or Edge - but I will agree on the correctness of applying the OOTF now that I know it was not meant to be simply a representation of OETF->EOTF for HLG.
|
|
Reporter | |
Comment 9•17 days ago
|
||
What do you mean by "similar"? The HLG and PQ versions look more similar to each other in Chrome on my PC. First, the grayscale parts are different in both Firefox and Chrome. Second, the gray in the brightwhite-bottom test and the leftmost & rightmost gray bar in BT2111 pattern look the same in Chrome on both PQ and HLG. But they look different on PQ and HLG in Firefox. The gray bar in BT2111 pattern is supposed to look the same on PQ and HLG, so Chrome is correct.
Note that I test with SDR brightness slider at 30, which corresponds to about 200nit. It seems Chrome tries to adjust the brightness of HLG, so that 75% input (~203nit on 1000nit peak) matches Windows SDR level. But Chromes doesn't adjust the brightness of PQ. If it were to adjust, 58% input of PQ (~203nit as well) should match Windows SDR level. So if the SDR brightness slider is not 30, the gray bar can look different on PQ and HLG in Chrome.
|
||
Comment 10•9 days ago
|
||
The severity field is not set for this bug.
:ahale, could you have a look please?
For more information, please visit BugBot documentation.
Description
•