Remove accepted and rejected time series from the standard file outputs

[handwerkerd]

Summary

The terminology for the 'denoised' vs 'accepted' time series is confusing to end users and saving both of these files is a waste of space most of the time. The proposal is to stop saving these time series and making the documentation a bit more explicit on how an end user can generate these files as needed.

This is based on a comment by @emdupre in the Oct 2021 dev call.

Next Steps

• Decide if others agree to move forward on this
• Decide if there's anything we can do to make it easier for an end user to generate and save these files or, if it's already easy enough, clearly document how to do it.

[tsalo]

👍 to remove optcomAccepted and optcomeRejected, but I don't want to remove optcomDenoised (though renaming it to just denoised might be nice). Based on the issue name I assume that's what you're proposing, but in the summary you mention "denoised" specifically, so I wasn't sure.

[jbteves]

Proposal:

1. Remove optcomAccepted, optcomRejected.
2. Rename optcomDenoised to denoised, enhance file description on ReadtheDocs and perhaps add that to the metadata we generate for BIDS derivatives.
3. Document this as a difference between tedana and ME-ICA.
4. Create a set of example code for how to generate the other time series. If someone is ambitious, perhaps a Jupyter notebook?

[tsalo]

Love it! If we're focusing on the denoised data, then we can even document it like AROMA. For example, we could distinguish between aggressive and non-aggressive denoising, and show how to do both in our documentation.

EDIT: Regarding the denoising documentation, check this out: https://me-ica.github.io/multi-echo-data-analysis/content/08_ICA_Based_Denoising.html

It turns out there's a cool Sphinx extension for tabs! We can use them to document Python-based, AFNI-based, FSL-based, etc. implementations of the same thing!

[tsalo]

It actually turns out that fMRIPrep names the AROMA-denoised files as "desc-smoothAROMAnonaggr_bold.nii.gz". If we want to be consistent with their naming convention, instead of desc-denoised, we might want to call it desc-TEDANAnonaggr? Does that sound better or worse than desc-denoised?

[jbteves]

I am admittedly not an fMRIPrep user and therefore a smidge biased, but I really don't want to explain the logic behind desc-TEDANAnonaggr to new users when desc-denoised is much more clear.

[tsalo]

@jbteves I think you're right! desc-denoised is much clearer.

[handwerkerd]

I do not want file names with things like nonaggr because we don't actually know what our non agressive vs agressive options are yet and we're also giving users options to create their own denoising methods. I'd also lean towards sticking with denoised and - maybe - giving users a way to give a more specific label.