Re: [Freesurfer] MNI305 to MNI152 coordinates
It worked, thanks. I tried to invert it but the coordinates didn't fully correspond; I must have made an error. Thanks for helping me out! ___ 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.
Re: [Freesurfer] Error when using --mask flag in mri_glmfit
Hi Doug,
Thanks for the code, this works. Nevertheless, I am a bit unsure about
whether the masks that are used as input into this command are correct. I
like to check all the stages of the process and when I open the mask.mgh
file within the appropriate glm folder, the segmentation is totally off
(the putamen is somewhere in the OFC). Furthermore, even though the file
that holds the output cluster from the Monte Carlo simulation
(mc-z.pos.23.lh.sig.cluster.mgh) seems correct, the segmentation file that
I use as input into the mri_segstats command is also totally off
(mc-z.pos.23.lh.sig.ocn.mgh) when I load it in tkmedit. Am I loading it
incorrectly as a segmentation? Does this have anything to do with the fact
that you advised me to use the 2mm version fsaverage/mri.2mm/aseg.mgz?
Should I adapt for that in my tkmedit command?
Finally, I also run into a problem with the nucleus accumbens specifically.
For some reason I get an error when I run the glmfit and mc simulation
within this specific mask. First I make the mask:
mri_binarize --match 26 --i
/home/sooster1/Desktop/FALSE_FEEDBACK_imaging/DATA/feedback_structural/fsaverage/mri.2mm/aseg.mgz
--o
/home/sooster1/Desktop/FALSE_FEEDBACK_imaging/DATA/feedback_structural/ROI_handmade_labels/accumb_lh.mgz
Then I run glmfit:
set labels = (accumb)
foreach label ($labels)
mri_glmfit --y ces.nii.gz --osgm --glmdir glm.${label} --mask
/home/sooster1/Desktop/FALSE_FEEDBACK_imaging/DATA/feedback_structural/ROI_handmade_labels/${label}_lh.mgz
mri_glmfit-sim --glmdir glm.${label} --sim mc-z 1 2.3 mc-z.pos.23.lh
--sim-sign pos
end
But I get an error saying:
FWHM = -nan
ERROR: input FWHM is NaN (not a number).
Check the mask in the glm directory.
Any ideas what I am doing wrong?
Thanks again!
Suzanne
On Tue, Nov 5, 2013 at 12:04 AM, Douglas N Greve
gr...@nmr.mgh.harvard.eduwrote:
Hi Suzanne, there is probably an easier way to do this. If you create
contrasts of each condition vs baseline then run isxconcat-sess on each,
you can then run something like
mri_segstats --seg mc-z.pos.23.lh.sig.ocn.mgh --i condition1.nii.gz
--avgwf condition1.table.dat --excludeid 0
where condition1.nii.gz is the output of isxconcat-sess for condition 1.
The output fo mri_segstats will be condition1.table.dat which will have a
row for each subject and a column for each of the clusters
doug
On 11/01/2013 09:51 AM, Suzanne Oosterwijk wrote:
Hello again,
I am stuck again in my analysis and I am not sure that my code is right.
I want to do the following. With a Monte Carlo simulation I search for
significant clusters within a particular ROI in my all conditions vs
baseline contrast. Then I want to translate this functional cluster to each
individuals native space (as a label) and extract percent signal change for
each condition separately from that label. This is no problem in my surface
analysis, but I am not sure how to do this in the volume. I ran the Monte
Carlo simulation within the mask, which provides a segmentation called
mc-z.pos.23.lh.sig.ocn.mgh. I assume that this would be the label that
would go into mri_vol2vol to translate the cluster to native space. I found
on the website, however, that you need to use tkregister first. So I used
the following code, but I am doubtful about whether I am doing this right.
tkregister2 --mov /home/sooster1/Desktop/FALSE_FEEDBACK_imaging/DATA/
feedback_functional/ff_image/feedback_gamma_image_vol
/omnibus/glm.amygdala/osgm/mc-z.pos.23.lh.sig.ocn.mgh --s ff_01_030512
--regheader --reg ff_01_030512/register.dat --surf
The results of this command do not look good at all(see attached
image). The cluster in the -mov file does not overlap with the amygdala.
For the next step, I assumed to use mri_vol2vol to save the cluster as a
native space label, although I'd like to make sure the first step is
correct before continuing with this step.
mri_vol2vol --mov /home/sooster1/Desktop/FALSE_FEEDBACK_imaging/DATA/
feedback_functional/ff_image/feedback_gamma_image_vol
/omnibus/glm.amygdala/osgm/mc-z.pos.23.lh.sig.ocn.mgh --reg
ff_01_030512/register.dat --fstarg --interp nearest --o
ff_01_030512/label/lh.amygdala.imact.mgz --s ff_01_030512
What am I missing? Is the translation off because I did something wrong,
or does that point to a deeper issue?
Any help is much appreciated!
Suzanne
On Tue, Oct 29, 2013 at 6:04 PM, Douglas N Greve
gr...@nmr.mgh.harvard.edu mailto:gr...@nmr.mgh.harvard.edu wrote:
Hi suzanne, you'll need to use the 2mm version
fsaverage/mri.2mm/aseg.mgz
doug
On 10/29/2013 11:46 AM, Suzanne Oosterwijk wrote:
Hello all,
I want to run a Monte Carlo simulation within a volume ROI and I am
running into a problem when I use the --mask flag while running
glmfit. My question is very similar to the question asked in
[Freesurfer] Volume-based Monte Carlo Restricted to a within mask
area but I could not find
[Freesurfer] Is transformation matrix in .nii (nifti) header applied by FS?
Hello, I have a question regarding nifti (.nii) input files. I have .nii image files, which are aligned to AC-PC with SPM. The actual (original) data in this file is not changed, but the transformation matrix is saved in the .nii file. When displaying the freesurfer reconstructed results with tkmedit, the images are tilted (AC-PC aligned). So it seems that freesurfer reads and applies the transformation saved in the nii file. Is that true? and if yes at which step? When using the recon-all -i command to create the starting folders and mgz files before starting the actual freesurfer processing, is the transformation matrix used to realign the images during this first process, and the following processing is done on the reoriented image? or is it just used for display? Or is the fact that the image appears tilted a result of the Talairach transform and the nii header was not read at all? I am asking because, I have subjects which were SPM aligned, and subject which were not. I am wondering if it makes any difference, since due to an initial reorientation data will be interpolated and maybe a bit smoothed, compared to data which was not aligned before. Does anybody have any experience with that and a feeling if an reorientation beforehand would have an effect on the outcome for cortical thickness maesures? Thaks for any comments, Chris ___ 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.
Re: [Freesurfer] Linux recon-all error
Hi Krista: You may want to update tcsh. You can do this by using SUDO and 'yum update'. best, Alan On Thu, Nov 14, 2013 at 10:42 AM, krista kelly krista.kell...@gmail.comwrote: Hello, I'm running freesurfer's recon-all using Linux and the past few subjects I've run, recon-all has exited with errors. I've ran a few subjects so far with no problems, and now all of a sudden there's an issue and I can't figure out why. I have been able to run these problem' subjects using Linux on other computers with no issues, so it can't be a raw data issue. I have pasted the terminal window text below. If anyone has any idea why this is occurring, I'd love to know! Thanks! freesurfer-Linux-centos4-stable-pub-v5.3.0 Setting up environment for FreeSurfer/FS-FAST (and FSL) FREESURFER_HOME /usr/local/freesurfer FSFAST_HOME /usr/local/freesurfer/fsfast FSF_OUTPUT_FORMAT nii.gz SUBJECTS_DIR /usr/local/freesurfer/subjects MNI_DIR /usr/local/freesurfer/mni Freesurfer Virtual Machine sudo password: freesurfer fsuser@xubuntu-VirtualBox:~$ recon-all -all -qcache -notal-check -cw256 -subjid BV33 -i ~/Desktop/nii.gzs/BV33.nii.gz WARNING: tcsh v6.17.06 has an exit code bug! Please update tcsh! Subject Stamp: freesurfer-Linux-centos4-stable-pub-v5.3.0 Current Stamp: freesurfer-Linux-centos4-stable-pub-v5.3.0 INFO: SUBJECTS_DIR is /usr/local/freesurfer/subjects Actual FREESURFER_HOME /usr/local/freesurfer Linux xubuntu-VirtualBox 3.2.0-55-generic #85-Ubuntu SMP Wed Oct 2 13:43:27 UTC 2013 i686 i686 i386 GNU/Linux -cw256 option is now persistent (remove with -clean-cw256) /usr/local/freesurfer/subjects/BV33 mri_convert /home/fsuser/Desktop/nii.gzs/BV33.nii.gz /usr/local/freesurfer/subjects/BV33/mri/orig/001.mgz mri_convert /home/fsuser/Desktop/nii.gzs/BV33.nii.gz /usr/local/freesurfer/subjects/BV33/mri/orig/001.mgz $Id: mri_convert.c,v 1.179.2.7 2012/09/05 21:55:16 mreuter Exp $ reading from /home/fsuser/Desktop/nii.gzs/BV33.nii.gz... TR=1900.00, TE=0.00, TI=0.00, flip angle=0.00 i_ras = (0.999683, 0.0209404, 0.0139622) j_ras = (-0.0209424, 0.999781, 0) k_ras = (-0.0139591, -0.000292399, 0.03) writing to /usr/local/freesurfer/subjects/BV33/mri/orig/001.mgz... # #@# MotionCor Thu Nov 14 10:28:28 EST 2013 Found 1 runs /usr/local/freesurfer/subjects/BV33/mri/orig/001.mgz Checking for (invalid) multi-frame inputs... WARNING: only one run found. This is OK, but motion correction cannot be performed on one run, so I'll copy the run to rawavg and continue. cp /usr/local/freesurfer/subjects/BV33/mri/orig/001.mgz /usr/local/freesurfer/subjects/BV33/mri/rawavg.mgz /usr/local/freesurfer/subjects/BV33 mri_convert /usr/local/freesurfer/subjects/BV33/mri/rawavg.mgz /usr/local/freesurfer/subjects/BV33/mri/orig.mgz --conform --cw256 mri_convert /usr/local/freesurfer/subjects/BV33/mri/rawavg.mgz /usr/local/freesurfer/subjects/BV33/mri/orig.mgz --conform --cw256 $Id: mri_convert.c,v 1.179.2.7 2012/09/05 21:55:16 mreuter Exp $ reading from /usr/local/freesurfer/subjects/BV33/mri/rawavg.mgz... TR=1900.00, TE=0.00, TI=0.00, flip angle=0.00 i_ras = (0.999683, 0.0209404, 0.0139622) j_ras = (-0.0209424, 0.999781, 0) k_ras = (-0.0139591, -0.000292399, 0.03) Original Data has (1, 1, 1) mm size and (176, 230, 175) voxels. Data is conformed to 1 mm size and 256 voxels for all directions changing data type from float to uchar (noscale = 0)... MRIchangeType: Building histogram Reslicing using trilinear interpolation writing to /usr/local/freesurfer/subjects/BV33/mri/orig.mgz... mri_add_xform_to_header -c /usr/local/freesurfer/subjects/BV33/mri/transforms/talairach.xfm /usr/local/freesurfer/subjects/BV33/mri/orig.mgz /usr/local/freesurfer/subjects/BV33/mri/orig.mgz INFO: extension is mgz # #@# Talairach Thu Nov 14 10:28:40 EST 2013 /usr/local/freesurfer/subjects/BV33/mri mri_nu_correct.mni --n 1 --proto-iters 1000 --distance 50 --no-rescale --i orig.mgz --o orig_nu.mgz Linux xubuntu-VirtualBox 3.2.0-55-generic #85-Ubuntu SMP Wed Oct 2 13:43:27 UTC 2013 i686 i686 i386 GNU/Linux recon-all -s BV33 exited with ERRORS at Thu Nov 14 10:29:51 EST 2013 For more details, see the log file /usr/local/freesurfer/subjects/BV33/scripts/recon-all.log To report a problem, see http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting fsuser@xubuntu-VirtualBox:~$ open /usr/local/freesurfer/subjects/BV33/scripts/recon-all Couldn't get a file descriptor referring to the console fsuser@xubuntu-VirtualBox:~$ ___ 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
[Freesurfer] Linux recon-all error
Hello, I'm running freesurfer's recon-all using Linux and the past few subjects I've run, recon-all has exited with errors. I've ran a few subjects so far with no problems, and now all of a sudden there's an issue and I can't figure out why. I have been able to run these problem' subjects using Linux on other computers with no issues, so it can't be a raw data issue. I have pasted the terminal window text below. If anyone has any idea why this is occurring, I'd love to know! Thanks! freesurfer-Linux-centos4-stable-pub-v5.3.0 Setting up environment for FreeSurfer/FS-FAST (and FSL) FREESURFER_HOME /usr/local/freesurfer FSFAST_HOME /usr/local/freesurfer/fsfast FSF_OUTPUT_FORMAT nii.gz SUBJECTS_DIR /usr/local/freesurfer/subjects MNI_DIR /usr/local/freesurfer/mni Freesurfer Virtual Machine sudo password: freesurfer fsuser@xubuntu-VirtualBox:~$ recon-all -all -qcache -notal-check -cw256 -subjid BV33 -i ~/Desktop/nii.gzs/BV33.nii.gz WARNING: tcsh v6.17.06 has an exit code bug! Please update tcsh! Subject Stamp: freesurfer-Linux-centos4-stable-pub-v5.3.0 Current Stamp: freesurfer-Linux-centos4-stable-pub-v5.3.0 INFO: SUBJECTS_DIR is /usr/local/freesurfer/subjects Actual FREESURFER_HOME /usr/local/freesurfer Linux xubuntu-VirtualBox 3.2.0-55-generic #85-Ubuntu SMP Wed Oct 2 13:43:27 UTC 2013 i686 i686 i386 GNU/Linux -cw256 option is now persistent (remove with -clean-cw256) /usr/local/freesurfer/subjects/BV33 mri_convert /home/fsuser/Desktop/nii.gzs/BV33.nii.gz /usr/local/freesurfer/subjects/BV33/mri/orig/001.mgz mri_convert /home/fsuser/Desktop/nii.gzs/BV33.nii.gz /usr/local/freesurfer/subjects/BV33/mri/orig/001.mgz $Id: mri_convert.c,v 1.179.2.7 2012/09/05 21:55:16 mreuter Exp $ reading from /home/fsuser/Desktop/nii.gzs/BV33.nii.gz... TR=1900.00, TE=0.00, TI=0.00, flip angle=0.00 i_ras = (0.999683, 0.0209404, 0.0139622) j_ras = (-0.0209424, 0.999781, 0) k_ras = (-0.0139591, -0.000292399, 0.03) writing to /usr/local/freesurfer/subjects/BV33/mri/orig/001.mgz... # #@# MotionCor Thu Nov 14 10:28:28 EST 2013 Found 1 runs /usr/local/freesurfer/subjects/BV33/mri/orig/001.mgz Checking for (invalid) multi-frame inputs... WARNING: only one run found. This is OK, but motion correction cannot be performed on one run, so I'll copy the run to rawavg and continue. cp /usr/local/freesurfer/subjects/BV33/mri/orig/001.mgz /usr/local/freesurfer/subjects/BV33/mri/rawavg.mgz /usr/local/freesurfer/subjects/BV33 mri_convert /usr/local/freesurfer/subjects/BV33/mri/rawavg.mgz /usr/local/freesurfer/subjects/BV33/mri/orig.mgz --conform --cw256 mri_convert /usr/local/freesurfer/subjects/BV33/mri/rawavg.mgz /usr/local/freesurfer/subjects/BV33/mri/orig.mgz --conform --cw256 $Id: mri_convert.c,v 1.179.2.7 2012/09/05 21:55:16 mreuter Exp $ reading from /usr/local/freesurfer/subjects/BV33/mri/rawavg.mgz... TR=1900.00, TE=0.00, TI=0.00, flip angle=0.00 i_ras = (0.999683, 0.0209404, 0.0139622) j_ras = (-0.0209424, 0.999781, 0) k_ras = (-0.0139591, -0.000292399, 0.03) Original Data has (1, 1, 1) mm size and (176, 230, 175) voxels. Data is conformed to 1 mm size and 256 voxels for all directions changing data type from float to uchar (noscale = 0)... MRIchangeType: Building histogram Reslicing using trilinear interpolation writing to /usr/local/freesurfer/subjects/BV33/mri/orig.mgz... mri_add_xform_to_header -c /usr/local/freesurfer/subjects/BV33/mri/transforms/talairach.xfm /usr/local/freesurfer/subjects/BV33/mri/orig.mgz /usr/local/freesurfer/subjects/BV33/mri/orig.mgz INFO: extension is mgz # #@# Talairach Thu Nov 14 10:28:40 EST 2013 /usr/local/freesurfer/subjects/BV33/mri mri_nu_correct.mni --n 1 --proto-iters 1000 --distance 50 --no-rescale --i orig.mgz --o orig_nu.mgz Linux xubuntu-VirtualBox 3.2.0-55-generic #85-Ubuntu SMP Wed Oct 2 13:43:27 UTC 2013 i686 i686 i386 GNU/Linux recon-all -s BV33 exited with ERRORS at Thu Nov 14 10:29:51 EST 2013 For more details, see the log file /usr/local/freesurfer/subjects/BV33/scripts/recon-all.log To report a problem, see http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting fsuser@xubuntu-VirtualBox:~$ open /usr/local/freesurfer/subjects/BV33/scripts/recon-all Couldn't get a file descriptor referring to the console fsuser@xubuntu-VirtualBox:~$ ___ 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.
Re: [Freesurfer] Re global lgi values
Thank you. Can I then use aparcstats2table --subjects --hemi lh --meas thickness --parc lh.aparc.pial_lgi.stats --tablefile aparc_lgi_lh.txt to get all the values in 1 tablefile or should I use other command? On Wed, Nov 13, 2013 at 6:59 PM, Douglas N Greve gr...@nmr.mgh.harvard.eduwrote: yes and yes On 11/13/2013 12:04 PM, Anna Jonsson wrote: Thank you very much. By second I assume you mean second row? And out of the values on the second row it must be the value 2.9472? Is it headed by Area_mm2 or Mean? And what are the units? Thanks again On Wed, Nov 13, 2013 at 4:56 PM, Douglas N Greve gr...@nmr.mgh.harvard.edu mailto:gr...@nmr.mgh.harvard.edu wrote: that looks correct. It is the 2nd number you want. The first is for the medial wall (not interesting). You can have it report only for cortex by adding --id 1 doug On 11/13/2013 11:45 AM, Anna Jonsson wrote: Dear list, I have a question about extracting global lgi values/hemisphere. I think I have managed to do it correctly using : mri_segstats --slabel subj lh $SUBJECTS_DIR/subj/label/lh.cortex --i $SUBJECTS_DIR/subj/surf/lh.pial_lgi --sum lh.aparc.pial_lgi.stats (Please let me know if this is not correct) I then get this output ( for each individual) ColHeaders Index SegId NVertices Area_mm2 StructName Mean StdDev Min Max Range 1 0 7953 5220.0 Seg 2.4055 0.4052 1.5796 2.9763 1.3967 2 1156737 101379.9 Seg0001 2.9472 0.9038 1.7030 6.0007 4.2977 I assume one of these values (if above command has worked correctly) contains the mean lgi value for the left hemisphere. Can somebody please tell me which of the above values is the correct lgi value? Additionally, what units are lgi measured in, and are values between 1-5 what is considered normal? Thank you very much Anna ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu mailto: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 mailto:gr...@nmr.mgh.harvard.edu Phone Number: 617-724-2358 tel:617-724-2358 Fax: 617-726-7422 tel:617-726-7422 Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting FileDrop: https://gate.nmr.mgh.harvard.edu/filedrop2 www.nmr.mgh.harvard.edu/facility/filedrop/index.html http://www.nmr.mgh.harvard.edu/facility/filedrop/index.html Outgoing: ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/ ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu mailto: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. -- 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: https://gate.nmr.mgh.harvard.edu/filedrop2 www.nmr.mgh.harvard.edu/facility/filedrop/index.html Outgoing: ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/ ___ 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.
Re: [Freesurfer] T2pial/FLAIRpial processing issues
To fix the second problem, why not reorient the T2w image so the image axes are oriented in the way that FreeSurfer expects? Peace, Matt. From: Martijn Steenwijk martijnsteenw...@gmail.com Date: Thursday, November 14, 2013 8:13 AM To: freesurfer freesurfer@nmr.mgh.harvard.edu Cc: Veronica Popescu v.pope...@vumc.nl, Hugo Vrenken h.vren...@vumc.nl Subject: [Freesurfer] T2pial/FLAIRpial processing issues Dear all, There seem to be some serious issues with the T2pial / FLAIRpial processing options provided in the latest versions of FreeSurfer. First of all, although not clearly documented, T2pial / FLAIRpial processing does require the FSLDIR to be set (in order to use bbregister with --init-fsl). If not set, recon-all will finish just without using the T2 or FLAIR information. Importantly, no clear warning about this is given although the user expects that T2/FLAIR has been used for pial surface refinement. I think this is a very easy source of errors, so it might be a good idea to just throw an error when FSLDIR is missing and T2pial/FLAIRpial processing is requested. Second, if FSLDIR has been set. T2pial/FLAIRpial uses bbregister with FLIRT initialisation to align the T2 or FLAIR image to orig.mgz. However, we have some high-res 3DFLAIR data in which this registration (more specifially, the FLIRT initialisation step of bbregister) seems to fail in more than half of the cases. Apparently, the FSL initialisation is not capable to change the orientation such that it fits to the coordinate system used for orig.mgz. Again, no warning or error is thrown, but the processing just continues with the wrong registration and without noticing the results will get worse compared to not using T2 or FLAIR. Although I know its essential to look at the output data; would it be possible to put some effort in letting the user know that things got wrong? As a sidenote; I tried to fix this registration issue, but it seems to be very complicated using bbregister (other than just inserting my own registration obtained by using FLIRT to register native FLAIR to native T1, and subsequently transform the result to Freesurfer space in order to obtain FLAIR.mgz). Best, Martijn ___ 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. ___ 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.
Re: [Freesurfer] T2pial/FLAIRpial processing issues
Hi Martijn we can print warning and errors if FSLDIR is not set, but the registration errros seem to be mostly a flirt issue, no? Have you posted on the FSL list? Bruce On Thu, 14 Nov 2013, Martijn Steenwijk wrote: Dear all, There seem to be some serious issues with the T2pial / FLAIRpial processing options provided in the latest versions of FreeSurfer. First of all, although not clearly documented, T2pial / FLAIRpial processing does require the FSLDIR to be set (in order to use bbregister with --init-fsl). If not set, recon-all will finish just without using the T2 or FLAIR information. Importantly, no clear warning about this is given although the user expects that T2/FLAIR has been used for pial surface refinement. I think this is a very easy source of errors, so it might be a good idea to just throw an error when FSLDIR is missing and T2pial/FLAIRpial processing is requested. Second, if FSLDIR has been set. T2pial/FLAIRpial uses bbregister with FLIRT initialisation to align the T2 or FLAIR image to orig.mgz. However, we have some high-res 3DFLAIR data in which this registration (more specifially, the FLIRT initialisation step of bbregister) seems to fail in more than half of the cases. Apparently, the FSL initialisation is not capable to change the orientation such that it fits to the coordinate system used for orig.mgz. Again, no warning or error is thrown, but the processing just continues with the wrong registration and without noticing the results will get worse compared to not using T2 or FLAIR. Although I know its essential to look at the output data; would it be possible to put some effort in letting the user know that things got wrong? As a sidenote; I tried to fix this registration issue, but it seems to be very complicated using bbregister (other than just inserting my own registration obtained by using FLIRT to register native FLAIR to native T1, and subsequently transform the result to Freesurfer space in order to obtain FLAIR.mgz). Best, Martijn ___ 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.
Re: [Freesurfer] T2pial/FLAIRpial processing issues
Hi Matt, Bruce, The problems are indeed a flirt issue, but given that it's programmed with --init-fsl there is not much flexibility. However, from a FS point of view, it might be a better and more robust approach to first register FLAIRraw.mgz to raw.mgz, and then concatenate the resulting registration with the (header based) registration from raw.mgz to orig.mgz - instead of trusting the robustness of either registration algorithms. ... or, as Matt suggests, fix the image axes appropriately after converting the FLAIR to mgz, and then run the registration. But I'm not sure how to do that. Best, Martijn On Thu, Nov 14, 2013 at 5:53 PM, Bruce Fischl fis...@nmr.mgh.harvard.eduwrote: Hi Martijn we can print warning and errors if FSLDIR is not set, but the registration errros seem to be mostly a flirt issue, no? Have you posted on the FSL list? Bruce On Thu, 14 Nov 2013, Martijn Steenwijk wrote: Dear all, There seem to be some serious issues with the T2pial / FLAIRpial processing options provided in the latest versions of FreeSurfer. First of all, although not clearly documented, T2pial / FLAIRpial processing does require the FSLDIR to be set (in order to use bbregister with --init-fsl). If not set, recon-all will finish just without using the T2 or FLAIR information. Importantly, no clear warning about this is given although the user expects that T2/FLAIR has been used for pial surface refinement. I think this is a very easy source of errors, so it might be a good idea to just throw an error when FSLDIR is missing and T2pial/FLAIRpial processing is requested. Second, if FSLDIR has been set. T2pial/FLAIRpial uses bbregister with FLIRT initialisation to align the T2 or FLAIR image to orig.mgz. However, we have some high-res 3DFLAIR data in which this registration (more specifially, the FLIRT initialisation step of bbregister) seems to fail in more than half of the cases. Apparently, the FSL initialisation is not capable to change the orientation such that it fits to the coordinate system used for orig.mgz. Again, no warning or error is thrown, but the processing just continues with the wrong registration and without noticing the results will get worse compared to not using T2 or FLAIR. Although I know its essential to look at the output data; would it be possible to put some effort in letting the user know that things got wrong? As a sidenote; I tried to fix this registration issue, but it seems to be very complicated using bbregister (other than just inserting my own registration obtained by using FLIRT to register native FLAIR to native T1, and subsequently transform the result to Freesurfer space in order to obtain FLAIR.mgz). Best, Martijn 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. ___ 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.
Re: [Freesurfer] T2pial/FLAIRpial processing issues
I think you can do it with mri_convert rl. I don't think it makes sense to expect FLIRT to get the registration right reliably if the axes are off (in the HCP Pipelines we definitely don't expect this and make sure all images are RPI before processing them). Peace, Matt. From: Martijn Steenwijk martijnsteenw...@gmail.com Date: Thursday, November 14, 2013 9:27 AM To: Bruce Fischl fis...@nmr.mgh.harvard.edu Cc: Veronica Popescu v.pope...@vumc.nl, Hugo Vrenken h.vren...@vumc.nl, freesurfer freesurfer@nmr.mgh.harvard.edu Subject: Re: [Freesurfer] T2pial/FLAIRpial processing issues Hi Matt, Bruce, The problems are indeed a flirt issue, but given that it's programmed with --init-fsl there is not much flexibility. However, from a FS point of view, it might be a better and more robust approach to first register FLAIRraw.mgz to raw.mgz, and then concatenate the resulting registration with the (header based) registration from raw.mgz to orig.mgz - instead of trusting the robustness of either registration algorithms. ... or, as Matt suggests, fix the image axes appropriately after converting the FLAIR to mgz, and then run the registration. But I'm not sure how to do that. Best, Martijn On Thu, Nov 14, 2013 at 5:53 PM, Bruce Fischl fis...@nmr.mgh.harvard.edu wrote: Hi Martijn we can print warning and errors if FSLDIR is not set, but the registration errros seem to be mostly a flirt issue, no? Have you posted on the FSL list? Bruce On Thu, 14 Nov 2013, Martijn Steenwijk wrote: Dear all, There seem to be some serious issues with the T2pial / FLAIRpial processing options provided in the latest versions of FreeSurfer. First of all, although not clearly documented, T2pial / FLAIRpial processing does require the FSLDIR to be set (in order to use bbregister with --init-fsl). If not set, recon-all will finish just without using the T2 or FLAIR information. Importantly, no clear warning about this is given although the user expects that T2/FLAIR has been used for pial surface refinement. I think this is a very easy source of errors, so it might be a good idea to just throw an error when FSLDIR is missing and T2pial/FLAIRpial processing is requested. Second, if FSLDIR has been set. T2pial/FLAIRpial uses bbregister with FLIRT initialisation to align the T2 or FLAIR image to orig.mgz. However, we have some high-res 3DFLAIR data in which this registration (more specifially, the FLIRT initialisation step of bbregister) seems to fail in more than half of the cases. Apparently, the FSL initialisation is not capable to change the orientation such that it fits to the coordinate system used for orig.mgz. Again, no warning or error is thrown, but the processing just continues with the wrong registration and without noticing the results will get worse compared to not using T2 or FLAIR. Although I know its essential to look at the output data; would it be possible to put some effort in letting the user know that things got wrong? As a sidenote; I tried to fix this registration issue, but it seems to be very complicated using bbregister (other than just inserting my own registration obtained by using FLIRT to register native FLAIR to native T1, and subsequently transform the result to Freesurfer space in order to obtain FLAIR.mgz). Best, Martijn 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 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. ___ 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. ___ 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.
Re: [Freesurfer] T2pial/FLAIRpial processing issues
Hi Matt hopefully Doug will chime in, but I don't see why that is the case. We preserve all the RAS information when we conform, so the info should be there for flirt cheers Bruce On Thu, 14 Nov 2013, Matt Glasser wrote: I think you can do it with mri_convert ?rl. I don't think it makes sense to expect FLIRT to get the registration right reliably if the axes are off (in the HCP Pipelines we definitely don't expect this and make sure all images are RPI before processing them). Peace, Matt. From: Martijn Steenwijk martijnsteenw...@gmail.com Date: Thursday, November 14, 2013 9:27 AM To: Bruce Fischl fis...@nmr.mgh.harvard.edu Cc: Veronica Popescu v.pope...@vumc.nl, Hugo Vrenken h.vren...@vumc.nl, freesurfer freesurfer@nmr.mgh.harvard.edu Subject: Re: [Freesurfer] T2pial/FLAIRpial processing issues Hi Matt, Bruce, The problems are indeed a flirt issue, but given that it's programmed with --init-fsl there is not much flexibility. However, from a FS point of view, it might be a better and more robust approach to first register FLAIRraw.mgz to raw.mgz, and then concatenate the resulting registration with the (header based) registration from raw.mgz to orig.mgz - instead of trusting the robustness of either registration algorithms. ... or, as Matt suggests, fix the image axes appropriately after converting the FLAIR to mgz, and then run the registration. But I'm not sure how to do that. Best, Martijn On Thu, Nov 14, 2013 at 5:53 PM, Bruce Fischl fis...@nmr.mgh.harvard.edu wrote: Hi Martijn we can print warning and errors if FSLDIR is not set, but the registration errros seem to be mostly a flirt issue, no? Have you posted on the FSL list? Bruce On Thu, 14 Nov 2013, Martijn Steenwijk wrote: Dear all, There seem to be some serious issues with the T2pial / FLAIRpial processing options provided in the latest versions of FreeSurfer. First of all, although not clearly documented, T2pial / FLAIRpial processing does require the FSLDIR to be set (in order to use bbregister with --init-fsl). If not set, recon-all will finish just without using the T2 or FLAIR information. Importantly, no clear warning about this is given although the user expects that T2/FLAIR has been used for pial surface refinement. I think this is a very easy source of errors, so it might be a good idea to just throw an error when FSLDIR is missing and T2pial/FLAIRpial processing is requested. Second, if FSLDIR has been set. T2pial/FLAIRpial uses bbregister with FLIRT initialisation to align the T2 or FLAIR image to orig.mgz. However, we have some high-res 3DFLAIR data in which this registration (more specifially, the FLIRT initialisation step of bbregister) seems to fail in more than half of the cases. Apparently, the FSL initialisation is not capable to change the orientation such that it fits to the coordinate system used for orig.mgz. Again, no warning or error is thrown, but the processing just continues with the wrong registration and without noticing the results will get worse compared to not using T2 or FLAIR. Although I know its essential to look at the output data; would it be possible to put some effort in letting the user know that things got wrong? As a sidenote; I tried to fix this registration issue, but it seems to be very complicated using bbregister (other than just inserting my own registration obtained by using FLIRT to register native FLAIR to native T1, and subsequently transform the result to Freesurfer space in order to obtain FLAIR.mgz). Best, Martijn 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. ___ 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
Re: [Freesurfer] Re global lgi values
I think it would be --parc aparc.pial_lgi doug On 11/14/2013 11:27 AM, Anna Jonsson wrote: Thank you. Can I then use aparcstats2table --subjects --hemi lh --meas thickness --parc lh.aparc.pial_lgi.stats --tablefile aparc_lgi_lh.txt to get all the values in 1 tablefile or should I use other command? On Wed, Nov 13, 2013 at 6:59 PM, Douglas N Greve gr...@nmr.mgh.harvard.edu mailto:gr...@nmr.mgh.harvard.edu wrote: yes and yes On 11/13/2013 12:04 PM, Anna Jonsson wrote: Thank you very much. By second I assume you mean second row? And out of the values on the second row it must be the value 2.9472? Is it headed by Area_mm2 or Mean? And what are the units? Thanks again On Wed, Nov 13, 2013 at 4:56 PM, Douglas N Greve gr...@nmr.mgh.harvard.edu mailto:gr...@nmr.mgh.harvard.edu mailto:gr...@nmr.mgh.harvard.edu mailto:gr...@nmr.mgh.harvard.edu wrote: that looks correct. It is the 2nd number you want. The first is for the medial wall (not interesting). You can have it report only for cortex by adding --id 1 doug On 11/13/2013 11:45 AM, Anna Jonsson wrote: Dear list, I have a question about extracting global lgi values/hemisphere. I think I have managed to do it correctly using : mri_segstats --slabel subj lh $SUBJECTS_DIR/subj/label/lh.cortex --i $SUBJECTS_DIR/subj/surf/lh.pial_lgi --sum lh.aparc.pial_lgi.stats (Please let me know if this is not correct) I then get this output ( for each individual) ColHeaders Index SegId NVertices Area_mm2 StructName Mean StdDev Min Max Range 1 0 7953 5220.0 Seg 2.4055 0.4052 tel:2.4055%20%20%200.40521.5796 2.9763 1.3967 2 1156737 101379.9 Seg0001 2.9472 0.9038 1.7030 6.0007 4.2977 I assume one of these values (if above command has worked correctly) contains the mean lgi value for the left hemisphere. Can somebody please tell me which of the above values is the correct lgi value? Additionally, what units are lgi measured in, and are values between 1-5 what is considered normal? Thank you very much Anna ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu mailto:Freesurfer@nmr.mgh.harvard.edu mailto:Freesurfer@nmr.mgh.harvard.edu mailto: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 mailto:gr...@nmr.mgh.harvard.edu mailto:gr...@nmr.mgh.harvard.edu mailto:gr...@nmr.mgh.harvard.edu Phone Number: 617-724-2358 tel:617-724-2358 tel:617-724-2358 tel:617-724-2358 Fax: 617-726-7422 tel:617-726-7422 tel:617-726-7422 tel:617-726-7422 Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting FileDrop: https://gate.nmr.mgh.harvard.edu/filedrop2 www.nmr.mgh.harvard.edu/facility/filedrop/index.html http://www.nmr.mgh.harvard.edu/facility/filedrop/index.html http://www.nmr.mgh.harvard.edu/facility/filedrop/index.html Outgoing: ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/ ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu mailto:Freesurfer@nmr.mgh.harvard.edu mailto:Freesurfer@nmr.mgh.harvard.edu mailto: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
Re: [Freesurfer] qdec
The non-gui verion is to run mri_glmfit from the command line:) doug On 11/13/2013 05:23 PM, dgw wrote: Hello, I sent the message below yesterday. I can confirm that I am also having problems visualizing with qdec using the standard nmr center install over nx. Everytime I click generate stats table, I get the error below. Is there a non-gui version, which I can use? Does anyone have a way to use this over nx or vnc? Thank You, Dan I am having trouble running qdec over an NX session. I downloaded a FreeSurfer installation (5.3.0) to a network drive (/cluster/neuromind/dwakeman/software/freesurfer/). The installation has no trouble running recon-all; however, when I try to run qdec, I get vtk errors (see below): ERROR: In /usr/pubsw/packages/KWWidgets/CVS-vtk560/KWWidgets/vtkKWTkUtilities.cxx, line 230 vtkKWQdecApp (0x27454520): Script: vtkTemp2 GenerateStatsDataTables Returned Error on line 1: Uncaught exception: command failed: asegstats2table --common-segs --meas volume --tablefile /autofs/cluster/neuromind/dwakeman/study/qdec/stats_tables/aseg.volume.stats.dat --statsfile=aseg.stats --subjects ead_01 ead_02 ead_03 ead_04 ead_11 ead_12 ead_13 ead_14 Stack trace: Uncaught exception: command failed: asegstats2table --common-segs --meas volume --tablefile /autofs/cluster/neuromind/dwakeman/study/qdec/stats_tables/aseg.volume.stats.dat --statsfile=aseg.stats --subjects ead_01 ead_02 ead_03 ead_04 ead_11 ead_12 ead_13 ead_14 while executing vtkTemp2 GenerateStatsDataTables h...@nmr.mgh.harvard.edu told me that I shouldn't need vglrun (as indicated on the wiki). Is there something I need to do to fix the installation, or do I need vglrun? Thank You, Dan Wakeman ___ 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: https://gate.nmr.mgh.harvard.edu/filedrop2 www.nmr.mgh.harvard.edu/facility/filedrop/index.html Outgoing: ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/ ___ 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.
Re: [Freesurfer] Error when using --mask flag in mri_glmfit
What is your tkmedit command used to view the segmentation?
doug
On 11/14/2013 07:10 AM, Suzanne Oosterwijk wrote:
Hi Doug,
Thanks for the code, this works. Nevertheless, I am a bit unsure about
whether the masks that are used as input into this command are
correct. I like to check all the stages of the process and when I open
the mask.mgh file within the appropriate glm folder, the segmentation
is totally off (the putamen is somewhere in the OFC). Furthermore,
even though the file that holds the output cluster from the Monte
Carlo simulation (mc-z.pos.23.lh.sig.cluster.mgh) seems correct, the
segmentation file that I use as input into the mri_segstats command is
also totally off (mc-z.pos.23.lh.sig.ocn.mgh) when I load it in
tkmedit. Am I loading it incorrectly as a segmentation? Does this have
anything to do with the fact that you advised me to use the 2mm
version fsaverage/mri.2mm/aseg.mgz? Should I adapt for that in my
tkmedit command?
Finally, I also run into a problem with the nucleus accumbens
specifically. For some reason I get an error when I run the glmfit and
mc simulation within this specific mask. First I make the mask:
mri_binarize --match 26 --i
/home/sooster1/Desktop/FALSE_FEEDBACK_imaging/DATA/feedback_structural/fsaverage/mri.2mm/aseg.mgz
--o
/home/sooster1/Desktop/FALSE_FEEDBACK_imaging/DATA/feedback_structural/ROI_handmade_labels/accumb_lh.mgz
Then I run glmfit:
set labels = (accumb)
foreach label ($labels)
mri_glmfit --y ces.nii.gz --osgm --glmdir glm.${label} --mask
/home/sooster1/Desktop/FALSE_FEEDBACK_imaging/DATA/feedback_structural/ROI_handmade_labels/${label}_lh.mgz
mri_glmfit-sim --glmdir glm.${label} --sim mc-z 1 2.3
mc-z.pos.23.lh --sim-sign pos
end
But I get an error saying:
FWHM = -nan
ERROR: input FWHM is NaN (not a number).
Check the mask in the glm directory.
Any ideas what I am doing wrong?
Thanks again!
Suzanne
On Tue, Nov 5, 2013 at 12:04 AM, Douglas N Greve
gr...@nmr.mgh.harvard.edu mailto:gr...@nmr.mgh.harvard.edu wrote:
Hi Suzanne, there is probably an easier way to do this. If you
create contrasts of each condition vs baseline then run
isxconcat-sess on each, you can then run something like
mri_segstats --seg mc-z.pos.23.lh.sig.ocn.mgh --i
condition1.nii.gz --avgwf condition1.table.dat --excludeid 0
where condition1.nii.gz is the output of isxconcat-sess for
condition 1. The output fo mri_segstats will be
condition1.table.dat which will have a row for each subject and a
column for each of the clusters
doug
On 11/01/2013 09:51 AM, Suzanne Oosterwijk wrote:
Hello again,
I am stuck again in my analysis and I am not sure that my code
is right. I want to do the following. With a Monte Carlo
simulation I search for significant clusters within a
particular ROI in my all conditions vs baseline contrast. Then
I want to translate this functional cluster to each
individuals native space (as a label) and extract percent
signal change for each condition separately from that label.
This is no problem in my surface analysis, but I am not sure
how to do this in the volume. I ran the Monte Carlo simulation
within the mask, which provides a segmentation called
mc-z.pos.23.lh.sig.ocn.mgh. I assume that this would be the
label that would go into mri_vol2vol to translate the cluster
to native space. I found on the website, however, that you
need to use tkregister first. So I used the following code,
but I am doubtful about whether I am doing this right.
tkregister2 --mov
/home/sooster1/Desktop/FALSE_FEEDBACK_imaging/DATA/feedback_functional/ff_image/feedback_gamma_image_vol
/omnibus/glm.amygdala/osgm/mc-z.pos.23.lh.sig.ocn.mgh --s
ff_01_030512 --regheader --reg ff_01_030512/register.dat --surf
The results of this command do not look good at all(see
attached image). The cluster in the -mov file does not overlap
with the amygdala. For the next step, I assumed to use
mri_vol2vol to save the cluster as a native space label,
although I'd like to make sure the first step is correct
before continuing with this step.
mri_vol2vol --mov
/home/sooster1/Desktop/FALSE_FEEDBACK_imaging/DATA/feedback_functional/ff_image/feedback_gamma_image_vol
/omnibus/glm.amygdala/osgm/mc-z.pos.23.lh.sig.ocn.mgh --reg
ff_01_030512/register.dat --fstarg --interp nearest --o
ff_01_030512/label/lh.amygdala.imact.mgz --s ff_01_030512
What am I missing? Is the translation off because I did
something wrong, or does that point to a deeper issue?
Any help is much appreciated!
Suzanne
On Tue, Oct 29, 2013 at 6:04 PM, Douglas N Greve
Re: [Freesurfer] Is transformation matrix in .nii (nifti) header applied by FS?
There are two matrices in the nifti file (qform and sform). By default we use the qform. The qform is 6 dof and so is probably not appropriate for your talairach transform. Bottom line is that the sform is probably being ignored. doug On 11/14/2013 07:18 AM, c...@uos.de wrote: Hello, I have a question regarding nifti (.nii) input files. I have .nii image files, which are aligned to AC-PC with SPM. The actual (original) data in this file is not changed, but the transformation matrix is saved in the .nii file. When displaying the freesurfer reconstructed results with tkmedit, the images are tilted (AC-PC aligned). So it seems that freesurfer reads and applies the transformation saved in the nii file. Is that true? and if yes at which step? When using the recon-all -i command to create the starting folders and mgz files before starting the actual freesurfer processing, is the transformation matrix used to realign the images during this first process, and the following processing is done on the reoriented image? or is it just used for display? Or is the fact that the image appears tilted a result of the Talairach transform and the nii header was not read at all? I am asking because, I have subjects which were SPM aligned, and subject which were not. I am wondering if it makes any difference, since due to an initial reorientation data will be interpolated and maybe a bit smoothed, compared to data which was not aligned before. Does anybody have any experience with that and a feeling if an reorientation beforehand would have an effect on the outcome for cortical thickness maesures? Thaks for any comments, Chris ___ 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: https://gate.nmr.mgh.harvard.edu/filedrop2 www.nmr.mgh.harvard.edu/facility/filedrop/index.html Outgoing: ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/ ___ 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.
Re: [Freesurfer] Is transformation matrix in .nii (nifti) header applied by FS?
you will see some differences due to reslicing and interpolation. These differences should be somewhat random, so they might be difficult to detect in a group analysis. But in general, you should treat all your data the same. On 11/14/2013 03:40 PM, c...@uos.de wrote: thanks, that was already helpful. But does the fact that the transformation is carried out affect the results? I mean, the images has to be resliced and interpolated during this transformation. So intensities change slightly. If i would process the same subject, once with and once without an reorientation in the beginning as start input data, would you expect a difference? Or in other words, if you would compare groups, where one group was AC-PC aligned with SPM before freesurfer processing and the other was not, could any of the differences be attributed to the different input files (transformation matrix in the nii header). Chris There are two matrices in the nifti file (qform and sform). By default we use the qform. The qform is 6 dof and so is probably not appropriate for your talairach transform. Bottom line is that the sform is probably being ignored. doug On 11/14/2013 07:18 AM, c...@uos.de wrote: Hello, I have a question regarding nifti (.nii) input files. I have .nii image files, which are aligned to AC-PC with SPM. The actual (original) data in this file is not changed, but the transformation matrix is saved in the .nii file. When displaying the freesurfer reconstructed results with tkmedit, the images are tilted (AC-PC aligned). So it seems that freesurfer reads and applies the transformation saved in the nii file. Is that true? and if yes at which step? When using the recon-all -i command to create the starting folders and mgz files before starting the actual freesurfer processing, is the transformation matrix used to realign the images during this first process, and the following processing is done on the reoriented image? or is it just used for display? Or is the fact that the image appears tilted a result of the Talairach transform and the nii header was not read at all? I am asking because, I have subjects which were SPM aligned, and subject which were not. I am wondering if it makes any difference, since due to an initial reorientation data will be interpolated and maybe a bit smoothed, compared to data which was not aligned before. Does anybody have any experience with that and a feeling if an reorientation beforehand would have an effect on the outcome for cortical thickness maesures? Thaks for any comments, Chris ___ 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: https://gate.nmr.mgh.harvard.edu/filedrop2 www.nmr.mgh.harvard.edu/facility/filedrop/index.html Outgoing: ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/ ___ 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. -- 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: https://gate.nmr.mgh.harvard.edu/filedrop2 www.nmr.mgh.harvard.edu/facility/filedrop/index.html Outgoing: ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/ ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
[Freesurfer] are there any previous studies on the robustness of freesurfer default parameters as used in cortical thickness computation?
Hi, My interest is in cortical thickness measurements for longitudinal Alzheimer data, namely the ADNI dataset. My understanding is that recon-all can be used to generate cortical thicknesses. I am trying to understand how the default parameter values used in recon-all were arrived at. Are the default parameters optimized in some sense? How robust are the default parameters with respect to the resulting cortical thickness? Will a small change in a parameter value result in a significant difference in some cortical thicknesses? I was able to find the following and would appreciate references to good papers on this topic. Excerpt from abstract: Standard manual tracing and FreeSurfer-based analyses were performed in 77 participants including 67 cognitively normal individuals and 10 individuals with early Alzheimer's disease The manual and FreeSurfer approaches yielded nearly identical estimates of amyloid burden (intraclass correlation = 0.98) as assessed by the mean cortical binding potential. http://www.plosone.org/article/info%3Adoi%2F10.1371%2Fjournal.pone.0073377 Thanks for any forthcoming comments. Mark ___ 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.
[Freesurfer] Order of edits for longitudinal data
Dear All, I was would like to double check the order of edits for longitudinal data. I did edits for my cross-sectional data, and for my base data, I did the following: 1. skull strips edits (if necessary) 2. control points edits 3. white matter edits 4. pial edits 5.brain final surfs edits. I was also wondering if correction for topological defects is needed for the base data. Thanks, Rongxiang___ 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.
[Freesurfer] freesurfer5.3 version In CentOS5
Dear all, In CentOS5,which freesurfer5.3 version(centos4 or centos6?) can be compatible? Thanks! All the best. 2013-11-15 Rujing Zha___ 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.
[Freesurfer] Export T1 volume and a set of points in the same space
Dear All, I need to export a T1.mgz and N points (Nx3 coordinates .mat file) of the same volume in SPM12b. N are actually intracranial electrodes. For this, I save T1.mgz as .nii prior to import into SPM. Should I use volume index, volume RAS or surface RAS coordinates for N? What other transforms I should apply to the .mat coordinate file so that when read in SPM is in the same space as T1.nii? Please advise, Thank you, Octavian. ___ 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.
