GigE Vision Multithreading Problem

[krispiekream]

Hi,

I have a Prosilica GE1910C camera.

Grabing image at 1920X1080 for 30 fps.

I am using Labview 2009 Vision Devolopement.

My desktop is an Intel Pentium D 2.8HGZ with 1GB ram

I also have the high performance Intel Pro/ 1000 GT Network Adapter

I am using a producer/consumer structure to build my applications. It is fairly simple.

I can't seems to make my process rate faster? Is it my computer?

can someone help me.

what can i be doing wrong?

[BlueCheese]

Hi Krispiekream,

You would likely have to attach your code for us to give you any tips on improving the performance. You are using a pretty high-resolution color camera and so you have a lot of data to process. 

Here's some ideas I can offer based solely on your screenshot and description:

- Memory copies are expensive of such large images. How does your producer/consumer pass the images?

- Make sure you are not grabbing images that you aren't going to process or you are wasting CPU. The producer should be throttled by the consumer's ability to consume the data

- Image display is expensive in CPU time... can you display images less often than every frame?

- Without seeing your algorithm you are doing on the data, I have no idea how efficient it is

Eric

[krispiekream]

can you take a look at this code

i even got myself a new quad core pentium so i really dont think its my computer that is too slow for this app.

i just need to prove that is it possible to for this application to work.

basically i am trying to draw crosshairs in this circular shape object and looking at a reference point and follow that point.

i am trying to do this in realtime.

[krispiekream]

i am thinking that maybe my template image is wayyyy too big so its hard for labview to process it in.

[George_P_Burdell]

Krispiekream-

Unfortunately, I don’t have a GigE camera to test your application with.  However, I would be more than happy to test your VI should you alter it such that it is hardware independent. 

[krispiekream]

i have tried a similar application before i purchased the gigE camera and it worked.

the only difference now is that i am taking in a 1920x1080 image rather than 620x480.

i can give you more examples tomorrow when i am at work.

[George_P_Burdell]

Sounds great.  Let me know how I can continue to help!

[krispiekream]

this is the concept of my application.

it should be in real time.

with the images rotated any any angle, the crosshair follows.

[George_P_Burdell]

The program you attached seemed to run correctly on my computer.  However, the images were all the 640 x 480 size.  I do agree with you that the larger image size may be affecting your application. 

[BlueCheese]

Hi Krispiekream,

I did some quick looking at your code and see several areas that could be improved on the acquisition side:

-Your producer loop runs as fast as the camera does, potentially faster than you are processing images. This simply wastes CPU time acquiring more images than you are processing

-Your producer loop copies images rather than references to them, increasing the CPU load. Additionally, since you are always copying into the same image you could potentially be changing the image contents while the consumer loop is in the middle of processing it if it uses multiple processing VIs.

Here's what I'd suggest doing:

-You could drop the producer/consumer concepts if you wanted as it is generally only useful if you want to maintain a high throughput when your image processing time is vary variable and you want to ensure you have data ready to process all the time. If all you want to do is process the latest image as fast as possible, doing the GetImage/Grab in sequence with the processing is not that much slower, especially since it ensures the image data is in the CPU cache right when you are processing it. The other problem with the producer/consumer architecture is that if you are processing slower than the frame rate being acquired then you are always processing older frames (because they were acquired when you were processing the other frame and are already old by the time you process them)

-You could switch to a pipelined architecture using shift registers where one image is acquired into each loop iteration while another is processed and then you swap them via shift registers every iteration

-You could change your producer/consumer architecture to have two queues of images. One is of already-processed images waiting to be re-filled with data (this is what the producer loop consumes from and what the consumer loop produces) and the other is of brand new image data ready to be processed (that the producer loop produces and the consumer loop consumes). If you change it to this way you are only queuing the image references, not image data, eliminating expensive memory copies. Additionally, this means that the speed of your consumer loop ends up throttling the producer loop and preventing it from acquiring more data than your consumer can consume.

Hope this helps,

Eric