A PresentationImage can be thought of as the sum total of all the graphical objects in a scene. Each PresentationImage owns a single CompositeGraphic object which forms the root of the scene graph.

There are three basic types of graphics in the Framework – there are raster images defined as a region of pixel values, vector graphics defined as a shape and a number of coordinates, and composite graphics, which are simply collections of other graphics.

The CompositeGraphic is an important class in that it is derived from the base class Graphic and can itself own other Graphics. Those familiar with design patterns will recognize this as the Composite pattern. There are some noteworthy implications here:
| 1. | The scene graph is a tree. |
| 2. | Leaves in the tree are primitives, either ImageGraphics or VectorGraphics |
| 3. | A CompositeGraphic can own other CompositeGraphics |
| 4. | Because CompositeGraphic is a Graphic, a group of Graphics can be manipulated as though it were a single Graphic. |
| 5. | The scene graph can be traversed recursively. |
Generally speaking, the scene graph for a presentation image consists of a single CompositeImageGraphic which owns an ImageGraphic (the actual image itself) and a number of CompositeGraphics in which client-created graphics can be placed. The actual available CompositeGraphics varies depending on the type of PresentationImage, but BasicPresentationImage defines two of these – one for application-level graphics and another for user-level ("overlay") graphics 1.
The division of graphics into different levels is both for logical organization purposes as well as ensuring that the graphics are drawn in the correct order. The user-level graphics is for vector graphics directly created using input from the user, such as ROI measurements, whereas the application-level graphics is for graphics created by client-code, such as the scale graphic overlay. The domain-level graphics collection is for special graphic concepts that are specific to the type of image and may be sourced from user input, client-code, or even from any extra image information. The best example of a domain with special graphic concepts is DICOM, which defines a number of specialized graphics including shutters and bitmap overlays. The scene graphic is recursively rendered from the ImageGraphic and up, with later graphics being drawn over top of earlier graphics - the result is that all user-level graphics are always on top of any application-level graphics, which in turn are always on top of any domain-specific graphics, and all these graphics are guaranteed to be on top of the image itself.

For most use cases, client code should access only the ImageGraphic and the level-specific CompositeGraphics of the scene graph, since changing things at the root level can break the scene graph easily! Even inserting graphics directly into the CompositeImageGraphic can result in odd behaviour by changing the order in which graphics are rendered. To facilitate obtaining access to these graphic collections and the ImageGraphic, the Framework defines a number of provider interfaces. The interfaces also solve the problem where a certain graphic collection may not be applicable to all images - if an instance of a PresentationImage does not implement a certain provider interface, then it does not support the corresponding graphic collection.
Interface |
Purpose |
|---|---|
IApplicationGraphicsProvider |
Provides the application-level graphics collection. |
IOverlayGraphicsProvider |
Provides the user-level graphics collection. |
IDicomPresentationImage |
In addition to being the interface for DICOM presentation images, it also provides a collection for DICOM domain graphics. |
Note also that ImageGraphic and VectorGraphic are both abstract classes, meaning that actual concrete classes must be derived from them. The subclasses defined in the Framework are examined in later sections.
1 The name "Overlay Graphics" given to the user-level graphics layer is a holdover from a previous version of the Framework where it was the only level where graphics were placed, regardless of whether they were logically at the user or application levels.