Do you just need a vox2vox that goes from the conformed space back to the original dicom space? That's pretty easy, if that's the case. doug
Aapo Nummenmaa wrote:
Hi Doug,
thanks for the reply. I have looked at the document and know approximately how things are defined. Our target TMS coordinate system is defined in terms of the original DICOM data and is "LSA", independent of how the data was acquired (let's say it is "PIL"). I know naturally how to go from "PIL" to "RAS" to "LSA" and so forth within this volume. I operate with MATLAB, so when I load this stuff in, I can see if the column-row-slice order actually is "LIA", "PIL" or whatnot "mri_info" says.
But once the original data is processed by FS, to my understanding the data is conformed to be isotropic 1 mm voxels with matrix 256x256x256 and orientation "LIA". So Tommi's question is can we incorporate this resampling procedure to obtain some kind of voxel-to-voxel transformation directly. It should be straightforward in principle, but I'm not sure what FreeSurfer exactly does during this resampling step. Assuming isotropic 1mm voxels to begin with, it seems to zero-fill the volume keeping the center of the FOV fixed.
For now, I have just "reverse engineered" the voxel to voxel (or rather XYZ to XYZ) transformation by identifying same anatomical landmarks in the TMS and FreeSurfer coordinates. I guess we can also use "bbregister" to co-register the original data with "orig.mgz" (or "T1.mgz") as an /ad hoc /solution.
But of course, as Tommi pointed out, if the transformation can be figured out directly, that would be the nicest option.
Thanks,
-Aapo
On Aug 22, 2011, at 11:55 AM, Douglas N Greve wrote:
Hi Tommi, have you looked at this document? http://www.freesurfer.net/fswiki/CoordinateSystems?action=AttachFile&do=... http://www.freesurfer.net/fswiki/CoordinateSystems?action=AttachFile&do=get&target=fscoordinates.pdf
doug
raij@nmr.mgh.harvard.edu wrote:
Hi,
We (Aapo Nummenmaa and I) are developing cross-platform software that would allow translating third-party coordinates back and forth with Freesurfer segmentations.
Our example structural image is MEMPRAGE_4e_p2_1mm_iso (1 mm isotropic, 192 sagittal slices, T1 weighting).
Our third-party system (TMS-navigator Nexstim NBS) uses DICOM/nifti with origin (0,0,0) at right posterior inferior corner of the stack with x=R-L y=I-S z=P-A.
Our goal is to relate the Nexstim NBS coordinates to these two images:
- $SUBJECTS_DIR/$SUBJECT/mri/orig/001.mgz (not altered by recon-all)
- $SUBJECTS_DIR/$SUBJECT/mri/T1.mgz (altered by recon-all)
For (1) above, "Volume Index" in tkmedit looks like this: origin (0,0,0) is at right anterior superior corner of the stack with x=A-P y=S-I z=R-L. Max values in tkmedit display were (255,243,191). The acquisition had 192 sagittal slices so the last number makes sense - not sure why the second figure is not 255 (perhaps just a display thing). The orig/001.mgz stack should be exactly the same stack as in the Nexstim NBS image (which is just the plain DICOM), without any resampling or other processing, just the axes have been reshuffled a bit.
For (2) above, "Volume Index" in tkmedit looks like this: origin (0,0,0) is at right posterior superior corner of the stack with x=R-L y=S-I z=P-A. Max values in tkmedit display were (255,255,255). This makes things difficult, as we do not know what exactly recon-all did to orig/001.mgz when it converted it into T1.mgz.
Our question is this: Is there a deterministic way to go from orig/001.mgz to T1.mgz Volume Index coordinates? It seems that recon-all has at least added sagittal slices to make the T1.mgz stack into a cube (looking at lateral shift between 001.mgz and T1.mgz, I would guess that 32 1-mm slices on both sides (2*32+192=256) were added)... Further, it is not clear if the orig/001.mgz volume has been shifted, rotated, or resampled by recon-all when turning it into T1.mgz.
Thank you for the advice!
Bests,
Tommi & Aapo
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
Yeah, that should be enough. Basically it is just a coordinate shift, then? I can (probably) figure out remaining part of the transformation to the TMS system.
By the way, when I use "mri_info --vox2ras-tkr" on the original data (which is "PIL"), does it give me the vox2ras on the conformed ("LIA") or the original ("PIL") coordinate system? I would guess the conformed?
Thanks,
-Aapo
On Aug 22, 2011, at 2:06 PM, Douglas N Greve wrote:
Do you just need a vox2vox that goes from the conformed space back to the original dicom space? That's pretty easy, if that's the case. doug
Aapo Nummenmaa wrote:
Hi Doug,
thanks for the reply. I have looked at the document and know approximately how things are defined. Our target TMS coordinate system is defined in terms of the original DICOM data and is "LSA", independent of how the data was acquired (let's say it is "PIL"). I know naturally how to go from "PIL" to "RAS" to "LSA" and so forth within this volume. I operate with MATLAB, so when I load this stuff in, I can see if the column-row-slice order actually is "LIA", "PIL" or whatnot "mri_info" says. But once the original data is processed by FS, to my understanding the data is conformed to be isotropic 1 mm voxels with matrix 256x256x256 and orientation "LIA". So Tommi's question is can we incorporate this resampling procedure to obtain some kind of voxel-to-voxel transformation directly. It should be straightforward in principle, but I'm not sure what FreeSurfer exactly does during this resampling step. Assuming isotropic 1mm voxels to begin with, it seems to zero-fill the volume keeping the center of the FOV fixed.
For now, I have just "reverse engineered" the voxel to voxel (or rather XYZ to XYZ) transformation by identifying same anatomical landmarks in the TMS and FreeSurfer coordinates. I guess we can also use "bbregister" to co-register the original data with "orig.mgz" (or "T1.mgz") as an /ad hoc /solution. But of course, as Tommi pointed out, if the transformation can be figured out directly, that would be the nicest option. Thanks,
-Aapo
On Aug 22, 2011, at 11:55 AM, Douglas N Greve wrote:
Hi Tommi, have you looked at this document? http://www.freesurfer.net/fswiki/CoordinateSystems?action=AttachFile&do=... http://www.freesurfer.net/fswiki/CoordinateSystems?action=AttachFile&do=get&target=fscoordinates.pdf
doug
raij@nmr.mgh.harvard.edu wrote:
Hi,
We (Aapo Nummenmaa and I) are developing cross-platform software that would allow translating third-party coordinates back and forth with Freesurfer segmentations.
Our example structural image is MEMPRAGE_4e_p2_1mm_iso (1 mm isotropic, 192 sagittal slices, T1 weighting).
Our third-party system (TMS-navigator Nexstim NBS) uses DICOM/nifti with origin (0,0,0) at right posterior inferior corner of the stack with x=R-L y=I-S z=P-A.
Our goal is to relate the Nexstim NBS coordinates to these two images:
- $SUBJECTS_DIR/$SUBJECT/mri/orig/001.mgz (not altered by recon-all)
- $SUBJECTS_DIR/$SUBJECT/mri/T1.mgz (altered by recon-all)
For (1) above, "Volume Index" in tkmedit looks like this: origin (0,0,0) is at right anterior superior corner of the stack with x=A-P y=S-I z=R-L. Max values in tkmedit display were (255,243,191). The acquisition had 192 sagittal slices so the last number makes sense - not sure why the second figure is not 255 (perhaps just a display thing). The orig/001.mgz stack should be exactly the same stack as in the Nexstim NBS image (which is just the plain DICOM), without any resampling or other processing, just the axes have been reshuffled a bit.
For (2) above, "Volume Index" in tkmedit looks like this: origin (0,0,0) is at right posterior superior corner of the stack with x=R-L y=S-I z=P-A. Max values in tkmedit display were (255,255,255). This makes things difficult, as we do not know what exactly recon-all did to orig/001.mgz when it converted it into T1.mgz.
Our question is this: Is there a deterministic way to go from orig/001.mgz to T1.mgz Volume Index coordinates? It seems that recon-all has at least added sagittal slices to make the T1.mgz stack into a cube (looking at lateral shift between 001.mgz and T1.mgz, I would guess that 32 1-mm slices on both sides (2*32+192=256) were added)... Further, it is not clear if the orig/001.mgz volume has been shifted, rotated, or resampled by recon-all when turning it into T1.mgz.
Thank you for the advice!
Bests,
Tommi & Aapo
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
-- 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 matrix that converts col-row-slice in the conformed space to that of the raw space is V = inv(Sr)*Sc where Sr and Sc are the vox2ras matricies of the raw (ie, dicom) and conformed spaces. You can get this matrix using mri_info --vox2ras
--vox2ras-tkr gives the vox2ras in the "tkregister" space of the input. This is a slightly non-sensical space that is unique to FS (see that PDF for more info). doug
Aapo Nummenmaa wrote:
Yeah, that should be enough. Basically it is just a coordinate shift, then? I can (probably) figure out remaining part of the transformation to the TMS system.
By the way, when I use "mri_info --vox2ras-tkr" on the original data (which is "PIL"), does it give me the vox2ras on the conformed ("LIA") or the original ("PIL") coordinate system? I would guess the conformed?
Thanks,
-Aapo
On Aug 22, 2011, at 2:06 PM, Douglas N Greve wrote:
Do you just need a vox2vox that goes from the conformed space back to the original dicom space? That's pretty easy, if that's the case. doug
Aapo Nummenmaa wrote:
Hi Doug,
thanks for the reply. I have looked at the document and know approximately how things are defined. Our target TMS coordinate system is defined in terms of the original DICOM data and is "LSA", independent of how the data was acquired (let's say it is "PIL"). I know naturally how to go from "PIL" to "RAS" to "LSA" and so forth within this volume. I operate with MATLAB, so when I load this stuff in, I can see if the column-row-slice order actually is "LIA", "PIL" or whatnot "mri_info" says. But once the original data is processed by FS, to my understanding the data is conformed to be isotropic 1 mm voxels with matrix 256x256x256 and orientation "LIA". So Tommi's question is can we incorporate this resampling procedure to obtain some kind of voxel-to-voxel transformation directly. It should be straightforward in principle, but I'm not sure what FreeSurfer exactly does during this resampling step. Assuming isotropic 1mm voxels to begin with, it seems to zero-fill the volume keeping the center of the FOV fixed.
For now, I have just "reverse engineered" the voxel to voxel (or rather XYZ to XYZ) transformation by identifying same anatomical landmarks in the TMS and FreeSurfer coordinates. I guess we can also use "bbregister" to co-register the original data with "orig.mgz" (or "T1.mgz") as an /ad hoc /solution. But of course, as Tommi pointed out, if the transformation can be figured out directly, that would be the nicest option. Thanks,
-Aapo
On Aug 22, 2011, at 11:55 AM, Douglas N Greve wrote:
Hi Tommi, have you looked at this document? http://www.freesurfer.net/fswiki/CoordinateSystems?action=AttachFile&do=... http://www.freesurfer.net/fswiki/CoordinateSystems?action=AttachFile&do=get&target=fscoordinates.pdf
doug
raij@nmr.mgh.harvard.edu wrote:
Hi,
We (Aapo Nummenmaa and I) are developing cross-platform software that would allow translating third-party coordinates back and forth with Freesurfer segmentations.
Our example structural image is MEMPRAGE_4e_p2_1mm_iso (1 mm isotropic, 192 sagittal slices, T1 weighting).
Our third-party system (TMS-navigator Nexstim NBS) uses DICOM/nifti with origin (0,0,0) at right posterior inferior corner of the stack with x=R-L y=I-S z=P-A.
Our goal is to relate the Nexstim NBS coordinates to these two images:
- $SUBJECTS_DIR/$SUBJECT/mri/orig/001.mgz (not altered by recon-all)
- $SUBJECTS_DIR/$SUBJECT/mri/T1.mgz (altered by recon-all)
For (1) above, "Volume Index" in tkmedit looks like this: origin (0,0,0) is at right anterior superior corner of the stack with x=A-P y=S-I z=R-L. Max values in tkmedit display were (255,243,191). The acquisition had 192 sagittal slices so the last number makes sense - not sure why the second figure is not 255 (perhaps just a display thing). The orig/001.mgz stack should be exactly the same stack as in the Nexstim NBS image (which is just the plain DICOM), without any resampling or other processing, just the axes have been reshuffled a bit.
For (2) above, "Volume Index" in tkmedit looks like this: origin (0,0,0) is at right posterior superior corner of the stack with x=R-L y=S-I z=P-A. Max values in tkmedit display were (255,255,255). This makes things difficult, as we do not know what exactly recon-all did to orig/001.mgz when it converted it into T1.mgz.
Our question is this: Is there a deterministic way to go from orig/001.mgz to T1.mgz Volume Index coordinates? It seems that recon-all has at least added sagittal slices to make the T1.mgz stack into a cube (looking at lateral shift between 001.mgz and T1.mgz, I would guess that 32 1-mm slices on both sides (2*32+192=256) were added)... Further, it is not clear if the orig/001.mgz volume has been shifted, rotated, or resampled by recon-all when turning it into T1.mgz.
Thank you for the advice!
Bests,
Tommi & Aapo
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
-- 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
Doug, thanks for the help, just to make sure: Does the "ras" in the raw data "voxel2ras" refer to the same "RAS" as in the conformed volume: The reason why I ask is that for the conformed volume, the "voxel2ras" direction cosines consist of "-1,0, & 1", whereas in the original this is not (exactly) the case.
If the whole vox2ras transformation would be just flipping the orthogonal axes plus translation, then we should expect only "-1,0, & 1". for the values of the direction cosines for both vox2ras matrices, right?
------"ORIGINAL RAW" VOXEL TO RAS---------------------------------- 0.0587 -0.0437 -0.9973 93.2015 -0.9982 0.0128 -0.0593 161.2992 -0.0153 -0.9990 0.0429 112.8152 0.0000 0.0000 0.0000 1.0000
------CONFORMED VOXEL TO RAS----------------------------------
-1.0000 -0.0000 -0.0000 135.3584 0.0000 -0.0000 1.0000 -98.0502 0.0000 -1.0000 -0.0000 114.7583 0.0000 0.0000 0.0000 1.0000
Thanks,
-Aapo
On Aug 22, 2011, at 3:10 PM, Douglas N Greve wrote:
The matrix that converts col-row-slice in the conformed space to that of the raw space is V = inv(Sr)*Sc where Sr and Sc are the vox2ras matricies of the raw (ie, dicom) and conformed spaces. You can get this matrix using mri_info --vox2ras
--vox2ras-tkr gives the vox2ras in the "tkregister" space of the input. This is a slightly non-sensical space that is unique to FS (see that PDF for more info). doug
Aapo Nummenmaa wrote:
Yeah, that should be enough. Basically it is just a coordinate shift, then? I can (probably) figure out remaining part of the transformation to the TMS system.
By the way, when I use "mri_info --vox2ras-tkr" on the original data (which is "PIL"), does it give me the vox2ras on the conformed ("LIA") or the original ("PIL") coordinate system? I would guess the conformed?
Thanks,
-Aapo
On Aug 22, 2011, at 2:06 PM, Douglas N Greve wrote:
Do you just need a vox2vox that goes from the conformed space back to the original dicom space? That's pretty easy, if that's the case. doug
Aapo Nummenmaa wrote:
Hi Doug,
thanks for the reply. I have looked at the document and know approximately how things are defined. Our target TMS coordinate system is defined in terms of the original DICOM data and is "LSA", independent of how the data was acquired (let's say it is "PIL"). I know naturally how to go from "PIL" to "RAS" to "LSA" and so forth within this volume. I operate with MATLAB, so when I load this stuff in, I can see if the column-row-slice order actually is "LIA", "PIL" or whatnot "mri_info" says. But once the original data is processed by FS, to my understanding the data is conformed to be isotropic 1 mm voxels with matrix 256x256x256 and orientation "LIA". So Tommi's question is can we incorporate this resampling procedure to obtain some kind of voxel-to-voxel transformation directly. It should be straightforward in principle, but I'm not sure what FreeSurfer exactly does during this resampling step. Assuming isotropic 1mm voxels to begin with, it seems to zero-fill the volume keeping the center of the FOV fixed.
For now, I have just "reverse engineered" the voxel to voxel (or rather XYZ to XYZ) transformation by identifying same anatomical landmarks in the TMS and FreeSurfer coordinates. I guess we can also use "bbregister" to co-register the original data with "orig.mgz" (or "T1.mgz") as an /ad hoc /solution. But of course, as Tommi pointed out, if the transformation can be figured out directly, that would be the nicest option. Thanks,
-Aapo
On Aug 22, 2011, at 11:55 AM, Douglas N Greve wrote:
Hi Tommi, have you looked at this document? http://www.freesurfer.net/fswiki/CoordinateSystems?action=AttachFile&do=... http://www.freesurfer.net/fswiki/CoordinateSystems?action=AttachFile&do=get&target=fscoordinates.pdf
doug
raij@nmr.mgh.harvard.edu wrote:
Hi,
We (Aapo Nummenmaa and I) are developing cross-platform software that would allow translating third-party coordinates back and forth with Freesurfer segmentations.
Our example structural image is MEMPRAGE_4e_p2_1mm_iso (1 mm isotropic, 192 sagittal slices, T1 weighting).
Our third-party system (TMS-navigator Nexstim NBS) uses DICOM/nifti with origin (0,0,0) at right posterior inferior corner of the stack with x=R-L y=I-S z=P-A.
Our goal is to relate the Nexstim NBS coordinates to these two images:
- $SUBJECTS_DIR/$SUBJECT/mri/orig/001.mgz (not altered by recon-all)
- $SUBJECTS_DIR/$SUBJECT/mri/T1.mgz (altered by recon-all)
For (1) above, "Volume Index" in tkmedit looks like this: origin (0,0,0) is at right anterior superior corner of the stack with x=A-P y=S-I z=R-L. Max values in tkmedit display were (255,243,191). The acquisition had 192 sagittal slices so the last number makes sense - not sure why the second figure is not 255 (perhaps just a display thing). The orig/001.mgz stack should be exactly the same stack as in the Nexstim NBS image (which is just the plain DICOM), without any resampling or other processing, just the axes have been reshuffled a bit.
For (2) above, "Volume Index" in tkmedit looks like this: origin (0,0,0) is at right posterior superior corner of the stack with x=R-L y=S-I z=P-A. Max values in tkmedit display were (255,255,255). This makes things difficult, as we do not know what exactly recon-all did to orig/001.mgz when it converted it into T1.mgz.
Our question is this: Is there a deterministic way to go from orig/001.mgz to T1.mgz Volume Index coordinates? It seems that recon-all has at least added sagittal slices to make the T1.mgz stack into a cube (looking at lateral shift between 001.mgz and T1.mgz, I would guess that 32 1-mm slices on both sides (2*32+192=256) were added)... Further, it is not clear if the orig/001.mgz volume has been shifted, rotated, or resampled by recon-all when turning it into T1.mgz.
Thank you for the advice!
Bests,
Tommi & Aapo
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
-- 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
-- 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
If you used mri_convert to convert from dicom to mgz, then the RAS in the vox2ras will be scanner coordinates for both the raw and conformed. During the conforming step, the volume is re-sliced to be aligned with the RAS coords, so the direction cosines are always +1/-1/0
doug
Aapo Nummenmaa wrote:
Doug, thanks for the help, just to make sure: Does the "ras" in the raw data "voxel2ras" refer to the same "RAS" as in the conformed volume: The reason why I ask is that for the conformed volume, the "voxel2ras" direction cosines consist of "-1,0, & 1", whereas in the original this is not (exactly) the case.
If the whole vox2ras transformation would be just flipping the orthogonal axes plus translation, then we should expect only "-1,0, & 1". for the values of the direction cosines for both vox2ras matrices, right?
------"ORIGINAL RAW" VOXEL TO RAS---------------------------------- 0.0587 -0.0437 -0.9973 93.2015 -0.9982 0.0128 -0.0593 161.2992 -0.0153 -0.9990 0.0429 112.8152 0.0000 0.0000 0.0000 1.0000
------CONFORMED VOXEL TO RAS----------------------------------
-1.0000 -0.0000 -0.0000 135.3584 0.0000 -0.0000 1.0000 -98.0502 0.0000 -1.0000 -0.0000 114.7583 0.0000 0.0000 0.0000 1.0000Thanks,
-Aapo
On Aug 22, 2011, at 3:10 PM, Douglas N Greve wrote:
The matrix that converts col-row-slice in the conformed space to that of the raw space is V = inv(Sr)*Sc where Sr and Sc are the vox2ras matricies of the raw (ie, dicom) and conformed spaces. You can get this matrix using mri_info --vox2ras
--vox2ras-tkr gives the vox2ras in the "tkregister" space of the input. This is a slightly non-sensical space that is unique to FS (see that PDF for more info). doug
Aapo Nummenmaa wrote:
Yeah, that should be enough. Basically it is just a coordinate shift, then? I can (probably) figure out remaining part of the transformation to the TMS system.
By the way, when I use "mri_info --vox2ras-tkr" on the original data (which is "PIL"), does it give me the vox2ras on the conformed ("LIA") or the original ("PIL") coordinate system? I would guess the conformed?
Thanks,
-Aapo
On Aug 22, 2011, at 2:06 PM, Douglas N Greve wrote:
Do you just need a vox2vox that goes from the conformed space back to the original dicom space? That's pretty easy, if that's the case. doug
Aapo Nummenmaa wrote:
Hi Doug,
thanks for the reply. I have looked at the document and know approximately how things are defined. Our target TMS coordinate system is defined in terms of the original DICOM data and is "LSA", independent of how the data was acquired (let's say it is "PIL"). I know naturally how to go from "PIL" to "RAS" to "LSA" and so forth within this volume. I operate with MATLAB, so when I load this stuff in, I can see if the column-row-slice order actually is "LIA", "PIL" or whatnot "mri_info" says. But once the original data is processed by FS, to my understanding the data is conformed to be isotropic 1 mm voxels with matrix 256x256x256 and orientation "LIA". So Tommi's question is can we incorporate this resampling procedure to obtain some kind of voxel-to-voxel transformation directly. It should be straightforward in principle, but I'm not sure what FreeSurfer exactly does during this resampling step. Assuming isotropic 1mm voxels to begin with, it seems to zero-fill the volume keeping the center of the FOV fixed.
For now, I have just "reverse engineered" the voxel to voxel (or rather XYZ to XYZ) transformation by identifying same anatomical landmarks in the TMS and FreeSurfer coordinates. I guess we can also use "bbregister" to co-register the original data with "orig.mgz" (or "T1.mgz") as an /ad hoc /solution. But of course, as Tommi pointed out, if the transformation can be figured out directly, that would be the nicest option. Thanks,
-Aapo
On Aug 22, 2011, at 11:55 AM, Douglas N Greve wrote:
Hi Tommi, have you looked at this document? http://www.freesurfer.net/fswiki/CoordinateSystems?action=AttachFile&do=... http://www.freesurfer.net/fswiki/CoordinateSystems?action=AttachFile&do=get&target=fscoordinates.pdf
doug
raij@nmr.mgh.harvard.edu wrote:
> Hi, > > We (Aapo Nummenmaa and I) are developing cross-platform software that > would allow translating third-party coordinates back and forth with > Freesurfer segmentations. > > Our example structural image is MEMPRAGE_4e_p2_1mm_iso (1 mm isotropic, > 192 sagittal slices, T1 weighting). > > Our third-party system (TMS-navigator Nexstim NBS) uses DICOM/nifti with > origin (0,0,0) at right posterior inferior corner of the stack with x=R-L > y=I-S z=P-A. > > Our goal is to relate the Nexstim NBS coordinates to these two images: > 1. $SUBJECTS_DIR/$SUBJECT/mri/orig/001.mgz (not altered by recon-all) > 2. $SUBJECTS_DIR/$SUBJECT/mri/T1.mgz (altered by recon-all) > > For (1) above, "Volume Index" in tkmedit looks like this: origin (0,0,0) > is at right anterior superior corner of the stack with x=A-P y=S-I z=R-L. > Max values in tkmedit display were (255,243,191). The acquisition had 192 > sagittal slices so the last number makes sense - not sure why the second > figure is not 255 (perhaps just a display thing). The orig/001.mgz stack > should be exactly the same stack as in the Nexstim NBS image (which is > just the plain DICOM), without any resampling or other processing, just > the axes have been reshuffled a bit. > > For (2) above, "Volume Index" in tkmedit looks like this: origin (0,0,0) > is at right posterior superior corner of the stack with x=R-L y=S-I z=P-A. > Max values in tkmedit display were (255,255,255). This makes things > difficult, as we do not know what exactly recon-all did to orig/001.mgz > when it converted it into T1.mgz. > > Our question is this: Is there a deterministic way to go from orig/001.mgz > to T1.mgz Volume Index coordinates? It seems that recon-all has at least > added sagittal slices to make the T1.mgz stack into a cube (looking at > lateral shift between 001.mgz and T1.mgz, I would guess that 32 1-mm > slices on both sides (2*32+192=256) were added)... Further, it is not > clear if the orig/001.mgz volume has been shifted, rotated, or resampled > by recon-all when turning it into T1.mgz. > > Thank you for the advice! > > Bests, > > Tommi & Aapo > > _______________________________________________ > 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
-- 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
-- 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
-
Aapo Nummenmaa -
Douglas N Greve