Navigation:  Image Viewer Architecture > Presentation States

A presentation state can be thought of as the set of parameter values, in addition to the original image itself, that would allow the current display of a presentation image to be persisted such that it can be recalled again at a later time, exactly as it appeared when the presentation state was saved.  In most cases, the parameters that can be persisted include the visible area, magnification factor and rotation of the image, but there can be more or less parameters depending on what the particular type of presentation image supports.  For example, a three-dimensional volume model image may support lighting source and intensity parameters, whereas a standard two-dimensional image would not.  The DICOM Standard, in particular, specifies a large number of supported presentation parameters such as annotation graphics, overlays and window width/centre, in addition to the basic parameters.

Images that support presentation states implement the IPresentationStateProvider interface which provides a single property to get or set the loaded presentation state object instance.

When the image is first constructed, this property is null.  After the user has customized the display of the image, a new instance of the proper presentation state type can be constructed and its Serilalize(...) method called to record the presentation state of the image in it's own type-specific format.  Typically, some way of saving the type-specific object is provided, for example as a DICOM file.  To restore a presentation state, the property is simply set to a presentation state object and, just before the next attempt by the renderer to draw the image, the presentation state is deserialized, adding the appropriate graphics to the image's scene graph.  Now, even if the user makes changes to the image, the presentation state object will still hold all the information required to reset the image's presentation state.

The reason the presentation state can only be deserialized just before drawing is because certain parameters depend on knowing the exact dimensions of the screen area it is being rendered to.  One of the key issues is that the client rectangle of the image at the time of deserialization can be different from that which was available at the time the presentation state was serialized (because, of course, there's no guarantee that the display device and resolution are going to be the same!).