A couple of IMAQ 16-bit image questions

[WNM]

Question #1
-----------
When I use a color lookup table (LUT, a.k.a. palette) that is a grayscale LUT with the zero value replaced with the color blue and the 255 value replaced with the color red and apply it to a LabVIEW "Image Display" that is connected to an 8-bit image, I get an image displayed which has the zero & 255 values highlighted.

If I use the same LUT with the same image display and connect it to a source of 12-bit image data, I lose the highlighting. The image display has had its "16-bit display mapping" set to a "Given range" where 0 is mapped to 0 and 4095 is mapped to 255.

What is happening to prevent the special colors at 0 & 255 from appearing in this case?


Question #2
-----------
When I save one of my 12-bit images to a TIFF file and then use ImageJ (a public domain image processing library from the NIH, http://rsb.info.nih.gov/ij/ ) to look at the file, I see that my image data which used to run from 0-to-4095, now spans the range 32768-to-36863. I can "fix" it by subtracting a constant 32768 from the image data before writing the file but I'm curious why this is needed? Isn't there a standard for how this data is supposed to appear in the file?

[Scott_R]

Hello Warren,

1) Try building your LUT as a 16-bit LUT (indices ranging from 0 to 65535) and then map your red and blue colors to the 32767 and 32768 indices (the indices corresponding to the max and min intensities). Then perform your 16-bit display mapping. This should properly map the red and blue values back to the 8-bit display. When you use the IMAQ Set User LUT function, it actually downloads that LUT to the acquisition board, so the mapped values will correspond to the pixel-depth of the image acquired, not specifically to the display. For more information about LUT and color mapping, take a look at the following KnowledgeBase on the NI website:

Image Display with IMAQ/Vision Part I
http://digital.ni.com/public.nsf/websearch/F64F223FDC2D15DD86256F480064FB26?OpenDocument

2) Looking at the scale that is being used, it seems that the zero to 4095 values of your 12-bit image are being mapped to their corresponding values in 16-bit mapping, where a 12-bit intensity of zero corresponds to an intensity of -32767 and an index of 32768. Take a look at the LUT text files and image attached to the KB that I referenced above. That shows how intensities map to their LUT indices.

Take a look at the KB and let me know if you have any additional questions.

Regards,
Scott R.
Applications Engineer
National Instruments

[WNM]

You say "Try building your LUT as a 16-bit LUT" but would this be the correct thing to do for 12-bit data?

You also say "When you use the IMAQ Set User LUT function, it actually downloads that LUT to the acquisition board" but I am not using that function or hardware.

I am using the IMAQ IEEE-1394 routines to get the data from firewire cameras but the LUT application is done to the LabVIEW "Image Display" control/indicator via a property node. The "Palette Type" is set to "User Defined" & the 8-bit LUT data is wired to the "User Palette" terminal.

Correct me if I'm wrong, but given the fact that the "Image Display" has only 256 levels, I don't think what you are suggesting will work in this case...

[Scott_R]

Warren,

I tried to replicate the issue that you have described on my end, but the image seems to adjust properly for my grayscale images of different bit-depths. Here is how I set up my test:

1) LUT consisted of 256 elements, element 0 was set to RGB = (0, 0, 255) and element 255 was set to (255, 0, 0).
2) Used an image property node to set the palette to user-defined and connected the custom LUT to the user-defined palette.
3) Used an IMAQ Create where I specified the Image Type as Grayscale I16.
4) Built a simple 2-D array that consisted of I16 values that included 0s and 4095s.
5) Connected this array and the image that was created to an IMAQ ArrayToImage function, wired the output to an image display.
6) Rt-clicked on the image display on the front panel, selected "16-Bit Display Mapping" and selected "Given Range" and mapped 0 to 0 and 4095 to 255.

Running this VI generated an output with grayscale values and blue pixels instead of zeros and red pixels instead of 255s. Be sure to pay attention to the datatypes used, as to avoid coersion, as coersion can cause loss of data.

I have attached the sample program that I built. Try running it and let me know if you have any questions.

Regards,
Scott R.
Applications Engineer
National Instruments

[WNM]

Scott,

I'm running LV 7.0 and for that reason could not use your sample program.

Warren

[WNM]

OK Scott, since I could not run your VI I built one of my own that either demonstrates the problem or else my lack of understanding about how to make this work properly. Please take a look at the attached VI.

It was built using LV 7.0 and the IMAQ Vision toolkit.

Only the 8-bit bit-depth option displays the upper-end highlight color as it should, when I run it here.

Thanks,

Warren

[Scott_R]

Warren,

I did not realize that you were using LabVIEW 7.0. Here is the same file, saved for that version.

Take a look at it and let me know if you have any questions.

Regards,

Scott R.
Applications Engineer
National Instruments

[WNM]

Thanks for the updated (or perhaps that should be backdated, since it is for an older version) VI, Scott.

Yes, I see the RED highlight color on your VI but that is only because the VI does not actually conform to this condition of yours:

"6) Rt-clicked on the image display on the front panel, selected "16-Bit Display Mapping" and selected "Given Range" and mapped 0 to 0 and 4095 to 255."

The VI you put together actually has 4094 mapped to 255. When I change it to 4095, the RED highlight disappears from your VI just like it does from mine.

Perhaps this is a bug (that 4095 does not get mapped correctly)?

[Scott_R]

Warren,

The VI seems to run properly on my system. Did you run my code by itself or did you copy it into your application and run it there? Do you have any coercion dots in your code? A coercion dot shows up as a gray spot on the input to the VI. This is caused when numerical data that is not of the correct format is connected to a numerical input (e.g. connecting a double to a U16 input). Initially, my code demonstrated the same problem that you are describing, but when I changed the representations so that there were no coercion dots, the code worked properly. To do this, I changed the data types of the constants that I wired into my Replace Array Subset functions and inserted the "To Unsigned Byte" function to convert the loop iteration into a U8.

Take a look at the implementation and be sure that there are no coercion dots present anywhere. Let me know if the problem persists.

Regards,

Scott R.
Applications Engineer
National Instruments

[WNM]

There are no coercion dots in the copy of your code that I am running.
(On my system I have coercion dots set to be pure green so that they are easier to see.)

Your code does work when the (16-bit image display) mapping is set to 4094-to-255 (this is how you delivered it).

Your code does not work when the mapping is set to 4095-to-255.

The correct mapping is 4095-to-255.

Your code does not work any better than mine does.

I suspect this is a bug in LabVIEW.