NIRALUser / DTIProcessToolkit

DTIProcess is a DTI processing and analysis toolkit developed in UNC and University of Utah
http://www.nitrc.org/projects/dtiprocess
Apache License 2.0
7 stars 8 forks source link

dtiestim produces bad DTI results #32

Closed hjmjohnson closed 7 years ago

hjmjohnson commented 7 years ago

@juanprietob @fbudin69500 @styner,

There appears to be bug in the dtiestim program. I am consistently getting bad results for all uses of dtiestim.

The following picture shows that tensors are only estimated in places of CSF, and that white matter completely excluded and set to zero. It seems to be some type of thresholding bug.

image

When comparing dtiestim to Slicers built in tools, or FSL's dti analysis tools, dtiestim always gives bad results. See the attached script for the command line options.

SlicerDWIProcessing.sh.zip

fbudin69500 commented 7 years ago

@hjmjohnson I do not work on these tools anymore now that I work at Kitware, but have you tried to change the value of the threshold (threshold/baselineThreshold) which by default uses an Otsu filter to detect what to threshold. Maybe if you set it to 0?

styner commented 7 years ago

Francois is correct. That has been the default behavior of dtiestim since the start, but I am thinking we probably need to change that (though I don't like changing API's but rather want to be backwards compatible). In all my scripts a call to dtiestim with -t 0 is the norm. It is important to note that dtiestim will even apply and Otsu based threshold when a brain mask is specified and it basically does two masking operations, one based on the specified mask and another based on the otsu thresholding.

hjmjohnson commented 7 years ago

@styner @fbudin69500 Thank you for the quick response. I feel silly now. I missed that option in dtiestim.

Hans

juanprietob commented 7 years ago

Should this issue be closed, or change the default settings?

hjmjohnson commented 7 years ago

@juanprietob @styner

Just my 2-cents. I'd like to see it changed, I prefer outright failure to possible incorrect results. The danger that I ran into was that on my test data sets for developing the processing, the use of "-t 0" did not seem to be necessary, and reasonable results were obtained. Most of the 1000's of scans actually seemed to be relatively unaffected.

At a minimum, if the -t flag is NOT used, and an explicit mask is used, a HUGE warning message should be printed to the screen describing what the behavior is.

I think that a more complete solution would be add the following

--threshold (-t) Defaults to (-999999, to indicate that the value was not provided) --useOtsuComputedMask (defaults to off) --inputMask (defaults to "")

If inputMask == "" && threshold == -9999999, then useOtsuComputedMask = ON do not use thresholding from command line do not use mask provided on command line else use user supplied settings

This should keep the behavior for any scripts that explicitly use the -t flag.

styner commented 7 years ago

We’ll work on it for the next version. We anyway need to add/debug several things in the next month. Martin

hjmjohnson commented 7 years ago

Thank you. I always appreciate your willingness to make these tools better.

Hans