A solution for gamma-adjustment support in Wayland

[Mattias Andrée]

On Tue, 27 Dec 2016 11:23:34 -0700
Chris Murphy <lists at colorremedies.com> wrote:

> 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?

That client can specify which colour space/model it uses.

> 
> 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

I think it is important when when any non-final colour
space the resolution is at least 16 bits, and I'm fine
with the final colour space having higher resolution
than the size of the gamma ramps.

> get away with 8 bit per channel CIE L*a*b* but even
> that's questionable these days.

I would reject CIE L*a*b* because it requires more
expensive conversion and more than two conversion
steps.

> I'm pretty sure there is
> an agreed upon 8 bit encoding for Lab, but no agreed upon
> 8 bit encoding for XYZ.
> 

I think native ‘float’s or ‘double’s should be used.
They are only used internally on the computer
(or between computers that share a display) and
native representation will be cheapest time-wise.

> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20161227/d066ba53/attachment.sig>