Skip to content
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

Merged
merged 7 commits into from
May 22, 2023

Conversation

tsalo
Copy link
Member

@tsalo tsalo commented Nov 10, 2022

Closes #894.

Changes proposed in this pull request:

  • Add a FAQ on distortion correction.
  • Add a subsection to the multi-echo processing section on distortion correction.

@tsalo tsalo added the documentation issues related to improving documentation for the project label Nov 10, 2022
@codecov
Copy link

codecov bot commented Nov 10, 2022

Codecov Report

Patch coverage: 96.18% and project coverage change: -4.34 ⚠️

Comparison is base (fb6e255) 93.30% compared to head (2468c26) 88.97%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #896      +/-   ##
==========================================
- Coverage   93.30%   88.97%   -4.34%     
==========================================
  Files          28       27       -1     
  Lines        2346     3373    +1027     
  Branches        0      617     +617     
==========================================
+ Hits         2189     3001     +812     
- Misses        157      226      +69     
- Partials        0      146     +146     
Impacted Files Coverage Δ
tedana/decomposition/pca.py 76.61% <ø> (-12.91%) ⬇️
tedana/utils.py 94.59% <ø> (-2.71%) ⬇️
tedana/reporting/html_report.py 91.39% <60.00%> (-8.61%) ⬇️
tedana/reporting/static_figures.py 96.34% <66.66%> (-2.45%) ⬇️
tedana/docs.py 77.35% <77.35%> (ø)
tedana/reporting/dynamic_figures.py 96.05% <81.25%> (-3.95%) ⬇️
tedana/workflows/tedana.py 80.95% <85.71%> (-8.68%) ⬇️
tedana/io.py 87.37% <87.35%> (-6.64%) ⬇️
tedana/workflows/ica_reclassify.py 97.79% <97.79%> (ø)
tedana/selection/component_selector.py 99.01% <99.01%> (ø)
... and 7 more

... and 14 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

dowdlelt
dowdlelt previously approved these changes Nov 10, 2022
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).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
One potential issue is that the nonlinear spatial transforms that are part of distortion correction methods have the potential to skew the relationship between echoes. Specific examples of nonlinear alignments causing problems have not yet been observed.

Copy link
Member Author

@tsalo tsalo Nov 19, 2022

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.

Copy link
Member

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.

Copy link
Collaborator

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).

(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>`_.
Copy link
Member

Choose a reason for hiding this comment

The 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.

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.

Copy link
Member

Choose a reason for hiding this comment

The 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.

Copy link
Collaborator

Choose a reason for hiding this comment

The 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.

Co-authored-by: Dan Handwerker <7406227+handwerkerd@users.noreply.github.com>
@jbteves
Copy link
Collaborator

jbteves commented Nov 23, 2022

@tsalo since we have the 3.10 checks now, I made it mandatory, looks like your PR accidentally got caught. If you merge in main it should run and pass.

@tsalo
Copy link
Member Author

tsalo commented Nov 23, 2022

Thanks @jbteves!

Copy link
Collaborator

@dowdlelt dowdlelt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is good to go - there is enough detail there, even if it will require some (slight) modification in the future as more edge cases are discovered. I think it would be worth including Dan's suggestion about potential nonlinear issues, so that we have a warning there that we can build on in the future.

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.

Copy link
Collaborator

Choose a reason for hiding this comment

The 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.

@dowdlelt
Copy link
Collaborator

I maintain my approval here - but I will note that section 3 (which was left unchanged, and encourages distortion correction and normilization to be applied after tedana) somewhat disagrees with the new section 4. I don't think it is a major issue worth holding this up, but it just reflects that this isn't super tested.

@handwerkerd
Copy link
Member

I'm going to merge this and we can tweak this text a bit more as part of #948

@handwerkerd handwerkerd merged commit 9a3b83f into ME-ICA:main May 22, 2023
@handwerkerd
Copy link
Member

New text is here: 290a7a8

I removed the recommendation to do distortion correction & normalization after tedana and I added a bit about normalization to the text on distortion correction. I also switched 3 & 4 & so we talk about what to do before tedana before talking about what goes after. The note was adjusted to justify why we do recommendation normalization & distortion correction first, but is retained as a warning to keep an eye on potential issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation issues related to improving documentation for the project
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add info on distortion across echoes to documentation
4 participants