All of lore.kernel.org
 help / color / mirror / Atom feed
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: Wed, 22 Sep 2021 11:06:53 -0400	[thread overview]
Message-ID: <a13d64b1-7b24-5fd5-41d3-b55d2bd388e0@amd.com> (raw)
In-Reply-To: <4ed51ca0-ca98-cf84-33ed-ab172e3548d3@amd.com>



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 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.

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.

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.

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.

Harry


  parent reply	other threads:[~2021-09-22 15:07 UTC|newest]

Thread overview: 38+ 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       ` Harry Wentland [this message]
2021-09-23  8:01         ` [RFC PATCH v3 1/6] drm/doc: Color Management and HDR10 RFC Pekka Paalanen
2021-09-23 13:40           ` Harry Wentland
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 23:33   ` kernel test robot
2021-07-31  1:18   ` kernel test robot
2021-07-31  1:18   ` [RFC PATCH] drm/color: drm_get_transfer_function_name() can be static kernel test robot
2021-07-31  1:31   ` [RFC PATCH v3 2/6] drm/color: Add transfer functions for HDR/SDR on drm_plane kernel test robot
2021-07-30 20:41 ` [RFC PATCH v3 3/6] drm/color: Add output transfer function to crtc Harry Wentland
2021-07-31  2:13   ` kernel test robot
2021-07-31  3:42   ` kernel test robot
2021-07-30 20:41 ` [RFC PATCH v3 4/6] drm/color: Add sdr boost property Harry Wentland
2021-07-31  0:42   ` kernel test robot
2021-07-31  2:13   ` kernel test robot
2021-07-30 20:41 ` [RFC PATCH v3 5/6] drm/color: Add color space plane property Harry Wentland
2021-07-31  3:47   ` kernel test robot
2021-07-31  3:47   ` [RFC PATCH] drm/color: drm_get_color_space_name() can be static kernel test robot
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=a13d64b1-7b24-5fd5-41d3-b55d2bd388e0@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.