[Insight-users] Registration of Slices

Luis Ibanez luis.ibanez at kitware.com
Sun Sep 12 14:49:22 EDT 2010


Hi Shekhar,

Thanks for the detailed description of what you are doing.

Please see comments below.

-----------------------------------------------------------------------------------
On Mon, Sep 6, 2010 at 10:36 PM, Shekhar Chandra <Shekhar.Chandra at monash.edu
> wrote:

>  Hi Everyone,
>
> I'm a VTK user who is new to ITK. In my current project I have to register
> a stack or series of Micro CT images, which will be used to reconstruct some
> biological samples.
>
> Via ITK I have worked out how to load the series (using the ImageSeries
> class, Multi-page TIFFs or MRC files). Traverse and filter (if necessary)
> the slices (using ImageSliceConstIteratorWithIndex and
> JoinSeriesImageFilter, as well as the itkSliceBySliceImageFilter). I put
> some of this on my blog for reference for those that are interested.
> <http://l3mmings.blogspot.com/2010/08/slices-stacks-and-itk.html>
>
>

Thanks for posting the code in your blog.
This is very helpful.



> The problem I have is that registering the slices give me barely adequate
> results. I went about it by using the Multi-res example and Software Guide.
>
>
What is the size (in pixels) of these images ?

Depending on the size, you may or may not need
to do multi-resolution.



> I make the first slice the fixed image and treat the next slice as the
> moving image. I transform/resample the moving image after registering it and
> make it the next fixed image. The next slice is then the moving image. I
> realise that the error in registration propagates using this method. Is this
> the best way to register slices?
>
>

This is a commonly used method.
You are right in that the registration error will propagate,
and that, therefore, a subsequent correction may be needed.
We probably should go back to this point once we manage
to register your slices (pair-wise).



> On one post, it was suggested that one could use a sliding window (e.g.
> register slice before and after with fixed slice), but it was not mentioned
> how to do this. Has someone solved this problem or encountered it?
>
> I know the parameters for registration are data dependent and have to be
> found. But when exploring a metric with a slice (as per Exploring a Metric
> example), it takes a while to compute even for -50 to 50 pixel translations
> for small images (300x300, few minutes for MeanSquares on a Core2duo with
> Optimised Registration methods). Is this normal?
>
>
No way   :-)

The metric computation between two images of that size
should be  should be very fast.  In my laptop (a dual core
2.8Ghz) it takes 7 milliseconds to evaluate the matrix with
images of similar size.

Doing this for a grid of 50x50 positions should take then
about 20 seconds.

Please make sure that you are compiling ITK for Release
mode, and that both of your cores are being used at
run time.

BTW: What version of ITK are you using ?



> Finally, what is the best way to do very coarse alignment in ITK? Center of
> Gravity sounds good, but it has rotations (because of the
> CenteredRigid2DTransform) and I do not need rotations.
>
>
You could use the CenteredTransformInitializer with
a Translation 2D transform. Then use the resulting
translation parameters to initialize the transform:
CenteredRigid2DTransform that you are using.


BTW: You should not use this transform.
Instead, the Rigid2DTransform is a more
modern way of performing this registration.

The difference is that the CenteredRigid2DTransform
attempts to fine tune the center of rotation at the
same time that it optimizes the translation and rotation.

The Rigid2DTransform, on the other hand, only
optimizes the Translation and Rotation parameters.


Searching the web has not yielded any further help. Any suggestion or advice
> would be greatly appreciated.
>
>

The common suspects of registraiton failure are:

1) Poor initialization
2) Poor (or no) setting of the Optimizer Parameter Scale.
3) Poor settings of the optimizer step lenght

---

The case (1) can be examined by running the
registration for Zero iterations, or by simply
taking the initialized transform and using it
to resample the moving image, without running
the registration at all.

If the image looks roughly aligned, then you
can exonerate (1).

----

The case (2) is quite likely to blame here, since
the Rigid2DTransform combines rotation and
translation parameters.

The scale for translation is in the range -100,100,
while the scale of ration is in the range  -0.5,0.5,
(because the units are Radians).

It is therefore, crucial to scale this parameters,
as illustrated in many examples.

Look for the line:

     optimizer->SetScales( optimizerScales );

----

The case (3) can be examined by looking at the
output of the array of parameters at every iteration.
You must use a Observer in order to print out this
values.  Most of the registration examples show
how to do this.

If the values of the transform have dramatic
changes between consecutive iterations,
that will be an indication that the optimizer
step length (or equivalent parameters) are
too aggressive.



      Regards,


             Luis


------------------------------------------------------------------

> Cheers
> Shakes
>
> _____________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Kitware offers ITK Training Courses, for more information visit:
> http://www.kitware.com/products/protraining.html
>
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.itk.org/mailman/listinfo/insight-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-users/attachments/20100912/a2e53ba3/attachment-0001.htm>


More information about the Insight-users mailing list