Image file formats

Due to circumstances wholly beyond our control, the Brain Mapping MRI lab must support a variety of image file formats and data types. To convert between them, see the Image Conversion HowTo note. This note describes the file formats and their uses.

Signa genesis (xxx.MR)

Overview
This is the native format saved by the Signa MR scanner. The data are stored as short integers (no fractional parts), with a single file for each image (a single location or time point). The first 7904 bytes of the file contain header information.
File names
Files are named ExxxxxSyyyIxxx.MR where xxxxx is the Signa Study number, yyy is the series number and zzz is the image number.
Other Notes
This is the most complete file format we presently use. It contains all scan information such as tr, te, sequences, all setup information, such as the slice thickness and location, and a wide variety of technical parameters such as receiver gain. The patient information is not saved automatically unless the images are copied from the scanner using ximg with the -s option.
 
Because all of the scan information is potentially useful, when converting from genesis format, it is often preferable to use the special program Genesis2Analyze, which preserves this header data in a separate file.

ANMR APD2 (xxx_001.img / xxx.irp)

Overview
This is the native format saved by the Advanced NMR Systens echo planar upgrade. The data are stored as short integers (no fractional parts), with all image locations and time points in a single file. The data must be accompanied by a separate header (named as below) to be readable.
File names
Files are named scanID_xxxxx_yyy_zzz_nnn.img, where scanID is the ID entered at the Signa console, xxxxx is the Signa Study number, yyy is the series number and zzz is the Signa image number; nnn is the scan number and is incremented each time that the scan button is pressed without first leaving the Scan Ops page on the Signa. To be useful, these data sets must be accompanied by the matching header, called, scanID_xxxxx_yyy_zzz.irp
Other Notes
The ANMR files contain almost no information on the specifics of the scan. The very small text header (.irp) contains information needed to display the images.
 
In the APD2 format, the files are arranged such that all time points for a slice location are saved together, with all time points of the next location following, and so on. Because of this, reading the files is very clumsy and is quite slow.
 
Further, the APD2 files usually contain a great deal of unused data from outside of the scan field of view. As a result, they are twice as large as is truly needed. When processed with imconvert, CC_gr, etc... the outer edges of the images are removed, resulting in a large savings in space.

Analyze (xxx.img / xxx.hdr)

Overview
The Analyze format was developed some years ago to support the program of the same name written by the folks at the Mayo clinic. The data can be saved as signed short integers (most typical) or floating point numbers. Analyze includes both 3D and 4D file formats (see below)
File names
Files are named freely, with the exception that they must end in .img and must be accompanied by a matching header file, whose name ends in .hdr
Other Notes
The Analyze 3D format is used most commonly. A separate file is created for all locations at any time point. In the PET days, this was rational, as the data usually consisted of only a small number of time points. With fMRI, however, it is clumsy, as hundreds of separate files must be created and maintained for each study (two for each time point, if you count the headers).
 
The Analyze 3D format is the standard for common PET-era analysis tools such as SPM and AIR
 
Analyze also supports a 4D format, in which all time points and all locations are saved together in a single file. While this does not result in any significant space savings over the 3D format, it is much more convenient, as only the data file and header must be saved.
 
The small (348 byte) Analyze header is more complete than the ANMR header, or the MGH header, but is still highly degenerate. There is no mechanism to save scan information or slice locations, and only cardinal axis (axial, coronal, sagittal) scan planes can be indicated. There is support for only rudimentary patient information.

bfloat (xxx.bfloat / xxx.hdr)

Overview
bfloat files contain blocks of floating point numbers representing the image data, and have a small, very short, header that specifies the number of pixels in each of (only)three dimensions, usually interpreted as Y, X and time. Mutiple slice locations are generally represented by increasing the y dimension to make a vertical stack format.
 
These files are created by the statistical analysis tools, such as CC_gr (and scanSTAT), as they can accurately convey non-integer values. An alternative would be Analyze floating point files.
File names
Files are named freely, but must end in .bfloat and must have a matching header file that ends in .hdr
Other Notes
Occasionally (often, in fact) we save files in the bfloat format with multiple slice locations arrayed in a tiled format. E.g., sixteen slices are saved in a four by four array. Although this appears nice on the screen, it is a messy format, as the header contains no specification for the number of slice locations, and each multi-slice collection must be treated as a single image.
 
As far as I am concerned, the sole reason to support this data type is that it can be vewed readily using the excellent 'xds' display program.

bshort (xxx.bshort / xxx.hdr)

Overview
bshort files contain blocks of signed short integers representing the image data, and have a small, very short, header that specifies the number of pixels in each of (only)three dimensions, usually interpreted as Y, X and time. Mutiple slice locations are generally represented by increasing the y dimension to make a vertical stack format.
 
The bshort file format is lossless in intensity information as compared to the scanner native formats, and is somewhat easier to manage, with the caveats listed below.
File names
Files are named freely, but must end in .bshort and must have a matching header file that ends in .hdr
Other Notes
Occasionally (often, in fact) we save files in the bshort format with multiple slice locations arrayed in a tiled format. E.g., sixteen slices are saved in a four by four array. Although this appears nice on the screen, it is a messy format, as the header contains no specification for the number of slice locations, and each multi-slice collection must be treated as a single image.
 
As far as I am concerned, the sole reason to support this data type is that it can be vewed readily using the excellent 'xds' display program.

buchar (xxx.buchar / xxx.hdr)

Overview
buchar files contain blocks of single byte numbers representing the image data, and have a small, very short, header that specifies the number of pixels in each of (only)three dimensions, usually interpreted as Y, X and time. Mutiple slice locations are generally represented by increasing the y dimension to make a vertical stack format.
File names
Files are named freely, but must end in .bfloat and must have a matching header file that ends in .hdr
Other Notes
The buchar format can save only 256 intensity levels, and is therefore useless for quantitative analyses. When using imconvert, be careful to set up the options to get the best possible intensity resolutions.
 
Occasionally (often, in fact) we save files in the buchar format with multiple slice locations arrayed in a tiled format. E.g., sixteen slices are saved in a four by four array. Although this appears nice on the screen, it is a messy format, as the header contains no specification for the number of slice locations, and each multi-slice collection must be treated as a single image.
 
The buchar files are created mostly because they are convenient for color displays when used with xds. In actuality, the color table and the files are entirely separate, and there is no guarantee that the selected color table is correct for any buchar image. CC_gr and overlay use consistent color tables that interpret the highest 32 values as colors, with the remaining 224 intensities set aside for gray scale.

Back to HowTo pages
This page is maintained by Mark Cohen [updated 08.21.00]