Although the AIR package was originally designed for use with 8 bit images, 16 bit images are fully supported, and the current AIR development environment uses 16 bits to represent images internally. Compilation of AIR in 8 bit mode is no longer generally recommended unless your machine is especially short of RAM and disk space. Modern MRI data is not generally well represented with only 8 bits of precision. Aside from this loss of precision, the primary disadvantage of using an 8 bit version of AIR is that care must be taken to assure that 16 bit values in image files will be converted into 8 bit values in a way that maximizes the dynamic range of the converted images. The AIR package does provide a mechanism for mapping 16 bit values to 8 bit values at the time that the images are loaded, making it unnecessary to store separate 8 bit versions of files on disk. If you choose to use an 8 bit version of AIR, you should review the illustration that shows the import and export mapping of voxel values
16 bit versions of AIR must also remap voxel values when importing and exporting data. Optimal use of the AIR package with 16 bit data requires a detailed understanding of these issues. Even if you fully understand the C representation of signed and unsigned integers, the AIR package handling of these issues is sufficiently idiosyncratic that you will need to review the information in this document. At a minimum, you should review illustrations showing the import and export mapping of voxel values for 16 bit versions of the AIR package. When a 16 bit version of AIR package is configured and compiled, a decision must be made about how data in 16 bit files generated by the AIR package will be represented. The package must be recompiled if a different output representation is desired. The person compiling the AIR package is responsible for correctly specifying how data in 16 bit files generated by the AIR package is represented.
Sixteen bit data can be represented on disk in a number of different formats, and it is critical that the format used to store the images to be registered be correctly identified. The AIR package cannot determine on its own what convention has been used for storing data, and the user is responsible for correctly specifying how data in external files that were not generated by the AIR package is represented. It is especially important that pixels that should be displayed as black by your image display program (assuming that black represents the background, i.e., not part of the object of interest) be mapped to a value of zero internally in AIR. The information below should help you to assure that this is the case.
In order to understand how the AIR package deals with the number of bits/pixel, it is necessary to make a distinction between three different types of data representation:
All versions of the AIR package (8 or 16 bit) are able to load external data stored in 8 bit and 16 bit formats. The programs use the header files to determine whether a given image file contains 8 bit or 16 bit data. The external values stored in the image file are mapped onto the AIR package's internal representation according to preset rules designed to optimize use of the internal representation's dynamic range. The import mapping of 16 bit values to 8 bit values can be optimized by specifying the largest value represented in the 16 bit images, a step that is unnecessary if you are using a 16 bit version of AIR. Three different types of external 16 bit data representation are supported. The specific 16 bit data type is specified in the header file, and an incorrect designation of the data type in the header file will result in an inappropriate internal representation of the data.
Prior to compiling the AIR package, you must configure the config.h file to specify whether the internal data representation will be 8 bits/pixel or 16 bits/pixel. The internal representation cannot be changed without recompiling the package. If 8 bits/pixel are specified, internal values of 0-255 are used. For 16 bits/pixel, internal values of 0-65535 are used. In order for automated registration to be successful, it is critical that all "black" pixels (i.e., "zero"-valued and undefined pixels) be mapped to an internal value of zero. Depending upon the external data types, voxel values may be systematically remapped when importing data into and when exporting data out of the AIR package.
If you compile the AIR package in 8 bit mode, your output images will always have 8 bits/pixel. If you compile the AIR package in 16 bit mode, your output images will always have 16 bits/pixel. When you compile in 16 bit mode, you must also specify in the config.h file how you want 16 bit output data to be represented. Internal data will be mapped onto external values based upon this specification. You must choose only one of the three possible representations (these are the same three choices available for imported 16 bit data) when you compile the AIR package, and you must recompile the package if you want to change the output data representation. The AIR package cannot "remember" the file format that was used to load an image in order to specify an output using the same format. It can only generate the one file format that was specified in the config.h file when the package was compiled.
The AIR package defines four different external data types for images. When
external data is loaded, the data type is determined by inspecting
three values stored in the header
files. The header "bits/pixel" field is used to distinguish 8 bit
data from 16 bit data, and the header "global maximum" and "global
minimum" fields are used to distinguish the three different types of
16 bit data. If the AIR package was compiled using an 8 bit internal
representation, the header "global maximum" is also used to optimize
the conversion of 16 bit to 8 bit values. When the AIR package
creates a file, it uses the format specified when the package was
compiled and creates header files that correctly identify the storage
format. You can use the program
scanheader to see what values are
stored for "bits/pixel", "global maximum" and "global minimum" and
thereby deduce what type of data is being specified by the header.
When you create a new header using
makeaheader, you must explicitly
identify the data type.
The following descriptions of the four external data types may be
easier to understand if you review the illustrations that show how
the various data types map onto eight
and sixteen bit internal representations.
Modified: February 12, 2002