topic IMAQ imgPlotDC2 in Machine Vision

IMAQ imgPlotDC2

Nate_W. — Thu, 30 Aug 2012 22:57:59 GMT

Hi,

I'm using function imgPlotDC2 to capture an image from my frame grabber and display it. It works find in my 32-bit application (left picture), but the 64-bit application image is messed up. Any ideas?

Thanks,

Nate

Re: IMAQ imgPlotDC2

TiTou — Tue, 04 Sep 2012 11:20:54 GMT

"where" are you calling that function? not from LabVIEW I imagine.

LabWindows CVI? Else?

When you install IMAQ drivers on a windows 64bit you can insependently select 32bit (WOW) and 64bit install. And then if you're using LabVIEW to develop your application you have to install the correct version you want LV 32bit or LV64bit (both can be installed on the same computer it works) and LV 32bit will use the 32b IMAQ driver and LV64bit will use the 64bit IMAq driver automatically, but if you're calling function from a different environnement I'm not sure how to specify the one you want.

Sorry, can't help more than that.

Re: IMAQ imgPlotDC2

BlueCheese — Tue, 04 Sep 2012 15:22:24 GMT

Hi Nate,

That garbled image somewhat looks like to me like there is some sort of mix-up regarding the bit-depth to display the image with. What bit depth is your camera file setup for? What are the flags you pass to imgPlotDC2?

Can you try running one of the shipping C examples that display images? "snap imgplot.c" seems like it uses imgPlot2(), but that just redirects into imgPlotDC2() internally. If these work in both 32-bit and 64-bit apps then I suspect it is an issue with the flags or other paramaters you are passing to the function.

Eric

Re: IMAQ imgPlotDC2

Nate_W. — Wed, 05 Sep 2012 18:56:56 GMT

So, I tried the 'LL Grab' example in 'C:\users\Public\Documents\National Instruments\NI-IMAQ\Examples\MSVC\Grab\LL Grab\', and I got the same result. The 32-bit app looks fine but the 64-bit app image is messed up.

(My application is a C# app that uses P-Invoke and the c:\windows\system32\imaq.dll, I also tried using the Active X 'imaq' component, but I get the same result. I am passing in IMGPLOT_MONO_12 to imgPlotDC2. I installed NI-IMAQ 4.6.4, but I didn't see a 64-bit option in the installation. I currently have 3 NI PCIe-1430 cards (firmware version 4.6.4.49152) in a very high end Falcon computer.)

Thanks in advance for any help you might be able to provide.

Nate

Re: IMAQ imgPlotDC2

Daniel_H1 — Thu, 06 Sep 2012 21:44:20 GMT

Hi Nate,

I see that you have used the example program from C:\users\Public\Documents\National Instruments\NI-IMAQ\Examples\MSVC\Grab\LL Grab\. I am wondering if we can get some more information about how you specified 32-bit vs 64-bit applications. There should only be one llgrab.exe in that folder, so I am curious about where you loaded each .exe from. Did you build one of them yourself from the example code?

I am trying to reproduce the behavior you are seeing, so any extra details you can provide will be very helpful.

Regards,

Daniel H

Re: IMAQ imgPlotDC2

BlueCheese — Thu, 06 Sep 2012 21:50:05 GMT

@Daniel H wrote:

Hi Nate,

I see that you have used the example program from C:\users\Public\Documents\National Instruments\NI-IMAQ\Examples\MSVC\Grab\LL Grab\. I am wondering if we can get some more information about how you specified 32-bit vs 64-bit applications. There should only be one llgrab.exe in that folder, so I am curious about where you loaded each .exe from. Did you build one of them yourself from the example code?

I am trying to reproduce the behavior you are seeing, so any extra details you can provide will be very helpful.

Regards,

Daniel H

Daniel,

The examples ships with a Visual Studio project file for building the example and there are two configurations already enabled in the solution - 32-bit and 64-bit - so you can build it both ways. The pre-built exe (32-bit) is just installed as a convenience so you can run the example out-of-the-box without compiling anything. If you want to build thr 64-bit solution, just open the included .vcproj file with Visual Studio 2005 or later and select the "x64" configuration prior to building.

Eric

Re: IMAQ imgPlotDC2

Nate_W. — Thu, 06 Sep 2012 23:19:55 GMT

Hi,

Indeed, I did rebuild the example as an x64 app. However, the display is garbled (the second image of the example shows this). Any ideas?

Nate

Re: IMAQ imgPlotDC2

BlueCheese — Fri, 07 Sep 2012 04:31:45 GMT

Hi Nate,

I believe Daniel is trying to reproduce this in-house now (my previous comment was directed at him) so hopefully we will get to the bottom of this shortly.

Eric

Re: IMAQ imgPlotDC2

Daniel_H1 — Fri, 07 Sep 2012 19:59:58 GMT

Hi Nate,

I am indeed trying to reproduce the issue here, but everything seems to be working fine. I'm running the llgrab example (both 32-bit and 64-bit) on a Windows 7 64-bit machine, with a PCIe-1430 framegrabber. I have NI-IMAQ 4.6.4 installed. Both llgrab.exe versions produce good images.

What camera are you using? Are you sure the pixels are 12-bit?

Did you change anything in the example code before building it into the 64-bit llgrab.exe?

Have you seen this with each of your PCIe-1430 cards, or just one of them?

Have you tried this on a different computer?

Have you seen this behavior with any other cameras?

One thing you might try is upgrading to IMAQ 4.7. This is included in Vision Acquisition Software 2012.08. If there was any problem during the install of IMAQ 4.6.4, this will overwrite the older driver and add any missing files.

I will be out of office next week, but another engineer will take over while I am gone, so you will continue getting responses here.

Regards,

Daniel H

Re: IMAQ imgPlotDC2

BlueCheese — Mon, 10 Sep 2012 06:47:45 GMT

Daniel,

Are you trying to replicate this with a 12-bit camera or an 8-bit camera?

Eric

Re: IMAQ imgPlotDC2

Nate_W. — Mon, 10 Sep 2012 16:25:45 GMT

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

Re: IMAQ imgPlotDC2

Wee-Bey — Mon, 10 Sep 2012 22:14:51 GMT

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.

Re: IMAQ imgPlotDC2

BlueCheese — Tue, 11 Sep 2012 05:50:30 GMT

@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

Re: IMAQ imgPlotDC2

Nate_W. — Tue, 11 Sep 2012 20:23:36 GMT

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

Re: IMAQ imgPlotDC2

Nate_W. — Tue, 11 Sep 2012 21:10:02 GMT

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.

Re: IMAQ imgPlotDC2

Wee-Bey — Wed, 12 Sep 2012 15:37:05 GMT

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.

Re: IMAQ imgPlotDC2

Daniel_W — Fri, 14 Sep 2012 16:09:01 GMT

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

Re: IMAQ imgPlotDC2

BlueCheese — Mon, 17 Sep 2012 17:03:11 GMT

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

Re: IMAQ imgPlotDC2

BlueCheese — Mon, 17 Sep 2012 17:53:45 GMT

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

Re: IMAQ imgPlotDC2

Nate_W. — Mon, 17 Sep 2012 19:13:28 GMT

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