Re: Incorrect Algorithm and mDCv for HLG (From last night's meeting)

Hi Pekka,


>Speaking of srgb_eotf(), which one do you prefer here: the two-part
>function with a linear segment near zero, or the 2.2 power function,
>and why?

I believe the specification has an encoding function and a reference display function.  It would be interesting to poll the members of the group as to which they use.  There’s a similar linearity in BT.709 (for noise suppression) – but it’s not always used.


>BT.2100 is based on monochromatic primaries, and consumer displays tend
>to use less saturated primaries. How does the HLG system avoid
>saturation clipping or how would one describe it? How do you make the
>best use of the available color gamut in a monitor or TV without
>exceeding it?
>Is there some assumption of what the color gamut is in a HLG signal
>and what do displays do to map that to their hardware primaries and
>white point?

Colour gamut is a function of a display, whereas HLG is a scene-referred system, so, we need to be careful with terminology.  HLG signals are assumed to conform to ITU-R BT.2100 primaries.

Most consumer electronics displays such as televisions expect a standards compliant signal on the input – this is then mapped within the device to best match its capabilities and whatever look is applied by the manufacturer or user (football mode, filmmaker mode etc.).  I’m not aware of any that allow you to precorrect for an individual device’s actual primaries, switching off the display added correction.  This may be different in a screen built into a computing device or phone.  What you definitely don’t want is to apply a correction and then for the screen to apply it again.

>I would imagine that knowing the primaries of the mastering display
>would help with color gamut mapping. Is that not necessary?

I don’t think it is for Consumer electronics, the manufacturers do the correction for their panel.  It’s also difficult to see how the metadata can be correct when multiple images or sequences are composited, when graphics overlays are added etc.

Also, many of the HDR video sequences seen in live television are not mastered using an HDR display.  They are created by monitoring a downmapped SDR version of the HDR signal whilst adjusting the HDR signal (because a) most viewers still watch SDR so it is important that this is correct and b) currently, the converters are static so you need to make sure you don’t go outside the envelope they can cope with).  For further details, see: https://tech.ebu.ch/docs/techreports/tr070.pdf

Simon