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