Open
Conversation
Previously, alterations to the gradient table were evaluated exclusively based on axis permutations and flips, in either the real / scanner space or bvec basis. With this change, the command can additionally consider the prospect where the gradient table has been erroneously interpreted as containing coefficients in one basis when in fact those values should have been interpreted in the other basis. This error can be in addition to possible axis permutations and/or flips in one of the two bases. Further, the command will now yield a non-zero return code if it is determined to be likely that the input gradient table is inappropriate.
|
clang-tidy review says "All clean, LGTM! 👍" |
Member
|
I presume the title should say "dwigradcheck" instead of "dwishellmath"? |
Member
Author
|
🤦♂️ |
10 tasks
afacaf7 to
fd01c34
Compare
Conflicts: docs/reference/commands/dwigradcheck.rst python/mrtrix3/commands/dwigradcheck.py testing/scripts/CMakeLists.txt
|
clang-tidy review says "All clean, LGTM! 👍" |
- Re-generate command documentation. - Resolve additions to CLI with augmentations to Python CLI in #2678. - Resolve some poorly formed code logic identified by pylint. - Improve progressbar appearance when not printing to a terminal, consistent with #3137. - Fix export of optimal gradient table. - Increase tolerance on default test: because a greater spectrum of gradient table alterations are now possible, it is more probable that a table that is not precisely equivalent to the unmodified table will be selected due to chance, but this should not lead to test failure given the stochasticity of the command and the relatively small number of streamlines.
|
clang-tidy review says "All clean, LGTM! 👍" |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Am currently in the process of generating data & analyses for verifying the handling of DWI metadata, both raw and derivative, both slice / phase encoding and gradient table (especially with the pesky
bvecesoterics). Am aiming particularly for resolution of #2477 and for verifying correct interpretation of subsequently derived diffusion model fibre orientations in https://github.com/bids-standard/bids-bep016.A known limitation of the original implementation of
dwigradcheckis that it considered exclusively axis permutations and flips. It failed to consider the prospect of a historically common misunderstanding where a user believeddw_schemeandbvec/bvalsto be merely transposes of one another, and would therefore apply that operation erroneously. Here I've finally gotten around to addressing this. In retrospect it was not the most crucial of enhancements for me to put effort into, given that the dataset I'm working with always has image axes aligned with the scanner axes, but it was nevertheless annoying that the command was doing twice as much work as it needed to in that case. Plus I wanted to have the command emit a non-zero return code if it considers the input gradient table to be incorrect, as this allows me to use it for automated verification of metadata handling.