[patches] Add a color management framework to weston

[Graeme Gill]

Thomas Daede wrote:
> I am not sure that doing the color conversion in the compositor is the
> correct place. Some of it has to be there to support vcgt, but for
> more general conversions, it gets complicated quickly.

Hi,

The expectation is that vcgt is per output (ie., it's loaded into
the display cards RAMDAC), or loaded into the display itself
using DDC. The display device color profile assumes this.
So vcgt shouldn't need shaders.

> Color correction is most important for artists doing work in something
> like the GIMP. Programs like this (as of GIMP 3.0, at least) generally

As well as this, there is a desire to color manage all GUI elements
on a wide gamut display, to avoid a rather garish and hard to read
result.

> I think that providing color space regions to the client, relative to
> the client's buffer, including vcgt settings, would shove a lot of
> complexity away to clients that are already used to dealing with it.

One of the things driving the idea of tagging a colorspace and
letting the display system handle color management by default, is
that many/most applications don't deal with it. So I think that the
idea of shoving off the learning curve about color to a larger group of
applcation writers is not likely to be successful.

> This is the correct way, I think. Splitting surfaces by monitor also
> has other unrelated benefits, like being able to sync separately to
> each monitor - it probably should go somewhere else.

Application writers particularly do not like dealing with the
messiness of color managing their graphics elements when they
happen to fall across more than one output. A number of applications
get color management right on a single display, and fail badly with
more than one display.

Graeme Gill.