color pixel for Strahler order

[catherine]

Hello,

I use Strahler order pluging to count order in branching object http://fiji.sc/Strahler_Analysis

The image is a skeleton image
I am searching how I could color pixels of the skeleton after he analysis, for each order (order 1 in yellow, 2 in red, 3 in green for example). Isearch and founded pixel colro counter, but I really don't know how to colorpixel with a macro.

Thanks a lot for your answers!
Cat

[Tiago Ferreira-2]

Hi Catherine,

On Mar 30, 2014, at 04:59, catherine <[hidden email]> wrote:
> I am searching how I could color pixels of the skeleton after he analysis,
> for each order (order 1 in yellow, 2 in red, 3 in green for example).
> Isearch and founded pixel colro counter, but I really don't know how to
> colorpixel with a macro.

It can be done with built-in commands. You could try the following:

1) Run Strahler Analysis in debug mode so that it generates the animation stack
2) Project that stack using the "Sum Slices" option (Image>Stacks>Z Project...)
3) Such projection will have the Strahler numbers rendered as multiples of 255
4) Apply your favorite Lookup table to the summed projection, e.g., Fire
5) If you want to add a calibration bar (Analyze>Tools>Calibration Bar), you can
   do one of the following:
     a) Divide the projection by 255 (Process>Math>Divide...) or
     b) Calibrate a non-32 bit version of the projection (Analyze>Calibrate...)
        using a linear function of slope 1/255    

In a macro this would be something like:

// <--- start of macro --->
// open an image
open("http://fiji.sc/images/b/b3/StrahlerAnimation.gif");
setThreshold(0, 10);
run("Convert to Mask");

// run Strahler Analysis in debug mode
setKeyDown("alt");
run("Strahler Analysis", "max.=100");

// frontmost image is now the animation stack.
nOrders = nSlices();
run("Z Project...", "projection=[Sum Slices]");
run("Fire");
run("Divide...", "value=255");
setMinAndMax(0, nOrders);
run("Calibration Bar...", " overlay");
// <--- end of macro --->

Is this used frequently? If yes, it could be added as an option to the plugin.

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

[Gabriel Landini]

On Sunday 30 Mar 2014 01:59:26 catherine wrote:
> I use Strahler order pluging to count order in branching object
> http://fiji.sc/Strahler_Analysis <http://fiji.sc/Strahler_Analysis>
>
> The image is a skeleton image
> <http://imagej.1557.x6.nabble.com/file/n5007132/86117_Th1.bmp>
> I am searching how I could color pixels of the skeleton after he analysis,
> for each order (order 1 in yellow, 2 in red, 3 in green for example).
> Isearch and founded pixel colro counter, but I really don't know how to
> colorpixel with a macro.

I am not sure that script is working correctly.
The number of branches of order 1 should be the same as the number of end
points at the start of the skeleton, or am I missing something obvious?

With a test image here I get:
order endp  branches junctions  
1 67 128 62
2 22 41 20
3 4 5 2
4 2 1 0

How is it possible to have 128 branches of order 1 with only 67 end points?

Cheers

Gabriel

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

[Tiago Ferreira-2]

Hi Gabriel,

On Apr 1, 2014, at 08:54, Gabriel Landini <[hidden email]> wrote:
> The number of branches of order 1 should be the same as the number of end
> points at the start of the skeleton, or am I missing something obvious?
>
> How is it possible to have 128 branches of order 1 with only 67 end points?

I'm definitely not an expert, but I think this has to do with our expectation of
what a branch is and how a branch is defined in a topographic skeleton, that
tries to be graph-theoretic representation of the arbor.

Looking at the snapshot Ignatio posted on the top of the documentation[1] page:
http://fiji.sc/images/b/be/Analyze_skeleton_09_13_2009.png

All the skeletons have more branches than tips (e.g, the largest has 9 end-points
and 15 branches). This is because branches are defined as all segments of slab
voxels (i.e., voxels with exactly 2 neighbors) flanked by either a end-point voxel
_or_ a junction voxel. So, the total number of branches in a skeletonized structure
would be the sum of segments of slab voxels connecting:
        1) End-point to End-point
        2) Junction to End-point
        3) Junction to Junction

