[Insight-developers] No-Bug in CenteredRigid2DTransform
Luis Ibanez
luis.ibanez@kitware.com
Fri, 24 Jan 2003 11:29:27 -0500
Jim,
===============================================
Miller, James V (Research) wrote:
> Luis,
>
> I understand how the transform is intended to work (though the
> documentation still has some cut and past errors from some other
> transform class). I don't want to specify the translation as the
> null vector since I need this image to be placed back in the original
> coordinates after rotation. Which is after all what this particular
> transformation is for, right?
>
The transform will put the image back in the original coordinates
after rotation. You get this for free, there is no need for you
to specify this movement as a translation.
The translation parameter of this transform is in addition to the
process of going back and forth to the origin. You don't need this
additional translation for what you are doing.
>
> I still question whether the math is correct. I haven't looked at
> the Jacobian math yet.
>
The Jacobian is consistent with the description above.
The transform is working fine for the registration examples
that we have in the SoftwareGuide.
>
> For the bigger picture:
> I am trying to gain some insight into the various image to image
> metrics. So I have a program where I take an image and compute
> a specified metric between the image and a transformed version of
> the image. In one case, I just translate the image around and
> measure the metric. In another case, I pin the centers and spin
> the image around its center and compute the metric to the unspun
> image.
>
This is great !
I wonder if we should provide a convenient mechanism for users
to do this. It sould be something like a filter whose inputs
are:
two images + one transform
and the output is a ND image, where N is the number of parameters
of the transform.
This output image is in fact the plot of the parameter space where
we run the optimizers during a registration process.
Plotting this image is probably the first thing people should do
when facing a registration problem. Once being familiar witht the
chararcteristics of this output image, users can better select
an optimization strategy to find the extrema of the ImageMetris
as function of the transform parameters.
This filter shouldn't be too hard to implement. It will be extremely
time consuming but it is something people will run only once in
order to study a Metric+Transform+Imagemodality problem.
>
> It is this latter case, where I am using the CenteredRigid2DTransform.
> I want the image centers to stay aligned, with one image just rotating
> about the center. So I set the center and translation to be same
> value, naming the middle of the image (in mm).
Please do not set the translation, just put the Center of rotation.
Following your own description:
You want to pin the center of rotation and not tranlate the images.
So, specify a null translation and set the Center of rotation to
the center of the image (or any point where you want to rotate around).
Let the transform do this job for you. You are trying to help the
transform as it it were an AffineTransform. In some way the purpose
of this transform is to release you from the burden of having to think
about the tranlations required for changing the center of rotation.
Trust that the transform knows what has to be done in order to switch
the rotation center (that two translations, back and forth). You don't
have to worry about returning the image to the original coordinate
system, the transform does this for you.
>
> Basically, I want to see what the expected area of convergence would
> be for a particular metric under the best possible circumstances.
>
>
That's a great thing to do for the metrics and the transform.
In some way, this should be the recommended first approach for
anybody doing registration. That is, to first get a plot of the
Image metric as function of the transform parameters, for a large
enough range of the parameters. Such a plot is fundamental in
figuring out the characteristics of the cost-function to be
optimized during registration. Is from this plot that we could
talk about noise, capture radius and stability. The only difficulty
is to represent this for transform having more that three parameters
since we deal with a high dimensional function...
Luis
--------------------------------
>
>
>
>
>>-----Original Message-----
>>From: Luis Ibanez [mailto:luis.ibanez@kitware.com]
>>Sent: Friday, January 24, 2003 10:46 AM
>>To: Miller, James V (Research)
>>Cc: Insight-developers (E-mail)
>>Subject: Re: [Insight-developers] Bug in CenteredRigid2DTransform
>>
>>
>>
>>Hi Jim,
>>
>>The CenteredRigid2DTransform do for you both
>>the back and forth translations to the center.
>>
>>The explicit translation parameter is to be
>>applied after the image have been placed back
>>in the original frame.
>>
>>So,
>>If you need just to rotate the image around
>>its center. Set the Translation to a NULL vector.
>>An only specify that the center of rotation is
>>point P and the angle is X
>>
>>The transform in this case will do:
>>
>>1) translate the image from point P to the axis origin
>>2) rotate by angle X
>>3) translate back from axis origin to point P.
>>
>>
>>The current setup of the transform is extremly
>>convenient for registration since it match the
>>way in which we could describe a miss registration
>>in terms of the image center.
>>
>>E.g. if an image is missregistered only by a rotation
>>with respect to the center of the image. We will
>>say that there is a rotation by angle X and that
>>there is no translation at all.
>>
>>I agree with you in that we could have absorbed the
>>second translation with the user-specified translation.
>>That's mathematically correct but probably less
>>intuitive for naive users.
>>
>>
>>
>> Luis
>>
>>
>>
>>--------------------------------------------------
>>
>>Miller, James V (Research) wrote:
>>
>>
>>>I am having trouble using the CenteredRigid2DTransform and
>>>
>>I think there
>>
>>>is a bug in the ComputeMatrixAndOffset() method. This
>>>
>>transform allows
>>
>>>to specify a center of rotation and angle to rotate about
>>>
>>and an amount
>>
>>>to translate after rotation.
>>>
>>>
>>>
>>>For my task at hand, I just want to rotate an image about
>>>
>>its center. So
>>
>>>I specify the center and translation as the same point.
>>>
>>This should
>>
>>>translate the center of the image to the origin, rotate by
>>>
>>the specified
>>
>>>angle and translate the center back to the original position.
>>>
>>>
>>>
>>>The code to compute the offset (final composed translation
>>>
>>component of
>>
>>>the transform) is currently
>>>
>>> offset[0] = tx + sa * cy + ( 1.0 - ca ) * cx;
>>> offset[1] = ty - sa * cx + ( 1.0 - ca ) * cy;
>>>
>>>where ca, sa are the sine and cosine of the angle, cx and
>>>
>>cy are the
>>
>>>center to rotate about, and tx and ty are the final translation.
>>>
>>>
>>>
>>>I think this code should be
>>>
>>>
>>>
>>> offset[0] = tx - ca * cx + sa * cy;
>>> offset[1] = ty - sa * cx - ca * cy;
>>>
>>>note the signs are set such that we translate the origin to
>>>
>>the center
>>
>>>(shift by negative center), rotate, then translate to the specified
>>>position.
>>>
>>>
>>>
>>>Does this make sense?
>>>
>>>
>>>*Jim Miller*
>>>*/_____________________________________/*
>>>/Visualization & Computer Vision//
>>>/GE Research/
>>>/Bldg. KW, Room C218B/
>>>/P.O. Box 8, Schenectady NY 12301/
>>>
>>>//_millerjv@research.ge.com <mailto:millerjv@research.ge.com>_/
>>>
>>>/_james.miller@research.ge.com_/
>>>/(518) 387-4005, Dial Comm: 8*833-4005, /
>>>/Cell: (518) 505-7065, Fax: (518) 387-6981/
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
> _______________________________________________
> Insight-developers mailing list
> Insight-developers@public.kitware.com
> http://public.kitware.com/mailman/listinfo/insight-developers
>
>