Differences between revisions 9 and 10
Deletions are marked like this. Additions are marked like this.
Line 39: Line 39:
||inflated ("football")||inflated.H ||mean[[BR]]variance[[BR]]Degrees-of-freedom ||
||smoothwm ||sulc (ie: convexity)||mean[[BR]]variance[[BR]]Degrees-of-freedom||
||smoothwm ||curv? ||mean[[BR]]variance[[BR]]Degrees-of-freedom||
||<^>inflated ("football")||<^>inflated.H ||mean[[BR]]variance[[BR]]Degrees-of-freedom ||
||<^>smoothwm ||<^>sulc (ie: convexity)||mean[[BR]]variance[[BR]]Degrees-of-freedom||
||<^>smoothwm ||<^>curv? ||mean[[BR]]variance[[BR]]Degrees-of-freedom||

Notes:[[BR]]
1. "inflated.H" is likely "mean curvature", that is the per-vertex value (kmin+kmax)/2.[[BR]]
2. I'm not sure on the measure in the 3rd row because in the mris_register source code it's calculated on the fly, and hard to tell which options cause it to do what.

So, we expect that the standard template contains nine arrays of (256 * 512) numbers.

== Template data storage format; What's with this tif business anyway? ==

In several areas throughout !FreeSurfer, non-obvious choices have been made regarding persisting (saving to disk for later use) various kinds of data, and this is the case for templates.

The !FreeSurfer code includes a library called that is suitable for handling 2-D images (ie: pictures), which already knows how to work with 2-D arrays of pixels, including keeping track of the type of data at each pixel, rows and columns and so on. In addition, it is able to save and load various image formats. As it happens, the TIFF format is able to do two useful things in this regard: save multiple images, and apply compression.

So, the template's (256 * 512) arrays are handled in memory as though they are images, and loaded and saved using TIFF functions.

By way of closure, here is lh.average.curvature.filled.buckner40.tif as seen in an image viewer (irfanview):

Index TableOfContents

Context: The surface registration process

This page relates to the "template" file type used in the FreeSurfer pipeline as part of the process of coregistering the surfaces of individual subjects. Several concepts are needed to understand this area. (In the following "?h." refers to either of "lh." or "rh.".)

  • Inflated Spherical "version" of a subject's surface mesh: As the pipeline progresses, the initial white surface mesh is "inflated" (with constraints to minimize distortion) to several other states, one of which is a sphere, typically ?h.sphere. The inflation process is constrainted to minimize the total distortion.

  • Vertex-wise data is applicable to all versions of the surface: The inflation process does not add or remove any vertices, so any data associated with the white vertices (such as curvature or convexity) is still associated with the same-numbered vertices of the sphere mesh. This is the basis of displays such as the following where a per-vertex variable "convexity" of the white surface (aka 'sulc') is plotted in color on the lh.sphere surface:BRattachment:fsbert_sulc_sphere.jpg

  • Registration of a subject's surface to a reference consists of a 2-D warp of the subject's sphere surface so that the individual's curvature data pattern aligns with a reference template pattern. The template was previously prepared as the "average" (loosely speaking) pattern from a group of representative subjects. The standard template supplied with FreeSurfer is in the files {fshome}/average/?h.average.curvature.filled.buckner40.tif.

  • The result of registation is yet another version of the subject's surface mesh, typically named ?h.sphere.reg, this time with the x,y,z vertex positions still on a sphere, but warped so that the subject's curvature pattern best aligns with the template data. Here is the same convexity data, now plotted on the lh.sphere.reg surface. Similar appearance, but "stretched around". BRattachment:fsbert_sulc_spherereg.jpg.

What is to be discussed below relates to the content and format of the template file just mentioned.

Disambiguation: template vs atlas

In many places, especially within the FreeSurfer source code, the word "atlas" is often used interchangeably with "template". I am reserving the term atlas for the GCA files used in labeling regions.

Template data

Template data grid

As might be guessed, a template contains curvature-related data as an array of data items that correspond to a grid of points on the sphere -- but which grid? Is it a specific surface mesh supplied with FreeSurfer? A standard "icosahedron"? As it turns out, it's a grid defined in spherical coordinates:BR

  • theta (0..2*pi in 512 steps)
  • phi (0..pi in 256 steps)BR

... the two parameters of the so-called "surface parameterization" (elsewhere known as u and v).

So, for any single data item, we can expect an array(256 * 512) of numbers.

Template data items

The various programs involved have some flexibility in what size and shape of template to work with, but here I will describe the standard ?h.average.curvature.filled.buckner40.tif.

The registration process does not simply attempt to match a subject and template based on a single variable. Instead it works with several variables, and statistics about those variables.

Here's what I think is in the standard template:

Surface

Measure

Variable/Statistics

inflated ("football")

inflated.H

meanBRvarianceBRDegrees-of-freedom

smoothwm

sulc (ie: convexity)

meanBRvarianceBRDegrees-of-freedom

smoothwm

curv?

meanBRvarianceBRDegrees-of-freedom

Notes:[[BR]] 1. "inflated.H" is likely "mean curvature", that is the per-vertex value (kmin+kmax)/2.BR 2. I'm not sure on the measure in the 3rd row because in the mris_register source code it's calculated on the fly, and hard to tell which options cause it to do what.

So, we expect that the standard template contains nine arrays of (256 * 512) numbers.

Template data storage format; What's with this tif business anyway?

In several areas throughout FreeSurfer, non-obvious choices have been made regarding persisting (saving to disk for later use) various kinds of data, and this is the case for templates.

The FreeSurfer code includes a library called that is suitable for handling 2-D images (ie: pictures), which already knows how to work with 2-D arrays of pixels, including keeping track of the type of data at each pixel, rows and columns and so on. In addition, it is able to save and load various image formats. As it happens, the TIFF format is able to do two useful things in this regard: save multiple images, and apply compression.

So, the template's (256 * 512) arrays are handled in memory as though they are images, and loaded and saved using TIFF functions.

By way of closure, here is lh.average.curvature.filled.buckner40.tif as seen in an image viewer (irfanview):

Author(s)

GrahamWideman

TemplateTifImageFiles (last edited 2009-02-02 20:29:28 by GrahamWideman)