Setting a color space for a wl_surface

[Erwin Burema]

> Wanted to post this to the list as an FYI for an implementation I did for
> setting the color space for a wl_surface. This has now been merged into the
> Chromium codebase. I was going to wait until this all settled out upstream,
> but needed something done sooner than that was likely to happen. I do plan
> to update this to whatever is settled on upstream when that happens.
>
> For the entire change:
> https://crrev.com/c/1934076
>
> For just the colorspace protocol:
> https://chromium-review.googlesource.com/c/chromium/src/+/1934076/6/third_party/wayland-protocols/unstable/color-space/color-space-unstable-v1.xml
>
> It's very straightforward, there's just one call to set the colorspace
> which takes 4 constants which correspond to the gfx::ColorSpace in
> Chromium. The values are for the primaries, transfer function, range and
> matrix.
>
> Cheers,
> Jeffrey Kardatzke
Hi,

I hate to break this news to you but that color space protocol is pretty awful
at least from a color management perspective (I also think it isn't that great
from a wayland perspective) for the following reasons

- A color space if fully described by its matrix + transfer curve (it is
  possible to derive the primaries and white point from just the matrix) or
  primaries + white point + transfer curve (you can derive the matrix from the
  primaries + white point)[1]
- For color management range doesn't matter (a display referred CM will always
  work on the [0.0,1.0] domain) (it might still be useful information
but strictly
  speaking doesn't belong in a color space)
- This protocol does not care for applications that need to work in the color
  space of the display itself (there is no feedback from the compositor at all
  which tells what the display output color space is), this is needed for either
  color accuracy (think programs that do stuff in CMYK that want to render as
  close as possible) or latency (think games)
- There is no way to set rendering intent (what to do with colors
outside the gamut)
- It isn't mentioned to be atomic (a set_color_space should only
become active after
  the next wl_surface.commit)
- Returning an error when one of the options isn't available is bad since there
  is no way to figure out which options will be valid (there will be compositors
  that only implement the basic color spaces), note that error are fatal (see
  https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_display
  under wl_display::error)

So I do think it is great that Chromium is working on color management support
but I would advice to revert this commit and try to implement the protocol as
proposed by Sebastian Wick
(https://lists.freedesktop.org/archives/wayland-devel/2019-November/040978.html)
. I know it currently is missing HDR support but that is because there is no
good way to describe HDR colorspace yet (there is nothing like ICC profiles for
HDR as of this writing, which is sorely needed)

Kind Regards

Erwin Burema


[1] I suspect gfx:colorspace gives both matrix + primaries out of convienence
(matrix for the transform, primaries to determine the boundry of the gammut)
because setting up a color space with sRGB primaries but an Rec.2020 matrix
doesn't make sense at all