Jump to content

IMAQ Memory Fragmentation Issues

Recommended Posts

I have a relatively large application which does heavy IMAQ image processing.  Many IMAQ buffers are created and destroyed dynamically at runtime based on need (i.e. different system components will create their own temporary images for processing steps and destroy them when their work is finished). While this dynamic creation/destruction reduces the overall memory footprint at a given time, it appears the constant re-sizing or re-creating is causing memory fragmentation over time. When this dynamic creation/destruction is used heavily, we get IMAQ out of memory errors (at different places in the application) after the system has been running for some time. Total memory usage has not increased (and is well below 2GB) so the errors are presumably due to the fact that there are not large enough contiguous blocks available. 

Are there any best practices or “standard” ways for managing lots of image references? Should they all be created initially? One idea is to allocate a pool of resources on startup (of images that will not get resized) that are shared throughout the application using a mechanism to “reserve” and “release” the resources in the pool. Is this a good approach?  Thanks! 

Share this post

Link to post
Share on other sites

I hope you are running LV 64bit to start with, we only run 64 bit here, so we hardly get any out of memory issues.

The easiest way it to stop disposing/destroying the image and see if that helps.
If you create a "new" image with the same name, you'll just get the same reference.

A pool is one way to go as well, but you need a acquire and release images out and into the pool, so if the pool is empty the next user have to wait for his turn.

Share this post

Link to post
Share on other sites

I'm not totally clear on the concept but I wouldn't expect contiguous memory to be a problem on the desktop (and linux-rt targets) since they have virtual addresses. I know that this was a big nice thing about switching from vxworks to linux-rt, there was no longer any concept of a largest contiguous block.

Are you sure there isn't a (very) temporary spike in memory usage and you're actually running out? I don't know if this works for imaq but under normal circumstances I'd suggest using desktop execution trace to monitor your program and see what is happening when you run out.

Share this post

Link to post
Share on other sites

Unfortunately 64-bit LabVIEW isn't an option in the near term (we have some NI motion dependencies which are not 64-bit compatible). In the future we'd like to break this part of the application out (maybe create a proxy application or move to an embedded solution) but in the mean time we are stuck with 32-bit labVIEW. I've thought about allowing some dynamic creation of images in addition to the pool so that during times of high load we do not have parts of the application blocked waiting for resources to be freed elsewhere. In this circumstance when the reference is "released" back to the manager it will be destroyed. Even if this is allowed, it should still cut down on the total number of images created/destroyed in the application (under most circumstances the resources available in the pool will be re-used). 

We are working on putting more memory monitoring in place to better understand the circumstances under which the out-of-memory errors occur.  As of yet, the memory appears to be more or less stabilized (with plenty of total memory available) when the errors occur. Also, once the error occurs initially all subsequent requests to allocate the necessary memory generate out-of-memory errors - we have to re-start the application to fix the problem. 

Share this post

Link to post
Share on other sites
7 hours ago, szalusky said:

Unfortunately 64-bit LabVIEW isn't an option in the near term (we have some NI motion dependencies which are not 64-bit compatible).

You are right the NI-motion driver is not working in 64 bit, which is a really bad thing.
But we use the NI motion drivers very successfully on from LV 64 bit....so how do we do that?

We create a LV32 bit server application, that our LC64 bit application starts (if it's not already running).
We then connect and send instructions over localhost-TCIP/IP, to the 32 bit written LV server application.
We use this architecture for several driver components where e.g. the vendor only supplies a 32 bit dll version.

Since we're using a GOOP based HAL inheritance structure the driver layer solves all our problems.

I hope you don't give up yet on the 64 bit solution, since it will solve a lot of your problems.





Share this post

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Similar Content

    • By Elancheran
      Hi Everyone,
            I am trying to play the video in reverse decrementing the frame number in IMAQ Read Frame function. Its working but the result is very choppy as every frame takes significant time to load, but when I just increment the frame number and play the video forward, its executing without any problem. I have attached the VI and info regarding the video, could you guys please let me know why I am having problem when I am trying to display the video in the reverse order.
      Playing AVI file.vi

    • By Shaun07
      I need one help regarding changing the image image type
      How can I convert grey scale image to false color image?
      Here, I have attached two images. 1. greyscale image 2. is just an example that I want to convert. (False Color). 
      Any help would be appreciate.
      Parth Panchal 

    • By caleyjag
      Understandably NI's own line of analog video frame grabbers have been obsolete for some time (since 2010 I believe).
      I have an industrial application where I am bound to using legacy analog VGA cameras. Upgrading the cameras is not an option
      I would like to use LabVIEW for testing purposes. Are there any good non-NI frame grabbers still out there that are easy to get up and running with LabVIEW?
      Unfortunately due to the bureaucratic purchasing processes ordering an old NI card of e-bay is not really feasible. 
    • By Karin Hellqvist
      In the attached image I have four Code 128 and two Code 39. I have problem detecting them without down sampling the image first. Since I want to grade the bar codes I don't want to down sample since the code quality is reduced then. I noticed this from that sometimes some of the bar codes are found without down sampling an then the grade is higher for those. Down sampling a factor 2 sometimes work, down sampling a factor 4 always works.
      I have tried croping the image around the bar code but this doesn't help.
      I'm using IMAQ Read Barcode 2, and have tried to change the parameter Min Bar Width with no result. Is there any other parameter I can change for the algorithm to find the barcodes, without having to down sample my image.
      Best regards
      Karin Hellqvist
      Certified LabVIEW Architect

    • By ASalcedo
      Hello to all.
      First of all thanks a lot for reading this post and being able to help.
      I have noticed the next problem:
      My application has a camera, this camera takes images (snap mode) and application process them (detect some edges in the image). It works fine.
      But when I make the Display bigger my application takes longer to process images (and for me that is crucial). I think that this happens because my application in this case has to process a bigger image (bigger display = bigger image??)
      So maybe if My camera takes images with lower resolution I solve the problem.
      So how can I change image resolution captured by my gigE camera? In NI MAX or in Labview?
      Thanks a lot!
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.