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

[NAGINENI]

 Dear  aeastet,

Thanks for your suggestions. I have some queries.

Can you suggest to me what framerate would be required to resolve this problem?

As you mentioned that, camera grab + processing = total time per picture, Can you tell me the way to calculate this time per picture?

Thanks and regards

Sukumar

[Bob_Schor]

If you follow my suggestion and separate "Acquire Image" from "Process and Display Image" into a Producer/Consumer Design Pattern, then the Acquire Image loop will run at 25 Hz (as the Camera will "clock" it at its Frame Rate) and the Process/Display Loop will run at the slower of (25 Hz, the Producer rate, and whatever rate is inherent in the processing you are doing).

In fact, you can speed it up a little more by making three loops.  Loop 1 is the Camera Loop, acquiring Images at 25 Hz.  Loop 2 is the "Process" loop -- it takes in an Image, process (but does not display it), and passes it out to Loop 3.  Loop 3 is the "Display" loop, displaying the images as fast as it receives them.

If you can get your processing time down to 40 msec (or 25 Hz), then here's how it will go:

Time 0.000 -- the Camera starts to Acquires an Image.

Time 0.040 -- the Camera gets the Image and exports it to Loop 2 and start to acquire next Image.

Time 0.040 -- Loop 2 gets Image, starts to Process it.

Time 0.080 -- Loop 2 finishes processing, passes processed Image to Loop 3 and starts to process second image from Loop 1.

Time 0.080 -- Loop 3 gets Image, displays it.  We know display takes <40 msec, so by the time the next Image is sent to Loop 3, it is ready to display it.

This entire sequence will run at 25 Hz (as each loop takes at most 40 msec).  Of course, the image you view will be delayed by 80-120 msec from the image acquired (as it takes time to acquire + time to process + time to display), but the overall rate of the display will be 25 Hz.

Work on your Processing Algorithm, get it down so that you can process a 640x480 Image in 40 msec.  If you need more time (say, 80 msec), consider processing (for display) every other image.  Really, the time-critical step here is the Image Processing step.

Bob Schor

[NAGINENI]

Hello Bob-schor,

Thank you for your suggestions.

I followed your suggestion that the separate loop for "Acquire image," "Process," and "Display image" using the producer/consumer loop. Still, the same delay is occurring in an output image. Please look into an attached VI program and let me know if any wrong thing in the program.

Thanks and regards

Sukumar

 

[wiebe@CARYA]

If the displaying is really the bottleneck, why would you display all images?

Why not update just the most recent image?

This can be achieved by simply using a 1 element queue and a lossy enqueue for the 2nd to 3rd step.

The for loop to process the images has redundant stuff in it. Why multiply with 1 (2 times)? Why multiply with -1 and than add (that is a subtract).

The Image To Array, reshape to 1D, reshape to 2D and Array To image are probably expensive.

Of course your wires are so twisted and bended, the code will execute slower.

Spoiler

It won't, but it will stop you from seeing other problems.

[wiebe@CARYA]

And by multiplying with 1, you also convert a lot of the data in the for loop to doubles (note the coercion dot). That's even more expensive than just using doubles... Change the constant 1 to a single to fix that.

Updating an indicator in a loop will slow it down quite a bit as well. Remove Loop 2 if you want speed.

The for loop seems to perform a simple kernel operation. Probably a Sobel or Canny will do something very similar, but a gazillion times faster (eliminating the conversion as well).

Perhaps you can explain a bit why you do the home made filtering?

[NAGINENI]

Thank you for your suggestions.

@Why not update just the most recent image?

We need to display all the images, and In further steps, this continuous mage information is helpful for the continuous monitoring (tracking) of things. In the future, we would like to do continuous monitoring.

@Why multiply with 1 (2 times)? Why multiply with -1 and than add (that is a subtract).

In my original algorithm, multiply with 2 (2 times) is there, I have not included my total algorithm here, and it has two more delay block elements in the feedback path and one more delay block element in a forward way. My intention behind the posting of an example algorithm mainly to know, how to reduce the delay

@ And by multiplying with 1, you also convert a lot of the data in the for loop to doubles (note the coercion dot). That's even more expensive than just using doubles... Change the constant 1 to a single to fix that.

I will adjust it to the SGL format.

@The for loop seems to perform a simple kernel operation. Probably a Sobel or Canny will do something very similar, but a gazillion times faster (eliminating the conversion as well).

Yes, for loop is doing the kernel operation to find the edges in an image. We are focusing on developing an edge filter.

@Updating an indicator in a loop will slow it down quite a bit as well. Remove Loop 2 if you want speed

I will work it now and let you know.

@Perhaps you can explain a bit why you do the homemade filtering?

We are going to develop an edge detection (edge detection filter) algorithm, it will be helpful, whereas other edge detection algorithm response is not up to the mark.

Any suggestions would be great

Thanks and regards

Sukumar