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 > > _______________________________________________ > Freesurfer mailing list > Freesurfer@nmr.mgh.harvard.edu > https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer _______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
