[cairo] cairo_color_space_t

[Bill Spitzak]

Yes I do not think this should be called "color space".

I would prefer this enumeration and the pixel format to be merged into a 
single enumeration, actually. Right now it is going to allow nonsense 
combinations, such as YCBCR with a 1-channel pixel format.

Also as I said before it is extremely important that we be able to 
specify the current color as "matching this pixel in this image" and 
therefore we need an api to set the current color that takes this exact 
same information.

What is the difference between the three YCBCR formats? I'm guessing 
it's different math for arriving at the Y value from the RGB, correct?

Not really clear what the per-channel data pointer and per-channel 
stride do. My guess is that this is to allow both interlaced and 
non-interlaced formats, but there appears to be no way to indicate the 
spacing between the samples so interlaced is not possible.

Benjamin Otte wrote:
> On Tue, 2010-03-09 at 17:10 +0100, Benjamin Otte wrote:
>> The code adds a pixman_color_space_t enum that can be used to specify
>> the color space the values are in. Valid values so far are ARGB,
>> ARGB_UNMULTIPLIED, YCBCR_SD, YCBCR_HD and YCBCR_JPEG.
>> [...]
>> addition of the cairo_color_space_t enum
>>
> Another thing that I'd rather have in a seperate thread:
> 
> Andrea Canciani and I have talked about if we could do something more
> sophisticated than just exposing a simple color space enum, like the
> proposals that have been circulating on this list for a while.
> 
> I want to note that I think this is certainly nice to have and I would
> be very happy to see code written to make this more awesome, but I
> haven't seen any progress on this in the form of actual code. And so far
> Søren (and Carl, too, iirc) said that it makes no sense to expose an API
> for something that might or might not happen in the future.
> 
> Cheers,
> Benjamin
> 
> --
> cairo mailing list
> cairo at cairographics.org
> http://lists.cairographics.org/mailman/listinfo/cairo