[cairo] Color space API
spitzak at gmail.com
Wed Aug 1 12:34:14 PDT 2012
>> Does that mean that other backends (X11, gl, win32, quartz) would have to fall
>> back to the image backend whenever a color space is involved?
I think this is the big confusion about any color space api. I believe
the answer is "no" for what you are thinking of.
(At least this is my understanding, please somebody correct me if I am
wrong, but personally I really hope I am right, otherwise cairo will be
a nightmare to use...)
The color space setting of any destination image, such as an on-screen
window, has ZERO effect on how numbers stored in that image are placed
onto the screen. In the typical case where the destination image is 3
8-bit channels, and your screen's buffer is 3 8-bit channels, the
numbers for opaque pixels are copied UNCHANGED from the destination
image to the screen buffer.
This also means that changing the colorspace of a destination image is
allowed, and does NOTHING to these numbers and nothing to what you see
on the screen. Changing to any colorspace and then back to the original
colorspace is always a lossless operation.
When compositing from a source image TO a destination, the only thing
that matters is the transformation between the source and destination
colorspace. If this is the identity then this can be really fast.
If it is not then the backend may want to do the conversion. However I
expect Cairo will provide fallback conversions, just like it does when
the source image is 16 bits.
> Assuming that the drawing model is the same as PDF (and that I
> understood it correctly), the colorspace in which the blending is
> performed is the same as the destination one.
> This means that the only color conversion is from source colorspace to
> destination colorspace.
> Moreover if they are the same, the conversion is not needed at all and
> compositing can be performed forgetting about colorspace and no
> fallback is needed even for backends which do not have netive support
> for colorspaces.
This pretty much agrees with my understanding.
> (Ok, I'm cheating a little, this is only true for separable
> compositing/blending operators...)
I believe the compositing operations are (and should be) defined as how
they act on the numerical values of channels of the image. For instance
if some operation multiplies the first channel by .299, the second by
.587, and the third by .114 and then adds them together, it ALWAYS does
this, irregardless of what the destination color space is.
It is true that what I described above only produces "grayscale" for a
*linear* RGB color space using obsolete primaries defined in 1933. I
think the fact that this is used without complaint on different sRGB
primaries and non-linear sRGB channels is proof that exact color space
definitions are not wanted. If a different colorspace grayscale is
wanted then that should be a different compositing operation, not part
of the destination colorspace.
In a similar way I think the "linear compositing" should be fixed to do
the "right" thing only for sRGB.
More information about the cairo