This morning I have been investigating python wrapping for plastimatch. It looks feasible to use the ITK wrapping method. Would this be a reasonable approach for eventually allowing python interaction within 3D Slicer? I’m a bit concerned because looking at the Slicer’s build it seems ITK itself is not wrapped and not available in Slicer python.
investigating python wrapping for plastimatch
This is good to hear. Are you thinking about creating a dedicated “pythonic” API or a one-to-one mapping with the C++ one ?
It looks feasible to use the ITK wrapping method
This is suitable for projects providing ITK filters and/or classes (or having functionality that could be wrapped in such a way).
If that makes sense, you could look at using the https://github.com/InsightSoftwareConsortium/ITKModuleTemplate as a starting point. See also https://blog.kitware.com/python-packages-for-itk-modules/
Would this be a reasonable approach for eventually allowing python interaction within 3D Slicer?
Since python packages distributed on http://pypi.org/ can now be installed on Linux, macOS and windows. This would work.
Slicer’s build it seems ITK itself is not wrapped
This is correct, while there is an option called
Slicer_BUILD_ITKPython, it not enabled by default.
ITK itself […] not available in Slicer python
following the recent transition of Slicer to python 3.6, running
pip install itk would allow you to use it.
Thank you for the great feedback! This is quite new area for me, and I’m still considering the best plan.
Both pybind or scikit-build look good. Do you have any idea which would be better? I note that SimpleITK seems to use scikit-build.
Do you have any idea which would be better?
If you are already familiar with ITK and crafting a Plastimatch API built around ITK data structure is relevant, this would be a sensible approach.
You also be able to leverage the input of the community and wealth of knowledge shared on the ITK forum (https://discourse.itk.org/)
The template would also give you CI and infrastructure for package distributions with no effort. @phcerdan works on a similar project to wrap the
proxTV project and make it available as https://github.com/InsightSoftwareConsortium/ITKTotalVariation module
While this removes the need for tools like
swig, you are still required to maintain the wrapping code. Note that I don’t have a lot of experience with it.
suggested next steps
It may be sensible to craft a document listing the functionality and API you would like to expose to Python.
It would also be nice to listing the data structure that should not be deep-copied and are expected to be shared between VTK/ITK/etc … (if any)
This project streamlines the creation of python package (called wheel) for project using CMake. It is not responsible for any wrapping in itself and will be relevant for all approaches involving compilation of python modules.
As @jcfr notes, the ITKModuleTemplate may be the fastest way to get started. This avoids:
- Manually maintaining binding code (we analyize the headers with CastXML to generate the required SWIG interface files).
- The CI infrastructure to generate Windows, Linux, and macOS packages.
- The configuration to build the wheel with scikit-build and the post-processing steps to make distributable wheels.
The ITK Software Guide has a section on writing the wrap interface files, but we would be happy to answer questions.
Got it. Thank you! I will do a pilot study.
I think for Slicer users interface with sitk might be more important than itk.