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