Response text file "shells" doesn't equal an actual used shell


I’ve been using the tournier dwi2response algorithm and had a look into the output response text file. The data I used this on contains 64 images acquired with b=1000 and one b=0 image. What confuses me is, that the response text file says “Shells=999” (instead of 1000) in the first line. Any hint on why that is and if I should be concerned about it would be very much appreciated!


1 Like

Hi Ella,

Upstream of the output of dwi2response, if you look at the raw data that comes from the scanner, it’s quite often for e.g. data acquired at b=1000 to be reported as 985–1015. Indeed b=0 volumes are often reported to be 5, or potentially even 10 or 15. This is because (on some vendors at least) the b-value is computed based on all applied gradients, not just the diffusion sensitisation gradients, and the effects of things like slice selection and readout are small but non-zero.

MRtrix3 has internal logic all over the place to interpret these data correctly, e.g. placing both b=985 and b=1015 into the same “shell”. It also explicitly calculates the mean b-value per shell in the presence of this small variation, and sometimes that’s not precisely equivalent to what you originally requested on the scanner console. But say you had multi-shell data, and requested at the command-line to use only “the b=1000 data”: MRtrix3 would still select this shell, even if the mean b-value is actually closer to 999 than 1000.

See relevant documentation here.

One thing I’ve had to do with some of my own data to deal with other software downstream is to round all shell mean b-values to the nearest 5. I wonder if that would have a deleterious effect on anyone else’s data were MRtrix3 to do the same…


Thank you so much for your detailed explanation and the link!