A solution for gamma-adjustment support in Wayland

[Mattias Andrée]

On Wed, 21 Dec 2016 10:40:44 +0000
Daniel Stone <daniel at fooishbar.org> wrote:

> Hi Mattias,
> 
> On 14 December 2016 at 00:20, Mattias Andrée
> <maandree at kth.se> wrote:
> >     There should also be a protocol for identifying
> > whether a VDC have CLUT that can be edited, and whether
> > the compositor supports cooperative gamma. The size and
> > the depth of the CLUT should should also be
> > retrievable. Since cooperative gamma is supported, the
> > size and depth of the CLUT can exceed the controller’s
> > CLUT for better results when output filters are chained
> > together.  
> 
> '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.
> 
> For instance, on recent Intel hardware, you can have the
> matrix with 10-bit LUTs on either side with 512 entries
> each, or you can have the matrix with only _one_ 10-bit
> LUT (either pre- or post-matrix) which can now contain
> 1024 entries. The weighting for interpolation between
> entries can be programmable, and the last entry in the
> post-matrix LUT is used to deal with overshoot, as the
> matrix can produce values in the range of [-3.0,3.0].
> 
> Tegra is pretty similar, except that its indexing into
> the LUT is very much non-uniform; the tradeoff for
> simplicity is that it's a fixed 8-bit -> 12-bit LUT
> pre-matrix, and the reverse post-matrix; wider colour
> modes are not supported. NVIDIA's desktop hardware is a
> black box to me, but their technical marketing material
> (if nothing else) very strongly suggests that they have
> something very similar. AMD hardware (CIK, at least) has
> roughly the same similar functionality, except it's not
> supported with the open driver.
> 
> The point is that I'm extremely wary of copying X11 by
> way of encoding this into an API; it's a truly dizzying
> space to even enumerate, let alone abstract.
> 
> Cheers,
> Daniel

I think at the very least want I have suggested should
be implemented. However, adding the functionality to
transform the values via matrix multiplication as well
is probably a good idea. If matrices and ramps are
combined into the same chain, what more could possibly
be added. Abstraction is easier than enumeration in this
case, if the transformation can be handles by the
graphics card, let it do it, otherwise, do it before.

If there is no API for these thinks, functionality
such as inverting the colours, lowering the temperature,
and (requires matrices) simulating defective colour
vision must be done in the compositor. This is not
a sustainable solution, an API is necessary. It's bad
enough that colour management is done by the compositor.

-------------- 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/20161221/1fd340f9/attachment.sig>