NITRC DWI/DTI Quality Control Tool: DTIPrep Forum: open-discussion

RE: Movement parameters extraction

Martin Styner — Mon, 29 Jan 2024 15:10:18 GMT

The parameters are the ones for an ITK affine transform : https://itk.org/Doxygen/html/classitk_1_1AffineTransform.html
Best
Martin
Originally posted by Daniel Berge:
<blockquote>
Dear DTIPrep developers, 
 Thank you for this extremely useful tool. I would like to extract motion parameters from the Eddy currents and motion artifact detection step. In the QCReport.txt file, there is a list of parameters for every gradient, with 12 parameters for each gradient. I assume they are derived from the affine transformation matrix, but I cannot figure out the correct order of these parameters and which one is which.
I guess that the first, the the 5th and the 9th are the scaling factor (x,y,z) as they are close to one, but I might be wrong. 
Thus, are the others, x,y and z for rotation, translation, and...?
Could you please clarify this simple question?
ie:
<ul>
<li>Parameters: [0.9940250406542067, 0.005037731155539504, -0.0044764617213477525, -0.003336387327671193, 0.9906213568620513, -0.001621771668964308, 0.002073337608179639, 0.0009743273562393963, 0.9919877206204243, -0.1478211258441959, -0.023645834340927947, 0.06009304791091765]</li>
</ul>
 
Thanks in advance
 
Dani Bergé
Hospital del Mar Research Institute
Barcelona, Spain
</blockquote>

RE: Interlace Correlation values not saving in QCReport.txt

Martin Styner — Mon, 29 Jan 2024 15:08:09 GMT

Hi Dani
This is likely a bug (there are some differences between the UI and non-UI run of protocols). An alternative is to capture also the terminal output (e.g. via redirection into a file), as the interlace correlation values should be reported on the terminal output in a non-UI run.
Also, you could consider moving to the new/next-gen version called dmriprep (which is part of dtiplayground): https://github.com/NIRALUser/DTIPlayground
That version stores the correlation values of the interlace check in the computations/checks.yml output (the UI and non-UI runs are identical in dmriprep as the UI calls the non-UI run)
Best
Martin
Originally posted by Daniel Berge:
<blockquote>
Dear DTIPrep developers, 
  I have noticed that, as compared to previous versions, even when specifying Report type "2", the interlace correlation values are not saved in the txt file anymore when I run DTIPrep from my script.
 Surprisingly, if I run exactly the same protocol from de DTIPrep gui, the generated Report file does contain these correlation values.
Any keys about what I might be doing wrong would be much appreciated.
Thanks in advance.
Dani Bergé
Hospital del Mar Research Institute
Barcelona, Spain
</blockquote>

Interlace Correlation values not saving in QCReport.txt

Daniel Berge — Mon, 29 Jan 2024 14:37:55 GMT

Dear DTIPrep developers, 
  I have noticed that, as compared to previous versions, even when specifying Report type "2", the interlace correlation values are not saved in the txt file anymore when I run DTIPrep from my script.
 Surprisingly, if I run exactly the same protocol from de DTIPrep gui, the generated Report file does contain these correlation values.
 
Any keys about what I might be doing wrong would be much appreciated.
 
Thanks in advance.
 
Dani Bergé
Hospital del Mar Research Institute
Barcelona, Spain

Movement parameters extraction

Daniel Berge — Mon, 29 Jan 2024 12:02:30 GMT

Dear DTIPrep developers, 
 Thank you for this extremely useful tool. I would like to extract motion parameters from the Eddy currents and motion artifact detection step. In the QCReport.txt file, there is a list of parameters for every gradient, with 12 parameters for each gradient. I assume they are derived from the affine transformation matrix, but I cannot figure out the correct order of these parameters and which one is which.
I guess that the first, the the 5th and the 9th are the scaling factor (x,y,z) as they are close to one, but I might be wrong. 
Thus, are the others, x,y and z for rotation, translation, and...?
Could you please clarify this simple question?
ie:
<ul>
<li>Parameters: [0.9940250406542067, 0.005037731155539504, -0.0044764617213477525, -0.003336387327671193, 0.9906213568620513, -0.001621771668964308, 0.002073337608179639, 0.0009743273562393963, 0.9919877206204243, -0.1478211258441959, -0.023645834340927947, 0.06009304791091765]</li>
</ul>
 
Thanks in advance
 
Dani Bergé
Hospital del Mar Research Institute
Barcelona, Spain

RE: Missing library when trying to launch DTIPrep 1.2.11 on Ubuntu 22.04

Jon Haitz Legarreta Gorroño — Wed, 28 Jun 2023 14:30:20 GMT

Hi, > https://ubuntuhandbook.org/index.php/2020/07/install-qt4-ubuntu-20-04/ Had tried following the instructions this morning to no avail; have just retried, probably more carefully, and fixed the problem. For the records, after adding the package archive for Ubuntu 22.04, it sufficed to install qt4-default.
Thanks for the support SK.

RE: Missing library when trying to launch DTIPrep 1.2.11 on Ubuntu 22.04

Sang Kyoon Park — Tue, 27 Jun 2023 15:51:12 GMT

The library issue can be resolved by installing the library, pls contact with your system administrator. 
If it's your own machine under your control, that error came from QT XML library. You can try after installing the library, DTIPrep doesn't automatically build or install QT libraries.
You can refer to below site for your reference.
https://ubuntuhandbook.org/index.php/2020/07/install-qt4-ubuntu-20-04/
Thanks
 
SK

Missing library when trying to launch DTIPrep 1.2.11 on Ubuntu 22.04

Jon Haitz Legarreta Gorroño — Mon, 26 Jun 2023 21:55:03 GMT

Hi,
I am trying to use DTIPrep on an Ubuntu 22.04 machine.
I downloaded the <code>DTIPrep-1.2.11.tar.gz</code> file corresponding to the <code>DTIPrep1.2.11_linux64</code> release from:  https://www.nitrc.org/frs/?group_id=283 After decompressing the file to a folder on my choice, when calling the DTIPrep executable in the bin folder, the process exits without launching the software with the following error: <code>$ ./DTIPrep </code><code>./DTIPrep: error while loading shared libraries: libQtXml.so.4: cannot open shared object file: No such file or directory</code>
The library is not found in the <code>lib</code> folder. Am I missing some step? If not, can the library be bundled with the compressed file and the issue be fixed, please? Thanks for your work

RE: Using QC xml interlace and gradient angle/translation values in determining protocol thresholds

David Stephenson — Wed, 22 Mar 2023 19:30:37 GMT

Noted. Thank you Martin.

[i]Originally posted by Martin Styner:[/i][quote][color=#000000]Hi David[/color]

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/latest/DMRIPrep.html , 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

[i]Originally posted by David Stephenson:[/i][quote]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[/quote][/quote]

RE: Using QC xml interlace and gradient angle/translation values in determining protocol thresholds

Martin Styner — Mon, 13 Mar 2023 20:15:28 GMT

[color=#000000]Hi David[/color]

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/latest/DMRIPrep.html , 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

[i]Originally posted by David Stephenson:[/i][quote]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[/quote]

Using QC xml interlace and gradient angle/translation values in determining protocol thresholds

David Stephenson — Mon, 13 Mar 2023 19:53:15 GMT

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