Bayer decoding with 16-bit images

[ETanner]

The IMAQ Bayer Color Decode VI (in Vision 8.0) works fine for converting 8-bit grayscale Bayer images to 32-bit RGB, but I'm not sure what to do with higher-bit-depth images.  Suppose you have a 16-bit grayscale Bayer image that you want to convert to RGB.  Although the decode VI accepts 16-bit input, it doesn't accept a 64-bit RGB as a destination image.  I'd rather not have the bit depth cut down by half in order to convert to color.

[Lorne H.]

ETanner,

The NI-IMAQ driver (as of version 3.5.1) does not support 64-Bit RGB images.  Because of this if you put a 10-Bit or 12-Bit into "IMAQ Bayer Color Decode.vi" the least significant bits of the image will be dropped to produce the 32-Bit RGB image.

I realize this is not a solution to your problem and that 64-bit RGB images is definantly a desireable feature.  I encourage you suggest that we add 64-bit images to a future release of NI-IMAQ via the link below...

Product Feedback

Lorne Hengst
Application Engineer
National Instruments

[BruceAmmons]

I suggested the following idea in response to another question that was very similar:

Convert your 16 bit Bayer image to an array, and split the upper and lower bytes.  Convert the resulting arrays back to U8 images, and use the Bayer conversion to convert each into a 32 bit color image.  Extract each color plane as a U8 array, and combine the low and high bytes to get 16 bit color planes.  Combine the color planes to get a 64 bit color image.

This wouldn't be the fastest method in the world, but I think it would work fairly well.  I believe the Bayer conversions are linear, so splitting and recombining the bytes should work.  I haven't tested it, though.  If you try it, please let everybody know if it works or not.

Bruce

[ETanner]

Splitting the bytes worries me...suppose you have the following 16-bit Bayer mapping of nine pixels around a central blue pixel:

RR GG RR
GG BB GG
RR GG RR

And our 2-byte values for the nine pixels are:

00 2F 00
3F 00 2F
00 20 00

If we now want to calculate our green value for the central pixel, using a typical Bayer scheme we would average the four green pixels, giving us:

Green value calculated with both bytes at once = (3F+2F+2F+20)/4 = 2F

If, however, we split the bytes, average the high byte, average the low byte, and recombine:

High byte green value = (3+2+2+2)/4 = 2
Low byte green value = (F+F+F+0)/4 = B
Green value calculated after operating on bytes separately and recombining = 2B

Tell me if there's something amiss here.  Perhaps I'll just write the Bayer decode from scratch.

[BruceAmmons]

I forgot about rounding.  The rounding on the high byte kind of eliminates the resolution on the low byte.

How many bits are used in the 16 bit image?  You could probably shift bits to eliminate the rounding errors if you have extra bits to work with.  For example, with a 12 bit image, you could shift the upper byte to the left 2 bits before processing, which would keep the rounded bits.  You would have to be careful when recombining the upper and lower bytes, but it wouldn't be too bad.  I guess the big question is when does it get easier to write your own routine.  Actually, with the white balancing factors (non-integers), you will probably lose the lower bits anyway with my method.  You would have to use factors of 1 and then do the correction on the final values.

I guess the next question would be:  Do you really need the extra bits on your color image?  I see the advantage of the extra bits before the conversion to get the added range, but I can't think of many applications where those extra bits would be useful in the color image.

Bruce

[zou]

Image Toolbox (http://www.geocities.com/gzou999/imgtool.htm) can take a 2D array, and save it to a 48 bit color format TIF.

[Hannamon]

Sorry for being Johnny-Come-Lately to this thread (thread was active in Mar, it is now Nov), but I have an alternate solution that may prove useful for someone running into the same issue...

I have run into the very same issue: using 16-bit Bayer images and needing to analyse them somehow.  IMAQ does not support 16-bit Bayer images, but it does support 16-bit monochrome  images.  Here's a quick summation of the method I used to get around the problem.  Essentially, this involves splitting the original 16-bit Bayer image into four separate colour images (R, G1, G2, B) and then performing your analysis on each plane.

The first thing I needed to do was to establish a starting (x,y) coordinate.  First, I needed to know that I was always starting my Bayer kernel separation on an even-valued pixel.  Then, depending on the particular Bayer pattern (I'll use R,G1,G2,B for reference), offset the remaining colours.  For example, R=(0,0), G1=(0,1), G2=(1,0), B=(1,1).  So, if you can get your image separation routine to always start with pixel (0,0), it is just a matter of adding a routine to offset these four colours.  Use IMAQ_Extract (with the colour pixel offset entered into the optional rectangle, and the X/Y-step set to 2 (so that it skips every other pixel), and if done correctly, the result is four sepearated colour planes.

Of course, this example assumes you always know what Bayer pattern you have.  I used a ring control to select which pattern was currently in use.

Again, this is FYI only, and only providing an alternate option.  Hope it is helpful.

DJH

[HaD]

I think u did mistake

In the MSB avg should be: (30+20+20+20)/4=24

So u add the remaining 4 to the LSB. now u get: 20+B+4=2F...