ShapeWorks ITK Module

[sheryjoe]

Template:
https://github.com/InsightSoftwareConsortium/ITKModuleTemplate

[cchriste]

Will you please explain the reasoning? ShapeWorks is not an itk module. It uses itk, not the other way around.

[cchriste]

Maybe related to #160, #171, #302, #408, and #431.

[sheryjoe]

The objective here is to allow developers to incorporate SW tools (computational library) in their ITK-based applications. Bindings to a widely used open-source toolkit as ITK will allow us to widely and effectively distribute our tools and ensure its long-term viability by building an engaged open-source developers community around ShapeWorks.

Initially, ShapeWorks or the particle system library was developed to be an ITK external module. Based on that, we had plans to have a ShapeWorks ITK module. In light of our significant progress in consolidating the computational backend of ShapWorks tools, I love to hear your thoughts on establishing such bindings with minimal changes to our infrastructure.

[cchriste]

The objective here is to allow developers to incorporate SW tools (computational library) in their ITK-based applications. Bindings to a widely used open-source toolkit as ITK will allow us to widely and effectively distribute our tools and ensure its long-term viability by building an engaged open-source developers community around ShapeWorks.

In C++ we currently provide access to the underlying ITK and VTK classes upon which our Image and Mesh classes are constructed. For Python, this hasn't been possible for at least two reasons. The first is a version mismatch which might be resolvable by building Python bindings when we build ITK itself in build_dependencies (#302). And the second is that ITK uses a different system for its Python bindings.

I suspect the underlying classes could be linked regardless of the bindings, but I'm not sure how to do this or whether it would be appropriate in C++ or Python. One idea is to send the ITK image pointer to Python as a black box type (C++ ShapeWorks modification), then provide an ITK binding that blindly trusts such a type contains a valid ITK image from which to instantiate their own Python Image wrapper (C++ ITK modification). It's very possible, but when we contacted them about it they were disinclined to add such a function, but this doesn't prevent us from modifying their code. However, as #302 describes, building the ITK Python bindings in the first place is apparently very difficult and/or time-consuming.

Initially, ShapeWorks or the particle system library was developed to be an ITK external module. Based on that, we had plans to have a ShapeWorks ITK module. In light of our significant progress in consolidating the computational backend of ShapWorks tools, I love to hear your thoughts on establishing such bindings with minimal changes to our infrastructure.

We can currently connect to ITK classes and functionality by providing our underlying classes when they happen to already be ITK classes (e.g., Image::getITK).But converting our APIs to be more ITK-like would be a significant task, requiring us to derive from ITK base classes and add specializations of all the necessary virtual functions. It's also very different in terms of the way our systems are used since ITK is pipeline-based while ShapeWorks is not. It might be possible to write ITK wrapper classes that use ShapeWorks classes just as some of our classes use ITK classes. Concrete examples might help us more carefully consider various options.

[akenmorris]

Shireen, is the goal here to do only the optimization?

For a history reference, the external ITK module that Josh developed was abandoned and the project went back to the original repository.

[cchriste]

I propose we consider ShapeWorks a first class citizen rather than an ITK module. It provides functionality that makes effective use of many other libraries besides ITK. ShapeWorks also provides a comprehensive command line interface and Python bindings. It is still interoperable with ITK such that Images can be transparently constructed from and passed to ITK pipelines, as well as an interface that seamlessly enables these images to be used in concert with vtk Meshes.

There are many other ways besides its primary functionality that ShapeWorks can be combined with other applications, including the use of increasingly popular Workflow Automation Systems that enable synchronized processing using a wide variety of tools, applications, and data storage.

Given the difficulty and lack of clarity of this task, I hope we can close it and that the text above can be properly cut and pasted into some useful description of our application.

P.S. We also have Studio that provides an excellent way to visualize and explore the ShapeWorks workflows.

[akenmorris]

Replacing with #1710 and #1711