--cifti-output incorrect resampling from fsaverage_den-164k to fsLR_den-32k

[brissend]

Hi all,

I am using fMRIPrep 20.0.1 and hoping to get preprocessed data in fsLR_den-32k space. I ran the following on our cluster:

singularity run \
    --cleanenv -B /nfs:/nfs $FMRIPREP \
    $BIDS_DIR $OUTPUT_DIR participant \
    --n_cpus $SLURM_NTASKS_PER_NODE \
    --omp-nthreads 4 \
    --fs-license-file=$SURF_LICENSE \
    --participant-label=$SUBLABEL \
    --ignore slicetiming \
    --dummy-scans 12 \
    --cifti-output \
    -w $WORK_DIR

It finished with no errors, but the resulting cifti time-series clearly does not look right.

Not sure if this is producing the issue but it appears that the area inputs to Connectome Workbench's -metric-resample are incorrect. 'area_metrics' is set to True, which means that metric overlay files (e.g. fsaverage.L.midthickness_va_avg.164k_fsavg_L.shape.gii) should be passed. It appears that anatomical surface files (tpl-fsLR_space-fsaverage_hemi-L_den-164k_midthickness.surf.gii) are used instead. If I run the following command using metric area files the output appears sensible:

wb_command -metric-resample \
$WORK_DIR/fmriprep_wf/single_subject_212_wf/func_preproc_ses_baseline_task_dsp_run_01_wf/bold_surf_wf/_target_fsaverage/update_metadata/mapflow/_update_metadata1/rh.fsaverage.gii \
~/standard_mesh_atlases/resample_fsaverage/fsaverage_std_sphere.R.164k_fsavg_R.surf.gii \
~/standard_mesh_atlases/resample_fsaverage/fs_LR-deformed_to-fsaverage.R.sphere.32k_fs_LR.surf.gii \
ADAP_BARY_AREA \
~/space-fsLR_hemi-R_den-91k_bold.gii \
-area-metrics ~/standard_mesh_atlases/resample_fsaverage/fsaverage.R.midthickness_va_avg.164k_fsavg_R.shape.gii \
~/standard_mesh_atlases/resample_fsaverage/fs_LR.R.midthickness_va_avg.32k_fs_LR.shape.gii

Best,
James

[mgxd]

@brissend thank you for the report - you are absolutely right, we should be using the per-vertex averages as the new areas. This will be fixed in the next release.

[brissend]

Good to hear. Thanks!

[brissend]

The issue actually appears to stem from the sphere files rather than the area metric files. The fsLR templateflow metric files look to be incorrectly named (surf.gii rather than shape.gii), but are otherwise identical to those provided by the HCP (http://brainvis.wustl.edu/workbench/standard_mesh_atlases.zip). However, I can recreate the incorrect resampling if I use the templateflow sphere files (tpl-fsLR_space-fsaverage_hemi-R_den-164k_sphere.surf.gii & tpl-fsLR_hemi-R_den-32k_sphere.surf.gii) rather than the HCP spheres (fsaverage_std_sphere.R.164k_fsavg_L.surf.gii & fs_LR-deformed_to-fsaverage.R.sphere.32k_fs_LR.surf.gii).

[mgxd]

hi @brissend - this should be fixed in 20.0.3. Thank you for filing this report, and let us know if you encounter any other problems!

[brissend]

Great, thank you!