Preprocessing multi-echo data with RABIES?

[davidgruskin]

Hi all,

I've just started to collect multi-echo data and would like to eventually preprocess those data with RABIES for consistency with my single-echo datasets. I was wondering if any RABIES users have already figured out a solid pipeline that incorporates RABIES and multi-echo-specific software (e.g., tedana, AFNI's meica.py), and/or if there's any interest in building multi-echo compatibility into RABIES preprocess itself. I imagine the latter wouldn't be too difficult (basically, just adapting motion realignment to use only parameters from the first echo and then running the rest of the pipeline on a single, optimally combined dataset), but I figured I should check here first before diving into all that.

Thanks!

-David

[Gab-D-G]

Hey David,

thanks for reaching out on this. I have not worked with multi-echo data myself, and I am not aware that someone has done it before with RABIES, but there is definitely interest in integrating this in RABIES.
If you're interested in working out a workflow for multi-echo, I would be happy to help figuring out how to integrate it in RABIES.

Best,
Gabriel DG

[davidgruskin]

Hi Gabriel,

Sounds good! I'm a bit new to nipype, but I imagine I can figure out a preliminary workflow based on fmriprep's multiecho pipeline and will reach out again once I've made some progress with that.

[Gab-D-G]

that would be an awesome contribution, let me know if I can help! Perhaps as a simple template you can take a look at the slice-timing correction file, which is a simple workflow with one node https://github.com/CoBrALab/RABIES/blob/master/rabies/preprocess_pkg/stc.py. It has the basic syntax we use in RABIES (inspired from fMRIPrep), it could be adapted for any function we want to run.

[davidgruskin]

@Gab-D-G Just a heads-up that I'm working on a multi-echo preprocessing pipeline over in this repository following guidelines from tedana and fmriprep. Because my primary goal right now is to get this pipeline set up such that I can preprocess my own data, I’ve been a bit nonchalant in my approach, but I’d be happy to work with you and the rest of the team to refine the code and improve the compatibility with the rest of RABIES so that these edits can eventually be folded into the main repo.

As of right now, I'm able to preprocess my own multiecho data without any errors, but I'm limited in my ability to test out various parameters as I'm working on my personal PC (so limited compute power) and haven't gotten around to building a docker image (and I'm running into some dependency issues that prevent me from running certain workflows, like inhomogeneity correction). I’d be happy to start integrating those other workflows/pipelines with the multi-echo pipeline, but given that I had to make a number of changes to the overall organization of the main and bold processing workflows to make them multi-echo compatible, I think it would make sense to get your feedback on my current edits before building out those functionalities.

I think the biggest change is probably how bold files are indexed and processed- because tedana recommends applying motion correction parameters from the first echo to subsequent echoes, I’ve serialized the processing of multiple echoes for a given run (while hopefully retaining parallel processing of different runs, but I can’t check this yet due to the aforementioned limitations) using workflow clones. I imagine there’s probably a more elegant way of doing this with iterables and joinnodes/mapnodes, but I’m still learning the ropes of nipype and haven’t yet figured out a better solution. Because tedana recommends saving normalization for once the echoes are optimally combined into a single nifti, I’ve added transformation workflows that independently perform motion realignment (in which all echoes are realigned according to parameters estimated from the first echo) and coregistration/normalization (in which the optimally combined nifti is registered and normalized without repeating another motion realignment step.). There appears to still be some debate re: whether or not this approach is optimal (vs. combining all the transformations into a single step), and some users might want to analyze derivatives from individual echoes, so I’ve retained the original combined resampling step as well.

I have a list of features I’d like to implement for my own processing which I’ll continue to work on, but I’ll hold off on bigger stuff until I hear back from you. Please let me know if you notice any significant issues that limit the compatibility between my repo and the rest of RABIES, and also if you’d like me to organize the multi-echo development better (e.g., by creating a task list or similar).

Thanks so much!

[Gab-D-G]

Hi David,

First of all, sorry for being so slow to come back to you on this. I was on vacation, and then had to catch up with various things. Secondly, thank you so much for sharing this, this is awesome!! I am definitely interested in figuring out how to integrate this appropriately into the main repository. I don't think it will be very challenging, but we'll have to work together.

First of all let's clarify what the multiecho workflow will need so we're on the same . Here's my understanding for what's needed:

1. Estimate motion from the first echo, and apply those the same correction on all echos
2. After motion correction, combine the echos into a single BOLD image, and use this image for normalization (because of improved anatomical contrast?)
3. We want to provide both a preprocessed combined image, as well as preprocessed individual echos as outputs, as users may have different needs

Please correct me if I'm misinterpreting or missing anything, but assuming this is correct, here are the modifications I envision to achieve this optimally:

1. Generating a 3D EPI for normalization; two modifications to the current function: 1) computation of a 3D average: generate a combined BOLD from multi-echos before generating a temporal average (unless combining the echos is computationally intensive?), 2) motion correction before computing the average: the first echo is used for estimating motion, and motion correction is applied to all echos before generating a combined BOLD. This way, we obtain a 3D EPI reference combining the echos, which can then be used for normalization
2. Head motion estimation: feed the first echo as moving image, and the 3D ref image (combined echos) as reference for the complete motion estimation
3. Resampling: 1-apply motion correction to all echos then create a combined image, 2-apply the remaining normalization steps to the combined image to obtain preprocessed BOLD, 3-apply the normal RABIES resampling to each echo individually for separate outputs (i.e. motion + normalization in one shot)
   **Question regarding resampling: this is in line with tedana’s recommendation? Can you tell me more about how applying motion correction helps with combining the echos afterwards? My concern is that here we will be applying resampling in two separate steps (once for motion, and then for normalization), which thus adds an extra interpolation of the data.
4. I've also noticed you had to adapt the BIDS reader; we should revisit this as I have implement a new BIDS filter option allowing to provide further BIDS specs to select appropriate files. It only allows to read more specific files, and should be able to distinguish the echos, but doesn't read info from the .json files (not sure if this is needed).

If the recommendations above are sufficient, the updates would not be substantial. Let me know what you think, and if these sound reasonable to you, we can follow up in more details, and perhaps initiate a pull request to help us work on this together.

Finally, would you recommend somewhere to access multi-echo data for testing? It would probably help me to get my hand on some data to understand the needs.

[davidgruskin]

No worries, and thanks for the detailed response! Your understanding of the workflow is correct, the only thing I’d add is that slice timing correction should also be performed before the echoes are combined “because slice timing differences may impact echo-dependent estimates.”

Regarding your suggested modifications:

1. I think we can just pass in the 3D reference from the first echo (which is what fMRIPrep does)- combining the echoes isn’t computation intensive, but I think the lower dropout of the first echo might make it more suitable for motion estimation?

2. (see above)

3. Yes, this is correct. My understanding is that motion correction allows for more accurate T2* modeling (“we need the individual echos to be motion corrected before creating the optimal combination”), and motion correction would probably be essential before running ME-ICA, although I’m not sure if it’s worth thinking about that functionality yet. Below is the note from Tedana’s FAQs on this topic:

We are assuming that spatial normalization and distortion correction, particularly non-linear normalization methods with higher order interpolation functions, are likely to distort the relationship between echoes while rigid body motion correction would linearly alter each echo in a similar manner. This assumption has not yet been empirically tested and an affine normalzation with bilinear interpolation may not distort the relationship between echoes. Additionally, there are benefits to applying only one spatial transform to data rather than applying one spatial transform for motion correction and a later transform for normalization and distortion correction. Our advice against doing normalization and distortion correction is a conservative choice and we encourage additional research to better understand how these steps can be applied before denoising.

4. Independent of the BIDS reader, I created a node to extract the TE from JSON files, as this information is necessary to properly combine the different echoes (although I suppose we could also ask users to specify the TEs in the call to preprocess, but this would be hairy for datasets with different EPIs).

Something else to consider- right now, I’m using the optimally combined dataset for nonlinear registration/SDC, but it might make sense to use the first echo instead due to less dropout.

I’d be happy to work with you on a formal pull request, although I’m still not exactly sure how to process (in parallel) BIDS directories containing EPIs with different numbers of echoes. fMRIPrep solves this issue by inputting all the echoes from each run to the various preprocessing sub-workflows, but as of right now it seems like the RABIES workflows accept only one .nii as input. My pipeline will currently only process the EPIs with the most echoes, so that would probably be the first thing to figure out before we move on to adjusting specific workflows.

Finally, I think the data from Grandjean et al., 2017 would work nicely for testing things out!

[Gab-D-G]

Awesome, it should be relatively straightforward then. We can feed the first echo through the normal preprocessing workflow up until the resampling step, and create a new multi-echo sub-workflow to handle resampling and combining the multi-echos.

After taking a good look at the current workflow, I think what makes most sense would be to modify bold_selectfiles such that it finds the first echo to take the place of the usual output, but then also output a list of all available echos for that scan. That list is fed to the multi-echo workflow, and inside the workflow we iterate through each echo in parallel before joining them when needed for combination.

If that sounds good with you, I would create a new branch and prepare a sketch for the multi-echo workflow, and create a multi-echo options which looks for the list of echos as mentioned above. From there, I can create iterable/joinnodes, and you could help me fill in the actual processing steps.

Let me know if that sounds good, and thanks again for your contribution!

Gabe