We are developing a Slicer Extension for aligning 3D shapes.
We have previously created our module and it runs like a charm, but because the algorithm is bit time consuming we wanted to parallelize the algorithm.
Because vtk objects cannot be pickled (which is needed for the multiprocessing), we successfully replaced the vtk with tvtk in our independent python module, and everything is looking good.
However, when I try to connect it to our Slicer module, upon opening Slicer I get the error
WARNING: Imported VTK version (8.2) does not match the one used
to build the TVTK classes (8.1). This may cause problems.
Please rebuild TVTK.
and the algorithm fails. Am running Ubuntu 18.04 with Slicer 4.11.0-2019-07-27 r28412, but we would of course like the extension work on all OS.
Is there a way I can rebuild the tvtk in Slicer, as the prompt suggests? Or should I try something completely else? Any pointers greatly appreciated, am hitting a wall here pretty badly.
I don’t think you can use different VTK versions in the same application. You may rebuild TVTK as suggested, but it is probably simpler to add custom pickling functions to vtkImageData (for example, you can serialize the image data to nrrd file).
If all you need is to run some processing in the background then it is probably simpler to run your processing script as a CLI module. See an example here.
It is important to use the exact same build options as Slicer, which might be somewhat tricky. You may try to build with default options and if you find the binaries incompatible (crash when you try to use TVTK) then build Slicer and then build TVTK using Slicer’s VTK.
You may also write to VTK forum, asking for improving VTK’s Python wrapping by making VTK objects pickleable.
Do you do all these to just run some processing in the background?
Do you need this to run the auto3Dgm module independently for multiple cores? Did you consider CLI module alternative @lassoan suggested?
If you create a custom build of Slicer, you will not have access to extension platform (i.e., any extension will need to be build manually against your custom build).
My interest in the custom build stemmed that since we are building a custom slicer to begin with, if solving the issue on that end is not an insurmountable task, that would give us parallelization in that custom build immediately. Clearly it is not a good long term solution.
We will need to be able to run the auto3dgm python package in parallel, but not the auto3dgm slicer module itself. So pass arguments with Slicer to the python package, which then runs it in parallel and returns the results.
For long term yes, I believe CLI module seems like a promising alternative, provided that the interfaces therein are easy enough for the audience to use. Another option would be refactoring the python package to use numpy arrays in lieu of tvtk objects.