Hi @brc0520,
Thanks for all the work you’ve put into your reports on the issue – I wish all our requests for support were that detailed!
I’ve been following your posts, but haven’t responded yet as I don’t think I have anything particularly helpful to say at this point. It feels like a scanner software issue (it wouldn’t be the first time…), but your latest post seems to suggest otherwise.
To recap:
-
Philips should and has historically always stored their DW directions in the DICOM output with respect to the DICOM patient-centered coordinate system, regardless of how they may have been originally specified (itself quite a mess: MPS normally, unless Overplus was used, in which case it was scanner XYZ).
-
bvecs/bvals are stored with respect to the image axes (with a potential x-axis flip if the image axes form a left-handed coordinate system – caught us out a while back)
-
MRtrix internally stores and handles the DW directions with respect to the NIfTI frame (which will normally coincide with the DICOM patient-centered coordinate system, with the y & z axes reversed).
If you introduce different image angulations, then the DW directions in the DICOM (and internally within MRtrix) will change if they had originally been specified with respect to image MPS, but not if they had originally been specified with respect to scanner XYZ. Conversely, the bvecs will not be affected in the former case, but will change in the latter case.
If everything remains consistent, there should be no problem, and the orientations should be correct with respect to the anatomy – as long as there is no mixing between the different conventions. Issues can and most likely will be introduced by e.g. producing tensor eigenvectors in FSL and expecting them to display correctly in MRtrix (different convention on that front too!).
If you find that running a direct DICOM → tensor → eigenvector pipeline all within MRtrix produces inconsistent results, then we’ll need to investigate whether that’s due to a bug in our DICOM handling or in the latest version of the Philips software… Try a command such as this one to do this:
dwi2tensor DICOM/ - | tensor2metric - -vec - | mrview DICOM/ -fixel.load -
If that still shows inconsistencies, then I’ll probably need to take a closer look at the data… 