ImFusion SDK 4.3
Low-level/Core API

Low-level data structures for handling DICOM data. More...

+ Collaboration diagram for Low-level/Core API:

Detailed Description

Low-level data structures for handling DICOM data.

The core level of the ImFusion DICOM API revolves around a couple of central classes modeling the structure of DICOM data. As illustrated in the following class diagram, there are three essential abstract base classes/interfaces.

The set of IODs that are available for loading/saving DICOM data is managed by the IOD_Registry. This enables API developers and third-party plugins to extend the ImFusion Dicom Plugin with support for additional DICOM SOPs and other custom types.

Overview class diagram of the core API modeling the structure of DICOM data.

Error Handling

The core API of the ImFusion DICOM plugin provides a fine-grained error handling interface to track errors while handling DICOM files. The central class for this is the ErrorRecorder interface. Inherit from this class if you need to handle error occurring during loading/saving DICOM data. The majority of the classes in the Dicom plugin (e.g. Dicom::Module, Dicom::IOD, DicomLoader) implement this interface and automatically propagate errors up the different hierarchy levels.

A Error distinguishes three severities:

In case of warnings or non-critical errors, the user has to decide how to proceed with the loaded data.

Extending DICOM loading/saving

Since DICOM is a very extensive standard, the ImFusionLib might not load/store all the (meta)data that are required for a specific application. The best way to support these cases, is to extend the DicomLoader and/or DicomWriter. There are currently two options for this:

Creating a Dicom::Extension

Implementing a Dicom::Extension is the best way if you need to load/store additional metadata, like a custom DataComponent or change certain parameters of the image data. See Extensions for more information.

Creating a Dicom::IOD

In some cases, creating a Dicom::Extension is not enough. For example due to an unsupported SOP class which produces a wrong SharedImageSet. In those cases it might be necessary to derive a custom Dicom::IOD. Check the documentation of Dicom::IOD for details on the individual interfaces that need to be implemented.

Also check if it makes sense to derive from Dicom::MultiFrameImageIOD or Dicom::EnhancedMultiFrameImageIOD instead of writing a Dicom::IOD from scratch.

Namespaces

namespace  ImFusion::Dicom
 Low-level and intermediate-level interfaces for working with DICOM data.
 
namespace  ImFusion::Dicom::VolumeReconstruction
 Namespace containing helper functions to reconstruct potential volumes from a set of individual DICOM frames.
 

Classes

class  ElementList
 Interface for classes that consist of Elements. More...
 
class  value_error
 Exception specialization for DICOM element retrieval. More...
 
class  Element< T >
 Dicom Element with a concrete value type. More...
 
struct  Error
 Structure for storing errors occurring during loading/saving DICOM data. More...
 
class  ErrorRecorder
 Error handling interface for the Dicom module. More...
 
struct  FrameDescriptor
 Descriptor for a single DICOM frame that is used during the loading process as intermediate representation before eventually converting the image data to a SharedImageSet. More...
 
class  IOD
 Base class of a Dicom Information Object Definition (IOD). More...
 
class  IOD_Registry
 A registry that assigns a IOD implementation to a SOP class UID. More...
 
class  ModuleList
 Interface for classes that consist of modules. More...
 
class  Module
 Base class for Dicom Modules. More...
 
class  SequenceItem
 Base class for sequence items. More...
 
class  Sequence< T >
 Concrete sequence of items of type T, which must be derived from SequenceItem. More...
 
class  PhilipsQLabIOD
 Loads ultrasound volume stored by Philips QLab software. More...
 
Search Tab / S to search, Esc to close