No subject

T =3D T_overall + R(MR_center(physical)) - PET_center(physical)=20

-----------------------
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 at ulb.ac.be]
> Sent: Friday, March 14, 2003 1:16 AM
> To: Lydia Ng
> Cc: insight-users at public.kitware.com; luis.ibanez at kitware.com
> Subject: RE: [Insight-users] MI Registration example translation
> parameters
>=20
> Dear Lydia,
>=20
> >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.
> >
>=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 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.
>=20
> 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
>=20
> We would end with someting like
>=20
> T(mm) =3D T(physical) - D - d
>=20
> 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)
>=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 at kitware.com]
> >> Sent: Thursday, March 13, 2003 11:01 AM
> >> To: David Wikler
> >> Cc: insight-users at 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 at ulb.ac.be
> >> > _______________________________________________
> >> > Insight-users mailing list
> >> > Insight-users at public.kitware.com
> >> > http://public.kitware.com/mailman/listinfo/insight-users
> >> >
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> Insight-users mailing list
> >> Insight-users at 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 at ulb.ac.be