[ITK] 3D-deformable B-spline registration - why is my program so slow?

Fri Jul 25 04:50:33 EDT 2014

Hi all,

I'm writing a program to perform multimodal, deformable, 3D image registration using a B-spline transform and Mattes mutual information metric (open to using other types of MI if better). My image data is float images of 432 x 432 x 120 and 512 x 512 x 250. Based on the ITK software guide examples I chose the LBFGSB-optimizer, since it apparently behaves better than LBFGS when the registrations needed are small, and either one of these two were recommended for combining with a transform with many parameters like B-splines. At the moment I use the MultiResolutionImageMethod, since the computations took so long (I ended up interrupting them after half an hour or so when I simply just couldn't waste time sitting around), but the problem remains, so computations just go on and on and in the end I have to interrupt the program, so I haven't actually seen how long it does take to finish, although getting past the first resolution level definitely took in the region of half an hour. Essentially, my program is a mix of the examples MultiResImageRegistration1.cxx (multi-resolution fundamentals in software guide, providing the multi-resolution framework) and DeformableRegistration8.cxx (3D B-spline registration in software guide, providing 3D B-spline framework), and I have mostly only played around with parameters to make it faster but no luck so far.

Next, I decided to use the registration->SetFixedImageRegionMethod( fixedRegion ) to speed it up and get to see some output. However, this resulted in the registration running for about 5 minutes after calling Update() and then throwing an exception, saying that "FixedImageRegion does not overlap the fixed image buffered region". I suspect this might have something to do with the way my program is set up: the actual registration takes place in a function separate from the main function, which takes as inputs smart pointers to the fixed and moving images, and the fixed region itself:

ImageType::Pointer registered Bspline( ImageType::Pointer fixed, ImageType::Pointer moving, ImageType::Region fixedRegion );

But I'm not sure how to make it right. Should I perhaps use something like SetRequestedRegion()?

I have tried to run both MultiResImageRegistration1.cxx (obviously it isn't what I want in the end since it's a translation transform, but just to test computational times) and DeformableRegistration8.cxx on the same data that I want to register but without setting the FIxedImageRegion, and although they both showed enough progress (CommandIteratorUpdate-observer) that I had the patience to wait for them to finish it took half an eternity (I don't really remember, but definitely around or more than half an hour). Also, in the case of the DeformableRegistration8.cxx the stopping condition was that the number of iterations exceeded the maximum- the optimizer stop condition was "Too many iterations. Iterations = 30" although the maximum number of iterations was set to 200, which is weird. And the "Get current iteration" output from the observer only showed interations up to 21, so I think there's something I'm missing here as well.
So my question here is three-fold:

1.       How do I manage the fixed image region input so I get rid of this buffered region problem?

2.       My gut feeling would have been that these kinds of registrations would take say 5-10 minutes, not this long. What's the deal here really? (Not a very specific question, sorry about that...)

3.       What would be the best ways for me to reduce computational time without sacrificing too much in the way of registration accuracy? In addition to the SetFixedImageRegion which I have already discussed, some options I have considered are -

a.       Mattes MI: lower number of histogram bins and spatial samples (e.g. 30 and x % of number of pixels in fixedImageRegion?)

b.      B-spline transform: number of control points. I guess this is something I'll have to try for myself because it's surely very application specific, but since it affects the number of parameters a lower number will obviously lower the computation times. By how much relative to other factors I don't know.

c.       LBFGSB-optimizer. Max. number of corrections, evaluations and iterations. I'm not even sure what the corrections and evaluations are (haven't got around to reading the reference yet), so any suggestions for these would be great! Also the projected gradient tolerance. I think for the cost function convergence factor I'll stick to the recommended 1.e7 for moderate accuracy for now.

I really hope I made my problems and questions clear. I didn't include any code since it's so similar to the aforementioned examples, but I'll happily share it if you want to look at it.

Best regards,
Mikael

.......................................................................................................
Mikael Eriksson
R&D Physicist Trainee
Philips Medical Systems MR Finland, Feasibility studies

+358 40 631 8500
mikael.k.eriksson at philips.com<mailto:mikael.k.eriksson at philips.com>
.......................................................................................................

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/community/attachments/20140725/ffef4f5d/attachment-0001.html>