spitzak at gmail.com
Tue Mar 9 11:11:58 PST 2010
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
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.
> cairo mailing list
> cairo at cairographics.org
More information about the cairo