fMRIPrep coregistration issues with functional slab

[carolina_travassos1]

Summary of what happened:

Hi everyone!
I’m processing fMRI data using fMRIPrep (new user!), where I acquired a functional slab (27 slices) focused on S1. Coregistration has been the biggest challenge, but I achieved good results for most participants using --bold2t1w-init header. However, for one participant, two out of four runs are poorly coregistered, while the other two look fine. This happens both in T1w and MNI space. This misaligned may be caused by participant movement between runs because it is pretty notorious on raw data.

I’ve already tried:

• --fs-no-reconall
• --bold2t1w-init header
• --bold2t1w-dof 6
• Running the pipeline without field maps (Spin Echoes)

None of these improved the misalignment. Has anyone faced similar issues with partial-brain acquisitions? Any suggestions for alternative flags or preprocessing adjustments?

Thanks in advance!

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

docker run -ti --rm \
-v /DATAPOOL/SOMATOMAP/BIDS2025:/data:ro \
-v /DATAPOOL/SOMATOMAP/BIDS2025/derivatives/fmriprep_boldheader_2025:/out \
-v /SCRATCH/users/user1/fmriprep-work_S1Map_boldheader_2025:/work \
-v /DATAPOOL/SOMATOMAP/BIDS2025/freesurfer/license.txt:/license \
nipreps/fmriprep:24.1.1 \
/data /out/fmriprep \
participant \
-w /work \
--fs-license-file /license \
--bold2t1w-init header \
--nprocs 18 \
--skip_bids_validation \
--stop-on-first-crash \
--output-spaces T1w func MNI152NLin2009cAsym \
--participant-label p0011

Version:

24.1.1

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

docker

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

yes

Relevant log outputs (up to 20 lines):

Screenshots / relevant information:

Functional raw data: one run is in gray, and the other is in orange.

Example of misalignment at MNI space (func file: desc-preproc_bold):

Example of good alignment at MNI space (func file: desc-preproc_bold):

---

[terezabountioukou]

Hi everyone,

I’m running into a very similar issue with non-deterministic and persistent coregistration failures in partial slab fMRI (3/67 participants).

I’m running fMRIPrep version 25.2.4 on a dataset of 67 participants, also with partial slab EPI and a full FOV T1w. Two tasks with slightly different acquisition parameters (see attached pictures): Task 1 (WoF) uses a 10° tilt angle, Task 2 (LCI) uses 20°, both with 38 slices, TR = 2.66 s, 3 mm isotropic voxels. The different acquisition parameters of the two tasks don’t seem to be systematically driving failures as the number of failing runs is not meaningfully different between tasks.

3 out of 67 participants have failures that persist across all flag combinations I’ve tried. For these participants the failure affects all runs, though the severity varies by run and task.

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

--participant-label <label> \ 

--fs-license-file /opt/freesurfer/license.txt \ 

--nthreads 8 --omp-nthreads 2 --mem_mb 64000 \

--output-spaces T1w MNI152NLin2009cAsym:res-native MNI152NLin2009cAsym:res-2 \

--dummy-scans 5 \ 

--work-dir /work \ 

--clean-workdir

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

Apptainer

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

yes

Flags attempted:

Flag(s)	Intended effect	Outcome
(default)	BBR with automated initialisation	Failures in affected participants
--force-bbr	Force boundary-based registration regardless of initialisation quality	Helped some runs, not all
--force no-bbr	Fall back to FSL FLIRT (6-DOF affine), bypassing BBR	Helped some runs, not all
--bold2anat-init header	Initialise BOLD-to-T1w transform from image headers rather than image content	Resolved some cases
--bold2anat-init header --bold2anat-dof 9	Header initialisation + 9-DOF (affine with scaling)	No improvement over 6-DOF
--use-syn-sdc	Add susceptibility distortion correction via SyN fieldmap-less approach	No improvement

Non-determinism (potentially the more informative issue)

Re-running fMRIPrep with identical flags on the same participant sometimes produces different coregistration outcomes ranging from acceptable to clearly misaligned. This suggests something stochastic upstream of the coregistration step itself, possibly in FreeSurfer surface placement or in the initialisation of the BOLD-to-T1w registration.

Coregistration failures

Of 67 participants, 3 show coregistration failures that persist across all flag combinations. To clarify what “failure” means here: these participants have at least one run where the BOLD-to-T1w alignment is visually unacceptable in the fMRIPrep HTML report. Failures are not consistent across runs or tasks within the same participant - some runs align acceptably with one flag set while others from the same participant fail or require a different combination. The 3 flagged participants are the worst cases, where no combination produced acceptable results in any run.

Beyond these 3, acceptable coregistration across the wider sample is flag-dependent, and which flag works is inconsistent: it varies across participants, across runs within the same participant, and across the two tasks. There is no single flag combination that works reliably across the dataset.

I’ve attached here a folder with the HTML reports of the 3 participants mentioned above (using the default flags) as well as a PowerPoint showing some overlays of their functional/T1 alignment before/after coregistration with all the different flag combinations: html failed runs

Any help or pointers on how to navigate this issue would be very appreciated!

[terezabountioukou]

Quick update - coregistration fine on SPM:

I tried running coregistration manually in SPM for one of the failing participants as a sanity check (attaching a check reg screenshot), and it actually produced an acceptable alignment. This makes me think the data itself isn’t fundamentally at fault, and that successful coregistration should definitely be achievable within fMRIPrep’s robust pipeline.

I’d love to understand what might be driving the failures here and whether it’s something about the initialisation, the cost function, or something upstream like FreeSurfer. Any pointers on what to look at next would be really helpful!