[Octave-bug-tracker] [bug #46099] image package: edge(I, 'canny') gives very bad quality results

[Carnë Draug]

Follow-up Comment #17, bug #46099 (project octave):

> I intentionally made the filtering along the two dimensions seperatly,
because this should execute significantly FASTER. The gaussian filter become
quite big in size for the Canny detector (default is already 16x16). The
results of your 2D-gaussian filter will probably be 100% the same. But please
double check the run time (also with bigger values of sigma) before pushing
your 2D-filter patch. Even sigma values of several hundreds (e.g. 300) are a
reasonable use case! This is because this parameter determines the size of the
edges you are looking for.

Ah, yes. I understand the issue now with performance.  And you're right, one
dimension at a time seems much faster for all the sigma cases I tried.  There
are two missing functions imgaussfilt, and imgaussfilt3 which should probably
do it.

> Nice to hear that even the THRESHOLD values are Matlab compatible for my two
tests.
>
> About the AUTOMATIC THRESHOLDS not always being Matlab compatible: I think I
have seen this happen. But I do not have a (failing) test at hand for this,
sorry. (Yes, I meant the thresholds that are used by edge.m, when the user
does not give any explicit threshold values.)

We are having some missunderstanding.  The thresholded image for your test
cases was Matlab compatible but not the computed threshold values (second
return argument).  The tests you submitted did not even try to set them or
test them.

I couldn't figure out from Matlab documentation how they pick those threshold
values.  So maybe the actual edge methods is whole Matlab compatible and the
difference is only the threshold values?

Do you plan on further improving this or submitting more tests or should I
close this bug report?

> About the CONNECTIVITY of the Canny edge results: You are right, when I look
at some results with my input images, then all contours are 8-connected,
meaning they sometimes do have only a diagonal connection. This means the
background is only separated into two separate regions, if you use
4-connectivity for the background. But I have no insight what this means for
your tested implementation with imreconstruct.

I'm guessing a bug on the hysteresis on nonmax_supress...

    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/