RFC: Bayer RGB Pixel type

[Steve Sisak]

The last (and most important) pixel format I'd like to have defined 
is Bayer RGB.

This is more complicated because it requires defining an 
ImageDescriptionExtension and there are a multitude of opportunities 
3rd parties to provide faster/better codecs.

My hope is to define a good ImageDescription definition and provide a 
minimal codec with our drivers in hopes of providing soemone with the 
opportunity to provide better (faster/higher quality) codecs.

For anyone who's not familiar with the format, a Bayer image is 
basically a graycale image where each pixel is actually red, green, 
or blue.

Inexpensive cameras usually use a single CCD or CMOS sensor with a 
colored filter over the pixels in the following pattern:

   RGRGRG
   GBGBGB
   RGRGRG
   GBGBGB

Leaving 4 possible pixel orders: 'RGGB', 'BGGR', 'GBRG', 'GRBG'

(I'll leave it as a mathematical exercise that there is only one 
format and the 4 possible orders are wether you start on an odd or 
even row and column)

We are currently using the codec type 'Bayr' with a depth of 8 or 16 
(for 8 or 16-bit pixels) but wondering if I should be using 2 
separate 4cc's an a depth of 24 for each.

Re reading Q&A 1183, we should be using a separate constant for each 
depth and a depth of 24 in the ImageDescription, so we need to come 
up with new constants.

We've defined an ImageDescriptionExtansion 'Bayr' whose first 4 bytes 
are a four character code ('RGGB', 'BGGR', 'GBRG', 'GRBG') indicating 
the byte order.

I originally started out with 4 pixel types by since flip/mirror/crop 
can change the component order, using an extension makes the most 
sense.

Also, the 'Bayr' extension should be valid on an RGB image that came 
to a Bayer source to indicate which color components contain real 
data from the camera and which are synthesized so that a 32-bit image 
can be losslessly recompressed 4:1 back to Bayer by just dropping the 
synthesized components.

Saving as Bayer makes sense for some high-speed cameras and you can 
save 1/4 the data and use variable quality on playback.

If there are already any four char codes in the field or if anyone 
has any suggestions/improvements, I'd be interested in your feedback.

Thanks,

-Steve