A solution for gamma-adjustment support in Wayland

[Daniel Stone]

Hi Graeme,

On 27 December 2016 at 05:25, Graeme Gill <graeme2 at argyllcms.com> wrote:
> 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), and there is much more flexibility in
> dealing with non color managed applications in the applications
> and/or compositor, so that they can co-exist with full color aware
> applications.

I'm deeply aware of the history of flat 8-bit LUTs in display
hardware, and am not proposing to throw them away. There are valid
usecases for the matrices, and I suspect some of your views on more
advanced hardware capability may change if you were more aware of the
details of how they work. The output of the pre-matrix LUT, the matrix
calculations themselves, and the input of the post-matrix LUT, are
generally in a deeper format; signed 1.16 is common. So there is no
sacrifice of precision involved.

>> 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.
>
> I'm not sure what you are thinking of here - the existing per channel
> VideoLUT API's are universally simple, and the only temptation in
> making changes to this might be in the direction of better coordinating
> competing use of this shared resource.

I also remember colourmap fighting, and have no desire to go back
there. It's my opinion that the only way to resolve this is to assign
responsibility in a way which avoids this. The compositor / display
server is today the only component which is aware of the _full_ output
chain (again, it's not a strictly 1:1 mapping from pixels in a flat
global co-ordinate space to pixels on a single CRTC), and it's also
the only component which directly controls the display hardware.

I do not for the life of me understand why 'the compositor must be
totally passive in colour management' is being proposed as the only
possible design. I understand how it has come to be the solution with
X11 et al, but again, square peg / round hole.

> I agree that expanding such API's to encompass more advanced HW capabilities is
> something of a project, and might not even be a good direction to proceed
> if other alternatives are a more enticing use of time and effort (installable
> shaders in the rendering pipeline ??)

I find it odd that you believe anything other than a single flat 8-bit
LUT to be a waste of time, yet you're suggesting piping user-supplied
shaders through.

Fundamentally, the design proposed here is to abstract responsibility
away, and to bake in assumptions about hardware which no longer match
reality. For instance, if we are able to use 10bpc output, then our
choice with this design would be to not use the LUT at all, or to
discard the extra precision by quantising to 8bpc. Neither strike me
as a great path forward.

Baking in API is expensive, and it does not fill me with confidence
that the suggestions in this thread involve removing all knowledge to
an external component which is fundamentally crippled from day zero.

Cheers,
Daniel