HDR support in Wayland/Weston
Nautiyal, Ankit K
ankit.k.nautiyal at intel.com
Thu Jan 31 10:46:55 UTC 2019
Thanks for the clarification Ole.
Regards,
Ankit
On 1/31/2019 2:22 PM, Niels Ole Salscheider wrote:
> Hi Ankit,
>
> please find my answers below.
>
> Am Donnerstag, 31. Januar 2019, 06:54:03 CET schrieb Nautiyal, Ankit K:
>> Hi Ole,
>>
>> I was going through the protocol you had proposed, and have some silly
>> questions, please pardon my ignorance.
>>
>> From where can the client-applications get the ICC profile files? Does
>> the client application manufacture it for a given color space and a
>> standard template?
>>
>> Or the compositor needs to store .icc files for each of the
>> color-spaces, which the clients can use.
> The compositor will know about a few widely used ICC profiles. In my proposal
> this is sRGB but we could also add e. g. a HDR profile. If the client wants to
> use one of these profiles it can just tell the compositor and use it. If the
> client wants to provide the surface in any other color space it has to create
> a matching color profile from an ICC profile. For that the client passes a
> file descriptor to the profile to the compositor. The file descriptor might
> correspond to a file on the hard disk (where it was installed by the client/
> toolkit/some third party) or to some temporary file created by the client. In
> the latter case the data might for example come from the embedded profile of
> an image or it might have been composed by the client.
>
>> Also, are there already libraries that can be user to parse the .icc files?
>>
>> I can see some recommended by ICC, like SampleICC, Argyll etc, is there
>> something which suits our case better?
> Yes, there are open source libraries to handle .icc files. You already
> mentioned ArgyllCMS. There is also LittleCMS which is easy to use and enough
> for a lot of usecases.
>
> Best regards,
>
> Ole
>
>> Regards,
>>
>> Ankit
>>
>> On 1/10/2019 9:31 PM, Niels Ole Salscheider wrote:
>>> Hello,
>>>
>>> on a first glance this sounds sensible. Would it work well with the last
>>> color management protocol proposal that I made or do you see issues
>>> there? We could add REC2020 as another predefined profile.
>>>
>>> https://lists.freedesktop.org/archives/wayland-devel/2017-January/032769.h
>>> tml
>>>
>>> I think the last proposal was mostly sane and usable for everybody, but
>>> there was not much interest afterwards. However, there was a lot of
>>> discussion with wishes from different sides that went into this. The
>>> relevant mailing list threads are the following, but you have to follow
>>> the discussion over the next months:
>>>
>>> https://lists.freedesktop.org/archives/wayland-devel/2016-November/031728.
>>> html
>>> https://lists.freedesktop.org/archives/wayland-devel/2014-March/013951.ht
>>> ml
>>>
>>> Best regards,
>>> Ole
>>>
>>> Am Donnerstag, 10. Januar 2019, 16:02:18 CET schrieb Sharma, Shashank:
>>>> Hello All,
>>>>
>>>> This mail is to propose a design for enabling HDR support in
>>>> Wayland/Weston stack, using display engine capabilities, and get more
>>>> feedback and input from community.
>>>> Here are few points (you might already know these), about HDR
>>>> framebuffers, videos and displays:
>>>> - HDR content/buffers are composed in REC2020 colorspace, with bit depth
>>>> 10/12/16 BPC. Some of the popular formats are P010,P012,P016.
>>>> - HDR content come with their own Metadata to be applied to get the
>>>> right luminance at the display device.
>>>>
>>>> - The metadata can be of two type 1. static 2. dynamic . For
>>>>
>>>> simplicity, this solution is focusing on static HDR only (HDR10 standard)
>>>> - HDR content also provide its supported EOTF (electro optical transfer
>>>> function) information, which is a curve (like SRGB gamma curve). One
>>>> popular EOTF is PQ(ST2084).
>>>> - HDR capable displays mention their EOTF and HDR metadata support
>>>> information in EDID CEA-861-G blocks.
>>>> - Normal SRGB buffers are composed in SRGB color space following REC709
>>>> specifications.
>>>>
>>>> - For accurate blending in display engines, we need to make sure
> following:
>>>> - All the buffers are in same colorspace (Rec 709 or Rec 2020)
>>>> - All the buffers are liner (gamma/EOTF removed)
>>>> - All the buffers are tone mapped in same zone (HDR or SDR)
>>>>
>>>> Please refer to the block diagram below, which presents a simple case of
>>>> a HDR P010 movie playback, with HDR buffers as video buffers, and SDR
>>>> buffers as subtitles. The subsystem looks and works like this:
>>>> - A client decodes the buffer (using FFMpeg for example) and gets the
>>>> two buffers, one with video (HDR) and one subtitles (SDR)
>>>>
>>>> - Client passes following information to the compositor:
>>>> - The actual buffers
>>>> - Their colorspace infromation, BT2020 for HDR buffer, REC709 for
>>>>
>>>> SDR buffer (planning to add a new protocol extension for this)
>>>>
>>>> - The HDR metadata of the content (planning to add new protocol
>>>>
>>>> for this)
>>>>
>>>> - Compositors actions:
>>>> - Reads the End display's HDR capabilities from display EDID. Assume
>>>>
>>>> its an HDR HDMI monitor.
>>>>
>>>> - Compositor tone maps every view's framebuffer to match tone of end
>>>>
>>>> display, applying a libVA filter. In this example:
>>>> - The SDR subtitles frame will go through SDR to HDR tone
>>>>
>>>> mapping (called S2H)
>>>>
>>>> - The HDR video frame will go through HDR to HDR tone mapping
>>>>
>>>> (called H2H) if the HDR capabilities of monitor and content are
>>>> different.
>>>>
>>>> - Now both the buffers and the monitor are in the same tone
>>>>
>>>> mapped range.
>>>>
>>>> - As the end display is HDR capable, and one of the content frame
>>>>
>>>> is HDR, the compositor will prepare all other planes for color space
>>>> conversion (CSC) from REC709->REC2020 using plane CSC property.
>>>>
>>>> - As the CSC and blending should be done in liner space, compositor
>>>>
>>>> will also use plane level degamma to make the buffers linear.
>>>>
>>>> - These actions will make sure that, during blending:
>>>> - All the buffers are in same colorspace (REC2020)
>>>> - All the buffers are linear
>>>> - All the buffers are tone mapped (HDR)
>>>> - The plane level color properties patch, for DRM can be found
>>>>
>>>> here: https://patchwork.freedesktop.org/series/30875/
>>>>
>>>> - Now, in order to re-apply the HDR curve, compositor will apply
>>>>
>>>> CRTC level gamma, so that the output buffer is non-linear again.
>>>>
>>>> - To pass the output HDR information to kernel, so that it can
>>>>
>>>> create and send AVI-info-frames to HDMI, compositor will set Connector
>>>> HDR metadata property.
>>>>
>>>> - Code for the same can be found here:
>>>> https://patchwork.freedesktop.org/series/25091/
>>>>
>>>> - And they will ever live happily after :).
>>>>
>>>> Please provide inputs, feedbacks and suggestions for this design and
>>>> plan, so that we can improve out half cooked solution, and start sending
>>>> the patches.
>>>>
>>>> +------------------+ +-------------------+
>>>>
>>>> | SDR Buffer subtitles | HDR Buffer video
>>>> | (REC 709 colorsp) | (REC 2020 colorsp |
>>>>
>>>> +-------+----------+ +-------+-----------+
>>>>
>>>> +------v---------------------------v------------+ +--------------+
>>>>
>>>> | Compositor: v | |
>>>>
>>>> LibVA |
>>>>
>>>> | - assigns views to overlays
>>>>
>>>> +---------> Tone mapping |
>>>>
>>>> | - prepare plane/CRTC color properties
>>>>
>>>> <---------+ SDR to HDR |
>>>>
>>>> | for linear blending in display
>>>> | |
>>>> | | HDR to SDR |
>>>>
>>>> +------+-----------------------------+----------+ +--------------+
>>>>
>>>> | Tone mapped | Tone
>>>> | mapped
>>>> | non-linear-Rec709 | non-linear
>>>>
>>>> Rec2020
>>>>
>>>> +------v------+ +-------v--------+
>>>>
>>>> SRGB Degamma | |EOTF as degamma |
>>>>
>>>> |(Plane) | |(Plane) |
>>>>
>>>> +------+------+ +-------+--------+
>>>>
>>>> Tone mapped linear Rec 709 | |
>>>>
>>>> +------v------+ | Tone
>>>> mapped
>>>>
>>>> | CSC/CTM | | non-linear
>>>>
>>>> Rec2020
>>>>
>>>> | REC709->2020| |
>>>>
>>>> +------+------+ |
>>>>
>>>> | Tone mapped linear |
>>>> | Rec 2020 |
>>>>
>>>> +------v-----------------------------v---------+
>>>>
>>>> | Blender |
>>>>
>>>> +--------------------+-------------------------+
>>>>
>>>> | Tone mapped linear Rec2020
>>>>
>>>> +--------------------v-------------------------+ Tone mapped
>>>>
>>>> | OETF(CRTC Gamma, post blending) |
>>>>
>>>> non-linear Rec2020 +------------------+
>>>>
>>>> | +----------------> | HDMI monitor |
>>>>
>>>> +----------------------------------------------+ +------------------+
>> _______________________________________________
>> wayland-devel mailing list
>> wayland-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
>
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
More information about the wayland-devel
mailing list