The mri_toolbox download at
http://eeg.sf.net
contains matlab code that employs the orient header field to read and
orthotransform ANALYZE volumes (see the avw* functions). In this code
(ie, avw_img_read.m) there is complete documentation of the XYZ directions
for all 6 orthogonal orientations defined by ANALYZE in the avw.hdr.hist.orient
field, namely:
The default ANALYZE orientation is LAS (radiological orientation):
The neurological convention is RAS (only the direction of X is swapped):
This toolbox will try to load an Analyze volume (actually any .img file) as an LAS volume, so long as the avw.hdr.hist.orient field is set correctly. Thus, the avw_view function should always present the volume in LAS (radiological) orientation (a GUI control allows easy L/R flipping for viewing purposes). If you need to, you can use avw_flip to orthoflip any dimension, although this could easily invalidate the Analyze coordinate system (NOT recommended).
The avw.hdr.hist.orient field is "optional" and not all software will read or write it correctly. For example, SPM ignores it and MEDx sets an unused header field.
The flipped orientations (orient values 3-5) are only defined in Analyze to support a movie animation. The flipping is not done in the slice direction, but rather in the dimension that suits raster graphics. The flipping has NO relationship to the actual orientation of the volume, only to how the data is handled during graphics processes. Thus, orient values 3-5 are NOT recommended. For example, for a transverse LAS volume, the orient=3 option flips to the anterior-posterior direction (LPS), which does not provide for saving RAS volumes. Nevertheless, this toolbox will attempt to handle the flipped Analyze volumes correctly.
If your not sure what the orientation of a volume is, it is near impossible to differentiate LAS from RAS without landmarks in the image. A useful tool is the flip L/R control in avw_view. It will allow you to quickly flip left/right to find visual cues that differentiate these two orientations. Often the ventricles provide good asymmetry indicators. Some high resolution T1 anatomical data I have worked with was acquired with a small pinpoint artifact in the central voxel of the left most slice of the volume (what a great idea! except when it comes to intensity normalisation!). It's also possible to use radiological markers (a preferable method, perhaps, as it should avoid the intensity artifact when normalising or correcting Bo field distortions). If that information is not available to you, but you have the original scanner files, you can use your favourite software or some free offerrings: http://www.mricro.com/ or http://xmedcon.sourceforge.net to read the original scanner volume headers, which usually contain useful orientation information, if you can interpret it (maybe speak to your radiographer). You might then use MRIcro or Xmedcon to convert the original data to ANALYZE, in a specific orientation. Keep careful track of the orientation during this conversion, especially left/right. Also consider acquisition of a small phantom volume, containing LAS orientation markers, in the sequence you use for your subject data. You can then process that volume through all the stages of your analyses to confirm the final orientation.
When working with format conversions, consider these enlightening notes from Mark Jenkinson!
All the best getting it right. MRI volume orientation has been a problem for me, prompting development of the MRI_toolbox. After better understanding how it works, the anxiety dissipates ;-) (although never really leaves you at peace). It's frustrating that our visuo-spatial intelligence for 3D object orientation virtually goes out the window when looking at ortho slices! In reality, we know this is a simple problem, yet the ortho views are unyielding!
Just to get down to basics, imagine a 2D axial slice through the AC, viewed with the nose at the top. Take a row of that image that passes from ear to ear. This is the X dimension (Y is the posterior to anterior dimension). Simple enough.
The question is what is left or right? Are we looking at this slice from the feet up or from the top of the head down? You can look for anatomical asymetries and try to find "real-world" landmarks. Alternatively, a convention for the order of the data in the file should provide a reliable answer.
That is, if the "left side of the image" is pixel 1 (X=1) and the "right side of the image" is pixel N (X=N), Analyze file format specifies that pixel 1 is "patient right" and pixel N is "patient left", so the row pixel numbers increase from right to left, ie +X is left (+Y is anterior and +Z is superior, LAS). So we are looking at this slice from the feet upwards.
A 2D image is stored in an .img file as a continuous data stream (say 8 bits per pixel/voxel). When reading this continuous data stream into a 2D matrix, it is divided up into M rows and N columns. The header provides the information about how many rows (M) and how many columns (N), often they are the axial in-plane dimensions and equal, say 64x64, 128x128, or 256x256 (these values are in hdr.dime.dim). For a 2D axial slice, the data stream can be read one row at a time and each row has N pixels. For each row of the Analyze file, we have a column index 1:N, where index 1 is right and index N is left.
Thus, we can read an .img file without knowing anything about the size of the voxels. We can completely ignore any hdr.dime.pixdim values when reading the .img file and we should have a data matrix where +X direction is left.
This is the radiological convention. It is also the Analyze file convention. To violate this convention is to risk confusion about left/right orientation, the most intractible orientation problem in tomography.
Any software working with .img files in the Analyze 7.5 format must be able to rely on this convention to be able to display left/right properly. There is no way to determine left/right otherwise (although SPM has the .mat solution, which is itself a convention that *overrides* the Analyze file format).
So what happens when the pixdim is considered. It provides information about the real-world size of each pixel of each dimension. We usually use 4 dimensions: X mm, Ymm, Zmm and Time in msec (although Analyze provides for more dimensions). OK, but what happens when we have a -ve pixdim value?
Analyze 7.5 format does not support the neurological convention (ie, +X right). This causes a problem when using the Talairach atlas, which is given in neurological orientation. The MNI has done some great work to provide templates for registration into Talairach space. But how do you do this registration with Analyze files?
The MNI templates have a -X pixdim value. Given that the Analyze format specifies +X pixdim values and the radiological convention, this use of -X pixdim values indicates that the files are in neurological convention. I have no idea whether the actual data order of the MNI template .img files is +X left or right. It is possible that they could be either. If +X is right, they are pseduo-Analyze .img files. If +X is left, the .img files can be read by any Analyze software that abides by the Analyze/radiological convention and the only question is what to do with the -ve pixdim value.
In essence, FSL does not determine left/right - only the number of rows, columns, slices and timepoints and the absolute magnitude of voxels (mm) and time (msec) is important, the rest is image intensity analysis. Normalisation/registration is mainly image intensity analysis, but also involves reslicing. One qestion is whether the MNI template .img files are +X right or +X left (regardless of their .hdr files) and whether this has any implications for the order of the data .img files after normalisation. FSL relies on the order of the pixels in the .img file. Whatever goes into registration to the templates could come out with the same .img order as the templates, but only if the data is resliced into the template space and I don't think FSL does that. In FSL, the MNI templates are resliced into the "native experimental data" space during registration. I think most, if not all, of FSL processing is done in "native experimental data space", with Talairach coordinates provided from the FSL .mat files. That is, I think FSL registers/reslices the templates to experimental volumes and then calculates the inverse registration to get the Talairach coordinates (FSL .mat file). This avoids interpolation of the experimental data during registration, effectively leaving it entirely untouched. In this sense, what goes into FSL is what comes out it. But note that it is the .img files that are important, not whether the hdr.dime.pixdim is +ve or -ve. Please search the FSL email archives for more discussion on this topic (search for "Registering Talairach and MNI152 Spaces").
Also, consider these notes from Mark Jenkinson!
SPM2 provides two specific alternatives for data orientation, either radiological (LAS) or neurological (RAS). SPM uses a spatial transformation matrix to supplement the Analyze format, so you get *.hdr *.img and *.mat files, where the .mat file holds all spatial transformations. Please ask the FIL for information on whether or not SPM changes the order of the pixels in the .img file to represent the neurological orientation. You will find SPM help at http://www.fil.ion.ucl.ac.uk/spm/help/. You will also find some information about SPM handling of Analyze files at: http://www.fil.ion.ucl.ac.uk/spm/spm99.html#AzeFmt
John Ashburner offerred the following comments:
The SPM99-SPM2 differences are documented at
http://www.fil.ion.ucl.ac.uk/spm/spm2.html#Compat.
The SPM2 orientation is now the same as that of Analyze (when flip=1).
Unlike PET images, MR images can be acquired in any orientation. Because
of this, it is better to consider the handedness of the data, rather than
the orientation of a single slice. For example, an image can be rotated
by 180 degrees around the Y axis, which would flip the left-right ordering
of the voxels within a plane. The image would still have the same
handedness though. Mapping from voxels to co-ordinates in some mm space
is done via a .mat file, so the actual ordering of the data is unimportant
(provided the handedness is correct).
The NIFTI file format should be finalised soon. This will incorporate the affine transform
within it.
I understand that MRIcro has been developed in conjunction with SPM and it provides the option to flip files left/right. Chris Rorden has web pages that clarify whether the .hdr has -ve pixdim values and how to interpret them, also how the .img file is written out of MRIcro/SPM99/SPM2 for each of the neurological and radiological orientations. MRIcro does not read any .mat files (as of Jan 2004). You will find MRIcro at http://www.mricro.com/.
According to Chris, SPM2 and SPM99 always show images in NEUROLOGICAL orientation.
see http://bishopw.loni.ucla.edu/AIR5/index.html and especially http://bishopw.loni.ucla.edu/AIR5/technicalnotes.html and http://bishopw.loni.ucla.edu/AIR5/file_types.html#voxelorder. Also, this description of the AIR internal coordinate system is informative: http://bishopw.loni.ucla.edu/AIR5/coordinates.html. Note that the image voxel order specifies axial .img files, but it does not specify whether +X is left (radiological/Analyze) or +X right. It does indicate that larger X indices are assigned to each successive voxel in the .img file (for each row of the axial .img file). Lastly, the AIR page on homogenous coordinates is a nice introduction to the information used for registration matrices, see http://bishopw.loni.ucla.edu/AIR5/homogenous.html
See the AFNI main page http://afni.nimh.nih.gov/afni/ including the matlab tools at http://afni.nimh.nih.gov/ssc/ziad/AFNI_MatlabLib/. Note the following comment, "The data in the .BRIK is stored in the order (orientation) in which the images were loaded into to3d. So, in order to know how to slice through a data set you need to look into the Info structure (output of BrikInfo and BrikLoad). I have included the AFNI* functions to help shed some light into the darkness." Also, see these additional files for Talairach coordinates ftp://geon.usc.edu/mni_to_tlrc/