Posted by
robert atwood on
May 22, 2017; 2:25pm
URL: http://imagej.273.s1.nabble.com/Autothresholding-results-was-FW-Threshold-is-giving-an-incomplete-range-tp5018760p5018773.html
I tried with some of the real data , also getting very different result from the plugin as from the built-in. Alternate programs (sITK, Matlab) are closer to the builtin result value.
Using IJ builtin, or simpleITK with either 256 or 65536 bins, Otsu's method finds the dark ball.
But AutoThresh plugin with Otsu does not find the dark ball.
Example files at anonymous ftp: This won't persist for more than several weeks however.
Real data is X-ray of a metal sphere in a hole in a plastic cylinder. Fuzzy edges are because some X-rays get through, as the ball is thinner at the edge (it is not out of focus) Some of the plastic features (another hole, edges of the hole, glue that holds the sphere ..) appear, faintly, due to diffraction effects.
ftp://ftpanon.diamond.ac.uk/I12/ForImageJ/autoThreshOtsu.zip
Archive: autoThreshOtsu.zip
Length Date Time Name
--------- ---------- ----- ----
262292 05-19-2017 11:49 appletOtsu.tif Result of blur10blob16.tif using builtin ImageJ threshold Otsu
262292 05-19-2017 11:49 autoThreshOtsu.tif Result of blur10blob16.tif using AutoThresh Otsu
524456 05-19-2017 11:37 blur10blob16.tif macro generated image, blur radius 10
524460 05-18-2017 17:41 blur2blob16.tif macro generated image, blur radius 2
524456 05-18-2017 16:44 nonblurblob16.tif macro generated image
262292 05-19-2017 11:49 sitkOtsu256bins.tif tif Result of blur10blob16.tif using simpleITK with 256 bins
262292 05-19-2017 11:49 sitkOtsu65535bins.tif Result of blur10blob16.tif using simpleITK with 65536 bins
2006466 05-22-2017 15:05 realball16.tif A real image -- find the dark ball !
1003360 05-22-2017 15:05 realball16_IJ_Otsu.tif
1003360 05-22-2017 15:05 realball16_autoThresh_Otsu.tif
1003311 05-22-2017 15:05 realball16_sitk_otsu_256.tif
1003311 05-22-2017 15:05 realball16_sitk_otsu_65536.tif
-----Original Message-----
From: ImageJ Interest Group [mailto:
[hidden email]] On Behalf Of Robert Atwood
Sent: Friday, May 19, 2017 17:33
To:
[hidden email]
Subject: Re: Autothresholding results; (was FW: Threshold is giving an incomplete range ?)
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--
ImageJ mailing list:
http://imagej.nih.gov/ij/list.html