[Pixman] [cairo] Planar YUV support
Øyvind Kolås
pippin at gimp.org
Sat Feb 26 03:36:46 PST 2011
On Fri, Feb 25, 2011 at 9:18 PM, Andrea Canciani <ranma42 at gmail.com> wrote:
> I would suggest the creation of a new opaque pixman type, pixman_format_t,
> that represents the format of a bits image with more flexibility than
> the existing
> pixman_format_code_t.
>
> To represent the existing formats (and many more, for example the x1a7r8g8b8
> format from https://bugs.freedesktop.org/show_bug.cgi?id=33741) a structure
> with the following fields would be sufficient:
> - bpp bits per pixel
> - n_components number of components
> - for each component:
> - shift the offset
> - bits the number of bits of the component
This sounds a lot like the system I ended up with using for GEGL, in
the utility pixel format enumeration and conversion library babl.
Having a fixed enumeration of formats will in the end only lead to
problems; while it is possible to dynamically extend the vocabulary of
color models, data types (number of bits, fixed point/floating point),
permutations of components as well as optimized and conformance tested
conversions. The speed of conversions with babl for optimized
conversions paths approximates a memcpy - which is also how it is
normally used in GEGL - making code paths that would be copying pixels
do implicit pixel format conversions if needed as well.
http://gegl.org/babl/
For the data type that sums up the PixelFormat .. in babl it is found in:
http://git.gnome.org/browse/babl/tree/babl/babl-format.h
IMO there is currently one minor design flaw in babl, and that is that
I made the gamma be part of the data types and not the color models.
It has no bearing on the use in practice but for organiing the
concepts involved it would be better to do the other way around.
Another issue is that there is only one YUV color model - and it is
not named properly, this however is a simpler thing since correctly
named ones are possible to add fully dynamically.
The license of babl is LGPL3 or later; relicensing of the code base
would however probably be possible.
/Øyvind K.
--
«The future is already here. It's just not very evenly distributed»
-- William Gibson
http://pippin.gimp.org/ http://ffii.org/
More information about the Pixman
mailing list