Managing U16 images in Labview/IMAQ Vision

[Chris_Regan]

I am working with a cooled, single-photon sensitive 16-bit CCD camera.  This camera returns U16 data, which is very sensible - dark pixels have values near 0 and bright ones have values near 65,000.  However, since Labview and IMAQ Vision only work with I16 16-bit images, I am forced to do the typecasting described in "16-bit Images in NI Vision".  This I16 restriction frustrates me since in this format 10 photons corresponds to an unintuitive number near -32,758, instead of something near 10.  I have two questions. 

1) Why is U16 not among the (now 7) different image types supported by IMAQ?  I can't fathom why I16 was chosen before U16, but even if historically there was some reason for that choice, 16-bit cameras like mine are now common enough that there must be some demand for this addition.

2) Working within the I16 constraint, is there a sensible way to get intuitive pixel values?  My camera has a minimum read noise of ~3.6 electrons per pixel, which tells me that my least-significant-bit is never going to have any real information.  Since I only have ~15 bits of real data, I should be able to store that as a positive number between 0 and 32767.  I can come up with a intuitive method (divide the I16 values by two and add 2^14), but I'm wondering, is there
    a) an architectural solution along the lines of the U16-I16 typecasting solution given in "16-bit Images in NI Vision"
and
    b) a way to get I16 "0" to display as black?  If there isn't this is a pointless exercise.

Thanks for your attention.

[Allison_S]

Chris,

    This is a common question, and there are reasons that we have chosen to keep the I16 image type and have not yet included the U16 type.
    First, when Vision was first being developed, 16 bit cameras did not exist so the top 4 or 6 bits were not used.  The advantage of having the negative range was that image math did not require a type change during calculations.

    Still today there are very few true 16 bit cameras, most cameras are still 12 bit or smaller.
    As far as your second question, you can display 0 as black if you choose.  When you create an Image Display on the front panel, right click and select 16-Bit Display Mapping.  This will allow you to map your actual image values to a different set of numbers (specifically from 0:0 as black to 255:32767 as white).
    I will put in a request that we add the U16 data type, and we have had many requests so I believe there is a good chance of it.  Let me know if you have any more questions, thank you!

-Allison S.
Applications Engineering

[Chris_Regan]

Hi Allison,

Thanks for the response. I have a follow-up question. To remove dark noise and offsets from my images, I want to subtract "dark" frames from my real data. So I acquire images with the shutter closed, save them, and subtract them from the real data when it arrives. In I16 these images have dark values, i.e. negative numbers. When I save them and reopen, these values have been shifted to positive numbers. If there is even one positive pixel this corruption does not occur.

Is this "feature" documented somewhere?
How do I disable it properly?
The attached vi illustrates this behavior.
 

Message Edited by Chris Regan on 02-16-2007 06:26 PM

Message Edited by Chris Regan on 02-16-2007 06:27 PM

Message Edited by Chris Regan on 02-16-2007 06:27 PM

[Allison_S]

Chris,

    Thank you for attaching a sample VI, and thank you for pointing this out.  Because of basic architectural reasons in the way we designed Vision, and because we use I16, we are not able to completely support .tif files.  I have informed R&D of the inconvenience, but because it is an architecturally based issue it will be a slow fix.  Because of the way the algorithm works, this cannot be disabled but can be worked around.  An easy workaround is to just add a white pixel to each image if you need to use the .tif file type.

    Something else to consider is that there are a few data types that will not change your data values.  Our NI custom file type, AIPD will keep those values, and a .png file supports I16 so it will also maintain those values.  Let me know if you have anymore questions, thank you.

-Allison S.

Applications Engineering

[Chris_Regan]

Hi Allison,

I'm disappointed to learn that TIFs aren't fully supported, and surprised that there's not a workaround that doesn't involve corrupting the image data. Couldn't something be done with the color palette during the save that would get the file to preserve the actual values?

I've looked at the other formats, and they have their own problems. I'm not interested in AIPD, since I need the data to be portable. PNG seemed like a good option, but that doesn't seem fully supported either. To illustrate, I modified the vi above (new version attached). This works within Labview (the reopened file has the same values as the original), but other programs are confused. The "Properties" as determined by Windows XP will declare the file to be 32-bit, not 16-bit. ImageJ (a reasonably vanilla, public-domain, image-handling program) will declare the file is 8-bit. Finally, ImageJ, IrfanView, Windows Paint, and Windows Picture and Fax Viewer will all display the image improperly - the upper-right region (-1) will display as white, not grey. I can fix the display problem by inserting some artificial white pixels, but that still leaves the bit-depth issue and I might as well return to your TIF workaround. Do you know what's going on with the bit depth in PNG?

Best regards,
Chris

[Chris_Regan]

Just to clarify my previous post:

The phrase "all display the image improperly" was poor wording.  Those programs are doing the usual "Full Dynamic" range 16-bit information to 8-bit greyscale display mapping.  In fact, this is also the Labview default display mode.  This mode is very confusing if you are interested in absolute light levels,  but it can be turned off in Labview using the method Allison points out in a post above.  Those other four programs are not as accomodating.

My earlier questions still stand:
Is is possible to arrange that a Labview-generated 16-bit TIF file reliably preserves the input data?
What is the source/resolution of the bit-depth confusion with PNG files?

[Allison_S]

Hi Chris,

    Because I16 is not a common format for images, not all features are completely supported. In some cases, image files written using NI-Vision will not display correctly in 3rd party viewers. As far as the .tif file, I have filed a request that that behavior be corrected. As of right now it is not possible to save an I16 .tif file using NI-Vision and have it preserve the data unless at least one of the pixels is a positive value. If there is anything else I can do for you let me know, and I have attached your forum to the correction request so that if a solution is found or made I will contact you. Thank you again for your patience, we will do our best to fully support I16 and U16 images and image files in future versions of Vision.

-Allison S.

Applications Engineering

[zou]

---

Chris Regan wrote: Hi Allison, I'm disappointed to learn that TIFs aren't fully supported, and surprised that there's not a workaround that doesn't involve corrupting the image data. Couldn't something be done with the color palette during the save that would get the file to preserve the actual values?

---

Image Toolbox ($) support U16 array to TIF (16 bit gray format) convert, and TIF to U16 array.

Image Toolbox

Message Edited by zou on 02-28-2007 10:27 AM

[peiyangium]

Hi, I am new to NI community, and I hope it is not abrupt to follow up such an 'ancient' thread.

But I also have trouble saving U16 tiff files. I am wondering, over so many year has this feature been improved? Is there any way to save a U16 tiff file with IMAQ nowadays?

[cbl-jnj]

Probably better to create a new thread and refer to an older one with a link.

From the 2015 Help, it looks like U16 images are supported by IMAQ Write (TIFF), but probably not supported by other software that reads TIFF, as noted in the help.