Closed hjmjohnson closed 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?
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.
@styner @fbudin69500 Thank you for the quick response. I feel silly now. I missed that option in dtiestim.
Hans
Should this issue be closed, or change the default settings?
@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.
We’ll work on it for the next version. We anyway need to add/debug several things in the next month. Martin
Thank you. I always appreciate your willingness to make these tools better.
Hans
@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.
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