Issue when thresholding 32-bit image

[Miso Mitkovski]

Dear ImageJ community,

when trying to threshold a 32-bit image, I noticed that in addition to the pixels containing values below the set threshold, some pixels with values above it are unfortunately also removed (or converted to NaN).

My aim was to convert the pixels below the threshold to NaN to then conduct measurements on the remaining pixels (area, intensity, etc.).

I noticed that most recently Gabriel Landini responded to a similar post. It sounded as though this is a known issue and that there may be a workaround. Has anyone else encountered this problem and maybe solved it in the mean time?

I would be grateful to anyone taking the time to respond.
Many greetings,
-Miso Mitkovski

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

[Divakar Ramachandran-2]

I recently learnt that a 32-bit image stores pixel values as
floating-point quantities. Could this be your problem: When comparing
floating-point numbers, it is best to define a tolerance value and
compare on the basis of the difference between the pixel value and the
threshold value being less or greater than the tolerance.

HTH,
Divakar

Miso Mitkovski wrote on Saturday 25 July 2015 02:20 AM:

> Dear ImageJ community,
>
> when trying to threshold a 32-bit image, I noticed that in addition to the pixels containing values below the set threshold, some pixels with values above it are unfortunately also removed (or converted to NaN).
>
> My aim was to convert the pixels below the threshold to NaN to then conduct measurements on the remaining pixels (area, intensity, etc.).
>
> I noticed that most recently Gabriel Landini responded to a similar post. It sounded as though this is a known issue and that there may be a workaround. Has anyone else encountered this problem and maybe solved it in the mean time?
>
> I would be grateful to anyone taking the time to respond.
> Many greetings,
> -Miso Mitkovski
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

--
*Dr. Divakar R.*
_Anupuram, TN 603127, INDIA._

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

[Michael Schmid]

Hi Miso,

currently, ImageJ displays the thresholded area (typically in red, unless you change it) by simply updating the 8-bit LUT used for displaying the image.  This has only limited accuracy.  For floating-point and 16-bit images, one typically finds a small deviation between the display and the actual selection.

Commands that are based on the threshold use the actual (accurate) values, not those of the selection.

You can use Edit>Selection>Create Selection to see the exact outline of the thresholded area.

[Side note:  As today's computers are much faster than in the early days of ImageJ, today one could display the thresholded area like an overlay; updating the overlay when moving the sliders of the Threshold panel should be fast enough.  This would resolve the 8-bit problem.  It would be some work to implement this, but I think it would be worthwhile since one could also set the threshold while viewing an image with increased contrast]

Michael
________________________________________________________________
On Jul 24, 2015, at 22:50, Miso Mitkovski wrote:

> Dear ImageJ community,
>
> when trying to threshold a 32-bit image, I noticed that in addition to the pixels containing values below the set threshold, some pixels with values above it are unfortunately also removed (or converted to NaN).
>
> My aim was to convert the pixels below the threshold to NaN to then conduct measurements on the remaining pixels (area, intensity, etc.).
>
> I noticed that most recently Gabriel Landini responded to a similar post. It sounded as though this is a known issue and that there may be a workaround. Has anyone else encountered this problem and maybe solved it in the mean time?
>
> I would be grateful to anyone taking the time to respond.
> Many greetings,
> -Miso Mitkovski
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

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