From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW: Memory is full

Solved!
Go to solution

Hi everyone!

 

I implemented a full image processing algorithm in LabVIEW using quite a lot of Matlab code imported throughout Mathscript nodes and when I have finished implementing the algorithm I found out that it works fine for a few number of pictures, but runs out of memory if I give him more than 25-30. My intentions are to run it through a database of approximately 1200 pics, so this very small amount that it can handle looks to be a pretty drastical problem for me. How can I make the algorithm to scale better and handle hundreds or even thousands of pictures?

 

Here you have my top level VI that just simply runs through a folder containing the images and compares every one of them to a reference image. Expected result is to have an array of similarity scores between each image from the folder and this reference one.

TopLevelVI.JPG

I have two subVI's that I figured that they may cause the problem. The Retrieve Properties VI does the most of the job which takes on the image as an input, calls lots of Matlab code from .m files and outputs a binary template and mask for the image. Then the Hamming Distance VI takes on the images from the folder and the template and mask from the reference picture, runs the Retrieve Properties VI for the image from the folder and does some logical operations (XOR, AND) on the templates and masks and outputs a double precision score. This subVI is called for every image in the folder and this is how it looks:

Hamming Distance.JPG

As I mentioned previously, the algorithm works fine for a small number of pictures, but when I give him more than 25-30 I get the error that "Memory is full". I've read some posts on this issue and most of them said to reduce number of front panel elements, arrays, copies of arrays and every large data structure that uses contiguous allocation, so I tried to do so. My only element on the front panel is the array with the final scores, however I cannot manipulate the Matlab code too much as it is not my code, I just have an authorization to use it.

 

As a final information that could be relevant I should mention the size of the pictures: they are 150x200 grayscale pictures with the size of around 22-25 kB's of data.

 

Does anyone have an idea how to make this algorithm work on a higher scale of pictures?

 

0 Kudos
Message 1 of 11
(5,014 Views)

1. On your top level VI, use an autoindexing output tunnel instead of building the array on your own.  The way you are doing it, you have to reallocate an array with each iteration.  With an autoindexing output tunnel, LabVIEW can preallocate the array size since it knows how many times that loop will run.  Therefore, only 1 array will be allocated instead of N.

 

2. It looks like your Matlab code is nothing more than a couple of FOR loops.  Why not just implement those in LabVIEW?


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 2 of 11
(5,006 Views)

Thanks for the tip for autoindexing, however it did not solve the problem.

 

Sorry if I wasn't clear enough, my Matlab code is in the Retrieve Properties VI which I didn't expose here. That VI contains a huge amount of Matlab code. Has a Mathscript node that calls in several .m functions which run the whole image processing and binary property retrieval algorithm. It takes around 500 lines of code if not a bit more.

0 Kudos
Message 3 of 11
(4,998 Views)

When I ask a mechanic to tell me what is wrong with my car I don't just bring him the radio.  Giving us the full source (not pictures of the source) will probably help.  But as mentioned the most efficient way to do the work, is to have LabVIEW do the work, not have LabVIEW call out to external libraries and do the work.  Native G code is best.

 

Also without the full picture I can't say for sure, but are these properties it is retreiving better read using the native LabVIEW image processing functions, or even IMAQ?

0 Kudos
Message 4 of 11
(4,985 Views)

Yes, you are right, but I'm not entitled to give you out somebody elses code.

 

From the point of view of implementing it in LabVIEW I thought that it should work fine by calling it from Matlab code. I mean, why reinvent the wheel if I have the tools for using the existing code? 

0 Kudos
Message 5 of 11
(4,978 Views)

Does the sub-VI "Retrieve Properties" close the files it opens?

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 6 of 11
(4,960 Views)
Solution
Accepted by topic author kemenesendre

@kemenesendre wrote:

 

From the point of view of implementing it in LabVIEW I thought that it should work fine by calling it from Matlab code. I mean, why reinvent the wheel if I have the tools for using the existing code? 


Yeah I get that point, and in this case it sounds like you have a decent amount of Matlab code, so that probably isn't a feasible option.  But if you were on a Matlab forum, and you had Matlab code that was calling ActiveX functions in Excel to do math operations, and returning the result, then I would expect that forum to also say you should probably have implemented it in Matlab, instead of calling out to an external library.

 

Is it possible to do operations in chunks?  Maybe perform part of the Matlab calls, return a result, then feed that into another Matlab call?  Without knowing where the memory allocation is taking place, and without knowing where the large amounts of data are being allocated, it is hard to recommend anything with much confidence.

 

Still based on the code I see I wouldn't expect the number of files being process to matter.  You only are taking one double for each image processed.  So even if it took 1GB of RAM to process an image, once that image is done being processed, all the memory should be de-allocated, other than the one number which was a result of that image.  Basically what I am saying is if it can process 5 images, it should be able to process 5000 (or more)  Are you sure it isn't crapping out on one particular image?  What happens if you try to just process the one image it fails to process?

0 Kudos
Message 7 of 11
(4,951 Views)

To be honest I didn't close any file, because I don't use any open node and about the others I didn't find in the documentation whether they implicitly call close or I should do it. I just read the data from the image with the IMAQ ReadFile function and give it to the IMAQ ImageToArray to create a 2D array of the image content that my Matlab code processes. Here is how it looks withouth the Mathscript node that does the image processing and outputs the template and the mask I use later on.

Retrieve Properties.JPG

0 Kudos
Message 8 of 11
(4,946 Views)

IMAQ Dispose?

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 9 of 11
(4,935 Views)

@Hooovahh wrote:

@kemenesendre wrote:

 

From the point of view of implementing it in LabVIEW I thought that it should work fine by calling it from Matlab code. I mean, why reinvent the wheel if I have the tools for using the existing code? 


Yeah I get that point, and in this case it sounds like you have a decent amount of Matlab code, so that probably isn't a feasible option.  But if you were on a Matlab forum, and you had Matlab code that was calling ActiveX functions in Excel to do math operations, and returning the result, then I would expect that forum to also say you should probably have implemented it in Matlab, instead of calling out to an external library.

 

Is it possible to do operations in chunks?  Maybe perform part of the Matlab calls, return a result, then feed that into another Matlab call?  Without knowing where the memory allocation is taking place, and without knowing where the large amounts of data are being allocated, it is hard to recommend anything with much confidence.

 

Still based on the code I see I wouldn't expect the number of files being process to matter.  You only are taking one double for each image processed.  So even if it took 1GB of RAM to process an image, once that image is done being processed, all the memory should be de-allocated, other than the one number which was a result of that image.  Basically what I am saying is if it can process 5 images, it should be able to process 5000 (or more)  Are you sure it isn't crapping out on one particular image?  What happens if you try to just process the one image it fails to process?


And yes you are right again! It already sounded strange when I was reading your last paragraph that a program that sequentially processes images runs out of memory, because as you say after being done with processing of one image it should de-allocate its memory. So I tried with each of them separately and there is one little **bleep** 🙂 that does not work. There is a picture for which it always throws the memory is full error. I removed that from the set of pictures I was testing on and now easily runs even for more instances. Thanks for the idea, it would have taken me quite a long time to figure this out. 

0 Kudos
Message 10 of 11
(4,910 Views)