[cairo] [gst-devel] Planar YUV support

[Benjamin Otte]

On Tue, 2010-03-09 at 10:36 -0800, Michael Smith wrote:
> On Tue, Mar 9, 2010 at 9:00 AM, Arjen Nienhuis <a.g.nienhuis at gmail.com> wrote:
> > I think pixman_color_space_t is not the right name. It's ambiguous
> > because color space can also mean sRGB vs AdobeRGB. What about
> > 'encoding'?
> 
> pixel_format would probably be a better name if it's _only_ intended
> to encode the pixel format. I think Benjamin's intent, though, was to
> encode a pair of "pixel format, colour space" in a single value.
> That's why his suggestion has YCBCR_SD and YCBCR_HD - these have the
> same pixel formats, but imply a different colour space.
> 
I've started to think about image data as an N-dimensional cube. N
denotes the number of channels in the image, so for RGB it's 3, for grey
it would be 1.
There's various additional informations about that, like how many
different values there are per dimension (256 in most cases these days
for RGB32) and how they are put into the memory of your computer (This
is what RGB vs BGR or planar vs packed is all about). This is encoded in
pixman with the pixman_format_code_t enum.

There's a separate question to all of this and that question concerns
itself with what color one such value actually represents. So far in
RGB-land, people were content with claiming that (0, 0, 0) is "black"
and (max, max, max) is "white". However, this isn't true anymore once
you want to support YUV - where (0, 0, 0) is dark green. So I used the
pixman_color_space_t to encode this meaning for my purposes.
There have been a lot of proponents for making this a universal anything
to encode anything from sRGB vs AdobeRGB to ICC profiles and spot colors
with this value, but as I said in a separate mail already: So far noone
wrote any code yet.

Cheers,
Benjamin