niraluser / dtiprep Goto Github PK

When doing visual checking and saving VC files, DTIPrep1.2.4 by default writes new files with "VC" in the name. The exception is the QCXML file. That one is overwritten, instead of writing a new file, and it does not appear to retain the original processing information. Please change such that when saving VC files, a new QC XML file is output. Thanks!

since I guess DTIPrep != NeuroLib, I can't simply "apply" Apache 2.0 license to the files from NeuroLib project which carry no statement of the license, thus "all rights are reserved" and nothing is permitted according to those files headers, e.g.

Program:   NeuroLib
Module:    $file: itkDWICropper.h $
Language:  C++
Date:      $Date: 2009-11-26 21:52:35 $
Version:   $Revision: 1.4 $
Author:    Zhexing Liu ([email protected])

Copyright (c) NIRAL, UNC. All rights reserved.
See http://www.niral.unc.edu for details.

This software is distributed WITHOUT ANY WARRANTY; without even
the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.  See the above copyright notices for more information.

BTW link on http://www.med.unc.edu/psych/research/niral/download/download-software for "Non-supported Software: NeuroLib download page" leads to N/A http://www.ia.unc.edu/dev/tutorials/index.php

When one attempts to adjust the contrast in the three right-hand-image panels (axial, sagittal, coronal) in DTIPrep1.2.6 using a mouse, the image instantly turns white. In versions 1.2.2 and and 1.2.4, the image contrast adjusts gradually as you move the mouse.

