Threshold bug

[Ed White]

Hi all,

I think I've encountered a bug in the ImageJ threshold operation. I'm
wondering if this is a known issue and if anyone has a solution.

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.

On image stacks the problem is more severe. In addition to displaying the
threshold incorrectly, it performs the threshold incorrectly. It uses the
'displayed' threshold that includes some pixels above the set threshold.
So, if I perform exactly the same threshold operation on a single image and
on an image stack containing the image, I get incorrect results on the
image stack (I've been careful to keep all settings the same and check
'Calculate threshold for each image').

Has anyone else encountered this problem before and know of a solution?

I'm running Fiji ImageJ 1.49q 64-bit on a Windows 7 machine.

Thanks,
Ed

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

[Gabriel Landini]

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

[Ed White]

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

[Gabriel Landini]

On Friday 11 Mar 2016 16:05:52 you wrote:
> 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?

Hi,
There is no practical way to handle and display a histogram of floating point
values. IJ bins the range into an 8 bit histogram (that is 256 bins) , so each
bin will contain a range of values. That is what you see.

We cannot expect to have a slider capable of going through every possible
value from -2586.34 to 260.45.... Or be able to show it in a histogram... How
large should that be?

You could convert your image to 8bits if you want to see exactly the red
pixels where they will threshold, but that is not much different from what you
are doing now as that involves you re-binning the image.

Or you could convert the 32 bit to 16 bits and use the Auto Threshold plugins
in my page (also included in the Fiji version) which use a 16bit  histogram (I
think the built in IJ thresholder bins the 16 bit images too).

When you set a value manually using the Set dialog, that would be exactly
thresholded at that value as far as I know.

Hope it helps

Gabriel

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

[Michael Schmid]

Hi Ed,

for 16-bit and float images, the display of thresholded pixels (red) is
only approximate, based on the 8-bit representation of the image used for
display. If you do an operation that depends on the threshold (Wand tool,
'Create Selection', 'Create Mask', 'Analyze Particles') it will use the
exact value, irrespective of whether a pixel appears red or not.

Michael
__________________________________________________________________________

On Fri, March 11, 2016 17:05, Ed White wrote:

> 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
>

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