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

[Hartmut]

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

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:


im = zeros (10);
im(2:4, 2:4) = 3;
im(6:8, 6:8) = 8;
im = im .* sqrt(-1);
out = imextendedmax (im, 4)


The Matlab result is:

Error using imextendedmax
Expected input number 1, I, to be real.

Error in imextendedmax>ParseInputs (line 73)
validateattributes(I, {'numeric'}, {'real' 'nonsparse'}, mfilename, 'I', 1);

Error in imextendedmax (line 61)
[I,h,conn] = ParseInputs(varargin{:});

Error in my_tests (line 192)
out = imextendedmax (im, 4)


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:

error: imreconstruct: MARKER must be less or equal than MASK


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:


im0 = uint8 ([5 5 5 5 5;
              5 4 3 4 5;
              5 3 0 3 5;
              5 4 3 4 5;
              5 5 5 5 5]);                  
bw0 = false (5);
bw0(4,4) = true;

imimposemin (double(im0), bw0)

ans =
    5.0050    5.0050    5.0050    5.0050    5.0050
    5.0050    4.0050    3.0050    4.0050    5.0050
    5.0050    3.0050    0.0050    3.0050    5.0050
    5.0050    4.0050    3.0050      -Inf    5.0050
    5.0050    5.0050    5.0050    5.0050    5.0050


The Octave result, using delta=__eps__(im) is instead:

ans =
   5.00000   5.00000   5.00000   5.00000   5.00000
   5.00000   4.00000   3.00000   4.00000   5.00000
   5.00000   3.00000   0.00000   3.00000   5.00000
   5.00000   4.00000   3.00000      -Inf   5.00000
   5.00000   5.00000   5.00000   5.00000   5.00000


And the second Matlab result:

im = uint8 (10 .* ones (10));
im(6:8,6:8) = 2;
im(2:4,2:4) = 7;
im(3,3) = 5;
im(2,9) = 9;
im(3,8) = 9;
im(9,2) = 9;
im(8,3) = 9;
bw = false (10);
bw(3,3) = true;
bw(6:8, 6:8) = true;

imimposemin (double(im), bw)

ans =
   10.0080   10.0080   10.0080   10.0080   10.0080   10.0080   10.0080  
10.0080   10.0080   10.0080
   10.0080    7.0080    7.0080    7.0080   10.0080   10.0080   10.0080  
10.0080   10.0080   10.0080
   10.0080    7.0080      -Inf    7.0080   10.0080   10.0080   10.0080  
10.0080   10.0080   10.0080
   10.0080    7.0080    7.0080    7.0080   10.0080   10.0080   10.0080  
10.0080   10.0080   10.0080
   10.0080   10.0080   10.0080   10.0080   10.0080   10.0080   10.0080  
10.0080   10.0080   10.0080
   10.0080   10.0080   10.0080   10.0080   10.0080      -Inf      -Inf     
-Inf   10.0080   10.0080
   10.0080   10.0080   10.0080   10.0080   10.0080      -Inf      -Inf     
-Inf   10.0080   10.0080
   10.0080   10.0080   10.0080   10.0080   10.0080      -Inf      -Inf     
-Inf   10.0080   10.0080
   10.0080   10.0080   10.0080   10.0080   10.0080   10.0080   10.0080  
10.0080   10.0080   10.0080
   10.0080   10.0080   10.0080   10.0080   10.0080   10.0080   10.0080  
10.0080   10.0080   10.0080


Whereas the Octave result (still with delta=__eps__(im)) is:

ans =
   10.0000   10.0000   10.0000   10.0000   10.0000   10.0000   10.0000  
10.0000   10.0000   10.0000
   10.0000    7.0000    7.0000    7.0000   10.0000   10.0000   10.0000  
10.0000   10.0000   10.0000
   10.0000    7.0000      -Inf    7.0000   10.0000   10.0000   10.0000  
10.0000   10.0000   10.0000
   10.0000    7.0000    7.0000    7.0000   10.0000   10.0000   10.0000  
10.0000   10.0000   10.0000
   10.0000   10.0000   10.0000   10.0000   10.0000   10.0000   10.0000  
10.0000   10.0000   10.0000
   10.0000   10.0000   10.0000   10.0000   10.0000      -Inf      -Inf     
-Inf   10.0000   10.0000
   10.0000   10.0000   10.0000   10.0000   10.0000      -Inf      -Inf     
-Inf   10.0000   10.0000
   10.0000   10.0000   10.0000   10.0000   10.0000      -Inf      -Inf     
-Inf   10.0000   10.0000
   10.0000   10.0000   10.0000   10.0000   10.0000   10.0000   10.0000  
10.0000   10.0000   10.0000
   10.0000   10.0000   10.0000   10.0000   10.0000   10.0000   10.0000  
10.0000   10.0000   10.0000


This leads me to the conclusion that Matlab does something similar to 

delta= ( max(im(:)) - min(im(:)) ) / 1000


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) ?

    _______________________________________________________

Reply to this item at:

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

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