Last edit: 050829 Graham Wideman 
FreeSurfer 
Understanding FreeSurfer Coordinates Article created: 20030514 
A challenge facing programmers working with FreeSurfer data, is trying to get one's mind around the several different coordinates systems. There's nothing terribly esoteric about it, it's just fiddly adding and subtracting, but without clear pictures it's too easy to get off by a half a voxel or two.
Here are the coordinate systems that are evident when working with FreeSurfer:
Name  Symbols  Description 
MRI Volume Files and Slices  Files COR001 through COR256  256 files containing 256 x 256 voxels 
MRI Volume Index  Byte, Row, Slice  0255 for each axis of 
Right, Anterior, Superior  R, A, S  Coordinates used to specify positions of vertices in FreeSurfer surface files 
Some 3D graphics environment (like OpenGL  X, Y, Z (Usually righthand coordinate system) 
So, our task is to identify unambiguously how these various systems relate to each other.
I don't discuss Talairach coordinates here. The Talairach process is essentially a preprocessing stage which warps the input volume, but still results in a 256x256x256 volume as described here. If you want to translate between pretalairach coordinates and the FreeSurfer MRI or RAS coordinates, you will of course need to know the talairach transformation.
The following figure summarizes the MRI voxel coordinates:
Guide to orientation. 

R: Right; L: Left A: Anterior; P: Posterior S: Superior; I: Inferior 
Things to note:
FreeSurfer specifies surface vertex positions using socalled RAS coordinates. Superficially, that looks like the figure to the right. However, we need to know how the RAS origin and scaling relates to the MRI volume.
The figure below summarizes the necessary info.
The central organizing fact is that the origin of the RAS coordinate space is centered in the voxel whose Volume Index is (128, 128, 128). Note that the RAS coordinate space is not centered in the overall MRI volume!
RAS Coordinate space is centered in the voxel whose Volume
Index is (128, 128, 128). One voxel has dimensions 1 x 1 x 1 in RAS space. 
The consequences of the midvoxel position of RAS origin, and the RAS axis directions are:
All voxels are centered on integer RAS positions
The overall MRI volume has edges at integer+half RAS coordinates
Because the RAS axes are not all in the same direction as Volume Index axes, the axis extents in RAS have different ranges: either 127.5 to + 128.5, or 128.5 to +127.5. This can be disconcerting if not alert to this aspect.
Just to make sure we have the coordinate relationships correct, here's a screenshot from tkmedit:
Right = 128  Byte Ant = Slice  128 Sup = 128  Row (corrected 20031210) 
And here are the limiting cases, so you can audit this discussion:
Finally, we can summarize this data ordering as (RL, SI, PA). In AFNI this would be known as RSP, other systems might refer to this as LIA.
Programmers might well want to arrange either the MRI voxel data or the surface data in a 3D graphical environment, such as OpenGL. Such spaces have coordinate systems that usually arranged according to the righthand orientation, as shown in the figures:
You are, of course, free to translate Volume Index and RAS to XYZ however you like. And in fact I've changed my mind several times on what's the optimum correspondence between the two coordinate systems. So here is one that maps RAS to a righthanded X,Y,Z coordinate system:
R = X
A = Y
S = Z
1. Position the MRI volume so that the center of voxel (Byte: 128, Row: 128, Slice: 128) is at the origin. (Note that this will probably entail specifying integer+half values for voxel edges and volume edges in each dimension.)
2. Orient directions so that increasing ByteinRow corresponds to X, Row corresponds to Y and Slice corresponds to Z.
3. Coordinates translate as follows:
Position in XYZ space of  
XYZ  Center of voxel at Voxel Index is at 
RAS direction 
X  128  Byte  +R 
Y  Slice  128  +A 
Z  128  Row  +S 
The capability is provided in tksurfer to select a vertex in the graphic window, and read the RAS coordinates from the tksurfer control panel. However, there's a surprise: tksurfer reports the RAS coordinates of that vertex in the original surface, not the coordinates of the vertex in the surface you are looking at. (This is especially a surprise if you didn't explicitly load the original surface into tksurfer.)
There is some sense to this  you may want to find the position in the original volume or wm volume of some defect that you spot in the smoothwm or inflated surface. The coordinates of a vertex on one of those surfaces will not be very useful. (And note there's a menu item to save such a point from tksurfer and navigate to it in tkmedit, or vice versa.)
Go to: or back to FreeSurfer main page.