A solution for gamma-adjustment support in Wayland

[Chris Murphy]

On Wed, Dec 21, 2016 at 4:57 AM, Daniel Stone <daniel at fooishbar.org> wrote:

> I also cannot disagree more with your assertion that 'it's bad enough
> that colour management is done by the compositor'. The compositor is
> the very thing between clients producing pixels, and the final output.
> If a compositor is unaware of how those pixels should be interpreted,
> then it is going to be destructive and do the wrong thing. If you want
> colour-accurate display, there is no good solution based on the
> premise that your display controller should have no idea about
> colours.

Sure but there is something to be said about making assumptions,
rather than requiring everything to be explicitly tagged. There are
advantages of compositing only in device RGB, even though blending in
non-linear encoded spaces has negative consequences.

For what it's worth on Windows with their newer GDI+ API uses scRGB as
the intermediate space, and since circa 2009 it supports a 48 bpc
float encoding for this; I'm not sure what the default is these days.
It has advantages for HDR and the simplicity that the primaries are
the same as Rec 709/sRGB, but it is in some sense a relic of a world
converging on sRGB. And that's not true anymore, clearly now there is
great divergence away from sRGB. Does that imply a need for a work
around and if so what would it be? In terms of quantization you can
pick almost any set of primaries if you're dedicating enough bits for
the transforms. That used to be expensive, and I'm not sure that's
true anymore either.

Pretty much anything that's going to involve any substantially complex
blending is going to need to do it in linear space, so that implies
everything has to be specified by the application in linear space, or
something has to intercept it and convert it to linear space before
compositing and blending. And linear space encoding also necessarily
implies high bit depth to avoid noticeable quantization.

It was about a decade ago I asked about encoding precision, so and so
is using 16 bit per channel, and a developer from a good sized company
said something like, "16 bits is so last decade we're only using 32
bpc float now". So now it's 10 years later and 32bpc float is now "so
last decade" but of course the orders of magnitude involved are quite
a bit greater. Not everything needs this many bits pushed around, but
if it's an architecture that could suitably replace what color managed
apps already do internally now, then it's needed at least as an option
that they can opt into.


-- 
Chris Murphy