This is at least, the way I see it, at least in in the context of AnalyzeSkeleton.
But hopefully someone more knowledgable will be able to discuss this better.

Would you like to have junction-to-junction segments subtracted from the
definition of "branch"?

All the real measurements in  Strahler Analysis[2] are done by AnalyzeSkeleton,
mainly using the "prune" option that was implemented in BoneJ[3].
If you suspect there is something wrong, we'd have to look at the code by
Ignacio Arganda-Carreras and Michael Doube. But in case I've missed something
obvious (I'm notorious for that), if you want to post your test image, I can
have a look at it and compare the results.

-tiago

[1] http://fiji.sc/AnalyzeSkeleton
[2] http://fiji.sc/Strahler_Analysis
[3] http://bonej.org/analyseskeleton
--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Gabriel Landini]

On Tuesday 01 Apr 2014 12:41:54 you wrote:
> Hi Gabriel,
>
> On Apr 1, 2014, at 08:54, Gabriel Landini <[hidden email]> wrote:
> > The number of branches of order 1 should be the same as the number of end
> > points at the start of the skeleton, or am I missing something obvious?
> >
> > How is it possible to have 128 branches of order 1 with only 67 end
> > points?

> Looking at the snapshot Ignatio posted on the top of the documentation[1]
> page: http://fiji.sc/images/b/be/Analyze_skeleton_09_13_2009.png
> All the skeletons have more branches than tips (e.g, the largest has 9
> end-points and 15 branches).

Hm... that is not right me thinks.

A "end point" is one that has only 1 connection in its 3x3 neighbourhood.

A skeletonized Y should have 3 end points, same as T.
K would have 4.

The order 1 branches (easiest to compute) would go from an end point to the
first junction pixel.

I noticed this because I started implementing a sequential pruning macro using
morphological operations and get different results that the bsh script, but I
can visualise the result with my macro and it seems to be correct but the
script does not show anything (so I can't say what it is really doing).

Cheers

Gabriel

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

[Tiago Ferreira-2]

On Apr 1, 2014, at 18:20, Gabriel Landini <[hidden email]> wrote:
> A skeletonized Y should have 3 end points, same as T. K would have 4.
>
> The order 1 branches (easiest to compute) would go from an end point to the
> first junction pixel.
Sure.

Gabriel, I thought the issue related to segments flanked by two junction pixels.
In the examples you describe such segments do not exist: All slab branches are
associated to one end-point and one junction point.
(BTW, as far as I can tell AnalyzeSkeleton_ (and thus the .bsh script) describe
such skeletons properly).

> I noticed this because I started implementing a sequential pruning macro using
> morphological operations and get different results that the bsh script
Nice. Can you point us to your macro?

> but the script does not show anything (so I can't say what it is really doing).
It does. You need to turn on ImageJ's debug mode (or press down Alt, if you run
it from an ImageJ menu) and it will output a stack documenting each iteration.

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

[Gabriel Landini]

On Tuesday 01 Apr 2014 23:46:58 Tiago Ferreira wrote:
> Gabriel, I thought the issue related to segments flanked by two junction
> pixels. In the examples you describe such segments do not exist: All slab
> branches are associated to one end-point and one junction point.
> (BTW, as far as I can tell AnalyzeSkeleton_ (and thus the .bsh script)
> describe such skeletons properly).

Thanks for the follow up. Maybe we are talking different things
Yes there are more "branches" than "endpoints" in most skeletons, but I am not
talking about "any branches", but "order 1 branches" only.

Isn't what the table shows? Those would disappear after the first pass of
hierarchical pruning.

The example of a branch extending between 2 junction pixels can never be
"order 1 branch". It can only be the max (order of the previous-step branches)
if not all equal orders or the  (order of previous-step branches + 1) if all
the same order. That is the Strahler algorithm.

Perhaps the analysis plugin does things differently, but that count does not
match the labelled Strahler pictures I have seen. But as I said earlier, I am
not sure what is exactly the plugin doing.

Thanks for any further clarification.
 
Cheers

Gabriel

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

[Tiago Ferreira-2]

Hi Gabriel,

On Apr 2, 2014, at 04:39, Gabriel Landini <[hidden email]> wrote:
> Thanks for the follow up. Maybe we are talking different things
Hopefully we are :)


