Visualization of DICOM Images– Handling the Standard's Complexity
Marco Eichelberg, Jörg Riesmeier, Sandra von Gehlen*, Peter Jensch*
Kuratorium OFFIS e.V., and * Carl von Ossietzky Universität Oldenburg,
Oldenburg, Germany
INTRODUCTION
Since it's introduction in 1993, the DICOM Standard [1] has become the omnipresent tool for image management in healthcare. Although DICOM defines many non-image-related services like information system interfaces and services for report management, the core of the standard defines how medical images can be exchanged, displayed and managed.
A closer examination of the DICOM image model reveals a striking complexity of the underlying representation of image pixel data. This complexity raises the question whether a modality independent "general purpose" DICOM image visualization is feasible at all and how DICOM image data can be managed efficiently.
THE DICOM IMAGE MODEL
A DICOM image consists of a set of "attributes" which describe different aspects of the image, e.g. demographic data of the patient, modality settings like radiation dose or physical resolution of the device and image specific data like number of columns and rows, color model or contrast resolution. The pixels of the image are transmitted as a single "blob" of data containing all samples (in case of a color image) and frames (in case of cine images, e.g. ultrasound or x-ray angiography). DICOM defines a generic image model which offers many "degrees of freedom":
· Pixel data need not be byte-aligned (e.g. images may be stored with 13-bit alignment).
· Image data can be sign-extended or unsigned.
· Unused bits of the image data can be used to store additional graphic overlays.
· Color images can be stored in different color models: RGB, CMYK, Palette Color, YCbCr, etc.
· Grayscale images can specify both linear and non-linear transformations (Modality, VOI LUT).
For each modality, DICOM specializes this generic model and introduces reasonable restrictions (e.g. CT images must always be grayscale and have a contrast resolution of 12-16 bits/pixel). A noteworthy exception is the DICOM "Secondary Capture" definition. This format is used for digitized images and, therefore, quite commonly used. DICOM defines no restrictions to the generic image model for Secondary Capture. This means that DICOM visualization software must be prepared to handle all the complexity of the standard's image model, because Secondary Capture images are too common not to be supported.
Practical experience, however, shows that most DICOM viewers, although claiming to be able to display generic Secondary Capture images, immediately reject all but the most common formats, or, even worse, silently ignore such images or display them incorrectly.
AN OBJECT-ORIENTED APPROACH TO DICOM IMAGE VISUALIZATION
Considering the limitations of existing DICOM viewers, we decided to design a toolkit [2] which attempts to overcome the common restrictions. The main design objectives were:
· Completeness: Support for (almost) all image formats and options defined in DICOM.
· Efficiency: The most usual formats should be processed quite efficiently.
· Extensibility: The functionality should be easily adaptable to future DICOM enhancements (e.g. new color models).
· Portability: Platform specific functions or C++ language features that are not commonly supported (e.g. RTTI) should be avoided.
As a concession to efficiency, no object manipulation is performed at a per-pixel level. An extensive use of C++ template classes and inline methods allows to combine a clear design with good code optimization.
The toolkit reads a DICOM image and preprocesses the pixel data (e.g. introduces byte-alignment) to facilitate the access to it’s internal bit structure. In a second step this "normalized" image is converted according to it's color model into one of two different intermediate representations (grayscale or RGB color). These representations convey the same spatial and contrast resolution as the original DICOM image, but can be processed more efficiently. In a final processing step the image is converted to an output format, possibly applying VOI windows and restricting the contrast resolution (e.g. for 8-bit displays).
Two applications based on this toolkit, a conversion and manipulation tool for the console and a small DICOM viewer with graphical user interface, have been developed for testing the toolkit's compliance with the design objectives. In parallel, a large set of artificial DICOM test images covering all aspects and options of the DICOM image model have been created as test cases allowing to "stress-test" DICOM viewing software.
CONCLUSION
We have demonstrated that it is possible to visualize DICOM images in a way that is general enough to cope with the complexities of the DICOM image model and still retain efficiency when handling the more conventional images which make up the vast majority of the "real-world" DICOM images.
Nevertheless the question remains whether DICOM's present complexity with regard to the image models is really necessary. While the many "degrees of freedom" make the conversion of modality specific formats to DICOM easy, they also significantly impede the practicability of DICOM image visualization. Especially the introduction of "reasonable" restrictions for Secondary Capture objects, which are frequently used in practice, would make DICOM visualization much easier and, in turn, more reliable.
REFERENCES
1. NEMA Standards Publication PS 3.x, Digital Imaging and Communications in Medicine (DICOM), National Electrical Manufacturers Association, 2101 L Street, N.W., Washington, D.C. 20037, 1993
2. J. Riesmeier, Objektorientierte Repräsentation von Bilddaten im DICOM-Standard, Diplomarbeit, Fachbereich Informatik, Carl-von-Ossietzky-Universität Oldenburg, 1997
Correspondence:
Marco Eichelberg
Kuratorium OFFIS e.V.,
Escherweg 2,
D-26121 Oldenburg, Germany*
Oral presentation at EuroPACS'98, Barcelona, Spain