[cairo] [RFC] Color space API (partial proposal)
spitzak at gmail.com
Sat Feb 27 15:25:14 PST 2010
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
> 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
More information about the cairo