Open SyamGadde opened 9 years ago
Thank you for reporting this issue. Do you have any dataset you could share on which we could reproduce the error to try to fix it?
It was surprisingly difficult to fake a dataset that would trigger this issue! I have put some data here:
https://duke.box.com/s/wp4wfjmmdm42gplttyh22gdl6b8f84n2
Which you can run like this:
DTIPrep -c -w noisyfull.nrrd -p noisyfullprotocol.xml
The input has 1 B0, 14 DWI, 1 B0, 14DWI. The result will be a dataset with the first B0 removed, the second B0 retained, but the output gradient directions in the _QCed.nrrd file suggest that the remaining B0 is at the beginning of the data.
This data was fashioned from the data in the last link at:
http://www.cabiatl.com/Resources/Course/tutorial/index.html
I took the first 15 volumes (including initial B0), repeated it, then added noise to a few slices in the first B0.
Thanks for you help!
Thank you for the test data set. I will try to reproduce the error you are mentioning and correct the problem as soon as possible.
Just wanted to mention that another "kludge" for this particular bug is to just turn off the baseline averaging feature entirely. In that case, even if the first B0 is excluded, the gradient directions in the .nrrd file and the output image data still stay in correspondence. (Note though that one consequence of taking this approach is that if you are also using the "eddymotion" step, your reference image for eddy/motion correction will then be whatever the first, non-excluded image happens to be).
That's a nice option to know about. Thanks!
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:
If no volumes were removed, then the resulting dataset would be:
where B0 is the average of B0a and B0b.
However, if the B0a was excluded, then the output image data would look like this:
But the gradient directions in the .nrrd file would be written out as:
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!