remote image creation

[Hamm]

I have a vision application that creates, acquires, and disposes many imaq images in labview 8.0.1.  I am using oop to store these images in clusters.

Sometimes when I call the variable to dispose of an image I notice that a new image is in memory called "remote image xxxxxxxxxx"  Where x is a hex value.  I'm seeing this new image via Ima status.

There is not way for me to dispose of the new image causing a bad memory situation.  Any insight into why these images are being created would be appreciated.

[McCarty]

Hello Hamm,

The issue you have described is a known bug in LabVIEW.  This bug is associated with Corrective Action Request 3YTEQD5G.  The remote image is not a foreign image randomly created in memory.  The image simply carries a name that you are not expecting.  Please find an attached VI that demonstrates the creation of a remote image.

Best Regards,
Travis M.

[Hamm]

Thank you Travis,

In the code that you have attached,  there is only 1 imaq create. So is this "Remote Image" going to occupy memory even after Imaq dispose is called?  If so, is there a way for me to prevent this from happening in my code?

Ryan 

[Hamm]

This is basically what I am dealing with, Whenever I disose of an image, I get another one created.  LEaving tons of images in memory.  If I could get any more insight into the VI(s) that cause this, I would really appreciate it.

[URL=http://www.putfile.com/pic.php?img=6649468][img]http://img2.putfile.com/thumb/9/26111543041.jpg[/img][/URL]

[McCarty]

Hello Ryan,

We'll need to gather some more information from you so we can look into the issue further.  For instance, which version of NI Vision are you using?  Also, are you using one of the NI-IMAQ drivers to acquire images?  If so, which driver and which version of the driver are you using?  If you could build and post a small sample VI with just enough code to demonstrate the issue, that could help us investigate the issue.

Let me also ask why you are creating and destroying images in your code rather than just reusing the existing memory locations of the image buffers you have already created?  If you need to dispose of multiple images, you can set the All Images? input of the IMAQ Dispose.vi to True.  Be aware, however, that disposing of all images will dispose of both your named images and the remote images. 

Can you expand on why you need to use Object Oriented Programming with your images?  Do you encounter the same remote images issue when you are not using Object Oriented Programming?

Best Regards,
Travis M.

[Hamm]

NI Vision v8.2.0, NI LabVIEW v8.0.1
I'm acquiring images using Imaq 3.7.0.  With the 1394 drivers v2.0.4.

My program is multi-threaded.  One thread acquires and stores the images like this:

http://www.putfile.com/pic.php?img=6657432

Then the other thread inspects the images as they are snapped, then disposes of them like this:

http://www.putfile.com/pic.php?img=6657431

With multiple cameras, I use this multi threaded approach to decrease cycle time as I can acquire faster than I can inspect.  That is my reason for using oop. 

I would rather not use the "All Images?" dispose because I have template images and calibration images that I only create once. 

Currently, I am reusing all images, but there are over 1500 images in memory,  I would much rather keep memory use low by dynamically creating and disposing Imaq allocations in case my sample size exceeds my memory capabilities.

[michaeld]

Hamm,

Can you attach a copy of your current code? This may be easier to diagnose if I can see your program as a whole.

[Hamm]

Unfortunately, I cannot post my source because I have finished the project and released the software to customers. 

As a workaround, instead of desroying Image references, I used set image size to make the resolution 1x1 so that the image is still in memory it uses less memory.

I would still like to solve this problem for future vision projects.

[McCarty]

Hello Ryan,

I have updated the Corrective Action Request regarding this issue.  Our R&D team is aware of the problem, and they will hopefully implement a solution in a future software release.

Best Regards,
T. McCarty

[Kahr]

Hi,

So 2023 and and the issue remain in LV2019.

Did anyone find a solution to the problem during these 16 years ?

Thanks