Highly variable affine registration results for repeated runs

Algorithms
, , ,
5

Hi @lassoan thanks for your insight and suggestion to plot the metric surface. I also admire your optimism with regards to my abilities. :laughing: Many times I’ve gone in circular arguments when trying to decide whether to progress with SimpleElastix or SimpleITK.

Apologies for the length of my response but this is an interesting topic with a fair bit of complexity. So if you will forgive me…

Despite Kasper Marstal’s valiant efforts I think the people power behind the development of Sitk far exceeds that of Selx. And with numerous notebooks for examples and forums like this it’s possible to get support from the community. This doesn’t exist for Selx. But moreover I ran into some major roadblocks with Selx.

It might be helpful to take a moment to explain the bigger picture of what I’m trying to do: An add-on feature for the OHIF-Viewer that will enable a user to “copy” a ROI (contour(s) or segmentation(s)) from one DICOM series to another. The bulk of the code will likely remain in Python with some conversion from/to JavaScript at inputs/outputs to the Python code.

If the “source” and “target” series have different FrameOfReferenceUIDs registration will be performed. The images could be MR, CT, PET, etc. and might require rigid, affine or bspline transforms, and might require landmarks (e.g. MR to full-body CT) for initialization.

Once the user has patiently waited for a registration to be performed we don’t want them to wait again if unnecessary. So following registration the parameters will be stored as a DICOM Registration Object. If in the future the user wishes to perform a copy of a different ROI but for the same pair of series the parameters will be read from the DRO, and the “source” ROI will be transformed to the “target” domain skipping the computationally expensive registration step.

Here lies the main issues that resulted in the switch from Selx to Sitk:

  1. While affine/bspline registrations in Selx using a COM/geometric initialization took ~ 1 min, using landmarks (“CorrespondingPointsEuclideanDistanceMetric”) for initialization took 7-8 min. By comparison Sitk does the affine in about 1 min, and the bspline in 3-4 min. I tried tuning Selx parameters to try to reduce computational time but to no avail.
  2. Trying to get the deformation field following a bspline registration in Selx killed my kernel (known issue), which means I can’t get access to the parameters to store in a DRO
  3. If I perform the registration in Sitk v1.2 (which is what Selx is based on) I cannot SetCoefficientImage for BSpline Transforms (SetCoefficientImage was introduced in v2.0), which means I can’t use an existing DRO to transform/resample the “source” ROI

Perhaps if the import call to Selx was import SimpleElastix rather than import SimpleITK it might have been possible for me register using Selx and transform/resample with Sitk v2, but that would still have required me to get the deformation field. As far as I’m aware it isn’t possible/practical to import two different versions of a package at the same time.

So I’m in a difficult situation where I would benefit greatly from the ease and robustness of Selx (which is really needed if you’re developing a GUI tool to be used for a broad range of data by non-programmers) but as it stands my workflow is fragmented in Selx and complete (not completed) in Sitk.

You seem to be a very experienced developer with expertise on both sides of the Selx/Sitk fence. I wonder if you might have any advice on how you might approach this dilemma.