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. 
NIfTI
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:
-
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.
-
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
or
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… 
Cheers,
Donald.
