Skeleton graphs

[scenerygraphics]

Skeleton graphs

[rimadoma]

We have quite a bit of research results riding on the old school Skeletonize3D_ and AnalyzeSkeleton_ so improvements on that stuff would be very welcome! @alessandrofelder, what do you think? We should check out the thinning ops @kephale created!

[imagejan]

See imagej/imagej-ops#63 (as this should go to imagej-ops, no?)

[kephale]

@imagejan it probably should go in imagej-ops but I believe that we do not have a graph data structure in ops yet. I got a little anxious about adding data structures to imagej-ops after DefaultMesh was added with some data structure dependencies that are now leading to big performance penalties in SciView.

Note that thinning has been merged and closed: imagej/imagej-ops#317

[alessandrofelder]

@kephale @rimadoma I agree that we do not need "the idiosyncrasies of the kind of graph AnalyzeSkeleton_ produces, e.g. storing the coordinates of all the voxels of a "junction" i.e. node.", but I can see that having access to the original skeletonization voxels may have some advantages for improving our high-level bone-biology-oriented command: for example, approximating a trabecula as a straight line as we're doing it now is probably too simplistic, so in the future, we might want to measure angles along the direction of the original structure (as given by the first 3 or so pixels, as done in the TriplePointAngle command) and not the graph structure. Would it be easy to keep this route open when we switch to a new graph library?

[kephale]

There have been some recent discussions about this w.r.t. https://jgrapht.org/

[alessandrofelder]

Interesting stuff! I agree that improvements would be welcome - in particular, it would avoid us using the Legacy code of AnalyzeSkeleton, and possibly see how different the results of our command are if we use different thinning algos?

[rimadoma]

@alessandrofelder Exactly! The missing piece here is creating a graph from a thinned image to be able to analyze the geometry of the skeleton (e.g. trabecular angles). Our tools would also need some work, because they're so heavily dependent on AnalyzeSkeleton_ etc. Maybe we shouldn't worry about migrating that stuff to sc.fiji.AnalyzeSkeleton_ until we check how we could benefit from this modern stuff? I wonder what @iarganda thinks...

[rimadoma]

@kephale At least we don't really have need for the idiosyncrasies of the kind of graph AnalyzeSkeleton_ produces, e.g. storing the coordinates of all the voxels of a "junction" i.e. node. Depending on whether that stuff would be generally useful, we could use an existing graph library, but we should hear @iarganda on this.

[kephale]

Sure, the graph-based skeletonization stuff that I wrote uses a Clojure library, so I'm expecting to have to port the code anyway.

[ctrueden]

And @tferr may have an opinion here as well, no?

[kephale]

It is worth noting that @tinevez and @tpietzsch could care once the discussion starts to narrow down on a specific graph library.

[iarganda]

Hello @rimadoma and everybody else!
Creating a simple graph containing all the voxel information of the skeleton was really useful for me but I can see how the specific representation of junctions could be a problem to transfer that graph to a more general library. What do you guys have in mind to use from such a library?

[kephale]

1. Topological comparisons between skeletons
2. Using skeletons to control animations by creating tracks for cameras in SciView
3. In the non-thinning based skeletonization code that I wrote (that uses Clojure graph libraries), approximate skeletons can be created from imperfect segmentations (i.e. a false gap in the segmentation ensures that thinning-based skeletonizations can never connect 2 regions, leading to topological defects)

Probably some other stuff, like tracks from cell tracking, etc..

[kephale]

Note that assimp has some support for skeleton I/O https://github.com/kotlin-graphics/assimp/blob/master/src/main/kotlin/assimp/SkeletonMeshBuilder.kt