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=get&target=fscoordinates.pdf >> >> <http://www.freesurfer.net/fswiki/CoordinateSystems?action=AttachFile&do=get&target=fscoordinates.pdf> >> >> doug >> >> r...@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 >> gr...@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 gr...@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 mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer 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.
