Re: [RFC PATCH 0/3] A drm_plane API to support HDR planes

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