|
ODIN
|
This page describes the functionality of the FileIO module.
When working with different systems for generating and processing of medical images very quickly one problem arises: These systems use different data formats and the available export features of any toolkit mostly support only a subset of the needed formats. The following report describes an approach to design a unified and extensible interface to medical image data. Implemented in an function library this interface can be used to efficently enable custom-built applications to read and write medical image data.
Unified access to different data formats implies a common interface for accessing this data. Thus a data structure, which provides a superset of all features of all data formats which shall be supported. Every medical image consists of image data of any type and metadata related to this image data. This data pair will be dicussed in the following.
The metadata which belong to an image usually describe the technical and administrative characteristics of an image. They consist of some required information like image dimension and used data type, some common information like the age of the subject or the date the image was taken and some optional information like used field strength for MR data. These parameters are either in a header inside the imagefile or in a separate header file. The required and the common parameter are very usefull to distinguish images. They, and with them the whole metadataset, can be used as a unique key to reference this image. In the following this paremeter set will be called the Protocol.
Some imagefile formats are only capable of storing at least two-dimensional images. In this case N-dimensional datasets are often stored by using several two-dimensional images. The protocols of these images differ only in the remaining coordinates (which needs to be specified in this case). The system must recognize this and combine them into one N-dimensional dataset when reading. And the inverse approach appiles to writing N-dimensional data in a fileformat which does not support that many dimensions.
The pair of protocol and dataset can be used as a universal interface to access image data. While the protocol offers all information to interpret the data, the dataset serves as a coordinate-based interface to the data for reading and writing.
Multiple protocol-dataset-pairs can efficiently be stored in a associative container where the protocol is the key which maps to the dataset. This enables the system to handle multiple datasets. A particular dataset can always be referenced by its protocol and a list of the available datasets can be obtained by iterating through this protocol-dataset-map (FileIO::ProtocolDataMap). Also, when reading multiple low-dimensional image files which are part of an high-dimensional image, they all will have the same protocol and thus will be automaticly sorted into one high-dimensional dataset referenced by this protocol.
To guarantee the flexibility of the system, the input from and the output to files is done via plugins (classes derived from FileFormat) which use the described protocol-dataset-map as front end. These plugins are gathered at the initialisation and held in a map with the file suffixes they support as key. If available, they are also referenced by a regular expression to detect the supported format directly from that data.
The selection of the right plugin is done in two ways. If a fileformat is directly requested, the corresponding plugin is used. If the format is not selected explicitly, the system at first tries to get the suffix of the file requested for read or write and guesses the format.
Many medical image formats exist in several different dialects or have optional extensions which makes it necessary to fine tune them. Thus every plugin can bring a set of additional parameters which than can be used by the client to modify their behavior.
1.9.1