Freesurfer

freesurfer@nmr.mgh.harvard.edu

19 participants
30088 discussions

Re: [Freesurfer] Coordinate transformations from orig/001.mgz to T1.mgz
by Douglas N Greve 22 Aug '11

22 Aug '11

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… >> <http://www.freesurfer.net/fswiki/CoordinateSystems?action=AttachFile&do=get…> >> >> doug >> >> raij(a)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(a)nmr.mgh.harvard.edu >>> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >>> >>> >>> >> >> -- >> Douglas N. Greve, Ph.D. >> MGH-NMR Center >> greve(a)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(a)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

2 4

cortical thickness in freesurfer 3.02 vs 4.5
by Rune X 22 Aug '11

22 Aug '11

Hi, We are concerned about differences of cortical thickness when we process the same scans in freesurfer 4.5 and 3.02. We have attached an excel spreadsheet of the differences in thickness between 4.5 and 3.02 using the mean thickness of parcellations of both versions in both hemispheres. The difference in the paracellations vary from 3-11% between the versions. Are these findings reliable and explainable in choosing freesurfer 4.5 as our final version. Any comment are greatly appreciated, Thanks! Rune

1 0

Unusual findings in regression analyses
by Adam Nitenson 22 Aug '11

22 Aug '11

Hi Doug, We've been running a regression analysis on our subjects, and the results are quite puzzling as they don't seem to sync up with the individual pieces of the regression. The data is taken from the Sternberg memory paradigm, with subjects memorizing groups of 1, 3, 5 and 7 letters. We have looked at imaging data of 1vFix, 3vFix, 5vFix, 7vFix, and then our regression analysis, in theory, we should see areas of significant linear pattern when moving from the activation between 1, 3, 5, and 7 letters. However, in our latest analyses, the regression maps have not been complimenting some of the individual subjects' 1,3,etc vs Fix data. In the attached PDF, there are 2 subjects with their 1vFix, 3vFix, etc maps shown, as well as the regression map in the middle, and as you can see, particularly for the 2nd subject, the regression map just doesn't make sense considering the maps from which it was derived. The third sheet of the excel file plots the ROI values generated from the regression analysis against a calculated slope derived from the funcroi values from 1, 3, 5, and 7 vs Fix. The two outliers in the top left are the subjects we further analyzed in the attached powerpoint (which includes ROI derived values). Another strange occurance is that when making regression maps for sub-groups of approx. 8 subjects, the maps don't seems to match up well with the numbers, but the regression map of all of our subjects together looks great, yet the average ROI derived value is quite low. We've been searching for a few days for a "stupid mistake" that could have caused this, but nothing is popping out. I'm attached the analysis info for the regression analysis as well as an example paradigm file for that analysis (slopepar). We just are not sure why the regression maps and individual subject ROI values are so low consider the rather strong regression effect implied from simply eyeballing the data. I understand that the maps may not always be as strong as anticipated, but they should certainly not show dark negative blue when the pattern is positive. Examples of group commands: isxconcat-sess -sf /cluster/roffman/users/Stable5_PerRun/Subject_Files/9_ActiveFolate_Post_5T -d /cluster/roffman/users/Stable5_PerRun -analysis SIRP_LoadRegression_Stable5 -c Cond2vFix -o /cluster/roffman/users/Stable5_PerRun/August_2011/9_ActiveFolate_Post_5T_TEST "mri_glmfit --y /cluster/roffman/users/Stable5_PerRun/August_2011/9_ActiveFolate_Post_5T_TEST/SIRP_LoadRegression_Stable5/Cond2vFix/lh.ces.nii --fsgd /cluster/roffman/users/fsgd/9_ActiveFolate_Post_5T.fsgd --osgm --glmdir /cluster/roffman/users/Stable5_PerRun/August_2011/9_ActiveFolate_Post_5T_TEST/SIRP_LoadRegression_Stable5/osgm/LH2vFix --surf fsaverage lh --fwhm 4.6 Adam Nitenson, B.S. Brain Genomics Lab Massachusetts General Hospital nitenson(a)nmr.mgh.harvard.edu Phone: 617-643-3215

2 1

Re: [Freesurfer] register data to the surface
by Douglas N Greve 22 Aug '11

22 Aug '11

This is not the correct procedure. Try looking at the multi-modal integration tutorial on our web site. Basically you should not register the difference image. Instead, register the middle time point of the raw data of the fMRI to the anatomical. Motion correct the time series to the middle time point. When you analyze the data in whatever way you are using, analyze the motion corrected data. You can then use the registration computed from the raw data for anything derived from the motion corrected data. doug francesca strappini wrote: > Yes, It's a whole brain acquisition and the functional and the > anatomical data come from the same subject. > I try to explain all the story. I acquired 12 runs of polarangle per > subject in two different days. I have 3 conditions and 4 runs for > every condition. In each day the subjects did all the conditions (6 > runs per day). > I calculated a sort of subtraction between these conditions, > unfortunately it's not a simple subtraction and for this reason I > didn't use fscalc. What I tried to do is to register this subtraction > to the surface but the process failed probably because the result of > the subtraction is as very small activation only in the occipital > cortex (in fact the conditions are slightly different). > Do you think that is there something else that I can try? > > Thanks! > > > Francesca > -- Douglas N. Greve, Ph.D. MGH-NMR Center greve(a)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