Hi @styner, we are interested in getting DTIPrep running in Slicer again, perhaps during project week next month. One question before considering further: is there any test-suite/data for DTIPrep? The port to ITKv4 seems to be a substantial amount of work (#4), and it would be difficult to ensure correctness without tests. Thanks.

(closing, resolved by #45)

Gradients are being excluded when running the InterlaceWise check. The user specified thresholds are not exceeded, so it is unclear why they are being excluded. Example QC report attached.
116845_01_79dir_topup_corrected_QCReport.txt

In command line mode, the diffusion check and replace for correct gradient info does not replace the gradient information

We are using v1.2.4 of DTIPrep.

Several of our users like to concatenate multiple DTI runs together. Generally each run consists of a single B0 volume followed by diffusion-weighted volumes, and this works pretty well. I believe DTIPrep averages the B0 volumes together and the averaged volume is placed where the first B0 volume would have been in the original data, and the rest of the B0 images are removed. In most cases, the diffusion directions are output correctly.

This also generally works if any of the B0 volumes are excluded for poor quality. The averaged volume is placed where the first non-excluded B0 would have been.

However, we've noticed that if it excludes the first B0 volume, the averaged B0 goes where the second B0 would have been (as expected above), BUT the gradient directions are written out with the B0 direction always associated with the first volume.

To illustrate, if our dataset was:

B0a   D0a D1a D2a D3a D4a D5a   B0b   D0b D1b D2b D3b D4b D5b

If no volumes were removed, then the resulting dataset would be:

B0   D0a D1a D2a D3a D4a D5a    D0b D1b D2b D3b D4b D5b

where B0 is the average of B0a and B0b.

However, if the B0a was excluded, then the output image data would look like this:

D0a D1a D2a D3a D4a D5a   B0b    D0b D1b D2b D3b D4b D5b

But the gradient directions in the .nrrd file would be written out as:

B0b   D0a D1a D2a D3a D4a D5a    D0b D1b D2b D3b D4b D5b

Note that in this case there is only one B0 left so no averaging is done, but I suspect the same thing would happen if there were more than 2 concatenated runs.

One kludge, for subjects where this happens, is to have our users reverse the order of concatenation. This is not an automated workaround, but gets some more data through the gauntlet.

I looked at the source a while back (ca. v1.1.6) but was unable to pinpoint the place where the error was occuring. If anyone has an idea how to fix this, or can point me in the right direction, our users would be very appreciative. Thank you!

Hi,
If you turn on the QuadFit feature of SliceChecker (which to accomplish currently requires setting SliceChecker->SetQuadFit(1) in IntensityMotionCheck.cxx and then re-compiling), the values computed for 'normalizedMetric' are completely wrong. They are intended to be the residuals after fitting the original SliceCheck correlations to a quadratic according to the b-value, but they are far from that.

I tracked the problem down to this bit of code in itkDWIQCSliceChecker.hxx:

  vnl_matrix_fixed<double, 3, 1> coefficients;
  coefficients = vnl_matrix_inverse<double>(bMatrix.transpose() * bMatrix);
  coefficients = coefficients * bMatrix.transpose() * correlationVector;

Note that the variable 'coefficients' is typed to a 3x1 matrix, but then used in an intermediate step to (temporarily) store the output of an inv(X' * X) operation. However, inv(X' * X) is a 3x3 matrix, and the result of the type mismatch is that the full set of 3x3 values is not stored properly. The end result is that the final values for 'coefficients' are wrong, and thus the 'normalizedMetric' values end up being wrong as well.

The fix I implemented was to just create an explicit XtXinv variable, typed to a 3x3 matrix, to store the output of the inv(X' * X) operation:

  vnl_matrix_fixed<double, 3, 1> coefficients;
  vnl_matrix_fixed<double, 3, 3> XtXinv; 
  XtXinv = vnl_matrix_inverse<double>(bMatrix.transpose() * bMatrix);
  coefficients = XtXinv * bMatrix.transpose() * correlationVector;

cheers,
-Mike Harms

Some nice & clean DWIs are excluded in slice wise check as there is no minimal correction threshold setting. We need to add that slices with a minimal threshold, e.g. 0.9 or 0.85 should not be excluded, this is especially necessary for high b-valued data.

I cloned the latest version of DTIPrep (975ed3d) and built it on a Mac OS X 10.10.4 using default cmake parameters except that I turned off USE_DTIProcess.
The build was successful, and DTIPrep binary was generated in:
bin/DTIPrep.app/Contents/MacOS/DTIPrep

While all other binaries were generated in the "bin/" directory.
Why is DTIPrep binary generated in a .app directory rather than the bin directory?

Also, when I run the DTIPrep on a test dataset, I get following error:

"
dyld: Library not loaded: libtiff.5.dylib
Referenced from: /scratch/DTIPrep/release-20160523/bin/DTIPrep.app/Contents/MacOS/DTIPrep
Reason: image not found
Trace/BPT trap: 5
"

Does anyone have an idea how to fix this issue?

Thank you,
Ali

The result xml simply lists all detected baselines as included into the averaging, even if they actually were rejected and then excluded from averaging. These are relatively easy to spot in that they have xml entries that look like below, i.e. -1 or 0 for entries in steps that happened afterwards, such as the motion correction, such as Translation is all 0 or InterlaceAngleX is -1 if it was rejected in SliceWiseCheck

    <entry parameter="gradient_0047">
        <processing>BASELINE_AVERAGED</processing>
        <entry parameter="OriginalDir">
            <value>0.000000 0.000000 0.000000</value>
        </entry>
        <entry parameter="ReplacedDir">
            <value>0.000000 0.000000 0.000000</value>
        </entry>
        <entry parameter="CorrectedDir">
            <value>0.000000 0.000000 0.000000</value>
        </entry>
        <entry parameter="Translation">
            <value>0.00000000 0.00000000 0.00000000</value>
        </entry>
        <entry parameter="TranslationNorm">
            <value>0.00000000</value>
        </entry>
        <entry parameter="Angle">
            <value>0.00000000</value>
        </entry>
        <entry parameter="SliceWiseCheck">
            <processing>INCLUDE</processing>
        </entry>
        <entry parameter="InterlaceWiseCheck">
            <processing>INCLUDE</processing>
            <entry parameter="InterlaceAngleX">
                <green>-1</green>
            </entry>
            <entry parameter="InterlaceAngleY">
                <green>-1</green>
            </entry>
            <entry parameter="InterlaceAngleZ">
                <green>-1</green>
            </entry>
            <entry parameter="InterlaceTranslationX">
                <green>-1</green>
            </entry>
            <entry parameter="InterlaceTranslationY">
                <green>3.07091e-316</green>
            </entry>
            <entry parameter="InterlaceTranslationZ">
                <green>-1</green>
            </entry>
            <entry parameter="InterlaceMetric(MI)">
                <value>-1</value>
            </entry>
            <entry parameter="InterlaceCorrelation">
                <red>-1</red>
            </entry>
        </entry>
        <entry parameter="GradientWiseCheck">
            <processing>INCLUDE</processing>
            <entry parameter="GradientAngleX">
                <green>-1</green>
            </entry>
            <entry parameter="GradientAngleY">
                <green>-1</green>
            </entry>
            <entry parameter="GradientAngleZ">
                <green>-1</green>
            </entry>
            <entry parameter="GradientTranslationX">
                <green>-1</green>
            </entry>
            <entry parameter="GradientTranslationY">
                <green>-1</green>
            </entry>
            <entry parameter="GradientTranslationZ">
                <green>-1</green>
            </entry>
            <entry parameter="GradientMetric(MI)">
                <value>-1</value>
            </entry>
        </entry>
        <entry parameter="QC_Index">
            <value>-1</value>
        </entry>
        <entry parameter="Visual Check">
            <entry parameter="VC_Status_0047">
                <value>NoChange</value>
            </entry>
        </entry>
    </entry>

Issue with writing intermediate file after baseline averaging:

Saving output of baseline average: ... itk::ERROR: ImageFileWriter(0x7f70c80096e0): No filename was specified

in XML:

Try.nrrd

When building DTIPrep as an extension:

file failed to open for reading (No such file or directory): /.../DTIPrep-build/DTIPrepTools-build/DTIPrepTools-build/package_target_output.txt

The entropy/direction checking writes a tensor image (tensor.nrrd) temporarily for the computation of the primary direction distribution. This is written in the current working directory, wherever DTIprep is started. This necessitates write permission for that directory. This is improper processing and should easily be replaced by writing that image into the DTIPrep output folder instead.

The current automatic brain masking is too inclusive for the purpose of entropy computation. Enable a new method that computes a restricted brain mask only comprising WM and GM excluding CSF for the purpose of entropy computation:
1- Compute IDWI as with FSL Bet on IDWI
2 - ImageMath -otsu
3 - ImageMath -conComp 1

This mask should be used ONLY for entropy computation.

Slicer is going to stop support for ITKv3 compatibility; therefore, changes suggested in this issue are needed for future compatibility.

I already started a patch to address this issue:
aghayoor@cde440f

However, DTIPrep still needs to go under a drastic refactoring in its registration framework. Here are some suggestions to start these changes:

1. "MultiResolutionMultiImageRegistrationMethod" class is not needed anymore, since "itkImageRegistrationMethodv4" provides multi-resolution and multi-metric/image registration capabilities.

2. "GradientDescentLineSearchOptimizer" class can be removed, since ITKv4 registration framework has the same optimizer: "itkGradientDescentLineSearchOptimizerv4".

3. "MultiImageMetric" class can be removed from the src directory, and the ITK class (itkObjectToObjectMultiMetricv4) can be used as the base class for multi-metric registration process.

4. The "UnivariateEntropyMultiImageMetric" and "VarianceMultiImageMetric" classes should be modified to be compatible with the new multi-metric base class.

5. "MultiImageRegistrationFilter" should be re-written in a way to run ITKv4 registration. Begin with:
   MultiResolutionMultiImageRegistrationMethod.h --> itkImageRegistrationMethodv4.h
   GradientDescentLineSearchOptimizer.h --> itkGradientDescentLineSearchOptimizerv4.h
   itkBSplineDeformableTransform.h --> itkBSplineTransform.h
   itkBSplineDeformableTransformInitializer.h --> itkBSplineTransformInitializer.h
   ...

6. Other registration classes in the src directory (like IntraGradientRigidRegistration, RigidRegistration and itkVectorImageRegisterAffineFilter) are also needed to be changed to use "itkImageRegistrationMethodv4" for their registration process.

Often baselines have b-values in the range of 1-5, those are currently not detected as baselines and are thus not used in the baseline averaging resulting in sub-par motion correction results. There should be a tolerance parameter that should be adjustable in the protocol

Hi,
Can you add the command line mode for creating protocol and setting options of protocol (e.g. turn off eddy correction) in future? It would be helpful to implement DTIPrep into some pipeline and customize the function of DTIPrep.

Thanks!
-Jian

We have been using v1.1.6 of DTIPrep with no problems. We wanted to try v1.2.4 to see if some outstanding issues had been addressed. Unfortunately it seems we can't run the newer version without X, even if we are using a protocol file and don't need the GUI. We are running this under SGE so jobs are submitted to a cluster and X is not available to us. Any ideas?

I converted DICOMs to a .nrrd file, and found that the data type was "short". After running DTIPrep, the resulting .nrrd file has data type "unsigned_short". This prevents Slicer (4.8.1) from being able to convert from Nrrd to FSL format. Is there any way to specify the output data type during a call to DTIPrep from the command line, or convert the data type of a .nrrd file?

There is an inconsistency when writing the report.

Some variables in the qcResult structure are set using a map to retrieve the index of the gradient.

As shown in:

The map: t_Original_ForcedConformance_Mapping[index].index_original[0]
Is used to set the values in the QCResult structure as shown in:
https://github.com/NIRALUser/DTIPrep/blob/master/src/IntensityMotionCheckPanel.cxx#L664

However, when writing the report. This structure is not used to retrieve the same variables:
As shown in:
https://github.com/NIRALUser/DTIPrep/blob/master/src/IntensityMotionCheckPanel.cxx#L4034

This could be a generalized error when writing the QCReports.

Could you associate the 3d-slicer-extension GitHub topic so that it is listed here: https://github.com/topics/3d-slicer-extension

To learn more about topic, read https://help.github.com/en/articles/about-topics

in src/itkDWIBaselineAverager.hxx

" << std::setw(9) << std::setiosflags(std::ios::fixed) << std::setprecision(17) << std::setiosflags( std::ios::right | std::ios::scientific )"

setw and setprecision should be aligned, particularly if one chooses a fixed notation (setw should be larger than setprecision). And if one choses a fixed notation, then one should not use scientific. So this is clearly not good programming on our end.

The best seems to replace this with a fixed notation at the higher precision (probably too high with 17), i.e.
" << std::setw(19) << std::setiosflags(std::ios::fixed) << std::setprecision(17) << std::setiosflags( std::ios::right)"

When checking the report of DTIPrep, there was a warning: "Image_information_checkingImage_origin_check FAILED", but the quality checking for the images is OK:

PASS: Gradient direction #is not less than 6!
PASS: Left Baseline images and the left b-value are ok!
PASS: Bad gradient directions #passed in the tolerance!

The protocol was created using the default option of DTIPrep from subject A, and then used for subject A's quality check （the same images for protocol).

Hi,
This isn't an "issue" per se. I thought it would potentially be very useful if the QCReport output included the z-scores that are calculated internally as part of SliceChecker and InterlaceChecker for deciding if a frame should be excluded. That way, one can quickly see how close a given frame was to exclusion, and more readily calibrate an appropriate set of thresholds to use for a given set of data.

So, I've implemented the changes necessary in the SliceChecker and InterlaceChecker code to store those z-scores while they are computed, and then later output them into the QCReport.

I'm not familiar with how to formally use GitHub for this sort of thing, so I haven't forked the code and created a pull request. But I'm mentioning this because if a DTIPrep developer is interested in incorporating these features, I'm more than happy to share the code.

cheers,
-Mike H.

While looking into addressing the following warning:

tmp/DTIPrep/src/IntensityMotionCheckPanel.cxx: In member function ‘void IntensityMotionCheckPanel::ResultUpdate()’:
/tmp/DTIPrep/src/IntensityMotionCheckPanel.cxx:3978:33: warning: suggest parentheses around operand of ‘!’ or change ‘&’ to ‘&&’ or ‘!’ to ‘~’ [-Wparentheses]
   if( ( ( (!qcResult.Get_result()  & InterlaceWiseCheckBit) == InterlaceWiseCheckBit ) ||
                                 ^

associated with this code:

I suspect something is wrong.

Indeed, based on the operator precedence [1], adding parenthesis around !qcResult.Get_result() is the right thing to do to address the warning, that said the check should be reviewed since the value returned by Get_result() always evaluates to 1 or 0.

[1] http://en.cppreference.com/w/c/language/operator_precedence

Looking at this test in an other part of the code hints on what should be the correct implementation:

Hello,
I am trying to use DTIprep for QA of our diffusion data. However, regardless of way I lounch it, the log allways ends with something like:

FAILED execution of ./DTIPrep in /opt/Francois/temp/LabTools/NAMICExternalProjects-build/DTIPrep/src/main.cxx at 1473 with code 1

FAILED execution of ./DTIPrep in /opt/Francois/temp/LabTools/NAMICExternalProjects-build/DTIPrep/src/main.cxx at 1473 with code 522

Is there any way to troubleshoot it more ? Honestly, the numeric codes thrown by

std::cout << "FAILED execution of " << argv[0] << " in " << FILE << " at " << LINE << " with code " << static_cast(result) << std::endl;

is not really helpfull to me :-(
Can it be fixed or is there any list of the codes ?

Thanks
George

On rare occasions (e.g., 4 out of 453 sessions), the DWICount and BaselineCount values in InterlaceChecker are non-sensible, as if they haven't been initialized properly.
e.g.,
DWICount: -1300997086; BaselineCount: 1300997134

FWIW, in all 4 instances, the DWICount was a large negative value, and the BaselineCount was a large positive value. Interestingly, the sum of the two nonetheless accurately reflects the total number of frames remaining after the slicewise check stage.

Also, I don't know if this is somewhat related, but in 3 of 453 sessions which "failed" at the gradient checking stage due to "Too many bad gradient directions found", I get non-sensible values such as the following in the terminal output (or equivalent, the output of the --resultsNotesFile argument):
GradientTotal#/LeftGradientTotal#: 52/1911268545
Baseline#/LeftBaseline#: 2/1904214016
Gradient#/LeftGradient#: 50/7054529
GradientDir#/LeftGradientDir#: 25/-1024065536