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
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?
I would be happy to send along mask files/other files should they be of help.