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.
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…
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:
Step 1 I16:
Thank you very much but, actually, I cannot find anything in the web about file size problems with Videroreader. Thanks again, massimiliano.
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.
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.
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.
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.
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:
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.
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.