fMRIPrep - Inconsistent SDC intensity correction on repeat fMRIPrep runs in spite of the same random-seed

Maurice_Pasternak · April 3, 2025, 5:27pm

Summary of what happened:

SDC [unwarping] correction occurs but it does not consistently apply intensity changes to the BOLD data despite a consistent seed argument provided when running fMRIPrep v24.1.1 with Apptainer. Re-running fMRIPrep may or may not result in the intensity correction being applied.

Unless I am misunderstanding something, this potentially raises an issue regarding reproducibility.

Version:

24.1.1

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

apptainer run --cleanenv \
    -B /path/to/BIDS/dataset:/data \
    -B /path/to/BIDS/dataset/derivatives/fmriprep:/output \
    -B /tmp/sub-asdasdasdasdas:/work \
    -B /path/to/freesurfer/.license:/opt/freesurfer/license.txt:ro \ 
    -B /home/mpasternak/.cache/templateflow:/templateflow \
    /path/to/fmriprep-24_1_1.sif \ 
    /data \
    /output \ 
    participant \ 
    -w /work \
    --participant-label sub-MAPT179 \
    --output-spaces MNI152NLin6Asym:res-2 T1w \
    --omp-nthreads 4 \
    --fs-license-file /opt/freesurfer/license.txt \
    --fs-subjects-dir /output/sourcedata/freesurfer \
    -v \
    --random-seed 42 \
    --aggregate-session-reports 10 \ 
    --cifti-output \
    --longitudinal

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

Apptainer

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

Passes bids-validator v1.15.0

Relevant log outputs (up to 20 lines):

See screenshots below

Screenshots / relevant information:

Fieldmap acquisition is your typical Siemens “2 magnitude images and a phasediff” combination.
SDC clearly works in the sense that it performs the expected unwarping around the orbitofrontal regions. What is inconsistent is whether intensity adjustment is also applied.

Round 1

Round 2

Steven · April 3, 2025, 5:32pm

Hi @Maurice_Pasternak please try with 25.0.0. Also note that those are different x-coordinate slices of the image. Image viewer of final product would be better so you have more control over image contrast and coordinates.

Best,
Steven

Maurice_Pasternak · April 3, 2025, 5:43pm

Oh, nice to see an update.

To my understanding from the new help manual, the new flag associated with this would be --force fmap-jacobian, correct? I’m assuming this flag can stay in and will be ignored if there is no fieldmap for a given subject/session, correct?

Steven · April 3, 2025, 5:45pm

Hi @Maurice_Pasternak,

Yes, that would be the correct syntax.

Best,
Steven

jsein · April 3, 2025, 7:55pm

Hi @Maurice_Pasternak ,

I wonder if this behaviour of occasional non-bias correction of the images may be link to antsAI, as noted in this discussion:

github.com/nipreps/fmriprep

Coregistration failing randomly between tpl-MNI152NLin2009cAsym_res-02_desc-fMRIPrep_boldref.nii.gz and SBref

opened 11:56PM - 29 Nov 23 UTC

julfou81

bug

### What happened? I noticed that for one of the run (out of 6 with identical… acquisition settings) of the subject we test with fmriprep v23.2.0a2, the image sub-SUB_task-TASK_run-RUN_space-T1w_boldref.nii.gz was not corrected at all by N4 for intensity bias. As far as I can tell, It didn't affect the final registration between the bold images and the T1w images. Re-running the "faulty" run after removing the temporary files for this run resulted in a new sub-SUB_task-TASK_run-RUN_space-T1w_boldref.nii.gz image that was corrected for intensity bias. ### What command did you use? ```shell /opt/conda/envs/fmriprep/bin/fmriprep --fs-license-file /work/freesurfer/license.txt /work/GesteSigne /work/GesteSigne/derivatives/fmriprep_23.2 participant --participant-label 02 -w /work/temp_data_GesteSigne_23.2 --mem-mb 50000 --omp-nthreads 10 --nthreads 12 --fd-spike-threshold 0.5 --dvars-spike-threshold 2.0 --bold2t1w-dof 9 --output-spaces MNI152NLin2009cAsym T1w --ignore slicetiming --fs-subjects-dir /work/GesteSigne/derivatives/fmriprep_23.2/sourcedata/freesurfer ``` ### What version of fMRIPrep are you running? 23.2.0a2 ### How are you running fMRIPrep? Singularity ### Is your data BIDS valid? Yes ### Are you reusing any previously computed results? FreeSurfer ### Please copy and paste any relevant log output. _No response_ ### Additional information / screenshots Digging into this I found that the output of this command was wrong (the output image is almost totally full of 0): ``` antsApplyTransforms --default-value 0 --float 0 --input /home/jsein/.cache/templateflow/tpl-MNI152NLin2009cAsym/tpl-MNI152NLin2009cAsym_res-01_label-brain_probseg.nii.gz --interpolation Linear --output tpl-MNI152NLin2009cAsym_res-01_label-brain_probseg_trans.nii.gz --reference-image /work/GesteSigne/sub-02/func/sub-02_task-CouleursEntendants_run-01_sbref.nii.gz --transform [ /work/temp_data_GesteSigne_23.2/fmriprep_23_2_wf/sub_02_wf/bold_task_CouleursEntendants_run_01_wf/bold_fit_wf/enhance_and_skullstrip_bold_wf/norm/transform0GenericAffine.mat, 1 ] ``` Which means that the transformation calculated the step before must have been wrong: ``` antsRegistration --collapse-output-transforms 1 --dimensionality 3 --initial-moving-transform [ /work/temp_data_GesteSigne_23.2/fmriprep_23_2_wf/sub_02_wf/bold_task_CouleursEntendants_run_01_wf/bold_fit_wf/enhance_and_skullstrip_bold_wf/init_aff/initialization.mat, 0 ] --initialize-transforms-per-stage 0 --interpolation Linear --output transform --transform Affine[ 0.1 ] --metric Mattes[ /home/jsein/.cache/templateflow/tpl-MNI152NLin2009cAsym/tpl-MNI152NLin2009cAsym_res-02_desc-fMRIPrep_boldref.nii.gz, /work/GesteSigne/sub-02/func/sub-02_task-CouleursEntendants_run-01_sbref.nii.gz, 1, 64, Random, 0.2 ] --convergence [ 200, 1e-09, 10 ] --smoothing-sigmas 2.0mm --shrink-factors 2 --use-histogram-matching 1 --winsorize-image-intensities [ 0.05, 0.98 ] --write-composite-transform 0 ``` I think that `antsRegistration` may sometimes fail to the register the sBref file and the `tpl-MNI152NLin2009cAsym_res-02_desc-fMRIPrep_boldref.nii.gz` image I think due to the strong intensity bias natively present in our SBref images ( 64CH receive coil and no "Prescan Normalize" option (Siemens intensity bias correction) activated to preserve the original signal). I didn't notice this using previous versions of fmriprep but I may have missed it. What is new is that I started to re-use the SBref images with fmriprep 23.2.0a2 since the new implementation now does not use the SBref image as reference for HMC ([which was messing with the the motion estimation](https://github.com/nipreps/fmriprep/issues/2360)) but rightfully use it for bold-to-T1w coregistration which was not the case previously. I don't really know what can be done to fix this kind of "random" problem (it affected one run out of 6 for two subjects in a row and disappeared when the faulty run was relaunched). Illustration: -correct run: <img width="1478" alt="Capture d’écran 2023-11-30 à 00 53 51" src="https://github.com/nipreps/fmriprep/assets/32452352/594700db-69c1-44e6-86ec-0fc92d00a85b"> - Wrong run: the SBref image used for coregistration with the anatomy show the original intensity bias of the native image (i.e. not corrected by N4): <img width="1475" alt="Capture d’écran 2023-11-30 à 00 53 25" src="https://github.com/nipreps/fmriprep/assets/32452352/08d96d06-7aeb-466f-8080-b2311b7aee25">

