ImageJ

Threshold is giving an incomplete range ?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

21 messages Options

robert atwood

Threshold is giving an incomplete range ?

Hi,
I use a macro that relies upon thresholding and then analyzing particles in a stack.

I notice visually that the threshold is leaving black holes in the particles. As far as I understand the notion of selecting an automatic threshold (Otsu etc. ) should produce a single number that divides 'foreground' from 'background' , dividing the image based on intensity into two sets from [0,th] and (th,infinity)

However I get some images divided into sets of [mysteryvalue,th] and ( [0,mysteryvalue] U [th,infinity] )

I think it is taking the minimum value of the first image on the stack and using that as the lower threshold value for other images in the stack.

What I want is all the dark area to be in one set and all the bright area in the other set. Not having some of the darkest area included along with the brightest area.
How can this be achieved? Is this a bug?

Thanks

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

Screenshot.png (606K) Download Attachment

Gabriel Landini

Re: Threshold is giving an incomplete range ?

On Tuesday, 9 May 2017 11:13:31 BST you wrote:
> I notice visually that the threshold is leaving black holes in the
> particles. As far as I understand the notion of selecting an automatic
> threshold (Otsu etc. ) should produce a single number that divides
> 'foreground' from 'background' , dividing the image based on intensity into
> two sets from [0,th] and (th,infinity)

Maybe your particles are not uniform in grey level, so some parts are in and
some out of the threshol?

Can you post an example?

Cheers

Gabriel

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

robert atwood

Re: Threshold is giving an incomplete range ?

No, that is not the case. THe 'holes' are parts of the particle that is darker than the rest, the background is lighter.
It is definitley returning a threshold range that does not go to zero

________________________________________
From: ImageJ Interest Group [[hidden email]] on behalf of Gabriel Landini [[hidden email]]
Sent: 09 May 2017 12:19
To: [hidden email]
Subject: Re: Threshold is giving an incomplete range ?

On Tuesday, 9 May 2017 11:13:31 BST you wrote:
> I notice visually that the threshold is leaving black holes in the
> particles. As far as I understand the notion of selecting an automatic
> threshold (Otsu etc. ) should produce a single number that divides
> 'foreground' from 'background' , dividing the image based on intensity into
> two sets from [0,th] and (th,infinity)

Maybe your particles are not uniform in grey level, so some parts are in and
some out of the threshol?

Can you post an example?

Cheers

Gabriel

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

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

robert atwood

Re: Threshold is giving an incomplete range ?

In reply to this post by Gabriel Landini

How and where can an example be posted? As it is, it occurs with the real data and I don't have a smaller dataset, it's about 100 megabytes (stack of 36 images 1280x800

________________________________________
From: ImageJ Interest Group [[hidden email]] on behalf of Gabriel Landini [[hidden email]]
Sent: 09 May 2017 12:19
To: [hidden email]
Subject: Re: Threshold is giving an incomplete range ?

On Tuesday, 9 May 2017 11:13:31 BST you wrote:
> I notice visually that the threshold is leaving black holes in the
> particles. As far as I understand the notion of selecting an automatic
> threshold (Otsu etc. ) should produce a single number that divides
> 'foreground' from 'background' , dividing the image based on intensity into
> two sets from [0,th] and (th,infinity)

Maybe your particles are not uniform in grey level, so some parts are in and
some out of the threshol?

Can you post an example?

Cheers

Gabriel

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

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

Gabriel Landini

Re: Threshold is giving an incomplete range ?

On Tuesday, 9 May 2017 12:48:58 BST Robert Atwood wrote:
> How and where can an example be posted? As it is, it occurs with the real
> data and I don't have a smaller dataset, it's about 100 megabytes (stack of
> 36 images 1280x800

Can you crop a small section where the problem still occurs? If so, maybe you
can zip it and upload it to the IJ Forum (the mailing list has a limit on the
size of the attachments).
What image type is it?
Can you tell how you call the thresholder, or do you have an example of a
recorded macro that works with other images?
Does it occur with any of the built in samples in IJ?

Regards

Gabriel

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

robert atwood

Re: Threshold is giving an incomplete range ?

Image is 16-bit Int (also 32 bit Float exhibits this behaviour)
It seems to be definitely the 'way it works' , the limits on the little slider bars are displayed and it is not zero at the lower limit.

Using the tick box 'stack histogram' partly solves the problem by setting the lower limit of the threshold to the minimum of the current stack , thus avoiding holes in the current stack.

> -----Original Message-----
> From: ImageJ Interest Group [mailto:[hidden email]] On Behalf Of
> Gabriel Landini
> Sent: 09 May 2017 13:54
> To: [hidden email]
> Subject: Re: Threshold is giving an incomplete range ?
>
> On Tuesday, 9 May 2017 12:48:58 BST Robert Atwood wrote:
> > How and where can an example be posted? As it is, it occurs with the
> > real data and I don't have a smaller dataset, it's about 100 megabytes
> > (stack of
> > 36 images 1280x800
>
> Can you crop a small section where the problem still occurs? If so, maybe you
> can zip it and upload it to the IJ Forum (the mailing list has a limit on the size of
> the attachments).
> What image type is it?
> Can you tell how you call the thresholder, or do you have an example of a
> recorded macro that works with other images?
> Does it occur with any of the built in samples in IJ?
>
> Regards
>
> Gabriel
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

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

Miettinen, Arttu

VS: Threshold is giving an incomplete range ?

Hello everybody,

I have encountered the same problem:
Assume the pixel values in a stack are in range [m, M], but the pixel values in current slice are in range [m', M'], where either m' > m, M' < M or both. Denote threshold range by [t, T]. The threshold range is a subset of [m', M']. When threshold is applied, pixel values in range [t, T] become 255 and all other values become zero. That means values in ranges [m, t[ and ]T, M] become zero. If the user intends to use only single threshold value such that everything above the threshold value becomes 255 and everything below it become 0, he will probably set threshold range to [T, M'] and apply the threshold. Now pixels with values in range [M', M] are zeroed and that is not what the user expected.

Using stack histogram definitely solves the problem, but it is easy to forget to check the checkbox. And if you forget to check it things go wrong silently. Stack histogram is also somewhat slow to calculate for very large stacks and could squeeze the histogram view into sharp peak if the stack contains some very bright and very dark outliers. Thus it would be nice to have some workaround. Maybe a setting that lets the user select whether to use one or two thresholds? Or a possibility to change the default behaviour so that t=m' is interpreted as t=-inf and T=M' is interpreted as T=inf?

Best regards,
Arttu Miettinen

________________________________________
Lähettäjä: ImageJ Interest Group [[hidden email]] käyttäjän Robert Atwood [[hidden email]] puolesta
Lähetetty: 9. toukokuuta 2017 20:39
Vastaanottaja: [hidden email]
Aihe: Re: Threshold is giving an incomplete range ?

Image is 16-bit Int (also 32 bit Float exhibits this behaviour)
It seems to be definitely the 'way it works' , the limits on the little slider bars are displayed and it is not zero at the lower limit.

Using the tick box 'stack histogram' partly solves the problem by setting the lower limit of the threshold to the minimum of the current stack , thus avoiding holes in the current stack.

Gabriel Landini

Re: VS: Threshold is giving an incomplete range ?

Hi,
Without an example to try it will be difficult to reproduce when this happens.
There are two issues: one is boundaries set by the thresholder sliders, the
other is a threshold value set by an auto-threshold method.

What if one wants to threshold on a given range, let's say 100..150? I do not
think that <=100 should be be forced to 0.

Did you try the Auto_Threshold plugin? I think that one behaves as you expect.
http://www.mecourse.com/landinig/software/autothreshold/autothreshold.html
It also processess 16bit images with 16bit histograms.

Now if you are talking about the built-in thresholder applet, wouldn't the
threshold extreme of each slice set the to minimum if you tick the option
"Calculate threshold for each image"?

I wonder if there might be something else at play (like some recorded
threshold command that also records the value and then it becomes fixed to
subsequent slices).

The stack histogram option should not be a cure to the problem reported as it
does not compute a threshold for each slice independently which is also a
useful function.

Cheers
Gabriel

On Wednesday, 10 May 2017 11:55:42 BST [hidden email] wrote:

> I have encountered the same problem:
> Assume the pixel values in a stack are in range [m, M], but the pixel values
> in current slice are in range [m', M'], where either m' > m, M' < M or
> both. Denote threshold range by [t, T]. The threshold range is a subset of
> [m', M']. When threshold is applied, pixel values in range [t, T] become
> 255 and all other values become zero. That means values in ranges [m, t[
> and ]T, M] become zero. If the user intends to use only single threshold
> value such that everything above the threshold value becomes 255 and
> everything below it become 0, he will probably set threshold range to [T,
> M'] and apply the threshold. Now pixels with values in range [M', M] are
> zeroed and that is not what the user expected.
>
> Using stack histogram definitely solves the problem, but it is easy to
> forget to check the checkbox. And if you forget to check it things go wrong
> silently. Stack histogram is also somewhat slow to calculate for very large
> stacks and could squeeze the histogram view into sharp peak if the stack
> contains some very bright and very dark outliers. Thus it would be nice to
> have some workaround. Maybe a setting that lets the user select whether to
> use one or two thresholds? Or a possibility to change the default behaviour
> so that t=m' is interpreted as t=-inf and T=M' is interpreted as T=inf?
>

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

Miettinen, Arttu

Re: VS: Threshold is giving an incomplete range ?

Hello,

I didn't mention that I was mainly talking about 3D images, sorry about that.

Anyway, maybe the attached screenshot helps. In the top row there are two positions in a 3D distance map that is also attached. There are large values in slice 2 (left) and smaller values in slice 16 (right). In the middle row there's a threshold window and threshold value is determined according to slice 16. The intention to threshold the middle part of the object, i.e. all values larger than -5.10. In the bottom row there's result of pressing Apply button in the threshold window. I've not calculated threshold for each slice separately as this is a 3D object. Slice 16 (bottom right) is as expected but slice 2 (bottom left) contains a hole in the middle of the object.

Obviously Stack histogram checkbox solves the problem but it has its drawbacks that I mentioned in my last mail. I've got my ways around the problem but many people I know don't realize that not checking Stack histogram has this kind of effect on the result.

Best regards,
Arttu

Macro code that does the thresholding:
setSlice(16);
setAutoThreshold("Default dark");
setOption("BlackBackground", true);
run("Convert to Mask", "method=Default background=Dark black");

>-----Original Message-----
>From: ImageJ Interest Group [mailto:[hidden email]] On Behalf Of
>Gabriel Landini
>Sent: 10. toukokuuta 2017 16:16
>To: [hidden email]
>Subject: Re: VS: Threshold is giving an incomplete range ?
>
>Hi,
>Without an example to try it will be difficult to reproduce when this
>happens.
>There are two issues: one is boundaries set by the thresholder sliders, the
>other is a threshold value set by an auto-threshold method.
>
>What if one wants to threshold on a given range, let's say 100..150? I do not
>think that <=100 should be be forced to 0.
>
>Did you try the Auto_Threshold plugin? I think that one behaves as you
>expect.
>http://www.mecourse.com/landinig/software/autothreshold/autothreshold
>.html
>It also processess 16bit images with 16bit histograms.
>
>Now if you are talking about the built-in thresholder applet, wouldn't the
>threshold extreme of each slice set the to minimum if you tick the option
>"Calculate threshold for each image"?
>
>I wonder if there might be something else at play (like some recorded
>threshold command that also records the value and then it becomes fixed to
>subsequent slices).
>
>The stack histogram option should not be a cure to the problem reported as it
>does not compute a threshold for each slice independently which is also a
>useful function.
>
>Cheers
>Gabriel
>
>
>On Wednesday, 10 May 2017 11:55:42 BST [hidden email]
>wrote:
>> I have encountered the same problem:
>> Assume the pixel values in a stack are in range [m, M], but the pixel
>> values in current slice are in range [m', M'], where either m' > m, M'
>> < M or both. Denote threshold range by [t, T]. The threshold range is
>> a subset of [m', M']. When threshold is applied, pixel values in range
>> [t, T] become
>> 255 and all other values become zero. That means values in ranges [m,
>> t[ and ]T, M] become zero. If the user intends to use only single
>> threshold value such that everything above the threshold value becomes
>> 255 and everything below it become 0, he will probably set threshold
>> range to [T, M'] and apply the threshold. Now pixels with values in
>> range [M', M] are zeroed and that is not what the user expected.
>>
>> Using stack histogram definitely solves the problem, but it is easy to
>> forget to check the checkbox. And if you forget to check it things go
>> wrong silently. Stack histogram is also somewhat slow to calculate for
>> very large stacks and could squeeze the histogram view into sharp peak
>> if the stack contains some very bright and very dark outliers. Thus it
>> would be nice to have some workaround. Maybe a setting that lets the
>> user select whether to use one or two thresholds? Or a possibility to
>> change the default behaviour so that t=m' is interpreted as t=-inf and T=M'
>is interpreted as T=inf?
>>
>
>--
>ImageJ mailing list: http://imagej.nih.gov/ij/list.html

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

ij_threshold_problem.png (283K) Download Attachment

throat2_dmap_29x29x33.tif (154K) Download Attachment

Gabriel Landini

Re: VS: Threshold is giving an incomplete range ?

I think that what you are seeing is a consequence of the re-binning of the 16
and 32 bit images into 8 bit histograms (that IJ does for thresholding).
Your range is from -5.10 to 3.32, the thresholded range is then applied to all
slices. So I would think that it is correct what you see and if another slice
has a different range of values, then some values might not be covered by the
range set earlier.

Since you are thresholding a volume, I agree that it makes sense to use the
"stack histogram" option in that case, and not use it when you want a given
threshold *range* to be applied all slices.
Note that there is no absolute max or minimum in 32bit images, just the re-
binned range.

Another option is to not rely on recording the autothreshold values and use a
macro to specify exactly what range is required on the 32bit stack with
setThreshold(min,max);

Cheers

Gabriel

On Thursday, 11 May 2017 07:45:26 BST [hidden email] wrote:

> Anyway, maybe the attached screenshot helps. In the top row there are two
> positions in a 3D distance map that is also attached. There are large
> values in slice 2 (left) and smaller values in slice 16 (right). In the
> middle row there's a threshold window and threshold value is determined
> according to slice 16. The intention to threshold the middle part of the
> object, i.e. all values larger than -5.10. In the bottom row there's result
> of pressing Apply button in the threshold window. I've not calculated
> threshold for each slice separately as this is a 3D object. Slice 16
> (bottom right) is as expected but slice 2 (bottom left) contains a hole in
> the middle of the object.
>
> Obviously Stack histogram checkbox solves the problem but it has its
> drawbacks that I mentioned in my last mail. I've got my ways around the
> problem but many people I know don't realize that not checking Stack
> histogram has this kind of effect on the result.

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

robert atwood

Re: VS: Threshold is giving an incomplete range ?

Here is an example:

Macro to create an example stack
__________________________________________________

newImage("Untitled", "16-bit black", 512, 512, 10);

for (i=1;i<=nSlices;i++){
setSlice (i);
setForegroundColor(250,250,250);

run("Select All");
run("Fill", "slice");
setForegroundColor(60,60,60);
makeOval(170, 190, 130, 140);

run("Fill", "slice");
setForegroundColor(40-i,40-i,40-i);
makeOval(214, 243, 45, 44);
run("Fill", "slice");
}
run ("Select None");
setSlice(1);
________________________________________________

Then select 'Adjust - Threshold - Auto (default, NOT dark background, NOT histogram stack)
Then scroll to another slice .. Is this what you expect?
I expect a threshold with the boundary calculated from slice 1 , dividing foreground from background. I don't expect the darker center of the blob to be part of the foreground.

In developing the example I have found a further problem. If I include in the macro the command to autothrehsld -- the behaviour DOESN'T happen .. in this example the central dark blob is included in the red area.

setAutoThreshold("Default");

But if you then just open the 'adjust .. threshold' dialog box, while slice 5 is active ... the black central blob appears!

Also using setAutoThreshold("Otsu"); yields even more unexpected behaviour ...

I believe those of us who consider this to be a problem are using

-- 3-d images
-- Automatic thresholding

'threshold each image' is unacceptable because the threshold value is then different for each slice.

Also the next step does not require 'apply' the threshold, and indeed doing this would make it more complicated to program, requiring storing the original to refer the analysis of grayscale back to , wheras running 'analyse particles' with the threshold active does pretty much what I want already.

An alternative is using a different program than ImageJ for 3-d thresholding ... but ... there are so many good things about ImageJ

'stack histogram' is sometimes the right thing , but sometimes I am wanting to get the threshold that is calculated from the active slice and then apply to all slices.

A method such as Otsu's original doi:10.1109/TSMC.1979.4310076 seeks to find a single number K that separates foreground from background. It does not seek to find a range in the middle of the grayscale. That would be the multi-thresholding case.

I see that it is simply to do with the bottom of the selected range being determined by the active slice minimum. In my opinion (sorry Wayne) this is wrong for automatic threshold and it should be the -inf of the image's data type, or rathe,r simply all points with values less than K are in the red section, all greater than are in the white section -- with suitable handling of exactly equal points :-) . With respect to Gabriel, if people are seeking to automatically find a range in the middle of the total gray scale shouldn't they be using multi-threshold variants, rather than selecting what happens to be the minimum of the first slice in the stack? That is no longer 'foreground/background' separation.

If they are interactively choosing the minimum for themselves to select a range within the total grayscale, it's a different case and nothing to do with my original problem .
Colour images are also not part of my problem.

Is it such a big deal to apply the ( less than K , greater than K ) criterion in the original data space (not the 8bit reduced dataset) -- even if the value of the threshold is calculated using the reduced data?

-----Original Message-----
From: ImageJ Interest Group [mailto:[hidden email]] On Behalf Of Gabriel Landini
Sent: Thursday, May 11, 2017 12:06
To: [hidden email]
Subject: Re: VS: Threshold is giving an incomplete range ?

I think that what you are seeing is a consequence of the re-binning of the 16 and 32 bit images into 8 bit histograms (that IJ does for thresholding).
Your range is from -5.10 to 3.32, the thresholded range is then applied to all slices. So I would think that it is correct what you see and if another slice has a different range of values, then some values might not be covered by the range set earlier.

Since you are thresholding a volume, I agree that it makes sense to use the "stack histogram" option in that case, and not use it when you want a given threshold *range* to be applied all slices.
Note that there is no absolute max or minimum in 32bit images, just the re- binned range.

Another option is to not rely on recording the autothreshold values and use a macro to specify exactly what range is required on the 32bit stack with setThreshold(min,max);

Cheers

Gabriel

On Thursday, 11 May 2017 07:45:26 BST [hidden email] wrote:

> Anyway, maybe the attached screenshot helps. In the top row there are
> two positions in a 3D distance map that is also attached. There are
> large values in slice 2 (left) and smaller values in slice 16 (right).
> In the middle row there's a threshold window and threshold value is
> determined according to slice 16. The intention to threshold the
> middle part of the object, i.e. all values larger than -5.10. In the
> bottom row there's result of pressing Apply button in the threshold
> window. I've not calculated threshold for each slice separately as
> this is a 3D object. Slice 16 (bottom right) is as expected but slice
> 2 (bottom left) contains a hole in the middle of the object.
>
> Obviously Stack histogram checkbox solves the problem but it has its
> drawbacks that I mentioned in my last mail. I've got my ways around
> the problem but many people I know don't realize that not checking
> Stack histogram has this kind of effect on the result.

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

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

Diteko, Keolatlhile

Data from the DICOM Header

Could someone help me with acquiring data from the Dicom header into a table. I am analysing CT Images and would like to have data on kV, mAs, slice width, spacing between slices into one table from 300 slices.

When I go to:
File>Image >Show Info.

I manage to get the data for one slice at a time.

I don't know how to wrote a macro, so please guide on the steps to follow.

Thank you.

Keol

Sent from my Samsung Galaxy J3 - powered by Three

-------- Original message --------
From: Robert Atwood <[hidden email]>
Date: 16/05/2017 15:31 (GMT+00:00)
To: [hidden email]
Subject: Re: VS: Threshold is giving an incomplete range ?

Here is an example:

Macro to create an example stack
__________________________________________________

newImage("Untitled", "16-bit black", 512, 512, 10);

for (i=1;i<=nSlices;i++){
setSlice (i);
setForegroundColor(250,250,250);

run("Select All");
run("Fill", "slice");
setForegroundColor(60,60,60);
makeOval(170, 190, 130, 140);

run("Fill", "slice");
setForegroundColor(40-i,40-i,40-i);
makeOval(214, 243, 45, 44);
run("Fill", "slice");
}
run ("Select None");
setSlice(1);
________________________________________________

Then select 'Adjust - Threshold - Auto (default, NOT dark background, NOT histogram stack)
Then scroll to another slice .. Is this what you expect?
I expect a threshold with the boundary calculated from slice 1 , dividing foreground from background. I don't expect the darker center of the blob to be part of the foreground.

In developing the example I have found a further problem. If I include in the macro the command to autothrehsld -- the behaviour DOESN'T happen .. in this example the central dark blob is included in the red area.

setAutoThreshold("Default");

But if you then just open the 'adjust .. threshold' dialog box, while slice 5 is active ... the black central blob appears!

Also using setAutoThreshold("Otsu"); yields even more unexpected behaviour ...

I believe those of us who consider this to be a problem are using

-- 3-d images
-- Automatic thresholding

'threshold each image' is unacceptable because the threshold value is then different for each slice.

Also the next step does not require 'apply' the threshold, and indeed doing this would make it more complicated to program, requiring storing the original to refer the analysis of grayscale back to , wheras running 'analyse particles' with the threshold active does pretty much what I want already.

An alternative is using a different program than ImageJ for 3-d thresholding ... but ... there are so many good things about ImageJ

'stack histogram' is sometimes the right thing , but sometimes I am wanting to get the threshold that is calculated from the active slice and then apply to all slices.

A method such as Otsu's original doi:10.1109/TSMC.1979.4310076 seeks to find a single number K that separates foreground from background. It does not seek to find a range in the middle of the grayscale. That would be the multi-thresholding case.

I see that it is simply to do with the bottom of the selected range being determined by the active slice minimum. In my opinion (sorry Wayne) this is wrong for automatic threshold and it should be the -inf of the image's data type, or rathe,r simply all points with values less than K are in the red section, all greater than are in the white section -- with suitable handling of exactly equal points :-) . With respect to Gabriel, if people are seeking to automatically find a range in the middle of the total gray scale shouldn't they be using multi-threshold variants, rather than selecting what happens to be the minimum of the first slice in the stack? That is no longer 'foreground/background' separation.

If they are interactively choosing the minimum for themselves to select a range within the total grayscale, it's a different case and nothing to do with my original problem .
Colour images are also not part of my problem.

Is it such a big deal to apply the ( less than K , greater than K ) criterion in the original data space (not the 8bit reduced dataset) -- even if the value of the threshold is calculated using the reduced data?

-----Original Message-----
From: ImageJ Interest Group [mailto:[hidden email]] On Behalf Of Gabriel Landini
Sent: Thursday, May 11, 2017 12:06
To: [hidden email]
Subject: Re: VS: Threshold is giving an incomplete range ?

I think that what you are seeing is a consequence of the re-binning of the 16 and 32 bit images into 8 bit histograms (that IJ does for thresholding).
Your range is from -5.10 to 3.32, the thresholded range is then applied to all slices. So I would think that it is correct what you see and if another slice has a different range of values, then some values might not be covered by the range set earlier.

Since you are thresholding a volume, I agree that it makes sense to use the "stack histogram" option in that case, and not use it when you want a given threshold *range* to be applied all slices.
Note that there is no absolute max or minimum in 32bit images, just the re- binned range.

Another option is to not rely on recording the autothreshold values and use a macro to specify exactly what range is required on the 32bit stack with setThreshold(min,max);

Cheers

Gabriel

On Thursday, 11 May 2017 07:45:26 BST [hidden email] wrote:

Gabriel Landini

Re: VS: Threshold is giving an incomplete range ?

In reply to this post by robert atwood

Thanks for the example.
Most of this problem seems that we are dealing with the threshold values set,
and one needs to "Apply" the threshold in the stack to get the expected result
into a binary image.

When you press "Apply", you are asked whether to "Calculate threshold for each
image". This does what you are expecting, setting the minimum to the minimum
of each slice.
Note that for the automated methods, IJ re-bins the greyscale data of 16 and
32 bit images into 8 bit space. Each slice is re-binned independently (unless
you select Stack histogram) and you get different min and max for each slice.
This is to get around thresholding 32bit images (see further for a 16 bit
case).

So detecting the threshold once (we see it in red) and moving to other slices
is actually showing that each slice greyscale data has been re-binned
differently and the min and max do not match across slices.

I think it would be useful to assume that the IJ thresholder applet just sets
the range of threshold, it does not detect a new threshold when you move to a
different slice in a stack. Using the Stack histogram option, of course gets
around this as now the histogram of the whole data is known.

If you want to process 16 bit images in 16 bit space (i.e. without the re-
binning) perhaps this could be of help (it is slower, of course as now it
processes 16bit histograms):
http://www.mecourse.com/landinig/software/autothreshold/autothreshold.html
(it comes installed by default in Fiji).
However that won't work with 32bit images, only 8 and 16 bits and assumes that
you want the result of thresholding as binary images.

Hope it helps a bit.
Regards

Gabriel

On Tuesday, 16 May 2017 14:28:57 BST Robert Atwood wrote:

> Here is an example:
>
> Macro to create an example stack
> __________________________________________________
>
> newImage("Untitled", "16-bit black", 512, 512, 10);
>
> for (i=1;i<=nSlices;i++){
> setSlice (i);
> setForegroundColor(250,250,250);
>
> run("Select All");
> run("Fill", "slice");
> setForegroundColor(60,60,60);
> makeOval(170, 190, 130, 140);
>
> run("Fill", "slice");
> setForegroundColor(40-i,40-i,40-i);
> makeOval(214, 243, 45, 44);
> run("Fill", "slice");
> }
> run ("Select None");
> setSlice(1);
> ________________________________________________
>
>
> Then select 'Adjust - Threshold - Auto (default, NOT dark background, NOT
> histogram stack) Then scroll to another slice .. Is this what you expect?
> I expect a threshold with the boundary calculated from slice 1 , dividing
> foreground from background. I don't expect the darker center of the blob to
> be part of the foreground.
>
> In developing the example I have found a further problem. If I include in
> the macro the command to autothrehsld -- the behaviour DOESN'T happen .. in
> this example the central dark blob is included in the red area.
>
> setAutoThreshold("Default");
>
> But if you then just open the 'adjust .. threshold' dialog box, while slice
> 5 is active ... the black central blob appears!
>
> Also using setAutoThreshold("Otsu"); yields even more unexpected behaviour
> ...
>
>
> I believe those of us who consider this to be a problem are using
>
> -- 3-d images
> -- Automatic thresholding
>
>
> 'threshold each image' is unacceptable because the threshold value is then
> different for each slice.
>
> Also the next step does not require 'apply' the threshold, and indeed doing
> this would make it more complicated to program, requiring storing the
> original to refer the analysis of grayscale back to , wheras running
> 'analyse particles' with the threshold active does pretty much what I want
> already.
>
> An alternative is using a different program than ImageJ for 3-d thresholding
> ... but ... there are so many good things about ImageJ
>
> 'stack histogram' is sometimes the right thing , but sometimes I am wanting
> to get the threshold that is calculated from the active slice and then
> apply to all slices.
>
>
> A method such as Otsu's original doi:10.1109/TSMC.1979.4310076 seeks to
> find a single number K that separates foreground from background. It does
> not seek to find a range in the middle of the grayscale. That would be the
> multi-thresholding case.
>
> I see that it is simply to do with the bottom of the selected range being
> determined by the active slice minimum. In my opinion (sorry Wayne) this is
> wrong for automatic threshold and it should be the -inf of the image's data
> type, or rathe,r simply all points with values less than K are in the red
> section, all greater than are in the white section -- with suitable
> handling of exactly equal points :-) . With respect to Gabriel, if people
> are seeking to automatically find a range in the middle of the total gray
> scale shouldn't they be using multi-threshold variants, rather than
> selecting what happens to be the minimum of the first slice in the stack?
> That is no longer 'foreground/background' separation.
>
> If they are interactively choosing the minimum for themselves to select a
> range within the total grayscale, it's a different case and nothing to do
> with my original problem . Colour images are also not part of my problem.
>
> Is it such a big deal to apply the ( less than K , greater than K )
> criterion in the original data space (not the 8bit reduced dataset) -- even
> if the value of the threshold is calculated using the reduced data?
>
>
>
>
>
>
>
>
>
> -----Original Message-----
> From: ImageJ Interest Group [mailto:[hidden email]] On Behalf Of
> Gabriel Landini Sent: Thursday, May 11, 2017 12:06
> To: [hidden email]
> Subject: Re: VS: Threshold is giving an incomplete range ?
>
> I think that what you are seeing is a consequence of the re-binning of the
> 16 and 32 bit images into 8 bit histograms (that IJ does for thresholding).
> Your range is from -5.10 to 3.32, the thresholded range is then applied to
> all slices. So I would think that it is correct what you see and if another
> slice has a different range of values, then some values might not be
> covered by the range set earlier.
>
> Since you are thresholding a volume, I agree that it makes sense to use the
> "stack histogram" option in that case, and not use it when you want a given
> threshold *range* to be applied all slices. Note that there is no absolute
> max or minimum in 32bit images, just the re- binned range.
>
> Another option is to not rely on recording the autothreshold values and use
> a macro to specify exactly what range is required on the 32bit stack with
> setThreshold(min,max);
>
> Cheers
>
> Gabriel
>
> On Thursday, 11 May 2017 07:45:26 BST [hidden email] wrote:
> > Anyway, maybe the attached screenshot helps. In the top row there are
> > two positions in a 3D distance map that is also attached. There are
> > large values in slice 2 (left) and smaller values in slice 16 (right).
> > In the middle row there's a threshold window and threshold value is
> > determined according to slice 16. The intention to threshold the
> > middle part of the object, i.e. all values larger than -5.10. In the
> > bottom row there's result of pressing Apply button in the threshold
> > window. I've not calculated threshold for each slice separately as
> > this is a 3D object. Slice 16 (bottom right) is as expected but slice
> > 2 (bottom left) contains a hole in the middle of the object.
> >
> > Obviously Stack histogram checkbox solves the problem but it has its
> > drawbacks that I mentioned in my last mail. I've got my ways around
> > the problem but many people I know don't realize that not checking
> > Stack histogram has this kind of effect on the result.
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>
> --
> 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

ctrueden

Re: Data from the DICOM Header

In reply to this post by Diteko, Keolatlhile

Hi Keol,

Have you had a look at this page yet?
https://imagej.net/DICOM

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - https://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden
Did you know ImageJ has a forum? http://forum.imagej.net/

On Tue, May 16, 2017 at 11:06 AM, Diteko, Keolatlhile <
[hidden email]> wrote:

> Could someone help me with acquiring data from the Dicom header into a
> table. I am analysing CT Images and would like to have data on kV, mAs,
> slice width, spacing between slices into one table from 300 slices.
>
> When I go to:
> File>Image >Show Info.
>
> I manage to get the data for one slice at a time.
>
> I don't know how to wrote a macro, so please guide on the steps to follow.
>
> Thank you.
>
> Keol
>
>
>
> Sent from my Samsung Galaxy J3 - powered by Three
>
>
> -------- Original message --------
> From: Robert Atwood <[hidden email]>
> Date: 16/05/2017 15:31 (GMT+00:00)
> To: [hidden email]
> Subject: Re: VS: Threshold is giving an incomplete range ?
>
> Here is an example:
>
> Macro to create an example stack
> __________________________________________________
>
> newImage("Untitled", "16-bit black", 512, 512, 10);
>
> for (i=1;i<=nSlices;i++){
> setSlice (i);
> setForegroundColor(250,250,250);
>
> run("Select All");
> run("Fill", "slice");
> setForegroundColor(60,60,60);
> makeOval(170, 190, 130, 140);
>
> run("Fill", "slice");
> setForegroundColor(40-i,40-i,40-i);
> makeOval(214, 243, 45, 44);
> run("Fill", "slice");
> }
> run ("Select None");
> setSlice(1);
> ________________________________________________
>
>
> Then select 'Adjust - Threshold - Auto (default, NOT dark background, NOT
> histogram stack)
> Then scroll to another slice .. Is this what you expect?
> I expect a threshold with the boundary calculated from slice 1 , dividing
> foreground from background. I don't expect the darker center of the blob to
> be part of the foreground.
>
> In developing the example I have found a further problem. If I include in
> the macro the command to autothrehsld -- the behaviour DOESN'T happen .. in
> this example the central dark blob is included in the red area.
>
> setAutoThreshold("Default");
>
> But if you then just open the 'adjust .. threshold' dialog box, while
> slice 5 is active ... the black central blob appears!
>
> Also using setAutoThreshold("Otsu"); yields even more unexpected behaviour
> ...
>
>
> I believe those of us who consider this to be a problem are using
>
> -- 3-d images
> -- Automatic thresholding
>
>
> 'threshold each image' is unacceptable because the threshold value is then
> different for each slice.
>
> Also the next step does not require 'apply' the threshold, and indeed
> doing this would make it more complicated to program, requiring storing the
> original to refer the analysis of grayscale back to , wheras running
> 'analyse particles' with the threshold active does pretty much what I want
> already.
>
> An alternative is using a different program than ImageJ for 3-d
> thresholding ... but ... there are so many good things about ImageJ
>
> 'stack histogram' is sometimes the right thing , but sometimes I am
> wanting to get the threshold that is calculated from the active slice and
> then apply to all slices.
>
>
> A method such as Otsu's original doi:10.1109/TSMC.1979.4310076 seeks to
> find a single number K that separates foreground from background. It does
> not seek to find a range in the middle of the grayscale. That would be the
> multi-thresholding case.
>
> I see that it is simply to do with the bottom of the selected range being
> determined by the active slice minimum. In my opinion (sorry Wayne) this is
> wrong for automatic threshold and it should be the -inf of the image's data
> type, or rathe,r simply all points with values less than K are in the red
> section, all greater than are in the white section -- with suitable
> handling of exactly equal points :-) . With respect to Gabriel, if people
> are seeking to automatically find a range in the middle of the total gray
> scale shouldn't they be using multi-threshold variants, rather than
> selecting what happens to be the minimum of the first slice in the stack?
> That is no longer 'foreground/background' separation.
>
> If they are interactively choosing the minimum for themselves to select a
> range within the total grayscale, it's a different case and nothing to do
> with my original problem .
> Colour images are also not part of my problem.
>
> Is it such a big deal to apply the ( less than K , greater than K )
> criterion in the original data space (not the 8bit reduced dataset) -- even
> if the value of the threshold is calculated using the reduced data?
>
>
>
>
>
>
>
>
>
> -----Original Message-----
> From: ImageJ Interest Group [mailto:[hidden email]] On Behalf Of
> Gabriel Landini
> Sent: Thursday, May 11, 2017 12:06
> To: [hidden email]
> Subject: Re: VS: Threshold is giving an incomplete range ?
>
> I think that what you are seeing is a consequence of the re-binning of the
> 16 and 32 bit images into 8 bit histograms (that IJ does for thresholding).
> Your range is from -5.10 to 3.32, the thresholded range is then applied to
> all slices. So I would think that it is correct what you see and if another
> slice has a different range of values, then some values might not be
> covered by the range set earlier.
>
> Since you are thresholding a volume, I agree that it makes sense to use
> the "stack histogram" option in that case, and not use it when you want a
> given threshold *range* to be applied all slices.
> Note that there is no absolute max or minimum in 32bit images, just the
> re- binned range.
>
> Another option is to not rely on recording the autothreshold values and
> use a macro to specify exactly what range is required on the 32bit stack
> with setThreshold(min,max);
>
> Cheers
>
> Gabriel
>
> On Thursday, 11 May 2017 07:45:26 BST [hidden email] wrote:
> > Anyway, maybe the attached screenshot helps. In the top row there are
> > two positions in a 3D distance map that is also attached. There are
> > large values in slice 2 (left) and smaller values in slice 16 (right).
> > In the middle row there's a threshold window and threshold value is
> > determined according to slice 16. The intention to threshold the
> > middle part of the object, i.e. all values larger than -5.10. In the
> > bottom row there's result of pressing Apply button in the threshold
> > window. I've not calculated threshold for each slice separately as
> > this is a 3D object. Slice 16 (bottom right) is as expected but slice
> > 2 (bottom left) contains a hole in the middle of the object.
> >
> > Obviously Stack histogram checkbox solves the problem but it has its
> > drawbacks that I mentioned in my last mail. I've got my ways around
> > the problem but many people I know don't realize that not checking
> > Stack histogram has this kind of effect on the result.
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>
> --
> 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
>

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

Michael Wilson-6

Re: Data from the DICOM Header

In reply to this post by Diteko, Keolatlhile

How about this as a starter:

Open your dicom image,

Paste the text below into a File> New> Text Window

//---------------------------------------------------------------------------------------
kVp_tag = "0018,0060";
slice_thickness_tag = "0018,0050";
// add more tags here if needed
// e.g. thing_tag = "xxxx,xxxx";

print("slice", "kVp", "thickness"); // add more things on the end as needed

for(slice = 1; slice < nSlices+1; slice++) {
setSlice(slice);
kVp = getInfo(kVp_tag);
slice_thickness = getInfo(slice_thickness_tag);
// thing = getInfo(thing_tag);
print(slice, kVp, slice_thickness); // add more things on the end as needed
}
//--------------------------------------------------------------------------------------

... then just click run!

Dr. Michael Wilson
Nuclear Medicine - Physicist

Tel: +44 (0) 121 371 2329
Internal: 12329
Email: [hidden email]
Web: http://www.uhb.nhs.uk

Physicist's Office (15)
Medical Physics - University Hospitals Birmingham NHS Foundation Trust
Queen Elizabeth Hospital Birmingham, Mindelsohn Way, Edgbaston
Birmingham, B15 2GW

-----Original Message-----
From: ImageJ Interest Group [mailto:[hidden email]] On Behalf Of Diteko, Keolatlhile
Sent: 16 May 2017 17:06
To: [hidden email]
Subject: Data from the DICOM Header

Could someone help me with acquiring data from the Dicom header into a table. I am analysing CT Images and would like to have data on kV, mAs, slice width, spacing between slices into one table from 300 slices.

When I go to:
File>Image >Show Info.

I manage to get the data for one slice at a time.

I don't know how to wrote a macro, so please guide on the steps to follow.

Thank you.

Keol

Sent from my Samsung Galaxy J3 - powered by Three

-------- Original message --------
From: Robert Atwood <[hidden email]>
Date: 16/05/2017 15:31 (GMT+00:00)
To: [hidden email]
Subject: Re: VS: Threshold is giving an incomplete range ?

Here is an example:

Macro to create an example stack
__________________________________________________

newImage("Untitled", "16-bit black", 512, 512, 10);

for (i=1;i<=nSlices;i++){
setSlice (i);
setForegroundColor(250,250,250);

run("Select All");
run("Fill", "slice");
setForegroundColor(60,60,60);
makeOval(170, 190, 130, 140);

run("Fill", "slice");
setForegroundColor(40-i,40-i,40-i);
makeOval(214, 243, 45, 44);
run("Fill", "slice");
}
run ("Select None");
setSlice(1);
________________________________________________

Then select 'Adjust - Threshold - Auto (default, NOT dark background, NOT histogram stack) Then scroll to another slice .. Is this what you expect?
I expect a threshold with the boundary calculated from slice 1 , dividing foreground from background. I don't expect the darker center of the blob to be part of the foreground.

In developing the example I have found a further problem. If I include in the macro the command to autothrehsld -- the behaviour DOESN'T happen .. in this example the central dark blob is included in the red area.

setAutoThreshold("Default");

But if you then just open the 'adjust .. threshold' dialog box, while slice 5 is active ... the black central blob appears!

Also using setAutoThreshold("Otsu"); yields even more unexpected behaviour ...

I believe those of us who consider this to be a problem are using

-- 3-d images
-- Automatic thresholding

'threshold each image' is unacceptable because the threshold value is then different for each slice.

Also the next step does not require 'apply' the threshold, and indeed doing this would make it more complicated to program, requiring storing the original to refer the analysis of grayscale back to , wheras running 'analyse particles' with the threshold active does pretty much what I want already.

An alternative is using a different program than ImageJ for 3-d thresholding ... but ... there are so many good things about ImageJ

'stack histogram' is sometimes the right thing , but sometimes I am wanting to get the threshold that is calculated from the active slice and then apply to all slices.

A method such as Otsu's original doi:10.1109/TSMC.1979.4310076 seeks to find a single number K that separates foreground from background. It does not seek to find a range in the middle of the grayscale. That would be the multi-thresholding case.

I see that it is simply to do with the bottom of the selected range being determined by the active slice minimum. In my opinion (sorry Wayne) this is wrong for automatic threshold and it should be the -inf of the image's data type, or rathe,r simply all points with values less than K are in the red section, all greater than are in the white section -- with suitable handling of exactly equal points :-) . With respect to Gabriel, if people are seeking to automatically find a range in the middle of the total gray scale shouldn't they be using multi-threshold variants, rather than selecting what happens to be the minimum of the first slice in the stack? That is no longer 'foreground/background' separation.

If they are interactively choosing the minimum for themselves to select a range within the total grayscale, it's a different case and nothing to do with my original problem .
Colour images are also not part of my problem.

Is it such a big deal to apply the ( less than K , greater than K ) criterion in the original data space (not the 8bit reduced dataset) -- even if the value of the threshold is calculated using the reduced data?

-----Original Message-----
From: ImageJ Interest Group [mailto:[hidden email]] On Behalf Of Gabriel Landini
Sent: Thursday, May 11, 2017 12:06
To: [hidden email]
Subject: Re: VS: Threshold is giving an incomplete range ?

I think that what you are seeing is a consequence of the re-binning of the 16 and 32 bit images into 8 bit histograms (that IJ does for thresholding).
Your range is from -5.10 to 3.32, the thresholded range is then applied to all slices. So I would think that it is correct what you see and if another slice has a different range of values, then some values might not be covered by the range set earlier.

Since you are thresholding a volume, I agree that it makes sense to use the "stack histogram" option in that case, and not use it when you want a given threshold *range* to be applied all slices.
Note that there is no absolute max or minimum in 32bit images, just the re- binned range.

Another option is to not rely on recording the autothreshold values and use a macro to specify exactly what range is required on the 32bit stack with setThreshold(min,max);

Cheers

Gabriel

On Thursday, 11 May 2017 07:45:26 BST [hidden email] wrote:

robert atwood

Re: VS: Threshold is giving an incomplete range ?

In reply to this post by Gabriel Landini

Hi,
Gabriel, you are making it too complicated.

I agree with Arttu, and his description seems a little more mathematically rigorous thanks! and I think each of us now understands what the applet is doing. I just believe that it is incorrect, it's a choice somewhere, sometime to take the minimum as also the 'lower' end of the range, and I think it's not technically a problem to simply apply a greater/less than criterion on whatever value in the original data is found by the algorithm .

If the developers just say that this is how they're going to do it , it's been done that way for years etc. etc. then , indeed, I use a workaround such as including another part of code to set the lower limit down or extract the calculated autothreshold value and re-apply it with a different dataset .

The 'stack' tick box seems to do close to what is needed in this case.

________________________________________
From: ImageJ Interest Group [[hidden email]] on behalf of Gabriel Landini [[hidden email]]
Sent: 16 May 2017 17:23
To: [hidden email]
Subject: Re: VS: Threshold is giving an incomplete range ?

Thanks for the example.
Most of this problem seems that we are dealing with the threshold values set,
and one needs to "Apply" the threshold in the stack to get the expected result
into a binary image.

When you press "Apply", you are asked whether to "Calculate threshold for each
image". This does what you are expecting, setting the minimum to the minimum
of each slice.
Note that for the automated methods, IJ re-bins the greyscale data of 16 and
32 bit images into 8 bit space. Each slice is re-binned independently (unless
you select Stack histogram) and you get different min and max for each slice.
This is to get around thresholding 32bit images (see further for a 16 bit
case).

So detecting the threshold once (we see it in red) and moving to other slices
is actually showing that each slice greyscale data has been re-binned
differently and the min and max do not match across slices.

I think it would be useful to assume that the IJ thresholder applet just sets
the range of threshold, it does not detect a new threshold when you move to a
different slice in a stack. Using the Stack histogram option, of course gets
around this as now the histogram of the whole data is known.

If you want to process 16 bit images in 16 bit space (i.e. without the re-
binning) perhaps this could be of help (it is slower, of course as now it
processes 16bit histograms):
http://www.mecourse.com/landinig/software/autothreshold/autothreshold.html
(it comes installed by default in Fiji).
However that won't work with 32bit images, only 8 and 16 bits and assumes that
you want the result of thresholding as binary images.

Hope it helps a bit.
Regards

Gabriel

On Tuesday, 16 May 2017 14:28:57 BST Robert Atwood wrote:

Wayne Rasband-2

Re: Threshold is giving an incomplete range ?

In reply to this post by robert atwood

> On May 16, 2017, at 10:28 AM, Robert Atwood <[hidden email]> wrote:
>
> Here is an example:
>
> Macro to create an example stack

This bug is fixed in the latest ImageJ daily build (1.51o16), thanks to the very helpful example stack created by this macro.

-wayne

> __________________________________________________
>
> newImage("Untitled", "16-bit black", 512, 512, 10);
>
> for (i=1;i<=nSlices;i++){
> setSlice (i);
> setForegroundColor(250,250,250);
>
> run("Select All");
> run("Fill", "slice");
> setForegroundColor(60,60,60);
> makeOval(170, 190, 130, 140);
>
> run("Fill", "slice");
> setForegroundColor(40-i,40-i,40-i);
> makeOval(214, 243, 45, 44);
> run("Fill", "slice");
> }
> run ("Select None");
> setSlice(1);
> ________________________________________________
>
>
> Then select 'Adjust - Threshold - Auto (default, NOT dark background, NOT histogram stack)
> Then scroll to another slice .. Is this what you expect?
> I expect a threshold with the boundary calculated from slice 1 , dividing foreground from background. I don't expect the darker center of the blob to be part of the foreground.
>
> In developing the example I have found a further problem. If I include in the macro the command to autothrehsld -- the behaviour DOESN'T happen .. in this example the central dark blob is included in the red area.
>
> setAutoThreshold("Default");
>
> But if you then just open the 'adjust .. threshold' dialog box, while slice 5 is active ... the black central blob appears!
>
> Also using setAutoThreshold("Otsu"); yields even more unexpected behaviour ...
>
>
> I believe those of us who consider this to be a problem are using
>
> -- 3-d images
> -- Automatic thresholding
>
>
> 'threshold each image' is unacceptable because the threshold value is then different for each slice.
>
> Also the next step does not require 'apply' the threshold, and indeed doing this would make it more complicated to program, requiring storing the original to refer the analysis of grayscale back to , wheras running 'analyse particles' with the threshold active does pretty much what I want already.
>
> An alternative is using a different program than ImageJ for 3-d thresholding ... but ... there are so many good things about ImageJ
>
> 'stack histogram' is sometimes the right thing , but sometimes I am wanting to get the threshold that is calculated from the active slice and then apply to all slices.
>
>
> A method such as Otsu's original doi:10.1109/TSMC.1979.4310076 seeks to find a single number K that separates foreground from background. It does not seek to find a range in the middle of the grayscale. That would be the multi-thresholding case.
>
> I see that it is simply to do with the bottom of the selected range being determined by the active slice minimum. In my opinion (sorry Wayne) this is wrong for automatic threshold and it should be the -inf of the image's data type, or rathe,r simply all points with values less than K are in the red section, all greater than are in the white section -- with suitable handling of exactly equal points :-) . With respect to Gabriel, if people are seeking to automatically find a range in the middle of the total gray scale shouldn't they be using multi-threshold variants, rather than selecting what happens to be the minimum of the first slice in the stack? That is no longer 'foreground/background' separation.
>
> If they are interactively choosing the minimum for themselves to select a range within the total grayscale, it's a different case and nothing to do with my original problem .
> Colour images are also not part of my problem.
>
> Is it such a big deal to apply the ( less than K , greater than K ) criterion in the original data space (not the 8bit reduced dataset) -- even if the value of the threshold is calculated using the reduced data?
>
>
>
>
>
>
>
>
>
> -----Original Message-----
> From: ImageJ Interest Group [mailto:[hidden email]] On Behalf Of Gabriel Landini
> Sent: Thursday, May 11, 2017 12:06
> To: [hidden email]
> Subject: Re: VS: Threshold is giving an incomplete range ?
>
> I think that what you are seeing is a consequence of the re-binning of the 16 and 32 bit images into 8 bit histograms (that IJ does for thresholding).
> Your range is from -5.10 to 3.32, the thresholded range is then applied to all slices. So I would think that it is correct what you see and if another slice has a different range of values, then some values might not be covered by the range set earlier.
>
> Since you are thresholding a volume, I agree that it makes sense to use the "stack histogram" option in that case, and not use it when you want a given threshold *range* to be applied all slices.
> Note that there is no absolute max or minimum in 32bit images, just the re- binned range.
>
> Another option is to not rely on recording the autothreshold values and use a macro to specify exactly what range is required on the 32bit stack with setThreshold(min,max);
>
> Cheers
>
> Gabriel
>
> On Thursday, 11 May 2017 07:45:26 BST [hidden email] wrote:
>> Anyway, maybe the attached screenshot helps. In the top row there are
>> two positions in a 3D distance map that is also attached. There are
>> large values in slice 2 (left) and smaller values in slice 16 (right).
>> In the middle row there's a threshold window and threshold value is
>> determined according to slice 16. The intention to threshold the
>> middle part of the object, i.e. all values larger than -5.10. In the
>> bottom row there's result of pressing Apply button in the threshold
>> window. I've not calculated threshold for each slice separately as
>> this is a 3D object. Slice 16 (bottom right) is as expected but slice
>> 2 (bottom left) contains a hole in the middle of the object.
>>
>> Obviously Stack histogram checkbox solves the problem but it has its
>> drawbacks that I mentioned in my last mail. I've got my ways around
>> the problem but many people I know don't realize that not checking
>> Stack histogram has this kind of effect on the result.
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>
> --
> 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

robert atwood

Re: Threshold is giving an incomplete range ?

Thanks, Wayne!

Sorry to 'rabbit on' a bit about the conceptual interpretation of thresholding, but it seemed like my point was not quite understood (by others)
I found it easier and more consistent to use macro to create the stack rather that attempt to reduce a huge stack in such a way that it would still show the behavior. I'm glad it worked to clarify the behaviour.

The new build seems to do what I think is correct for the non 'stack histogram' case -- however, it now seems that the interactive (red overlay) display does not accurately reflect what the threshold has done.

Example : Run the macro as before

Be sure to have 'slice 1' in focus
Select 'Adjust -> Threshold ' use 'Huang', do not tick 'dark background' and do not tick 'stack histogram'
Click 'auto'

Main background has value 64250
Outer blob is 15420
Inner blob is 10023 in slice 1

The threshold is calculated as 15339 by Huang method.
However , the outer blob is overlaid with red in Slices 1 , 8 , 9 and 10 , although its value is greater than 15339.

Selecting 'analyse , particles, show Outlines' results in only outlines of the inner blob, this reveals that only the inner blob is considered part of the thresholded area according to the internal calculation -- which should be correct for the Huang method on this data -- but the red overlay seems to show otherwise.

I suspect this has to do with an 8 bit representation used to determine the red overlay? The broad areas of numerically identical values are a harsh test I suppose ..

Thanks again,
Robert

-----Original Message-----
From: ImageJ Interest Group [mailto:[hidden email]] On Behalf Of Wayne Rasband
Sent: Wednesday, May 17, 2017 18:44
To: [hidden email]
Subject: Re: Threshold is giving an incomplete range ?

> On May 16, 2017, at 10:28 AM, Robert Atwood <[hidden email]> wrote:
>
> Here is an example:
>
> Macro to create an example stack

This bug is fixed in the latest ImageJ daily build (1.51o16), thanks to the very helpful example stack created by this macro.

-wayne

> __________________________________________________
>
> newImage("Untitled", "16-bit black", 512, 512, 10);
>
> for (i=1;i<=nSlices;i++){
> setSlice (i);
> setForegroundColor(250,250,250);
>
> run("Select All");
> run("Fill", "slice");
> setForegroundColor(60,60,60);
> makeOval(170, 190, 130, 140);
>
> run("Fill", "slice");
> setForegroundColor(40-i,40-i,40-i);
> makeOval(214, 243, 45, 44);
> run("Fill", "slice");
> }
> run ("Select None");
> setSlice(1);
> ________________________________________________
>
>
> Then select 'Adjust - Threshold - Auto (default, NOT dark background,
> NOT histogram stack) Then scroll to another slice .. Is this what you expect?
> I expect a threshold with the boundary calculated from slice 1 , dividing foreground from background. I don't expect the darker center of the blob to be part of the foreground.
>
> In developing the example I have found a further problem. If I include in the macro the command to autothrehsld -- the behaviour DOESN'T happen .. in this example the central dark blob is included in the red area.
>
> setAutoThreshold("Default");
>
> But if you then just open the 'adjust .. threshold' dialog box, while slice 5 is active ... the black central blob appears!
>
> Also using setAutoThreshold("Otsu"); yields even more unexpected behaviour ...
>
>
> I believe those of us who consider this to be a problem are using
>
> -- 3-d images
> -- Automatic thresholding
>
>
> 'threshold each image' is unacceptable because the threshold value is then different for each slice.
>
> Also the next step does not require 'apply' the threshold, and indeed doing this would make it more complicated to program, requiring storing the original to refer the analysis of grayscale back to , wheras running 'analyse particles' with the threshold active does pretty much what I want already.
>
> An alternative is using a different program than ImageJ for 3-d
> thresholding ... but ... there are so many good things about ImageJ
>
> 'stack histogram' is sometimes the right thing , but sometimes I am wanting to get the threshold that is calculated from the active slice and then apply to all slices.
>
>
> A method such as Otsu's original doi:10.1109/TSMC.1979.4310076 seeks to find a single number K that separates foreground from background. It does not seek to find a range in the middle of the grayscale. That would be the multi-thresholding case.
>
> I see that it is simply to do with the bottom of the selected range being determined by the active slice minimum. In my opinion (sorry Wayne) this is wrong for automatic threshold and it should be the -inf of the image's data type, or rathe,r simply all points with values less than K are in the red section, all greater than are in the white section -- with suitable handling of exactly equal points :-) . With respect to Gabriel, if people are seeking to automatically find a range in the middle of the total gray scale shouldn't they be using multi-threshold variants, rather than selecting what happens to be the minimum of the first slice in the stack? That is no longer 'foreground/background' separation.
>
> If they are interactively choosing the minimum for themselves to select a range within the total grayscale, it's a different case and nothing to do with my original problem .
> Colour images are also not part of my problem.
>
> Is it such a big deal to apply the ( less than K , greater than K ) criterion in the original data space (not the 8bit reduced dataset) -- even if the value of the threshold is calculated using the reduced data?
>
>
>
>
>
>
>
>
>
> -----Original Message-----
> From: ImageJ Interest Group [mailto:[hidden email]] On Behalf Of
> Gabriel Landini
> Sent: Thursday, May 11, 2017 12:06
> To: [hidden email]
> Subject: Re: VS: Threshold is giving an incomplete range ?
>
> I think that what you are seeing is a consequence of the re-binning of the 16 and 32 bit images into 8 bit histograms (that IJ does for thresholding).
> Your range is from -5.10 to 3.32, the thresholded range is then applied to all slices. So I would think that it is correct what you see and if another slice has a different range of values, then some values might not be covered by the range set earlier.
>
> Since you are thresholding a volume, I agree that it makes sense to use the "stack histogram" option in that case, and not use it when you want a given threshold *range* to be applied all slices.
> Note that there is no absolute max or minimum in 32bit images, just the re- binned range.
>
> Another option is to not rely on recording the autothreshold values
> and use a macro to specify exactly what range is required on the 32bit
> stack with setThreshold(min,max);
>
> Cheers
>
> Gabriel
>
> On Thursday, 11 May 2017 07:45:26 BST [hidden email] wrote:
>> Anyway, maybe the attached screenshot helps. In the top row there are
>> two positions in a 3D distance map that is also attached. There are
>> large values in slice 2 (left) and smaller values in slice 16 (right).
>> In the middle row there's a threshold window and threshold value is
>> determined according to slice 16. The intention to threshold the
>> middle part of the object, i.e. all values larger than -5.10. In the
>> bottom row there's result of pressing Apply button in the threshold
>> window. I've not calculated threshold for each slice separately as
>> this is a 3D object. Slice 16 (bottom right) is as expected but slice
>> 2 (bottom left) contains a hole in the middle of the object.
>>
>> Obviously Stack histogram checkbox solves the problem but it has its
>> drawbacks that I mentioned in my last mail. I've got my ways around
>> the problem but many people I know don't realize that not checking
>> Stack histogram has this kind of effect on the result.
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>
> --
> 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

Gabriel Landini

Re: Threshold is giving an incomplete range ?

Hi Robert,
The Huang threshold for the 16 bit version of the first slice on that stack is
actually 15420, not 15339. You can verify that using the Auto_Threshold plugin
in the link posted last time which processes 16bit images in their native
greyscale space (at the expense of a slower computation).

Wayne might be able to clarify this, but I think that the 15339 comes from the
binning of the image data into 8bit space, so the slider ends up set to the
nearest value and this varies slightly from slice to slice.

Cheers

Gabriel

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

robert atwood

Re: Threshold is giving an incomplete range ?

Thanks Gabriel!

That is interesting, and probably a better result of this data , I stand corrected as to whether the built-in is 'correct' result of Huang's method.

But it is sure incredibly slow and doesn't help with the observation that the red overlay does not match the reported value from the IJ builtin Huang method -- because there is no preview overlay!

But, it doesn't work suitable for my intended use , which contains the following stanza, allowing the user to 'improve' upon the autothreshold before applying binarization, because it doesn't even provide a preview overlay at all.

60 run("Threshold...");
61 title = "Wait for user to adjust threshold and convert to binary mask";
62 msg = "Please adjust threshold using ImageJ tool and convert to binary mask.\n After all done then click \"OK\".";
63 waitForUser(title, msg);
64 id4=getImageID();

There's a few other problems with it also...

I don't fundamentally have a problem with the result being altered from the precise value by 8bit reduction ... if it is consistent, but the problem now is the overlay doesn't match the actual result.

-----Original Message-----
From: ImageJ Interest Group [mailto:[hidden email]] On Behalf Of Gabriel Landini
Sent: Thursday, May 18, 2017 14:35
To: [hidden email]
Subject: Re: Threshold is giving an incomplete range ?

Hi Robert,
The Huang threshold for the 16 bit version of the first slice on that stack is actually 15420, not 15339. You can verify that using the Auto_Threshold plugin in the link posted last time which processes 16bit images in their native greyscale space (at the expense of a slower computation).

Wayne might be able to clarify this, but I think that the 15339 comes from the binning of the image data into 8bit space, so the slider ends up set to the nearest value and this varies slightly from slice to slice.

Cheers

Gabriel

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

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