Eight and Sixteen Bit Images

General comments

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:
  1. Use a 16 bit version of the entire AIR package for all procedures.
  2. Use an 8 bit version of AIR to derive .air files (which are independent of whether the package is compiled in 8 or 16 bit mode) and then use a 16 bit version of AIR to apply these .air files to your data. (This is the approach that I generally recommended).

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.

Internal and external data representation

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:

External data to be loaded (importing data)

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.

Internal representation of 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.

External data created by the AIR package (exporting data)

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.

External data types

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.

Type 0 data

Type 1 data

Type 2 data

Type 3 data

Modified: December 30, 1995

© 1995 Roger P. Woods, M.D.(rwoods@ucla.edu)