This is similar to a similar discussion going in this thread. In your case however, the MRtrix results look correct: the image is displayed in the correct orientation (assuming inferior-superior maps to ventral-rostral, and anterior-posterior to rostral-caudal), and the direction vectors are the right colour for that coordinate system. I assume the nerve bundle you are referring to the large structure (trigeminal nerve?) visible in the top-left panel? If that’s the case, then it should be green: it’s oriented rostral-caudal, and in all packages is displayed as anterior-posterior, which by convention is assigned to green. Displaying it as blue would imply it’s oriented as inferior-superior (ventral-dorsal), which is at odds with what the packages are actually displaying, as well as my (limited) knowledge of rodent anatomy…
However, it could also be argued that in a rodent system, rostral-caudal is generally aligned with the scanner z-axis, in which case it would be displayed in these packages as inferior-superior, and hence that structure would be coloured in blue. I’m not sure what the right answer is here, it depends on the conventions used in the rodent world, and how the scanner sets up the coordinate system (on human systems, the coordinate system is actually set at exam time relative to the anatomy via the DICOM patient-based coordinate system, so doesn’t need to be aligned with the scanner as such).
Note that (for your first FSL screenshot) the image is also interpreted correctly in FSL, in that the orientation labels are as expected and match those with MRView. The directions are not however coloured correctly with respect to the anatomy - they are the ‘right’ colours with respect to your display. In other words, if the top-left panel had been labelled as I-S for the vertical direction (i.e. the NIfTI standard coordinate system in the absence of rotation) instead of A-P, then the cingulum and trigeminal are shown in the expected green colour, rather than blue (which is the right colour for an I-S orientation) - this is confirmed in your second FSL screenshot, where the images are displayed with the expected standard orientation in FSLView (by using the -stride 1,2,3,4 option in mrconvert). I’m not familiar with how FSLView decides how to colour their tracks, but evidently they use the display coordinate system. In MRtrix3, we try to do everything in real/scanner/world coordinates if possible, and that means the images are displayed relative to that coordinate system, and therefore with the expected orientation (i.e. the top-left pane should always show a coronal section, with R-L on the horizontal axis and I-S on the vertical axis), and the colours are always determined in that frame also. This means the display is independent of the details of how the images were stored (i.e. basically what strides were used).
Two more tiny comments:
-
there is a script in the
scripts/folder calledconvert_bruker, which is provided on a best-effort basis to help import Bruker data. It converts to one of the MRtrix3-specific formats (.mih), from which you can convert to NIfTI or whatever you see fit. It should try to also import the directions (bvecs/bvals), and so might help avoid all this hassle. Note however that it is known not to get everything right, particularly for obliquely-acquired data, and sometimes the DW orientations aren’t in the right frame. But it might nonetheless help sort out some of these issues. -
your conversion from NIfTI to NIfTI via the two
mrconvertcalls can be performed in a single step, no need to store to an intermediate.miffile:mrconvert -info -stride 1,2,3,4 -fslgrad ../../../bvecs_xy-z.txt ../../../bvals.txt ../dwi_top.nii.gz -export_grad_fsl exp_bvecs2.txt exp_bvals2.txt dwi_top_fslgradxy-z_s1234_conv.nii.gz