Maurice_Pasternak · April 4, 2025, 12:20am

@Steven and @jsein I can confirm that this issue seems to persist in the v25 release even with the --force fmap-jacobian flag present. Some sessions flip flop between having biasfield correction applied, some appear to be “stable” in it either being applied or not applied across re-runs.

Some additional context:

other than the contents of the subject’s fmriprep/sourcedata/freesurfer/<subject> directory being preserved, to avoid the costly recon-all step, each re-run is completely fresh.
I run multiple Apptainer instances in parallel, but each instance is only given one --participant to process, which I believe is fMRIPrep’s recommendation for running in parallel.

jsein · April 4, 2025, 3:46pm

Yes, you can see what went wrong when looking at the temporary files saved by fmriprep in the working directory.

For fmriprep v23.2, you can look for instance at :
PATH_to_working_directory/fmriprep_23_2_wf/sub_02_wf/bold_ses_01_task_TASK_run_RUN_wf/bold_fit_wf/enhance_and_skullstrip_bold_wf/fix_header/tpl-MNI152NLin2009cAsym_res-01_label-brain_probseg_trans_fixhdr.nii.gz

if you see a weird brain mask, this means that the step with antsAI went wrong. The sep with antsAI is visible here:

PATH_to_working_directory/fmriprep_23_2_wf/sub_02_wf/bold_ses_01_task_TASK_run_RUN_wf/bold_fit_wf/enhance_and_skullstrip_bold_wf/init_aff/

with this kind of command:
antsAI -c [10,1e-06,10] -d 3 -x /home/jsein/.cache/templateflow/tpl-MNI152NLin2009cAsym/tpl-MNI152NLin2009cAsym_res-02_desc-brain_mask.nii.gz -m Mattes[/home/jsein/.cache/templateflow/tpl-MNI152NLin2009cAsym/tpl-MNI152NLin2009cAsym_res-02_desc-fMRIPrep_boldref.nii.gz,/work/MotorLang/sub-01/ses-01/func/sub-01_ses-01_task-Motor_run-07_sbref.nii.gz,32,Regular,0.2] -o initialization.mat -p 0 -s [20,0.12] -g [40.0,0x40x40] -t Affine[0.1] -v 1

Correct mask:

Wrong looking mask:

Maurice_Pasternak · April 4, 2025, 4:55pm

That looks to be it!

May I ask for anyone’s thoughts on the best approach to side-stepping this issue? I understand the go-to response is “it depends on your analysis”. In which case I would say that given that orbitofrontal regions are of interest to me and the work is longitudinal resting state functional connectivity, I would prioritize solutions where SDC is applied consistently across timepoints.

I wonder if it would be worthwhile to sacrifice one round of interpolation by rigid-body transforming sessions where this happens to be closer to the MNI template’s location prior to running fMRIPrep.

jsein · April 4, 2025, 10:51pm

Correct me if I am wrong: I have the feeling that this issue with bias correction being applied or not is only affecting the _boldref images and in the end I don’t really see an issue with the preprocessed bold images.

It is not ideal of course to have one step in the preprocessing which does not perform consistently but overall I don’t see any issue with the preprocessed bold images so I decided to live with this issue for now and go on with my analyses.