[Octave-bug-tracker] [bug #46547] image package: canny detector in edge() should use LoG as first step

[Hartmut]

Follow-up Comment #10, bug #46547 (project octave):

Yes, I have the same observations as Carne.

Here is my reasoning about it:

* The fix of the C-FUNCTION (my very first patch, never purely applied) was
only to FIX a buggy behavior of the Canny implementation. The resulting
countours weren't properly closed before. The change in the c-function fixed
this very well. This fix has nothing to do with all the other following fixes
in the m-file. Those m-file fixes all have a different aim: Make the behavior
more Matlab compatible (which I think is necessary to add reasonable tests to
the m-file). Conclusion: The change of the c-function should be beyond any
doubt and stay.

For the various stages of the M-FILE (edge.m) I would like to summarize the
effective changes between (A) the very first implementation (probably for
years untouched), and (B) the m-file with my latest patch applied (from
comment 7).

(A) "original" implementation of edge.m:
* edge (I, "Canny", [5.2742e-004 0.3899]) gives a very good result in Matlab.
It gives a very bad result in Octave. (This was the original statement in this
bug report.)
* edge (I, "Canny") gives in Octave a quite good result on this test image.
* Conclusion: The interpretation of explicitly given threshold values was NOT
Matlab compatible before. The guessing of an automatic threshold value was
quite good, at least for this example image.

(B) "latest" implementation of edge.m with my patch from comment 7:
* edge (I, "Canny", [5.2742e-004 0.3899]) gives nearly the same result in
Octave as in Matlab. Both are good.
* edge (I, "Canny") gives a not so good result in Octave. I do not know (maybe
someone could check this...) what the Matlab result looks like in this case.
* Conclusion: The interpretation of explicitly given threshold values is
mostly Matlab compatible now. But the guessing of an automatic threshold value
is worse as before, at least for this single sample image.

So currently we do not have both: We can either have a Matlab compatible
interpretation of explicictly given threshold values. Or we can have a good
(at least good for this single example image) guessing of automatic threshold
values.

I would very much like to know the Matlab result of edge(I, "Canny") for this
example image. This would make the decision easier!

I think we have the following options:
1. stick with (A): only apply the c-function part of my patches, otherwise
stick with the old implementation
2. stick with (B): apply my latest patch
3. try to restore the automatic threshold guessing from the original
implementation (A) (was not Matlab compatible, but better than now) but keep
the Matlab compatible interpretation of thresholds as in (B). This might be
doable, but somewhere I spoiled it...
4. try to figure out what Matlab does for automatic treshold guessing.  (I
wanted to avoid this...) 

I will think about about option 3. But I personally would also be very fine
with option 2 (especially if Matlab also fails to deliver a nice edge image
without explicit threhold values given).

What are your thoughts, Carne?

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?46547>

_______________________________________________
  Nachricht gesendet von/durch Savannah
  http://savannah.gnu.org/