> Yes there are more "branches" than "endpoints" in most skeletons, but I am not
> talking about "any branches", but "order 1 branches" only.
>
> Isn't what the table shows? Those would disappear after the first pass of
> hierarchical pruning.
The table simply reports the properties of the remaining skeleton upon a pruning cycle.
Thus, "order 1 branches" are listed under the "# End-points" column in row 1, "order 2"
in row 2, etc...
As I've mentioned, the "# Branches" column just reports the count of _all_ slab segments,
and its logged (together with "# Junctions") just so that users can monitor the progressive
pruning. Is this what is causing misunderstandings?


> But as I said earlier, I am not sure what is exactly the plugin doing.
Did you look at the code annotations[1] and the script page[2]?
Running it with ImageJ in debug mode was not useful?

The relevant code that is called is the pruneEndBranches() method by Michael Doube:
https://github.com/mdoube/BoneJ/blob/master/src/org/doube/skeleton/AnalyzeSkeleton.java#L472

I'll try to describe what the script does:

1) Skeletonizes the arbor using Ignacio's library[3][4]
2) Calls the pruneEndBranches() method[5] to eliminate terminal branches
3) Keeps track of the properties of the remaining skeleton using AnalyzeSkeleton_[6][7]
4) Iterates previous steps until no junction pixels are detected, or until the "max n. of
   interactions" specified in the dialog prompt is reached

5) For each iteration, the AnalyzeSkeleton_ properties[7][8] of the pruned skeleton are
   logged to the "Strahler table"
6) If debug mode is active, each pruned skeleton is added to a new slice of an ImageStack


> but that count does not match the labelled Strahler pictures I have seen.
Which images? The toy arbor in [2]? You will have to be more specific, as it is very hard
for me to materialize it into a concrete criticism that I can address. Perhaps we should
be working on a common image? (e.g., a region of the ddaC sample image in Fiji?) and a
reproducible example?

-tiago

Links:
[1] https://github.com/tferr/Scripts/blob/master/Morphometry/Strahler_Analysis.bsh
[2] http://fiji.sc/Strahler_Analysis
[3] https://github.com/fiji/fiji/blob/master/src-plugins/Skeletonize3D_/src/main/java/Skeletonize3D_/Skeletonize3D_.java
[4] http://fiji.sc/Skeletonize3D
[5] https://github.com/fiji/fiji/blob/master/src-plugins/AnalyzeSkeleton_/src/main/java/skeleton_analysis/AnalyzeSkeleton_.java#L605
[6] https://github.com/fiji/fiji/blob/master/src-plugins/AnalyzeSkeleton_/src/main/java/skeleton_analysis/AnalyzeSkeleton_.java
[7] http://fiji.sc/AnalyzeSkeleton
[8] http://fiji.sc/javadoc/skeleton_analysis/AnalyzeSkeleton_.html

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

[Gabriel Landini]

On Wednesday 02 Apr 2014 11:44:44 Tiago Ferreira wrote:
> The table simply reports the properties of the remaining skeleton upon a
> pruning cycle. Thus, "order 1 branches" are listed under the "# End-points"
> column in row 1, "order 2" in row 2, etc...

OK I will take another look at this.

> As I've mentioned, the "# Branches" column just reports the count of _all_
> slab segments, and its logged (together with "# Junctions") just so that
> users can monitor the progressive pruning. Is this what is causing
> misunderstandings?

Perhaps. I was expecting to get a count of the coloured branches by order but
the bsh file now, I realise that seems to count all segments of a branch as a
different one when the remain with the same order. Perhaps it is the names of
the columns that I could not relate to.

