A solution for gamma-adjustment support in Wayland

[Chris Murphy]

On Mon, Dec 26, 2016 at 11:00 PM, Mattias Andrée <maandree at kth.se> wrote:

> On Tue, 27 Dec 2016 16:25:20 +1100
> Graeme Gill <graeme2 at argyllcms.com> wrote:
>
> > Hi,
> >
> > Daniel Stone wrote:
> > > 'The size and depth' and 'the CLUT' are no longer
> > > applicable. Colour management units, incorporating two
> > > LUTs and a matrix (coarsely, degamma-transform-regamma)
> > > are becoming rather common now. These units can be
> > > present per-plane as well as per-output/pipe. Sometimes
> > > you have to make tradeoffs.
> >
> > Just because some hardware is a lot more capable, is no
> > reason to ignore supporting currently expected
> > functionality.
> >
> > Simple per channel hardware lookup tables have been
> > supported by graphics card software for a very long time
> > (Our X terminals in the late 80's certainly had them), so
> > this level of support can be assumed as almost universal,
> > and there are well understood reasons for using such
> > hardware to set the state of the display for color
> > management purposes at least (which I have articulated
> > elsewhere). Usage of further HW capabilities (matrices
> > etc.) are much less clear - no application interested in
> > fully utilizing a displays best possible gamut has any
> > use for them (since they can only reduce the gamut),
>
> Ideally I think the display server should support sRGB,
> CIE XYZ, and the monitors' native RGB for input.


What does "support" mean in this context?

sRGB is defacto on it's way out the door because manufacturers are pretty
much all diverging from this color space now, while cameras purport to
render image to it. So the situation is pretty awful for wide scale assumed
color space workflows. You can reliably do assumed color space workflow
internally in a tight closed loop situation; but for the broader open
workflow every object and device has to be tagged with a color space or
there will be partial data loss (color fidelity)

As for CIEXYZ, to literally convert pixels into this space, or even as an
exchange space, it will require minimum 16 bits per channel or there will
be noticeable quantization. It's a huge color space. You could maybe get
away with 8 bit per channel CIE L*a*b* but even that's questionable these
days. I'm pretty sure there is an agreed upon 8 bit encoding for Lab, but
no agreed upon 8 bit encoding for XYZ.



-- 
Chris Murphy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20161227/0b23ee03/attachment.html>