On Sat, Mar 24, 2012 at 8:29 PM, Mike Sarahan <msarahan@gmail.com> wrote:
Hi Tony,

Glad you figured this out. 
 

I'm also not a huge fan of the Matlab-style padding.  I guess
theoretically, it gives your match greater range - beyond the bounds
of the image.  In practice, I found that such behavior in the presence
of noise often gave me a peak outside the image, when I knew I wanted
my peak inside the image.

I'm mixed on the input padding.  Intuitively, I think the high value
at template center is easier to understand for a human looking at the
cross correlation result image.  I know that this confused me a lot
when I first encountered cross correlation using OpenCV.  However, any
subsequent analysis (peak finding, for example) would have to account
for the difference, and I think this would be more of a headache than
a benefit to people.  I can imagine a lot of careless analyses with
offsets of exactly half the template dimensions.

Your proposed method for the padding makes more sense to me than
Matlab's.  I would recommend defaulting to no padding, and also
recommend a little documentation that warns the user about the offset
they will have to account for if using the pad option.

I can't think of a use case for padding the output with zeros.  If
anyone else knows one, I'll be happy to learn, though.

Hey Mike,

I guess my rationale for padding with zeros was the following: I want the output hotspot to match the image coordinates, but I don't want to have matches where the template exceeds the image boundaries.

With the match centered on the template-origin, this padding actually makes no difference since you're padding only the higher indices, but with the match centered on the template-center, there would be a difference. Also, there's a (usually-insignificant) computational improvement compared to padding the input.

I'm just making this stuff up as I go along, so this might not actually be a desirable use case.
 
-Tony



Best,
Mike