[Insight-users] MI Registration example translation parameters
David Wikler
dwikler@ulb.ac.be
Tue, 18 Mar 2003 14:52:54 +0100 (MET)
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) = ((128-1)*2.57,(128-1)*2.57,(63-1)*2.4)/2
>MR_volume_center(physical) = ((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)) = R * (X_MR - MR_center(physical)) + T
>
>X_PET = R(X_MR) - R(MR_center(physical)) + PET_center(physical) + T
>
>
>So the overall parameters are:
>
>R_overall = R
>T_overall = - R(MR_center(physical)) + PET_center(physical) + T
>
>>From your comment, it seems like it is T that you want
>T = 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) = T(physical) - D - d
>>
>> where D = (PET_volume_center(physical)-MR_volume_center(physical))/2
>> which is the relative distance between the centers of images
>> where d = 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 = 43.5 mm - dz
>> For Y: 31.1387 - (128*2.57- 256*1.05)/2 - dy = 1.06 mm - dy
>> For X: 36.6828 - (128*2.57- 256*1.05)/2 - dx = 6.6 mm - dx
>>
>> with dx = 0.6885, dy = -0.7060, dz = 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) = slicethickness *( Tz(physical) - D)
>> >> > and
>> >> > Tz(mm) = Tz(physical) - D
>> >> >
>> >> > where D =
>(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 = 43.5 mm
>> >> > For Y: 31.1387 - (128*2.57- 256*1.05)/2 = 1.06 mm
>> >> > For X: 36.6828 - (128*2.57- 256*1.05)/2 = 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
>
>
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