[cairo] [RFC] Color space API (partial proposal)

[Bill Spitzak]

Jonathan Morton wrote:

> Also, I'm ignoring the video-oriented formats as mere convolutions and
> compressions of RGB.  AFAIK, you can't treat a YUV420 (for example)
> image as a destination directly, only as a source.

This is a good point. These are not "color spaces" as far as color 
management is concerned. You cannot mix in YUV numbers directly (because 
black is not 0,0,0) so it cannot be a usable blending space.

> 2) Introduce an extended operation, which replaces the traditional D =
> (S * M) OP D with D = (colour(S) * M) OP D.  The colour(S) operation
> is a colour-management transform specified by the user, and the
> operation is legal as long as the result of colour(S) would be legal
> for the source operand in a normal operation.

As far as I can tell this is exactly what is proposed. The function 
colour(S) however is not directly specified by the user, but is chosen 
by Cairo to translate the color space of S to the color space of D. If 
the transformation is the identity this then is the same as normal 
behavior without the function. Cairo must detect that this is the 
identity and make that code path fast.

The change in api is that all colors sent to Cairo have a color space 
attached to them, and all surfaces have a "blending" space. There may 
also be a conversion from the blending space to the device color space 
when the drawing is finally put on the screen.

> Naturally, printers will probably want to do some post-processing on
> the final image to make it more suitable for the printer - they might
> even convert it from CMYK to one of the extended formats, or vice
> versa, to produce a better result.

I think this is intended. The printer is supposed to convert "blending 
space" to the actual device.

> Or they might perform a
> normalisation on the channels (eg. x=min(C,M,Y); CMY -= x; K += x;)

I got the impression that this is *not* wanted. If they wanted that the 
user would leave the blending space at the default of sRGB. This sort of 
modification is done when converting colors between spaces. Once it is 
in the printer's space then exact control over the levels is allowed.

> As far as implementation is concerned, we really just need to extend
> Pixman to deal with arbitrary numbers of colour channels (from zero up
> to, say, eight), plus an optional alpha channel.

That is my hope but I have not gotten a clear answer about this. I would 
like the color experts to indicate if "blending space" means that linear 
add and multiply of the values are expected to work in this space. The 
alternative is the color space provides the function but that seems 
unworkable to me and would make it impossible for Cairo to add new 
compositing functions.

> This gets a lot less
> cumbersome if we manage to fix a channel order (eg. RGB versus BGR is
> already a Problem).  As long as the channels match up, Pixman doesn't
> need to know what each one means.

ABGR is only for 8-bit data and is a special case due to how hardware is 
designed. There is also xBGR 3-channel data that must also be supported.

I think any data size larger than 8 bits can be stored in channel order 
with alpha on the end. The questions that need answering are padding (to 
a power of 2 or a multiple of 4 needed by many vector processors) and 
non-interlaced channels.