Rotation of b vecs values



I have a problem with a probable rotation of the bvec of a diffusion image.

The tractography of the spine shows transversal fibers instead of vertical fibers.

Here is the anonymized DICOM, and the bval and bvec list.

Would you have an idea/a tool to be sure of the abnormal rotation, of the angle (only90° or not?) and how to put it right?

Thank you very much!

0 0 -1 -0.848999994794926 0.108000005569824 -0.884000003401043 0.00299999274444239 0.867999997653773 -0.798999996352505 0.162000009729939 -0.866000001271694 0.211999990772823 -0.0680000087934205 -0.550000005362803 0.434999995839884 0.599000007689314 0.525000000295743 0.599999993217631 -0.653000000591486 -0.207000000749215 0.412999993109192 0.436000008103354 -0.461999991384025 0.50300000481075 -0.82400000522479 -0.296999996559525 0.040000003134874

-0 -0 -9.85809433737272e-09 0.527999991630478 0.565000001064674 -0.345000008714555 -0.735999999970426 -0.237999991443174 0.369999992123383 0.987000001597011 -0.12900000853711 -0.935999997910084 -0.89200000067035 -0.544000005421952 -0.421999995711729 0.780000005904999 0.0300000051754994 -0.687999994085143 -0.0600000064373357 -0.0760000020406257 -0.698999995928607 0.822000004298129 0.87399999544556 0.488000004958621 -0.53000000812307 0.348999997072146 0.318000000394324

0 0 -3.03576608295941e-18 8.32667268468867e-17 -0.818 0.315 -0.677 -0.436 -0.475 1.38777878078145e-16 -0.483 -0.281 0.446 0.634 -0.795 -0.182 0.851 -0.409 0.755 0.975 0.584 0.366 -0.148 0.713 -0.202 -0.889 0.947

0 0 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600

Here is the link to DICOM anonymised images:

Thanks a lot!!!


I’ve had a look at your data, but I’m not sure what I’m looking at – I’m not used to looking at spine images. It certainly looks like there’s a consistent AP orientation where I’m guessing the spine should be. These are GE data, which need to be handled differently because the bvec coefficients are (typically) stored relative to the image frame rather than the scanner coordinate system – MRtrix3 detects this and applies the appropriate transformation (which it does for your data). If I disable this reorientation, the region that was oriented AP is now oriented LR – which I’m guessing is still not right… So there’s nothing in our code that I can think of that could explain this (assuming this was a bug in our handling).

As to how to fix this: this isn’t as trivial as it might sound. you can probably switch the rows of the bvec file around until you get sensible directions, but you may also need to invert the coefficients of one of the rows too. Once you suspect the directions are wrong, you have to allow for the potential that they might be wrong in multiple ways. Unfortunately, it’ll probably be difficult to visualise from the data what combination of transformations is appropriate (certainly for me, I don’t spine anatomy well enough). On top of that, the images are acquired in an oblique orientation, so the bvecs are specified in a different frame from the scanner coordinate system – it’s not clear whether the right thing to do is swap/invert axes in a scanner coordinate system, or in the image coordinate system. If they were aligned, you wouldn’t need to worry about this… But my intuition, given that these were acquired on a GE, is that you can swap/invert in the image frame, i.e. you should be able swap lines in the bvecs file, and potentially invert the values on one of the rows if required. But that’s based on nothing more than a hunch…

Ideally, the best thing to do is to try to fix this at source. Can I ask whether these data were acquired using a product sequence, as provided by the manufacturer?


While correcting the issue at the source definitely needs to be pursued, I would suggest trying the dwigradcheck script. You will likely need to provide it with a mask of the spine, as without this the script will execute dwi2mask, and that in my experience tends to fail on spine data. But that will provide suggestions of what it thinks the gradient table issue may be, and what it deems to be the “optimal” correction can be obtained using the -export_grad_fsl or -export_grad_mrtrix options.