conformance

This page details which parts of DICOM the DWV supports and also plans to support... This is mainly guided by the demo data that I have, so if you have data that is not supported, please provide me some and I'll try to integrate it.

Main reference: DICOM/2022a. The dictionary was generated using part06/chapter_6.

Validity

All DICOM files should start with the DICOM prefix DICM (see DICOM File Meta Information). If not, it is not a valid DICOM. Since v0.26 (#188), the parser will attempt to parse data without the prefix but there are no guaranty of results!

Transfer syntax

See the definition and the UID list.

  • 1.2.840.10008.1.2: Implicit VR - Little Endian -> ✅ (since v0.2)
  • 1.2.840.10008.1.2.1: Explicit VR - Little Endian -> ✅ (since v0.2)
  • 1.2.840.10008.1.2.1.99: Deflated Explicit VR - Little Endian -> ❌
  • 1.2.840.10008.1.2.2: Explicit VR - Big Endian -> ✅ (since v0.2)
  • 1.2.840.10008.1.2.4.100: MPEG2 Image Compression -> ❌
  • 1.2.840.10008.1.2.4.5[0,1]: JPEG -> ✅ (since v0.11, see #61)
  • 1.2.840.10008.1.2.4.[57,70]: JPEG Lossless -> ✅ (since v0.11, see #165)
  • 1.2.840.10008.1.2.4.5[others]: retired JPEG -> ❌
  • 1.2.840.10008.1.2.4.6*: retired JPEG -> ❌
  • 1.2.840.10008.1.2.4.8*: JPEG-LS -> ❌
  • 1.2.840.10008.1.2.4.9*: JPEG 2000 -> ✅ (since v0.5, see #131)
  • 1.2.840.10008.1.2.5: RLE -> ✅ (since v0.26, see #636)

Photometric Interpretation

See the definition. The planar configuration (definition) is used to define the memory layout of colour images.

  • MONOCHROME1 -> ✅ (since v0.2)
  • MONOCHROME2 -> ✅ (since v0.3)
  • PALETTE COLOUR -> ✅ (since v0.27, see #664)
  • RGB -> ✅ (since v0.3, both planar configuration)
  • YBR_FULL -> ❌
  • YBR_FULL_422 -> ✅ (since v0.15)
  • YBR_PARTIAL_422 -> ❌
  • YBR_PARTIAL_420 -> ❌
  • YBR_ICT -> ❌
  • YBR_RCT -> ❌

Data elements

All Value Representations (VR) should be supported. See the official list.

Dicom web

Web Access to Dicom persistent Objects (see DICOMweb)

WADO-RS

-> RESTful Services (RS) (see Part 3.18 chap 10)

WADO-RS is supported via the MultipartLoader since v0.31.

The default Accept header should be something like: multipart/related; type="application/dicom"; transfer-syntax=*'.

The tests/pacs/dcmweb.html test page allows to connect to an Orthanc instance and retrieve data from it.

WADO-URI

-> URI based (see Part 3.18 chap 9)

WADO-URI can be provided in the DWV URL using ?input= since v0.3.

Arguments follow regular URI standard.

  • requestType: WADO. Required
  • contentType: Required
    • application/dicom (see transfer syntax above for support)
    • image/jpeg ✅ (since v0.3)
    • image/gif ✅ (since v0.3)
    • image/png ✅ (since v0.3)
    • image/jp2 ❌
  • studyUID, seriesUID, objectUID. Required
  • anonymise: true or false.
  • If the type is image, then rows, columns, windowWidth, windowCenter and more can be specified.

Example url:

http://dicom.vital-it.ch:8089/wado?
   requestType=WADO&
   contentType=application/dicom&
   studyUID=2.16.840.1.113669.632.20.1211.10000744858&
   seriesUID=1.3.6.1.4.1.19291.2.1.2.2413568109772100001&
   objectUID=1.3.6.1.4.1.19291.2.1.3.2413568110716100007

Example server: dicomserver.co.uk, search.

Pixel data

File data storage, either one frame per file or multiple:

  • Single-frame data: ✅ (from start!)
  • Multi-frame data: ✅ (since v0.15.0, see #132)

Character sets

  • without code extensions: ✅ (since v0.15.0, see #248)
  • with code extensions: ❌

IOD and Modules

The Part PS 3.3 of the DICOM Standard specifies the set of Information Object Definitions (IODs) which provide an abstract definition of real-world objects applicable to communication of digital medical information. The Attributes of an IOD describe the properties of a Real-World Object Instance. Related Attributes are grouped into Modules which represent a higher level of semantics documented in the Module Specifications found in Annex C of the DICOM Standard.

An overview of modules for each IOD is defined in sect_A.1.4 (legend: sect_A.1.3).

Some IODs: