Machine Vision
NI1439 16-bit signed display imagery: Just fix it
Hi, Evan,
Thank you for the explanation.
BullDozier wrote:
...16-bit images as I16 instead of U16 because this was a design decision that was made a while back. It's my understanding that a while back, 16-bit images were preferred in the I16 format for simplicity of algorithms and calculations done on the images. I'm not going to argue the wrongness of this decision, ...
I would like to say, that the initial decision was not the best. We working with grayscale XRay images, they are mostly over 8 bit depth. Some devices deliver 12-14 bit images, mostly 16 bits, and everytime black is zero. I haven't seen any XRay detector which deliver I16 images with negative values. Always U16, and everytime 0 is black. So, when using NI Vision algorithms, I should first convert U16 to I16 for processing, and then convert I16 to U16 for visualization. Line profiles, pixel meters - all things are corrected in my application, otherwise customer frustrated with images, which starts from -32768 with zero intensity exactly in the middle of the image. Its just additional work for me to adapt UI for bringin images info in range 0...65535 instead of -32768...32767.
Also not understand, which algorithms more simply for I16?
lookup table: NewPixel[i] = LUT[OldPixel[i]], or histogram: Histo[Pixel[i]]++ - try to do this with negative index. So, U16 is more convenient for imageprocessing than I16 from my point of view.
BullDozier wrote:
I think you would have a better experience acquiring from LabVIEW since you can use your U16 datatype from there without error.
Evan, before this recommendation try use U16 yourself. Well, U16 was introduced in Vision 8.x. But this type is unusable, because only few processing algorithms support this type. Technically you can create U16 now, but you can't do much with it:
Is this U16 support?!
In additional, I'm not sure, that IMAQ wil acquire directly to U16. (but this not checked, just suggestion).
Andrey.
Ok, I am joining this discussion. Yes, I am dealing with this problem at the moment, and it is very, Very frustrating. I cannot believe the limited support I am getting in LabVIEW with Images. I have dealt with Image problems for years, and I just told myself that It was because I didn't have the Vision Module.
SO I bought the Vision Suite for and extra 4 G's and I though it would fix this problem. 
Yes, I have a full, true 16 bit camera. And the numbers start with 0 being black, and 65535 being white. When displaying the imagery, at first I always think something is wrong with the camera, until I realized the data format is being displayed in I16.
WHO WANTS AN IMAGE DISPLAYED IN I16?
Not me.
So lets get to my current problem. I have a camera that outputs U16 Data at 640 x 480 x 60 Hz. When I use the IMAQ configure buffer.vi to set up a continuous grab from a CameraLink NI-PCIe-1427 card, I have to make Images to fill the buffer, so I use IMAQ create.vi with U16 Images.
You know what comes out of the IMAQ Extract.vi?? I16 IMAGES!
So now what do I do? convert every image on the fly to U16, then Put back into an Image form using IMAQ ArrayToImage?
How Expensive in processing power is that? More expensive than I want to pay.
Any thoughts?
Eric, you say:
For what it is worth, IMAQdx's latest version will now return 16-bit images as U16 if either the camera explicitly specifies that it is a signed, full, 16-bit format, or the user specifies to force it to return an unsigned image. But, as others have mentioned, many algorithms in Vision still are not yet able to handle U16 image data.
Where is this?
