Python wrapping of plastimatch

(Greg Sharp) #1

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.

1 Like
(Jean Christophe Fillion Robin) #2

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.

suggestions

You may want to look at using https://github.com/pybind/pybind11#readme along https://scikit-build.readthedocs.io

1 Like
(Greg Sharp) #3

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.

(Jean Christophe Fillion Robin) #4

Do you have any idea which would be better?

ITKModuleTemplate

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

Cc: @thewtex

pybind11

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)

scikit-build.

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.

1 Like
(Matt McCormick) #5

Hi @gcsharp,

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.

(Greg Sharp) #6

Got it. Thank you! I will do a pilot study.

I think for Slicer users interface with sitk might be more important than itk.