Hi Doug,
Thanks so much for your note, that makes complete sense!
To confirm, if I just delete the session/bold/masks and session/bold/RRR/masks and re-ran my preproc-sess command (-update) in v 6.0 new masks would be generated but my registration, stc, motion correction, (normalization?), would remain in 5.3. Is there any chance that version 6.0 might view the absence of register.dof6.lta files for my subjects (generated as register.dof6.dat files in 5.3) as cause for re-running the registration step and generating/using the register.dof6.lta files for use downstream of this step?
Thank you again for your help!
Best wishes, Kevin
Date: Tue, 15 Jan 2019 21:47:37 +0000 From: "Greve, Douglas N.,Ph.D." DGREVE@mgh.harvard.edu Subject: Re: [Freesurfer] preproc-sess mask issue To: "freesurfer@nmr.mgh.harvard.edu" freesurfer@nmr.mgh.harvard.edu Message-ID: 5b4ea669-5ade-6be4-2435-aed05faf1454@mgh.harvard.edu Content-Type: text/plain; charset="Windows-1252"
Yea, the 5.3 stream used FSL brain masking to make the masks for the fmri. Version 6 uses the FS brain mask transferred into fmri space. Inevitably, you will have to do a lot of reprocessing. The simplest thing to do is to delete the mask files in session/bold/masks and sessoin/bold/RRR/masks (where RRR is the run number). When you re-run preproc-sess, it will figure out what needs to be re-run. It should not rerun motion correction, slice timing correction, or registration ________________________________ ________________________________ On 1/15/19 1:26 PM, Dowling, Kevin Francis wrote:
Hello FreeSurfer Experts,
I'm writing to follow-up on my question about incomplete lhrh cortical and mni305 subcortical masks in preproc-sess. My initial email is copied below, but briefly when running WLS functional analyses via mri_glmfit in FS 5.3, I noticed a number of large regions that were pruned out?in my subcortical and cortical analyses. I traced these pruning problems back to subjects' whose raw and fmcpr.siemens.nii.gz data are fine for all functional runs, but for whom some pre-processed runs had brain.mni305.nii.gz, brain.fsaverage.rh.nii.gz, and brain.fsaverage.lh.nii.gz masks that were missing voxels/vertices (0 values rather than 1s) that cause the pruning problem later on in mri_glmfit.I tried pre-processing a number of these problematic subjects in FS 6 and noticed that these missing voxels/vertices were all fixed. However, as our analysis has ~200 subjects and is multi-modal in nature, I would like to avoid re-doing all of our analyses in FS 6.0 unless absolutely necessary.
Since the fmcpr.siemens.nii.gz functional data looks fine to me for the problematic subject runs (as do the brain.nii.gz and brain.e3.nii.gz masks), I thought something might possibly be amiss with the registration in the mni305 mask generation command (below). Specifically,when I look at the output of this command for the problematic runs relative to the good runs, the mask brain.mni305.2mm.nii.gz looks like it has been rotated away from the normal orientation (see attached image, rotated_mask_questionable.png).
mri_vol2vol --mov /autofs/cluster/roffman/users/Stable5_PerRun/GDDA161_Testing/bold/masks/brain.nii.gz --reg /autofs/cluster/roffman/users/Stable5_PerRun/GDDA161_Testing/bold/022/register.dof6.dat --tal --talres 2 --talxfm talairach.xfm --nearest --no-save-reg --o /autofs/cluster/roffman/users/Stable5_PerRun/GDDA161_Testing/bold/022/masks/brain.mni305.2mm.nii.gz
When I look at the analogous surface command (below), there are similar problems, that result in a mask missing 50% of its vertices:
mri_vol2surf --mov /autofs/cluster/roffman/users/Stable5_PerRun/GDDA161_Testing/bold/masks/brain.nii.gz --reg /autofs/cluster/roffman/users/Stable5_PerRun/GDDA161_Testing/bold/022/register.dof6.dat --trgsubject fsaverage --interp nearest --projfrac 0.5 --hemi rh --o /autofs/cluster/roffman/users/Stable5_PerRun/GDDA161_Testing/bold/022/masks/brain.fsaverage.rh.nii.gz --noreshape --cortex --surfreg sphere.reg
Looking at the structural functional alignment for this subject with tkregister-sess -s GDDA161_Testing -per-run -fsd bold, the registration (from register.dof6.dat) seems fine (mincost .57 for this problem run, but looks good visually).?Since the use of the register.dof6.dat file is common to these two processes, and since FS 6.0 uses register.dof6.lta rather than the .dat file, my? inclination was to suspect there was a registration issue except that, again, visualizing register.dof6.dat via tkregister-sess is fine.
Forgive this somewhat naive question, but beyond checking the input (which seems fine) and output (which is bad) of this command along with the subject's structural/functional registration, is there anything else I could do to further troubleshoot this issue? Is there a different registration file I should be looking at, or alternatively am I looking too far downstream in the preproc-sess pipeline? I would be most grateful for any additional troubleshooting ideas.
I have attached a .txt file containing the debug output for the described subject, whom is an extreme example of the pruning/masking issue. The problem run is 022.
Thank you again for any thoughts or suggestions you might have!
Best wishes,
Kevin
*Kevin F. Dowling * Clinical Research Coordinator Brain Genomics Laboratory Division of Psychiatric Neuroimaging Martinos Center for Biomedical Imaging Massachusetts General Hospital 149 13th Street Charlestown, MA, 02129 (p) 617.643.3215 He / Him / His
*From:* Dowling, Kevin Francis *Sent:* Tuesday, January 8, 2019 2:40 PM *To:* freesurfer@nmr.mgh.harvard.edu *Subject:* preproc-sess mask issue
Hello FreeSurfer Experts,
I'm writing with a question about a potential problems that has come up in my functional analysis. I'm running FS version 5.3 on a Linux (at the Martinos Center - CentOS release 7.6.1810).
I was recently running osgm WLS analyses with mri_glmfit and the --prune flag when I noticed that a large number of vertices in my surface based analysis were pruned out due to no signal (about 40% of the entire surface, see attached an example image of a group analysis that includes one of the bad subjects: pruning_issue.png). My first thought was that this result was potentially due to a poor functional/structural alignment for some subjects. However, I re-checked my functional and structural alignments, along with the quality of the recons, and they all look good. Upon further inspection, I observed similar erroneous pruning problems affecting voxels in the mni305 space (for an example see pruning_issue2.png). This issue stems from a modest number of subjects that have first level analyses with large amounts of no signal. Indeed, removing these problematic subjects from group surface based analyses resolves most of the excessive surface pruning problems.
When I look at the fmcpr.siemens.nii.gz files for the runs in the problematic subjects' directories the processed functional data looks good, but when I visualize the fmcpr.siemens.sm5.mni305.nii.gz (and ...fsaverage.lh.nii.gz / ...fsaverage.rh.nii.gz) files it is clear that an inappropriate number of voxels (/vertices) have been masked out. When I look at the brain.mni305.nii.gz, brain.fsaverage.rh.nii.gz, and brain.fsaverage.lh.nii.gz masks I can see they are missing a large number of voxels/vertices that should be in the masks, which leads me to think that something may be going wrong in the lh/rh/mni305 masking/mask generation step (though brain.nii.gz and brain.e3.nii.gz masks look fine to me). I've looked through the archives and wasn't able find a similar issue discussed previously.
I was therefore wondering what might be causing this mask issue (given the alignments appear to be good) and what might be the best way to go about correcting this error. Would I need to manually edit all of these masks to include the missing voxels/vertices if the automatic generation failed or is there a better solution someone might be able to suggest?
My preprocessing command is: preproc-sess -s SubjectID01 -surface fsaverage lhrh -mni305 -d $SUBJECTS_DIR -fsd bold -stc siemens -fwhm 5 -per-run
I would be happy to send along mask files/other files should they be of help.
Thank you in advance for any suggestions you might be able to provide!
Best wishes, Kevin
*Kevin F. Dowling * Clinical Research Coordinator Brain Genomics Laboratory Division of Psychiatric Neuroimaging Martinos Center for Biomedical Imaging Massachusetts General Hospital 149 13th Street Charlestown, MA, 02129 (p) 617.643.3215 He / Him / His