[RFC PATCH v3 1/6] drm/doc: Color Management and HDR10 RFC

[Vitaly Prosyak]

On 2021-09-23 9:40 a.m., Harry Wentland wrote:
>
> On 2021-09-23 04:01, Pekka Paalanen wrote:
>> On Wed, 22 Sep 2021 11:06:53 -0400
>> Harry Wentland <harry.wentland at amd.com> wrote:
>>
>>> On 2021-09-20 20:14, Harry Wentland wrote:
>>>> On 2021-09-15 10:01, Pekka Paalanen wrote:> On Fri, 30 Jul 2021 16:41:29 -0400
>>>>> Harry Wentland <harry.wentland at amd.com> wrote:
>>>>>   
>>> <snip>
>>>
>>>>>> +If a display's maximum HDR white level is correctly reported it is trivial
>>>>>> +to convert between all of the above representations of SDR white level. If
>>>>>> +it is not, defining SDR luminance as a nits value, or a ratio vs a fixed
>>>>>> +nits value is preferred, assuming we are blending in linear space.
>>>>>> +
>>>>>> +It is our experience that many HDR displays do not report maximum white
>>>>>> +level correctly
>>>>> Which value do you refer to as "maximum white", and how did you measure
>>>>> it?
>>>>>   
>>>> Good question. I haven't played with those displays myself but I'll try to
>>>> find out a bit more background behind this statement.
>>>>    
>>>
>>> Some TVs report the EOTF but not the luminance values.
>>> For an example edid-code capture of my eDP HDR panel:
>>>
>>>    HDR Static Metadata Data Block:
>>>      Electro optical transfer functions:
>>>        Traditional gamma - SDR luminance range
>>>        SMPTE ST2084
>>>      Supported static metadata descriptors:
>>>        Static metadata type 1
>>>      Desired content max luminance: 115 (603.666 cd/m^2)
>>>      Desired content max frame-average luminance: 109 (530.095 cd/m^2)
>>>      Desired content min luminance: 7 (0.005 cd/m^2)
>>>
>> I forget where I heard (you, Vitaly, someone?) that integrated panels
>> may not have the magic gamut and tone mapping hardware, which means
>> that software (or display engine) must do the full correct thing.
>>
>> That's another reason to not rely on magic display functionality, which
>> suits my plans perfectly.
>>
> I've mentioned it before but there aren't really a lot of integrated
> HDR panels yet. I think we've only seen one or two without tone-mapping
> ability.
>
> Either way we probably need at least the ability to tone-map the output
> on the transmitter side (SW, GPU, or display HW).

It is really interesting to see the quality of panel TM algorithm by 
specifying different metadata

and validate how severe loss of details which could mean no TM at all or 
1DLUT  is used to soften the

clipping or 3DLUT( which has wider possibilities for TM)

To facilitate this development we may use LCMS proofing capabilities to 
allow simulate the image

view on high end(wide gamut display) how it may looks on low end

(narrow gamut displays or integrated panels)

>>> I suspect on those TVs it looks like this:
>>>
>>>    HDR Static Metadata Data Block:
>>>      Electro optical transfer functions:
>>>        Traditional gamma - SDR luminance range
>>>        SMPTE ST2084
>>>      Supported static metadata descriptors:
>>>        Static metadata type 1
>>>
>>> Windows has some defaults in this case and our Windows driver also has
>>> some defaults.
>> Oh, missing information. Yay.
>>
>>> Using defaults in the 1000-2000 nits range would yield much better
>>> tone-mapping results than assuming the monitor can support a full
>>> 10k nits.
>> Obviously.
>>
>>> As an aside, recently we've come across displays where the max
>>> average luminance is higher than the max peak luminance. This is
>>> not a mistake but due to how the display's dimming zones work.
>> IOW, the actual max peak luminance in absolute units depends on the
>> current image average luminance. Wonderful, but what am I (the content
>> producer, the display server) supposed to do with that information...
>>
>>> Not sure what impact this might have on tone-mapping, other than
>>> to keep in mind that we can assume that max_avg < max_peak.
>> *cannot
>>
> Right
>
>> Seems like it would lead to a very different tone mapping algorithm
>> which needs to compute the image average luminance before it can
>> account for max peak luminance (which I wouldn't know how to infer). So
>> either a two-pass algorithm, or taking the average from the previous
>> frame.
>>
>> I imagine that is going to be fun considering one needs to composite
>> different types of input images together, and the final tone mapping
>> might need to differ for each. Strictly thinking that might lead to an
>> iterative optimisation algorithm which would be quite intractable in
>> practise to complete for a single frame at a time.
>>
> Maybe a good approach for this would be to just consider MaxAvg = MaxPeak
> in this case. At least until one would want to consider dynamic tone-mapping,
> i.e. tone-mapping that is changing frame-by-frame based on content.
> Dynamic tone-mapping might be challenging to do in SW but could be a possibility
> with specialized HW. Though I'm not sure exactly how that HW would look like.
> Maybe something like a histogram engine like Laurent mentions in
> https://lists.freedesktop.org/archives/dri-devel/2021-June/311689.html.
>
> Harry
>
>> Thanks,
>> pq
>>