[Insight-users] MI Registration example translation parameters
Lydia Ng
lng@insightful.com
Thu, 20 Mar 2003 12:08:12 -0800
Dear David,
So I stuck all the numbers you gave me into my equations in SPlus and =
this is what I get:
> # Your fixed image is MR with
FixedSize
[,1]=20
[1,] 256
[2,] 256
[3,] 50
> FixedSpacing
[,1]=20
[1,] 1.05
[2,] 1.05
[3,] 1.30
> # Your moving image is PET with
MovingSize
[,1]=20
[1,] 128
[2,] 128
[3,] 63
> MovingSpacing
[,1]=20
[1,] 2.57
[2,] 2.57
[3,] 2.40
> # The program moves the fixed image origin to the image center
FixedCenter =3D ((FixedSize - 1) * FixedSpacing)/2
> FixedCenter
[,1]=20
[1,] 133.875
[2,] 133.875
[3,] 31.850
> # The program moves the moving image origin to the image center
MovingCenter =3D ((MovingSize - 1) * MovingSpacing)/2
> MovingCenter
[,1]=20
[1,] 163.195
[2,] 163.195
[3,] 74.400
> #
# Your overall rotation and translation is
#
ROverall
[,1] [,2] [,3]=20
[1,] 0.9998680 -0.01443690 0.00750628
[2,] 0.0144862 0.99987400 -0.00655476
[3,] -0.0074107 0.00666263 0.99995000
> TOverall
[,1]=20
[1,] 36.6828
[2,] 31.1387
[3,] 86.6143
> #
# The relationship between a FixedPoint and MovingPoint is given by:
#
# MovingPoint =3D ROverall %*% FixedPoint + TOverall
#
# What you want is Rdesired and Tdesired such that:
#
# (MovingPoint - MovingCenter) =3D Rdesired %*% (FixedPoint - =
FixedCenter) + Tdesired
# MovingPoint =3D Rdesired %*% FixedPoint - Rdesired %*% FixedCenter + =
Tdesired + MovingCenter
#
# Therefore,=20
Rdesired =3D ROverall
> Rdesired
[,1] [,2] [,3]=20
[1,] 0.9998680 -0.01443690 0.00750628
[2,] 0.0144862 0.99987400 -0.00655476
[3,] -0.0074107 0.00666263 0.99995000
>=20
#
# And,=20
Tdesired =3D TOverall + (Rdesired %*% FixedCenter) - MovingCenter
> Tdesired
[,1]=20
[1,] 5.651464
[2,] 3.532403
[3,] 43.962560
---------------------------
So I get (5.6, 3.5, 43.9) which seems compatible to what you expect.
Are you sure about your Z spacing in your computation?
- Lydia
> -----Original Message-----
> From: David Wikler [mailto:dwikler@ulb.ac.be]
> Sent: Thursday, March 20, 2003 8:48 AM
> To: Lydia Ng
> Subject: fwd:[Insight-users] MI Registration example translation
> parameters
>=20
>=20
> Dear Lydia,
>=20
> Have you had a chance to have a look at my answer and=20
> questions to your latest email ?
>=20
> Thank you.
>=20
> David
>=20
> Dear Lydia,
>=20
> I did compute the translation parameters I am looking
> for with your math ormulation bit I don't get the same
> result, I get (5.6, 3.5, 88) which is not compatible=20
> with Z translation I know to be around 40 mm.
> But it could be that I misinterpret your formulas as
> I am not sure of what means the '3D' term you use.=20
> The results you sent to me (20) is also not compatible=20
> with this estimation.=20
>=20
> On the other hand I looked at the final parameters you
> mentionned with quartenion rotation and translation=20
> parameters and there, it seems that these numbers match
> my a priori knowledge of the translation:
>=20
> Final parameters: [-0.00330447, -0.00372939, -0.00723108,=20
> 0.999961, 6.2419, 4.14018, 43.1871]
>=20
> Overall transform matrix:=20
> 0.999868 -0.0144369 0.00750628=20
> 0.0144862 0.999874 -0.00655476=20
> -0.0074107 0.00666263 0.99995=20
>=20
> Overall transform offset:=20
> 36.6828 31.1387 86.6143 =20
>=20
> Could you explain the 3D term to me and help me find out
> the relation between the Final parameters and the Overall transform=20
> parameters ?
>=20
> Thanks again for your help
>=20
> David
>=20
>=20
> >Dear David,
> >
> >--------------------
> >In answer to the first question, since the simple=20
> application only reads
> >in raw and does not ask the user for the image origin - you=20
> can't really
> >tweak the origin externally. You could of course tweak it inside the
> >code - but currently it only uses the image size to place=20
> the origin in
> >the center of the images.
> >
> >----------------------
> >This is how I think of the mathematics of what is going on in the
> >program. Let,
> >
> >PET_volume_center(physical) =3D=20
> ((128-1)*2.57,(128-1)*2.57,(63-1)*2.4)/2
> >MR_volume_center(physical) =3D=20
> ((256-1)*1.05,(256-1)*1.05,(50-1)*1.3)/2
> >
> >The registration tries to find the best R and T such that
> >
> >(X_PET - PET_center(physical)) =3D R * (X_MR - MR_center(physical)) + =
T
> >
> >X_PET =3D R(X_MR) - R(MR_center(physical)) + PET_center(physical) + T
> >
> >
> >So the overall parameters are:
> >
> >R_overall =3D R
> >T_overall =3D - R(MR_center(physical)) + PET_center(physical) + T
> >
> >>From your comment, it seems like it is T that you want
> >T =3D T_overall + R(MR_center(physical)) - PET_center(physical)=20
> >
> >-----------------------
> >By the way I think the program also dumped the last/final=20
> parameters -
> >what did you get for those? There should be 7 numbers, the first four
> >represents a unit quaternion and the last 3 numbers should be "T".
> >
> >- Lydia
> >
> >
> >> -----Original Message-----
> >> From: David Wikler [mailto:dwikler@ulb.ac.be]
> >> Sent: Friday, March 14, 2003 1:16 AM
> >> To: Lydia Ng
> >> Cc: insight-users@public.kitware.com; luis.ibanez@kitware.com
> >> Subject: RE: [Insight-users] MI Registration example translation
> >> parameters
> >>=20
> >> Dear Lydia,
> >>=20
> >> >Actually, the MultiResMIRegistration application actually=20
> doesn't use
> >> >image origin information. The first preprocessing step it=20
> does is to
> >> >artificially place the origin in the center of each of the images.
> >This
> >> >is equivalent to align the images at their center.=20
> Additionally any
> >> >rotation is with respect to the center of the image.
> >> >
> >>=20
> >> I have seen this in the code and that was the substrate for my
> >> correction of the physical translation parameters using the
> >> relative distance between the image centers. Does your remark
> >> make this computation irrelevant or just makes Luis proposal
> >> to tweak the original images origins impossible with this code ?
> >>=20
> >> >You should also note that the "final quaternion parameters" are
> >respect
> >> >to the origin at the image center - but the display of the overall
> >> >matrix and translation is reposition so that the image origin for
> >both
> >> >images is at the [0,0,0] pixel.
> >> >
> >> >Since the output matrix has some rotation in it - the=20
> position of the
> >> >center of rotation comes into play and hence the output=20
> translation
> >is a
> >> >mixture of your introduced translation and the center of rotation.
> >>=20
> >> Could we formalize it with a formula to add the rotation=20
> contribution
> >> to the translations numbers ?
> >> using
> >> 1. the rotation matrix
> >> 2. the volume center coordinates
> >>=20
> >> We would end with someting like
> >>=20
> >> T(mm) =3D T(physical) - D - d
> >>=20
> >> where D =3D=20
> (PET_volume_center(physical)-MR_volume_center(physical))/2
> >> which is the relative distance between the centers of images
> >> where d =3D PET_volume_center(physical) - RotationMatrix *
> >> PET_volume_center(physical)
> >>=20
> >> [d would be zero for a null rotation whicj makes sense]
> >>=20
> >> For my case, I would end with
> >>=20
> >> For Z: 86.6143 - (63*2.4- 50*1.3)/2 - dz =3D 43.5 mm - dz
> >> For Y: 31.1387 - (128*2.57- 256*1.05)/2 - dy =3D 1.06 mm - dy
> >> For X: 36.6828 - (128*2.57- 256*1.05)/2 - dx =3D 6.6 mm - dx
> >>=20
> >> with dx =3D 0.6885, dy =3D -0.7060, dz =3D 0.0495
> >>=20
> >> and I would end with a translation of
> >>=20
> >> (6.55, 1,766, 42.81)
> >>=20
> >> which still makes sense according to my visual evaluation but as
> >> my rotation quasi null, I can't be 100% sure of my formulas.
> >> I don't currently have a dataset with more rotation to check this
> >> better. Can you tell me whether you think my math development
> >> looks allright according to your comments.
> >>=20
> >> Thank you all.
> >>=20
> >> David
> >>=20
> >> >> -----Original Message-----
> >> >> From: Luis Ibanez [mailto:luis.ibanez@kitware.com]
> >> >> Sent: Thursday, March 13, 2003 11:01 AM
> >> >> To: David Wikler
> >> >> Cc: insight-users@public.kitware.com
> >> >> Subject: Re: [Insight-users] MI Registration example translation
> >> >> parameters
> >> >>
> >> >> Hi David,
> >> >>
> >> >> The origin of the physical coordinate system
> >> >> for the volumes should be taken into account
> >> >> during the registration process.
> >> >>
> >> >> Your analysis looks right. It makes sense to
> >> >> first discount the relative distance between
> >> >> the image centers.
> >> >>
> >> >> In general, simply creating a diagram of the
> >> >> images in a common coordinate system in physical
> >> >> space should clarify the discrepancy.
> >> >>
> >> >> In any case, if the resampled images are aligned
> >> >> correctly, you can be confident that the only
> >> >> difficulty is the intrepretation of the transform
> >> >> in a common coordinate system.
> >> >>
> >> >> --
> >> >>
> >> >> If the resampled images are not aligned correctly,
> >> >> then we could suspect that the registration method
> >> >> didn't converge as expected.
> >> >>
> >> >> ---
> >> >>
> >> >> An easy and quick test is to tweak the origin
> >> >> values of your images and verify that the
> >> >> changes are reflected in the final registration.
> >> >> For example, if you add (13,17,19) to x,y,z of one
> >> >> of the images origin, the registration should
> >> >> report a variation of (13,17,19) in the translation
> >> >> offset.
> >> >>
> >> >>
> >> >>
> >> >> Luis
> >> >>
> >> >>
> >> >> ---------------------
> >> >> David Wikler wrote:
> >> >> > Dear Luis,
> >> >> >
> >> >> > I think your comments helped me to understand
> >> >> > my numbers a bit better. I focused on my numeral (3)
> >> >> >
> >> >> >
> >> >> >>3. The registration result I get with datasets oriented
> >> >> >>Head to Feet along the z axis is
> >> >> >>
> >> >> >>Overall transform matrix:
> >> >> >>0.999868 -0.0144369 0.00750628
> >> >> >>0.0144862 0.999874 -0.00655476
> >> >> >>-0.0074107 0.00666263 0.99995
> >> >> >>
> >> >> >>Overall transform offset:
> >> >> >>36.6828 31.1387 86.6143
> >> >> >
> >> >> >
> >> >> > What I actually did was flip the images along the Z axis
> >> >> > so the head goes to feet and vice-versa. I actually also
> >> >> > did flip Anterio-posterior but this is not relevant for
> >> >> > the following.
> >> >> >
> >> >> > I said to you that I estimated the Z translation to
> >> >> > about 40.8 mm. Actually I can also estimate X and Y
> >> >> > translation being of the order of less than 10mm.
> >> >> >
> >> >> > After reading your comments about physical space vs
> >> >> > voxels space, I imagined the dicrepancy could come
> >> >> > from the centers of volumes translations when going
> >> >> > from voxel space to physical space.
> >> >> > We could then write
> >> >> >
> >> >> > Tz(slices) =3D slicethickness *( Tz(physical) - D)
> >> >> > and
> >> >> > Tz(mm) =3D Tz(physical) - D
> >> >> >
> >> >> > where D =3D
> >(PET_volume_Zcenter(physical)-MR_volume_Zcenter(physical))
> >> >/2
> >> >> > which is the translation in physical space between=20
> volume centers
> >> >> > (for Z coordinate)
> >> >> >
> >> >> > In my case:
> >> >> >
> >> >> > For Z: 86.6143 - (63*2.4- 50*1.3)/2 =3D 43.5 mm
> >> >> > For Y: 31.1387 - (128*2.57- 256*1.05)/2 =3D 1.06 mm
> >> >> > For X: 36.6828 - (128*2.57- 256*1.05)/2 =3D 6.6 mm
> >> >> >
> >> >> > which is now compatible with my estimation.
> >> >> > I still have got to check with other cases but
> >> >> > I think it could be the solution, what is your
> >> >> > impression ?
> >> >> >
> >> >> > Thank a lot for your quick help.
> >> >> >
> >> >> > David
> >> >> >
> >> >> > David Wikler, Ir
> >> >> > ULB - Erasme Hospital - PET Scan
> >> >> > 808 route de Lennik - B1070 Brussels - Belgium
> >> >> > Phone: 32 2 5556603 - Fax: 32 25556631
> >> >> > Email: dwikler@ulb.ac.be
> >> >> > _______________________________________________
> >> >> > Insight-users mailing list
> >> >> > Insight-users@public.kitware.com
> >> >> > http://public.kitware.com/mailman/listinfo/insight-users
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> _______________________________________________
> >> >> Insight-users mailing list
> >> >> Insight-users@public.kitware.com
> >> >> http://public.kitware.com/mailman/listinfo/insight-users
> >> >
> >> >
> >>=20
> >>=20
> >> David Wikler, Ir
> >> ULB - Erasme Hospital - PET Scan
> >> 808 route de Lennik - B1070 Brussels - Belgium
> >> Phone: 32 2 5556603 - Fax: 32 25556631
> >> Email: dwikler@ulb.ac.be
> >_______________________________________________
> >Insight-users mailing list
> >Insight-users@public.kitware.com
> >http://public.kitware.com/mailman/listinfo/insight-users
> >
> >
>=20
>=20
>=20