The information on this page is relevant to anyone who plans to use the AIR package.
The AIR package includes two programs for automated
registration of images. The first of these,
alignlinear, includes 2D and 3D
variants of all linear spatial transformation models, including
rigid-body models, global rescaling models, affine models and perspective models.
It support within-modality, across-modality and linear intersubject
registration.It generates a file, referred
to here as a ".air file", that
contains linear transformation parameters for resampling one of the
images to match the other. The second alignment program,
align_warp, includes 2D and 3D variants
of nonlinear polynomial spatial transformation models ranging from first (linear)
to twelfth order.
It generates a file, referred to here
as a ".warp file", that contains
nonlinear transformation parameters for resampling one of the images
to match the other. The information in first order .warp files can also
be represented by a .air file, and such files can be substituted for .air
files in any AIR program that uses .air files. Similarly, any .air file that does not describe
a perspective deformation can be represented by a .warp file, and such files
can be substituted for .warp files in any AIR program that uses .warp files.
Aside from these transparent substitutions, programs within the AIR package are
generally designed to work with .air files or .warp files, but not both. Most
programs that deal with .warp files include _warp at the ends of their names.
AIR provides limited support
for a third type of file for describing registration parameters, referred to here
as .vector files. These files describe deformation
fields and are provided as a mechanism for integrating any deformation into AIR. The
distribution version of AIR does not provide any programs for creating .vector files
The program reslice will use the
registration parameters in a .air file to resample the reslice file
(which is explicitly identified in the .air file) to match the
standard file. Nearest neighbor, trilinear, or various forms of sinc and chirp-z
interpolation can be used. The program
reslice_warp provides similar
functionality for .warp files, as does the program reslice_vector
for .vector files. In addition to reslicing images,
it is possible to use .air or .warp files to remap lists of points that refer to coordinate locations
in the images. The programs reslice_ucf and
reslice_warp_ucf will perform this remapping.
The alignment programs depend upon the image headers for certain information about file dimensions and sizes. If you do not already have headers for your images, you can create them using the program makeaheader. The program scanheader will display the relevant information contained within an image header so that you can verify that the information is correct. The program fixheader will allow you to modify the real world sizes that correspond to the voxel sizes of an image if the header information about these sizes is inaccurate.
For use with AIR, individual slices from an image must be concatenated into a single image volume. The programs reunite and separate facilitate conversion between data formats that store each slice in a separate file and the multiimage format required by AIR.
The programs scanair and scan_warp allow you to display the information contained in .air and .warp files. On a more limted basis, the program scan_vector provides similar functionality for .vector files. Several programs are available to make specific modifications to .air and .warp files. The programs mv_air and mv_warp allow you to change the name of the reslice file designated in a preexisting .air or .warp file. This feature allows you to use the same parameters to resample multiple files that you know (or assume) to be spatially equivalent to one another. The programs cd_air and cd_warp allow you to update .air and .warp files to reflect the fact that the reslice file has been moved to some other directory in the file hierarchy. The same effect could be achieved using mv_air and mv_warp, but cd_air and cd_warp do not require you to keep track of the specific name of the reslice file (which is unmodified) and are therefore well suited to safely changing only the directory name. The program invert_air will exchange the reslice and standard files (adjusting the transformation matrix accordingly) so that you can use parameters originally derived for aligning file A to B to align file B to A instead. There is no counterpart program for .warp files due to the fact that nonlinear transformations cannot generally be analytically inverted. Instead of analytic inversion, numerical inversion can be performed on-the-fly by the programs reslice_unwarp and reslice_unwarp_ucf. The program combine_air allows you to combine multiple .air files into a single .air file that will have the same effect as applying the individual files sequentially to a single data set, but without the accumulation of interpolation errors and loss of data outside the field of view that occurs with sequential resampling.The program combine_warp allows a single .warp file to be combined with .air files and is an exception to the general rule that programs do not deal with both .air and .warp files.
Because the .air, .warp and .vector files are stored separately from the image files, an additional level of file identification has been incorporated into these files. In addition to the names of the files, a ten digit identifier is computed based on the data in the file. This identifier is displayed along with the other information shown by scanair, scan_warp and scan_vector. In the event that you are unsure that a file is the file used to derive a set of registration parameters, you can use the program identify to compute the ten digit number that corresponds to a given data file.
Several programs are provided to manipulate the size or orientation of files without changing any voxel values. The program reorient allows you to rotate your data 90 degrees or 180 degrees around the x-, y-, or z- axis and also makes it possible to flip the data (effectively converting it to its mirror image) along any of these axes. The program resize will shift, clip or pad your data to achieve any desired matrix size. The program crop will allow planes that contain no data to be trimmed from the edges of an image file. The program layout will composite multiple slices from an image into a single 2D file to create illustrations, etc.
Other programs reformat data in specified ways that do alter voxel values. The program zoomer will interpolate a study with anisotropic voxel sizes to generate a volume composed of cubic voxels. The program magnify uses Fourier interpolation to increase the number of voxels along a given image dimension. The program gsmooth will apply a Gaussian smoothing filter to a file.
Several of the programs that reformat data can also optionally save .air files describing the transformation that they perform. These include crop, reorient, resize and zoomer
The program manualreslice is the only interactive program in the AIR package. This program requires you to specify values for roll, pitch, yaw, x_shift, y_shift, and z_shift, x-axis_scaling, y-axis_scaling and z-axis_scaling. These values can then be stored in an initialization file for use with the linear automated alignment programs. Alternatively, these values can be used to manually generate a .air file or to manually reslice a file according to these parameters without generating a .air file. When used together with the capabilities of combine_air, and reslice, or with combine_warp and reslice_warp, manually created .air files make it possible for you to resample your data consistently with a pixel size and interplane distance of your choosing.
The program definecommon_air will average together a series of .air files to define an "average" common space for data analysis. The program reconcile_air will compare various .air files with redundant, potentially conflicting information and will create new .air files that are more internally consistent with one another.
The program softmean will take missing data into account in generating a mean image from resliced data that can be used for additional subsequent automated image registration.
Several programs are provided to manage binary files. These are useful for saving editing information, regions of interest, etc.To create a binary file from a non-binary file, use the program binarize. Binary files can be combined, intersected, subtracted, etc., from one another using the program binarymath. The program binarymask will apply a binary file to a non-binary file to create a masked non-binary file. The program overlay_mask provides a shortcut for one use of these binary programs, namely, the ability to overlay thresholded regions of one image as 'blobs' on another image. The program determinant_mask will create a binary file from a .warp file, showing locations in which the .warp file has a positive determinant.
The program setheadermax will change the global maximum value in the header of 16 bit images so that they can be converted to 8 bit images with as many significant figures of precision as possible. This program is irrelevant when AIR is compiled as a 16-bit program.
The program sizeof shows the size of various variable types generated by your C compiler and compares them to the corresponding sizes in the AIR development environment.
With the AIR package, you should be able to reorient tomographic images of the same subject to match one another. If both images were acquired using the same modality, it is likely that you will want to perform a quantitative comparison of the two images to see if there has been any change between the two images. In making such comparisons, you should be aware of the fact that there are a number of issues that may arise when comparing a pair of reoriented images that do not arise when comparing a pair of images that were acquired in identical positions:
Problems 1-3 are particularly amenable to quantitative analysis using phantoms, and it is strongly recommended that you perform such studies and fix the problems if you suspect that they are leading to errors in quantitation. Problems 4-7 are more difficult to deal with, and in some cases may be unavoidable. A particularly difficult situation can arise if some state or task of interest is significantly associated with a systematic variation in head position. In this case, it may not always be possible to separate the errors in quantitation due to problems 4-7 from true changes. For band-limited data, the use of sinc interpolation may help to minimize resampling interpolation artifacts, but most tomographic data is not fully band-limited in three dimensions at present. Problem 8 can generally be avoided by randomizing or pseudorandomizing which image is to be resliced.
You should note that quantitative errors above are equally applicable to any method of analyzing misregistered data (e.g., the use of regions of interest) but that they are particularly evident when the images are analyzed on a pixel-by-pixel basis (which essentially amounts to extremely tiny ROI's).
With the exception of sinc and chirp-z interpolation for band-limited data, the AIR package does not incorporate any features intrinsically designed to deal with the quantitation problems described above. In some situations, on-line registration, which is not discussed or supported in this release but is discussed in the first paper describing the PET-PET registration method, minimizes many of these quantitative errors.
Note that the AIR package completely separates the derivation of the registration parameters from the final resampling of the data. Consequently, you are able to apply the spatial information contained in the .air files at any point in the data analysis that you like. On-line registration is one extreme, with the information being used to make modification even before data is acquired. However, it should also be possible to apply this information post acquisition, but prereconstruction, etc.
The AIR package now supports nearest neighbor, trilinear, and various forms of sinc and chirp-z interpolation.
When a misregistered file is resliced to create a registered file, a portion of the resulting file will generally be missing because it was outside the field of view in the original image. Particularly if the field of view is limited, the missing data may include voxels that are within the brain on the reference image. The reslicing programs in the AIR package will assign a voxel value of zero to the regions of missing data which will have linear edges for when using linear models but may have curved edges when using nonlinear spatial transformation models. Users unfamiliar with this possibility may be puzzled by the absence of data, especially since even a slight movement may suffice to lose an entire plane of data in the resliced images (AIR will not extrapolate outside the boundaries of the original image, no matter how trivial the excursion outside these boundaries).
If you have software originally developed for analyzing images that did not require realignment, you should review the consequences of assigning values of zero to missing data.
When performing registration, the AIR package cannot distinguish between voxels within the images that are zero because of missing data and voxels that are truly zero. Consequently, except in special situations, images to be registered with the AIR package should not have missing data within the brain (structures outside the brain such as scalp, skull, and dura may be missing due to recommended editing for MRI-PET registration or for intersubject registration). Consequently, it is generally best to avoid registering images that have already been resliced. Where possible, registration to the original images (which are assured not to include missing data) is preferred. In instances where one of the registration targets needs to be an average of several images that have been coregistered, use of the program softmean to create the average image can help to assure that no voxels have missing data.
One situation where it may be important to edit the data to remove data within the brain is when brain pathology has led to extreme focal changes between acquisitions that are disrupting the registration process. In this situation, it is possible to force the alignlinear algorithm to perform a unidirectional fit by using the -p1 0 or -p2 0 flags. These flags allow one of the images to be edited to exclude areas that should not be included when deriving the registration parameters.
There is no preferred or required image orientation for the AIR package, so long as you are consistent (or at least able to keep track of your inconsistencies and consistently take them into account when using the programs). The package should not be expected to rotate an image by more than 45 degrees from its initialization parameters, and an increasing failure rate should be anticipated as the necessary alignment approaches this value. The package is incapable of recognizing that two images are mirror image versions of one another, a problem that is particularly likely to go unrecognized when the two images being registered start out in different formats. Don't forget that two data sets can be three dimensional mirror images of one another by virtue of having their planes ordered in opposite directions (top to bottom versus bottom to top). A utility program called reorient is provided to allow you to perform repositioning and mirror imaging as needed to get the images oriented for automated registration. Additional fine tuning of the initial registration can be provided when necessary by using an initialization file with the program alignlinear or align_warp.
AIR does not require voxel sizes to be isotropic along any dimension. You should be able to reorient a coronally or sagitally acquired MRI scan and align it to a PET study without having to worry about the fact that the resulting pixel sizes are anisotropic.
The AIR package is designed to be extremely flexible with regard to the dimensions of your image. For practical purposes, you are limited only by the amount of contiguous RAM that is available for loading an image into memory. It is recommended that you not interpolate your original data to generate cubic (or approximately cubic) voxels prior to using the AIR package. The package has internal interpolation capabilities that are quite fast, avoiding the need to use extra disk space to save what is actually redundant information. You will also avoid the quantitation errors introduced by repeatedly reinterpolating the same data. The one exception to this recommendation is that if you are averaging together multiple realigned images with the intent of using the averaged value for subsequent registration, there may be some advantage to reslicing the realigned images to cubic voxels and averaging them as cubic voxels.
The AIR package can be compiled to use either 8 or 16 bits/pixel for internal representation of voxels. Regardless of its internal representation, the AIR package will load images of either 8 bits/pixel or 16 bits/pixel. Images are converted to AIR's internal format when they are loaded. The AIR package will only generate output images with the number of bits/pixel that it uses for internal representation. For example, if the AIR package is compiled for 8 bits/pixel, it can register two images that have 16 bits/pixel and generate an appropriate .air file. If this .air file is used by the program reslice compiled for 8 bits/pixel, the original 16 bit file will be loaded and resliced, but the output image will be saved as 8 bits/pixel. Note however, that the same .air file that was generated by an 8 bits/pixel registration program can be utilized by a 16-bit version of reslice to generate a 16 bits/pixel resliced image. You should be aware of the fact that this process will remap the absolute pixel values (in a systematic way). If you are doing absolute quantitation, you will need to take this remapping of pixel values into account. Issues related to 16 bit images are discussed in detail in the technical notes.
The interconversion between different data formats is handled exclusively by the data loading subroutines, and the other components of the package generally do not have any way of determining what the format of the original data actually was. For 16 bit data, an additional complication is imposed by the fact that there are three different ways that 16 bit data may be represented externally. The AIR package uses the header global maximum and global minimum values to determine which of the three data types is being used. This issue is discussed in detail in the technical notes.
This is an extremely complicated issue, and most of what is said here consists of empirical guidelines that should be adjusted by your own practical experience.
Extremely noisy high resolution PET images generally take longer to register than smoother, lower resolution images. Furthermore, slight (subpixel size) misregistration of data that is actually already perfectly aligned can result in a small amount of additional smoothing due to the trilinear interpolation process used in the AIR package. This additional smoothing may make the slightly misregistered images "look" better aligned to the AIR package than the registered images. This effect is minimized when the images are already fairly smooth (see 1992 reference for further discussion of this problem). Finally, there are some theoretical reasons to suspect that registration may be particularly robust when the image smoothness is isotropic in all three dimensions.
With these generalizations in mind, we currently reconstruct our PET H215O images with the highest possible resolution (~6mm in-plane, 10 mm axially) and smooth them to isotropic resolution (10mm in all directions) either using gsmooth or using the internal smoothing capabilities of the program alignlinear before registering them to each other.
Our validation work suggests that slight smoothing of MRI data with a 2 mm Gaussian filter improves the internal consistency of the resulting transformations. It is uncertain whether this also results in an improvement in true accuracy. If you are going to ultimately smooth the data more anyway, there is little reason to avoid smoothing in the registration process. If you plan to keep and analyze the data at high resolution, arguments can be made both for and against smoothing during registration (note that smoothing to derive registration parameters is independent of smoothing during the ultimate resampling of the data using those parameters).
For intermodality (e.g. MRI to PET) registration, there are theoretical arguments that the PET scans should have the highest possible resolution (assuming that the MRI resolution will be even higher still). Consequently, we realign our 6mm resolution PET images (using the registration parameters derived by smoothing them) to match one another and then average them all together using the program softmean to generate a high resolution, moderately noisy mean image which is then registered to the edited MRI scan. Using somewhat smoother images (e.g., FWHM 7-8 mm) still provides excellent results for MRI to PET registration (see 1993 reference). We do not smooth the MRI images.
Smoothed and unsmoothed data give quite similar results for intersubject registration.
In general, the programs in the AIR package will not overwrite existing files unless you have explicitly granted permission to do so. However, there is an exception to this rule. The programs alignlinear and align_warp will always overwrite a preexisting file with the same name as the output file--practical experience has shown that the annoyance of having the program refuse to save the results of many minutes or even tens of minutes of iterative computation because a file with that name already existed outweighs the risk of losing data. A few safeguards have been built in: the programs will announce the fact that they intend to overwrite an existing file before starting the iterations, hopefully giving you sufficient time to type control-C to terminate the program if you want. Also the programs will reject any file name containing ".img" or ".hdr" as an output file name. To avoid any possibility of data loss, it is recommended that you always make a copy of data that could not be easily replaced if overwritten and that you store the data in a safe location in your directory where it cannot be accidentally overwritten by these programs.
Modified: December 22, 2001