How to get a continuous display of an output image in the LabVIEW?

[NAGINENI]

Dear all,

We have interfaced with a web camera on a cRIO using a USB port. It continuously capturing an image with a frame rate of 25 fps, I would like to see these images in the display after some processing in the cRIO RT environment. Here, only one image is updated after stopping the program (loop). We want to see the continuous output images in the display after some processing for a continuous input image. I attached the VI program, anyone can give suggestions regarding the problem in my approach. Please let me know if any better way of approaching this problem.

Here obtained processed image means that applying some algorithm to an input image.

Thanks and regards

Sukumar.

 

[Bob_Schor]

There are several methods, all involving saving all of the images you want to (re)-view.  One way to do this is to save them to an .AVI file, "making a movie" that you can subsequently view (and set to auto-repeat).  This isn't hard, and is "easy on the PC memory" (in case the movie is long).  The other way is to save all of the Images (as 2D arrays) to an Array (making a 3D array, the third dimension being "frames"), and then in a "Viewing" loop, display them with a 40 msec "Wait" in each frame (to achieve 25 FPS).  Neither method should be too difficult.

Bob Schor

[NAGINENI]

Thanks for your replay,

Any suggestions regarding to an attached VI.

Could you send me some example VI programs to resolve this problem?

[PalanivelThiruvenkadam]

If you just want to display the current image after Processing the Grabbed Image , Just Put your Grab and Processing Algorithm inside the While Loop with Loop timing based on the rate at which you want the view the image.

[wiebe@CARYA]

---

@NAGINENI wrote:

Please let me know if any better way of approaching this problem.

---

Are you sure you're getting LabVIEW's dataflow principle?

NI Vision is even harder than 'normal' programming.

The image isn't updated until you press both of the stop buttons. If you put the image indicator in the first loop, it will update every iteration.

The 2nd loop is almost certainly a bug. This will grow the output array until you press stop. If you don't, or if you wait too long, the application will use up all memory and crash. This goes unnoticed as you reshape the array. This is probably a 'solution' to the misunderstood problem.

The flat sequence structure doesn't do anything useful. It's just one more structure that is twisting your wiring.

There are 5 wires that are straight. All the other wires are bended and\or crossing. If you want this code to work (for you, not for the computer), you might try to keep it tidy.

[NAGINENI]

Dear all,

This is the corrected VI program based on your suggestions. Here the output image and input image are updated for every 6-7 milliseconds (ms), even though I replaced with the timed loop contains a source is in microseconds. How to reduce this delay and get a continuous (instant) image for a continuous (instant) input image. Please look at an attached VI program and let me know the possibilities for further improvements.

Thanks and regards

Sukumar

[aeastet]

What camera are you using?

You need to understand that you will never get a real time display. there will always be a delay. you need to try to minimize that delay. To do this you need a camera that can output a high frame rate. the faster the frame rate the smaller the delay. Second you are reprocessing the picture after getting it from the camera. this will further delay seeing the image. You need to understand how long your processing takes. This will help you understand what your maximum frame rate would be with everything you want to do to the image.

your time will be:

camera grab + processing = total time per picture

some thing you can do to minimize this time would be to have one loop that only get images from the camera. that loop would feed a different loop for processing. You need to find out where your slowest process is. That will be the maximum you will ever achieve. If the camera is the limit, you would need to buy a new camera that is faster. If your processing loop is the slowest process then you might be able to build a loop that pulls images from a queue to process faster.

This will be a complicated process. You need to determine what maximum delay you can live with and try to design a system that can achieve that, if possible.

[aeastet]

Your processing algorithm take almost 67 msec. That is a long time. That would put you at 14Hz. It looks like your algorithm is the slow process here. 

[NAGINENI]

Thanks for your good information. It's a Logitech webcam c270 having a frame rate of 25 fps ( 640*480 ). Actually the delay is 6 to 7 (6 -7) seconds, I mentioned wrong in the above post. So what frame rate of camera should be required to resolve this problem

[Bob_Schor]

Get all of the data processing out of the Acquisition Loop.  Replace the Timed Loop with an ordinary While Loop and let the Camera (running at 25 FPS) act at the "clock" -- it should take 40 msec to run a loop.  I don't know what kind of processing you want to do, but it needs to be done in a parallel loop.  Do you need to see the results "in real time"?  The easiest (and cheapest) way to handle processing is to go "off-line" -- save the image data to a file (you can easily stream 25 FPS to disk), and in a second program, read the file back and process it frame-by-frame, taking as much time as you need (since the data are already saved to disk).

Bob Schor