On 2021-09-23 04:01, Pekka Paalanen wrote:
> On Wed, 22 Sep 2021 11:06:53 -0400
> Harry Wentland <harry.wentl...@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.wentl...@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).
>> 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
>