If you visualise the extracted peak orientations using the Fixel Plot tool in mrview, you should find orientations that are consistent with the ODFs.
What’s most likely happening here is the consequence of different conventions for how orientation information is encoded. In MRtrix3, all orientation information is defined with respect to the three spatial axes of the acquisition scanner hardware, referred to as “real space” or “scanner space”. In the FSL software, orientation information is defined with respect to the directions of the image axes; referred to as “image space” or “voxel space” (which can be fractionally different depending on the context, but I think we can skip past that detail here). While this is now reasonably well documented for diffusion gradient directions, the same logic applies to derivative DWI data such as fibre orientations (though not sure about whether the FSL flipping X direction for radiological images also applies to fibre orientations in FSL).
If the image data happen to be perfectly axially aligned, there’s a good chance that negating the value of the x-component will do the trick. If your image data are oblique then the requisite transformation is more complex; I don’t actually think we have anything in MRtrix3 for the conversion, there’s probably at least one person out there that’s written some form of converter.
Thanks for your comphrehensive answer. Yes, it’s right when visualized in mrview. While I’m still confused that the “transform” is identity except for a placement of the origin as you can see with mrinfo. So the orientation represented in both space is expected to be … the same, isn’t is? Or the mrtrix did some extra transform when converting a DWI data to .mif fomat?
Yes, it’s all a bit confusing. The transform relates voxel indices to their location in 3D space, but orientations are stored according to different conventions. In MRtrix, they’re stored relative to the real space coordinate system. In FSL, they’re stored relative to the image axes. So that means components (1,0,0) in MRtrix points along the scanner x-axis, while in FSL it points along whatever direction the image’s x-axis is pointing along. And on top of that, there’s an additional quirk when handling FSL directions (see here for details, it’s the same for bvecs/bvals). There’s no right and wrong here, just different conventions…