Match Pattern - Efficiency of ROI descriptor

[ehrlich]

In my application, I am tracking objects in an image using the "IMAQ Match Pattern 4" VI from the Vision Module. Currently, the tracking can not keep up with the 60 Hz acquisition rate of the camera so I would like to speed it up.

My first step was to define an ROI descriptor to look for the objects only in a (user defined) part of the image, which reduced tracking time in one frame from 30 ms to 20 ms.

However, if I instead reduce the image size by:

• setting an ROI directly in the camera such that it returns only the interesting part of the image
• or by "manually" copying the ROI from the large image into a smaller temporary one within LabView

tracking time reduces to ~ 7 ms.

I was very surprised to see, that especially the second step of cropping the image in LabView and performing the tracking on the small image is faster than the built-in ROI descriptor of the "IMAQ Match Pattern 4" VI.

Could it be that I am missing some option or parameter here? Or is there an explanation of why I see this behaviour?

[udka]

-Looks something suspicious, maybe possible to post your code along with sample image if it's ok?
-I am thinking it shouldn't change between input to ROI Descriptor and cropped image as long as both have same size of image area to search.
-How you are calculating time?

[Hatef.fouladi]

two possible thing could reason for this weird action 1 you have on other processing that involve with this image and related size and wen you corp picture it process faster 2 in nivison dll corpping part of IMAQ Match Pattern is not enhanced method to corp and it is some kind of bug!

[ehrlich]

Hi, I appreciate your input. Please find attached screenshots of a testing VI I wrote that shows the behaviour and the VI itself in case you want to give it a try (I also attached a random template image, this is not important for testing).

For no ROI and an image size of 1280 x 1024, I get ~ 22 ms. For the ROI descriptor, I get ~ 15 ms and for the Camera ROI (same region), I get ~6 ms.

So setting the ROI descriptor seems to have an effect but not as substantial as reducing image size. And in this example, there is no other code accessing the image so there should be no other process blocking it.

[Hatef.fouladi · Accepted solution]

OK what i think is that
you use ROI for camera in this case you force ccd to work just in related ROI
it means resulted images are small size from beginning and inside loop
it is mechanical action (or it is better to say that physical action )
but in second one you acquire full image size and making image smaller is piece of your processing that consume your CPU
indeed in first method you do not corp image you just configure camera to make smaller image
but in second one you do cutting image and it is part of your processing in your PC that need CPU involving

[ehrlich]

So indeed, the "IMAQ Match Pattern" VI seems to be slow applying the ROI. I just modified the code to acquire the full frame and then crop the image to the ROI I want to analyze (using the "IMAQ Extract" VI). This reduces tracking speed to ~ 6 ms which is what I get from setting the ROI physically on the camera.

PS: I also realized that my "benchmarking" using the flat sequence had a little flaw. The error (or all) input should have entered the first frame already to make sure it get's executed just before the tracking VI and nothing else is running in parallel.

[udka]

I think it may not be correct.
-I don't think setting ROI descriptor setting does cutting image, instead it changes the search region.
-Means instead of 0,0,1280,1024 as search space, it checks only in 0,0,300,300
-The cropped image from Camera or by IMAQ Extract VI or ROI defined Search should be similar.
-Otherwise there would be no point in using this terminal!!!
-Can you confirm the timing difference even after changing the error wire properly?

Also

-What's the Contour type in ROI descriptor input? 0-external, 1-internal.

-Means if it's 0, the region which you selected will be excluded and remaining place is used for searching.

-If it's 1, the region which you give is taken as search space.

[ehrlich]

The timing after chaning the error wire and removing the image display are:

- tracking full frame: ~ 40 ms (not sure why it got slower)

- tracking with ROI Descriptor: ~7.5 ms

- tracking with cropping the image: ~ 4.5 ms

- tracking with ROI set on camera: ~ 2.5 ms

[udka]

-Avoid updating indicator values inside loop since you are running at high rate.
-Use Producer/Consumer architecture to acquire images and process them parallel.
-Can you confirm on the contour type?

-Output is same in all three scenarios? Number of matches?

-You can use IMAQ Convert Rectangle to ROI for conversion.

[udka]

In the snippet you provided

1)without ROI Image size:1280 x 1024, template size remains same in all cases so can be ignored for calculations.

-the search algorithm has to search in entire image from 0,0 to 1280,1024.

2)Setting ROI descriptor, Here as i doubted the setting for ROI contour type is external. Means 0,0,300,300 rectangle region is excluded from image for search.

-I think here you wanted to give 0,0,300,300 as the search region means you have to set contour type as internal. Hence the difference.

3)Cropping image directly by selective capturing using ROI. Since Image compared to previous cases smaller, time will be taken also small.

Now,

-Try changing the contour type to internal and time sould be similar to other cases.

-Could you please post your snippet after the update and the timings.