http://imagej.273.s1.nabble.com/About-sortings-errors-in-MaximumFinder-java-tp5009020p5009038.html
Thanks again.
> Hi José,
>
> this really goes into the details of the MaximumFinder...
>
> The MaximumFinder starts be sorting the maxima by descending value. For
> speed, this is done with 64-bit integers with the value encoded in the 32
> most significant bits and the x, y coordinates encoded in the least
> significant bits.
> The reason for the "maxSortingError" is that sorting the maxima is done
> with 32-bit integer accuracy. This might be insufficient for floating point
> images in some cases, so one has to care about cases where maxima with
> equal 32-bit values have actually different pixel values.
>
> For ByteProcessors and ShortProcessors, the maxSortingError is set to zero
> in
> public ByteProcessor findMaxima(ip, tolerance, threshold, outputType,
> excludeOnEdges, isEDM)
>
> Having maxSortingError=0 for byte&short data should be fine unless there
> is a very strange pixel value calibration, where the difference between two
> pixel values is well below 10^-9 of the total range of pixels (Find Maxima
> uses calibrated pixel values).
>
>
> Michael
> ________________________________________________________________
> On Aug 2, 2014, at 19:21, José wrote:
>
> > I am taking a look to the MaximumFinder implementation in ImageJ 148t
> > (source code available in
http://pastebin.com/wRrZqXiE ) trying to
> > understand the function analyzeAndMarkMaxima(), and I have some questions
> > about it:
> >
> > - How is the value of maxSortingError computed? (line 392) Could you
> > explain that computation?
> >
> > - Why is the condition in the if in line 569 "v2 > v0 +
> maxSortingError"?
> > Could it be "v2 > v0"?
> >
> > - Is it possible for sorting errors to happen in ByteProcessor?
> >
> > Thanks.
> >
> > José Díaz de Greñu
> >
> > --
> > ImageJ mailing list:
http://imagej.nih.gov/ij/list.html>
> --
> ImageJ mailing list:
http://imagej.nih.gov/ij/list.html>