Last edit: 05-08-29 Graham Wideman
|Understanding FreeSurfer Coordinates
Article created: 2003-05-14
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:
|MRI Volume Files and Slices||Files COR-001 through COR-256||256 files containing 256 x 256 voxels|
|MRI Volume Index||Byte, Row, Slice||0-255 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 right-hand 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 pre-processing stage which warps the input volume, but still results in a 256x256x256 volume as described here. If you want to translate between pre-talairach 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 so-called 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 mid-voxel 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
And here are the limiting cases, so you can audit this discussion:
Finally, we can summarize this data ordering as (R-L, S-I, P-A). 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 right-hand 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 right-handed 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 Byte-in-Row 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
|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.