Xcp_d can't find standard spaces

Software Support
1

Summary of what happened:

I am trying to figure out why standard space surfaces cannot be found. I have already tried binding the the freesurfer directories in two ways shown below this comment, and so far xcp_d doesn’t seem to find it. I inspected the function on xcp_d’s GitHub, utils.bids.get_freesurfer_dir, and in my opinion xcp_d should be able to find my freesurfer output. But maybe I’m just thinking about it all wrong and the issue is not with finding freesurfer at all. I’d appreciate any help! Besides this, xcp_d runs fine!

-B ${input_dir}/sourcedata/freesurfer

and

-B ${input_dir}/sourcedata/freesurfer:/freesurfer:ro

Command used (and if a helper script was used, a link to the helper script or the command generated):

apptainer run -B ${code_dir}:/code -B /om2/user/dclb/tools/imaging \
    -B ${input_dir}:/input:ro -B ${output_dir}:/out:rw -B ${scratch}:/workdir:rw -B ${input_dir}/sourcedata/freesurfer \
    --cleanenv ${APP_IMG} \
    /input \
    /out \
    participant \
    --participant-label ${subject} \
    --bids-filter-file /code/${bids_filter} \
    --cifti \
    --nprocs 8 --mem-gb 25 \
    --input-type fmriprep \
    --smoothing 6 \
    --min-coverage 0.5 \
    --min-time 100 \
    --lower-bpf 0.01 \
    --upper-bpf 0.08 \
    --bpf-order 2 \
    --head-radius 50 \
    --fd-thresh 0.3 \
    --work-dir /workdir \
    --clean-workdir \
    --resource-monitor

Version:

0.7.5

Environment (Docker, Singularity / Apptainer, custom installation):

Apptainer 1.1.7

Data formatted according to a validatable standard? Please provide the output of the validator:

├── sourcedata
│   └── freesurfer
│       ├── fsaverage
│       │   ├── label
│       │   ├── mri
│       │   │   ├── orig
│       │   │   └── transforms
│       │   │       └── bak
│       │   ├── mri.2mm
│       │   ├── scripts
│       │   ├── surf
│       │   └── xhemi
│       │       ├── bem
│       │       ├── label
│       │       ├── mri
│       │       │   ├── orig
│       │       │   └── transforms
│       │       │       └── bak
│       │       ├── scripts
│       │       ├── src
│       │       ├── stats
│       │       ├── surf
│       │       ├── tmp
│       │       ├── touch
│       │       └── trash
│       └── sub-MM314
│           ├── label
│           ├── mri
│           │   ├── orig
│           │   └── transforms
│           │       └── bak
│           ├── scripts
│           ├── stats
│           ├── surf
│           ├── tmp
│           ├── touch
│           └── trash
└── sub-MM314
    ├── figures
    ├── log
    │   └── 20230413-223034_521a5bee-98c6-43a2-879e-6c034e92a375
    └── ses-baseline
        ├── anat
        ├── fmap
        └── func

Relevant log outputs (up to 20 lines):

240801-01:32:27,51 nipype.utils INFO:
	 No standard-space surfaces found.
240801-01:32:27,89 nipype.utils INFO:
	 No standard-space surfaces found.
240801-01:32:27,128 nipype.utils INFO:
	 No standard-space surfaces found.
240801-01:32:27,174 nipype.utils INFO:
	 No standard-space surfaces found.

Screenshots / relevant information:

2

XCP-D only needs the Freesurfer directory to find registration spheres if the standard-space surfaces aren’t already available. Standard-space mesh files generally aren’t available anyway- it’s more a matter of future-proofing XCP-D for when fMRIPrep and Nibabies start outputting fsLR-space mesh files.

You don’t have --warp-surfaces-native2std in your XCP-D call, so it doesn’t seem like fsLR-space mesh files are something you requested anyway. Is there a reason the message about missing standard-space surfaces is a concern?

3

Thanks so much! I am new to xcp_d and thought this would be required to run the processing in the fsLR space. Could you help me understand in what space the processing happens, native, fsLR, fsaverage, and if including warp-surfaces-native2std would change that?

4

The BOLD data will be processed in fsLR space as long as you used the --cifti flag. XCP-D can also do the following to anatomical surface files:

  1. Take fsnative mesh files (white matter and pial) and warp them to fsLR space. This is what --warp-surfaces-native2std enables. This step will also create HCP-style midthickness, inflated, and very-inflated surface files in fsLR space. These files may be useful for visualizing fsLR-space derivatives (e.g., ALFF) on the subject’s topology.
  2. Copy over fsLR-space morphometry files (e.g., sulcal depth, sulcal curvature, cortical thickness) generated by fMRIPrep or Nibabies into the XCP-D derivatives.
  3. Parcellate the morphometry files (if they’re available) with any cortical atlases you’ve enabled XCP-D to use.

Enabling --warp-surfaces-native2std won’t affect what space the data are processed in, and the main benefits to running it are to (1) visually inspect parcellation quality and (2) overlay surface maps on the subject’s topology.

5

Thanks so much!! I have a separate xcp_d question but I’ll open another thread for that.