Image Formats

Multi-modality imaging usually requires handling of image formats with substantially differen properties and capabilities: the amount of header information ranges from non-existent with Flat Image Format to overwhelming in the case of DICOM Image Format. To make matters worse, several image types come in different “flavours”, e.g. both Analyze images and ECAT7 data format can have Little Endian or Big Endian representation, and might contain integer or float values for one or more image frames. However, the real challenge is elsewhere, and we have seen it with almost all types of image data: missing or inconsistent header information and (gross) violations of data standards. We try to present images in a standard orientation and keep the original header information natively, an important design goal of VINCI.

The ECAT7 data format is native to several generations of PET scanners manufactured by Siemens/CTI Inc. It is a “traditional” binary format that uses struct-type data blocks for header information [1]. The header and image data are contained in one file, the header data is split into one “main” header of size 512 Bytes [2] located at the beginning of the file and a 512 Byte header prefixed to each image frame. In addition there is one “directory” block. “Multi-frame” ECAT7 files contain more than one image volume: all images usually have the same dimensions and belong to one study, activation studies are saved in multi-frame files, each image frame has an entry in the directory block. It should be noted that this file format is not particularly suited as a general-purpose file format for data post-processing: it uses a fixed-size header which, by definition, cannot be expanded for extended keywords or general post-processing information; different conventions exist for numbering of frames in different contexts; no information about coordinate systems is provided; space for free-text comments and patient data is very limited.

The Analyze data format [3] offers even less in terms of header information but is important as this is a popular format for several packages for processing of PET and MRI data, e.g. SPM [4] and FSL [5]. It also has a fixed-size, binary header. VINCI supports this data format for reading and writing, also for multi-frame files. CAVEAT: patient orientation is not a well-defined property for Analyze images and is a well-known problem. If you have a choice, use the NIfTI Data Format instead which is Analyze compatible and was designed to address this issue.

The NIfTI-1 Data Format [6] was defined to address some of the shortcomings of the Analyze Data Format, specifically an improved method to store patient orientation. VINCI can import several flavours of NIfTI files.

The American College of Radiology (ACR) and the National Electrical Manufacturers Association (NEMA) formed a joint committee in 1983 to develop a standard to “Promote communication of digital image information, regardless of device manufacturer” in response to the “emerging need for a standard method for trans- ferring images and associated information” in medical imaging. The result, ACR- NEMA, was the precursor of the Digital Imaging and Communications in Medicine (DICOM) standard. Major enhancements of DICOM compared to the previous standard include support for a networked environment, support for off- line media environments (such as CD-ROM storage), detailed specifications for levels of conformance. [7]

This is easily the most complex data type available for medical imaging, and complexity is its main problem: even major vendors of medical imaging systems have histories of MRI and CT scanners which export DICOM data that violates the standard. “Shadow Groups” also pose a problem if manufacturers use this DICOM option to store important image parameters in an undocumented fashion. [8]

Our DICOM implementation uses DCMTK [9], an OpenSource toolkit, to internally convert DICOM header information into XML representation, these XML trees are then processed by VINCI. DICOM output also utilizes DCMTK functionality. Challenges of importing DICOM data sets as image volumes involve sorting the slices into their respective data sets—and in the right order.

DICOM import has been optimized in several ways: scanning a directory tree with hundreds of DICOM slices to assemble a list of available DICOM data sets is slow. VINCI avoids scanning a directory more than once by writing a small summary file (in XML format) that describes which image file belongs to which data set and at what position. We have also implemented a fast read mode: only one file of a data set is parsed completely (and we have modified DCMTK to avoid creating temporary files), all other slices of a data set are block-read, skipping most of the header information.

The Interfile v3.3 format was conceived as “an appropriate mechanism for the transfer of nuclear medicine image data files between computer systems from different vendors” [10]. The main idea is to have a (binary) image file and an accompanying text file with header information. The latter is “human readable”, easy to generate and to edit: it is based on key-value pairs such as

patient name := JOAN

one key-value pair per line of text. A long list of keys (e.g. “!study ID”, “study date”) has been defined.

However, most programs support only a small subset of keys. There is no mandatory method of validation for Interfile-type headers (a problem, as headers tend to get edited in experimental setups), there is no support for encapsulation of hea- der sections, i.e. Interfile-type headers are not suitable for accumulating header information of different steps in a workflow (potential conflict of key-value pairs), there is no Unicode support.

The HRRT uses Interfile format with some additional keys that have been added by the manufacturer for scanner and reconstruction specific information. We have added another key that incorporates a MD5 message-digest (“electronic fingerprint”) of the associated image volume into the header file during the final reconstruction step (quantification) so it is now possible to check whether a particular image file is consistent with its header.

The term Flat Image usually refers to a binary file which contains “raw” voxel data for one image, without any embedded or external header information. Thus all meta-information must be supplied manually in the plugin, at the minimum, this would be the image file’s dimensions, data format (float, int, endianness, etc) and pixel sizes. See Load Flat Image Plugin for more information.