I hereby draw your attention to ‘Branch clipper’ module newly written in C++.
It splits a bifurcated vascular segmentation using its centerline model as produced by ‘Extract centerline’ module.
I believe that its logical home is the SlicerVMTK extension. The single problem is that VMTK is compiled in SlicerVMTK targeting Python development only, and is not C++ friendly. I suppose that VMTK there could be built for development in both languages, but I could not find a nice way to do that for C++. So ‘Branch clipper’ builds against an independent VMTK build. As such, it can’t be integrated in SlicerVMTK.
‘Branch clipper’ can also be rewritten in Python. I’m ready to do that, being left with an uneasy feeling of “VMTK in SlicerVMTK is good for Python, bad for C++ !”. It would of course take time.
I wish to know :
Would ‘Branch clipper’ module be welcome in SlicerVMTK?
Is there any chance that VMTK in SlicerVMTK may become friendly for C++ development, even on some remote day?
Would splitting SlicerVMTK into SlicerVMTKLibs and SlicerVMTK be a thinkable option? SlicerVMTKLibs would here provide VMTK libraries only, fit for both Python and C++, while SlicerVMTK would be another extension interacting with SlicerVMTKLibs. (Just a question; and I don’t have sufficient cmake skills to do that.)
Hi @chir.set that looks really useful and would be great to include.
I think the idea of extensions in C++ being linked to other C++ extensions is a hard problem in general but not unsolvable. Setting up SlicerVMTK has always been one of the more complex extensions since it has both VTK and ITK classes.
Would it make sense to contribute your features to VMTK upstream? That might simplify the build process.
VMTK already provides vmtkbranchclipper.py, which is the basis for the proposed module. It’s designed for PypeS (which is quite foreign to me). The purpose of ‘Branch clipper’ is to do same in Slicer. It’s doubtful that VMTK devs would create a dependency on Slicer.
I see, thanks for the info. No, of course we don’t want a circular dependency with VMTK depending on SlicerVMTK or Slicer. What I meant to say is can’t you add your code to SlicerVMTK.
There are several extensions that has C++ modules that uses on C++ modules (module logics, MRML classes, etc) of another extension. When you first do this it is probably not trivial, but I don’t think there is anything very special about it - it all works very similarly as using any other external project in CMake (you specify <external_package>_DIR as CMake variable and use find_package() in the CMakeLists.txt file of the project to get targets, include files, etc. from the external project).
If you get stuck at any point then post the error message and we will help with figuring out the solution.
“PypeS” is just a set of helper functions to make it easier to implement command-line scripts in Python. Those people who learn how to use it like it. However, I don’t like it because it makes the code more opaque, non-standard, unfamiliar - or as you put it “foreign”. It is foreign to everyone but the few VMTK developers who originally developed it and those few people who actually learned how to use it. I just refuse to learn how to use them because that would mean I would need to use shell scripting to use VMTK, and I much prefer Python scripting.
I just use these PypeS scripts as examples by copying the contents of their Execute method, use the __init__ method as documentation.
I agree, that would be the appropriate place. The same was as we did for vessel enhancement and centerline extraction modules.
These are Python projects, vtkvmtk libraries are searched for and used at runtime only, at least that’s what I understand.
Consider these steps :
Try 1 ::
add BranchClipper directory to a SlicerVMTK source tree, and the corresponding add_subdirectory() instruction in CMakeLists.txt
configure setting Slicer_DIR only
-build result is
/home/arc/src/SlicerExtension-VMTK/BranchClipper/Logic/vtkSlicerBranchClipperLogic.cxx:32:10: fatal error: 'vtkvmtkPolyDataCenterlineGroupsClipper.h' file not found
#include <vtkvmtkPolyDataCenterlineGroupsClipper.h>
Try2 ::
add BranchClipper directory to a SlicerVMTK source tree, and the corresponding add_subdirectory() instruction in CMakeLists.txt
add find_package(VMTK) in the CMakeLists.txt of BranchClipper
configure setting Slicer_DIR, and VMTK_DIR to a non existing VMTK-build directory that has not yet been created because VMTK is not built yet; the result is
CMake Error at SuperBuild/External_VMTK.cmake:18 (message):
VMTK_DIR [/home/user/tmp/Slicer/VMTKBranchClipper/VMTK-build] variable is
defined but corresponds to nonexistent directory
Call Stack (most recent call first):
/home/arc/src/Slicer/CMake/ExternalProjectDependency.cmake:844 (include)
/home/arc/src/Slicer/CMake/ExternalProjectDependency.cmake:918 (ExternalProject_Include_Dependencies)
SuperBuild.cmake:35 (ExternalProject_Include_Dependencies)
CMakeLists.txt:35 (include)
How can we point to a non-built external project, and get its include directories, link directories and link libraries ?
I could include BranchClipper, in fact the extension containing it, inside SlicerVMTK and get a successful build, in this branch. It’s certainly not optimal.
There are 2 clear problems I could not resolve :
packaging ignores BranchClipper
in a clean build, the first try will fail in BranchClipper while VMTK is being built.