[ITK] Image Registration Initialization

[Lowekamp, Bradley (NIH/NLM/LHC) [C]]

Hello,

Did you do any specific profiling to determine these bottlenecks? If so could you please share the profiling code along with the timing you got?

Also you did not provide any details about the situation where you found these performance issues. What transform you are using? What is the size of the image? What optimizer are you using?

With the v4 framework, in some situations the initialization, and iterations are slower, however for many registration setups with a large number of parameters good results can be achieved with fewer iterations. Additionally, when the framework is combined with the parameters estimators the results are more robust. And with the built in multi-resolution and metric sampling efficient results can be achieved by using all these features of the framework.

Based on your comments, I looked through the itk::ImageRegistrationMethodv4. I see that it is using the itk::DiscreteGaussianImageFilter. The itk::SmoothingRecursiveGuassianImageFilter is generally known to be more efficient. I would suggest hacking the ImageRegistrationMethodv4 to use the itk::SmoothingRecursiveGaussianImageFilter, and determine if there is a performance improvement.

You cannot swap the fixed and moving inputs images at each resolution scale iteration. However, you could take control of scale iterations yourself, by just running the ImageRegistrationMethod at one level, where you choose the appropriate scale for setting the fixed and moving input images.

HTH,
Brad


From: Brian Eastwood <brian at mbfbioscience.com>
Date: Friday, September 22, 2017 at 4:55 PM
To: "community at itk.org" <community at itk.org>
Subject: [ITK] Image Registration Initialization


Hi Folks,



I really like the changes implemented for ITK v4 registration. The composite transform makes multistage registration much easier to implement. Nice work!



Is there a way to explicitly set the fixed and moving images to be used at each level of a multiresolution registration? How about the gradient images used by the image metric? I see you can set gradient filters on the metric, but what if you already have the gradients precomputed?



I get the feeling that v4 registration runs slower than similar v3 registration, but I think it’s mainly down to the initialization where the fixed and moving images are smoothed and the metric computes the image gradients.



It seems like there could be some real advantages to using precomputed smoothed and gradient images. For example, the smoothing could be implemented with a cascade of Gaussians where the standard deviation used at a level k is given by s^2 = s_k^2 - s_{k-1}^2. Or the smoothing could be implemented on the GPU. Or we could be reusing a resolution level in a different registration stage, perhaps optimizing a different set of transform parameters.



Have I missed something in the API where it is possible to explicitly set the images and gradients to use at each level of the registration? I could probably create an itk::Command that swaps the fixed and moving images before each registration iteration, but is there a way to disable the smoothing step?



Regards,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/community/attachments/20170925/186e7ef9/attachment-0001.html>