DICOM in MeVisLab

This document is a basic reference for MeVisLab related DICOM (Digital Imaging and Communications in Medicine) functionality. This includes

  • References - References to external web sites.
  • Import - Loading DICOM files from disk and - if necessary - compose or convert multiple DICOM files to ML image or MultiFileVolumes.
  • Image and Tag Processing - Manipulating DICOM information and image data in DICOM files.
  • Export - Deriving DICOM files from existing ones or creating new ones and exporting them to files.
  • MeVisLab Communication with a PACS - The communication of MeVisLab, MeVisLab modules or services with a PACS or DICOM servers.
  • External Tools - Standalone tools distributed together with MeVisLab.
  • Anonymization - Ensuring that no undesired information (for example about patients) is left in DICOM files.
  • Programming Support - Tools, Libraries, Sources, Interfaces, and Examples for C++ and Python DICOM programmers.
  • Glossary - A DICOM related summary of many keywords, abbreviations, tools, modules etc. used in MeVisLab, also useful as an FAQ.

DICOM References

Some important DICOM web sites with much more information about DICOM:

DICOM Import

Importing DICOM files from a file system is probably the most typical problem related to DICOM. MeVisLab provides a number of tools for this purpose which have different advantages and disadvantages. Start with the following modules and tools:

Image and Tag Processing, Converters

DICOM Export

Available tools and modules:

  • DicomDOCSave - Creates DICOM compliant files encapsulating a given CDA, PDF, STL, OBJ, or MTL file.
  • DicomEnhancedSave - Creates DICOM compliant Legacy Converted Enhanced MR files.
  • DicomFIDSave - Creates DICOM compliant files of modality FID (fiducials).
  • DicomREGSave - Creates DICOM compliant files of modality REG to store registration deformation fields.
  • DicomSEGSave - Creates and composes a DICOM file of modality SEG and provides/composes the necessary tags to fulfill the DICOM standard requirements.
  • DicomSCSave - Creates DICOM compliant Secondary Capture DICOM files.
  • DicomSRSave - Creates DICOM compliant files of modality SR (Structured Report).
  • DicomModifyMultiFileVolumeExport - Exports a DICOM MultiFileVolume as files into a destination directory after applying connected DICOM tag modifiers.
  • DicomTool - Combines several often needed DICOM tools: saving of single DICOM slices, sending of data to a PACS, modifying of DICOM Tags, and verifying DICOM connectivity.
  • ImageSave - Stores an ML image in one of many common files formats including DICOM.
  • SaveDicomTree - Saves a DicomTree tree as DICOM file.
  • Radio Therapy related modules:

MeVisLab Communication with a PACS

  • DicomQuery - A simple browser for a DICOM Query/Retrieve Service Class Provider.
  • DicomReceiver - An interface to the OFFIS storescp application which allows to receive DICOM images from any networked DICOM Storage Service Class User.

External Tools

  • eatDicom
  • Median (not part of all MeVisLab installations)
  • Command line Tools of Dcmtk
    • PACS communication (not available in all MeVisLab installers):
      • echoscu: DICOM verification (C-ECHO) SCU
      • findscu: DICOM query (C-FIND) SCU
      • movescu: DICOM retrieve (C-MOVE) SCU
      • storescp: DICOM storage (C-STORE) SCP
      • storescu: DICOM storage (C-STORE) SCU
      • termscu: DICOM termination SCU
      • dcmsend: Simple DICOM storage SCU (sender)
    • Conversion, tag dump, and further tools (not available in all MeVisLab installers):
      • Between DICOM and JSON, CDA, XML, PDF, NII, PNM, ASCII, STL, or image formats: cda2dcm, dcm2xml, dcm2stl, xml2dcm, dcm2pdf, pdf2dcm, dcm2nii, dcmj2pnm, dcm2pnm, dcm2json, dcmcjpeg, dcmdjpeg, img2dcm, dcmconv
      • dcmftest: Tests whether a file uses DICOM part 10 format.
      • dcmgpdir: Creates a general purpose DICOMDIR.
      • dcmodify: Modifies DICOM files.
      • uuid: Creates a DICOM UID.
      • dcmdump: Dumps DICOM file and data set.
      • dump2dcm: Converts ASCII dump to DICOM file.
      • dcmcrle, dcmdrle: Encodes/Decodes DICOM file to/from RLE-compressed DICOM file.
      • as well as further tools: dcmgpdir, dcmicmp, dcmmkdir, dcmquant, dcmrecv, dcmscale.

