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?

/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) 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:

• 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):