[cairo] [gst-devel] Planar YUV support

Kai-Uwe Behrmann ku.b at gmx.de
Wed Mar 10 04:07:05 PST 2010

Am 10.03.10, 11:03 +0100 schrieb 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.

You mean you did not write a pixman_color_space_t type. Given that there 
is repreatedly interesst in a qualified colour API in Cairo, it would 
be quite useful not to enter the term "color space" for some fixed meaning 
enums in opposite to a generic flexible system.

Btw colour characteristics of BT.601, BT.709 and friends can be decribed 
with ICC profiles.

kind regards
Kai-Uwe Behrmann
developing for colour management 
www.behrmann.name + www.oyranos.org

More information about the cairo mailing list