Add information about quantitative T2* mapping to documentation

[tsalo]

Summary

This is related to #407. We should provide some information on quantitative T2* sequences, and a couple of protocol PDFs if possible.

Additional Detail

High quality T2* estimates would be helpful for decomposition and component classification, so the ability to provide them as input is useful (i.e., #407). In addition, folks need to be able to actually acquire these data. I, for one, have no clue what sequence I would even use for this, even if I know that it is possible.

Next Steps

1. Add information about quantitative T2* mapping to the sequences section on RTD.
2. Discuss the benefits of higher quality T2* estimates in the tedana pipeline section on RTD.
3. Add a couple of example protocol PDFs (or whatever the preferred format is for each manufacturer) to the RTD. We can include a caveat about trusting these examples implicitly if necessary.
4. Support external T2* maps for the denoising workflow (Add ability to provide T2* map as input #407).

[tsalo]

Possibly useful papers:

• Ruuth et al. (2019): Describes attempts made to optimize acquisition parameters and post processing steps for a multi-contrast technique that primarily supports quantitative T2*.

[emdupre]

@dowdlelt do you have other suggestions for papers and/or places in the documentation we could add this info ?

[dowdlelt]

I actually don't, never done any T2* maps, other than with multiecho EPI.

Regarding the docs, I'm looking at #499 and thinking that there is an important point here. If we want to highlight using a precalculated t2smap with --t2smap its confusing to have a workflow t2smap, imo. Makes me want to push for #499 a bit more.

It would make sense to have it where @tsalo points at, I think right after
sequences. Perhaps by making an Available T2Star mapping sequences, with details on the sequences and then linking to the portion of the workflow here that has the t2smap argument? And adding extra details highlighting that this can be a higher quality version? Assuming I'm understanding usage right...

I'll see if I can find out about T2* mapping at 3T.

[tsalo]

@emdupre would any of the BEP-001 folks know about T2* mapping (since it falls under that extension)?

[emdupre]

@emdupre would any of the BEP-001 folks know about T2* mapping (since it falls under that extension)?

Definitely ! Not sure if @KirstieJane has specific suggestions and / or references to add, but I know @agahkarakuzu and I have chatted T2* mapping in person, so he might have a few references on benefits and/or access to standard protocol sequences !

[agahkarakuzu]

@emdupre Traditional way is to collect a multi-echo GRE dataset (e.g. multi-echo FLASH stock sequence | BEP001 has MEGRE suffix to group these inputs ) and fitting it to an exponential decay curve for T2* estimation:

It sounds easy, but T2* fitting is actually trickier than it sounds. There are some details to watch out for: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3442114/.

Luckily, this paper comes with a repo:
https://github.com/neuropoly/t2star-mapping

I will soon implement this in qMRLab, then probably write a blog post about it.

[tsalo]

@agahkarakuzu Thank you very much for the information. It will be great to include links to these software in our documentation.

The qMRLab implementation will be in MATLAB, right?

[agahkarakuzu]

@tsalo no worries! Yes, the implementation will be in MATLAB, but our codebase is almost totally Octave compatible.

If I can implement this for v2.4.0 release, there will be some Docker images for that:

https://hub.docker.com/orgs/qmrlab

I am also happy to write a workflow if you are planning to use it.

[tsalo]

@agahkarakuzu I think a workflow would definitely be beneficial for the community, although I'd like to see what elements can be incorporated into tedana directly. The actual monoexponential fit is pretty similar to what we have implemented (although perhaps with different initial values and/or limits), but the use of phase data is really interesting. I wonder how well it would translate over to complex, multi-echo EPI data.

Of course, we still want to document and link to other tools for multi-echo acquisition and analysis, so we will make sure to add information about qMRLab's implementation once that's up and running.

[agahkarakuzu]

@tsalo sure, as long as implementations are similar, I am in favor of having them in several languages.

I wonder how well it would translate over to complex, multi-echo EPI data.

I've never done T2* fitting using EPI readout, I just know that there are some cardiac applications. Yet it is obvious that the EPI approach will be more susceptible to B0 effects compared to a standard ME-GRE. So, the signal correction is of high value. I am not sure to which extent it can compensate in the EPI case, but worths a try. Reducing the contribution of later echoes is quite relevant, discarding some of the echoes based on a threshold can be considered as well.