Feature based geometric match stability issue

[AndyN]

Thanks, I feel like we are getting somewhere.

I uploaded a faulty template. My bad.  Here is a new one. It is the same picture but this time I made sure it has the pattern info embedded.

I tested it again to be sure. Same thing one image 980, the next one nothing, 970, 980, nothing.

I am quite familiar with the example. The only problem is, it seems it is for edge based matching not for feature based matching. The template I uploaded is feature based only.

Feature based methods use  IMAQ Match Geometric Pattern (Geometric Pattern Matching (Feature Based ) Palette)  and edge based use 

IMAQ Match Geometric Pattern 2. If I got something wrong here please correct me.  I apologize for the font.

I just tested it. Edge based methods work fine (!) with both Geometric Pattern Vi and Geometric Pattern 2 VI

Feature based seems to accept only  Geometric Pattern and I guess that is why there is a separate palette for them.

Is this behavior normal? What I see is Match version 3 for intensity based methods, version 2 for edge based and version 1 for feature based. I assume the template editor is compatible for all of them? Or maybe not? Am I missing something here?

I just updated the drivers and went form 2011 to 2012 (yes I updated the drivers once again after I went up to 2012) and have all the updates form NI update utility installed and activated.

[User002]

Yes, you are right about the different VIs being for different functionality.  The example works fine for both feature or edge based, if you change those two VIs in the Match case.  Don't save it like that, however, or it will be overwritten.

Yes, the Template Editor works for each case.  You must specify what kind of 

I have now recreated the behavior you are seeing now on my side, so we may be able to take a closer look at it.  In the meanwhile, I seem to be able to use edge-based methods without trouble.  Are you having similar trouble with edge-based methods?  Or is there a reason you have to use feature-based methods?

[AndyN]

Thanks a lot!

I am good on the programming side/editor, I made my own application with all three cases  etc. I recently made an update and I wanted to clarify what I see in the machine vision toolbox.

I will have to retest it again for the edge based part because I had a case when it worked fine (the object was different though)  and I had a case when it was behaving exactly the same way.

A simple test showed up that the edge based methods with the same flexibility (rotation etc) were roughly twice slower than the template matching (intensity) and I do not have much room for slow downs.

Since I am doing it all in real-time, I would prefer actually to speed it up.

[AndyN]

I just tested the edge based method on the same set of images ( roughly 200).same conditions

It is more reliable. It misses the object once a while - particulalry in motion bluring.

However, the bottom line seems the same. In the failure cases it does not return a score at all even though I lowered it down to 10/20( of 1000).

the edged as not as distinct but I would expect to see at least a small level of similarity, unless I am missing something about the method. 

I uploaded the comparison of a working case, not working and the template with the source images and the template. 

[AndyN]

And here is the edge template.

[AndyN]

My whole point is  (and I can be wrong) that based on what I read in the Vision Concepts and the end of the day there is a correlation score.

In other words there almost always should be a small similarity between two images.

Instead it acts like a binary method- it either finds it well or not at all.

[AndyN]

Andrew, 

Do you have any update on the issue?

I see there is a NI file update for the Vision Common Resources. It does not seem related, though.

On the other hand, because of my error, I was able to force a similar problem with the template matching (intensity).

The LV Image processing is based on pointers (that is not well emphasized in the documentation). 

I passed a pointer to the matching function and in parallel to a processing function. 

The effect was similar to what I saw with feature and edge based methods. Perfect matches followed by no matches.

I assume the code for  all the matching function is heavily parallelized?

[User002]

Have you done all of your processing in parallel?  Yes, things are optimized at the low level, but I can't say too much about the level of parellization.  LabVIEW as a whole generally passes data by value, but all of the image functions use pointers.  If you do processing in parallel, it should be done by first making a copy so both operations are not operating on the same memory location.  

[AndyN]

The once I had troubles with were just a single pass/thread/wire so no ambiguity here.

[AndyN]

Any update on the issue?

Do I need to call the support to investigate it further?

Thanks.