IMAQ Array to Image Bit Shift?

[tringold]

Hi,

I've been working with some 12 bit images from a camera and saving the results as 16 bit TIFFs using some of the Vision VIs.  I can save and read back in the TIFFs and all of the data stays intact, but if I try to open the saved TIFFs in another reader (e.g. MATLAB), the returned data is incorrect.  Opening the raw TIFF files and looking at the image data (little endian) in bytes, numbers like 234 001 [490] end up becoming 234 129 [33258].  From the attached VI, it becomes clear there's a problem when you simply put in zeros to the array and try to open up the resultant TIFF in MATLAB (0 goes to 2^15) and yet LabView reads in the TIFF just fine.  While I can work around this problem, I only know I that need to work around it if I know a priori that the TIFF is from LabView.  Is there some resolution to this problem?  I'm thinking some kind of bit shifting to the data in LabView before converting the array to an image.  Thanks.

[TiTou]

Hello,

Maybe you are looking for the functions "swap byte" and "swap words"




Hope this helps

Message Edité par TiTou le 06-29-2007 02:00 PM

[GiGe]

Hi,

The difference is in how NI Vision displays 16 bit images.  When NI Vision displays a 16-bit image (using its default method), it looks at the full dynamic range of the image and scales that range to an 8-bit range before displaying it. (This attempts to compress all the pixel information to a range that can be displayed in Windows.) On the other hand, Photoshop and other external viewers just take the 16-bit data, shift it right by 8 bits and then display the resulting image. Although common, this method results in the loss of pixel resolution by truncating the least significant bits. As a result, if you have an image that uses 10 bits per pixel, you will get only 2 bits of display resolution (out of 8), and your image will look black.

To correct this problem try multiplying the original image by a power of 2 and then re-save the image. This shifts every bit in the pixels upward by that power of two, which accounts for the display method used by many image editing programs.  I hope this helps.

Regards,

GG

[tringold]

Hello,

Thank you for the reply.  I am more concerned, though, that MATLAB (which assumedly is not doing any truncation since it returns 16 bit values) returns incorrect values specifically for 16 bit TIFFs written by LabView, but not 16 bit TIFFs written by some other softwares.  As a result, I don't think this is an issue about how various softwares visualize greater than 8-bit images (since I'm not visualizing, but rather just reading values), but rather how LabView writes its 16 bit TIFF files.  Thanks.

[GiGe]

Hi,

I found a KB that talks about how 16 bit images are handled in labview that may help.  But I believe the reason TIFF's from other programs don't appear black is that they have been saved with the data shifted. 

Did you try multiplying the image by a power of 2?  Where you able to view the images in Matlab after that?  Keep me posted.

GG

[tringold]

Thanks Gige for the link.  That page describes my problem perfectly.  I just needed to subtract all the value by 2^15, effectively shifting the values down since the IMAQ input is I16 as opposed to U16.  While I certainly won't complain, I'm kind of suprised TIFFs saved in MATLAB read perfectly into LabView and I don't have to add 2^15.  Oh well.  Thanks for the help!