[patches] Add a color management framework to weston

[John Kåre Alsaker]

I'd suggest that client should use subsurfaces if they want multiple
colorspaces in a window. They might have to do that anyway since they may
want a different pixel format.


On Thu, May 2, 2013 at 8:58 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:

> 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
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20130502/39b7676e/attachment.html>