fMRIPREP + TEDANA Status of things as of April 2019?


Hi guys,

I used fMRIPREP 1.26 to preprocess some multi-echo data. We noticed it output a single preprocessed, T2*-weighted combined dataset per sub/ses. Although this is wonderful, I see it precludes users from using TEDANA for denoising, as that would require having separate echoes. I’ve seen a previous thread suggesting a manual extraction of files from the fMRIPREP work directory. I was wondering if this is still a recommended workaround, and if yes, which files should I be looking for exactly?

Furthermore, if I do get these files out of fMRIPREP’s working directory, what would the recommended pipeline for TEDANA processing look like? No highpass / no smoothing, I guess? Should I then detrend the denoised data afterwards?

On a more practical level, as of April 2019, would you guys think TEDANA is the way to go or should I just use another denoising strategy for the combined dataset and be done with it?

Thanks for your time and for your willingness to help.



Hi @dangom, thanks for the interest. I want to rope in @emdupre and @tsalo for their opinions. If the problem is simply that there are files in our working directory that need exposing for TEDANA to be usable, that may be worth doing even if it’s not the long-term goal. But I’m not positive what current plans and timeline are.



Hi @dangom,

Thanks for reaching out ! And for the tag, @effigies !

The choice to not incorporate tedana denoising into fMRIPrep was a conscious one. Given that fMRIPrep is geared towards robustness – and our lingering concerns as to whether tedana denoising was (yet) able to produce robust results – we decided not to include it for now.

tedana denoising is currently drawn from ME-ICA denoising. So, if you have previously used ME-ICA and were happy with it in your own data, you should be happy (or even happier) with tedana. In our experience, however, ME-ICA denoising will systematically fail for certain types of data (block-design tasks immediately come to mind, here). That being said, we are actively working to improve the selection process, see for example:

We also have incorporated visualizations to help researchers inspect each component and determine whether or not it should have been accepted / rejected; you can then feed in the corrected selections using our --manacc option.

As you pointed out, we have developed workarounds to grab the correct files from the working directory. This is particularly useful for researchers who have had good results with ME-ICA. For that, I’d point to a script we started on grabbing the correct files from the working directory:

The files you’re grabbing should be unsmoothed with no highpass filtering, and you shouldn’t need to detrend the denoised data after tedana.

On a practical level, I strongly recommend using the optimal combination with multi-echo data. This method is already incorporated into fMRIPrep by calling tedana internally to run t2smap. This is very robust and unlikely to change.

Regarding denoising, if you have had good experiences with MEICA and are willing to visually inspect your components, I think that tedana offers very powerful potential for denoising your data. If, however, you cannot commit to that or have had mixed experiences with MEICA in the past, I would recommend you use more traditional denoising methods on the optimally combined dataset.

Hopefully this clarifies things ! Please let me know if you have any other questions.




Hello and sorry to jump in on this thread,

I was wondering whether I could ask a few follow-up questions relating to @emdupre 's reply:

  1. Great to hear the tedana allows visual inspection of components. With regards to the --manacc option, is the idea to a) run tedana, b) inspect and classify noise and signal components, c) run tedana again, now with the --manacc option ??

  2. Thank you for supplying a script to grab the required files for tedana. Are the files being grabbed already optimally combined? Ie., can tedana recognise that the initial steps have already been run and only ICA-denoising is required? tedana would like non-sdc images. Are these the ones being grabbed in this script?

  3. fmriprep offers ICA-AROMA denoising. Is this recommended with multi-echo data? I have run it on my multiecho dataset I can see it has run without errors. Looking at the html report it looks like it may be running correctly. However, I would like to manually check the AROMA-classified components but cannot locate the required melodic files. I can only find the melodic.ica file for each of the individual echos. Is there a melodic.ica for the optimally combined time-series? If not, how does fmriprep combine the melodic components for the optimally-combined dataset?

Kind regards,



That is probably the best way to do this at the moment.

The files being grabbed by the script should be the native-space preprocessed echo-specific data, prior to optimal combination. Tedana still needs echo data to do denoising, even after optimal combination, so you can’t run tedana on optimally combined data alone.

Unfortunately, I think that the data that will be grabbed are distortion corrected. That’s not optimal for tedana, but I don’t think it’s a major problem. The data being grabbed should be slice timing corrected, motion corrected, and distortion corrected. The transforms necessary for coregistration and normalization should also be grabbed by the script, and you can apply those transforms to the denoised data after running tedana.

We’ve been looking into incorporating AROMA metrics into tedana’s denoising, but in the meantime I don’t see anything particularly wrong with running AROMA on the optimally combined or denoised data. It’s just a matter of employing multiple denoising steps sequentially, which isn’t great.
I don’t know how AROMA and tedana are set up within fMRIPrep (@emdupre would know better), but I don’t think it’s a good idea to run AROMA before tedana, so if that’s how it’s currently set up it might be worth trying to switch the order.