Brainstorming/Comparison of candidate Color and Lightness modes

Update 2013-03-20 The W3C have now settled on a standard way of doing Hue, Huminosity, Saturation and Color modes, now published as [Compositing and Blending 1.0]. The OpenRaster specification has been updated to refer to these algorithms, so the following brainstorm is of historical interest only.

The (former) problem
There's no way of making different programs' perceptually-relevant lightness/brightness/luminance/luminosity layer modes interoperable using the OpenRaster specification, which has historically defined its layer compositing modes only in terms of the values permissible for the SVG Compositing Specification's comp-op property. Valid values for OpenRaster are formed by taking the values defined for comp-op and prefixing them with a svg: namespace string. The value  is used for unrecognised values.

As of 2011-03-15, SVG and OpenRaster do not define any kind of non-separable blend modes. We should at least define a mode allowing the lightness of the source layer to be assigned to the target layer, and a mode which allows the hue and saturation of the source to be applied to the target layer, and make them an implementable part of the OpenRaster specification.

(Former) Candidate algorithms

 * naive-hsv
 * Naive value assignment in the HSV colourspace. MyPaint works in HSV a lot, and this algorithm is simple and doesn't require gamut mapping, clipping or scaling. However the colour space is not perceptually relevant; examples are included for comparison purposes only.


 * cairo-compat
 * Compatible with Cairo's CAIRO_OPERATOR_HSL_COLOR and CAIRO_OPERATOR_HSL_LUMINOSITY operators, as defined by the documentation for Cairo's compositing operators, and also in various PDF compositing specifications. It is likely to be similar to the way old versions of Photoshop worked, which is interesting when considering interoperability, but this of course is impossible to verify without access to the source code. This scheme is very well defined and widely implemented, and is perceptually relevant; however it uses coefficients from an older display equipment specification which are perhaps less well suited to common sRGB displays than the updated version. The difference between use of the Rec. 601 and Rec. 709 coefficients is in practice rather slight as the examples show. Another drawback of this approach is that it doesn't allow for wide gamuts and colour management: it's defined as an operation in Rec. 601 RGB space, so strict implementations will have to map through that rather narrow gamut, and may lose information as a result.
 * Update 2012-07-26: the W3C seem to be favouring this approach in CSS drafts. I'm not sure choice of coefficients really matters, although it would be helpful if we used the same ones everywhere within MyPaint (new HCY selectors, brush blend modes etc.) And as for the operation being defined against a limited RGB space, I'm not sure that matters. If a value is unclipped during this transform when working in two different colour spaces under end-to-end colour management, its absolute colour would remain unchanged, yes? --Achadwick 18:52, 26 July 2012 (UTC)


 * perceptual-*
 * To counter the drawbacks of the tightly defined algorithm we're calling cairo-compat for fancier programs with wide gamuts and colour management, it may be wise to permit implementations to use any colour space they choose, provided it's perceptually relevant. Let's define it for the purposes of the OpenRaster specification as: first assign the lightness values of pixels in the top layer to the corresponding pixels in the bottom layer, using any colourspace which has a perceptually relevant lightness dimension. This will cause colours to go outside displayable gamuts, so implementations should as a second step deploy gamut clipping or scaling to return pixels to displayable RGB values. Alternatively, for the purposes of detecting out-of-gamut values on screen, they can be highlighted with user-settable colours.
 * MyPaint might end up using a transformation in a YCbCr space derived from its internal RGB representation, at least initially. We don't do colour management, but mapping via YCbCr should be adequate for artists' needs in the short term.
 * The cairo-compat method above may be suitable too. However the lightness-setting mode differs quite a bit in appearance.
 * Recent versions of the GIMP use a much more complicated transformation in LCHab space, a cylindrical representation of CIE 1976 L*a*b*.

None of these, of course, define how the colour derived from the top and bottom layer colours is to be combined with the bottom layer.

Examples
The examples below use linear light (current MyPaint master does not, but then again it doesn't attempt fancy colour and luminance manipulations).