[Insight-users] MI Registration example translation parameters

[Lydia Ng]

> 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.

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.

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.

- Lydia

> -----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
>=20
> Hi David,
>=20
> The origin of the physical coordinate system
> for the volumes should be taken into account
> during the registration process.
>=20
> Your analysis looks right. It makes sense to
> first discount the relative distance between
> the image centers.
>=20
> In general, simply creating a diagram of the
> images in a common coordinate system in physical
> space should clarify the discrepancy.
>=20
> 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.
>=20
> --
>=20
> If the resampled images are not aligned correctly,
> then we could suspect that the registration method
> didn't converge as expected.
>=20
> ---
>=20
> 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.
>=20
>=20
>=20
>    Luis
>=20
>=20
> ---------------------
> 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
> >
>=20
>=20
>=20
>=20
> _______________________________________________
> Insight-users mailing list
> Insight-users@public.kitware.com
> http://public.kitware.com/mailman/listinfo/insight-users