NIRALUser / DTIPrep

DTIPrep performs a "Study-specific Protocol" based automatic pipeline for DWI/DTI quality control and preparation
http://www.nitrc.org/projects/dtiprep
Apache License 2.0
19 stars 11 forks source link

Incorrect gradient directions when B0 is not the first volume #9

Open SyamGadde opened 9 years ago

SyamGadde commented 9 years ago

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!

fbudin69500 commented 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?

SyamGadde commented 9 years ago

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!

fbudin69500 commented 9 years ago

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.

mharms commented 8 years ago

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).

SyamGadde commented 8 years ago

That's a nice option to know about. Thanks!