Pipeline Check for Surface Analysis from fMRIPrep to SUMA

AFNI version info (afni -ver):
Dear AFNI experts,

I'm a newcomer to AFNI and currently working on surface analysis using fMRIPrep outputs with SUMA. I've put together a processing pipeline that runs, but as a beginner, I'd really appreciate your expertise in reviewing my approach.

#!/usr/bin/env tcsh

set subj_dir="sub-01"  
set MAIN_DIR="/mnt/g/Train/TaskfMRI/AFNI"  

afni_proc.py -subj_id ${subj_dir} \
        -blocks mask surf blur scale regress \
        -script proc.${subj_dir} -scr_overwrite\
        -out_dir ${MAIN_DIR}/SUMA/surface1st/${subj_dir}.results\
        -copy_anat ${MAIN_DIR}/Prep/${subj_dir}/anat/${subj_dir}_space-MNI152NLin2009cAsym_res-2_desc-preproc_T1w.nii.gz \
        -dsets ${MAIN_DIR}/Prep/${subj_dir}/func/${subj_dir}_task-flanker_run-1_space-MNI152NLin2009cAsym_res-2_desc-preproc_bold.nii.gz \
        -tcat_remove_first_trs 0 \
        -surf_anat ${MAIN_DIR}/FS/${subj_dir}/SUMA/${subj_dir}_SurfVol.nii \
        -surf_spec ${MAIN_DIR}/FS/${subj_dir}/SUMA/std.141.${subj_dir}_?h.spec \
        -blur_size 4.0 \
        -regress_stim_times \
            ${MAIN_DIR}/SUMA/STIM/${subj_dir}/congruent.1D \
            ${MAIN_DIR}/SUMA/STIM/${subj_dir}/incongruent.1D \
            ${MAIN_DIR}/SUMA/STIM/${subj_dir}/${subj_dir}_rot_x.1D \
            ${MAIN_DIR}/SUMA/STIM/${subj_dir}/${subj_dir}_rot_y.1D \
            ${MAIN_DIR}/SUMA/STIM/${subj_dir}/${subj_dir}_rot_z.1D \
            ${MAIN_DIR}/SUMA/STIM/${subj_dir}/${subj_dir}_trans_x.1D \
            ${MAIN_DIR}/SUMA/STIM/${subj_dir}/${subj_dir}_trans_y.1D \
            ${MAIN_DIR}/SUMA/STIM/${subj_dir}/${subj_dir}_trans_z.1D \
        -regress_stim_types times times file file file file file file \
        -regress_stim_labels congruent incongruent rot_x rot_y rot_z trans_x trans_y trans_z \
        -regress_basis_multi 'GAM' 'GAM' 'NONE' 'NONE' 'NONE' 'NONE' 'NONE' 'NONE' \
        -regress_motion_file ${MAIN_DIR}/SUMA/STIM/${subj_dir}/Motion.txt \
        -regress_opts_3dD \
            -jobs 30 \
            -gltsym 'SYM: congruent -incongruent' -glt_label 1 con-incon \
            -gltsym 'SYM: incongruent -congruent' -glt_label 2 incon-con \
        -regress_censor_motion 2.0 \
        -regress_censor_outliers 0.05 \
        -regress_reml_exec \
        -regress_make_ideal_sum sum_ideal.1D \
        -regress_run_clustsim no \
        -html_review_style pythonic \
        -execute

I have several specific questions:

  1. Since I'm using fMRIPrep preprocessed data, is the volreg block necessary? Or can I skip this step?
  2. I'm using preprocessed data in MNI space - is this setup appropriate?
  3. For motion parameters, I'm using the confounds from fMRIPrep output. Is this the correct approach for AFNI surface analysis?
  4. Are there any additional blocks or parameters I should consider for surface analysis?

Any guidance or suggestions would be greatly appreciated. I want to ensure I'm following best practices for surface-based analysis in AFNI.

Thank you in advance for your help!

Best regards,
Lv Qiuyu

Hi Lv Qiuyu,

Does Motion.txt contain the same terms as rot_x.1D, etc.? If so, there is no need to pass the rot_x and similar files. I suppose one question is whether you want to actually see betas and stats for the motion, which people usually do not. If not, omit those regress_stim_times files and just use -regress_motion_file.

Note that you can view the 3dDeconvolve command in the proc script to verify exactly what is being used in the linear regression.

To be sure, have all pre-steady state volumes been removed?

What is the voxel size? Depending on that, a -blur_size of 4 might be a touch small, since in the case of surface analysis that is a final blur size, not an added blur size.

For motion censoring, 2.0 is extremely high. That number refers to a per-time point difference in location, according to the motion parameters. For healthy adults, we generally suggest 0.3. For subjects that are very prone to motion, going up to 1.0 is common.

Directly addressing your questions:

  1. Indeed, do not include a volreg block in this case.

  2. This is a big question. Are your surfaces and SurfVol.nii already in MNI space? We do not generally go to any standard space when running a surface analysis. The standard mesh surfaces suffice for that. For what you are doing, it might make sense to run FreeSurfer on that -copy_anat dataset. Or is that what you did?

  3. It is indeed important to give afni_proc.py the motion regressors. All that is needed is to pass them via -regress_motion_file. The extra rot_/trans_ regressors are not needed.

  4. The blocks are enough, though 'mask' is not needed for a surface analysis.

-rick

Dear Rick,

Thank you very much for your detailed response and suggestions.

I have made the following modifications based on your feedback:

  1. Removed the redundant motion parameters (rot_x.1D etc.) and kept only -regress_motion_file Motion.txt.

Regarding the pre-steady state volumes question: if I manually removed the first few TRs, do I need to adjust the corresponding timing files? Or does afni_proc.py have parameters that can handle this directly?

As suggested, I have switched to using the preprocessed T1w space data. Given my data's voxel size (3.4×3.4×4mm), what would you recommend as an appropriate blur_size setting?

I have also adjusted the motion censoring threshold from 2.0 to a more reasonable range.

Thank you again for your guidance, which has been extremely helpful in improving my analysis pipeline.

Best regards,
Lv Qiuyu

Hi Lv Qiuyu,

Sorry for getting away from this.

Yes, if time points are removed, the timing files need to be adjusted. But afni_proc.py does have the -regress_stim_times_offset option, so if you remove the first 12 seconds of EPI data, you can specify -12.0 as the offset to subtract that same 12 s from the events.

Our rule of thumb for blurring is between 1.5 and 2 times the minimum voxel dimension. Those are fairly large voxels, so you won't be going after small regions. But blurring by 5 or 6 mm might be reasonable.. Note that when doing an ROI-based analysis, we do not want to blur at all (the ROI averaging takes care of that).

  • rick

Dear Rick,

Thank you so much for your continued guidance and detailed explanations. Your responses have been incredibly helpful in refining my analysis pipeline.

These technical details are exactly what I needed to ensure my analysis is methodologically sound. Thanks for taking the time to provide such thorough and clear explanations.

Best regards,
Lv Qiuyu