1 0

FW: Occipital Flattening
by Tax, C.M.W. 22 Aug '11

22 Aug '11

Dear all, I tried to cut the occiput surface with Freesurfer. When I follow the manual on the Wikipage and description found here http://www.alivelearn.net/?cat=10 (Line cut trough the calcarine sulcus, surface cut placing 2 points on the medial side, 1 on the lateral side and a fourth point to specify which part I want to keep) I get the following error when clicking the 'cut surface' button: surfer: poffset = 205895.000000, sign = 165453.718750, n = {-703.239014,-3109.317627,-1290.049561} % tksurfer.bin: tnl/t_vertex.c:407: update_input_ptrs: Assertion `a[j].inputstride == vptr->stride' failed. Aborted Please could you help me with this problem? Thank you in advance, Kind regards, Chantal

2 1

Re: [Freesurfer] DOSS or DODS
by Tetiana Dadakova 22 Aug '11

22 Aug '11

Hello Douglas, I did as you suggested and I got the results, but I still have difficulty understanding how exactly the choice of Design Matrix Type influences the analysis, so I have several questions: 1. When I look at thickness difference between two groups and choose age as nuisance parameter, doesn't it mean that calculation take into account the difference in slopes already (as I correct for age)? So therefore, when I also choose DODS or DOSS I do kind of double correction (matrix type + nuisance), don't I? 2. When I choose e.g. DODS and do the analysis, can I see the slopes (or the values of slopes) for two groups somehow? In which file this output is? 3. Can you recommend me anything to read regarding mathematics of how the analysis is done with either matrix type? 4. Just in case you know: how is this step implemented in SPM? It also uses glm, but it doesn't ask for the DODS vs DOSS choice. Thank you, I appreciate you time and help, Tanja. On Wed, Aug 17, 2011 at 6:19 PM, Tetiana Dadakova <tetiana.d(a)gmail.com> wrote: > Thank you, Douglas. > > On Wed, Aug 17, 2011 at 5:48 PM, Douglas N Greve > <greve(a)nmr.mgh.harvard.edu> wrote: >> >> Hi Tanja, you should use DODS and test for a difference between the age >> slopes of the groups (ie, an interaction between group and age). If there >> are no significant interactions, you should then use DOSS to test for the >> difference between thicknesses. >> doug >> >> Tetiana Dadakova wrote: >>> >>> Dear all, >>> >>> I have two groups of subjects, and I want to see a difference in >>> thickness between them controlling for age. >>> I couldn't find any information in the literature on how the subject's >>> brains in my groups develop with age. Therefore I can't tell whether >>> thickness as a function of age for both groups has the same slope or >>> different. >>> >>> My question is if in this case I should use DODS? >>> >>> Thank you, >>> Tanja. >>> _______________________________________________ >>> Freesurfer mailing list >>> Freesurfer(a)nmr.mgh.harvard.edu >>> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >>> >>> >>> >> >> -- >> Douglas N. Greve, Ph.D. >> MGH-NMR Center >> greve(a)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. >> >> >

3 2

Transforming freesurfer meshes to FSL coordinates
by Todd Krieg 22 Aug '11

22 Aug '11

I am trying to use the output meshes from freesurfer (lh/rh.pial and lh/rh.white converted to .stl) with the BET meshes from FSL. They seem to be in different coordinate systems and have to be moved and scaled to match correctly. Is there an easy transform that can do this. I have tried several with no success. ---Todd Krieg Illinois Institute of Technology

2 1

V1 on fsaverage
by Ritobrato Datta 22 Aug '11

22 Aug '11

Hi Is it possible to estimate the V1 boundary on fsaverage using Hinds method ? Thanks Ri

1 0

Re: [Freesurfer] Avg.Thickness in a cluster
by Douglas N Greve 22 Aug '11

22 Aug '11

Does cluster cover the exact same region in the group map as in the individual? Even if you choose the same nominal region (eg, posterior cingulate) you will not get the same exact number when you do it in fsaverage space as when it is done in the native space. doug Antonella Kis wrote: > Dear Doug, > > I just checked my results for the average thickness from each subject > generated in the csdbase.y.ocn.dat file in different clusters (e.g. I > have 5 clusters for p<0.05). For cluster #1 - posteriorcingulate, the > average thickness for subject 1 is different from the average > thickness value in the same region-posteriorcingulate, in the > lh.aparc.stats for the same subject. I thought it should be the same. > Why they are different? Is this right? > > > MANY THANKS! > Antonella > > > -- Douglas N. Greve, Ph.D. MGH-NMR Center greve(a)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

1 0

Coordinate transformations from orig/001.mgz to T1.mgz
by raij＠nmr.mgh.harvard.edu 22 Aug '11

22 Aug '11

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

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Freesurfer