From: Harry Wentland <harry.wentland@amd.com>
To: Pekka Paalanen <ppaalanen@gmail.com>
Cc: amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
sebastian@sebastianwick.net, mcasas@google.com,
jshargo@google.com, Shashank.Sharma@amd.com,
Deepak.Sharma@amd.com, Shirish.S@amd.com, Vitaly.Prosyak@amd.com,
aric.cyr@amd.com, Bhawanpreet.Lakha@amd.com,
Krunoslav.Kovac@amd.com, hersenxs.wu@amd.com,
Nicholas.Kazlauskas@amd.com, laurentiu.palcu@oss.nxp.com,
ville.syrjala@linux.intel.com, jeremy@jcline.org,
Brian Starkey <brian.starkey@arm.com>
Subject: Re: [RFC PATCH v3 1/6] drm/doc: Color Management and HDR10 RFC
Date: Thu, 23 Sep 2021 09:40:07 -0400 [thread overview]
Message-ID: <27a41be5-3563-6334-7bf8-e6d8f334359a@amd.com> (raw)
In-Reply-To: <20210923110130.1928d8bf@eldfell>
On 2021-09-23 04:01, Pekka Paalanen wrote:
> On Wed, 22 Sep 2021 11:06:53 -0400
> Harry Wentland <harry.wentland@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@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
>
next prev parent reply other threads:[~2021-09-23 13:40 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-30 20:41 [RFC PATCH v3 0/6] A drm_plane API to support HDR planes Harry Wentland
2021-07-30 20:41 ` [RFC PATCH v3 1/6] drm/doc: Color Management and HDR10 RFC Harry Wentland
2021-08-02 16:30 ` Brian Starkey
2021-08-13 5:12 ` Sharma, Shashank
2021-08-16 11:10 ` Brian Starkey
2021-08-16 12:40 ` Harry Wentland
2021-08-16 13:37 ` sebastian
2021-09-06 21:20 ` Shankar, Uma
2021-09-15 14:36 ` Pekka Paalanen
2021-09-21 1:55 ` Harry Wentland
2021-09-15 14:01 ` Pekka Paalanen
2021-09-15 15:50 ` Jeremy Cline
2021-09-21 0:14 ` Harry Wentland
2021-09-21 13:31 ` Pekka Paalanen
2021-09-21 18:05 ` Harry Wentland
2021-09-22 8:31 ` Pekka Paalanen
2021-09-22 15:28 ` Harry Wentland
2021-09-23 7:43 ` Pekka Paalanen
2021-09-30 13:04 ` Repository for additional color and HDR related documentation (Re: [RFC PATCH v3 1/6] drm/doc: Color Management and HDR10 RFC) Pekka Paalanen
2021-09-22 15:06 ` [RFC PATCH v3 1/6] drm/doc: Color Management and HDR10 RFC Harry Wentland
2021-09-23 8:01 ` Pekka Paalanen
2021-09-23 13:40 ` Harry Wentland [this message]
2021-09-23 15:50 ` Vitaly Prosyak
2021-07-30 20:41 ` [RFC PATCH v3 2/6] drm/color: Add transfer functions for HDR/SDR on drm_plane Harry Wentland
2021-07-30 20:41 ` [RFC PATCH v3 3/6] drm/color: Add output transfer function to crtc Harry Wentland
2021-07-30 20:41 ` [RFC PATCH v3 4/6] drm/color: Add sdr boost property Harry Wentland
2021-07-30 20:41 ` [RFC PATCH v3 5/6] drm/color: Add color space plane property Harry Wentland
2021-07-30 20:41 ` [RFC PATCH v3 6/6] drm/amd/display: reformat YCbCr-RGB conversion matrix Harry Wentland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=27a41be5-3563-6334-7bf8-e6d8f334359a@amd.com \
--to=harry.wentland@amd.com \
--cc=Bhawanpreet.Lakha@amd.com \
--cc=Deepak.Sharma@amd.com \
--cc=Krunoslav.Kovac@amd.com \
--cc=Nicholas.Kazlauskas@amd.com \
--cc=Shashank.Sharma@amd.com \
--cc=Shirish.S@amd.com \
--cc=Vitaly.Prosyak@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=aric.cyr@amd.com \
--cc=brian.starkey@arm.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=hersenxs.wu@amd.com \
--cc=jeremy@jcline.org \
--cc=jshargo@google.com \
--cc=laurentiu.palcu@oss.nxp.com \
--cc=mcasas@google.com \
--cc=ppaalanen@gmail.com \
--cc=sebastian@sebastianwick.net \
--cc=ville.syrjala@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).