Camera File Generator Ignores MSB (15)?

[mysterylectricity]

Hi,

I'm using an IMAQ 1424 in conjunction with a microcontroller to
digitize a scanning electron microscope. Essentially I'm
designing my own "camera".

It's going fairly well. But there seems to be an odd problem
in the camera file generator utility. In 16 bit mode, if I
peg bit 15 (the 16th and MSB) high, I get a vertical line
at ~32300 in the histogram like I should. But the screen remains dark,
whereas I expect a 50% grey level. Likewise if I toggle the bit,
no response. If I toggle bit 14, I get a %25 grey/black response
as one would expect.

This lead to a lot of head-scratching until I opened the
card in MAX. It seems to work fine there, toggling bit
15 "flashes" the screen.

So, what's wrong with the Camera File Generator? Is this a
known bug?

-Jeff

[Scott_R]

Jeff,

If the camera file seems to be working in MAX, then it should function properly in your IMAQ system during image acquisition and display in in your programming environment.

I have not encountered this issue in the camera file generator before. I am going to try to reproduce this behavior on my end. I will let you know just as soon as I find anything.

Regards,
Scott R.
Applications Engineer
National Instruments

[Scott_R]

Jeff,

The image displays use a signed 16-bit value. This means that when you toggle the MSB, that will actually toggle the value to the negative intensity range. MAX may be showing a close approximation to what you expected due to the display mapping settings that are in place. If you want to use an unsigned 16-bit value, you could acquire your pixel information in grayscale and then copy the value into an RGB64 image, which uses unsigned 16-bit values for R, G, and B. You could then perform whatever processing you need to using that image type.

If you want to acquire images just using the signed 16-bit image, you could also try inverting the MSB. That should place your intensities into a close approximation of a U16.

Try these suggestions and let me know if you have any additional questions on this issue.

Regards,
Scott R.
Applications Engineer
National Instruments

[mysterylectricity]

Hi,

Yes, I came to the same conclusion recently. And routing
bit 15 through an inverter deos solve the problem.

Could I also do this through the LUT? Where is the
file format for the LUT detailed?

While looking into this signed vs. unsigned problem,
I seemed to be getting strange results under MAX that
aren't related to the signage problem.

It seemed that if I toggled any single high-byte bit
at about a rate of 1 Hz, I'd get about 50mS of pure
white on both the high-to-low and low-to-high transitions
regardless of which bit was toggled. All other bits were
held low.

Does the card or MAX implement some sort of AGC, or learn
to ignore "stuck" bits?

When I inject a grescale signal the visual results are fine,
but it's true that my greyscale signal is 10 Hz (the refresh
rate). I'm a bit concerned about what might happen if the
real world signal varies at a rate around 1 Hz, though
one could argue that any bit that varies at a rate less
than the refresh rate _should_ be handled through AGC.
The images are largely static in any case, so by definition
they shouldn't vary at a rate slower than the refresh rate.
Still I wonder if I'll get flashing or tearing of the images.

I guess I'll be looking into that next, exactly what happens if
I apply a 1 Hz sine function.

-Jeff

[Scott_R]

Jeff,

Yes, you can do this through the LUT. What programming environment are you going to use to develop your application? If you are using LabVIEW, CVI, Visual Basic or Visual C++, there should be a function available in the API that will allow you to set a user lookup table. In LabVIEW, the function is called IMAQ Set User LUT. You can create your lookup table by building an array that consists of 16-bit values. These values can count from 0 to 65535. You would then need to swap the first byte of the value with the last bit, resulting in 32768-65535 followed by 0-32767.

With regard to the display issue that you were seeing, try acquiring into your programming environment and using different mapping methods. Measurement and Automation Explorer uses a method that takes the full range of pixel intensities and maps the lowest value to 0 and the highest value to 255, because its image display is only 8 bits. Try using a different mapping method. For example, you could specify a maximum value, such that all values above that value are going to be mapped to 255. You could also specify a range of values so that any values lower than the minimum will be mapped to 0.

Try those steps and let me know if you have any additional questions.

Regards,
Scott R.
Applications Engineer
National Instruments

[mysterylectricity]

Hi,

I think that explains the behavior I'm getting exactly. I think you imply that the mapping
is dynamic, what is the "sampling interval"? I hadn't realized before now that the real problem
will surface for me at higher resolutions, which may take tens or hunreds of seconds each.
Perhaps with luck the mapping takes place each frame? Actually it seems subframe to me.

And of course that explains why my "16 bit" images look like 8 bit. The funny thing is I'd
been eyeing 10+ bit frame buffers and so was more than casually aware that my frame buffer
would only do 8 bit.... but when I saw the symptoms I didn't recgonize it.

To be honest I was hoping MAX had all the functionality I would need, at least until I finish
the hardware. Long after I'd finished the hardware actually, I need a break from this project. While I'm asking, would MAX take advatage of a 10 bit framebuffer?

I'll probably try using LABView first but I've never really used it. I don't anticipate it being a huge problem, but any references to sample code, locations of libraries, location of relevant docs.... I guess I should search the knowledgbase for that stuff. Seems I've seen
the relevant docs detailing the functions but I can't find them now.

Thanks for the great responses so far, they've really hit the nail on the head.

-Jeff

[RManion]

Hi Jeff,

When using a dynamic mapping in MAX, the uppermost pixel value is mapped to white, and the lowest value is mapped to black. The intermediate values are divided equally.

You can definitely use 16 bit images, but the monitor is not capable of displaying them as such. Because MAX has no purpose other than to display the acquired image, MAX will not do anything much with 10 bit images. That said, the data is still there and available for processing, and it can be valuable to have a higher bitdepth image.

Hope this helps,

Robert