Multi-echo: replace CompCor with ME-ICA

[oesteban]

Comes from #891

[emdupre]

This will likely involve working with ME-ICA/tedana !

[emdupre]

tedana is gearing up for its first release 🎉
I could open a PR incorporating it here, since it will be available on pypi, but I have a few questions:

• MDP is still a dependency for tedana, although we're planning to remove this in a later release. Would you prefer to wait until this is updated, to avoid introducing another dependency ?
• I'm planning to just sub it out for the AROMA connections, and pass along the T2* map we're already generating. I don't think it makes sense to allow for both AROMA and tedana, but if you have thoughts otherwise, I'd love to hear them !

[tsalo]

Regarding the use of AROMA and ME-ICA, what if the ICA step was separated from the AROMA step? Tedana can perform its classification on existing decompositions, as long as they're in the right format, which should be BEP012-compatible. I know that there are plans to replace the current AROMA dependency (#1784), so as long as the new implementation can accept BIDS-compatible decomposition files, then component classification (whether tedana or AROMA) becomes modular.

Tedana outputs its classifications in addition to the denoised data, so if fMRIPrep retained the classifications and the decomposition file(s), but not the denoised data, then the tedana-selected noise components could be retained in the confounds file just like AROMA noise components, and users could denoise the preprocessed data as they see fit.

[effigies]

@tsalo We have a user that wants to use fMRIPrep + Tedana denoising. Right now, they're extracting files from the working directory, denoising, and resampling. From your comment, it sounds like an alternative approach (short of doing this correctly inside fMRIPrep) would be for them to create confounds and write them out in TSV files. Is that correct, and is it as simple as performing MELODIC on the optimal combination that comes out of the T2SMap node?

[tsalo]

For tedana denoising, you need the STC+MC echo-wise files in native space in order to calculate the metrics necessary for the classification step. While tedana does support external ICAs like MELODIC, you still need access to the partially preprocessed echo-wise data.

Our current recommendation is to grab those files from the working directory, like this user is doing. Then, they could either (1) use the mixing matrix and classifications to clean up the fMRIPrep-outputted optimal combination file if they wanted (which is along the lines of my idea from the previous comment) or (2) apply the necessary transforms to the native-space denoised file outputted by tedana.

[effigies]

@tsalo If it works for y'all, I'd like to set up a cross-project meeting, where we figure out the use cases that we want to support and make a roadmap. I suspect this isn't going to be too difficult, we just need to get coordinated. Can do meeting planning on this thread or elsewhere...

[tsalo]

I think that's a great idea.

Tagging @ME-ICA/tedana-devs (inter-org team mentions really should work...): @handwerkerd, @eurunuela, @emdupre, @dowdlelt, @jbteves

[jbteves]

Happy to attend, this would be a big step forward for everyone using fMRIPrep and tedana. That said, I have no knowledge of fMRIPrep so I'm unsure of what I can contribute.

[oesteban]

Hi, I @eilidhmacnicol and I recently reached out to @emdupre and Javier proposing a meeting. So I'll prepare a doodle and have both meetings (in reality one, just that @eilidhmacnicol has specific questions about rodents) together.

[oesteban]

Doodle here - https://doodle.com/poll/w538nyhiyagdm4ha?utm_source=poll&utm_medium=link I'm very excited about seeing this happening!

[effigies]

It's shaping up that 10am EDT (UTC-4) on Friday Sept 10 or Wednesday Sept 15 are the clearest times. Unless there's a strong objection by someone who hasn't yet weighed in, I'd propose Friday just to keep things moving.

In any case, is there an existing agenda document or should I create one?

[oesteban]

It's shaping up that 10am EDT (UTC-4) on Friday Sept 10 or Wednesday Sept 15 are the clearest times. Unless there's a strong objection by someone who hasn't yet weighed in, I'd propose Friday just to keep things moving.

Sounds reasonable

In any case, is there an existing agenda document or should I create one?

Not yet, but it would be great you and/or @eilidhmacnicol put an agenda together :)

[effigies]

Now looking like there's someone who can't make Friday, so let's plan on Wednesday. Sorry for the noise.

Here's an agenda outline. Please feel free to add points and aggressively reformat to ensure the conversation gets us where you think we need to go.

[eilidhmacnicol]

Thanks for the tag @oesteban and thanks to @effigies for creating an agenda.

I've added a point for fmriprep-rodents; I don't expect this to take up much of the meeting, but by carving out some time to ask a few questions and explain my experiences, I hope we can open a channel for future, more in-depth talks :)

[handwerkerd]

I was planning to attend this meeting, but an internal work meeting was just scheduled at the same time. I'm not sure how much use I'd be since I'm not an fMRIPrep user, but if there are things you want me to comment on in advance or afterwards, let me know.

[handwerkerd]

I just got a bit of an update about last weeks meeting from @jbteves While it's on my mind I wanted to add a few comments here.

1. For @eilidhmacnicol's rodent data, I can't think of anything in tedana where rodent data should specifically violate the current assumptions in the component selection process. Some thresholds are arbitrary and brittle and may be causing problems (Fixing that is one of my high priorities). As part of that process, it would be good to know how/where things are failing for rodent data. If you can open an issue on https://github.com/ME-ICA/tedana with more info, that might help us.
2. I am planning to work with a post-undergraduate trainee to integrate AROMA's component classification method into tedana. In the medium term, I've given up on a full replication of their code because I don't want to deal with running both the MELODIC PCA dimensionality reduction and the MA-PCA reduction on the same data. If someone wants to convert the PCA method from MELODIC into a freestanding python library, like we did with https://github.com/ME-ICA/mapca from GIFT, that might make a closer replication more realistic. Also, the current AROMA code is really locked into FSL in some unnecessarily rigid ways and requires things like using brain and CSF masks from a template rather than more accurate subject-specific masks. If I'm re-implementing, I see no reason to include those same inflexibilities. If others are interested in making a cleaner version of AROMA, I'd be very happy to have more help.

[eurunuela]

@handwerkerd Re point 2: @tsalo and I were thinking of using MA-PCA and have already started dropping all the FSL calls. You can see how far we've gone on the repo under ME-ICA here: https://github.com/ME-ICA/aroma

This was an effort made during last year's Brainhack Donostia event, with the help of @oesteban and @vinferrer and our goal was fully replicate their code. I was thinking of working on the project during this year's Brainhack Donostia edition, which will take place online on Nov 22-24 (I have actually submitted the project for the event).

How about we meet sometime next month and come up with a plan?

[handwerkerd]

@eurunuela Happy to meet & discuss more next month. It does seem best if this port is separate from other packages so that it can be run with fewer dependencies like FSL.

[eilidhmacnicol]

@handwerkerd - I absolutely agree that theoretically nothing is different for rodents (it's one of the reasons that preclinical MRI is one of the best translational tools science has! ☺️) but, in my experience, overlooked default parameter values can derail a workflow for rodent images.

I will open an issue next week once I've tried running it with the most recent release (and with the minimal decision tree). Myself and a colleague acquired some toy data this week, while scanning for another project, so I will share the raw data and derivatives once I've had a chance to look at it.

[tsalo]

I think this can be closed in favor of working on an fMRIPost workflow (e.g., fMRIPost-tedana).