Feedback on using elastix for deformable prostate registration

[fedorov]

We are in the process of incorporating elastix into the SliceTracker extension in 3D Slicer that we use to support in-bore targeted prostate biopsy (see publications in the extension documentation for references etc).

The registration problem we need to solve is registration between T2-weighted high-resolution scan of the prostate obtained before the procedure (typically, with the use of endo-rectal coil), and the intra-procedural T2-weighted scan of somewhat lower in-plane resolution (no endo-rectal coil).

Until now, we used registration tools included in 3D Slicer in that extension (details in this publication), but we want the software to be modular so we can experiment with the registration strategies, and we also think elastix registration might be a better registration tool anyway.

To do registration with elastix, we use an application-specific initializer (rigid alignment of the centroids of the segmented masks of the prostate and rough grid search to improve the initial pose), passing the the moving image after applying the rigid transform to elastix, and using one of the default parameter files with minimum changes. You can see the discussion and specifics on how we initialize the parameters here:

• Consider using Elastix registration as an alternative registration solution SlicerProstate/SliceTracker#334
• ENH: added Elastix registration (issue #334) SlicerProstate/SliceTracker#341

Based on the initial testing on a couple of datasets, we are getting good results. We have a reasonable-sized dataset annotated with landmarks that we next planned to use to measure TRE and compare elastix registration with the approach we are using currently for a more principled comparison. Before we do that, we would like to check with the elastix experts on whether the parameterization we use requires any modifications. Would you mind taking a glance at the parameter files, and let us know if you have any recommendations?

To be clear, things seem to work, and we have no specific problem, but we would appreciate if the elastix experts could give us the "blessing", to make sure we use it in the most optimal way, before we do the quantitative evaluation of the registration accuracy.

cc: @che85

[kaspermarstal]

Sure I can take a look @fedorov, but can you link directly to the parameter files or just post them here? It is not clear to me where to obtain the parameter files in the two discussions you listed. Thanks!

[fedorov]

@kaspermarstal thanks!

You can see the parameter files for rigid/affine/b-spline in this pull request:

• rigid: https://github.com/SlicerProstate/SliceTracker/pull/341/files#diff-35c17ae0c6fc45f6280c8c6719d7c54b
• affine: https://github.com/SlicerProstate/SliceTracker/pull/341/files#diff-04aa48b3655e2714bb803a80c1035da4
• b-spline: https://github.com/SlicerProstate/SliceTracker/pull/341/files#diff-3aa4e49b9ded4e59482b10be9c35f37b

[kaspermarstal]

• FixedImagePyramid should be FixedImageSmoothingPyramid for best results (unless memory is really and issue).
• AutomaticTransformInitialization should be true for rigid and false for affine and bspline.
• 250 number of iterations is also on the low side. If speed is really an issue, 250 is fine, but if you can afford it use at least 512.
• Depending on the problem you might want to use at least 3 resolutions. Some places you use 2 which is on the low side.
• ImageSampler should be RandomSparseMask if users use masks. Otherwise it is fine.
• If you use a BSplineInterplationOrder of 1 you might as well use LinearInterpolator which produces the same results but is faster.

Otherwise it looks good!

[fedorov]

@kaspermarstal thank you for the feedback! Since my last update, we did more testing, and the elastix registration unfortunately does not always work. But I am sure we will figure it out with your help! @Kmacneil0102 is currently working to reproduce the issues on a public dataset, and we will update this thread as soon as we have results.

See my responses to your suggestions:

AutomaticTransformInitialization should be true for rigid and false for affine and bspline.

We use external application-specific initializer. The initializer we implemented takes the segmentation masks of the prostate in the two images, aligns their centroids, and then does sparse search to optimize the metric by rotating the images over small range (don't remember now in what plane!). This initializer has been working quite well, and I don't think default initializer could replace it. Unless you already have something similar in elastix?

Depending on the problem you might want to use at least 3 resolutions. Some places you use 2 which is on the low side.

We actually started with the default 3, but then reduced, since our region of interest is quite small (could be as small as 5-10% of the total image volume probably), and so there may not be enough data to subsample. Reducing resolutions helped somewhat with making the configuration more reliable.

We will update the rest of the parameters as you advised - it all makes sense to me!

[kaspermarstal]

OK great! One comment:

We use external application-specific initializer [...]

OK, then make sure to set AutomaticTransformInitialization to "false" for all parameter maps. It was true for the first one, which will discard your custom initialization.

[fedorov]

@Kmacneil0102 can you please update the configuration as suggested above before running the experiments?

[mstaring]

closing for now, you can reopen when needed.