Hello,
I was wondering what orientation conventions are used when calculating the affine transformation matrix in register.dat. For an example, I'll use the data from subject 101 of the fsfast tutorial. According to mri_info, the functional volume is in LPS orientation, and the processed anatomical volume (T1.mgz) is in LIA orientation. Does the matrix in register.dat convert from the functional LPS orientation to the anatomical LIA orientation, or does the matrix assume these volumes are already transformed in some other way?
Thanks, Clark
Hi Clark, have you looked at this documentation yet? http://www.freesurfer.net/fswiki/CoordinateSystems?action=AttachFile&do=... doug Clark Fisher wrote:
Hello,
I was wondering what orientation conventions are used when calculating the affine transformation matrix in register.dat. For an example, I'll use the data from subject 101 of the fsfast tutorial. According to mri_info, the functional volume is in LPS orientation, and the processed anatomical volume (T1.mgz) is in LIA orientation. Does the matrix in register.dat convert from the functional LPS orientation to the anatomical LIA orientation, or does the matrix assume these volumes are already transformed in some other way?
Thanks, Clark _______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Hi Doug,
Thanks for pointing me back to that; I had forgotten how much depth it goes into! I have 2 remaining questions:
1) Why is the tkr vox2ras transform sometimes dramatically different from the one in the volume header? For instance, in one of the functional volumes I'm talking about, "mri_info --vox2ras" gives:
-3.42822 0.21499 0.15398 101.74103 -0.24476 -3.27187 -1.19314 135.02863 0.06182 -1.03201 3.81480 -30.98481 0.00000 0.00000 0.00000 1.00000
while "mri_info --vox2ras-tkr" gives:
-3.43750 0.00000 0.00000 110.00000 0.00000 0.00000 4.00000 -70.00000 0.00000 -3.43750 0.00000 110.00000 0.00000 0.00000 0.00000 1.00000
I would understand if the tkr-vox2ras only did flips and 90º rotations to put the data as close to RAS format as possible without having to interpolate, but the orientations produced by those 2 transformations are very different, with the rows and the slices essentially switched. I would guess that it has something to do with this explanation from Slide 5, but I don't quite understand it:
"Field-of-View based – only depends on the identity of columns, rows, and slices, the number of voxels in each dimension, and their sizes. Unrelated to the “true” geometry but is an RAS coordinate system when the volume is “Coronally” sliced, which is the based “conformed” orientation in FreeSurfer."
Any additional clarity you could provide would be appreciated.
2) In Freesurfer XYZ space, why are the volumes centered at (# of voxels)/2? I would think that centering at ((# of voxels) + 1) /2 would put the true center of the volume on the origin.
Thanks again, Clark
On Sep 20, 2011, at 2:14 PM, Douglas N Greve wrote:
Hi Clark, have you looked at this documentation yet? http://www.freesurfer.net/fswiki/CoordinateSystems?action=AttachFile&do=... doug Clark Fisher wrote: Hello,
I was wondering what orientation conventions are used when calculating the affine transformation matrix in register.dat. For an example, I'll use the data from subject 101 of the fsfast tutorial. According to mri_info, the functional volume is in LPS orientation, and the processed anatomical volume (T1.mgz) is in LIA orientation. Does the matrix in register.dat convert from the functional LPS orientation to the anatomical LIA orientation, or does the matrix assume these volumes are already transformed in some other way?
Thanks, Clark _______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
-- Douglas N. Greve, Ph.D. MGH-NMR Center greve@nmr.mgh.harvard.edu Phone Number: 617-724-2358 Fax: 617-726-7422
Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting FileDrop: www.nmr.mgh.harvard.edu/facility/filedrop/index.html
The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail.
Clark Fisher wrote:
Hi Doug,
Thanks for pointing me back to that; I had forgotten how much depth it goes into! I have 2 remaining questions:
- Why is the tkr vox2ras transform sometimes dramatically different
from the one in the volume header? For instance, in one of the functional volumes I'm talking about, "mri_info --vox2ras" gives:
-3.42822 0.21499 0.15398 101.74103 -0.24476 -3.27187 -1.19314 135.02863 0.06182 -1.03201 3.81480 -30.98481 0.00000 0.00000 0.00000 1.00000
while "mri_info --vox2ras-tkr" gives:
-3.43750 0.00000 0.00000 110.00000 0.00000 0.00000 4.00000 -70.00000 0.00000 -3.43750 0.00000 110.00000 0.00000 0.00000 0.00000 1.00000
I would understand if the tkr-vox2ras only did flips and 90º rotations to put the data as close to RAS format as possible without having to interpolate, but the orientations produced by those 2 transformations are very different, with the rows and the slices essentially switched. I would guess that it has something to do with this explanation from Slide 5, but I don't quite understand it:
"Field-of-View based – only depends on the identity of columns, rows, and slices, the number of voxels in each dimension, and their sizes. Unrelated to the “true” geometry but is an RAS coordinate system when the volume is “Coronally” sliced, which is the based “conformed” orientation in FreeSurfer."
Any additional clarity you could provide would be appreciated.
The tkr vox2ras is not related to RAS/LIA/etc and you should not attempt to understand it using these terms. It will always have the same pattern of zeros and non-zeros regardless of the true geometry. Given the number of voxels in each dimension and the voxel size in each dimension, one can write down the tkr vox2ras without knowing anything else above the volume. This unfortunate situation is historical. The true geometry as it relates to the tkr geometry ends up being embedded in the registration matrix. In the end, neither the tkr vox2ras nor the registration matrix are interpretable by themselves (but together they are).
- In Freesurfer XYZ space, why are the volumes centered at (# of
voxels)/2? I would think that centering at ((# of voxels) + 1) /2 would put the true center of the volume on the origin.
You are correct. This is another unfortunate accident of history. doug
Thanks again, Clark
On Sep 20, 2011, at 2:14 PM, Douglas N Greve wrote:
Hi Clark, have you looked at this documentation yet? http://www.freesurfer.net/fswiki/CoordinateSystems?action=AttachFile&do=... http://www.freesurfer.net/fswiki/CoordinateSystems?action=AttachFile&do=get&target=fscoordinates.ppt doug Clark Fisher wrote:
Hello,
I was wondering what orientation conventions are used when calculating the affine transformation matrix in register.dat. For an example, I'll use the data from subject 101 of the fsfast tutorial. According to mri_info, the functional volume is in LPS orientation, and the processed anatomical volume (T1.mgz) is in LIA orientation. Does the matrix in register.dat convert from the functional LPS orientation to the anatomical LIA orientation, or does the matrix assume these volumes are already transformed in some other way?
Thanks, Clark _______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
-- Douglas N. Greve, Ph.D. MGH-NMR Center greve@nmr.mgh.harvard.edu Phone Number: 617-724-2358 Fax: 617-726-7422
Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting FileDrop: www.nmr.mgh.harvard.edu/facility/filedrop/index.html
The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail.
Thanks Sebastian and Doug, that clears everything up.
-Clark
On Sep 26, 2011, at 11:27 AM, Douglas N Greve wrote:
Clark Fisher wrote:
Hi Doug,
Thanks for pointing me back to that; I had forgotten how much depth it goes into! I have 2 remaining questions:
- Why is the tkr vox2ras transform sometimes dramatically different
from the one in the volume header? For instance, in one of the functional volumes I'm talking about, "mri_info --vox2ras" gives:
-3.42822 0.21499 0.15398 101.74103 -0.24476 -3.27187 -1.19314 135.02863 0.06182 -1.03201 3.81480 -30.98481 0.00000 0.00000 0.00000 1.00000
while "mri_info --vox2ras-tkr" gives:
-3.43750 0.00000 0.00000 110.00000 0.00000 0.00000 4.00000 -70.00000 0.00000 -3.43750 0.00000 110.00000 0.00000 0.00000 0.00000 1.00000
I would understand if the tkr-vox2ras only did flips and 90º rotations to put the data as close to RAS format as possible without having to interpolate, but the orientations produced by those 2 transformations are very different, with the rows and the slices essentially switched. I would guess that it has something to do with this explanation from Slide 5, but I don't quite understand it:
"Field-of-View based – only depends on the identity of columns, rows, and slices, the number of voxels in each dimension, and their sizes. Unrelated to the “true” geometry but is an RAS coordinate system when the volume is “Coronally” sliced, which is the based “conformed” orientation in FreeSurfer."
Any additional clarity you could provide would be appreciated.
The tkr vox2ras is not related to RAS/LIA/etc and you should not attempt to understand it using these terms. It will always have the same pattern of zeros and non-zeros regardless of the true geometry. Given the number of voxels in each dimension and the voxel size in each dimension, one can write down the tkr vox2ras without knowing anything else above the volume. This unfortunate situation is historical. The true geometry as it relates to the tkr geometry ends up being embedded in the registration matrix. In the end, neither the tkr vox2ras nor the registration matrix are interpretable by themselves (but together they are).
- In Freesurfer XYZ space, why are the volumes centered at (# of
voxels)/2? I would think that centering at ((# of voxels) + 1) /2 would put the true center of the volume on the origin.
You are correct. This is another unfortunate accident of history. doug
Thanks again, Clark
On Sep 20, 2011, at 2:14 PM, Douglas N Greve wrote:
Hi Clark, have you looked at this documentation yet? http://www.freesurfer.net/fswiki/CoordinateSystems?action=AttachFile&do=... http://www.freesurfer.net/fswiki/CoordinateSystems?action=AttachFile&do=get&target=fscoordinates.ppt doug Clark Fisher wrote:
Hello,
I was wondering what orientation conventions are used when calculating the affine transformation matrix in register.dat. For an example, I'll use the data from subject 101 of the fsfast tutorial. According to mri_info, the functional volume is in LPS orientation, and the processed anatomical volume (T1.mgz) is in LIA orientation. Does the matrix in register.dat convert from the functional LPS orientation to the anatomical LIA orientation, or does the matrix assume these volumes are already transformed in some other way?
Thanks, Clark _______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
-- Douglas N. Greve, Ph.D. MGH-NMR Center greve@nmr.mgh.harvard.edu Phone Number: 617-724-2358 Fax: 617-726-7422
Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting FileDrop: www.nmr.mgh.harvard.edu/facility/filedrop/index.html
The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail.
-- Douglas N. Greve, Ph.D. MGH-NMR Center greve@nmr.mgh.harvard.edu Phone Number: 617-724-2358 Fax: 617-726-7422
Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting FileDrop: www.nmr.mgh.harvard.edu/facility/filedrop/index.html
freesurfer@nmr.mgh.harvard.edu