Navigation:  Image Viewer Architecture > Presentation States >

DICOM Presentation State

Previous pageReturn to chapter overviewNext page

In addition to the basic concepts of presentation state, the DICOM Standard defines additional presentation state concepts such as masks, display shutters, bitmap overlays, vector graphic overlays and VOI information 1.

Typically, the scanners that produced the original image would encode any presentation information available at the time directly into the image SOP instance, which then becomes the definitive base instance and is generally not intended to be modified by any consuming applications.  In order to add and distribute additional presentation information to an image without modifying the original SOP instances, the DICOM Standard defines a number of SOP classes called softcopy presentation states which store only a reference to the original SOP instance and the presentation state information without the original image pixel data.  The two instances are then distributed together in order to view the image with the modified presentation state on different devices.

In the Framework, the DICOM presentation state refers to the combination of both the presentation information stored in the image SOP instance as well as the information stored in any accompanying softcopy presentation state.

The majority of DICOM presentation state concepts are implemented as graphics which are loaded into the domain-level composite graphics of DICOM image scene graphs.  Conceptually, the scene graph of a DICOM image differs from that of the Framework.  The layering structure in DICOM splits graphics, whether they are bitmap overlays or vector annotation graphics, into a number of user-defined levels whose visibility can be individually toggled on and off by the user.  Display shutters, which are shapes or rasters that hide a portion of the underlying image for the purpose of making the visible portions more prominent without modifying the underlying pixel data, can also be applied on top of the image.

 

This scene graph is further complicated by the fact that, in the DICOM Standard, both bitmap display shutters and raster overlays are stored as overlay plane constructs – in other words, overlay planes can be displayed as layered graphics or as a display shutter, resulting in a scene graph where there are shared objects between the Shutters and Layers logical groupings as in the diagram above.

The Framework support for DICOM presentation states solves this by introducing the DicomGraphicsPlane composite which holds all the shutters, layers, overlays and annotation graphics.  The DicomGraphicsPlane is a domain-level graphic that owns collections of available shutters, overlays and layers.  Individual annotations can be inserted into the appropriate layer and geometric shutters can be inserted into the shutters collection, while references to the overlays are kept in a separate collection (the grey elements in the following diagram) and individually activated as either a shutter or a regular graphic (if the latter, then a layer must be specified) by moving the actual graphic objects to the appropriate shutter or layer composite graphic.

 

The overlay collections are actually further divided by the source of the overlay data – be they from the image SOP instance, the presentation state SOP instance, or dynamically created at runtime – as its class diagram shows.

 

Finally, the VOI aspect of DICOM presentation states are stored separately since they are not graphics at all, but rather act on the underlying image by transforming the viewable pixel values.  This information can be stored as either a window width/centre pair (which essentially gives you the coefficients of a formula that is used to transform the pixel values to display values) or as a look-up table (which maps each pixel value to a display value).  The IDicomVoiLutsProvider interface provides the mechanism to retrieve any VOI information from either the image header itself or an associated presentation state.


1  DICOM masks are not supported at the time of this writing, although all the other listed concepts are supported.