Reorienting images

Hi everyone

I am trying to reorient the atlas image and also it segmentations using Mrtrix3. I was able to interchange the y and z axis and also i used flip option to get the desired orientation for the atlas. Now I wanted to get the segmentation file for the atlas to be in the same orientation as the atlas. For the same I used mrtransform -replace file option , thinking the transformation matrix of the atlas file would be applied on the segmentation file. I got the output file but when i try to use it for normalization, i get an error saying the matrix is singular or badly scaled.

I am not sure if there was problem when i applied the transformation matrix of atlas to the segmentation file.

Can some one help me with this?

thanks for help.


Sorry for the delay, I’ve had a few other issues to deal with before I could look into the data you sent me.

The problem is that the segmentation image has different dimensions compared to the atlas, and consequently the origin for the transformation is different – this is due to the fact that you’re passing in images in Analyze format, which can’t store the transformation information, so MRtrix3 assigns them a sensible default one (straight axial centred on the origin). You can see this with a call to mrinfo (note the warnings for the two images in Analyze (hdr/img) format):

 $ mrinfo.exe atlas.img atlasReoriented.nii nuclei_delineationsi_for_skull.img
mrinfo: [WARNING] transform matrix contains invalid entries - resetting to sane defaults
Image:               "atlas.img"
  Dimensions:        256 x 256 x 256 x 1
  Voxel size:        0.8 x 0.8 x 0.8 x 0
  Data strides:      [ -1 2 3 4 ]
  Format:            AnalyseAVW / NIfTI
  Data type:         signed 16 bit integer (little endian)
  Intensity scaling: offset = 0, multiplier = 1
  Transform:                    1           0           0        -102
                                0           1           0        -102
                                0           0           1        -102
Image:               "atlasReoriented.nii"
  Dimensions:        256 x 256 x 256
  Voxel size:        0.8 x 0.8 x 0.8
  Data strides:      [ -1 3 2 ]
  Format:            NIfTI-1.1
  Data type:         signed 16 bit integer (little endian)
  Intensity scaling: offset = 0, multiplier = 1
  Transform:                    1          -0           0        -102
                               -0           1           0        -102
                               -0           0           1        -102
mrinfo: [WARNING] transform matrix contains invalid entries - resetting to sane defaults
Image:               "nuclei_delineationsi_for_skull.img"
  Dimensions:        300 x 300 x 512
  Voxel size:        0.8 x 0.8 x 0.8
  Data strides:      [ -1 2 3 ]
  Format:            AnalyseAVW / NIfTI
  Data type:         unsigned 8 bit integer
  Intensity scaling: offset = 0, multiplier = 1
  Transform:                    1           0           0      -119.6
                                0           1           0      -119.6
                                0           0           1      -204.4

What this means is that simply replacing the transform of one with the other won’t do what you’re after: the origin will be set wrong. On top of that, MRtrix3 handles transformation information quite differently from other packages, so the operation won’t even swap the axes like you wanted…

The simplest thing to do here is simply to rotate the data by 90°. You can do this by copy/pasting the following into a text file, called say trans.txt, and then asking mrtransform to apply this transformation to the data.

file trans.txt:

1 0 0 0
0 0 1 0
0 1 0 0
0 0 0 1


mrtransform -linear trans.txt nuclei_delineationsi_for_skull.img nuclei_delineationsi_for_skullReoriented.nii

This seems to do the trick.

However, I note that the transformation applied here is not a pure rotation: swapping the y & z axes like this is a mirroring operation, and converts a left-handed coordinate system into a right-handed one (vice versa). I’d be very careful with these types of manipulations, unless you are absolutely sure that it does what you expect, or you don’t care about left & right. Moreover, if you do care about not mixing up right & left, you should also never use the Analyze image format, and at the very least use NIfTI instead.



Thanks so much for your reply. I do not want to change the left and right of the brain. So If i convert the images into Nifti format, I should be able to change the axis like you said and it should not affect the left and the right?

Thank you


It’s unfortunately a lot more complicated than that… This is going to take a while to explain, I’ll try to keep it brief.

Analyze & SPM left/right ordering

The Analyze standard originates from the Mayo Clinic, and their specification of the format was ambiguous about one crucial issue: the ordering of the voxels on file (it’s still ambiguous, by the way: no mention of left/right ordering in the official docs). To understand this, you’ll need to understand the concept of strides, for which I’ll refer you to our documentation on the matter.

But to cut a long story short, the Analyze standard doesn’t state unambiguously whether the voxel values are stored on file from anatomical left to right, or from right to left. In practice, the convention used in Analyze (the software package) is to store them from right to left, which is why it’s sometimes called radiological convention (which is a very bad way to describe it IMO, since a neurologically stored image can easily be displayed radiologically – the neurological / radiological labels should only refer to the display, not the storage convention).

However, in the early days of SPM, which handled Analyze format images, the opposite convention was assumed: voxels were assumed to be stored left to right. This means an image produced by Analyze (the software) would be interpreted as the left/right mirror image of what it should have been – and vice-versa. But there is no information in the Analyze format header from which to figure out which was which. So this introduces a fundamental ambiguity in the handling of these data. While it’s trivial to check whether you’ve got front & back right, and similarly for up & down, it’s often too subtle to tell left from right on visual inspection of (healthy) brain images.

