[Insight-users] Re: [Insight-developers] Changes in itkAffineTransform.txx from 181 to 201

[Stephen R. Aylward]

Hi,   ...long email warning....

Thanks for catching this!   This was fixed several weeks ago, and the 
fix is available in the current CVS version of ITK.

Actually - this illustrates a dilemma that exists within centered 
transforms as implemented in ITK.   I'd like to explain it a bit to ITK 
users and developers...

The story is as follows:
A centered affine transform of a point x, given a rotation matrix R, a 
center point c, and a translation vector t, can be defined to produce 
the point y as follows:
y = R(x-c) + t

This equation can be re-written in terms of an offset o as
y = Rx + o

Offset is thereby a function of rotation, translation, and center.

Some itk transforms previously optimized offset as a parameter.  Other 
transforms optimized translation as a parameter.   With an explicit 
center of rotation, there are clear advantages to optimizing translation 
instead of offset.

The dilemma is:  If you provide an API that allows a user to set 
rotation, translation, center, and offset; then when someone changes 
rotation, what should be done to translation and offset in order to 
maintain their relationship (that is a function of rotation)?

Previously, related to what you've discovered, inconsistencies would 
occur in which an instance of a transform was actually representing two 
different transforms (one using translation and one using offset and 
each producing different results!).

In the current CVS version, the transform classes are much improved and 
TRANSLATION is the dominant parameter over offset.   So, updates to 
rotation and center induce updates to offset in order to maintain the 
value assigned to translation, and optimizers update translation 
directly.   Rotations, such as in the Rotate3D function, update offset, 
not translation.

So, perhaps you can do a cvs update, and let us know if this fixes your 
problem.  I hope this email clarifies the dilemma, and I hope you agree 
with our choice and appreciate that it is now consistently implemented.

Thanks,
Stephen

Ashish Poddar wrote:
> Hi,
> I was running a program that was working fine in ITK 1.8.1. Recently I
> installed ITK 2.0.1 and it started behaving in unexpected way...
> 
> What I was doing : Rotating in 3D using Centered Affine Transform and
> computing the metric to find an initial estimate for the angle
> 
> 
> for (double angle=initangle; angle<=finalangle; angle+=stepsize)
> {
>      double rot_angle = (angle) * PI / 180; // radians
>      transform->SetIdentity();
>      transform->SetCenter( center );
>      transform->SetTranslation(trans);
>      transform->Rotate3D( axis, rot_angle );
> // some processing
> }
> 
> in the new version it started giving me weird error saying image is
> out of range!! so metric cant be computed ... I debugged it a bit to
> find the cause... Rotate3D function was somehow assigning some weird
> values for the translation !!
> 
> I traced the source of this error back to itkAffineTransform.txx...
> and there was surely a change in the code
> 
> From:
>   ......
>   // Compose rotation matrix with the existing matrix
>   if (pre) 
>     {
>     m_Matrix = m_Matrix * trans;
>     }
>   else 
>     {
>     m_Matrix = trans * m_Matrix;
>     m_Offset = trans * m_Offset;
>     }
>   RecomputeInverse();
>   return;
> }
> 
> 
> To:
>   ......
>   // Compose rotation matrix with the existing matrix
>   if (pre) 
>     {
>     m_Matrix = m_Matrix * trans;
>     }
>   else 
>     {
>     m_Matrix = trans * m_Matrix;
>     m_Offset = trans * m_Offset;
>     }
>   this->ComputeTranslation();
>   m_MatrixMTime.Modified();
>   this->Modified();
>   return;
> }
> 
> 
> Why is Translation being computed in Rotate3D function?? is it by
> design or some coverup for some other bug??
> 
> any idea on this would be highly appreciated 
> 
> with regards,
> Ashish.
> 

-- 
===========================================================
Dr. Stephen R. Aylward
Associate Professor of Radiology
Adjunct Associate Professor of Computer Science and Surgery
http://caddlab.rad.unc.edu
aylward at unc.edu
(919) 966-9695