I have now gathered the necessary information to add more tests for the mentioned functionality. But before supplying them as a patch, I would like to discuss the following two topics:
(1.) complex inputs (to imextendedmax, maybe also to other functions)
I have tested the following sample code:
The Matlab result is:
So Matlab does NOT support complex inputs in this case. But it is a valid question if Octave could do better here.
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:
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), but even if I take this for granted, there would currently be no immediate benefit of allowing complex input values in imextendedmax.m. (The imreconstruct error message might be due to bug #48794, but I have not digged deep enough into this to be sure.)
@Carne: What shall I do here? My suggesion would be to insist on isreal in the input checks.
(2.) The delta value for float images in imimposemin.m
In my first commit, I set this to be delta=eps(max(im(:))). But as discussed in bug #51724 this is just a suboptimal approach, due to a bug in eps() in Octave 4.2.1. Carne then introduced _eps_() into the image package, to temporarily fix this. Now it would be the best approach to also use this _eps_ function in imimposemin, and use delta=__eps__(im). (This is now also done in imregionalmax, see bug #51724.)
Unfortunatelly, Matlab does NOT seem to do this. Here are two Matlab results that I have tested:
The Octave result, using delta=__eps__(im) is instead:
And the second Matlab result:
Whereas the Octave result (still with delta=__eps__(im)) is:
This leads me to the conclusion that Matlab does something similar to
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) ?
