When a DICOM study is loaded into CC Workstation, its images (or more correctly, SOP instances) are inserted into a StudyTree. Using the Study, Series and Sop Instance UIDs in the images themselves, the StudyTree organizes the images into the Patient/Study/Series/Sop hierarchy as defined by DICOM.
A few things are worth noting:
| • | Although images are the most common type of DICOM object, a Sop is not always an image; hence the reason why there is both a Sop and an ImageSop class. |
| • | DICOM makes a distinction between regular image objects (i.e. ImageSops that contain pixel data for only one image) and multiframe image objects (i.e., ImageSops that encapsulate pixel data for multiple image frames). In the CC Framework, however, we simplify the model by insisting that all images are multiframe images. A regular image is simply a special case: it is a multiframe image with one frame. Thus, in the object model, an ImageSop has 1 or more Frames. |
| • | The pixel data returned from a Frame (actually, ISopFrameData, owned by ISopDataSource, which has been purposely excluded from the above diagram for the sake of simplicity) is normalized, in that any required decompression or colour space transformation is done automatically, since doing so makes it much easier for ImageGraphic-related classes to consume the pixel data. More specifically, the following conditions are true: |
| 1. | All pixel data is guaranteed to be uncompressed. |
| 2. | Colour images are always in 32-bit ARGB format. |
| 3. | Grayscale images are always in 8-bit or 16-bit values and sign-filled in the high bits (any bits outside the range as specified by HighBit and BitsStored are masked out, and then the entire thing is bit shifted such that HighBit is exactly one less than BitsStored). |
| • | Sop and ImageSop are simply bridge classes (see Bridge Design Pattern) to the actual source of DICOM data, ISopDataSource. Sop and ImageSop also transparently manage a shared cache of ISopDataSources in order to minimize memory usage, since DICOM images are often very large. This means that if you load the same study into several ImageViewerComponents, they will all transparently share the same data. The cache will silently dispose a duplicate in favour of an existing instance. |
| • | ISopDataSource can be thought of as an abstraction of what is essentially a DICOM file. The underlying data, however, is often pieced together as it's attributes are accessed in order to provide the most efficient experience possible. There are currently 3 main implementations of ISopDataSource in the viewer: |
| 1. | LocalSopDataSource: this is the type of data source that will be used if you load images from the 'My Computer' tab in the viewer's Explorer. The underlying source is simply a local dicom file. |
| 2. | LocalDataStoreSopDataSource: this is the type of data source that will be used if you load images from the viewer's local database. The underlying source is a combination of: |
| • | A database table for some important study-level attributes (basically anything that would be queried on in a Study Root Query) to optimize query speed. |
| • | An xml file that efficiently stores the DICOM attribute values for all the sop instances in the parent study, excepting private and unknown tags, as well as tags with extremely long values (i.e. pixel data, among others). Only when an attempt to access an attribute that is not stored in the xml is the actual DICOM file loaded from disk. This greatly improves the "time to first image" when loading a study. Refer to ClearCanvas.Dicom.DataStore.Study and ClearCanvas.Dicom.Utilities.Xml.StudyXml to see the implementation. |
| 3. | StreamingSopDataSource: this is a proprietary WADO (See DICOM Part 18 - Web Access to DICOM Persistent Objects) implementation, and it is the type of data source that will be used if you load images from a ClearCanvas Streaming Server. The underlying data source is similar to the LocalDataStoreSopDataSource, but: |
| • | All the sop instances in the study are initially created from a study xml file. |
| • | If client code attempts to access an attribute that has been excluded from the xml, the entire image header will be retrieved from the streaming server, minus the pixel data. |
| • | Pixel data is loaded on-demand, directly from the streaming server. |
| • | Although the actual data comes from an ISopDataSource, the level to which you will ever use these objects in your code is minimal. The entire viewer Framework still deals with Sops and ImageSops as much as possible because they are higher level abstractions of DICOM sop instances and are, therefore, much easier to work with. |
