[RFC wayland-protocols] Color management protocol

[Niels Ole Salscheider]

On Wednesday, 21 December 2016, 11:39:50 CET, Graeme Gill wrote:
> Pekka Paalanen wrote:
> > When one integrates a CMS in a compositor, you no longer need to
> > expose configuration (hardware configuration, like CLUT programming)
> > via any protocol. The compositor talks directly with the CMS and if the
> > compositor can set e.g. CLUTs, CMS can tell it what to set.
> 
> "cLUTS" are things in the ICC profile (Color, or multi-dimensional lookup
> tables.) and are typically used (as part of a conversion) to represent a
> device response or an overal color transformation.
> 
> VideoLUTs are in the graphics hardware (CRTC), and involve the setup
> ("calibration") of the display. ICC profile handle some aspects
> of the display badly - namely white point setting, which has
> been (deliberately) crippled in the ICC format, so setting the hardware
> per channel Lookup tables is the way to work around that,
> as well as having the benefits of ensuring that even non-color
> aware applications all have a consistent white point and visual
> transfer curve.
> Without this, mixed visual white adaptation will destroy the usefulness
> of the display.
> 
> An additional subtlety is that in typical hardware, the VideoLUT entry
> depth is greater than the frame buffer depth, so setting the overall
> visual transfer curve and neutral axis matching using
> the VideoLUT has the advantage of extra precision (typically 2 or
> more extra bits, quite noticeable on 8 BPP frame buffers). Because
> the VideoLUTs are global to each display, all the applications get
> the benefit of this, and it makes the profile more accurate by making
> the display better behaved
> 
> There is a de facto standard in ICC profiles that display
> profiles may include a tag that stores the display expected
> VideoLUT values ('vcgt' tag), and since the contents of
> the display profile are built on the assumption of that
> set of calibration curves, systems typically install
> that vcgt tag contents in the VideoLUTs when a profile
> is set to be the one for that display.
> 
> But, to actually create the calibration curves, a color
> calibration and profiling application needs to be able
> to set the VideoLUT contents to specific values. Other
> useful functions are to be able to read the VideoLUT
> values, to be able to verify that the calibration is as
> intended.
> 
> (A little more information is here:
>  <http://www.argyllcms.com/doc/calvschar.html>)

If the resolution of the frame buffer was high enough we could just apply the 
VideoLUT in software when we also apply the display profile and leave the 
hardware LUT alone. You could then profile the screen by setting the device 
link profile of your surface to the identity mapping without any vcgt tag.

But I agree that we want to program the VideoLUT as long as we use 8 bit 
framebuffers. We normally do not want to allow applications to change the 
VideoLUT since that would have an influence on all applications and a broken 
application might mess with it in some unintended way.

Maybe the solution for profiling would then be to just use KMS for fullscreen 
display and bypass the compositor completely? The profiling application could 
do whatever it wants to the hardware and the compositor would then restore the 
proper state when it is started again...

> > I am assuming that the compositor can interface with a CMS by calling
> > into a library offered by the CMS. If that interfacing was previously
> > done over X11, then you have to write that library. It will be more
> > efficient too, since you don't have to serialize and deserialize, and
> > asynchronicity (problems) appear only when you want to.
> 
> In X11 the VideoLUT setting/reading is done via XF86VidModeQueryExtension
> (old) or XRandR (current). Typically the system color management support
> will track the currently installed display profile, and set the
> VideoLUT hardware (Gnome colord), or users will invoke
> an equivalent utility at system startup (dispwin, xcalib etc.).
> Such utilities also typically set an X11 atom or Output property
> so that applications can obtain the display profile.
> 
> Note also that there are more things that an application
> may want out of the current display profile than simply
> the ability to transform into that space - they may
> want to determine the color gamut, they may wish
> to tag a window capture with the colorspace it is in, etc.
> 
> > I'm slowly starting to suspect that CMS designers need a slight paradigm
> > shift: the compositor is meant to integrate with the CMS, instead of
> > the CMS given low-level access to the hardware bypassing the window
> > manager. CMS is no longer something that can be bolted on externally,
> > like it is in X11. Embrace the idea of integration, and I belive and
> > hope that it will pay off as a much more reliable architecture and
> > polished user interfaces. Some of what used to go over X11 would
> > probably be much better as a library ABI, but in X11 times it was not
> > possible because X11 implied separate processes.
> 
> There is scope for moving in that direction, but care needs
> to be taken not to reduce functionality as a consequence.
> 
> The chicken and egg problem remains - how do color management
> applications exercise the hardware to create calibration curves,
> as well as help manage the display color configuration by
> installing profiles, etc. ?
> Without the ability to create the calibration and profile,
> you don't have a color managed system.
> 
> Graeme Gill.
> 
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel