-
Notifications
You must be signed in to change notification settings - Fork 97
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add recommendations for distortion correction #896
Changes from all commits
dc76f0d
3ce9142
3ed70ec
e8f58f2
a4ab46e
f7bdaa2
2468c26
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -193,3 +193,22 @@ Yes, these techniques are complementary. | |
Multiband fMRI leads to collecting multiple slices within a volume simultaneously, while multi-echo | ||
fMRI is instead related to collecting multiple unique volumes. | ||
These techniques can be combined to reduce the TR in a multi-echo sequence. | ||
|
||
******************************************************************************** | ||
[ME-fMRI] How do field maps and distortion correction work with multi-echo fMRI? | ||
******************************************************************************** | ||
|
||
There are many different approaches to susceptibility distortion correction out there- far too many to discuss here. | ||
However, the good news is that distortion does not typically change across echoes in multi-echo fMRI. | ||
In most cases, the readout acquisition type and total readout time are the same for each echo, | ||
so distortion will remain relatively constant, even as dropout increases with echo time. | ||
|
||
What this means is that, in the vast majority of multi-echo datasets, | ||
standard distortion correction methods will work, and should be applied in the same manner on all echoes. | ||
For example, if you acquire a blip-up/blip-down set of images for all of your echo times, | ||
you should use the first echo time's images to generate the undistortion transform, | ||
as long as that first echo has sufficient gray/white constrast to be useful for alignment | ||
(in which case, use the earliest echo that does have good contrast). | ||
|
||
For context, please see | ||
`this NeuroStars thread <https://neurostars.org/t/multi-echo-pepolar-fieldmaps-bids-spec-sdcflows-grayzone/23933/5>`_. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I like the idea of starting to link to NeuroStars from our docs so that people know to go there with questions and we don't have to reword entire discussions with examples in the docs. |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -462,6 +462,19 @@ time point. | |
research to better understand how these steps can be applied before denoising. | ||
|
||
|
||
4. Apply susceptibility distortion correction consistently across echoes | ||
======================================================================== | ||
|
||
One key feature of susceptibility distortion is that it is primarily a factor of readout pattern and total readout time, rather than echo time. | ||
This means that, for most multi-echo sequences, even though dropout will increase with echo time, | ||
distortion will not (at least not to a noticeable/meaningful extent). | ||
|
||
For this reason, if you are applying TOPUP-style (blip-up/blip-down) "field maps", | ||
we recommend using your first echo time, as this will exhibit the least dropout. | ||
If your first echo time is very short, and exhibits poor gray/white contrast, then a later echo time may be preferable. | ||
In any case, you should calculate the spatial transform from just one of your echoes and apply it across all of them. | ||
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Lots of repetition in these two files. Not sure if we should add the warning about nonlinear transforms here as well. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think this is ok, given that the nonlinear issues are relatively rare (I think and also hope). It also seems that the fix for this would not be on the users to generate special workflows, but instead on AFNI/fmriprep to run or save things at specific stages. |
||
|
||
.. _fMRIPrep: https://fmriprep.readthedocs.io | ||
.. _afni_proc.py: https://afni.nimh.nih.gov/pub/dist/doc/program_help/afni_proc.py.html | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this apply when the same transform is applied to all echoes? It seems like this is the problem our recommendation is meant to address.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I saw this issue on a dataset a while back that had non-trivial intensity inhomogeneity from the surface to the center of the brain. Even though interpolation is calculated using the same voxels in all echoes, the interpolation affected each echo a bit differently and messed up the relationship between the echoes. I really don't know how systematic or serious this issue is, but I've generally been cautious on using aggressive non-linear interpolations before combining echoes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like this has to be rare, though that observation does worry me. The main issue I see with stating something like it is preferable to avoid non-linear alignment is that this is in direct contrast with the default settings in AFNI, for example.
That said, I think the suggestion is good, because it will keep people on their toes. It does make me think it might be an issue that needs to be raised with AFNI in regards to what data goes into tedana (though its possible I missed some of the flexibility there).