[patches] Add a color management framework to weston

[Kristian Høgsberg]

On Mon, Apr 22, 2013 at 01:30:28PM +0300, Pekka Paalanen wrote:
> 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.

It's not too different from how we handle opaque regions.  We split up
the surfaces into opaque and transparent parts and render them using
different shaders already.

Kristian