open-discussion
open-discussion > RE: Using QC xml interlace and gradient angle/translation values in determining protocol thresholds
Mar 13, 2023 08:03 PM | Martin Styner
RE: Using QC xml interlace and gradient angle/translation values in determining protocol thresholds
Hi David
The Gradient_check is run after the motion correction and looks at residual motion still present (and this is done via an alternative registration/motion correction method applied to the motion corrected data). Not fully sure, but it looks like you are looking at the recovered motion from the motion correction step?
But, in any case, we recommend to disable the gradient_check step, as it is not robust enough, in particular for high b-value DWI volumes (which we have in most of our sequences). So, I would simply skip that step of DTIPrep (while keeping the slice and interlace checks).
In the next-gen DTIPrep (called dmriprep, which is part of dtiplayground https://dtiplayground.readthedocs.io/en/... , it is still under beta release, and combines the processing of DTIPrep and FSL and more), the gradient check is no longer available for the same reason.
Best
Martin
Originally posted by David Stephenson:
The Gradient_check is run after the motion correction and looks at residual motion still present (and this is done via an alternative registration/motion correction method applied to the motion corrected data). Not fully sure, but it looks like you are looking at the recovered motion from the motion correction step?
But, in any case, we recommend to disable the gradient_check step, as it is not robust enough, in particular for high b-value DWI volumes (which we have in most of our sequences). So, I would simply skip that step of DTIPrep (while keeping the slice and interlace checks).
In the next-gen DTIPrep (called dmriprep, which is part of dtiplayground https://dtiplayground.readthedocs.io/en/... , it is still under beta release, and combines the processing of DTIPrep and FSL and more), the gradient check is no longer available for the same reason.
Best
Martin
Originally posted by David Stephenson:
Hello Martin,
We are currently exploring DTIPrep for QA/QC of our research diffusion data, and had a question about the interpretation of the gradient specific angle and translation values (x/y/z) within the DTIPrep xml QC output.
For our data, we noticed we were getting a number of excludes ('Too many gradient excludes' using the default 20%) where the same comparison in FSL using eddy_quad showed a relatively clean image.
In looking at the xml QC output file using the DTIPrep GUI, we noticed within the Gradient_check FAIL section, the dropdown list of angle/translation xyz would be color coded green and red. I assume that green means that it passed the rotation/translation tolerance in the protocol file, and red means that it was above this tolerance threshold.
However, when we plotted these values within angle/translation metrics (across subjects), we expected that all or most of the gradient FAIL individuals would be on the outlier tails of the distribution, but these plots indicate that, even for those where it indicates the angle/translation was beyond tolerance threshold, that the angle/translation x/y/z values are within the distribution of those individuals who passed all tolerance thresholds and had all global pass flags (i.e. More than #6, Too many bad gradients=FALSE). Plots are attached for our 12ch data gradientwise checks.
We were going to use this information to determine what we could change/relax the gradient rotation/translation tolerances too, but given that there is not a clear relationship between gradient rotation/translation tolerance failure and outlier status relative to other subjects, how do you suggest we use our study sample to derive these thresholds?
Let us know if you have any additional questions or require us to clarify anything.
Thank you,
David Stephenson
We are currently exploring DTIPrep for QA/QC of our research diffusion data, and had a question about the interpretation of the gradient specific angle and translation values (x/y/z) within the DTIPrep xml QC output.
For our data, we noticed we were getting a number of excludes ('Too many gradient excludes' using the default 20%) where the same comparison in FSL using eddy_quad showed a relatively clean image.
In looking at the xml QC output file using the DTIPrep GUI, we noticed within the Gradient_check FAIL section, the dropdown list of angle/translation xyz would be color coded green and red. I assume that green means that it passed the rotation/translation tolerance in the protocol file, and red means that it was above this tolerance threshold.
However, when we plotted these values within angle/translation metrics (across subjects), we expected that all or most of the gradient FAIL individuals would be on the outlier tails of the distribution, but these plots indicate that, even for those where it indicates the angle/translation was beyond tolerance threshold, that the angle/translation x/y/z values are within the distribution of those individuals who passed all tolerance thresholds and had all global pass flags (i.e. More than #6, Too many bad gradients=FALSE). Plots are attached for our 12ch data gradientwise checks.
We were going to use this information to determine what we could change/relax the gradient rotation/translation tolerances too, but given that there is not a clear relationship between gradient rotation/translation tolerance failure and outlier status relative to other subjects, how do you suggest we use our study sample to derive these thresholds?
Let us know if you have any additional questions or require us to clarify anything.
Thank you,
David Stephenson
Threaded View
| Title | Author | Date |
|---|---|---|
| David Stephenson | Mar 13, 2023 | |
| Martin Styner | Mar 13, 2023 | |
| David Stephenson | Mar 22, 2023 | |