[boost] Quicktime v210 format support (Re: GIL Review)

From: Matt Gruenke (mgruenke_at_[hidden])
Date: 2006-11-01 00:13:33

Lubomir Bourdev wrote:

> 
>Stefan Heinzmann wrote:
>  
>
>>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.
>>    
>>
>
>Stefan,
>
>This is an excellent example for a very complicated image format.
>  
>

It's an example of the sort of thing I mentioned in parts of my review.  
Though you seemed to focus mostly on the complex packing, I do 
appreciate your illustration of this case.

>Here is a rough plan of how I would approach modeling this in GIL:
>  
>

Sorry to nitpick, but in case you're adding any of this to GIL...

>1. Provide yCrCb color space
>  
>

I believe there exist component formats with the channel order Y'CrCb.  
However, when referring to the family of digital component video 
formats, I think the order Y'CbCr is preferable, as it matches the 
common (though less precise) Y'UV nomenclature.

In the past, the digital video community largely discouraged use of the 
term Y'UV, since it was only defined for the analog domain.  However, 
having been used pervasively in standards, such as ISO/IEC 14496 (aka 
MPEG-4), as well as in many implementations, the term Y'UV (or YUV) is 
here to stay, and should be treated as an imprecise substitute for 
Y'CbCr (and perhaps a couple other color difference coding formats based 
on B' - Y' and R' - Y').

So, unless Y'CrCb serves to define a pixel format with that specific 
ordering, I'd stick with Y'CbCr.  The Quicktime docs you cited even 
define v210 as the "Component Y'CbCr 10-bit 4:2:2" codec.

>Its dereference will return a reference to the appropriate channels.
>For example, the fourth pixel uses:
> For Y': bits [22..31] of the 3rd word
> For Cb: bits [2 ..11] of the 2nd word
> For Cr: bits [12..21] of the 3rd word
>  
>

Almost.  If you just wanted a rough approximation, that would be better 
than nothing.  However, the chroma phase for Y3 is actually half way 
between C1 and C2.  Of course, using standard video interpolation 
(windowed sinc), you would need to access many chroma samples on either 
side.

This could be used to demonstrate an interpolating iterator.  But, if 
you wanted the easy way out, your example should have used Y0, Y2, or Y4!
;)

>You should be able to run carefully designed generic algorithms directly
>on native v120 data.
>  
>

Mostly what I'm concerned with, when using non-4:4:4 sampled data, is a 
descriptive container format.  My needs don't extend much beyond 
applying the proper (and most minimal) conversions, when necessary.  
Most processing of component video formats (especially those with 
subsampled chroma) is independently applied to each channel (e.g. 
resampling, DCT, IDCT, etc.).  Because the components are nonlinear 
quantities, you can't do much else.  Even seemingly simple operations - 
such as adjustments of brightness, contrast, hue, & saturation - are 
only approximations, in Y'CbCr.

Matt