On 2021-04-30 6:39 a.m., Shashank Sharma wrote: > Hello Pekka, > > On 30/04/21 15:13, Pekka Paalanen wrote: >> On Wed, 28 Apr 2021 13:24:27 +0530 >> Shashank Sharma <shashank.sha...@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 >
Thanks, Ville and Shashank. This is indeed helpful. I apologize for the late response but I needed to take some time to do more reading and internalize some of the HDR and CM concepts. I will send out a v2 of my patchset but realize that it is only a small step toward the right KMS interface for HDR and CM. Harry >> >> 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 _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
