Orientation, labelling and getting left and right correct are important but often confusing issues. You should always look at your data and check if the labels in FSLView are correct. No further analysis should ever be done if the labels in FSLView are incorrect or missing. If your labels are fine then you probably will not need to use any other these tools, although fslreorient2std may be useful. If not, then you will need to read on. We have tried to simplify the usage of the tools for common tasks involving orientation issues, although still providing flexible and powerful tools for the expert user.

Common problems

We describe here the most common problems and how to solve them. If you have a different problem then you will need to work with the advanced tools described later (and read the information on NIfTI orientation).

1. The labels in FSLView are wrong or missing

This is very serious and needs to be fixed before doing any analysis at all. Ideally it should be fixed by using a tool that creates a correct NIfTI file. There are numerous converters from DICOM to NIfTI -- for recommendations, see the FSL FAQ. A correct converter should store the correct information in the NIfTI file so that the labels are correct when viewed in FSLView. If you have tried many converters and still cannot get the images converted correctly then you will need to use the advanced tools, fslswapdim and fslorient, to fix the problem (more info below).

2. The labels in FSLView are correct but the image is oriented "wrongly"

By default FSLView shows the image in the way that the scanner acquired it, so that sagittal, coronal and axial scans look very different. Hence this is not really "wrong" - just how FSLView chooses to display the images. If you do not want this but want to see the image in the same orientation as the standard templates (MNI152) then you can run the tool fslreorient2std which is designed for just this task. However, make sure that the labels are correct in FSLView to start with, as this tool only works if they are correct.


Serious (uncommon) problems

1. The labels in FSLView are wrong or missing and no conversion to NIfTI can fix this

If this really cannot be fixed at the conversion stage, then it is possible to fix by the follow (only to be attempted after reading the following section on background information on NIfTI orientation): 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. However, unless you have some way of telling left from right in the image (e.g. by a vitamin capsule or clearly known structural asymmetry) this method can easily result in an incorrect left-right labelling and so should not be attempted.

Background information on NIfTI Orientation

This section is purely optional but is extremely useful to understand if you are working with any of the advanced tools, have unusual problems, or are just plain interested.

The NIfTI standard is confusing for many people on the issue of orientation, largely because it is intrinsically a confusing issue. It is complicated because the intensity data is stored on disk as a list of numbers - there is no concept of spatial or anatomical location with these numbers, and so information and standard conventions are used to associate spatial and anatomical location information with these numbers.

To start with, voxel coordinates are associated with the numbers (intensity values), such that the first number is at coordinate (0,0,0) the second at (1,0,0), the third at (2,0,0), etc. So, for example, say the image was 64 by 64 by 20 in size, then the coordinates would go as (0,0,0) then (1,0,0) ... then (63,0,0) then (0,1,0) then (1,1,0) then (2,1,0) ... then (63,1,0) then (0,2,0) ... then (63,63,0) then (0,0,1) then (1,0,1) ... until (63,63,19). Note that all coordinates start at 0, not 1, and that the first coordinate (i) here is the one that increases the fastest as you go through the list, followed by second (j) and then the third (k). These voxel coordinates - (i,j,k) - give spatial information (using information about how many voxels are in the three spatial directions) but do not attribute any anatomical information at all.

To go from voxel coordinates to more anatomically meaningful coordinates is the job of the qform and sform matrices that are stored in the NIfTI file. Note that these matrices only provide useful information if they have a non-zero code, since a zero code indicates that the matrix is "Unknown" and hence cannot be used. Having two matrices here is a common source of confusion. They were originally proposed so that two different coordinates could be kept track of - one representing the scanner coordinate system (the real space inside the scanner bore) and the other one relating to standard space coordinates (e.g. MNI152). However, in practice, it is rare that both contain different information as they are often set to be the same, or one of them is "Unknown" in which case the other contains all the useful information.

