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.
>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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk