Open julfou81 opened 11 months ago
Yes, I believe the issue is that the antsAI
is wildly bad for these kinds of sbrefs. I've just been testing with another dataset that looked similar to this, and the affine registration is pretty extreme. I think the fix would be to register the boldref template to the bold image instead of the sbref, but continue to use the mask on the sbref.
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?
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):
Which means that the transformation calculated the step before must have been wrong:
I think that
antsRegistration
may sometimes fail to the register the sBref file and thetpl-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: