Orientations are wrong in mrview with post-mortem data

Hi. I am working with post-mortem dwi data. As we all know, the orientations of the image are unusual in general. In order to identify the regions of interest easier, the orientations are changed into RAS using 3dresample. Although the new dwi image seems to be normal in fslview, this change can not be captured in mrview. Is it related with the ‘Data strides’ in mrview? A further question, should I modify the b-matrix in this case (nifti format) too? If yes, any idea how to make it? Thank you in advance.

Image: “dwi_ras.nii.gz”

Dimensions: 144 x 128 x 192 x 51
Voxel size: 1.10417 x 1 x 1.10417 x 1
Data strides: [ -1 3 -2 4 ]
Format: NIfTI-1.1 (GZip compressed)
Data type: 32 bit float (little endian)
Intensity scaling: offset = 0, multiplier = 1
Transform: 1 -0 0 -71.65
0 1 0 -71.6
-0 0 1 -133.2

Here is the dwi file in fslview:

the same file in mrview:

OK, lots going on here. First, getting the orientation right. You’ll note that the orientations are not correct in fslview either, as the orientation labels demonstrate: you get A & P labels where you’d want S & I, and vice versa. The difference is that fslview shows you the image as stored irrespective of the transformation matrix, and adjusts the orientation labels to match, whereas MRView loads the image in its expected anatomical orientation, taking the transformation matrix in account directly.

If you want the images to display correctly (as in the same way) in both fslview and MRView, then yes, you need to worry about the strides. But first, how do the images display in MRView before you run 3dresample? I’m not familiar with this software, so I’ve no idea how it does its thing. It might resample without modifying the transformation matrix to match, in which case the before and after images will differ in orientation in MRView, or it might alter the transformation matrix according to the resampling it did, in which case it would look no different in MRView (but different in fslview). Also, mrinfo would report a different transformation matrix in the former, and the same matrix in the latter (but with different strides). It’s hard to know without having a look… Also, the name ‘3dresample’ suggests that the data might be interpolated into a different voxel grid, which sounds like a bad idea, it introduces subtle errors in the data for no good reason - ideally all it would do is shuffle the voxel values around without interpolating, and/or modify the transformation matrix. I’ve no idea what it actually does, these are just the issues that I’d be looking into.

If the data look OK in MRView, either before or after some manipulation, then you can always use mrconvert -stride 1:3 in.nii out.nii to ensure the voxel order matches between fslview and MRView (although you may need to use -stride -1,2,3 if there’s a left/right flip).

The issue of what to do with your bvecs on the other hand is potentially trickier, it depends on exactly what was done… If the resampling only modified the transformation matrix, then it would be safe to use the bvecs as-is. But if there has been a reshuffling of the voxels on file (i.e. a manipulation of the actual image axes), then the bvecs will need to be modified accordingly, since they are defined with respect to the image axes. If all that happened was that the x & y axes were swapped (for example), then it’s typically easy to correct. But if there’s been some actual resampling via interpolation, introducing non-trivial rotations in the anatomy relative to the image axes, then it’s a lot harder to figure out. And also a lot harder to provide any guarantees that the correction is 100% accurate: it might look OK in some data sets because the rotation introduced was small, but fail badly in other cases. In those cases, you’d need to verify every step does exactly what you think it should have done…

So as you can see, lots of scope for tripping yourself up in there. In general, I recommend you use the MRtrix commands mrconvert (to manipulate the strides) and/or mrtransform (to actually rotate the images). For the latter, focus on the -linear option, and don’t use the -template option (as this will trigger a resampling of the data, rather than simply modifying the transformation matrix). The advantage of using these tools is that they will take care of the DW information for you if it’s provided. The simplest way to do this is to convert everything to MRtrix3’s own .mif format while you work with them, using mrconvert -fslgrad bvecs bvals in.nii out.mif to import the data initially (at which point the DW scheme information is embedded in the image header), perform whatever manipulations you need, and then export back to NIfTI using mrconvert in.mif out.nii -export_grad_fsl bvecs bvals to get the appropriately modified bvecs/bvals (assuming they were correct to begin with…).

Thanks for your replies, this is all really helpful!

An alternative solution works using several FSL commands.

fslorient -deleteorient imagename ;
fslswapdim imagename a b c imagename ;
fslorient -setqformcode 1 imagename ;

where a b c need to be chosen, usually by trial and error, so that the image after this is in the same orientation (as viewed in FSLView) as the MNI152 images.

More details can be found in fslwiki — (1. The labels in FSLView are wrong or missing and no conversion to NIfTI can fix this). http://fsl.fmrib.ox.ac.uk/fsl/fslwiki/Orientation%20Explained

Glad you got something working, but bear in mind that this almost guarantees that the bvecs/bvals will no longer match with your images. You’d need to figure out how to manipulate the directions back into correspondence with the images.

fslorient -deleteorient imagename ; 
fslswapdim imagename a b c imagename ; 
fslorient -setqformcode 1 imagename ;


mrtransform image_in -identity - | mrconvert - image_out -axes a,b,c

should achieve the same (or similar) effect.

Hello @Meng ,

This is very interesting question in MRtrix3. I see many discussions regarding orientation in MRtrix3 community.

I would like to share my experience with you. Actually, the dcm2nii that convert dicom into nifti will give the correct orientation of bvecs as well. We can also check the axes and axis-labels such as AP or RL or SI using fslhd in order to confirm the phase encoding (PE) direction. Again, PE direction can be found in json file. Again, fslorient and fslreorient2std can be a strong arsenal like you said.

I also analyzed dti data changing polarity and swapping dimensions in every possible ways. Finally, I realized it’s an orientation issue that can be solved easily if we keep a close eye on to the orientation.

For me, MRtrix3 is a best command-line tractography software. Basically, we can know everything what is happening and what we are doing.