Either matrix (qform or sform) is used to convert the voxel coordinates into "real world" coordinates (also called continuous coordinates, or mm coordinates, or other names). These new coordinates - called (x,y,z) here - have units of mm, and can take any values, not just positive whole numbers like the (i,j,k) voxel coordinates. Note that FSLView displays both voxel and mm coordinates. [Aside: the conversion is done by multiplying the matrix with the voxel coordinate, reshaped as a 4x1 vector with the last element equal to 1 - although this detail is not important for any of the discussion or understanding.]

If the qform (or sform) is set so that it gives information about scanner coordinates (as indicated by the code), then a standard convention is used to relate the coordinate values to the anatomy. The convention is: +x = Right; +y = Anterior; +z = Superior. That is, moving in the positive x-direction (so that the x-coordinate increases) will be moving to the right, etc. This now allows left and right to be distinguished, which is usually not possible just by looking at brain images. Hence this information is absolutely crucial and getting this right for the conversion of the image to NIfTI format is extremely important. If it is incorrect then it would be easy for left and right to be assigned incorrectly and all analysis results to be on the wrong side. The information from the qform and sform is what is used by FSLView to determine the labels that are shown on the image.

If the sform is set so that it gives information about standard space coordinates then the situation is the same as above, since the standard convention used above was chosen to be the same as the convention chosen for the standard space coordinate systems (MNI152 and Talairach). The main difference between the two situations is that the transformation to standard space (represented by the sform matrix) also involves scaling and shearing of the coordinate axes to make the brain "fit" the standard templates, whereas the transformation to scanner space coordinates is normally just a rotation and translation.

An aside on left-right conventions: it is possible to store an image in many different ways that are totally and completely equivalent in terms of the intensities and the (x,y,z) coordinates. What can be different is the voxel coordinates (and hence the order of the intensities stored in the file) but if only the images are being used in the analysis then these conventions are unimportant for all analysis purposes - they are purely related to the storage format, in this case NIfTI - only the (x,y,z) coordinates and the intensity values count with respect to the analysis. The one exception to this is when voxel coordinates are required for the commands (either on the command-line or in the GUI - for example fslroi, FDT GUI, etc.) and only in these cases is it important that the voxel coordinates are known. That being said, one common confusion arises when the left-right order of the storage is changed (but the mm coordinates and intensities are unchanged). For instance, imagine taking an image where the first voxel is on the left and then swapping the left-right order so that the new image is stored such that the first voxel is now the rightmost one, but modifying the qform and sform matrices appropriately so that this rightmost voxel still has the same (x,y,z) coordinate as it had before - just a different voxel coordinate. This kind of change will not affect any analysis in FSL or any programs that are fully NIfTI compliant. However, some programs are only happy with one sort of ordering (sometimes called left-handed/right-handed, or radiological/neurological, or RAS/LAS, etc.) This used to be the case for old versions of FSL, but is no longer true. But if only the order of the intensities in the file is swapped, without compensating for this in the sform and qform matrices, then the swapped version is no longer equivalent to the original. This is why both the data order and header information need to be kept in sync, and why running either fslswapdim or fslorient alone to change the orientation information is dangerous and usually incorrect.

An aside on display orientation: everything that has been said above about the NIfTI format refers to coordinates and data storage and has nothing to do with what way the images can be displayed in different viewing programs. Although the storage can be referred to as "radiological" or "neurological" this does not mean anything with respect to the displayed orientation. A valid NIfTI image can be displayed in any orientation that the viewing tool chooses, with the left side of the brain shown on the right side of the screen (so called radiological convention) or the other way around (neurological convention). It is also possible to display the inferior side of the brain at the top of the image, or any other configuration. It is entirely up to the display software how it chooses to show the image on the screen. What the NIfTI format does do is provide information to determine how to label the different parts of the image (with mm coordinates or anatomical labels such as left, right, anterior, posterior, superior and inferior). As long as the display tool correctly interprets this information and keeps it consistent with its choice of display orientation, there is no conflict between any type of NIfTI image and any displayed orientation.



Orientation Explained (last edited 08:11:34 11-12-2015 by EugeneDuff)