If you plan to use the AIR package with 16 bit data, or if
you have compiled the AIR package in 16 bit format, you are strongly
encouraged to read this page carefully. The AIR package
remaps voxel values in the process of importing and exporting data
when 16 bit formatting is involved. Successful 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 8 bit and
16 bit versions of the AIR package.
The AIR package was originally designed for use with 8 bit data.
Indeed, 8 bit representation is generally sufficient for automated
registration of images. The primary justification for utilizing 16
bit data is the need for higher precision for additional data
analysis that will occur after image registration is completed.
Consequently, there are two major options for dealing with 16 bit
data:
Both of these approaches will generate registered 16 bit images. With
the second approach, RAM requirements of the automated registration
programs are cut in half and computation time is decreased.
The primary disadvantage is that care must be taken to assure that
the 16 bit values will be converted into 8 bit values in a way that
maximizes the dynamic range of the converted images. The AIR package
provides 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. 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.
When a 16 bit version of AIR package is
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.
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. 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 AIR.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
AIR.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 AIR.h file when the package was compiled.
The AIR package defines four different external data types. When
external data is loaded, the data type is determined based on the
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: December 11, 1996