Login  Register

Re: Autothresholding results; (was FW: Threshold is giving an incomplete range ?)

Posted by Gabriel Landini on May 19, 2017; 4:14pm
URL: http://imagej.273.s1.nabble.com/Autothresholding-results-was-FW-Threshold-is-giving-an-incomplete-range-tp5018760p5018763.html

On Friday, 19 May 2017 11:19:21 BST Robert Atwood wrote:
> Using 'Otsu' I find  ---  not a little difference ---  but a big one. A
> little difference caused by the binning, a big one between implementations.
> Which is the 'real' Otsu threshold? or which different assumptions  can
> make this difference? The Otsu method seems well defined and established
> for many years so I wouldn't expect some ambiguity about what the result
> should be for a specific image and number of bins?

> The other implementations (sItk, Applet) approach a similar value as the
> image gets more continuously varying, it seems, except the AutoThresh one
> gives the same value for each level of blurring?

Hi Robert,
The same Otsu's routine in the Auto_threshold plugin is used for both the 8
and the 16bit images.
So wouldn't the differences in the granularity of the histograms account for
the inter-class variances ending up being not-directly equivalent  in 256 and
in a 2^16 greylevel versions of an image? I suppose that something similar
happens with other methods. For example a minimum valley search does not
guarantee that a coarser histogram has a minimum in that same position.

> Also, for some reason Autothresh -> Huang seems to consistently give a
> segfault in processing the one with Gaussian blur 10 ?

Yes, I can reproduce it in that image. Had a look at the source, seems to be
an array dimension issues. The original code ported from Emre Celebi's
implementation was re-written by Johannes Schindelin in 2011 to make it more
efficient in handling 16bit data.  I will compare the old and new code results.
Thanks for reporting these issues. The IJ applet still uses E Celebi's code.

I see that the itk plugin appears similar to Johannes's code but it uses a bin
multiplier to re-scale the threshold value between the min and max of the
image. That might be the reason for the differences across implementations.

Regards

Gabriel

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html