Re: [boost] GIL Review

From: Stefan Heinzmann (stefan_heinzmann_at_[hidden])
Date: 2006-10-31 16:32:36

Lubomir Bourdev wrote:
> Matt Gruenke wrote:
>> For example, a program or library that handles encoding/decoding of 
>> MPEG-4 video (non-studio profiles) has to deal with as many as 6 
>> variants of YUV, 4 transfer functions, and two different scales of 
>> sample values (without getting into things like n-bit profile).  In 
>> addition to that, professional video production systems will 
>> also have 
>> to deal with a variety of linear, non-linear, and log-scale RGB 
>> formats.  Add RGBA, and you also have to deal with whether Alpha is 
>> premultiplied.  Combined with a few different channel 
>> orderings and data 
>> layouts, I fear the result is such a multiplicity of 
>> combinations that 
>> the core purpose of GIL's color space construct would be defeated.
> 
> Hopefully my description above addresses all these examples. You don't
> need to create a custom color space for every combination of
> possibilities. These variations, which are mostly orthogonal to each
> other, are best addressed in different GIL abstractions, which are also
> orthogonal, such as custom channels and channel algorithms, custom
> pixels, pixel references and iterators, custom color conversion objects,
> views, etc.

Maybe it's just me but I find extending GIL to support something like
the v210 Quicktime format quite challenging (I don't want to imply that
this is GIL's fault). This is a 10-bit YUV 4:2:2 format which stores 6
pixels in 16 bytes. It appears to me as if trying to support it would
touch on a lot of concepts and corners of GIL, as it would require a new
pixel storage format, color space, component subsampling, and maybe more.

I believe it would help understanding if you could try to give at least
a road map of what needs doing to support this properly (a fully coded
example would probably require quite some effort).

Cheers
Stefan