[cairo] cairo_color_space_t

[Benjamin Otte]

On Tue, 2010-03-09 at 11:11 -0800, Bill Spitzak wrote:
> 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.
> 
My initial patches just extended the format enum. But when discussing
this, we feared an explosion in formats would happen if we kept doing
this (a8r8g8b8 vs a8r8g8b8_unmultiplied vs a8y8u8v8 vs a8y8u8v8_hd
vs...)
When I redid the patches I also realized that the pixman code could cope
way better with keeping format and color space separate. So by now I'm
very convinced that mangling this into the format enum is a bad idea.

Of course, this gives us a lot of stupid (format, color space) tuples
that most likely nobody will ever use, but that doesn't matter. Nobody
will use them anyway. And just like before, code will optimize the
important ones and ignore the other ones.

> 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?
> 
Yes. SD is supposed to be BT.601, HD is BT.709 and JPEG is the YUV
mapping specified by the JPEG standard.

> 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.
> 
No, this has nothing to do with interlaced, but with the fact that a
planar image consists of 3 separate images, one for each of Y, Cb and
Cr. And people want to be able to treat them as 3 separate images.
(Currently there's a de-facto standard for memory alignment for these
images that xv forced upon people, but quite a few embedded devices
don't conform to that.)

Cheers,
Benjamin