[Octave-patch-tracker] [patch #9488] image package: new functions imhmax, imextendedmax, imimposemin (and imhmin, imextendedmin)

[Carnë Draug]

Follow-up Comment #4, patch #9488 (project octave):

> When I remove the test for "isreal" in my implementation of imextendedmax.m
(and also in immhmax.m, which is called by it) then I get the following result
from the above sample code: "error: imreconstruct: MARKER must be less or
equal than MASK"

You are not using the latest development of the image package. The error
message you are getting was removed with
http://hg.code.sf.net/p/octave/image/rev/4957d5743185

With current development sources of the image package, imreconstruct will
accept complex numbers.

> I don't know which definition of order Octave has on the complex numbers
(Carne mentioned this, I though that proper math does not have this),

There was a bug report about this, and whether the Octave definition made
sense and whether it was Matlab compatible. Not sure the conclusion was but
Octavge certainly has some sort of "sens" since you can use < and > operators
with complex numbers.  Even sort() will handle complex numbers.

> but even if I take this for granted, there would currently be no immediate
benefit of allowing complex input values in imextendedmax.m.

I would put it the other way around. What's the benefit of preventing the use
of complex numbers? It's more code to check for this than not checking. The
only requirement is that the elements have a order.

> The current Octave result is probably better in some sense. But this Octave
result is also very fragile and difficult to understand. For example is the
first value of the Octave result matrix equal to 10+eps(10) which is difficult
to distinguish from 10 in the display, and this meaningful difference of
eps(10) might quickly get lost in the following calculations that the user
does.
>
> @Carne: What shall we do? Mimic the (somehow arbitrary, but probably useful)
Matlab behavior, or stick to the "theoretically better" result (as done with
imregionalmax in bug #51724) ?

I'm reading about imimposemin for the first time so I don't have a strong
opinion. Can you think of case where using the Matlab approach, instead of
eps(img), could lead to an incorrect result? For example, what if one of the
values in img that is not in the marker region is Inf?

What's the real name of this operation? The matlab documentation do not
mention anything beyond "modifies the intensity image I using morphological
reconstruction so it only has regional minima wherever BW is nonzero" which
would mean that an array of Inf and -Inf only would be a "correct" result.

I will leave the decision up to you, but I would like to have tests for such
corner cases and I'm only making sure they have been thought about.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/patch/?9488>

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