Aggressiveness controls how much simplification is allowed. If aggressiveness value is too low then you may not be able to reach the point count target. If aggressiveness value is too high then you may have errors in the generated mesh.
Thank you. May I know what’s the range in which this parameter can be varied? Or is it recommended to use the default?
Any positive “aggressiveness” value is valid, but on the models I’ve tested on values in 3.5 to 4.5 range worked best.
I have added detailed “Extract centerline” module documentation here: https://github.com/vmtk/SlicerExtension-VMTK#extract-centerline
1 Like
Hi @lassoan
I would like to know if you had a chance to test the centerline computation on the model file that I had shared to understand how much memory would be required and the duration that it takes.
I’d also like to know if multi-thread centerline extraction can be executed.
Yes, it works well.
Starting from your original model (525k points, 1051k cells), with default settings, endpoint auto-detection is done under 15 seconds and with these endpoints centerlines are detected in less than 1 minute. Memory usage does not go above 1GB.
Branch extraction (computation of centerline curve or quantification results) seems to be sensitive to presence of unreachable endpoints: computation can take a really long time and lots of memory (maybe it never completes?). For example, I had to stop one execution after about half an hour computation and 10GB memory usage. After deleting all the unreachable endpoints, computation was completed within a couple of minutes (and peak memory usage was not more than 1.2GB).
Thanks a lot for sharing the link to documentation.
Yes, it never completes. I have been facing memory issues in the past while trying to obtain the quantification results and the centerline detection worked absolutely fine. I now switched to a server with 35GB of free memory and the process is still running for more than 12 hours. So I was wondering why it’s taking so long and why does it consuming so much memory
Could you please let me know how to find out the unreachable endpoints ? Should I have a look at the Voronoi model and find out the endpoints that don’t lie on the Voronoi model? If you could add a snapshot of the unreachable endpoints that you are referring to, that will be really helpful.
I also have a suggestion, I think it would be helpful for the users if Slicer can throw a warning before
the computation of centerline curve or quantification results task is initiated when unreachable endpoints are present in the model.
Look for the straight line segments, as shown in the tutorial video. For each unreachable point, you can decide to move it to the Voronoi model surface or (if they are actually not connected to the rest of the tree) delete it.
Yes, of course, it would be great to detect these points automatically. Could you give it a try to implement it? Centerline extraction is just a Python script, so you can make changes very easily. You just need to do some detective work to figure how these points can be detected: search on google in VMTK mailing list archives, ask on the mailing list, or maybe review and figure out something from VMTK source code.
I had noticed this in the tutorial and removed 1 line before I initiated the run. I had a relook at the model and figured out there was another straight line that I missed. Finally after removing both, the quantification of results completed in less than 2 minutes. Never imagined the presence of these lines could cause a lot of trouble. Thanks a lot !
However, I also noticed that the centerlines aren’t detected for some branches in the model that I have shared before.
Could you please let me know if it’s possible to do some manual intervention to enable the centerline computation of these vessel segments too?
Sure, I will discuss this issue on VMTK mailing list and keep you posted here.
Thanks a lot for your tremendous support!
Path search between endpoints fail if no path is found, i.e., the route would need to go through very thin or non-existing segmented regions. You need to improve the segmentation’s quality (increase image resolution, smooth it more carefully) and/or tune surface smoothing. You can try disabling surface smoothing completely to ensure that branches are not thinned at all.
If a branch is clearly visible in the segmentation (branch is not thin and its tip is not pointy) but the branch is not in the preprocessed model then you can increase the Target point count or decrease Decimation aggressiveness.
@lassoan Thank you. I’m trying out the about-mentioned suggestion on improving the segmentation quality.
But from what I understand, only tree-like structure is returned and the loops /cycles aren’t detected.
EDIT:
It is indeed true. Please check the following excerpt from [vmtk mailing list], written by Luca
Indeed the centerlines filter doesn’t catch loops, which is usually ok for arterial trees, but it can be limiting in other situations such as yours.The reason is that the algorithm searches for some sort of shortest path from the inlet to the outlet, thus is will only choose one of the two arms of the loop.
There are a couple of things you can do:
This is a hack:
a) generate one centerline and save it to a file
b) use vmtksurfaceclipper to make a cut in the branch in which the centerline was generated
c) run vmtkcenterlines again; it will extract the other branch (since the former is not continuous due to the cut); save it to another file
d) use vmtksurfaceappend to have the two centerlines in one dataset, if you need thisuse vmtknetworkextractor; make sure the surface has at least one opening and run the script; this algorithm is less accurate in tracing the centerline, although it might be enough for your needs; however, it handles loops correclty
Hi @lassoan
I’ve testes the above. Networkmodel, I belive is obtained using VMTK’s networkextraction, captures the loops -blue lines appropriately.
It will be really helpful if the quantifications results are made available for the network model in addition to the centerline model. I hope this will be easy and the network polydata can be used as input instead of centerline polydata in createCurveTreeFromCenterline function definition available here.
Could you please let me know this will be made available?
I would be happy to add this to a Slice module if you can provide me to a Python script that computes it. Could you give it a try? If you are not sure if it is possible then ask it on the VMTK mailing list.
Could you please have a look at the relevant python script that I have shared on my GitHub account ?
The input file for running the above script is in stl format.
I worked on this a month back before I got started with Slicer.
I am stuck here – computing the centerlines length / branch length in the network . Some suggestions were offered in this discussion on VMTK mailing list.
You can use vmtkCenterlineAttributes on any centerline object (e,g, the output of vmtkNetworkExtractor). It will create an array called “Abscissas”. The Abscissas is the length along each cell/branch. So the length of the branch will be the abscissas value at the last endpoint of the branch. See the VMTK tutorial “Geometric Analysis” for more information.
But I couldn’t find Abscissas array and got stuck here. Please have a look at the discussion in the above-mentioned thread.
If you could offer advice on how to improve this further I will be super happy to continue from here.
Could you please have a look at this updated script?
@lassoan
Updated a nicer version again in the above link 
I’d like to ask for suggestions on using the network model generated form slicer as an input instead of the stl input file that’s currently used.
The problem is, currently the networkExtraction algorithm doesn’t work on the stl files that I export from the segment generated in Slicer.
Please find the corresponding stl file of the large model, for which networkextraction failed in vmtk, available here
Network extraction works perfectly using Extract Centerline module for this model (segment3.stl, 264702 points, 529596 cells). Both with preprocessing and without it.
I’ve enabled metric computation (radius, curvature, torsion, Frenet-Serret frame, length, and tortuosity) for network extraction result (will be availble in tomorrow’s Slicer Preview Release):
In addition to these could you please enable startposition and endposition for this network model as well in the quantification results table?
Adding a quantification table for network extraction would not be hard, but for this to make sense one step is missing: you would need to split curves at branching points:
Please try to figure this out by playing with the code in Extract Centerline module and/or asking on VMTK mailing list.