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

[Kai-Uwe]

Am 06.03.19 um 18:09 schrieb Sebastian Wick:
> 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.

Sorry for speak up lately. What is missed is black point compensation.
That is formal standardised and supported in almost any ICC color
engine. The ICC relative colorimetric intent is not much useful without
black point compensation enabled.

> 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.

All the same would have to apply too for surfaces with color space
'none' (, if you want). In the end, that is no point at all, or do I
miss something?

> 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.
>
> Which brings me to open issues:
>
> 1. Does it make sense to support device link profiles? I'm against it
>    but would love to hear if anyone has objections given that they are
>    supported in the other proposal.
pro device link:
* GPU color conversion for pro applications (print/theater proofing)
* handy for caching
* application decided look for arbitrary outputs from one surface
(currently not possible in X11)
* a surface can be mapped virtually anywhere without the client to know

Is the later wayland design goal still in force?

thanks,
Kai-Uwe Behrmann

> 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!
>
> 3. Do the standard color spaces actually improve anything? When the
>    compositor doesn't have to make them available to clients and they
>    can't rely on them being available, what's the point? Especially when
>    displays don't really support standard color spaces most of the time
>    (according to the EDID).
>
> 4. How do universal planes handle gamma when blending? This hopefully
>    has a sinmple answer and there probably is some documention which
>    I just can't find.
>
> There is some more open issues regarding HDR but I'll leave that to
> Ankit.
>
> Did I miss anything?
>
> Sebastian Wick (1):
>   unstable: add color management protocol
>
>  Makefile.am                                   |   1 +
>  unstable/color-management/README              |   4 +
>  .../color-management-unstable-v1.xml          | 189 ++++++++++++++++++
>  3 files changed, 194 insertions(+)
>  create mode 100644 unstable/color-management/README
>  create mode 100644 unstable/color-management/color-management-unstable-v1.xml
>