We are planning to tag ITK 5.0.0 alpha later this week (around April 6th). Prior to this, there will be a freeze in the patches that are merged into ITK. This week, we will be careful to only merge patches that solves important bugs and help to clean up the dashboard. More improvements will be integrated into ITK 5.0.0 before the final release is tagged. The alpha tag does not mean that this is a feature freeze for ITK 5.0.0. We will follow the usual ITK release process and create release candidates when the real feature freeze happens. This alpha release is a preview to allow developers to get their code ready for this exciting new ITK version that integrates a large number of great improvements.
As far as I can see the wish list for ITK5 (nor ITK4) do not contain a wish for something like a itk::GraphObject as described in this PPT on e.g. slide 35. I stumbled on that PPT recently, when we were considering converting the result of itkBinaryThinningImageFilter3D into a graph in order to process this further with Boost. Even though this might be a very special use case, I would find it interesting to have some well defined means to represent a graph in ITK and a bridge to Boost’s graph algorithms.
Where should such wishes for the wish list be posted? Here, GH Issue or elsewhere?
I think it would be very helpful to get early user feedback on removing those virtual keywords. There is a very small risk that it might break some user code. But it offers a significant performance gain. (We observed ~20% reduction of run-time duration of a filter update.)
@grothausmann.roman I agree that is such an important feature! If I have time I will be glad to work on ITKBoostGraph feature in the short future. I have contributed a thinning algorithm to DGtal, a digital topology library, and a way to treat a DGtal::Object (basically a set of points with a topology aka, connectivity) as a boost graph.
I then transform that raw boost graph, where all adjacent pixels/voxels are connected with an edge into a SpatialGraph, where only nodes that are end-points (degree = 1) or branch-points (degree >=3) are kept. The bending or chain-nodes (degree = 2) are stored in the edges between these nodes, as edge_points.
I do this using a depth_first_visit in boost, with a custom visitor, that might be slightly over-complicated, but it works well.
To export/import the graphs I use graphviz with labels (storing position in nodes, and edge_points in edges).
All that work can be ported to a ITKExternalModule, just with the easy step of creating the initial raw boost graph from an image. Basically each pixel is a node, and adjacent pixels are connected via an edge (depending on the desired topology). This graph would be huge for regular images, but for thin images is pretty manageable.
This is the work I have done as the last chapter of my thesis, I will be glad to port it for ITK.
In this area, a nice thing to have would be extra thinning algorithms, and more importantly, a way to compute them in parallel. Amira/Avizo I think do it setting the pixels in the borders of the parallel regions as non removable, run the thinning, then change the regions for the border to be now in the middle, and re-run the thinning. It is quite effective, and I think it would be worth to do it in GPU (but I have no experience with GPU computing right now) .
@Niels_Dekker: Unfortunatly, since we froze the list of features for the alpha, we won’t be able to integrate your patch that is really good but doesn’t help making the dashboard green and doesn’t technically correct a bug. We will definitely integrate it in the ITK 5.0 RC when we are there. This alpha is mostly here to help the community test the change in the API and the C++11 support.
@phcerdan That sounds very interesting, especially considering that itkBinaryThinningImageFilter3D is still not part of ITK and apparently has
some issues (https://doi.org/10.1006/gmip.1995.1045). What is your thinning
algorithm called in DGtal. I couldn’t find any nor something similar on your GH
fork.
@grothausmann.roman My PR was merged in 0.9.4, you can find the function that performs the thinning here.
The algorithm is based on Critical Kernels that ensures that the thinning keeps the same topology than the original object. It was originated by Couprie and Bertrand.
Ready to use scripts can be found here, and my own. Be warned that the memory consumption is pretty high for big volumes, but the run time is ok.
Indeed, the freeze is over. As mentioned by @Niels_Dekker, ITK v5.0a01 has been tagged. The release has not been up officially announced yet because I am still working on generating some of the packages. I will update this thread as soon as everything is ready.
