fMRIPREP + TEDANA Status of things as of April 2019?

[dangom]

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.

[effigies]

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.

[emdupre]

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: https://github.com/ME-ICA/tedana/issues/153.

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: https://github.com/ME-ICA/tedana-reliability-analysis/blob/master/collect_fmriprep.py

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.

Elizabeth

[gspitz]

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,
Gershon.

[tsalo]

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 ??

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

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?

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.

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?

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.

[agnesnorbury]

Hi @emdupre and @tsalo

Thanks so much for this information (and various replies below) - this is incredibly helpful.

I have a quick question regarding SDC for multiecho data using fmriprep, if the intention is to pass the intermediate (partially processed individual echo) files to tedana for further analysis.

On my understanding, it is not optimal to run any form of SDC prior to tedana, but it is particularly important not to apply any form of correction that will shift the mean of or separately scale the values in each echo image independently.

In my current dataset, there are several AP functional runs, each of which is preceded with a short PA scan of otherwise the same sequence, which I have been using to apply PEPOLAR SDC as part of fmriprep (v1.4.1). As both the functional runs and opposite PE scans are multiecho, I have previously been setting the “IntendedFor:” field of the PA image sidecar .json files to relate to relevant AP functional run, on an individual echo basis, e.g.:

• fmap/sub-001_task-faceStroop_dir-PA_run-01_echo-1_epi.json
  “IntendedFor”: [“func/sub-001_task-faceStroop_dir-AP_run-01_echo-1_bold.nii.gz”,
  “func/sub-001_task-faceStroop_dir-AP_run-02_echo-1_bold.nii.gz”],

• fmap/sub-001_task-faceStroop_dir-PA_run-01_echo-2_epi.json
  “IntendedFor”: [“func/sub-001_task-faceStroop_dir-AP_run-01_echo-2_bold.nii.gz”,
  “func/sub-001_task-faceStroop_dir-AP_run-02_echo-2_bold.nii.gz”],

In the fmriprep log output, it seems that based on this specification, pepolar SDC is applied separately for each echo, prior to downstream steps (e.g. optional combination). However, I’m now thinking that this behaviour might be exactly what is not recommended prior to tedana, and might also be affecting the optimal combination workflow.

Would you recommend in this case that I choose one opposite PE image (e.g. echo-1) to correct for all the echos of a functional run? Or should I avoid using SDC altogether in this case?

Thanks so much,

Agnes

[agnesnorbury]

Update: I found some helpful info about this issue here:

Blipup Blipdown distortion correction on multiecho data

I’d recommend applying the same spatial transform to each echo. A fundamental assumption of multi-echo analyses is that the data in each voxel represents the same underlying anatomical volume, just at a different echo time. Applying different spatial transforms to each echo would violate that assumption. That said, spatial distortion can increase with echo time, which would also violate that assumption. A blipup blipdown correct might be able to correct for this issue and actually result in mor…

It seems that although B0 spatial distortion may vary with echo time (depending on sequence), the currently recommended approach is to use a single transform (e.g. echo-1) for all images.

(sorry - I previously searched pepolar so rather than blip so missed this response!)