Anonymization

Anonymization means in this context the removal or the replacement of all patient specific information from a medical data set (for example a DICOM file). The resulting file does not contain any more information which allow the inferring of the patient’s identity (e.g., PatientName, PatientBirthDate).

A more general anonymization will also remove or replace information about the institution where the data set came from, or when the image data were obtained.

In MeVisLab, * DicomDeidentify performs anonymization of DICOM data according to DICOM standard PS 3.15 annex E. DicomTagModify or DicomModifyTagsPlugin can also be used for this purpose if only a few tags shall be modified. In some versions of MeVisLab, the anonymization tool Median is also available.

Programming Support

The following projects in the MeVis/Foundation package contain the basic DICOM interface libraries in MeVisLab:

  • DCMTree Overview- The abstract interface for most DICOM related implementations in MeVisLab. It is independent of a library such as dcmtk or gdcm.
  • DicomTree_OFFIS - The concrete backend implementation for Dicom Tree using dcmtk for all low level DICOM operations. It should not be used directly.

The following projects in the FMEwork/ReleaseMeVis package contain tool functions and (base) classes for DICOM related developments, using Dicom Tree:

The following projects also have SDK interfaces and public sources which might be useful for DICOM related developments, using Dicom Tree:

The following libraries directly use dcmtk (and not the Dicom Tree abstraction interface):

The following C++ libraries implement wrappers for some DirectDicomImport and MultiFileVolume classes as well as for dcmtk-based interfaces. In this way these classes can directly be used in Python:

  • MLAccessDirectDicomImportWrapper
  • ToolBoxReference/MLDirectDicomImportWrappersDocPage
  • ToolBoxReference/MLMultiFileVolumeListWrapper
  • ToolBoxReference/MLDirectDicomImportWrapper
  • ToolBoxReference/MLDirectDicomImportOutputWrapper
  • ToolBoxReference/MLDirectDicomImportVolumeReferenceWrapper
  • In the directory FMEwork/ReleaseMeVis/Sources/Wrappers/MLDcmtkIODWrappers/ there is also a number of wrappers for IOD classes of dcmtk.

Glossary

