[Octave-bug-tracker] [bug #52933] [octave-forge] (image) regionprops Perimeter returns Matlab incompatible results

[Hartmut]

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

I have tested Avinoam's code for the (new) perimeter property in comment #14
(and comment #16) and it looks good:

* All my small sample images (see comment #12) give now Matlab compatible
results.
* The incompatible image from bug #52926 gives now also a Matlab compatible
result. (details see item 6 in comment #7 of this present report)

So I don't know of any leftover incompatibilities, very nice.

@Avinoam: You mentioned "more elaborate cases" in comment #8 that gave
incompatible results as well. Are they now also "fixed"?

The present code is a bit "arbitrary", because we don't have any reasonable
justification of this new way of counting "corners", except for my
observations in comment #12. But this code seems to work fine. I am sure that
Matlab does the calculation in a very different way, and the present behavior
is probably only a side effect of their way to calculate the number of
corners.

Question: What do we prefer?
* (A) To have (quite good) Matlab compatibility. But with the only
justification of our algorithm to be "this is what Matlab does". This would
then be Avinoam's code from comment #16.
* (B) Or do we stick to the understandable code (from comment #6)? Even though
the results are slightly Matlab incompatible. But I do think the discrepancy
of the results should not seriously harm any further calculation in a real
image processing task.

@Avinoam: Sorry, I am not good in helping with speeding up your code. Maybe
Carne is. But is this code really slower than the old one, when used on real
images? Have you tested this?

    _______________________________________________________

Reply to this item at:

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

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