On Thu, 27 Nov 2014 15:58:51 +0100 Niels Ole Salscheider <[email protected]> wrote:
> Hi, > > > first a general question, since I'm at loss here on the big picture: > > How does all this relate to the cms-static and cms-colord modules > > already in Weston? > > > > Are those modules only about configuring the output's color space? > > And then this work simply leverages that to have some output color > > spaces to work with? > > > > Hmm, cms-static/colord set the gamma ramps..? So the hardware LUT? > > Yes, cms-static and cms-colord allow to get a color space for each output. > This is done by querying colord or by reading a static configuration from > weston.ini. > Without my patches, only the hardware LUT is programmed with the gamma ramp > from the corresponding profile. My patches reuse the existing modules to get > the profile data for each output but then to do full color correction. What happens if someone builds Weston with LCMS and full color management support, but does not load neither cms-static nor cms-colord? I'm not even sure how cms-static gets used since it's built as a static lib. > > On Mon, 27 Oct 2014 18:54:06 +0100 > > > > Niels Ole Salscheider <[email protected]> wrote: > > > On Wednesday 15 October 2014, 21:54:37, Bryce Harrington wrote: > > > > On Mon, Oct 13, 2014 at 07:40:47PM +0200, Niels Ole Salscheider wrote: > > > > > This implements the functionality to attach a profile to a surface > > > > > in weston. An LUT is built from the profile that can be used to > > > > > transform colors from the input color space to the blending color > > > > > space. > > > > > > > > > > An sRGB color space is assumed for all newly created outputs > > > > > > > > > > This patch uses the sRGB color space as blending space because it > > > > > uses 8 bit LUTs for now and I want to avoid additional banding. In > > > > > the long term we should use a linear blending space though to get > > > > > correct results. > > > > > > > > > > Signed-off-by: Niels Ole Salscheider <[email protected]> > > > > > --- > > > > > > > > > > Makefile.am | 3 + > > > > > configure.ac | 2 +- > > > > > src/compositor.c | 411 > > > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++- > > > > > src/compositor.h > > needed regardless of... of... where is the switch to disable color > > management support? > > It is enabled if weston is compiled with LCMS and disabled otherwise (or do > you see any reason why you would want to have LCMS but not full color > management?). I'm not sure. Maybe for hardware that has a hw LUT, but doing full color management would be prohibitively slow? Like with the Pixman renderer? Or maybe Raspberry Pi, although I don't think we program any LUTs atm. but I'd imagine it has a hw LUT somewhere. rpi-renderer cannot do color management with DispmanX. (Take the rpi-renderer as an example of a full hardware compositor, as opposed to an arbitrary rendering pipeline like OpenGL.) How would you handle these cases? This patch registers the wl_cms global if LCMS was available at build time. However, I think you need to make that conditional on the backend and renderer capabilities. If the renderer cannot do color management, it is useless to advertise wl_cms at all, because it won't have any effect at all, right? It would only fool apps to believe that they could get color managed output. Another thing I think this patch is missing, is making the DRM backend check for the color profile compatibility. If a surface needs color correction at all, the buffer cannot be scanned out directly and you need to make backends not put such surfaces on hw planes. The DRM backend currently does not use hw overlay planes, but it does use a cursor plane and the primary plane. A fullscreen window may get promoted to the primary plane which bypasses compositing and therefore also color correction. Oh btw. would apps want to know if an output's color profile is "unknown"? That is, the compositor just assumes it's sRGB because it has no information about it. I could imagine some apps wanting to show a warning about unmanaged output in that case, maybe? Thanks, pq _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
