Hi, I’ve been developing a module for manual refinement of normalization (WarpDrive - github, video).
This module runs plastimatch landwarp based on source and target fiducials set by the user via different tools accessed in the module.
The module allows the user to set a radius specific for each point, but the current implementation of plastimatch takes one fixed radius. I recently added the possibility to set the radius as a vector (commit), and a modification in platimatch to allow this input (commit).
Would there be interest in adding these changes (or something of the sort)?
Also (perhaps should post this on a separate topic), would it make sense to have a SlicerPlastimatch extension instead of having it inside SlicerRt? Then the dependency of this module would be more straightforward (as well as people in general that would be interested in it).
I’ve also seen some activity by platimatch developers here. I would be very interested to hear their thoughts on the module
Yes, I think a SlicerPlastimatch makes a lot of sense. Maybe @gregsharp.geo can chime in?
There’s some similarity to the LandmarkRegistration (although I haven’t worked on that for a while) and also the FiducialRegistration in SlicerIGT. Maybe we should try to harmonize or unify these approaches somehow.
It would not be trivial to expose all of Plastimatch features via a public module interface. As far as I remember Plastimatch is not even built as a dynamically loadable module in Slicer due to some issues in the build system. Therefore it would take some effort to move out Plastimatch to a separate extension.
Also, main focus of Plastimatch is radiation therapy and so it makes sense for it to depend on SlicerRT, and SlicerRT to depend on Plastimatch, which the easiest to achieve if they are in the same extension.
What would make a lot of sense is to move out independent features from Plastimatch to separate libraries to make the core library smaller and more focused. For example, the registration library could be a nice independent, Python-wrapped, ITK remote module that could be used in Slicer extensions but could be also easily pip-installed and used in any Python environment. Similarly, DRR, CBCT reconstruction, segmentation, could be all carved out into separate ITK remote modules. Those basic features that are now widely available in ITK, SimpleITK, VTK, and other toolkits (such as image and vector field conversion and manipulation), could be probably retired. This reorganization would result in a much smaller, more cohesive, RT-oriented Plastimatch library that could be kept with SlicerRT; while general-purpose features could be made available in separate extensions.
These decisions of course all completely up to @gcsharp, who developed and maintains the entire code base.
