OK @Marco_Aiello pretty sure I’ve found the problem. I was able to reproduce the error at my end when running with the -rpe_all option and an input image with -1,-2,+3,+4 strides. The change implemented here fixes the fundamental cause of the error (it also shows just how easy it is to bugger these things up…), and will be available to you as soon as the automated tests are completed and I hit the merge button. But please still investigate your images thoroughly to make sure that the fibre orientations are as expected.
I always recommend to minimize the amount of conversion between formats. So for instance: If your processing is predominantly using MRtrix, use the .mif format and keep the gradient scheme in the image header; if FSL is required for a particular task, convert to NIfTI and bvecs/bvals only at that point, and then convert back to .mif with embedded gradient table once this is completed. Having an image history that contains images in both formats, and keeping track of which gradient files apply to which images, can cause manual errors just like the one present in the script.
Thanks for re-escalating, and for your patience in us isolating the source of the problem.
If all x-, y- and z-components of the gradient vectors have opposite signs, there should indeed not be any problem. If you compute either tensors or FODs from DWIdata.mif, does it look like those all correspond nicely to the anatomy? If yes, you should be good. If not, we’ve got an issue to look into.
Can I just check what your reference is for the ‘real’ vectors? In DICOM, they’re stored relative to the DICOM patient-centered coordinate system, which has the x & y axes flipped relative to the NIfTI/MRtrix convention. So the ‘reference’ here (DICOM) won’t match with the vectors produced by MRtrix3, whether inverted or not. If you’re comparing against some other conversion software, then bear in mind that some packages may decide to invert the x & y components (as MRtrix3 does), or invert the z component. Either way, the results should be correct for a diffusion analysis. Which one is more correct is a matter of opinion - personally I’m pretty sure the MRtrix3 approach is correct, since it applies the same transformations to other vectors when reading DICOM, such as the positions of the image sizes and the orientation of their axes, where getting the direction right does make a difference - but that’s just my 2 cents…
Actually, was just loitering around near the relevant code: If the diffusion gradients are defined with respect to scanner space, then yes, axes 0 and 1 are inverted; but if the DW_scheme_wrt_image field is set, then it’s axis 2 that gets flipped (in addition to the rotation). This might be what’s causing the inversion relative to the ‘real’ gradient vectors.
So that should only happen for GE gradient vectors, when stored using their proprietary tags. Given that @phmag’s data is from a Philips scanner, I don’t see this being the problem.
But I do admit that I’m not sure what the right answer should be in the GE case - but I also don’t think it matters a great deal, modern GE scanners should output data using the newer DICOM standard tags for this (namely Diffusion b-value & Diffusion Gradient Orientation).
As before, the question here is what do you consider to be the ‘real’ vectors? Those obtained via some other conversion software? Those you provided to the scanner? From my point of view, the DICOM standard is the only thing we can rely on. Their conventions are well documented, and MRtrix3 interprets the directions according to that convention…
Apologies for late reply. I’ve been doing some emailing to a few Philips people to see if I could get the right answer before I responded. It turns out that the input vectors will be in LPH coords however the ones used by the scanner, and ultimately encoded into the DICOM file are switched (rotated and flipped) into MPS coords.
“Diffusion directions in the “read from file” aka your user defined direction mode are defined in LPH coordinates.
When the FOV is angulated, the directions in MPS coordinates differ from the ones in LPH coordinates.”
As you say, it isn’t a problem but I do wonder how many people know this. Thanks for your help and input with this.
Good to hear. It’s actually slightly more complicated than that. On Phillips, the directions you provide would be the correct ones if converted from DICOM to bvecs/bvals format (since in that convention they’re relative to the image axes), but not in the raw DICOM or MRtrix (since the coordinate system used is the scanner’s). However, if you use the overplus option, these directions must by necessity be provided relative to the scanner coordinate system, to ensure that the gradients can genuinely be run at max amplitude along two axes simultaneously. So that would introduce another source of difference for angulated slices. Regardless, though, these directions are stored into the DICOM files using the same standard, so the safe thing to do (and our recommendation) is always to convert from DICOM directly, preferably using MRtrix3 since this is the only code we can vouch for.
There was a similar discussion on our GitHub repo a while back. In this post you’ll notice that I’d said I might write a wiki about this. Ahem, no need to reiterate that here then…
