Thanks for your review, Avinoam:
1. good
2. thanks
3. I will leave those coding style issues to Carne. The coding guideline of the image package (in the file HACKING) doesn't say anything about this.
4. Yes, hough.m is still slightly Matlab incompatible. But I double checked, and it turned out that the different results you have observed here, ARE mostly really due to houghpeaks.m and not due to hough.m! Further investigation (using a saved csv file with the Matlab H result of peaks.m to debug the Octave function) showed that Matlab deletes the (593,136) value of H, therefore it gives the third peak (at 310,46) instead of the second one that Octave gives. This lead to the conclusion that Matlab uses a slightly bigger nhood for the peak deletion as my current Octave implementation. I am pretty sure that my current Octave implementation is doing what the Matlab help page says (size H = 723,180 > divided by 50 gives 14.46 and 3.6 > next bigger odd integer is 15 and 5. But Matlab seems to use 17 and 5.) So I have created a new version of my houghpeaks.m that also increases the nhood by 1 for half of the possible size values. (So their documentation is wrong here, or it is a Matlab bug I would say.) Nevertheless this new version of houghpeaks.m is now more Matlab compatible. All test still pass, Avinoams example from comment #3 now also gives Matlab compatible results, and this is added as a new test. (Slight differences of +1 in the peak positions are really due to hough.m and not to houghpeaks.m).
The result of this houghpeaks.m on Avinoams example in comment #3 now is:
P =
586 136
311 46
596 136
523 104
374 46
But if you use the Matlab result of hough(I) (e.g. via csv export) as input to this Octave function houghpeaks.m then the result is 100% Matlab compatible, now.
You can find my new version of houghpeaks.m here:
https://bitbucket.org/hgimpel/octaveimage/commits/7f928414c980bdd7360f937f32bad265011f24b5
and also attached (as file V4) to this bug report.
(file #41385)
