[patches] Add a color management framework to weston

[Pekka Paalanen]

On Wed, 1 May 2013 17:03:30 -0400
Kristian Høgsberg <hoegsberg at gmail.com> wrote:

> 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.

Sorry, I read "providing color space regions to the client" as "the
server determines the areas of each output overlapping with the
surface", and communicated that to the clients.

If the regions are communicated from clients to the server direction
only, then nevermind my comment.


Thanks,
pq