Re: Threshold bug

Posted by Ed White on Mar 11, 2016; 3:54pm
URL: http://imagej.273.s1.nabble.com/Threshold-bug-tp5015854p5015856.html

Hi Gabriel,

Here's an image showing what I mean:
[image: Inline image 1]
I've drawn a black cross over the pixel I'm looking at. You can see the
value is 262.73, which is above the threshold but the pixel appears red!
Are you saying it's a rounding error from mapping the 32bit image to 8bit?
I'm more troubled by the problem with image stacks, which gives different
results from performing the same threshold operation. Any idea what's
happening there?

Ed

On Fri, Mar 11, 2016 at 3:53 PM, Gabriel Landini <[hidden email]>
wrote:

> On Friday 11 Mar 2016 15:35:56 Ed White wrote:
> > I have a 32bit image on which I perform a threshold using the Huang
> > algorithm. For my particular example using Huang applies a threshold to
> > pixel values between -3586.43 and 260.45. While previewing the threshold
> > (looking at the red overlay of thresheld pixels), I zoom in on the image
> > and check individual pixel values. To my surprise, I find that some
> pixels
> > slightly above the 260.45 threshold are red in the preview, as well as
> all
> > those below 260.45 (by slightly above, I've seen values up to 266
> > included). When I actually apply the threshold it seems to be done
> > properly; in other words, those pixels displayed in red that were above
> > 260.45 are not included when the operation is preformed. To summarize, on
> > single images the bug appears to 'make red' some incorrect pixels while
> > previewing the threshold.
>
> Hi,
> The display of the 32 bit image histogram is done on 8-bit space. That is
> not
> a bug, but a way of displaying a binned histogram.
>
> Cheers
> Gabriel
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

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