| MINC Programmer's Guide | ||
|---|---|---|
| <<< Previous | Next >>> | |
It is possible to build MINC format files using only NetCDF function calls, however a C include file is provided to facilitate (and help ensure) adherence to the standard. This file defines useful constants, standard dimension, variable and attribute names and some attribute values. It also declares the functions defined in a library of minc convenience functions, designed to make an application programmer's life easier.
Various requirements for file formats have been put forward. One such list is as follows: A protocol should be: 1) simple, 2) self describing, 3) maintainable, 4) extensible, 5) N dimensional, and 6) have a universal data structure. The NetCDF format meets all of these requirements, suggesting that it is a good place to start. I would, however, add some more requirements to the list. Implied in the above list is the requirement that there be a standard for accessing data (how do I get the patient name) --- this is not provided by NetCDF. Furthermore, a useful format should come with a software interface that makes it easy to use, particularly in a development environment. Finally, a format that stores many associated pieces of information should also provide some data organization.
The MINC format attempts to add these things to the NetCDF format.
Medical imaging tends to produce files with a large amount of ancillary data (patient information, image information, acquisition information, etc.). To organise this information in a useful fashion, MINC uses variables to group together related attributes. The variable itself may or may not contain useful data. For example, the variable MIimage contains the image data and has attributes relevant to this data. The variable MIpatient has no relevant variable data, but serves to group together all attributes describing the patient (name, birthdate, etc.). This sort of variable is called a group variable.
Variables that correspond to dimensions are called dimension variables and describe the coordinate system corresponding to the dimension. An example is MIxspace --- both a dimension and a variable describing the x coordinate of other variables.
The NetCDF conventions allow for these dimension variables to specify the coordinate at each point, but there is nothing to describe the width of the sample at that point. MINC provides the convention of dimension width variables, e.g. MIxspace_width, to give this information.
Finally, it is possible to have attributes that vary over some of the dimensions of the variable. For example, if we have a volume of image data, varying over MIxspace, MIyspace and MIzspace, we may want an attribute giving the maximum value of the each image, varying over MIzspace. To achieve this we use a variable, called a variable attribute, pointed to by an attribute of the image variable.
Thus MINC introduces a number of types of variables: group variables, dimension variables, dimension width variables and variable attributes.
MINC attempts to provide some level of data organization through a hierarchy of group variables. As mentioned above, attributes are grouped according to type in group variables. Each group variable can have an MIparent and an MIchildren attribute --- the former specifying the name of another variable that is above this one in the hierarchy, the latter specifying a newline-separated list of variables that come below this one in the hierarchy. At the root of the hierarchy is the MIrootvariable variable, with no parent. Although it is not necessary to make use of this structure, it can provide a mechanism for ordering large amounts of information.
The NetCDF format says nothing about variable and dimension naming conventions and little about attribute names. It does provide a few standards, such as the attribute "long_name" for describing a variable, which have been adopted by the MINC standard. MINC defines a set of standard names for commonly used entities and the include file defines constants specifying these names. These are described at length in the MINC reference manual. The most interesting of these is MIimage, the name of the variable used for storing the actual image data in the file.
The MINC standard gives some special status to the concept of an image. There is nothing inherent in NetCDF that suggests any special status for particular dimensions, but it can be convenient to place limitations on what can vary over which dimensions in an imaging context. For example, the requirement that the variables that specify how to rescale images (see later section on pixel values) not vary with image dimensions means that we can treat the image as a simple unit. In the simplest case, the image dimensions are simply the two fastest varying dimensions of the MIimage variable.
It can also be helpful to allow for vector fields --- images or image volumes that have a vector of values at each point. A simple example of a vector field is an RGB image. At each point in space, there are three values: red, green and blue. The dimension MIvector_dimension is used for the components of the vector and it should be the fastest varying dimension in the MIimage variable. If it is present, then the three fastest varying dimensions of MIimage are the image dimensions.
The MINC standard defines how spatial coordinates should be oriented relative to patients. Files are free to have data stored in the desired direction, but positive world coordinates are given a definite meaning in the medical imaging context. The standard is that the positive x axis points from the patient's left to right, the positive y axis points from posterior to anterior and the positive z axis points from inferior to superior.
The conversion of element index to world coordinates is done using the dimension variable attributes MIdirection_cosines, MIstep and MIstart. If the direction cosines are c=(c_x, c_y, c_z), then the vector between adjacent elements along an axis is step x c. If start(i) and c(i) are the MIstart and MIdirection_cosines attributes for dimension i (one of MIxspace, MIyspace and MIzspace), then the first element of the image variable is at world coordinate \sum_i start(i) c(i).
If the direction cosines are not present, then they are assumed to be (1,0,0) for MIxspace, (0,1,0) for MIyspace and (0,0,1) for MIzspace. Direction cosines are unit vectors and should be normalized. As well, the step attribute should carry the information about axis flipping (negative or positive) rather than the direction cosine.
In medical imaging, pixel values are frequently stored as bytes or shorts, but there is a generally a real value associated with each pixel as well. This real value is obtained by a scale factor and offset associated with each image or image volume. The MINC standard indicates how pixel values should be interpreted.
Image data in the MIimage variable can be stored as bytes, shorts, ints (32-bit), floats or doubles. NetCDF conventions use the attributes MIvalid_range or MIvalid_max and MIvalid_min to indicate the range of values that can be found in the variable. For short values, for example, we might have a valid range of 0 to 32000. To convert these integers to real values, we could use a scale and offset. However, these values would have to change if the data where converted to bytes in the range 23 to 228.
If we specify an image maximum and minimum to which MIvalid_max and MIvalid_min should be mapped by an appropriate scale and offset, then we can convert type and valid range without having to change the real maximum and minimum. To allow the maximum dynamic range in an image, we use the variables MIimagemax and MIimagemin to store the real maximum and minimum --- these can vary over any of the non-image dimensions of MIimage.
| <<< Previous | Home | Next >>> |
| Programming with NetCDF | General convenience functions |