Posted by
robert atwood on
May 19, 2017; 4:32pm
URL: http://imagej.273.s1.nabble.com/Autothresholding-results-was-FW-Threshold-is-giving-an-incomplete-range-tp5018760p5018764.html
THere are small differences depending on binning eg 15254 vs 15419 , that should be explained by the histogram
granularity, sure,
but the difference between 40645 and 64249 for blur2blob16.tif ? and the complete unchanging result of autoThresh->Otsu regardless of blurring the image? I'm not feelign competent to re-program the method myself to see which is right but they shouldnt really be that drastically different in behavour shoudl they?
________________________________________
From: Gabriel Landini [
[hidden email]]
Sent: 19 May 2017 17:14
To: Atwood, Robert (DLSLtd,RAL,SCI)
Cc:
[hidden email]
Subject: Re: Autothresholding results; (was FW: Threshold is giving an incomplete range ?)
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
--
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
--
ImageJ mailing list:
http://imagej.nih.gov/ij/list.html