This section describes the core concepts in the
Cornerstone3D is more than a "rendering" library. It handles:
- rendering of the image (both using GPU or CPU)
- caching of the data and metadata
- providing a framework for image/volume loader APIs
- providing metadata API support.
The purpose of this section is to give an overview of the core concepts in
A Cornerstone3D ImageId is a URL which identifies a single image for cornerstone to display.
Cornerstone Image Loaders return Image Load Objects which contain a Promise. The reason we have chosen to use an Object instead of solely returning a Promise is because now Image Loaders can also return other properties in their Image Load Objects. As an example, we intend to implement support for cancelling pending or ongoing requests using a cancelFn passed back by an Image Loader within an Image Load Object.
Medical images typically come with lots of non-pixel-wise metadata such as the pixel spacing of the image, the patient ID, or the scan acquisition date. With some file types (e.g. DICOM), this information is stored within the file header and can be read and parsed and passed around your application. With others (e.g. JPEG, PNG), this information needs to be provided independently from the actual pixel data. Even for DICOM images, however, it is common for application developers to provide metadata independently from the transmission of pixel data from the server to the client since this can considerably improve performance.
A volume is a 3D data array that has a physical size and orientation in space. It can be built by composing pixel data and metadata of a 3D imaging series, or can be defined from scratch by the application. A volume has a FrameOfReferenceUID, voxelSpacing (x,y,z), voxel dimensions (x,y,z), origin, and orientation` vectors which uniquely define its coordinate system with respect to the patient coordinate system.
Similar to the Image Loaders, a volume loader takes a volumeId and other information
The Cache API’s role is to keep track of created volumes, manage memory usage, and alert the host application when trying to allocate data that would exceed application defined limits.
A viewport can be thought of as:
A RenderingEngine allows the user to create Viewports, associate these Viewports with onscreen HTML elements, and render data to these elements using an offscreen WebGL canvas.
The RequestPool Manager has been extensively reworked to provide two new features: 1) asynchronous image retrieval and decoding 2) requests re-ordering.