Re: Octave 4.0.3: normxcorr2 producing unexpected result

[Hartmut]

This result looks mostly alright to me. For details please see the above
discussion. Here follows a shorter summary.

Octave code:

clear
pkg load image                        % using image 2.6.1 release
s = [-1 0 0 1 1 1 0 -1 -1 0 1 0 0 -1]
t = [1 1 0]
x = normxcorr2(t,s);
x(~isfinite(x))=0                       % to fix inf values (bug 50151)
[maxVal maxRawIndex] = max(x)

The resulting output is (slightly rounded):
x = 1 -0.5 -0.5 -1 -0.5 0 1 0.87 0.5 -1 -0.87 0.5 0.5 1 -0.5 -0.5
maxVal = 1
maxRawIndex = 7

The maxRawIndex could equally well be 1 or 14 instead of this 7. Those are
all the positions where x has the value 1 (the position 7 seems to be
closest to 1 because of machine precision).

The index 7 position corresponds to "1 1 0" in s, and the index 14 position
corresponds to "0 0 -1" in s. Both have the same maximum normalized cross
correlation to t. The index position 1 is just an artifact of padding the
borders (those padded borders are also currently not perfectly Matlab
compatible).

This raw index can the be transferred to the index in the original array s
if you like. The way you do this in the function find_template_1D seems
slightly wrong to me. You might do something like "index =
rawIndex-(length(t)-1)/2". Then you will get the center element in s that
corresponds to your matching substring. This value would then be 6 and would
properly correspond to the part "1 1 0" in s.



--
View this message in context: 
http://octave.1599824.n4.nabble.com/Octave-4-0-3-normxcorr2-producing-unexpected-result-tp4681543p4682907.html
Sent from the Octave - General mailing list archive at Nabble.com.