vmtkbranchclipper running for a day and still no result.

Hi all,
I am new here!
As the title says, I have been using the vmtkbranchclipper on a tracheobronchial tree to generate the branches but the command is running forever.

The command I am using is this
“~/vmtk_Py36/vmtk/bin/vmtkbranchclipper -ifile TB.stl -centerlinesfile TB_cl_sm_sp.vtp -ofile TB_branch_cl_sm_sp.vtp”

here is a look of the input files:

If I run the same command on a subset of the geometry the command gives an output. For example see the image below

In fact I can run the command for the other 4 subsets (lobes) and again I get an output.
It takes about 30mins if I remember well to run each subsets. But the full tree was running for a day and I stopped it.

What seems to be the issue?
I believe some form of optimisation is needed. Somewhere it gets trapped.

You can access my files here

It could be that your TB.stl file is corrupted, just a conclusion.

Try these in SLicer :

  • load TB.stl
  • in Data module, create a segmentation from the TB node
  • in Segment editor module, hide 3D and show 3D again

This is the result :

No such glitches were found with sample STL files.

I can’t explain any of these unexpected behaviours, you may try regenerating your surface.

Hi and thank you for your reply.
The stl file is not corrupted. It is an open surface meaning that the inlet and outlets are open. So your visualisation software is tying to close them and it fails.
I have updated the dropbox folder and I provide also closed stl files.
Try again if you like to see what is going on.


Yep, the closed surface does not get altered in Slicer, I mean, the segmentation derived from your original file.

Now I made other processing today with a segmentation containing only 19 branches, i.e., much fewer than in your model. I took 12 mins. Too much. And it uses only one CPU core throughout. Only VMTK folks can say if this processing can be multi-threaded.

Debranching your model would probable end up with success in a few days, that’s obviously not a pragmatic workflow. As for ‘How will so many branches help you in practice ?’, well, …

We learn that less is better here.

any other ideas are welcome from the VMTK folks…

This is a great airway segmentation, would be interested in how you generated it.

Are you running vmtkbranchclipper from an extension in 3d Slicer, from the Python console, or from the command line?

It seems @Fotos_Stylianou is using the command line, and I am using a newly available module in SlicerVMTK, based on vmtkbranchclipper.py.

But the bottleneck is here. Too many points in the surface, and too many branches will definitely be very long to process on one single CPU core.

Maybe trivial, but you may see on a CPU / GPU monitoring tool (I currently use and recommend CPUid HWMonitor classic on Windows) where the hardware performance bottlenecks really are at certain points of a script.

Many thanks for your responses.
@rbumm the segmentation mask is processed with meshmixer to reach the level you see at the images. I did some magic also with vmtk for the outlets.
@chir.set thank you for pinpointing where the bottleneck is. Hopefully the VMTK team will look into it.
I have to say that even if I reduce (by a lot) the number of cells on the surface mesh still the command does not produce anything. I believe that the number of branches is the problem.
Anyhow, I was not expecting a quick solution.

By the way I found an other way to get something similar to what branchclipper does by using paraview. And it runs like in 1 second. So that is why I say that the vmtk branchclipper needs some rewriting and optimisation.

I summarise my steps in paraview with the images below in case someone might end up in my situation:

the last two steps follow in the next post because I can only add 3 images per post

I will be deleting the dropbox folder next week because I do not want my geometry circulating the internet.

Many Thanks for your responses!

1 Like

1 Like