Posted by
Michael Schmid on
Aug 04, 2014; 10:35am
URL: http://imagej.273.s1.nabble.com/About-sortings-errors-in-MaximumFinder-java-tp5009020p5009023.html
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