[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Octave-bug-tracker] [bug #52933] [octave-forge] (image) regionprops Per
[Octave-bug-tracker] [bug #52933] [octave-forge] (image) regionprops Perimeter returns Matlab incompatible results
Tue, 13 Feb 2018 15:14:35 -0500 (EST)
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0
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
* 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
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:
Message sent via/by Savannah