Slice Timing Correction Applied but not Reported

Summary of what happened:

I’m running fMRIprep to preprocess some multi-echo fMRI data before inputting the data into tedana. Everything is going relatively well although for some reason I cannot for the life of me get slice timing corrections to be run (or potentially just be reported). I was keeping a close eye on the fMRIprep runtime logs and to my surprise I see slice timing corrections being made despite the end report saying Slice timing acquisition is “n/a”.

I guess the main thing I’m wondering is if the fmriprep logs are saying it’s applying slice timing corrections but the report say “n/a”, did it apply slice timing corrections and just not say it did? If it didn’t apply, what could be some reasons for fMRIprep thinking slice timing corrections are not applicable?

Thank you for your time and help!!

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

docker run \
    -v MRI_preprocessing\input:/data:ro \
    -v MRI_preprocessing\output:/out \
    -v MRI_preprocessing\scratch:/scratch \
    -v MRI_preprocessing\freesurfer:/freesurfer \
    nipreps/fmriprep:latest /data /out/out participant \
    --participant-label sub-50091 \
    -w /scratch \
    --fs-license-file /freesurfer/license.txt \
    --level resampling \
    --me-output-echos \
    --output-spaces MNI152NLin6Asym MNI152NLin2009cAsym MNIPediatricAsym:cohort-2:res-2 \
    --n_cpus 8


latest version of the nipreps/fmriprep docker image (version 23.2.3)

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

I ran fMRIprep through docker on a Windows 10 PC

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

Here’s the output of the validator, it does seem to have some issues with our dwi scans but looking through the forums I think this is just an error specific to the validator and fMRIprep itself can recognize the various dwi acquisitions we’ve collected since it passes the fMRIprep bids validator and finishes “successfully”.

File Path: The number of volumes in this scan does not match the number of volumes in the corresponding .bvec and .bval files.

Type:		Error
File:		sub-50091_ses-1_dir-PA_dwi.nii.gz
Location:		input/sub-50091/ses-1/dwi/sub-50091_ses-1_dir-PA_dwi.nii.gz
Reason:		The number of volumes in this scan does not match the number of volumes in the corresponding .bvec and .bval files.


Relevant log outputs (up to 20 lines):


Reports for: session 1, task movie.


  • Original orientation: LAS
  • Repetition time (TR): 0.8s
  • Phase-encoding (PE) direction: Posterior-Anterior
  • Multi-echo EPI sequence: 3 echoes.
  • Slice timing correction: n/a
  • Susceptibility distortion correction: None
  • Registration: FreeSurfer bbregister (boundary-based registration, BBR) - 6 dof
  • Non-steady-state volumes: 4

Screenshots / relevant information:

Let me know if I can provide any additional info, thanks again for your time!

6/12/2024 edit:
Adding in the full logs of the run…
stc_limbo_logs.txt (133.6 KB)

May have just answered my own question inadvertently, looks like I just didn’t fully understand what the resampling level does. It looks like using the --level resampling field halts slice timing corrections before they are applied. Removing this allows slice timing to be reported in the html output and get the multi-echo outputs. Instead just using the --me-output-echo’s fields to get the multi-echo outputs allows for slice timing to happen too.

1 Like