On Tue, 10 Dec 2019 at 23:25, Erwin Burema <e.bur...@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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel