Analyze particle & Flood fill

[Corentin Cras-Méneur-2]

        Hi All,


    My apologies if the question have been already raised on the list,
but I search for a while and did not find any mention of it.
    I've been using the Analyze Particle function to measure tissue
areas on calibrated TIFF images and I noticed two things that threw
me off for quite a while:

- the Flood Fill option seems to work the opposite way as what I
would have anticipated (or I simply did not understand it): when the
option is checked, the measurements are performed *without* filling
the inner-spaces and when the Flood Fill option is unchecked, the
measurements include these areas.

- Setting the maximal size appears to be critical. If I don't set
anything, the largest elements on the thresholded image will simply
be ignored (as can be visualized with the masks). If I set a value
that's too big (I would say, larger than the entire area in the
image), then I have the same problem. I have to set it to a value
larger than these objects (obviously) but also smaller than the
surface of the entire image.
I would have thought that not setting the max value would have been OK.

Are these known issues? Is there something I don't understand??
Thanks,


                Corentin

[Bilal Ahmed-2]

Hi all,

Is there a way to execute Macros via Java (ImageJ API) in a headless server
environment?

Thanks,
Bilal

[Gabriel Landini]

On Friday 09 December 2005 16:56, Corentin Cras-Méneur wrote:
> - the Flood Fill option seems to work the opposite way as what I
> would have anticipated

I think that you are right.
I just also noticed that this is so when the "Limit to Threshold" is NOT
checked in the Set Measurements.

If it is checked, then it gives just the thresholded area (which is fine). But
what is a bit confusing is that the "Limit to Threshold" overrides the Flood
Fill one.

I must say that having the 2 settings in different dialogs is not ideal  
(specially when one overrides the other) but since settings in Set
Measurements are shared between Measure (which has no dialog) and Analyze
Particles (which does), I wonder if there is a better way to do it.

Cheers,

Gabriel

[Gabriel Landini]

On Friday 09 December 2005 22:26, Philippe Grosjean wrote:
> Now, the flood fill algorithm introduced recently (version 1.32 or 1.33
> if my memory is correct) fills the *inside* of the blobs before
> analyzing them, but excluding holes. So, once you use the flood fill,
> ImageJ becomes aware of holes inside your blobs.

From the IJ News page:
"v1.34l, 15 April 2005
 The "Flood Fill" particle analyzer option enables measurement of nested
particles and causes interior holes to be ignored."

> I tend to agree with you: the algorithm used is not important here. The
> option should better be spelled '[] Fill holes' and it should use the
> flood fill algorithm if you select that option.

I guess that the above means "ignore the holes area as part of the particle"
rather than filling them (and then count particles within particles). So the
flood fill is to extract the connected thresholded area but not holes. (the
particle is flood filled, not the holes).

But even if this option is "off" (so the holes areas *are* counted as part of
the particle area), the "Limit to threshold" seems to override it when "on"
and counts only the thresholded area (without holes).
Can you see the possibility of confusion? (If I am understanding this wrong, I
would be happy to be corrected).

As I see it, Limit to Threshold is useful for the Measure command, but
confusing for the particle analysis.

On Friday 09 December 2005 23:16, Corentin Cras-Méneur wrote:
> In our case, we hardly ever want to measure the "holes'.

That's great, but the idea is to make it flexible enough so it can be used in
both ways.

Cheers,

Gabriel

[Philippe Grosjean]

Gabriel Landini wrote:

> On Friday 09 December 2005 22:26, Philippe Grosjean wrote:
>
>>Now, the flood fill algorithm introduced recently (version 1.32 or 1.33
>>if my memory is correct) fills the *inside* of the blobs before
>>analyzing them, but excluding holes. So, once you use the flood fill,
>>ImageJ becomes aware of holes inside your blobs.
>
>
>>From the IJ News page:
> "v1.34l, 15 April 2005
>  The "Flood Fill" particle analyzer option enables measurement of nested
> particles and causes interior holes to be ignored."
>
>
>>I tend to agree with you: the algorithm used is not important here. The
>>option should better be spelled '[] Fill holes' and it should use the
>>flood fill algorithm if you select that option.
>
>
> I guess that the above means "ignore the holes area as part of the particle"
> rather than filling them (and then count particles within particles). So the
> flood fill is to extract the connected thresholded area but not holes. (the
> particle is flood filled, not the holes).

