Update fMRIPrep requirements and T2SMap interface to 0.0.9

[tsalo]

Summary

Changes in 0.0.9 will break fMRIPrep's T2SMap interface (particularly #416).

Next Steps

• OPTIONAL: Change output files for t2smap_workflow and corresponding outputs in tedana_workflow to be more BIDS-like. Sort of like a light version of Update output names to match BIDS derivatives RC2 conventions #146.
  • t2sv.nii --> T2StarMap.nii.gz (given the BEP001 suffix)
  • s0v.nii --> S0Map.nii.gz (given the BEP001 suffix)
  • ts_OC.nii --> desc-optcom_bold.nii.gz (maybe)
• Release 0.0.9
• Change minimum tedana version in fMRIPrep to 0.0.9. Maybe just pin it to that version actually.
  • Not sure if there's anything we can do about fresh installs of old versions of fMRIPrep, except hope that people are using containers.
• Have fMRIPrep's T2SMap interface look for nii.gz files instead of niis.
• OPTIONAL: Remove t2star_adaptive_map and s0_adaptive_map from fmriprep.interfaces.multiecho.T2SMapOutputSpec. These aren't the adaptive maps actually- they're the "full" ones.
• OPTIONAL: Switch to nonlinear fit in T2SMap interface. There's a minimal time cost and the results should be better.

[tsalo]

How does everyone feel about the proposed changes here?

[dowdlelt]

I have no concerns - in fact, more descriptive names can only be beneficial (other than breaking scripts). Gets my thumbs up.

[tsalo]

On a related note, t2smap_workflow does not use --out-dir, and implementing this would alter the default output directory and thus fMRIPrep.

Also, our T2* maps will now be in seconds (#525). @emdupre do you think that will cause problems for fMRIPrep's --t2s-coreg (above and beyond its current issues)?

[emdupre]

The map being in seconds won't cause any isues as far as I can see. Setting an outdir might since fMRIPrep has a series of DataSinks they set up in the background to move results around. But, if we set outdir to the current working directory in our call then behavior should proceed as expected.

As a light tangent: I think the decision was to remove --t2s-coreg as an option (see the discussion here: nipreps/fmriprep#1786 (comment) ), so I wouldn't worry about impacting that parameter in particular.

Just to be clear, though: we still create a T2StarMap and optimal combination in fMRIPrep even if --t2s-coreg isn't called (if multi-echo data is supplied); it's just that we don't use that T2StarMap in coregistration. Instead, we "just" pass around the optimal combination as our "bold" file; for example, here:

https://github.com/poldracklab/fmriprep/blob/8a10be0dd46fb1db98b217e5575908f1b3966bc1/fmriprep/workflows/bold/base.py#L696