[patches] Add a color management framework to weston

[Pekka Paalanen]

On Fri, 5 Apr 2013 14:23:50 -0500
Thomas Daede <daede003 at umn.edu> 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.
> 
> 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
> work in higher bit depths - 16 bit, half float, or sometimes 32 bit
> float. It's much better to do conversion in the higher bit depth, then
> dither to the final display depth. Doing this with the compositor
> involves supporting all of these texture formats for subsurfaces -
> also, the toolkit has to support subsurfaces, because generally the UI
> will be some lower bit depth, or not need correction.
> 
> Converting bit depths in the compositor would also require an extra
> buffer allocation and copy in the compositor.
> 
> RGB images are also not the only thing that needs to be color
> corrected - for example, 10bit YUV video streams might want to be
> color corrected too. If we were to go as far as converting bit depths
> in the compositor, it wouldn't be much to add this.
> 
> 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.

I'm not sure we can do that. The regions can be arbitrarily complex and
non-linear shapes.

I also do not believe that solving the color correctness problem for
a single surface spanning more than one monitor is worth all the pain
and special cases, unless the color correction is done in the
compositor.

> > The compositor should be able to draw N polygons for the N
> > intersections of a surface with each output, each using a different
> > shader? You absolutely do not want to put an if based on a pixel
> > value into a glsl shader. It is really slow.
> 
> 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.

Weston already does it like that. Each output is a framebuffer, the
desktop as a whole is not.


Thanks,
pq