[Insight-users] Scaling in Registration
Luis Ibanez
luis.ibanez at kitware.com
Wed Jan 5 15:45:58 EST 2005
Hi Michael,
When you say "smaller" do you mean:
1) The physical extent of the image measured in
millimeters is smaller
OR do you mean:
2) The number of pixels of the image is smaller.
You description lead us to think that you are registering
two images that have different pixel spacing and you are
trying to interpret the scaling in terms of pixels instead
of in terms of millimeters (in the physical world).
Please post to the list the following information for both
the Fixed and Moving images:
1) Number of pixels along each dimension
2) Pixel spacing in millimeters
3) Origin of the image in millimeters
You *MUST* look at the following section of our course on
image registration:
http://www.cs.rpi.edu/courses/spring04/imagereg/lecture07.ppt
and you *MUST* read the following sections
of the ITK Software Guide:
http://www.itk.org/ItkSoftwareGuide.pdf
A) Section 6.7.1, "Geometric Transformations" pdf-pages 199-219
B) Chapter 8. "Registration", pdf-pages 241-340
Regards,
Luis
-----------------------------
Michael Hardisty wrote:
> I am attempting to use a centred affine transform to register two 3D
> volumes. I believe that the registration should be a combination of
> shearing, scaling, rotation and translation. Therefore the Affine
> transform seems like the ideal choice. The problem I am having is that
> when I do the registration I never get proper scaling of the volumes.
> The Image I am registering is smaller than the target image and remains
> smaller after the registration has converged. The other parts of the
> transformation look relatively good, the scaling is the only part of the
> registration that seems totally off. I thought that the scaling might
> be suppressed by the particular metric that I am using
> (MeanSquaresImageToImageMetric), but I am not sure. This leads me to
> several questions:
>
> 1) How do the metrics evaluate when the images have different pixel
> densities? Does it make sense to suggest that by stretching the moving
> image over more target pixels that this could cause a greater metric
> value because more pixels are included? If so which metric is the most
> suited to deal with this problem?
>
> 2) Are there any other parts of the registration process that may
> effect the scaling of the moving image? What other strategies could I
> take to encourage more scaling?
>
> Current Registration Components:
> Metric: MeanSquaresImageToImageMetric
> Interpolator: LinearInterpolateImageFunction
> Optimizer: RegularStepGradientDescentOptimizer
> Transform: CenteredAffineTransform
> Image Types: uCT (pixel type = float)
>
> Thanks
>
More information about the Insight-users
mailing list