Fmriprep handling of multi-echo data with single-band reference scans

[markushs]

Hi, I posted this on neurostars a while ago:
(https://neurostars.org/t/fmriprep-handling-of-multi-echo-data-with-single-band-reference-scans/4822).
Registration of Multi-echo multi-band (MEMB) data would likely benefit from using single-band reference scans (when available). Right now I believe registration is done based on some kind of average of the volumes representing the first echo, and with multiband the contrast in these images gets very low.

As we cannot openly share participant data from the relevant project, we've collected MEMB data on two volunteers in our lab for the purpose of sharing. If someone thinks it's worthwhile looking into this, let me know and I will provide you with the data (or put it on openneuro, if that's better).

Thanks!
Markus

[effigies]

If your participants are willing to have their scans put on OpenNeuro (note that OpenNeuro releases all data under CC0), that would probably be simplest (we can just grab it with DataLad), and make it easier for others to benefit from the effort you went to.

[markushs]

Here it is:
https://openneuro.org/datasets/ds002147/versions/1.0.0

[tsalo]

How should single-band reference images fit into the multi-echo workflow?

I assume that the goal here is to use the single-band reference images (probably the one for the first echo) as BOLD reference images for motion correction and brain-mask generation. Then, if t2s_coreg is not enabled, use the single-band reference image for coregistration?

Is that roughly the extent to which the single-band reference images would be used with multi-echo data?

[markushs]

In addition to the steps mentioned above I would ensure that the echo-1 sbref is used for all co-registration steps not involving the T2*-map (e.g. with fieldmaps). We get sub-optimal results for quite a few subjects at this step.

An example.:

[tsalo]

Would it make sense to use the mean SBRef (averaged across echoes) instead of just echo 1?

[markushs]

Dropout typically becomes quite prominent at later echoes, and in my experience there is sufficient contrast in the echo-1 sbref. So my immediate intuition would be to just use echo 1 rather than the mean, at least when sbrefs are available.

[tsalo]

I could be very wrong, but it does seem like this could be solved by just removing the multi-echo-specific elif here:

https://github.com/poldracklab/fmriprep/blob/243b227fd3dfa841aa115b0369246301f8d7f854/fmriprep/workflows/bold/base.py#L320-L333

I read through the workflow connections and it seems like the T2* image would take over for the original reference image at the right time, regardless of whether that reference image is an SBRef or something pulled from the first echo.

@emdupre does that sound right?

[effigies]

I'm having trouble remembering if we put that simply because we didn't have test data, or some other reason. I can try to look around later today, if y'all don't figure it out first.

[tsalo]

It seems reasonable to default to using the first echo's SBRef as the reference image, but if possible I'd like to feed all SBRefs into niworkflows.func.util.init_bold_reference_wf and to let that workflow select the first echo internally. That way, if there are improvements that can use multiple echoes' SBRefs, they can be implemented directly in niworkflows without having to make any changes to fMRIPrep.

Does that sound alright to everyone?

[effigies]

@tsalo That sounds perfectly reasonable to me.

[tsalo]

@effigies Awesome. I'll open a corresponding issue in niworkflows to allow multiple values for sbref_file. It should also be pretty easy to pass multiple SBRefs from fMRIPrep to init_bold_reference_wf. I think it would just be a good idea to be more explicit about selecting rec-magnitude SBRefs instead of rec-phase ones at that point.

[emdupre]

I read through the workflow connections and it seems like the T2* image would take over for the original reference image at the right time, regardless of whether that reference image is an SBRef or something pulled from the first echo.

@emdupre does that sound right?

Yes, that sounds right. @effigies is also right that we didn't have access to multi-echo data with these scans when originally writing the workflow, so we weren't making use of that data (hence the elif). I think your solution sounds great, @tsalo, thanks !