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