RFC: Updating t2s_coreg for MEEPI

[emdupre]

Recently, @Shotgunosine showed on NeuroStars that there are some reasons to be concerned about MEEPI processing with t2s_coreg.

Specifically, because T2* maps are calculated voxelwise, voxels with invalid T2* values are filled with zeroes, and the images therefore appear "skullstripped" or "masked" in some way (I'll call them "clipped," here). This is causing problems with last brain masking and dropping regions with lower signal, such as the OFC.

There's discussion internally to tedana about alternative T2* fitting methods (see ME-ICA/tedana#315) beyond a simple log-linear fit, which might show less "clipping." This is a longer term discussion at this point, though.

At this point, I see three paths forward.

1. Replace those voxels with invalid T2* values with values from some other echo. I have implemented a draft of this here, although this feels more like a band-aid than a real solution.

2. Update how fMRIPrep handles its bold_ref images, such that this "clipping" isn't a concern. This one feels the least likely to me, but maybe it's achievable.

3. Remove the t2s_coreg option altogether. @handwerkerd expressed that he personally has not seen strong benefits to using the generated T2* image in coregistration, despite it being promoted in the previous ME-ICA pipeline. In this case, we could just continue to use the first echo.

I'd love feedback on which, if any, of these paths make sense to you !

[effigies]

I will defer to the people working on tedana (and multiecho data more generally) because I just don't have enough experience to make a well-informed decision. I can still give opinions, though...

I do agree that filling in zeroed-out voxels without a mathematical justification of the image as a map of some useful measure feels problematic. Supposing somebody actually wanted the T2* map, and they get this (call it a T2*-coreg map), the interpretation would presumably be ambiguous, right? If so, we probably wouldn't want this to happen silently. So if we wanted to continue providing T2* coregistration, then a small workflow that extracts the T2* map and augments it would be more methodologically explicit and less magical.

But if there aren't clear benefits to that, then I'm inclined toward option 3. The simplicity is appealing, so there's less to code, less to justify, and fewer places for bugs to creep in.

[emdupre]

So we tried strategy 1 in ME-ICA/tedana#393 without success. Strategy 2 seems infeasible.

I'd like to propose one more strategy --

Right now we're generated the bold_mask and bold_ref_brain internally within init_bold_t2s_wf for multi-echo data, specifically here:

https://github.com/poldracklab/fmriprep/blob/a6029eda7a418cea2d9f7326e6d455afa2c5acb4/fmriprep/workflows/bold/t2s.py#L94

We're connecting those outputs here:

https://github.com/poldracklab/fmriprep/blob/a6029eda7a418cea2d9f7326e6d455afa2c5acb4/fmriprep/workflows/bold/base.py#L760

and here:

https://github.com/poldracklab/fmriprep/blob/a6029eda7a418cea2d9f7326e6d455afa2c5acb4/fmriprep/workflows/bold/base.py#L646

What if we change L760 s.t. it does not update depending on whether the data is multi-echo? We should change L646 only if we decide to move forward with removing t2s-coreg as an option, although I could change the internals of the init_bold_t2s_wf to no longer skullstrip the generated T2* map.

[effigies]

Sorry, @emdupre, I'm having a hard time wrapping my head around the bold workflow at this point. I'm inclined to say you know what you're doing more than I do in there, so go for it.

[handwerkerd]

I'll be on the opposite side of not knowing the fmriprep workflow very well, but the other option is to allow for pre-defined masks to be used in registration. If one is aligning datasets with two different contrasts, I assume this alignment can be done on masked data. Allowing flexibility for the source of the mask might have uses beyond this one specific case.

[oesteban]

I'm inclined to say that option 3 is the most reliable. Using the shortest echo as reference will give reliable brain masks easy to extract and the echo closest to the typical single-echo time will give a contrast sufficient for bbregister to perform well.

Once the pipeline is fixed we can come back to the T2* generation. We might want to try some super-resolution approach where we upsample and remove values that are clipped. The higher resolution will make it easier for bbregister and we will be implicitly removing those outliers within the brain mask.

WDYT?