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