You can imagine how important this is when the processed data are to be used for e.g. neurosurgery planning (as fMRI was & is commonly used for). But at least there was no issue provided all of the processing, including the initial DICOM import, was done within SPM, since the convention assumed, although wrong, was at least applied consistently. Issues would arise only when passing Analyze images between SPM and Analyze (the software), since they assumed different conventions – but this rarely happened in practice.

But it got worse again when SPM realised that something needed to be done, so they introduced a setting in SPM2 to allow the user to chose which convention should be assumed. While this sounds like a good idea, and was undoubtedly a necessary step for them to take, this also meant that data processed via SPM could be either stored one way or the other, with no way to know with any degree of certainty which setting was used at the time the image was produced. Also, any data produced using the older version of SPM (or the new one using the old defaults) couldn’t be mixed with data generated from the new version (with the new default) without introducing the very real possibility of getting left & right wrong. So back in the day, we took the decision to ditch all of our previous data and process everything afresh from scratch, having tripled-checked that all SPM installations in the lab were updated to the new version, with the same setting for the flip. Those were fun times. :face_with_symbols_over_mouth:


The NIfTI format came along to solve this and other issues. It clearly states what order the voxel values were to be stored on file, and how to figure this out from the header. It also allows storage of the transformation information, so that the voxels can be mapped to their real space positions (the old Analyze format does not store this information, SPM used to rely on separate .mat files in MatLab format to store this, one per image). These are two very compelling reasons why you want to use the NIfTI format in preference to Analyze – personally, I urge everyone to avoid Analyze format like the plague.

As an aside, the NIfTI standard group decided that rather than come up with a new format altogether, they would adapt the Analyze format to allow backwards-compatibility, and squeeze the additional required information in fields that were broadly unused anyway. This was probably a good idea at the time, but this means you can get a *.hdr/*.img file pair, which looks like Analyze format, but is actually in NIfTI format… In fact, when you ask an MRtrix3 application to produce an Analyze format image, you actually get a NIfTI format image stored as an *.hdr/*.img pair. The *.nii single-file format is essentially the concatenation of the two files, and is a much more sensible format to use – if only to make it clear to the user that this is a different format from Analyze.

What does this mean for you?

There are actually two issues I’d be worried about in your case:

  1. Are the original data correct? When I receive data in Analyze format, I instinctively assume that left & right are undefined. If I need to process these data in a way that requires knowledge of left & right, I ask whoever supplied these images to quadruple-check the entire conversion process. Better still, if the DICOM data are available, to send that rather than the Analyze-converted images (at least the manufacturers provide some guarantees that their DICOM output should be correct – though not always with pre-clinical systems…). Otherwise, I might ask them to verify with an image acquired with a clear fiducial marker (liquid vitamin pills are often used for this): place it next the animal’s head within the field of view, take a photo of the setup for future reference, acquire the data, and verify that the fiducial is in the expected position.

    All this to say: I’d urge you to be very suspicious about your current input (Analyze) data, and go back to the raw format if at all possible, bypassing Analyze altogether.

  2. Does your transformation preserve left & right? The operation you’ve performed here doesn’t: swapping the y & z axes mirrors the data about the plane bisecting the y & z axes (with normal vector [ 0 -1 1]). A mirror operation will swap left & right. The operation I suggested previously uses a transformation matrix that performs the same operation as you originally applied, so is equally left & right swapping. If you want to do a left/right preserving operation, you need to make sure it is a pure rotation. In your case, a suitable transformation matrix might be:

    1  0  0  0
    0  0 -1  0
    0  1  0  0
    0  0  0  1


    1  0  0  0
    0  0  1  0
    0 -1  0  0
    0  0  0  1

    So once you’re confident your data are in the correct orientation, you could if needed apply the mrtransform -linear trans.txt call using one of the above matrices as the contents of trans.txt. If some other transformation is required, make sure it has determinant = 1 (positive unit determinant means no flipping and no volume change).

OK, I think that should just about cover it… :sweat:


thank you so much for explaining in detail.

So the whole point of changing the orientation of the atlas image was to bring it in the same orientation as to the functional data that i have.

The atlas images are freely downloadable from the university of antwerp who made the atlas sometime ago. There are only .hdr/img files. I did not find the original scanner files to avoid any conversion to niftii. So I converted the images myself using SPM.

I earlier said I did not want to change the left/right in the image. But I realised that the functional data that i have is in LPI orientation as compared to the atlas which is RPI.

So I used the following matrix to do the conversion.
-1 0 0 0

0 1 0 0

0 0 1 0

0 0 0 1

when i tried to put the functional data to the atlas space using mrregister - functional data (moving) atals (fixed)
I got an error "final warp computed is not diffeomorphic (negative jacobian determinants detected). Try increasing -nl_disp_smooth or -nl_update_smooth regularisation.

I have pasted the link to the input images for the mrregister command.

Link to images

I really appreciate your help in this.

thank you