Re: Color space API

>> 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.

-- 
cairo mailing list
[email protected]
http://lists.cairographics.org/mailman/listinfo/cairo