Failed registrations between BOLD and T1w

[HippocampusGirl]

I am experiencing a significant number of failed registrations between BOLD and T1w for multiple datasets. We noticed that the images appear to be rotated basically in the wrong direction after registration.

We also re-ran some of the registrations with FSL BBR and ANTs, which worked without any problem.

Sadly we are not able to share any of the underlying data, but I am happy to help diagnose the issue.

What version of fMRIPrep are you using?

20.2.3

What kind of installation are you using? Containers (Singularity, Docker), or "bare-metal"?

Singularity, via HALFpipe

What is the exact command-line you used?

singularity run --containall --bind /:/ext halfpipe-halfpipe-1.2.0.sif

Are you reusing previously computed results (e.g., FreeSurfer, Anatomical derivatives, work directory of previous run)?

No, we were running from scratch

Have you checked that your inputs are BIDS valid?

They seem to be missing some metadata, but are valid.

Do you know if this used to work in the past?

We were also having these issues with version 20.2.1, but were hoping that #2307 would fix it.

Are you running it with the --fs-no-reconall flag?

Yes

And are you running with susceptibility distortion correction?

No

Did fMRIPrep generate the visual report for this particular subject? If yes, could you share it?

See screenshot above. I was asked not to share the full image, please let me know if the provided information is sufficient for diagnosing the issue.

Can you find some traces of the error reported in the visual report (at the bottom) or in crashfiles?

There are no crashfiles.

fMRIPrep log

If you have access to the output logged by fMRIPrep, please make sure to attach it as a text file to this issue.

The log file is quite large for the entire dataset. I will re-run a single subject to generate a smaller one and post that.

[oesteban]

Sadly we are not able to share any of the underlying data, but I am happy to help diagnose the issue.

But, you should be able to share the visual report, right? :D

If not, the first thing I'm going to try to look up is whether FSL FLIRT+BBR was used or there's a reason the BBR registration was rejected. That should be stated on the caption above the reportlet showing T1w-BOLD registration.

[HippocampusGirl]

Thank you for walking me through this!

• For most failed participants, the FLIRT+BBR registration appears to have been rejected.
  Registration: FSL flirt rigid registration - 6 dof
• Looking at report.svg in fsl_bbr_wf/flt_bbr, I can see that the boundary-based registration worked perfectly, it is just the initial registration fsl_bbr_wf/flt_bbr_init that failed.
  • Interestingly, if I remove the flag -usesqform from the FLIRT call, then the initial registration is fixed. I'm not sure what this means. The flag seems to be important for other datasets (Coregistration failure - 90 degree rotation (FLIRT) #999).
• As far as I can tell, the FLIRT+BBR registrations are rejected due to excessive deviations from the initial registration (https://fmriprep.org/en/stable/workflows.html#epi-to-t1w-registration), and this check was implemented to fix errors on another dataset (Fall-back registration for BBR failures #681). Would it be a good idea to add a more fine-grained check?
• For now, one solution would be to set use_bbr to True for the affected subjects.

[HippocampusGirl]

I investigated the issue some more, and it appears to be specific to datasets where the T1w image has a very high resolution (at least one voxel dimension smaller than 0.75 mm).

In this case, FLIRT will scale all input images by one over the minimum voxel dimension via the basescale parameter.

I think there may be some issue with how this scaling is applied when calculating the starting value for registration. I have sent my report to the FSL developers here https://www.jiscmail.ac.uk/cgi-bin/wa-jisc.exe?A2=FSL;78d20013.2110. It will be interesting to get their expert opinion on this issue.

In general, I think this scaling may be important for animal/rodent data, but should be safe to disable for human images. This can be easily accomplished with the command line argument -basescale 1.

[effigies]

@HippocampusGirl Thanks for digging into this. I agree that it doesn't make sense to adjust the affine matrix with an automatic scaling factor. Weird that this is completely undocumented AFAICT.

I wonder if the better option is to drop FLIRT and switch to mri_coreg for the initial registration.

[oesteban]

I wonder if the better option is to drop FLIRT and switch to mri_coreg for the initial registration.

IMHO this would be not just an easy workaround the problem, it's actually going to make both pathways (w/wo surfaces) more similar to one another.

The wonderful investigation of @HippocampusGirl is very much appreciated (pinging @eilidhmacnicol - more ammo for her arguments), and has made me think of two derived lines of this:

• Normally the FSL flirt initialization (the one failing here) and mri_coreg trip because there's an XY flip in the image not accounted for by the headers (besides the hidden -basescale parameter issue presented here). We could save a fair bit of time to ourselves and to users with Insert one checkpoint node using AFNI's tool for flip detection #2599.
• Also, I checked whether we could run bbregister on a WM surface generated from FSL fast segmentations (with mri_tesselate and mris_smooth). This doesn't seem to be possible, but another way to avert registration issues further down the line could be With SDCFlows 2.0, enabling the --vsm input of bbregister would be trivial #2600.

Thanks Lea, this issue is a large contribution in itself an in so many ways :)

[eilidhmacnicol]

Thanks for the ping @oesteban and thanks @HippocampusGirl for digging into the code on this!

This is really interesting; I imagine it's the underlying reason why mcflirt motion correction was so problematic in fprodents. Interestingly, we only use flirt in fprodents - mri_coreg was removed because I (erroneously?) thought it would require freesurfer inputs. Knowing this, I'd be tempted to do as @effigies suggests and use mri_coreg there.

[HippocampusGirl]

Using a different tool like mri_coreg for the initial registration is a great idea. I think may be an much easier change than waiting for an updated version of flirt. I will have a look and check how mri_coreg it performs with my data.

Would such a change be made only in 21.x and later, or would you also consider incorporating it into the LTS?

[oesteban]

As this doesn't change the I/O interface of fMRIPrep, and honestly, the number of users that are setting the --fs-no-reconall does not seem substantial (and of those, most of them are using standard resolutions) it doesn't seem like this change is going to be a deal-breaker. So I would be in favor of including it in the LTS. But I'm happy to be convinced otherwise if someone puts forward a good argument.

If you want to start taking a stab at it, I'd say you should branch out of maint/20.2.x. WDYT @effigies, @mgxd @bpinsard @ltetrel ?

BTW, I don't think this would require any new code, just rewiring the registration workflow, so that the recon-all pathway is made the baseline up until the accurate registration step with either bbregister or flirt. In other words, we need to delay one step the bifurcation of the computational graph.

[effigies]

If we're going to modify in 20.2.x, I would say just directly swapping FLIRT for mri_coreg with no graph restructuring at all is the safest way forward. We'll also need to make sure we update the reporting.

I would suggest that we do this limited fix in 20.2.x and 21.0. Future versions can do some cleaning up where we can restructure the graph to share an initial registration step.

[effigies]

Will be fixed in 20.2.7. Is fixed in 21.0.0.