[Insight-users] MI Registration example translation parameters
Lydia Ng
lng@insightful.com
Mon, 24 Mar 2003 10:17:00 -0800
Hi David,
Remember that transform used in registration is the inverse to the one
people use to think of mathematically.
In registration typically the inverse transform is estimated. Inverse
mapping have many advantages over forward mapping (e.g. you don't get
holes).
Take your example, your fixed is MR and your moving PET.
If you only have translation, points in the fixed and moving spaces is
related such that
Point_in_moving_space(PET) =3D Point_in_fixed_space(MR) + translation
The registration gave you a translation of 86mm in the Z direction.
Say that you only have a translation in the Z direction, then
Zposition_of_PET =3D Zposition_of_MR + 86mm
Thus,
Zposition_of_MR =3D Zposition_of_PET - 86mm
Which is what you expect. Does this help?
- Lydia
> -----Original Message-----
> From: David Wikler [mailto:dwikler@ulb.ac.be]
> Sent: Monday, March 24, 2003 9:21 AM
> To: Lydia Ng
> Cc: insight-users@public.kitware.com; luis.ibanez@kitware.com
> Subject: [Insight-users] MI Registration example translation
parameters
>=20
> Dear Lydia,
>=20
> You are right, I did it again and found the right results though I
still
> have a problem with orientation.
> My PET volume covers all the Brain from base to top.
> My MRI volume covers only the base of the brain.
> Both brain base slice levels correspond quite well.
>=20
> My Z orientation is Head to Feet.
>=20
> With these information, I drawed physical space diagrams as advised by
> Luis and things clear up quite well.
> I get
> for MRI: a Z range from 0 to 50*1.26=3D63
> for PET: a Z range from 0 to 63*2.42=3D152.5 where
>=20
> As Z orientation is Head to Feet and as brain base slice levels do
> correspond approximately, PET maximum physical coordinate (152.5)
should
> be transformed by the overall translation to MR maximum physical
> coordinate (63).
>=20
> And effectively PET_Zmax-Toverall_Z =3D 152.5-86.6 is approximately 63
> except that the reported Toverall does not specify -86.6 but 86.6
>=20
> Could it be that the volumes orientations are changed somewhere in the
> reading process or the transforms or did I miss some point ?
>=20
> Thank you for your help
>=20
> David
>=20
>=20
> >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]
> >[1,] 256
> >[2,] 256
> >[3,] 50
> >> FixedSpacing
> > [,1]
> >[1,] 1.05
> >[2,] 1.05
> >[3,] 1.30
> >> # Your moving image is PET with
> >MovingSize
> > [,1]
> >[1,] 128
> >[2,] 128
> >[3,] 63
> >> MovingSpacing
> > [,1]
> >[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]
> >[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]
> >[1,] 163.195
> >[2,] 163.195
> >[3,] 74.400
> >> #
> ># Your overall rotation and translation is
> >#
> >ROverall
> > [,1] [,2] [,3]
> >[1,] 0.9998680 -0.01443690 0.00750628
> >[2,] 0.0144862 0.99987400 -0.00655476
> >[3,] -0.0074107 0.00666263 0.99995000
> >> TOverall
> > [,1]
> >[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,
> >Rdesired =3D ROverall
> >> Rdesired
> > [,1] [,2] [,3]
> >[1,] 0.9998680 -0.01443690 0.00750628
> >[2,] 0.0144862 0.99987400 -0.00655476
> >[3,] -0.0074107 0.00666263 0.99995000
> >>
> >#
> ># And,
> >Tdesired =3D TOverall + (Rdesired %*% FixedCenter) - MovingCenter
> >> Tdesired
> > [,1]
> >[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
> >>
> >>
> >> Dear Lydia,
> >>
> >> Have you had a chance to have a look at my answer and
> >> questions to your latest email ?
> >>
> >> Thank you.
> >>
> >> David
> >>
> >> Dear Lydia,
> >>
> >> 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
> >> 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.
> >> The results you sent to me (20) is also not compatible
> >> with this estimation.
> >>
> >> On the other hand I looked at the final parameters you
> >> mentionned with quartenion rotation and translation
> >> parameters and there, it seems that these numbers match
> >> my a priori knowledge of the translation:
> >>
> >> Final parameters: [-0.00330447, -0.00372939, -0.00723108,
> >> 0.999961, 6.2419, 4.14018, 43.1871]
> >>
> >> 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
> >>
> >> Could you explain the 3D term to me and help me find out
> >> the relation between the Final parameters and the Overall transform
> >> parameters ?
> >>
> >> Thanks again for your help
> >>
> >> David
> >>
> >>
> >> >Dear David,
> >> >
> >> >--------------------
> >> >In answer to the first question, since the simple
> >> application only reads
> >> >in raw and does not ask the user for the image origin - you
> >> 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
> >> 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
> >> ((128-1)*2.57,(128-1)*2.57,(63-1)*2.4)/2
> >> >MR_volume_center(physical) =3D
> >> ((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)
> >> >
> >> >-----------------------
> >> >By the way I think the program also dumped the last/final
> >> 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
> >> >>
> >> >> Dear Lydia,
> >> >>
> >> >> >Actually, the MultiResMIRegistration application actually
> >> doesn't use
> >> >> >image origin information. The first preprocessing step it
> >> 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.
> >> Additionally any
> >> >> >rotation is with respect to the center of the image.
> >> >> >
> >> >>
> >> >> 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 ?
> >> >>
> >> >> >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
> >> position of the
> >> >> >center of rotation comes into play and hence the output
> >> translation
> >> >is a
> >> >> >mixture of your introduced translation and the center of
rotation.
> >> >>
> >> >> Could we formalize it with a formula to add the rotation
> >> contribution
> >> >> to the translations numbers ?
> >> >> using
> >> >> 1. the rotation matrix
> >> >> 2. the volume center coordinates
> >> >>
> >> >> We would end with someting like
> >> >>
> >> >> T(mm) =3D T(physical) - D - d
> >> >>
> >> >> where D =3D
> >> (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)
> >> >>
> >> >> [d would be zero for a null rotation whicj makes sense]
> >> >>
> >> >> For my case, I would end with
> >> >>
> >> >> 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
> >> >>
> >> >> with dx =3D 0.6885, dy =3D -0.7060, dz =3D 0.0495
> >> >>
> >> >> and I would end with a translation of
> >> >>
> >> >> (6.55, 1,766, 42.81)
> >> >>
> >> >> 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.
> >> >>
> >> >> Thank you all.
> >> >>
> >> >> David
> >> >>
> >> >> >> -----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
> >> 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
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >> 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