Mon 17 Mar 2014 11:21:40 PM UTC, comment #7:
I have pushed that change to the image package:
https://sourceforge.net/p/octave/image/ci/e9c18bff13be86a0d067969c2a3dcfc405edb0b2/
I have signed that commit with your name and email. As per the emails we changed in private, I then made some further modifications to make it work with N dimensional images and follow Octave coding guidelines, expanded documentation a bit, and added tests.
https://sourceforge.net/p/octave/image/ci/0ed283edee13a5c562b51521a457d5d996fcf022/
For future reference, there's some machine precision error that creeps in, so even if the template is within the image, the normalized cross correlation may not have any 1.
The condition there will fail around half of the times. However, I asked someone to test this in Matlab and they're not doing any better than us here.

Sat 08 Mar 2014 12:16:18 AM UTC, comment #6:
This is a reminding poke I was encouraged to issue. :)

Sat 15 Feb 2014 11:01:02 PM UTC, comment #5:
I finally got down to adjusting the tests. The bolstered up file is appended.
There is a remaining problem of principle: How to behave at the boundaries? Matlab is not a role model here, as it fails
normxcorr2(tmplt,img) == normxcorr2(tmplt,img)
The "correct" behaviour would be to only consider the overlapping parts of template and image and only subtract the differences of these overlapping parts in all three places. However, I could not find a clever way to achieve this without interpreted loops, which would be unacceptable. I went for the nexttoideal solution from my point of view, which consists in centring the whole image (line 39 in the appended file) which makes sure that images that differ only by a constant offset yield the same normalized cross correlation with the same template.
I hope you find my reasoning acceptable although the result is that in some cases the function will yield different results than matlab near the boundary (for example, my version ensures
normxcorr2(tmplt,img) == normxcorr2(tmplt,img) ).
Also note that I have the function issue a warning, if the template is larger than the image (as this most likely happens by mistake). I hope this is acceptable for Octave.
(file #30562)

Fri 07 Feb 2014 01:40:03 PM UTC, comment #4:
The deviation is not simply a matter of scaling. The normalized cross correlation used in matlab is as defined in this article, formula (2):
http://scribblethink.org/Work/nvisionInterface/nip.pdf
This means, they use "centered 2nd moments" whereas the current implementation in Octave uses "uncentered 2nd moments". Because the cross correlation itself is given by the "uncentered mixed 2nd moment", the correlation coefficient (or normalized cross correlation) is not simply given by a scaled cross correlation. I suppose that the nomenclature creating the false impression that these two quantities were related more closely is rather unfortunate.
(I will have a look at the tests when I have some more time.)

Fri 07 Feb 2014 12:56:58 PM UTC, comment #3:
I was aware that normxcorr2 was returning different values than Matlab's but my understanding was that this was a matter of different methods to normalize. Is this correct?
I am very interested in having a Matlab compatible version in the image package. However, could you please add some minimum input check and test blocks like what already exists in xcorr2? test blocks are the %! at the bottom of the file.
Finally, the copyright of the whole thing will be assign to you only, since it's no longer based on the work done in xcorr2.

Thu 06 Feb 2014 03:59:12 PM UTC, comment #2:
Originally, I thought, that xcorr2 was wrong, because it calculates (upcoming abuse of mathematical notation) <ab> and not (<ab>  <a><b>) as I expected. However, as Matlab does the same, it turns out I was mistaken. (So you actually understood me correctly and I was wrong then.)
normxcorr2 in Matlab calculates
(<ab>  <a><b>) / sqrt( (<a^2>  <a>^2)(<b^2>  <b>^2) ).
xcorr2(.,.,"coeff") in Octave currently calculates
<ab> / sqrt( <a^2><b^2> ).
(Again, mind the abuse of notation.)

Thu 06 Feb 2014 02:01:08 PM UTC, comment #1:
Thanks for reporting and clarifying your bug report over what you had posted to the mailing list. On the list it seemed like you were suggesting that xcorr2 is wrong, but perhaps it's the normxcorr2 function in the image package that needs tweaking.
As Carnë said on the mailing list, the xcorr2 function in Matlab has no options, those are Octave extensions to have feature parity with the xcorr function.
Perhaps this bug should be addressed by changing normxcorr2, and leaving xcorr2 as it is now. If xcorr2 (..., "coeff") is equivalent to xcorr (..., "coeff"), then it should be normxcorr2 that is fixed to be Matlab compatible if that's what's happening here.

Thu 06 Feb 2014 01:00:01 PM UTC, original submission:
In Octave, normxcorr2(b,a) = xcorr2(a,b,"coeff") yields different results from the corresponding matlab function.
Example:
Octave:
matlab:
Appended to this bug report is a function, that yields:
which is, up to rounding, the same as the matlab function yields (where arguments are interchanged, as the normxcorr2wrapper interchanges arguments as stated and illustrated above). I would be glad if the corresponding 8 lines of code would be integrated in Octave (and I appologize for the poor coding style).
