# Modification of orientation with mrresize **URL:** \ **Category:** Uncategorized\ **Created:** [June 6, 2016, 11:48am UTC](https://community.mrtrix.org/t/modification-of-orientation-with-mrresize/279 "2016-06-06T11:48:57Z")\ **Posts on this page:** 14\ **Page:** 1
**Author:** ![mblesac](https://community.mrtrix.org/user_avatar/community.mrtrix.org/mblesac/32/2210_2.png) [@mblesac](https://community.mrtrix.org/u/mblesac)\ **Post date:** [June 6, 2016, 11:48am UTC](https://community.mrtrix.org/t/modification-of-orientation-with-mrresize/279/1 "2016-06-06T11:48:58Z")
Dear all, When I use some of the commands (like mrresize or 5tt2gmwmi) the orientation of my images changes, it’s not a big deal, I can easily solve it, but I was wondering if there is a command to avoid this and what’s the reason for this. Maybe all the operations are performed in the MNI space? Best regards, Manuel ---
**Author:** ![Dave](https://community.mrtrix.org/user_avatar/community.mrtrix.org/dave/32/7_2.png) [@Dave](https://community.mrtrix.org/u/Dave)\ **Post date:** [June 6, 2016, 1:43pm UTC](https://community.mrtrix.org/t/modification-of-orientation-with-mrresize/279/2 "2016-06-06T13:43:02Z")
Hi Manuel, What do you mean by orientation of your images changes? Do you mean the transform in the image header is modified? If so, then this is expected behaviour. `mrresize` should modify the image grid, but ensure the image itself remains in the same location in scanner space. This means that the 3 values in the right column of the transform that designate the position of the 0,0,0 voxel centre (with respect to the scanner space origin) are modified. A different voxel size means it’s centre must be in a different (slightly shifted) scanner position, given the FOV must remain the same (or close as possible if defining the new grid with `-vox`). Let me know if this does not make sense, or if you are talking about something different. Happy to clarify with a diagram if needed. Also, this has nothing to do with MNI space. Cheers, Dave ---
**Author:** ![mblesac](https://community.mrtrix.org/user_avatar/community.mrtrix.org/mblesac/32/2210_2.png) [@mblesac](https://community.mrtrix.org/u/mblesac)\ **Post date:** [June 6, 2016, 2:20pm UTC](https://community.mrtrix.org/t/modification-of-orientation-with-mrresize/279/3 "2016-06-06T14:20:32Z")
Hi David, I understand what you mean, but my problem is different (I think). I’m using the following command: mrresize -voxel 1 -interp sinc subject.nii.gz subject\_RES.nii.gz My images are going from 2x2x2 to 1x1x1, everything works fine, but I open the image with ITK-Snap and I found that the orientation of the original (RAI code) is RPI, and the resampled one is LPS. As I said is not a big deal, but I was curious to know the reason or if there was a flag in the command to solve this. Regards, Manuel ---
**Author:** ![jdtournier](https://community.mrtrix.org/user_avatar/community.mrtrix.org/jdtournier/32/2594_2.png) [@jdtournier](https://community.mrtrix.org/u/jdtournier)\ **Post date:** [June 6, 2016, 9:40pm UTC](https://community.mrtrix.org/t/modification-of-orientation-with-mrresize/279/4 "2016-06-06T21:40:43Z")
@mblesac: can you provide the output of `mrinfo` for both input and output? I’m just a bit confused about how RPI / LPS maps onto our strides. Does RPI refer to the location of the corner voxel, or to the direction of the axes…? Otherwise, I can’t see anything in there that would modify the strides or the transform (i.e. anything that might affect what you call the orientation). If you post the above information, it might help to narrow down what’s going on. ---
**Author:** ![mblesac](https://community.mrtrix.org/user_avatar/community.mrtrix.org/mblesac/32/2210_2.png) [@mblesac](https://community.mrtrix.org/u/mblesac)\ **Post date:** [June 7, 2016, 10:04am UTC](https://community.mrtrix.org/t/modification-of-orientation-with-mrresize/279/5 "2016-06-07T10:04:57Z")
Hi Donald, I think is the direction of the axes, here is the mrinfo output of the raw data: * * * Image: “7004\_diff.nii.gz” * * * Dimensions: 128 x 128 x 50 x 75 Voxel size: 2 x 2 x 2 x 7.3 Data strides: [-1 2 3 4] Format: NIfTI-1.1 (GZip compressed) Data type: signed 16 bit integer (little endian) Intensity scaling: offset = 0, multiplier = 1 Transform: 1 0 0 -118.1 -0 1 0 -152.5 -0 0 1 -71.93 comments: TractoR NIfTI writer v2.4.0 and after mrresize: * * * Image: “7004\_diffRES.nii.gz” * * * Dimensions: 256 x 256 x 100 x 75 Voxel size: 1 x 1 x 1 x 7.3 Data strides: [-1 2 3 4] Format: NIfTI-1.1 (GZip compressed) Data type: 32 bit float (little endian) Intensity scaling: offset = 0, multiplier = 1 Transform: 1 0 0 -118.6 -0 1 0 -153 -0 0 1 -72.43 comments: TractoR NIfTI writ mrtrix\_version: 0.3.13-768-g3898921e From my point of view, booth of them look fine, but when I open it with another viewing, the orientation of the axis is different. Regards, Manuel ---
**Author:** ![jdtournier](https://community.mrtrix.org/user_avatar/community.mrtrix.org/jdtournier/32/2594_2.png) [@jdtournier](https://community.mrtrix.org/u/jdtournier)\ **Post date:** [June 7, 2016, 3:32pm UTC](https://community.mrtrix.org/t/modification-of-orientation-with-mrresize/279/6 "2016-06-07T15:32:28Z")
So this looks entirely self-consistent to me… Maybe you can try running `mrinfo` with the `-norealign` option to see _exactly_ what the transfom information was in the NIfTI header (MRtrix3 does otherwise massage this information somewhat before using it to make everything consistent with anatomical axes). But given what you’ve shown, I don’t see that this will make any difference - I expect the outputs to match with each other (although they’ll probably be different from what you show here). However, there’s a bunch of [unused fields in the NIfTI header](http://nifti.nimh.nih.gov/nifti-1/documentation/nifti1fields/nifti1fields_pages/UNUSED.html) that may be set and/or interpreted by whatever other software package you’re using. MRtrix3 does [set a couple of these fields](https://github.com/MRtrix3/mrtrix3/blob/master/lib/file/nifti1_utils.cpp#L359-L360), which may explain the differences. The reason these fields are set is mostly historical - that’s what they seemed to be set to in all the Analyse data that I’d come across so far (and also what SPM set these values to at the time, probably around 2005…), so it seemed sensible to make sure they remained as-is. But technically, they _shouldn’t_ be interpreted by a NIfTI-1 compliant viewer: the standard quite explicitly specifies them as _unused_ - while MRtrix3 does fill some of the values on write, it completely ignores them on read. So that’s my best guess as to what might be causing the discrepancy. But I don’t think it’s a bug in MRtrix3… Does this mean the images are displaying differently in your other viewer, or just that the orientation is reported as being different…? ---
**Author:** ![mblesac](https://community.mrtrix.org/user_avatar/community.mrtrix.org/mblesac/32/2210_2.png) [@mblesac](https://community.mrtrix.org/u/mblesac)\ **Post date:** [June 8, 2016, 3:49pm UTC](https://community.mrtrix.org/t/modification-of-orientation-with-mrresize/279/7 "2016-06-08T15:49:55Z")
> [@jdtournier](#): > > ut Hi Donald, Thanks, that’s probably the reason, the images are perfect but in different orientation, once I change the orientation all are perfectly aligned. Regards, Manuel ---
**Author:** ![jdtournier](https://community.mrtrix.org/user_avatar/community.mrtrix.org/jdtournier/32/2594_2.png) [@jdtournier](https://community.mrtrix.org/u/jdtournier)\ **Post date:** [June 8, 2016, 3:50pm UTC](https://community.mrtrix.org/t/modification-of-orientation-with-mrresize/279/8 "2016-06-08T15:50:50Z")
OK, good to know. Just out of interest, how did you change the orientation…? ---
**Author:** ![mblesac](https://community.mrtrix.org/user_avatar/community.mrtrix.org/mblesac/32/2210_2.png) [@mblesac](https://community.mrtrix.org/u/mblesac)\ **Post date:** [June 20, 2016, 8:16am UTC](https://community.mrtrix.org/t/modification-of-orientation-with-mrresize/279/9 "2016-06-20T08:16:21Z")
Hi Donald, I changed the orientations using convert3d, with the -orient option. Regards, Manuel ---
**Author:** ![jdtournier](https://community.mrtrix.org/user_avatar/community.mrtrix.org/jdtournier/32/2594_2.png) [@jdtournier](https://community.mrtrix.org/u/jdtournier)\ **Post date:** [June 20, 2016, 9:50am UTC](https://community.mrtrix.org/t/modification-of-orientation-with-mrresize/279/10 "2016-06-20T09:50:15Z")
> [@mblesac](#): > > I changed the orientations using convert3d, with the -orient option. Thanks for the update. I’ve had a look through [the documentation for convert3d’s -orient option](https://sourceforge.net/p/c3d/git/ci/master/tree/doc/c3d.md#-orient-change-image-orientation), and I can’t make sense out of what you show. As far as I can tell, `convert3d` _should_ do what I’d expect it to, but it doesn’t match up with what seems to actually happen. Looking at the output of `mrinfo` that you provided earlier [in this post](http://community.mrtrix.org/t/modification-of-orientation-with-mrresize/279/5): ```auto Image: "7004_diff.nii.gz" ... Data strides: [-1 2 3 4] ... ``` and after mrresize: ```auto Image: "7004_diffRES.nii.gz" ... Data strides: [-1 2 3 4] ... ``` These suggest that the orientation should be interpreted by `convert3d` as `LAS` for both images - the only difference from the NIfTI-default RAS is the inversion of the x-axis. But neither of these match what you stated earlier on: > [@mblesac](#): > > the orientation of the original (RAI code) is RPI, and the resampled one is LPS So I’m not sure what would cause this discrepancy. The only thing I can think of is that your other viewer is interpreting some (deprecated and unused) flag in the NIfTI header. But if that’s the case, it would explicitly _not_ be NIfTI-compliant: the [NIfTI standard](http://nifti.nimh.nih.gov/pub/dist/src/niftilib/nifti1.h) states quite explicitly that _‘NIFTI-1 does not have the ANALYZE 7.5 orient field, which is not general and is often not set properly’_. The reasons for not using that field are discussed for example [on this page](http://www.grahamwideman.com/gw/brain/analyze/formatdoc.htm), under the section _‘The Problem With hist.orient Field’_, which highlights the issues associated with it for the old Analyze format. In fact, given that the byte offset to this entry in the old Analyze header is now within the NIfTI qform code, I can’t see how you can interpret a proper NIfTI image that way, it’s just not possible. So maybe that’s not what the problem is, I just can’t think of any other semi-sensible interpretation… ---
**Author:** ![mblesac](https://community.mrtrix.org/user_avatar/community.mrtrix.org/mblesac/32/2210_2.png) [@mblesac](https://community.mrtrix.org/u/mblesac)\ **Post date:** [June 20, 2016, 11:06am UTC](https://community.mrtrix.org/t/modification-of-orientation-with-mrresize/279/11 "2016-06-20T11:06:04Z")
Hi, I don’t know the reason behind this miss match of the orientations. Attached is a screnshoot of how they look in the ITK-Snap viewer (left is the raw image, right the up-sampled image). This was a problem to realize some registrations, but after reorient the image, everything works fine. I don’t know if more people found this problem… Regards, Manuel ![](https://community.mrtrix.org/uploads/default/original/1X/8d43478635b7361a1d5e8b5ef03235fae11fbd60.png) ---
**Author:** ![jdtournier](https://community.mrtrix.org/user_avatar/community.mrtrix.org/jdtournier/32/2594_2.png) [@jdtournier](https://community.mrtrix.org/u/jdtournier)\ **Post date:** [June 20, 2016, 3:26pm UTC](https://community.mrtrix.org/t/modification-of-orientation-with-mrresize/279/12 "2016-06-20T15:26:07Z")
I’m pretty stumped by this… Any chance you could post the output of FSL’s `fslhd` on each of those images…? ---
**Author:** ![mblesac](https://community.mrtrix.org/user_avatar/community.mrtrix.org/mblesac/32/2210_2.png) [@mblesac](https://community.mrtrix.org/u/mblesac)\ **Post date:** [June 20, 2016, 7:56pm UTC](https://community.mrtrix.org/t/modification-of-orientation-with-mrresize/279/13 "2016-06-20T19:56:50Z")
Hi Donald, fslhd for the raw file: ``` filename /mnt/usb-TOSHIBA_External_USB_3.0_20150819005525F-0:0-part1/TRACTOGRAPHY/RAW/DIFF/beforeUP/B0/7004_B0.nii.gz sizeof_hdr 348 data_type FLOAT32 dim0 3 dim1 128 dim2 128 dim3 50 dim4 1 dim5 1 dim6 1 dim7 1 vox_units mm time_units s datatype 16 nbyper 4 bitpix 32 pixdim0 0.000000 pixdim1 2.000000 pixdim2 2.000000 pixdim3 2.000000 pixdim4 1.000000 pixdim5 0.000000 pixdim6 0.000000 pixdim7 0.000000 vox_offset 352 cal_max 0.0000 cal_min 0.0000 scl_slope 1.000000 scl_inter 0.000000 phase_dim 0 freq_dim 0 slice_dim 0 slice_name Unknown slice_code 0 slice_start 0 slice_end 0 slice_duration 0.000000 time_offset 0.000000 intent Unknown intent_code 0 intent_name intent_p1 0.000000 intent_p2 0.000000 intent_p3 0.000000 qform_name Aligned Anat qform_code 2 qto_xyz:1 -2.000000 0.000000 -0.000000 135.918015 qto_xyz:2 0.000000 2.000000 -0.000000 -152.490677 qto_xyz:3 0.000000 0.000000 2.000000 -71.929497 qto_xyz:4 0.000000 0.000000 0.000000 1.000000 qform_xorient Right-to-Left qform_yorient Posterior-to-Anterior qform_zorient Inferior-to-Superior sform_name Scanner Anat sform_code 1 sto_xyz:1 -2.000000 0.000000 0.000000 135.918015 sto_xyz:2 0.000000 2.000000 0.000000 -152.490677 sto_xyz:3 0.000000 0.000000 2.000000 -71.929497 sto_xyz:4 0.000000 0.000000 0.000000 1.000000 sform_xorient Right-to-Left sform_yorient Posterior-to-Anterior sform_zorient Inferior-to-Superior file_type NIFTI-1+ file_code 1 descrip FSL5.0 aux_file ``` and for the resampled file: ``` filename /mnt/usb-TOSHIBA_External_USB_3.0_20150819005525F-0:0-part1/TRACTOGRAPHY/RAW/DIFF/RES/7004vol_0000.nii.gz sizeof_hdr 348 data_type FLOAT32 dim0 3 dim1 256 dim2 256 dim3 100 dim4 1 dim5 1 dim6 1 dim7 1 vox_units mm time_units s datatype 16 nbyper 4 bitpix 32 pixdim0 0.000000 pixdim1 1.000000 pixdim2 1.000000 pixdim3 1.000000 pixdim4 7.300000 pixdim5 0.000000 pixdim6 0.000000 pixdim7 0.000000 vox_offset 352 cal_max 0.0000 cal_min 0.0000 scl_slope 1.000000 scl_inter 0.000000 phase_dim 0 freq_dim 0 slice_dim 0 slice_name Unknown slice_code 0 slice_start 0 slice_end 0 slice_duration 0.000000 time_offset 0.000000 intent Unknown intent_code 0 intent_name intent_p1 0.000000 intent_p2 0.000000 intent_p3 0.000000 qform_name Scanner Anat qform_code 1 qto_xyz:1 1.000000 -0.000000 -0.000000 136.418015 qto_xyz:2 0.000000 1.000000 0.000000 -152.990677 qto_xyz:3 0.000000 0.000000 -1.000000 -72.429497 qto_xyz:4 0.000000 0.000000 0.000000 1.000000 qform_xorient Left-to-Right qform_yorient Posterior-to-Anterior qform_zorient Superior-to-Inferior sform_name Scanner Anat sform_code 1 sto_xyz:1 -1.000000 0.000000 0.000000 136.418015 sto_xyz:2 0.000000 1.000000 0.000000 -152.990677 sto_xyz:3 0.000000 0.000000 1.000000 -72.429497 sto_xyz:4 0.000000 0.000000 0.000000 1.000000 sform_xorient Right-to-Left sform_yorient Posterior-to-Anterior sform_zorient Inferior-to-Superior file_type NIFTI-1+ file_code 1 descrip FSL5.0 aux_file ``` There are differences in the qform orientation, but I really don’t know why. Regards, Manuel ---
**Author:** ![jdtournier](https://community.mrtrix.org/user_avatar/community.mrtrix.org/jdtournier/32/2594_2.png) [@jdtournier](https://community.mrtrix.org/u/jdtournier)\ **Post date:** [June 20, 2016, 11:38pm UTC](https://community.mrtrix.org/t/modification-of-orientation-with-mrresize/279/14 "2016-06-20T23:38:56Z")
OK, there was a bug in the qform output in MRtrix3, which was discussed at length [in this thread](https://community.mrtrix.org/t/dwipreproc-error-inconsistent-left-right-order-stored-in-sform-and-qform/179/5?u=jdtournier), and I was hoping was fixed with [this commit](https://github.com/MRtrix3/mrtrix3/commit/7547d476e496c49effa2ea0a3406ca950a932f94) on April 22. If your install is older than that, there is a good chance updating might fix it (`git pull && ./build`). However, it might be that the fix I’d committed didn’t actually completely address the issue - the original problem seemed to persist in that thread, although I was unable to reproduce it. If updating doesn’t fix it, it would be good if I could have access to the data to investigate further. So this would address the discrepancy between the qform and the storm in the output, which sounds like the problem. The RAI code in ITKsnap matches what `fslhd` reports, and gets the wrong inferior-superior direction in the output. The most likely explanation is that ITKsnap is reading the (incorrect) qform and ignoring the sform (MRtrix3 uses the sform preferentially)… By the way, I notice that earlier on, I used `LAS` to describe what ITKsnap refers to as `RPI`, etc. The issue is that I expect for example `L` to mean ‘towards the left’, whereas ITKsnap expects it to mean ‘from left to right’ - the exact opposite. I’m not sure who’s right here - probably not me… But the point is there’s no disagreement, at least as far as the input image is concerned. The problem really seems to be confined to the incorrect qform…