Setting a color space for a wl_surface

[Erwin Burema]

On Tue, 10 Dec 2019 at 23:25, Erwin Burema <e.burema at gmail.com> wrote:
>
> > 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

Probably should have put Jeffrey Kardatzke on the CC, fixing that now