Yes, wasn't it what I said: flood fill eliminates holes in the blobs.

> But even if this option is "off" (so the holes areas *are* counted as part of
> the particle area), the "Limit to threshold" seems to override it when "on"
> and counts only the thresholded area (without holes).
> Can you see the possibility of confusion? (If I am understanding this wrong, I
> would be happy to be corrected).

Hummm, I just double-check this (I use to check myself, and not to trust
the documentation too much, and I remember I did not care about "Limit
to threshold" in particle analysis, but don't remember why). Here is the
result on a particle with a hole in it:
                 Area   Mean  Skew    Kurt
FF - LTT        6569   209   -0.579  -0.122
FF - no LTT     6569   209   -0.579  -0.122
no FF - LTT     6815   210   -0.471  -0.155
no FF - no LTT  6815   210   -0.471  -0.155

This is when I redirect to a 8bit grayscale picture, but the result is
the same without redirection (just Skew & Kurt is not usable in that case).

So, this confirm to me that LTT (Limit to threshold) has no effect in
particle analyzer. So, there is no clash between "Flood fill" and "Limit
to threshold": they are used in different contexts.

Best,

Philippe Grosjean


> As I see it, Limit to Threshold is useful for the Measure command, but
> confusing for the particle analysis.

> On Friday 09 December 2005 23:16, Corentin Cras-Méneur wrote:
>
>>In our case, we hardly ever want to measure the "holes'.
>
>
> That's great, but the idea is to make it flexible enough so it can be used in
> both ways.
>
> Cheers,
>
> Gabriel
>
>

[Gabriel Landini]

Hi Pilippe,

On Saturday 10 December 2005 09:25, Philippe Grosjean wrote:

> Yes, wasn't it what I said: flood fill eliminates holes in the blobs.

The problem is that the language to describe the procedure is unclear (at
least to me).
You suggested to change the option to "Fill holes":

>option should better be spelled '[] Fill holes'

"Eliminate" may mean that they are "not counted as set" but (in binary images)  
that "they are filled with the foreground colour". If holes usually contain
"not set", in a binary image one eliminates the "not set" by doing
not(not(set))==set. (i.e. inverting the "not-set").
"Flood fill" is I guess flood filling the particle and probably means that
holes are not counted as area.
But if you run the Binary>Fill holes, then they are filled with the foreground
colour and they become part of the particle. So it is still a confusing
terminology.

If one calculates the area of a slice of cheese before and after filling the
holes, I would tend to think that the one without holes (i.e. "filled") has a
larger area (or, if the holes are there, there is less cheese!). :-)

