The overall DICOM Implementation in 3D Slicer consists of two main bodies of code embedded within the application. CTK code is responsible for the implementation of the DICOM database and networking layer. The CTK code is implemented C++ and follows the Qt style. The DICOM Module exposes this functionality to slicer users, and provides hooks through which other module can register DICOM Plugins to handle the conversion of specific DICOM data objects into the corresponding MRML representation. Once the data is in slicer, it can be operated on via the standard slicer mechanisms.

Customize table columns in DICOM browser

Columns in the browser can be renamed, reordered, shown/hidden, etc. An example snippet to customize the browser can be found in the script repository.

The changes made like this are written into the database (ColumnDisplayProperties table), so the column customizations can be done only once per database.

Customize DICOM browser table content

The way the raw DICOM tags are represented in the fields of the DICOM tables is determined by the displayed field generator rules. These rules are subclasses of the ctkDICOMDisplayedFieldGeneratorAbstractRule class, and need to be registered to the displayed field generator in order to take part of the generation.

The fields are updated when 1) files are added to the database or 2) the database schema is updated (happens when opening an older database with a newer Slicer). In the current version only those files (i.e. instances) are processed for which the displayed fields have never been generated.

When updating the displayed fields, every rule defines the fields it is responsible for using the cached DICOM tags in the database. Tags can be requested to be cached in the rules from the getRequiredDICOMTags function. New field values are generated by the rules instance by instance. First, the getDisplayedFieldsForInstance function is called for each rule in which the custom values are generated from the raw tags, then the results are merged by calling mergeDisplayedFieldsForInstance for all the rules. Each field can be requested to be merged with “expect same value”, which uses the only non-empty value and throws a warning if conflicting values are encountered, or with “concatenate”, which simply concatenates the displayed field values together.

The existing two rules can be used as examples: the default and the RT rules.

Plugin architecture

There are many different kind of DICOM information objects and import/export of all of them would not be feasible to implement in the Slicer core (see more information in the DICOM module user manual). Therefore, extensions can implement custom importer/exporter clases based on DICOMLib.DICOMPlugin class and add them to slicer.modules.dicomPlugins dictionary object. The DICOM module uses these plugins to determine list of loadable and exportable items.


See the CTK web site for more information on the internals of the DICOM implementation. This tool uses the DCMTK DICOM library.


Examples for common DICOM operations are provided in the script repository.