2012/3/26 Stéfan van der Walt <stefan(a)sun.ac.za>
> Hi Tony
> On Sat, Mar 24, 2012 at 4:03 PM, Tony Yu <tsyu80(a)gmail.com> wrote:
> > zero, but round-off errors are causing it to go negative. If that's the
> > case, then it's an easy fix to check that the argument is positive, but
> > someone should check my math to make sure the the code matches the
> I checked the paper vs your code, and the code looks correct. The
> only thing I didn't check was whether the normalization was done on
> the correct position in the correlation.
Thanks for checking. What do you mean by "correct position in the
> > Padding *the input* sounds like a good idea, but I think it should be
> > in such a way that the output is (M, N)---i.e. same size as the input
> > I'm not a huge fan of the Matlab output size (but maybe some people
> > this output?).
> If the user wants to pad the input, they should probably do that
> themselves beforehand. Half-template matches feel sketchy (and where
> do you stop: when at least half the template matches?). Also, with
> the new proposed padding in numpy, this should become a lot easier.
Hmm, I was under the impression that half-template matches would be
Say we have a template of a face: If it perfectly matches a patch of an
image, the result will have a match value of 1 at that location. Now, if
half the face matches perfectly but the rest is garbage, then the result
might get a value of 0.5 (I'm not sure what the value would actually be).
To me, it doesn't really matter whether the face is half-obstructed by a
shadow (but still fully in the image), or if it's half cropped by the image
edge; they should both have values around 0.5. Unfortunately, the exact
score would depend on what value was used to pad the image (Mike's
suggestion of the average seems preferable, but nothing's going to be
I agree that it'd be better for users to take care of the padding
themselves, but I think it's a common-enough use-case that we should make
it easy to pad with the image average (although turn it off by default).