[RFC wayland-protocols v2 0/1] Color Management Protocol

[Pekka Paalanen]

On Wed,  6 Mar 2019 18:09:27 +0100
Sebastian Wick <sebastian at sebastianwick.net> wrote:

> Sending in v2 with small fixes only. I'm using this in the hope to focus
> the previous discussion in the direction of the actual protocol and
> implementation.
> 
> It looks like we have come to at least some consensus on a few points.
> If anyone disagrees here that would be great to know.
> 
> 1. The color management protocol should contain support for HDR. I've
>    previously argued against it but everyone else seems to agree and I
>    don't have a strong opinion.
> 
> 2. The whole pipeline should look something like
> 
>    [surface cs] -cs conversion-> [output cs] -tone mapping-> [output cs]
>    -degamma-> [output linear cs] -blending-> [output linear cs] -gamma->
>    [output cs].
> 
>    Where some parts can be skipped if e.g. surface cs == output cs or
>    surface and output are SDR.
> 
> 3. A CMS (like lcms2) can create a 3d lut which the pipeline can use to
>    do the color space conversion from two 3 channel ICC profiles and a
>    rendering intent.
> 
> 4. A CMS can also create a 1d lut from the same data to linearize a
>    surface from the output color space (degamma, gamma).
> 
> 5. Device link profiles don't offer enough information to correctly do
>    blending and convert to a random output color space.
> 
> 6. The client should know which color spaces the surface is likely going
>    to be converted to.
> 
> 7. The CRTC gamma lut belongs to the compositor and no client should be
>    able to directly change it.

Hi Sebastian,

all the above sounds good to me.

> Which brings me to open issues:

> 
> 2. How exactly should the client be informed of the "prefered" color
>    spaces?
>    IMO there are a few requirements:
>    * the client should know when the prefered color space changes
>    * the client should know when multiple color spaces are involved
>    * the priority of those color spaces
>    The single "prefered" color space that can be requested doesn't meet
>    those requirements, neither does the wl_output.enter/leave (missing
>    priority) nor does my protocol (moving the surface to another output
>    will not trigger any new events).
>    Another point here is that wl_output actually doesn't map to a single
>    but multiple color spaces (e.g. cloned display).
>    Better ideas are very welcome!

Actually, a single wl_output should correspond to a single monitor...
if you are to believe my clone mode implementation in Weston. I think
that is still not fully decided on how cloned monitors should be
exposed. My rationale is based on wl_output exposing the monitor make
and model.

If you take color spaces instead of wl_outputs, then that issue
disappears.

Let's say you find a way to expose a priority list of color spaces that
the compositor would prefer. It will not exempt the compositor from
having to support arbitrary color spaces from custom ICC profiles with
three channels. How would a client choose what color profile to use?

I'm thinking this:

- If the client cannot do color transformations efficiently itself or
  doesn't care, it picks whatever color space its content already has.
  The compositor can probably do it much more efficiently.

- If the client can do color transformation efficiently or even produce
  the content in any given color space, it would want to pick the color
  space that saves the compositor's work the most.

What kind of use case am I missing where it would be beneficial for the
client to have a priority list to choose from?


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20190312/161ab92c/attachment.sig>