[PATCH 2/6] Attach input profiles and build corresponding LUTs

[Pekka Paalanen]

On Thu, 27 Nov 2014 15:58:51 +0100
Niels Ole Salscheider <niels_ole at salscheider-online.de> 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 <niels_ole at salscheider-online.de> 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 <niels_ole at salscheider-online.de>
> > > > > ---
> > > > > 
> > > > >  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