> Did you look at the code annotations[1] and the script page[2]?

No I did not, I am reinventing the wheel, because I can. :-)
Now seriously, I think that this problem could be resolved by a different
means that does not require the skeleton encoded as a graph.
Will post it if it works.

> is very hard for me to materialize it into a concrete criticism that I can
> address. Perhaps we should be working on a common image? (e.g., a region of
> the ddaC sample image in Fiji?) and a reproducible example?

Looking again
http://en.wikipedia.org/wiki/Strahler_number
I realised that they are shown as sub-branches. The confusing part is that the
table counts all branches, not the order k ones, which appear as "end points".
Will have another look at this. Thanks for the follow up.

Gabriel

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

[Tiago Ferreira-2]

On Apr 2, 2014, at 12:09, Gabriel Landini <[hidden email]> wrote:
> Now seriously, I think that this problem could be resolved by a different
> means that does not require the skeleton encoded as a graph.
> Will post it if it works.
That would be great. Do let us know how it goes, and do let me know if I can
help.

Again, the .bsh script is not really sophisticated. It was born out of an
immediate need, so a different approach is more than welcome.

What the iterative pruning fails at is that it eliminates all terminal branches
indiscriminately, and thus it eliminates the root of the arbor upon the 1st pass.
This can be problematic. E.g. Take the example of a highly ramified neuronal arbor
shaped like a hand-held fan:
In such a structure, all processes branch out from a common focus (e.g., the cell
body).  For biological meaningful Strahler orders, what would make sense would be
to always protect from elimination the endpoint at the cell body, so that orders
are really assessed in a centripetal manner, towards the soma.

At the time, I thought about prompting the user for an area ROI including the
'root' end-point to be protected, but it soon became clunky, and so, I've decided
to postpone it (so do let me know your suggestions and thoughts on this).


> Looking again
> http://en.wikipedia.org/wiki/Strahler_number
> I realised that they are shown as sub-branches. The confusing part is that the
> table counts all branches, not the order k ones, which appear as "end points".
>
> Perhaps it is the names of the columns that I could not relate to.
Oh, I see now how they can be misleading. I'll rename them to make it more clear,
and will try to output color-coded segments in a better way.


> Thanks for the follow up.
No thank you for looking into this.


-tiago

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

[catherine]

Hy everybody,



Well, I used "end points" and it seems to give me the right number for each "branch". I hope it works definitely, because I analyzed 500 images and included the results in my dataset! I verified for several images and it seemed to work. I also noticed that "banches" adn "junctions" were not suitable for any analysis.

I agree with the discussion about definitions. I just wrote something about that using graph theory, adapted to plants.
Thanks again.

[catherine]

Dear Tiago,

Your macro works perfetly, and it is usefull for me. I do not know exactly how to manage with code, I only write small macros, so I do not think I am able to include it my self in the code as an option as you told me.
Catherine

[Tiago Ferreira-2]

Dear Gabriel, Catherine:

I've just updated Strahler_Analysis.bsh as a followup of our discussion:

Major changes are:
  - It does not modify the analyzed image (it works on a copy)
  - Column headers have been renamed (as per Gabriel's comments)
  - It no longer reports slab segments (as per Gabriel's comments)
  - Outputs an image colored by classification (as per Catherine's suggestion)
  - Reports closed loops in the skeleton
  - Calculates bifurcation ratios
  - It no longer overestimates disconnected branches
  - It ignores segments of length zero (isolated pixels)

The last two points should make it more accurate when iterating through complex
structures (e.g., the ddaC sample image in Fiji).

The documentation page[1] has also been updated. Hopefully everything is more
clear now. Do let me know if you find any issues.

-tiago

PS: I'll likely create an update site[2] for it and remaining scripts on GitHub[3]

[1] http://fiji.sc/Strahler_Analysis
[2] http://fiji.sc/List_of_update_sites
[3] https://github.com/tferr/Scripts#scripts

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