[ITK] b-spline registration performance

Wed Aug 26 17:09:13 EDT 2015

Hello Chad,

One other thing you can try is to use an even simpler similarity metric. For unimodal registration you can try the mean squares metric. It is simpler than correlation, but the assumption on the data becomes stricter (intensities haven’t changed vs. a linear change which is what the correlation is accommodating).

Possibly this will provide some speedup.
             Ziv

From: Chadwick Rothenberg <chadrothenberg at gmail.com<mailto:chadrothenberg at gmail.com>>
Date: Wednesday, August 26, 2015 at 11:16 AM
To: "Lowekamp, Bradley (NIH/NLM/LHC) [C]" <blowekamp at mail.nih.gov<mailto:blowekamp at mail.nih.gov>>
Cc: "community at itk.org<mailto:community at itk.org>" <community at itk.org<mailto:community at itk.org>>
Subject: Re: [ITK] b-spline registration performance

Hello,

Thank you for the helpful replies.

For the metric, I am using correlation since it's unimodal registration, and I have 32 threads (16 physical cores total with 2 CPUs, 8 cores on each).

Also, I've heard that the interpolator can affect the registration performance, and I'm currently trying out different ones (using linear for default).

For the registration initiation, the Python (SimpleITK) process's CPU % goes up all the way for couple minutes, and then it drops—I only see 1~3% activity (virtually no activity) and no change in memory. And this period seems to be correlated with the image size and also the mesh size for b-spline transformation—if I use a large number of nodes for the mesh, it can even take up to couple hours.

Is this a known issue? or Am I doing something wrong?

Thanks!

Regards,
Chad

On Wed, Aug 26, 2015 at 9:52 AM, Bradley Lowekamp <blowekamp at mail.nih.gov<mailto:blowekamp at mail.nih.gov>> wrote:
Hello,

The obvious thing to do is try to compute less. Use less pixels, and less samples ( as Matt already suggested ).

What the size of you image (3000x2500x100) and an initial BSpline mesh size of (25x25x10) you may want to run the BinShrink filter with 10x10x2 to reduce the resolution of the image for the first pass with the low resolution mesh. Still use multi-scale and only a percentage of the pixels for the metric. Also note how long it take the registration to start, before the iterations start.

Then you can run another registration with a higher resolution mesh and image. You likely still don't need to full resolution image.

What metric are you using? It may be worth profiling the effect of the number of threads for the metric you are using.

HTH,
Brad

On Aug 25, 2015, at 10:51 PM, Matt McCormick <matt.mccormick at kitware.com<mailto:matt.mccormick at kitware.com>> wrote:

> Hi Chad,
>
>> I'm new to non-rigid image registration and ITK, and I've been using
>> SimpleITK to perform b-spline registrations.
>
> Welcome to ITK!
>
>
>> I am working with relatively large images (pixels, x: 3000, y: 2500, z: 100)
>> with dense information (microscopy images), and I'm quite frustrated with
>> the speed / computation time.
>>
>> I'm following
>> (https://github.com/SimpleITK/SimpleITK/blob/master/Examples/ImageRegistrationMethodBSpline2.py)
>> except that I'm using (25, 25, 10) mesh (ideally higher numbers if
>> feasible), correlation for metrics (I'm working with unimodal), and using
>> down-sampled images with multi-resolution registration (12x smaller, 6x
>> smaller). With two E5 2687w processors, the Python process (the SimpleITK)
>> takes about 70~80% CPU. Ideally I'd like to use at least (40, 40, 20) mesh.
>>
>> 1. Will I gain any performance by using ITK instead of SimpleITK?
>
> If you are using the same approach, there will effectively be no
> performance difference.
>
>
>> 2. What advice could you give me to improve the b-spline registration speed
>> (both in general and specifically in SimpleITK)?
>
> Get the registration working well with the large image when densely
> sampling the images for metric computation.  Then, progressively
> decimate the metric sampling [1] until registration performance
> declines.  Increase the sampling percentage again with an additional
> safety factor.
>
> Hope this helps,
> Matt
>
>
> [1] http://www.itk.org/SimpleITKDoxygen/html/classitk_1_1simple_1_1ImageRegistrationMethod.html#adca6e03c04216fca8ba0d90d84cb9600
> _______________________________________________
> Community mailing list
> Community at itk.org<mailto:Community at itk.org>
> http://public.kitware.com/mailman/listinfo/community

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/community/attachments/20150826/c85d4195/attachment-0001.html>