LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

continous capture to AVI --> not enough memory

I'm running LabView 2009 right now with two Camera Link  cameras (JAI CM-200MCL), each capable of running at roughly 25 fps with an NI PCIe 1430 frame grabber (They're rated for 30 fps, but I haven't been able to get them to run at this speed in LabView). I'm trying to get it so that I can capture a 30 second movie at least in which the images in both videos can be roughly coordinated with eachother in the time domain. 

Currently, I'm running into two major problems:
1) When imaging with both cameras and writing them to their own AVIs simultaneously, the respective camera fps values drop to about 17 each, screwing up the time fidelity of the resulting video and making analysis virtually impossible.  

2) Whenever I try to implement the code with newer AVI sub VIs in labview (requiring a compression codec), or when I try to take the raw VI and compress it by reading it and writing it to a new AVI file, my system runs out of memory and I get a message like this:

 

Error -1074396159 occurred at IMAQ AVI2 Write Frame

 

Possible reason(s):

IMAQ Vision: Not enough memory for requested operation.

Does anyone know what I can do to solve this? Currently I'm at a loss as to next steps and can't seem to find a solution in the various discussion threads I've read on similar topics. 


 

Message 1 of 10
(3,299 Views)

Hi floomich86,

 

How large are the images you're capturing?  And are they color or gray scale?  

 

It seems like your frame grabber is running at its max - the NI-PCIe 1430 can only use CameraLink Base, which has a maximum throughput of 255 MB/s. You can read about other versions of CameraLink here: http://digital.ni.com/public.nsf/allkb/2EE80B8C381D61D286257B1F005674A5?OpenDocument

 

Getting a frame grabber with a faster throughput would be able to prevent your system from running out of memory.  This would allow it to run more reliably at faster framerates.

 

 

Julian R.
Applications Engineer
National Instruments
0 Kudos
Message 2 of 10
(3,261 Views)

Hi Julian, thanks for responding so quickly. 

The images I'm capturing are 1620 x 816 in 8-bit. I did the math and I think that comes out to about 1.26 MB/image. At 25 fps for two cameras, that should only be about 63 MB/s, right? 

Regardless, even when I've already captured the video and am attempting to compress it with another LabView program (see 3rd attached VI), and am not using the cameras or the linker, my comp runs out of memory and I Get that error message. 

0 Kudos
Message 3 of 10
(3,225 Views)

Hi floomich86,

 

When do you get the error?  How many times the acquisition loop runs before you get the error?

 

Looking at it now, I think you're right that it's not a throughput issue, but has to do with the memory being used up.  I have a couple recommendations:

 

1) Try using a codec after to process your images so they're smaller.  Use the IMAQ Get Codec Names node to find the various codecs available on your computer (it returns an array of all the various codecs), then use an index array function to choose one of these (try an NI one to start).  Then wire this codec into your IMAQ AVI Create node in your Vision_Acquisition_2cam.vi.  Adding this compression should help your images take up less memory.

 

2) This seems like a good application for the Producer-Consumer architecture.  This would require revamping your code in a major way, but I think using this architecture would improve performance.  This architecture is best for programs that need to gather data in one loop and process it in another simultaneously.

 

Here are some examples of the Producer-Consumer architecture.  I tried to find some specifically with Vision functions in them but I couldn't.  Yet, you can still see how the architecture and data gathering/analysis works with these.

 

Here is a white paper to introduce the architecture: 

http://www.ni.com/white-paper/3023/en/

 

Here are some examples:

https://decibel.ni.com/content/docs/DOC-26558

https://decibel.ni.com/content/docs/DOC-2431

https://decibel.ni.com/content/docs/DOC-2145

 

Please let me know if these are helpful.

Julian R.
Applications Engineer
National Instruments
0 Kudos
Message 4 of 10
(3,202 Views)

Is the IMAQ grab automatically paced, or do you need to place a wait in there? (grab and save.vi) Else it'll try to grab some 100 fps quickly filling memory ...

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 5 of 10
(3,184 Views)

I have tried the codec method already - Microsoft Video 1 and the Cinepak one; You're right in that they both produce a much reduced video size, but I still encounter the same problem when using them; whether I attempt capture by using a codec directly or whether I try to convert the raw avi to a compressed format after recording it. Either way, I can only do the operation once before it runs out of memory, and the video that I do capture that first time around generally has a screwed up frame rate that caps at 17 fps. 

0 Kudos
Message 6 of 10
(3,155 Views)

floomich86,

 

Have you tried using any of the NI codecs?  They may work a little better.  Besides that, I'm checking out your code to see if I spot anything.

Julian R.
Applications Engineer
National Instruments
0 Kudos
Message 7 of 10
(3,138 Views)

Just humor me, try a 40ms wait inside the grab loop and set the AVI to 25fps and see what happens.

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 8 of 10
(3,119 Views)

Hey Yamaeda, I'll definitely try that when I get back into town, although I've also been encountering the same problem when using the IMAQ express VI; I'm not 100% sure, but I think that SubVI asks you to set a frame rate for the acquisition when you implement it (I chose 25.) 

0 Kudos
Message 9 of 10
(3,107 Views)

Yes it asks for a frame-rate, but i'm not so sure it actually pauses for the time required, it's more of a setting to the resulting file on how fast to playback the file. I've seen similar problems in a project and am uncertain on auto- vs manual-timing on the frame grab.

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 10 of 10
(3,094 Views)