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”
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.
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, …
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:
