LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Large size file memory problem?

Hello, i am really new to Labview, i am working on a VI written by a colleague and i have a problem I hope i will be able to explain clearly. I have a video composed of 10000 frames with 640x480 pixels and 8 bit grey scale values, i use a for loop to do some processing on each frame and write the resulting frames into a binary file of 10000 2d array (or, in another version, into an I16 file of 10000x640x480 elements). In a second VI i use another for loop to read each frame, calculate the mean value and write the mean value vs frame signal in a tds file. The problem is that when I read the signal file I see it stops at frame 3500 (it becomes a constant line) and starts again at frame 7000. Which could be the reason? I have Labview 2013 64 bit and Windows 64 bit. Thanks in advance, massimiliano.

Download All
0 Kudos
Message 1 of 14
(1,708 Views)

Hi massimiliano,

 


Massi@INO wrote:
The problem is that when I read the signal file I see it stops at frame 3500 (it becomes a constant line) and starts again at frame 7000. Which could be the reason?

Maybe this Matlab script, which uses that "VideoReader()" function, is the reason!?

That's the only function which is used to actually read the video frames…

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 2 of 14
(1,651 Views)

Gerd suggestions is a good one, but I cannot really help you with that.

 

Looking at the LabVIEW code, many things seems highly flawed.

 

Step 1 binary:

  • Why is "Numero Frame"  not an integer?
  • Why are the DISTAZA and "Input file" terminals inside the loop? Are you expecting them to change during the loop?
  • Index array is resizable, but to get the number of element from a multidimensional array is just to apply this function to the array of sizes (see picture below).
  • Exactly why do you need I16 for a 8bit greyscale? Can't you save it as U8? SInce all frames are of known identical size, you can ven store it flat withouth size information.
  • Never manipulate paths as strings. (use this, this and this). Except for the matlab script input, paths should remain path datatype.
  • None of your scaling is needed if you set the z color scale of your intensity graphs correctly.

Step 1 I16:

  • some of the same issues.
  • You don't ever need to set the file position to the end if you create a new file and keep writing.

 

Step 2:

  • Same of the same issues. All controls belong before the loop unless you want allow changing them during execution of the loop (which would invalidate a lot of results).
  • The reading datatype is just a 2D array of I16, right. Can be empty.
  • Why are you reading from the I16 file? Why is there no path?
  • I would stay away from dynamic data and express VIs, they are not needed.

 

 

altenbach_0-1624211053861.png

 

 

Message 3 of 14
(1,641 Views)

Thank you very much but, actually, I cannot find anything in the web about file size problems with Videroreader. Thanks again, massimiliano.

0 Kudos
Message 4 of 14
(1,626 Views)

v = VideoReader(Path);

 

Opens a VideoReader. I assume you have to close it. The Matlab node might not do this automatically.

 

If this is AX or .NET, I'd try to do it in LabVIEW. Opening and closing such an object over and over again will be very inefficient.

0 Kudos
Message 5 of 14
(1,584 Views)

That whole VI with the Matlab node makes little sense to me. It does create an array for the Amps variable as the absolute value of H1. It never does create any data for the F variable which is written to the file. It never uses the d variable. It could indeed cause resource starvation by opening a new VideoReader every time that never gets closed, but most likely Matlab cleans up after every execution and does some garbage collection like most scripting languages do nowadays.

 

The entire path handling is at least "suboptimal" and definitely ugly. There is a ready made VI in the File Advanced palette to deal with file endings properly.

File Ending.png

 

The OpenG File package has a function that does it all for you.

 

And in case anyone hasn't noticed, 3500 * 640 * 480 I16 values is pretty much exactly 2'150'400'000 bytes which is susceptible close to 2^31, or the maximum amount addressable by an I32.

Rolf Kalbermatter
My Blog
Message 6 of 14
(1,577 Views)

Thank you very much, i changed the Matlab script to close VideoReader but the problem persists.

0 Kudos
Message 7 of 14
(1,562 Views)

Thank you very much, you are completely right, the Matlab script i attached is a simplified (non sense) version, in the complete version d and Fase are used, i tought the complete script was not essential to illustrate and solve my problem. Thanks for your hints about the path. I do not understand your last consideration about the maximum amount addressable by an I32, is this related to my problem? Thanks again.

0 Kudos
Message 8 of 14
(1,555 Views)

Hi Massimo,

 


Massi@INO wrote:

I do not understand your last consideration about the maximum amount addressable by an I32, is this related to my problem?


This seems very related!

At about 3500*640*480*I16 (exactly: 3496) data you get an overflow error in a I32 counter, resulting in negative I32 values.

And at ~7000*640*480*I16 (exactly: 6991) you get another overflow back into the positive value range.

 

And both of these values correlate with your problem description:


Massi@INO wrote:

The problem is that when I read the signal file I see it stops at frame 3500 (it becomes a constant line) and starts again at frame 7000.


 

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
Message 9 of 14
(1,549 Views)

Indeed the signal stops at frame 3496 not 3500. I think you get the problem! But unfortunately, due to my very low experience in programming, i still do not understand exactly the point: which I32 counter are you speaking of? Is there a solution to avoid this overflow error? Thanks again, massimiliano.

0 Kudos
Message 10 of 14
(1,536 Views)