From: Pekka Paalanen <ppaalanen@gmail.com>
To: Shashank Sharma <shashank.sharma@amd.com>
Cc: Deepak.Sharma@amd.com, aric.cyr@amd.com, Krunoslav.Kovac@amd.com,
mcasas@google.com, Bhawanpreet.Lakha@amd.com,
dri-devel@lists.freedesktop.org, Shirish.S@amd.com,
sebastian@sebastianwick.net, hersenxs.wu@amd.com,
amd-gfx@lists.freedesktop.org, laurentiu.palcu@oss.nxp.com,
Harry Wentland <harry.wentland@amd.com>,
Nicholas.Kazlauskas@amd.com, ville.syrjala@linux.intel.com,
Vitaly.Prosyak@amd.com
Subject: Re: [RFC PATCH 0/3] A drm_plane API to support HDR planes
Date: Fri, 30 Apr 2021 12:43:58 +0300 [thread overview]
Message-ID: <20210430124358.1f5ac6ec@eldfell> (raw)
In-Reply-To: <ba369002-69e9-15d5-323c-1923ecdeda63@amd.com>
[-- Attachment #1.1: Type: text/plain, Size: 3059 bytes --]
On Wed, 28 Apr 2021 13:24:27 +0530
Shashank Sharma <shashank.sharma@amd.com> wrote:
> Assuming these details, A compositor will look for DRM color properties like these:
>
> 1. Degamma plane property : To make buffers linear for Gamut mapping
>
> 2. Gamut mapping plane property: To gamut map SRGB buffer to BT2020 colorspace
>
> 3. Color space conversion plane property: To convert from YCBCR->RGB
>
> 4. Tone mapping plane property: To tone map SDR buffer S2H and HDR buffer H2H
>
> 5. Gamma plane/CRTC property: to re-apply the output ST2084 curve
>
>
...
> *
> *
> *
> * ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ ┌────────────────┐
> * HDR 600 Nits│ │HDR 600 Nits │ │HDR600 │ │HDR500 │ │ HDR500
> * ────────► │ Degamma ├────────────►│ Color space ├──────────►│ Tone mapping ├──────►│ Gamma │
> * BT2020 │ OETF ST2084 │ BT2020 │ conversion │BT2020 │ H2H │BT2020 │ ST2084 │ BT2020
> * YCBCR420 │ │ YCBCR420 │ YCBCR->RGB │RGB88 │ 600->500 │RGB888 │ │ RGB888
> * Non Linear └─────────────────┘ Linear └─────────────────┘Linear └─────────────────┘Linear └────────────────┘ ST2084
> */
Hi Shashank,
I think you might have degamma and color model conversion reversed, or
is that a new thing in the HDR specs?
Usually the YCbCr/RGB conversion matrix applies to non-linear values
AFAIU.
There is also confusion with OETF vs. EOTF. I got that initially wrong
too. OETF is not just a name for inverse-EOTF but it is used in a
different context. Though here it seems to be just a typo.
OETF is inherent to a camera when it converts light into
electrical signals. EOTF is inherent to a monitor when it converts
electrical signals to light. Depending on what the electrical signals
have been defined to be in each step of a broadcasting chain, you might
need OETF or EOTF or their inverse or a different OETF or EOTF or their
inverse.
As we are talking about displays and likely assuming display-referred
content (not scene-referred content), we probably have no use for OETF,
but we could have several different EOTFs.
Thanks,
pq
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 154 bytes --]
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
next prev parent reply other threads:[~2021-04-30 9:44 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-26 17:38 [RFC PATCH 0/3] A drm_plane API to support HDR planes Harry Wentland
2021-04-26 17:38 ` [RFC PATCH 1/3] drm/color: Add RGB Color encodings Harry Wentland
2021-04-26 18:07 ` Ville Syrjälä
2021-04-26 18:56 ` Harry Wentland
2021-04-26 19:08 ` Ville Syrjälä
2021-04-30 9:04 ` Pekka Paalanen
2021-05-01 0:53 ` Sebastian Wick
2021-05-14 21:04 ` Harry Wentland
2021-05-17 8:34 ` Pekka Paalanen
2021-05-18 14:32 ` Harry Wentland
2021-05-19 7:56 ` Pekka Paalanen
2021-04-26 17:38 ` [RFC PATCH 2/3] drm/color: Add Color transfer functions for HDR/SDR Harry Wentland
2021-04-26 17:38 ` [RFC PATCH 3/3] drm/color: Add sdr boost property Harry Wentland
2021-04-27 9:09 ` [RFC PATCH 0/3] A drm_plane API to support HDR planes Daniel Vetter
2021-04-27 14:50 ` Pekka Paalanen
2021-04-28 7:54 ` Shashank Sharma
2021-04-30 9:43 ` Pekka Paalanen [this message]
2021-04-30 10:39 ` Shashank Sharma
2021-05-14 21:01 ` Harry Wentland
2021-05-14 21:05 ` Harry Wentland
2021-05-17 8:57 ` Pekka Paalanen
2021-05-17 16:48 ` Sebastian Wick
2021-05-17 19:39 ` Vitaly Prosyak
2021-05-18 7:56 ` Pekka Paalanen
2021-05-18 14:19 ` Harry Wentland
2021-05-18 23:00 ` Sebastian Wick
2021-05-19 8:53 ` Pekka Paalanen
2021-05-19 10:02 ` Pekka Paalanen
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=20210430124358.1f5ac6ec@eldfell \
--to=ppaalanen@gmail.com \
--cc=Bhawanpreet.Lakha@amd.com \
--cc=Deepak.Sharma@amd.com \
--cc=Krunoslav.Kovac@amd.com \
--cc=Nicholas.Kazlauskas@amd.com \
--cc=Shirish.S@amd.com \
--cc=Vitaly.Prosyak@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=aric.cyr@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=harry.wentland@amd.com \
--cc=hersenxs.wu@amd.com \
--cc=laurentiu.palcu@oss.nxp.com \
--cc=mcasas@google.com \
--cc=sebastian@sebastianwick.net \
--cc=shashank.sharma@amd.com \
--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).