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

From: Shashank Sharma <shashank.sharma@amd.com>
To: Pekka Paalanen <ppaalanen@gmail.com>
Cc: Deepak.Sharma@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,
	Nicholas.Kazlauskas@amd.com, Vitaly.Prosyak@amd.com
Subject: Re: [RFC PATCH 0/3] A drm_plane API to support HDR planes
Date: Fri, 30 Apr 2021 16:09:49 +0530	[thread overview]
Message-ID: <82a1c8e6-a7d6-bff3-fae7-f2a3dc68f9f7@amd.com> (raw)
In-Reply-To: <20210430124358.1f5ac6ec@eldfell>

Hello Pekka,

On 30/04/21 15:13, Pekka Paalanen wrote:
> 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.
Ah, that was due to the Gamut mapping block. You are right, color format conversion can happen on non-linear data (doesn't mean it can't happen on linear), but in the sequential block above, there was gamut mapping (color space conversion), which needs to be done on Linear space, and I was a bit too lazy to create separate blocks, so I just re[placed the block titles  :D.
> 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.

Yes, that was a typo. The intention was to call it inverse curve for HDR encoded buffers. It's almost 4 years (and 2 companies) since I last did HDR, so I am a bit rusty on the topic ;) .

- Shashank

>
> 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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel