Frame rate issues

[pwu.380]

First, I'm pretty new to LabView and any sort of declarative programming in general. My profile is actually lying, because there was no option in the drop down menu for started in 2009.

I have a camera that runs at 15 fps and when I'm just grabbing the images to display it runs just fine, but when I put a function to save the frames in the same loop, the frame rate drops dramatically. It becomes something closer to 5 fps. Now I'm stuck, the individual pictures are about 1.5mb so I don't think I'm being bottlenecked by hard drive write speed. I don't know where to go from here, 15 fps isn't that fast in the first place, so it shouldn't be an unreasonable demand.

Also, the low level grab examples from LabView don't work. I get a camera not detected error, but it shows up in MAX and works for high level grabs.

[Francois Normandin]

Can you post your code?

[pwu.380]

Lets say it's fairly minimalist.

Also, I'm getting nearly the full frame rate when I halve the acquired image dimensions (so a quarter the size). But I still don't think write speed is the issue, the hd should be capable of writing at 40mb/s.

[Francois Normandin]

QUOTE (pwu.380 @ Feb 3 2009, 02:28 PM)

Lets say it's fairly minimalist.

Also, I'm getting nearly the full frame rate when I halve the acquired image dimensions (so a quarter the size). But I still don't think write speed is the issue, the hd should be capable of writing at 40mb/s.

I got to write to disk at maximum speed of my camera (26fps) with your code with only a small change:

Wire a TRUE constant to the IMAQ Grab Acquire.vi's IMMEDIATE? input. It's false by default.

http://lavag.org/old_files/monthly_02_2009/post-10515-1233692772.png' target="_blank">

[pwu.380]

QUOTE (normandinf @ Feb 3 2009, 09:29 PM)

I got to write to disk at maximum speed of my camera (26fps) with your code with only a small change:

Wire a TRUE constant to the IMAQ Grab Acquire.vi's IMMEDIATE? input. It's false by default.

http://lavag.org/old_files/monthly_02_2009/post-10515-1233692772.png' target="_blank">

That worked really well, I'm incredulous.

Any explanation as to why this happens or is it one of those "just because" kind of things?

In any case, I appreciate your help.

[Francois Normandin]

QUOTE (pwu.380 @ Feb 3 2009, 04:12 PM)

Any explanation as to why this happens or is it one of those "just because" kind of things?

I don't have a real intelligent answer for you, as I haven't really asked myself the question. But the help file says this:

Immediate? determines if the system returns the image currently being acquired or the last completely acquired image. The default value if FALSE, which causes NI-IMAQ to wait until the current image is completely acquired before returning the image. TRUE returns the next acquired image

That explains why it's faster, but not why it's five times faster... I would have guessed that the maximum delay between true and false would have been the duration of one frame, hence I would have expected at most a two-fold increase in speed. Since it's much faster, there must be other considerations. Perhaps someone else has a better description of what it actually does...

[bmoyer]

You may want to do a test to see if it is acquiring the same image more than 1 time. I thought this is the way that it worked - if a new image is not available since the last time, to just return the same image. But I could be wrong or this functionality could have changed at some point.

It's probably worth comparing the Acquired Buffer Number output of the IMAQ Grab Acquire.vi to the previous iteration (using a shift register in a while loop) to make sure this isn't the case (at least in your test code).

Bruce

[Francois Normandin]

QUOTE (bmoyer @ Feb 4 2009, 08:00 AM)

You may want to do a test to see if it is acquiring the same image more than 1 time. I thought this is the way that it worked - if a new image is not available since the last time, to just return the same image. But I could be wrong or this functionality could have changed at some point.

It's probably worth comparing the Acquired Buffer Number output of the IMAQ Grab Acquire.vi to the previous iteration (using a shift register in a while loop) to make sure this isn't the case (at least in your test code).

Bruce

That was my hunch as well and I did see the buffer number was not rising as fast as the loop rate.

Although this implementation demonstrates that it's not limited by speed, either writing to disk or data processing.

Many cameras can't deliver 30fps at full resolution (1280 x 1024 for example). The next question I'd ask myself is: What's the camera's model? Can it run at 15fps at full ROI?

[pwu.380]

Well, as sudden as it started working, it stopped again. Now it's grabbing at a sluggish 5 fps. I have no idea what happened because I didn't change the code at all between today and yesterday. As far as buffers are concerned, that wouldn't be sustainable for indeterminately long image captures right? Because eventually you'll run out of memory to store the images in. Unless there's some kind of speed gain to be made in bulk processing of images.

Also, I'm pretty sure the camera is capable of acquiring full res pictures at full speed, because I can display them at the full frame rate if I remove the saving process.

So, any suggestions?

[crelf]

QUOTE (pwu.380 @ Feb 4 2009, 11:38 AM)

Well, as sudden as it started working, it stopped again. Now it's grabbing at a sluggish 5 fps.

A couple of quick questions: is there anything in the error cluster that's coming out of the IMAQ VIs? You haven't wired your error clusters, so you might be missing an error or warning. Also, what's the bus you're using for image acquisition? Is it a gigE, FireWire camera, or are you using a NI image acquisition card with a different standard?

[pwu.380]

QUOTE (crelf @ Feb 4 2009, 06:02 PM)

A couple of quick questions: is there anything in the error cluster that's coming out of the IMAQ VIs? You haven't wired your error clusters, so you might be missing an error or warning. Also, what's the bus you're using for image acquisition? Is it a gigE, FireWire camera, or are you using a NI image acquisition card with a different standard?

I just wired the errors, and there's nothing.

The camera is going to a frame grabber card from NI. It's an analog input to the card and from there should be a PCI bus to the motherboard.

[crelf]

QUOTE (pwu.380 @ Feb 4 2009, 02:35 PM)

I just wired the errors, and there's nothing.

bugger.

QUOTE (pwu.380 @ Feb 4 2009, 02:35 PM)

The camera is going to a frame grabber card from NI. It's an analog input to the card and from there should be a PCI bus to the motherboard.

Double bugger - I was thinking it might be a bus loading issue if you were using firewire, but you're not

[pwu.380]

I ended up calling NI and they suggested to use a producer/consumer structure, but my script isn't working out and I'm don't know it it's some kind of syntax error or if my entire structure is faulty. Anyone care to take a look at it?