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