Proposal: Install SimpleITK from wheels instead of building from source

Development
1

Now that Slicer PR-6564 adding support for building ITK with a custom namespace has been integrated, installing SimpleITK from wheels should be possible.

Pros:

  1. Reduced build time by a factor x2 (and probably more on windows)
  2. Version of SimpleITK bundled in Slicer may be update-able using pip, this would allow to install a newer SimpleITK in a released Slicer distribution.
  3. Reduced build-system complexity by removing external projects Swig, PCRE and SimpleITK and introducing python-SimpleITK

Cons:

  1. Fixes integrated in ITK C++ that is used to build Slicer may not be immediately be available in the nightly build, they may only be available once new SimpleITK wheels are released.

Questions

Assuming SimpleITK wheels can be used, should we move forward with this proposal ?

Should we distribute SimpleFilters as a standalone extension and further reduce the size of the main Slicer package ?

  • _SimpleITK.cpython-39-x86_64-linux-gnu.so is 259M on Linux
  • _SimpleITK.cpython-39-darwin.so is 201M on macOS
  • _SimpleITK.cp39-win_amd64.pyd is 10M on Windows

Rational for smaller library on Windows:

# SimpleITK has large internal libraries, which take an extremely long
# time to link on windows when they are static. Creating shared
# SimpleITK internal libraries can reduce linking time. Also the size
# of the debug libraries are monstrous. Using shared libraries for
# debug, reduce disc requirements, and can improve linking
# times. However, these shared libraries take longer to load than the
# monolithic target from static libraries.

Source: Slicer@ff8f546e4 (COMP: Adding option for SimpleITK as a shared library)

Preliminary testing

After removing ITK_AUTOLOAD_PATH from the environment, the SimpleITK package could successfully be installed & imported on Linux (Ubuntu 20.04.4).

import os
del os.environ["ITK_AUTOLOAD_PATH"]
import SimpleITK

That said, attempting to apply a filter by leveraging the SlicerSimpleFilter module failed with the following error:

Exception thrown in SimpleITK ImageFileReader_Execute: /tmp/SimpleITK/Code/IO/src/sitkImageReaderBase.cxx:97:

sitk::ERROR: The file "slicer:0x561741d91310#vtkMRMLScalarVolumeNode1" does not exist.

This means that we should revisit how the SlicerSimpleFilter module access volume node information by instead passing numpy array by leveraging vtk.util.numpy_support like what is done in itk.vtk_image_from_image/itk.image_from_vtk_image or sitk2vtk.py/vtk2sitk.py

3 Likes
2

Yes! (due to the reasons you described above)

Yes, because reducing the installer size (and maybe reducing startup time?) would be very useful. Especially because ITKPython wrapping is kept being improved so developers may choose to use that instead of SimpleITK. For extensions in Slicer-5.3 and later we could add SimpleITK extension as a dependency if the extension uses SimpleITK.

3

SimpleITK rebuild builds packages for most of the common wheels each night when there has been a source code change in the master branch. Currently these are just uploaded to Github for the “latest” release, and discarded when the next latest package is created. Discussions have occurred if it would be useful to upload these packages to an S3 bucket or some other place to be archived for some period ( total size / time limit ). This could enabled fixes and contributions to SimpleITK to be readily available to the Slicer community.

1 Like
4

Things have observed to break down when Slicer’s SimpleITK is uninstalled a SimpleITK upstream version is installed from whl. Slicer's embedded SimpleITK can be removed by pip · Issue #6711 · Slicer/Slicer · GitHub

As of right now it seems that proceeding with using SimpleITK whl files is not possible within Slicer due to requiring the fixes made in BUG: Update SimpleITK to fix test_sitkUtils by jcfr · Pull Request #6606 · Slicer/Slicer · GitHub which are not in SimpleITK upstream.