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

[Hartmut]

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

(1.) complex input images

I have now used the new version of imreconstruct.cc, and yes it can then well
deal with the inputs that are generated by complex inputs to imextendedmax.m
and the others. (Octave's order relation for complex number is mainly based on
their absolute magnitude.)

Still I do NOT want to allow for complex input values in my new functions. To
understand this, please consider the following code example:


im = zeros (10);
im(2:4, 2:4) = 3;
im(6:8, 6:8) = 8;
out_real = imhmax (im, 4)

im = im .* sqrt(-1);
out_complex = imhmax (im, 4)


If I remove the isreal check, then the result of this code becomes:


out_real =

   0   0   0   0   0   0   0   0   0   0
   0   0   0   0   0   0   0   0   0   0
   0   0   0   0   0   0   0   0   0   0
   0   0   0   0   0   0   0   0   0   0
   0   0   0   0   0   0   0   0   0   0
   0   0   0   0   0   4   4   4   0   0
   0   0   0   0   0   4   4   4   0   0
   0   0   0   0   0   4   4   4   0   0
   0   0   0   0   0   0   0   0   0   0
   0   0   0   0   0   0   0   0   0   0

out_complex =

   0 + 0i   0 + 0i   0 + 0i   0 + 0i   0 + 0i   0 + 0i   0 + 0i   0 + 0i   0 +
0i   0 + 0i
   0 + 0i   0 + 3i   0 + 3i   0 + 3i   0 + 0i   0 + 0i   0 + 0i   0 + 0i   0 +
0i   0 + 0i
   0 + 0i   0 + 3i   0 + 3i   0 + 3i   0 + 0i   0 + 0i   0 + 0i   0 + 0i   0 +
0i   0 + 0i
   0 + 0i   0 + 3i   0 + 3i   0 + 3i   0 + 0i   0 + 0i   0 + 0i   0 + 0i   0 +
0i   0 + 0i
   0 + 0i   0 + 0i   0 + 0i   0 + 0i   0 + 0i   0 + 0i   0 + 0i   0 + 0i   0 +
0i   0 + 0i
   0 + 0i   0 + 0i   0 + 0i   0 + 0i   0 + 0i   0 + 8i   0 + 8i   0 + 8i   0 +
0i   0 + 0i
   0 + 0i   0 + 0i   0 + 0i   0 + 0i   0 + 0i   0 + 8i   0 + 8i   0 + 8i   0 +
0i   0 + 0i
   0 + 0i   0 + 0i   0 + 0i   0 + 0i   0 + 0i   0 + 8i   0 + 8i   0 + 8i   0 +
0i   0 + 0i
   0 + 0i   0 + 0i   0 + 0i   0 + 0i   0 + 0i   0 + 0i   0 + 0i   0 + 0i   0 +
0i   0 + 0i
   0 + 0i   0 + 0i   0 + 0i   0 + 0i   0 + 0i   0 + 0i   0 + 0i   0 + 0i   0 +
0i   0 + 0i


The first result (with real input) is what you expect from imhmax. All maxima
that are not 4 heigher than their neighborhood are removed. So the 3 peak is
gone, but the 8 peak remains (just lowered by 4).

But the second result (complex input) is NOT what you would (maybe) like to
get. The 3i peak is not gone this time. But it should be gone, because its
magnitude (which is the base of Octave's ordering relation in the complex
numbers) is by less then 4 bigger than its neihgborhood. The reason for this
"wrong" behavior is, that for complex numbers the assumptions of the imhmax
algorithm are not true any more, when you add a (real) value of h (the number
4) to a complex number, you do NOT get something that is by 4 bigger than
before! If you add 4 to 3i then you only get something with a magnitude of 5
(=sqrt(4^2+3^2), which is only 2 bigger than 3i. So the underlying algorithm
of all those new functions is not correct any more for complex input values.
(And it does NOT help to allow for complex h values, because the complex im
inputs might have complex angles in different directions.)

So I would like to forbid those complex input values, because the provoke
wrong results in the above sense.

(2.) delta value for float inputs in imimposemin.m

This operation can be found in the literature as "Minima imposition". The
detailed references are given in the source code of this function. But I
personally also had never heard of this functions, nor used it before.

I have only implemented this function for completeness. I wanted to implement
imhmax.m (because it was very useful in my new imfindcircles.m) And then I
searched for similar functions in the Matlab help. And because their core
algorithm is mostly only a one-liner, I've just implemented them all in one
go.

So the reason I've implemented the function at all is "because Matlab has it".
And as a conclusion I would like to also mimic the Matlab behavior of the
delta value for float inputs. Let's stick to the Matlab values, just "because
Matlab does it".  (There are already test in place for this Matlab compatible
behavior.)

So my bottom line is, to please push those functions as they are now (i.e.
V2). But let me know if you have a different view to those topics.


    _______________________________________________________

Reply to this item at:

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

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