Bug in IMAQ Bayer Decode on 64 bit LabView

[Chris Davis]

I believe I have found a bug in the IMAQ Bayer Decode subVI that is shipped as part of the Vision Acquisition Drivers, August 2010 (NI-IMAQ 4.5). Inside this subVI, there is a call to imaq.dll to convert a grayscale image to a color image, to pass pointers to the memory space for the source and destination image, 32 bit pointers are used in a 64 bit OS. Obviously this is incorrect and could cause crashes if the program is working with the large amounts of memory on 64 bit systems.

It is possible to work around this bug by manually changing the first two calling parameters of CLN from int32's to i64's or u64's. Since the Map Pixel Pointer subVI returns u64's for pointers on 64 bit OS's, this CLN should probably use u64's as well. You could wrap the CLN call in a conditional disable structure with flags for 64 or 32 bit operating environments, if you want. I've been happy with that solution when I've needed to make code work on 64 bit and 32 bit LabVIEW. I've tested this work around in my appliation, after I discovered the issue, and my application works fine now. Until the bug is fixed, I'll be sticking with this solution, unless a better work around is provided in the comments below.

I know this may not be the best place to post this bug, but I wanted others to avoid the issues that I've faced when dealing with this bug. Immediate crashes when calling this subVI, unmodified from the initial install were hard to track down.

When an NI engineer reads this, please post the CAR for future reference.

I've tested this with LabVIEW 2009 64 bit on Windows Vista Business 64 bit and Windows 7 Professional 64 bit.

<a href="http://forums.ni.com/t5/Machine-Vision/Bug-in-IMAQ-Bayer-Decode-on-64-bit-systems/td-p/1312549">Cross-posted at NI Discussion forums</a>

Cross Post Link

[Rolf Kalbermatter]

It is possible to work around this bug by manually changing the first two calling parameters of CLN from int32's to i64's or u64's. Since the Map Pixel Pointer subVI returns u64's for pointers on 64 bit OS's, this CLN should probably use u64's as well. You could wrap the CLN call in a conditional disable structure with flags for 64 or 32 bit operating environments, if you want. I've been happy with that solution when I've needed to make code work on 64 bit and 32 bit LabVIEW. I've tested this work around in my appliation, after I discovered the issue, and my application works fine now. Until the bug is fixed, I'll be sticking with this solution, unless a better work around is provided in the comments below.

Actually the proper fix would be to use Pointer sized (signed or unsigned) integer instead. Then you can forget about the conditional compile node. This CLN datatype is available since LabVIEW 8.5.