> Hummm, I just double-check this (I use to check myself, and not to trust
> the documentation too much, and I remember I did not care about "Limit
> to threshold" in particle analysis, but don't remember why). Here is the
> result on a particle with a hole in it:
>                  Area   Mean  Skew    Kurt
> FF - LTT        6569   209   -0.579  -0.122
> FF - no LTT     6569   209   -0.579  -0.122
> no FF - LTT     6815   210   -0.471  -0.155
> no FF - no LTT  6815   210   -0.471  -0.155

This is odd. I double checked too and my results do not agree with yours:

//Test_1 "Limit" and "not Flooding"
run("Colors...", "foreground=white background=black selection=yellow");
run("Options...", "iterations=1 black count=1");
newImage("test", "8-bit Black", 200, 200, 1);
makeOval(40, 28, 139, 139);
run("Draw");
run("Select None");
run("Dilate");
setAutoThreshold();
run("Set Measurements...", "area limit redirect=None decimal=3");
run("Analyze Particles...", "size=1-999999 circularity=0.00-1.00 show=Nothing
display clear record");
//--------------------------
        Area XStart Ystart
1 1668 100 27

//--------------------------

//Test_2 "not Limit" and "not Flooding"
run("Colors...", "foreground=white background=black selection=yellow");
run("Options...", "iterations=1 black count=1");
newImage("test", "8-bit Black", 200, 200, 1);
makeOval(40, 28, 139, 139);
run("Draw");
run("Select None");
run("Dilate");
setAutoThreshold();
run("Set Measurements...", "area redirect=None decimal=3");
run("Analyze Particles...", "size=1-999999 circularity=0.00-1.00 show=Nothing
display clear record");
//--------------------------
        Area XStart Ystart
1 16036 100 27

//--------------------------
// Test_3 "Limit" and "Flooding"
run("Colors...", "foreground=white background=black selection=yellow");
run("Options...", "iterations=1 black count=1");
newImage("test", "8-bit Black", 200, 200, 1);
makeOval(40, 28, 139, 139);
run("Draw");
run("Select None");
run("Dilate");
setAutoThreshold();
run("Set Measurements...", "area limit redirect=None decimal=3");
run("Analyze Particles...", "size=1-999999 circularity=0.00-1.00 flood
show=Nothing display clear record");
//--------------------------
        Area XStart Ystart
1 1668 100 27

//--------------------------
// Test_4 "Not Limit" and "Flooding"
run("Colors...", "foreground=white background=black selection=yellow");
run("Options...", "iterations=1 black count=1");
newImage("test", "8-bit Black", 200, 200, 1);
makeOval(40, 28, 139, 139);
run("Draw");
run("Select None");
run("Dilate");
setAutoThreshold();
run("Set Measurements...", "area  redirect=None decimal=3");
run("Analyze Particles...", "size=1-999999 circularity=0.00-1.00 flood
show=Nothing display clear record");
//--------------------------
        Area XStart Ystart
1 1668 100 27
//--------------------------


Three of the tests return the same result, unlike the results you posted.

In the case of "Limit, not Flooding", the user may be thinking that by "not
flooding" is counting the area of the holes as part of the particle, but it
is not so. The "Limit" option seems to take precedence over the setting of
the "Flood" option.
In the examples above, it seems that if "Limit" is on, then "Flooding" setting
does not do anything.
That is why in the results above Test_1 gives the same result as Test_3 &
Test_4.

Would it be sensible to relegate "Limit" to just "Measure" and have no
influence over "Flooding"?

> This is when I redirect to a 8bit grayscale picture, but the result is
> the same without redirection (just Skew & Kurt is not usable in that case).

Maybe this is the source of problems.
The above is without redirecting & there is only a single binary image.

> So, this confirm to me that LTT (Limit to threshold) has no effect in
> particle analyzer. So, there is no clash between "Flood fill" and "Limit
> to threshold": they are used in different contexts.

And the above confirms to me that there is an effect :-)

Just for the record, I am using the latest 1.35j under suse linux with Java
1.5.0_06.

If it is not too much trouble could you run those test with your set up and
report what you get?

Regards,

Gabriel

[Philippe Grosjean]

Gabriel Landini wrote:

> [...]
>
>>Hummm, I just double-check this (I use to check myself, and not to trust
>>the documentation too much, and I remember I did not care about "Limit
>>to threshold" in particle analysis, but don't remember why). Here is the
>>result on a particle with a hole in it:
>>                 Area   Mean  Skew    Kurt
>>FF - LTT        6569   209   -0.579  -0.122
>>FF - no LTT     6569   209   -0.579  -0.122
>>no FF - LTT     6815   210   -0.471  -0.155
>>no FF - no LTT  6815   210   -0.471  -0.155
>
>
> This is odd. I double checked too and my results do not agree with yours:
>
> //Test_1 "Limit" and "not Flooding"
> run("Colors...", "foreground=white background=black selection=yellow");
> run("Options...", "iterations=1 black count=1");
> newImage("test", "8-bit Black", 200, 200, 1);
> makeOval(40, 28, 139, 139);
> run("Draw");
> run("Select None");
> run("Dilate");
> setAutoThreshold();
> run("Set Measurements...", "area limit redirect=None decimal=3");
> run("Analyze Particles...", "size=1-999999 circularity=0.00-1.00 show=Nothing
> display clear record");
> //--------------------------
> Area XStart Ystart
> 1 1668 100 27
>
> //--------------------------

Yes, but:
//Test_1b "Limit" and "not Flooding" with manual thresholding
run("Colors...", "foreground=white background=black selection=yellow");
run("Options...", "iterations=1 black count=1");
newImage("test", "8-bit Black", 200, 200, 1);
makeOval(40, 28, 139, 139);
run("Draw");
run("Select None");
run("Dilate");
setThreshold(128, 255);
run("Threshold", "thresholded remaining black");
run("Set Measurements...", "area limit redirect=None decimal=3");
run("Analyze Particles...", "size=1-999999 circularity=0.00-1.00
show=Nothing display clear record");
//--------------------------
        Area XStart Ystart
1 16036 100 27

//--------------------------

I am completelly lost at this point! Why is autothreshold taken into
account differently than a manual threshold? The thresholded area is the
same, isn't it?

> //Test_2 "not Limit" and "not Flooding"
> run("Colors...", "foreground=white background=black selection=yellow");
> run("Options...", "iterations=1 black count=1");
> newImage("test", "8-bit Black", 200, 200, 1);
> makeOval(40, 28, 139, 139);
> run("Draw");
> run("Select None");
> run("Dilate");
> setAutoThreshold();
> run("Set Measurements...", "area redirect=None decimal=3");
> run("Analyze Particles...", "size=1-999999 circularity=0.00-1.00 show=Nothing
> display clear record");
> //--------------------------
> Area XStart Ystart
> 1 16036 100 27
>
> //--------------------------
> // Test_3 "Limit" and "Flooding"
> run("Colors...", "foreground=white background=black selection=yellow");
> run("Options...", "iterations=1 black count=1");
> newImage("test", "8-bit Black", 200, 200, 1);
> makeOval(40, 28, 139, 139);
> run("Draw");
> run("Select None");
> run("Dilate");
> setAutoThreshold();
> run("Set Measurements...", "area limit redirect=None decimal=3");
> run("Analyze Particles...", "size=1-999999 circularity=0.00-1.00 flood
> show=Nothing display clear record");
> //--------------------------
> Area XStart Ystart
> 1 1668 100 27
>
> //--------------------------
> // Test_4 "Not Limit" and "Flooding"
> run("Colors...", "foreground=white background=black selection=yellow");
> run("Options...", "iterations=1 black count=1");
> newImage("test", "8-bit Black", 200, 200, 1);
> makeOval(40, 28, 139, 139);
> run("Draw");
> run("Select None");
> run("Dilate");
> setAutoThreshold();
> run("Set Measurements...", "area  redirect=None decimal=3");
> run("Analyze Particles...", "size=1-999999 circularity=0.00-1.00 flood
> show=Nothing display clear record");
> //--------------------------
> Area XStart Ystart
> 1 1668 100 27
> //--------------------------
>
>
> Three of the tests return the same result, unlike the results you posted.
>
> In the case of "Limit, not Flooding", the user may be thinking that by "not
> flooding" is counting the area of the holes as part of the particle, but it
> is not so. The "Limit" option seems to take precedence over the setting of
> the "Flood" option.
> In the examples above, it seems that if "Limit" is on, then "Flooding" setting
> does not do anything.
> That is why in the results above Test_1 gives the same result as Test_3 &
> Test_4.
>
> Would it be sensible to relegate "Limit" to just "Measure" and have no
> influence over "Flooding"?
>
>
>>This is when I redirect to a 8bit grayscale picture, but the result is
>>the same without redirection (just Skew & Kurt is not usable in that case).
>
>
> Maybe this is the source of problems.
> The above is without redirecting & there is only a single binary image.
>
>
>>So, this confirm to me that LTT (Limit to threshold) has no effect in
>>particle analyzer. So, there is no clash between "Flood fill" and "Limit
>>to threshold": they are used in different contexts.
>
>
> And the above confirms to me that there is an effect :-)
>
> Just for the record, I am using the latest 1.35j under suse linux with Java
> 1.5.0_06.
>
> If it is not too much trouble could you run those test with your set up and
> report what you get?
>
> Regards,
>
> Gabriel
>
>

[Gabriel Landini]

On Saturday 10 December 2005 13:32, Philippe Grosjean wrote:

> Yes, but:
> //Test_1b "Limit" and "not Flooding" with manual thresholding
> run("Colors...", "foreground=white background=black selection=yellow");
> run("Options...", "iterations=1 black count=1");
> newImage("test", "8-bit Black", 200, 200, 1);
> makeOval(40, 28, 139, 139);
> run("Draw");
> run("Select None");
> run("Dilate");
> setThreshold(128, 255);
> run("Threshold", "thresholded remaining black");
> run("Set Measurements...", "area limit redirect=None decimal=3");
> run("Analyze Particles...", "size=1-999999 circularity=0.00-1.00
> show=Nothing display clear record");
> //--------------------------
> Area XStart Ystart
> 1 16036 100 27
> //--------------------------

Hi Philippe,

There is some error in the macro above. Note that the macro is set to use
white particles and you are thresholding the image to remain "black":

run("Threshold", "thresholded remaining black");

The line above is not needed because the threshold is set between 128 and 255,
but the "object" after thresholding is black (i.e. 0).
Note that after running the line above, the threshold is set to (0,0) (if
black is selected, 255,255 if it is not selected) and the macro finds luckily
the particle.

With the macro you sent I still get:
  Area XStart Ystart
1 1668 100 27


I think the macro should include:
setThreshold(128, 255);
and the next line ignored.
The particle analysis does not need a binarised image, but just a threshold
set.

With the corrected macro below I also get:
  Area XStart Ystart
1 1668 100 27

which is still not the expected result anyway.

Here is the macro I think we should be using:
//Test_1c "Limit" and "not Flooding" with manual thresholding
run("Colors...", "foreground=white background=black selection=yellow");
run("Options...", "iterations=1 black count=1");
newImage("test", "8-bit Black", 200, 200, 1);
makeOval(40, 28, 139, 139);
run("Draw");
run("Select None");
run("Dilate");
setThreshold(128, 255);
run("Set Measurements...", "area limit redirect=None decimal=3");
run("Analyze Particles...", "size=1-999999 circularity=0.00-1.00 show=Nothing
display clear record");
// -------------------

Can you run this corrected macro above and report the result (and post which
IJ version and platform. If we have different results, then there is
something else playing up)?
Thanks.

Regards,

Gabriel

[Philippe Grosjean]

Gabriel Landini wrote:

> Hi Philippe,
>
> There is some error in the macro above. Note that the macro is set to use
> white particles and you are thresholding the image to remain "black":
>
> run("Threshold", "thresholded remaining black");
>
> The line above is not needed because the threshold is set between 128 and 255,
> but the "object" after thresholding is black (i.e. 0).
> Note that after running the line above, the threshold is set to (0,0) (if
> black is selected, 255,255 if it is not selected) and the macro finds luckily
> the particle.

OK, now I got it! Indeed, what I do is to binarize my image and then
analyze particles on the binary mask, possibly using another image as
redirection. Doing so, I never use the threshold functionnality, since
it is reset after binarisation. That is why I believe that 'Limit to
threshold' is not working in my particle analyzer. Thanks for the
explanation!

Now, I also understand what you mean with the conflict between 'Limit to
threshold' and 'Flood fill'. I totally agree that this is misleading.
Could we propose changes to ImageJ dialog boxes and/or documentation?

A logical approach would be to collect together the two options in the
same dialog box, and to rename 'Flood Fill' into 'Exclude holes & detect
nested' or something similar. Indeed, after thinking about it carefully,
there is no reasons that 'Exclude on edges' and 'Flood fill' (or its
renamed equivalent) are in the 'Analyze particles' dialog box (other
than because they do not apply to other measurement methods). They
really are measurement options. They should be placed into the 'Set
measurements' dialog box close to 'Limit to threshold'...

> With the macro you sent I still get:
>   Area XStart Ystart
> 1 1668 100 27
>
>
> I think the macro should include:
> setThreshold(128, 255);
> and the next line ignored.
> The particle analysis does not need a binarised image, but just a threshold
> set.
>
> With the corrected macro below I also get:
>   Area XStart Ystart
> 1 1668 100 27
>
> which is still not the expected result anyway.
>
> Here is the macro I think we should be using:
> //Test_1c "Limit" and "not Flooding" with manual thresholding
> run("Colors...", "foreground=white background=black selection=yellow");
> run("Options...", "iterations=1 black count=1");
> newImage("test", "8-bit Black", 200, 200, 1);
> makeOval(40, 28, 139, 139);
> run("Draw");
> run("Select None");
> run("Dilate");
> setThreshold(128, 255);
> run("Set Measurements...", "area limit redirect=None decimal=3");
> run("Analyze Particles...", "size=1-999999 circularity=0.00-1.00 show=Nothing
> display clear record");
> // -------------------
>
> Can you run this corrected macro above and report the result (and post which
> IJ version and platform. If we have different results, then there is
> something else playing up)?
> Thanks.
>
> Regards,
>
> Gabriel

Yes, it works like that (ImageJ 1.35b, Java 1.5.0_03 on Win XP sp2).
best,

Philippe

[Gabriel Landini]

On Saturday 10 December 2005 16:28, Philippe Grosjean wrote:
> OK, now I got it

Ok. :-)

> Now, I also understand what you mean with the conflict between 'Limit to
> threshold' and 'Flood fill'. I totally agree that this is misleading.
>
> A logical approach would be to collect together the two options in the
> same dialog box, and to rename 'Flood Fill' into 'Exclude holes & detect
> nested' or something similar.

Yes, something along those lines. Let's wait for Wayne's comments next week.
Thanks for the testing.
Cheers,

Gabriel

[Corentin Cras-Méneur-2]

À 23:58 +0000 le 09/12/05, Gabriel Landini a écrit:
>
>On Friday 09 December 2005 23:16, Corentin Cras-Méneur wrote:
>>  In our case, we hardly ever want to measure the "holes'.
>
>That's great, but the idea is to make it flexible enough so it can be used in
>both ways.

Sure!!! I was just thinking about what the default option should be.

Corentin

[Wayne Rasband]

> > Now, I also understand what you mean with the conflict between
> > 'Limit to threshold' and 'Flood fill'. I totally agree that this is
> misleading.
> >
> > A logical approach would be to collect together the two options
> > in the same dialog box, and to rename 'Flood Fill' into 'Exclude
> > holes & detect nested' or something similar.
>
> Yes, something along those lines. Let's wait for Wayne's comments
> next week. Thanks for the testing.

How about replacing the "Flood Fill" option with "Include Holes"? The
particle analyzer would do flood filling unless "Include Holes" was
checked. The default behavior would be to do flood filling, to exclude
holes, and to detect nested particles.

-wayne

[Corentin Cras-Méneur-2]

À 11:15 -0500 le 13/12/05, Wayne Rasband a écrit:
>How about replacing the "Flood Fill" option with
>"Include Holes"? The particle analyzer would do
>flood filling unless "Include Holes" was
>checked. The default behavior would be to do
>flood filling, to exclude holes, and to detect
>nested particles.

It sounds great to me!


        Corentin

[Philippe Grosjean]

Wayne Rasband wrote:

>> > Now, I also understand what you mean with the conflict between
>> > 'Limit to threshold' and 'Flood fill'. I totally agree that this is
>> misleading.
>> >
>> > A logical approach would be to collect together the two options
>> > in the same dialog box, and to rename 'Flood Fill' into 'Exclude
>> > holes & detect nested' or something similar.
>>
>> Yes, something along those lines. Let's wait for Wayne's comments
>> next week. Thanks for the testing.
>
>
> How about replacing the "Flood Fill" option with "Include Holes"? The
> particle analyzer would do flood filling unless "Include Holes" was
> checked. The default behavior would be to do flood filling, to exclude
> holes, and to detect nested particles.
>
> -wayne

Sounds good to me, but what about the "conflict" between 'Limit to
threshold' and 'Include holes' in different dialog boxes?
Best,

Philippe Grosjean

[Gabriel Landini]

On Tuesday 13 December 2005 16:15, Wayne Rasband wrote:
> How about replacing the "Flood Fill" option with "Include Holes"?

Hi Wayne,
Yes, that is fine.
The problem to resolve next is what to do with the "Limit to threshold".
Can the "Include holes" overrule the "Limit" option? If not, then people will
use it and still not analyse the holes if "Limit" is on.
Or can the "Limit to threshold" be moved to a "Measure" option only?

Cheers,

Gabriel