IMAQ imgPlotDC2

[Nate_W.]

Hi Daniel,

Here are some of the cameras I have tried (without success in the 64-bit app):

FLIR Tau (640x512) 12-bit

Sofradir Atom (640x480) 14-bit

NiT MC1001 (640x480) 14-bit

...and others

The llbgrab solution and files are unmolested. I have tried Microsoft Visual Studio 2008 9.0.21022.8 RTM and Visual Studio 2010 10.0.30319.1 RTMRel. Same results in both.

All three of the PCIe-1430 cards have this issue. I haven't tried any other computers, but this is out target computer (it is going on flight test) so it is important to get it working.

Thanks for your help.

Nate

[Wee-Bey]

Hi there. I'm taking over the issue from Daniel, and I'm also using the test station he set up.

Have you been able to look at the array behind the image to see if there is a correlation between what kinds of values the data should have and what it does have? It's possible there is some strange bit-shifting going on that we can spot pretty quickly if we can take a look at the arrays and compare the two.

[BlueCheese]

---

@Wee-Bey wrote:

Hi there. I'm taking over the issue from Daniel, and I'm also using the test station he set up.

Have you been able to look at the array behind the image to see if there is a correlation between what kinds of values the data should have and what it does have? It's possible there is some strange bit-shifting going on that we can spot pretty quickly if we can take a look at the arrays and compare the two.

---

Ravi,

So are you trying to reproduce this with an 8-bit or >8bit camera?

Eric

[Nate_W.]

Hi Ravi,

The data itself looks reasonable, although I only have ImageJ to view it (and ImageJ doesn't seem to have good support to 12-bit images). So it looks like the function that displays the data may be the culprit.

Nate

[Nate_W.]

I did some more poking around in ImageJ and Datahammer 7yuv. It looks like the 64-bit application is rendering the image as 8 bits per pixel even though the IMGPLOT_MONO_12 plot flag is being passed to imgPlotDC2. The 32-bit application is properly rendering the 12-bit image. Below is a picture of how ImageJ renders the raw data as 8bpp, which is similar to what I'm seeing in the NI demo app.

[Wee-Bey]

Eric, so it turns out this was previously tested with an 8-bit camera, so I'm reassembling the system with a 12-bit camera.

Nate, while I try to recreate the issue, to confirm your suspicions (which seem right), does downsampling this to 8 bits actually result in a reasonable-looking image if you pass it in? You could likely quickly try by removing the bottom four bits and passing them in that way.

Sorry about the delay on this. I'll let you know when I'm able to get it up and running and recreate it.

[Daniel_W]

One other interesting data point would be to manually overwrite the acquired image with some known pattern (like just copy the x value into the pixel, creating vertical stripes in the image). That would separate the acquisition from the display and tell us where the problem was.

Is that something you can try?

-Daniel

[BlueCheese]

Hi Nate,

I have confirmed that there is a bug in the IMAQ driver code that does not properly handle >8bit image depths in imgPlotDC2() when in a 64-bit application. This has been filed as CAR #371092 if you need to refer to this in any future NI support correspondence. I can't give any sort of timeline for when this will be fixed yet.

In the meantime, I can suggest a few possible workarounds:

- You could copy/map the >8-bit data to 8bit before display. This is effectively what the underlying code is doing anyway since generally display technology is only 8-bit. Doing it yourself would likely add a bit of overhead but might not be a problem depending on the characteristics of your application

- I might be able to provide a snippet of (untested) Win32 code that let you implement the display yourself. It might not have quite the same functionality of the internal NI code (I believe ours has all sorts of dynamic depth scaling options for mapping it to 8-bit displays) but I'm not sure how much of that is exposed in imgPlotDC2() anyway.

Eric

[BlueCheese]

A third workaround (since you are using C#) might be to try using Microsoft's native .NET framework functions to do the drawing. The System.Drawing.Imaging and BitmapData classes/namespaces seem like a good place to start (http://msdn.microsoft.com/en-us/library/system.drawing.imaging.bitmapdata(v=vs.71).aspx). I imagine you could fairly easilly constuct an appropriate bitmap object pointing into the image data array and get it to display the image data directly.

Eric

[Nate_W.]

Hi Eric,

Indeed, The .NET solution to draw raw bitmap data is very straightforward. I implemented the following source, but I'm getting an InvalidArgument exception in the call to DrawImage. I'm uncertain if there is some GDI+ issue with 16bpp data. I will try and post this to a .NET GDI+ forum to see if anyone has an explanation.

private void panImage_Paint(object sender, PaintEventArgs e)
{

.....

   // Get the current session info from the device
   ImaqWrapper.getSessionInfo(m_iInterfaceNumber, out iImageWidth, out iImageHeight, out iBitsPerPixel);

   // Get image data from the IMAQ interface.
   if ((sReturn = ImaqWrapper.grabImageData(out ptrSource, m_iInterfaceNumber, out iBufferSize)) == "")
   {

      ...

      Bitmap b = new Bitmap(iImageWidth, iImageHeight, 2 * iImageWidth, PixelFormat.Format16bppGrayScale, ptrSource);

      e.Graphics.DrawImage(b, e.ClipRectangle.X, e.ClipRectangle.Y);

      b.Dispose();

   }

Nate