This glossary lists some often used DICOM abbreviations, keywords, and questions related to MeVisLab. For a more detailed list see http://www.dclunie.com/dicom-status/status.html#BaseStandard2011, Section 3 - Definitions.

  • ACR-NEMA:

    The abbreviation of American College of Radiology and the National Electrical Manufacturers Association. In DICOM contexts this often refers the older standard of ACR-NEMA file format used for medical images. DICOM almost always is able to operate on ACR-NEMA files as it can do it on DICOM files, because a backward compatibility is normally given.

  • Anonymization:

    Usually this means the removal or replacement of patient information, but is sometimes used in other similar contexts. See Anonymization for details.

  • Composite IOD:

    A Composite IOD (simplified) is an IOD which represents several real world entitites. As an example the Composite IOD CT is built from the Patient, the General Study, General Series, and many other modules.

  • Dcmtk

    The DICOM ToolKit, an open source library dedicated for C++-development of DICOM. See http://support.dcmtk.org/docs/ for details. It is used in MeVisLab mostly as backend for DICOM file IO, but in many places also directly for advanced DICOM operations.

  • DICOM Tag Dictionary

    A dictionary of all standard DICOM tags can be found in many places in the web, examples are http://www.dicomlookup.com/default.htm or the standard itself where also a more complex context description of all tags can be found.

  • DICOM/Tiff File Format

    A proprietary MeVisLab file format storing DICOM information together with a paged TIFF file in a DICOM/TIFF file pair. It stores multi-dimensional image data of 8, 16, 32 bit (un)signed integer values or floating point values, and all non-pixel data DICOM tags as a second file. This way, a large number of DICOM files can be represented as a single file pair.

  • DICOM Tree

    In most C++ implementations in MeVisLab, DICOM files and tags are implemented using classes from the DCMTree library which contains interface classes hiding the application code from the actually used DICOM library (currently dcmtk). Loaded DICOM files in MeVisLab are represented by a class called DCMTree::Tree from which each one is built of DICOM Tags of class type DCMTree::Tag. Both classes are heavily used to implement most algorithms on DICOM tags.

  • DICOM UID

    A DICOM UID is Unique Identifier which is used to identify uniquely objects such instances, files, class types etc. A UID used for one object may never be used for another object. Therefore is can safely be used to reference another object in the world. It is always build from numbers and separating dots “.”, such as 1.2.840.10008.5.1.4.1.1.2 which identifies the CT Image Storage Service-Object Pair SOP. The length of UIDs must not exceed 64 bytes.

  • eatDicom

    An old command line tool used to compose and convert sets of image-like DICOM files to the proprietary MeVisLab DICOM/Tiff File Format. It is used by DicomImport. It should only be used for backward compatibility; it does not support newer concepts are not supported any more.

  • Enhanced Multiframe DICOM

    This is an advanced DICOM Standard to embed multiple DICOM frames belonging to multiple series or volumes in one or more files. Such Multi-frame DICOM files require a more sophisticated approach to import them correctly, because their pixels data is no contiguous block any more which can easily be interpreted as a single image volume. The import module DirectDicomImport therefore decomposes such files into all of its frames and handles them as a large number of single frame DICOM files instead. See option Decompose Multi Frame Files in DirectDicomImport.

  • Frame

    In the DICOM context a frame usually describes a 2D dimensional gray level or color image. It is often described as a Single frame DICOM image.

  • Frame of Reference

    Typically stored as a DICOM Tag, the Frame of Reference is an identifier specifying another DICOM object with a UID. This way a DICOM file, for example, may depend on other information of another DICOM file, or a series of files may share some common information in another file without duplicating information.

  • gdcm
    • The Grassroots DICOM library. A C++ open source DICOM library used in ITK versions for DICOM IO and therefore also indirectly by MeVisLab modules.
    • Internally the gdcm is needed by MeVisLab to load JPEG2000 compressed DICOM images.
    • See http://gdcm.sourceforge.net/wiki/index.php/Main_Page for details.

  • IE

    An Information Entity (IE) in the DICOM sense is a portion of data related to a real-world object. Such entities are usually used to as smaller components of a Composite IOD.

  • DICOM Unique Identifier (UID)

    A unique identification string or number which can be referenced by someone else to identify safely a specific object. This concept is used by DICOM in many contexts, but typically to assign world-wide unique identifier to files, objects, cases, studies, series, images, frames, or a medium. For example, a DICOM object can use a Frame of Reference tag with an ID of another DICOM object containing the ID as DICOM Unique Identifier. This way multiple DICOM objects can be handled independently of each other without losing the information about their togetherness.

  • Median

    An anonymization tool for DICOM files available in some MeVisLab version. See Anonymization for details.

  • Modality

    The type of equipment that originally acquired the data of the DICOM files, such as CT (Computed Tomography), MR (Magnetic Resonance), OT (Other) US (Ultrasound), SR (Structured Report Document), and many more.

  • MultiFileVolume

    Older MeVisLab tools or applications used to convert DICOM files to the DICOM/Tiff File Format before it could be loaded in MeVisLab for further processing. This, however, has many disadvantages such as data duplication or that only image-like DICOM files can be imported and Enhanced Multiframe DICOM file formats are not supported.

    Those problems are solved by creating a MultiFileVolume referencing the original (DICOM) file set and representing it as one (image) volume in MeVisLab. Loaders for MultiFileVolumes such as DirectDicomImport or MultiFileVolumeListImageOutput provide a demand-driven access to the original input file set. Therefore a MultiFileVolume can be added to the original data for an easier and better organized access.

    Modules such as DirectDicomImport or MultiFileVolumeListImageOutput do not only create or read single MultiFileVolume instances but MultiFileVolumeLists. This allows to handle multiple DICOM series or studies in one file set.

  • Multi-frame DICOM

    In the recent years the amount of DICOM images in clinical contexts has rapidly increased. The common approach to represent each 2D DICOM image / Frame as a Single frame DICOM causes more and more trouble due to the huge number of resulting files.

    Therefore the DICOM Standards has introduced multi-frame DICOM files which can contain multiple Frames in one file for more compact and faster access. The common multi-frame files can easily be loaded comparably to a three or four dimensional image. However, some multi-frame parts also allow to embed multiple Frames belonging to multiple image volumes in one file. Such Enhanced multi-frame DICOM files require a more sophisticated approach to import them correctly.

  • Overlay

    Many DICOM files contain overlays next to image information. These are bit images which are used to display additional information on top of a normal DICOM image or frame. Typically they are used to add annotations, masks, frame locations, orientation information, but also segmentation information, etc. The modules DirectDicomImport, MultiFileVolumeListImageOutput, and ApplyDicomPixelModifiers have an addition output for displaying those overlays.

  • Private Creator

    Private tags in a DICOM file shall always be attached to a private creator. A private creator must have the same odd Group ID as the private tag and its Element ID must be zero in the upper eight bits and the lower eight bits must be identical with the upper eight bits of the element ID of the Private tags.

    An example with a private creator defining the private tag group with the group ID 0019 and the element ID group with 10 as upper eight bits. In this private creator group up to 240 tags can be stored with the ids (0019,1000) up to (0019,10FF):

    (0019,0010) LO [PrivateCreator]:MY_OWN_UNIQUE_PRIVATE_CREATOR_DEFINITION
    (0019,1008) CS [Private Tag: Unknown meaning, MY_OWN_UNIQUE_PRIVATE_CREATOR_DEFINITION]:This is a private tag value
    (0019,1009) LO [Private Tag: Unknown meaning, MY_OWN_UNIQUE_PRIVATE_CREATOR_DEFINITION]:This is another private tag value

    Without the corresponding Private Creator, the two private tags would be orphaned and therefore meaningless. The string MY_OWN_UNIQUE_PRIVATE_CREATOR_DEFINITION should be ‘as unique as possible’ to avoid that any other vendor or manufacturer uses the same one.

  • Private Tag

    A private DICOM tag which has an odd Tag ID is a so called Private Tag. The meaning of its value is not defined by the DICOM Standard but by a proprietary institution or software. Its contents, meanings, and usage are of no public use. Although the values of some private tags are readable, the contents of binary values of private tags normally cannot be displayed easily, because vendors may store arbitrary data in them.

    Note

    A private tag can be identified only by its Private Creator together with its Tag ID whose upper 24 bits must match the Group ID and the lower eight bits of the Element ID.

    A typical error is that a private tag is created or identified only by its ID which is insufficient. See Private Creator for details.

    MeVisLab has manipulators, creators, decoders, and base classes for some private DICOM tag types. See Private DICOM Tag Decoders for further information.

  • Private DICOM Tag Decoders

    MeVisLab allows the implementation of decoders for private binary tags. See the base class PrivateDICOMTagDecoderPluginBase from which new decoders can be derived and registered in the runtime type system of MeVisLab. Many, not all, tag dump functions in MeVisLab detect such decoders and can decode such tags. Modules such as DirectDicomImport or MultiFileVolumeListImageOutput allow the activation of these decoders with a flag in their user interface. See C++-implementation documentation of some private tag decoders for GDCM, Generic, Toshiba, and Sequence and an overview about such decoders.

  • Query

  • Rescale Intercept and Rescale Slope

    Rescale Intercept and Rescale Slope are normally understood as factor and offset for pixel values of DICOM images. If a DICOM image file contains Rescale Intercept and Rescale Slope tags then any stored pixel must be multiplied with the Rescale Intercept value and Rescale Slope must be added to get the actual pixel value for further processing.

  • Retrieve
  • Sequence Tag

  • SCP

    Service Class Provider (similar to a server).

  • SCU

    Service Class User (similar to a client).

  • Single frame DICOM

    A single frame DICOM file usually contains a 2D dimensional gray level or color image. This is a very commonly used DICOM file type. To describe higher dimensional image data, a set of these files is needed. In recent years such file sets are replaced more and more by so-called Multi-frame DICOM.

    MeVisLab usually needs a DICOM Import process to be able to interpret single and multi-frame DICOM correctly as a compound image volume.

  • Tag Type

    The type of a DICOM Tag (not to be mixed up with Value Representation) describes whether a tag is mandatory (Type 1), mandatory but it may be empty (Type 2), or optional (Type 3) in its context. Type 1 and Type 2 tags also can be conditionally mandatory, for example only if another tag exists or has a specific value. Such conditional tags have either the type Type 1C or the Type 2C.

  • Value Multiplicity

    A DICOM Tag has zero, one, or multiple Tag Values. The value multiplicity defines how many of such values are required or allowed for a tag (typically for Standard Tags).

  • Value Representation

    The value of a DICOM Tag can store a number of different data configurations which are defined by the value representation of the tag. Most standard tags have value representations which are defined in the DICOM Standard (see DICOM Tag Dictionary for details) and which must not be changed. For Private Tags this is usually defined by the institution or software, and might not be known. See http://medical.nema.org/Dicom/2011/11_05pu.pdf, section 6.2 for a detailed description of all valid value representations.

    See also DCMTree::Vr