IDLffDICOM Object DICOM Conformance Summary

Note
This Conformance Summary is for the IDLffDICOM object only and has no relevance to IDL's DICOM Network Services or DICOM Read/Write support (provided by the IDLffDicomEx object). See www.ittvis.com/idl/dicom for the current DICOM Conformance Statement. See the following information for the IDLffDICOM object's conformance information.

Introduction

This section is an abbreviated DICOM conformance statement for the IDLffDICOM object, and specifies the compliance of this object's file reading support to the DICOM v3.0 standard. As described in the DICOM Standard PS 3.2 (Conformance), the purpose of this document is to outline the level of conformance to the DICOM standard and to enumerate the supported DICOM Service Classes, Information Objects, and Communications Protocols supported by the implementation of the IDLffDICOM object.

The IDLffDICOM object does not contain or support any of the DICOM services such as Storage, Query/Retrieve, Print, Verification, etc., so there will be no conformance claims relating to these services and no mention of any Application Entities for these services. Communications Protocol profiles will also be absent from this document for the same reasons. The remainder of this document will describe how the IDLffDICOM object handles the various Information Objects it is capable of reading.

Reading of DICOM Part 10 files

IDL supports reading files that conform to the DICOM Standard PS 3.10 DICOM File Format. This format provides a means to encapsulate in a file the Data Set representing a SOP (Service Object Pair) Instance related to a DICOM IOD (Information Object Definition). Files written to disk in this DICOM File Format will be referred to as DICOM Part 10 files for the remainder of this document. Note that the IDLffDICOM object does NOT support the writing of files in this DICOM File Format, only reading.

Encapsulated Transfer Syntaxes Supported

IDL supports reading DICOM Part 10 files whose contents have been written using the following Transfer Syntaxes. The Transfer Syntax UID is in the file's DICOM Tag field (0002,0010).

Table 30-1: Encapsulated Transfer Syntaxes Supported 

UID Value
UID Name

1.2.840.10008.1.2

Implicit VR Little Endian: Default Transfer Syntax for DICOM

1.2.840.10008.1.2.1

Explicit VR Little Endian

1.2.840.10008.1.2.2

Explicit VR Big Endian

Encapsulated Transfer Syntaxes NOT Supported

The IDLffDICOM object does NOT support reading DICOM Part 10 files whose contents have compressed data that has been written using the following Transfer Syntaxes. This object will NOT be able to access the data element (DICOM Tag field (7FE0,0010)) of files with these types of compressed data. The Transfer Syntax UID is in the file's DICOM Tag field (0002,0010).

Table 30-2: Encapsulated Transfer Syntaxes NOT Supported 

UID Value
UID Name

1.2.840.10008.1.2.4.50

JPEG Baseline (Process 1): Default Transfer Syntax for Lossy JPEG 8 Bit Image Compression

1.2.840.10008.1.2.4.51

JPEG Extended (Process 2 & 4): Default Transfer Syntax for Lossy JPEG 12 Bit Image Compression (Process 4 only)

1.2.840.10008.1.2.4.52

JPEG Extended (Process 3 & 5)

1.2.840.10008.1.2.4.53

JPEG Spectral Selection, Non-Hierarchical (Process 6 & 8)

1.2.840.10008.1.2.4.54

JPEG Spectral Selection, Non-Hierarchical (Process 7 & 9)

1.2.840.10008.1.2.4.55

JPEG Full Progression, Non-Hierarchical (Process 10 & 12)

1.2.840.10008.1.2.4.56

JPEG Full Progression, Non-Hierarchical (Process 11 & 13)

1.2.840.10008.1.2.4.57

JPEG Lossless, Non-Hierarchical (Process 14)

1.2.840.10008.1.2.4.58

JPEG Lossless, Non-Hierarchical (Process 15)

1.2.840.10008.1.2.4.59

JPEG Extended, Hierarchical (Process 16 & 18)

1.2.840.10008.1.2.4.60

JPEG Extended, Hierarchical (Process 17 & 19)

1.2.840.10008.1.2.4.61

JPEG Spectral Selection, Hierarchical (Process 20 & 22)

1.2.840.10008.1.2.4.62

JPEG Spectral Selection, Hierarchical (Process 21 & 23)

1.2.840.10008.1.2.4.63

JPEG Full Progression, Hierarchical (Process 24 & 26)

1.2.840.10008.1.2.4.64

JPEG Full Progression, Hierarchical (Process 25 & 27)

1.2.840.10008.1.2.4.65

JPEG Lossless, Hierarchical (Process 28)

1.2.840.10008.1.2.4.66

JPEG Lossless, Hierarchical (Process 29)

1.2.840.10008.1.2.4.70

JPEG Lossless, Non-Hierarchical, First-Order Prediction (Process 14 [Selection Value 1]): Default Transfer Syntax for Lossless JPEG Image Compression

1.2.840.10008.1.2.5

RLE Lossless

Encapsulated SOP Classes Supported

The IDLffDICOM object supports reading DICOM Part 10 files whose contents encapsulate the data of the following SOP Classes. The SOP Class UID is in the file's DICOM Tag field (0008,0016).

Table 30-3: Encapsulated SOP Classes Supported 

UID Value
UID Name

1.2.840.10008.5.1.4.1.1.1

CR Image Storage

1.2.840.10008.5.1.4.1.1.2

CT Image Storage

1.2.840.10008.5.1.4.1.1.4

MR Image Storage

1.2.840.10008.5.1.4.1.1.6.1

Ultrasound Image Storage

1.2.840.10008.5.1.4.1.1.7

Secondary Capture Image Storage

1.2.840.10008.5.1.4.1.1.12.1

X-Ray Angiographic Image Storage

1.2.840.10008.5.1.4.1.1.12.2

X-Ray Radiofluoroscopic Image Storage

1.2.840.10008.5.1.4.1.1.20

Nuclear Medicine Image Storage

1.2.840.10008.5.1.4.1.1.128

Positron Emission Tomography Image Storage

Handling of odd length data elements

The DICOM Standard PS 3.5 (Data Structures and Encoding) specifies that the data element values which make up a DICOM data stream must be padded to an even length. The toolkit upon which IDL's DICOM reading functionality is built strictly enforces this specification. If IDL encounters an incorrectly formed odd length data field while reading a DICOM Part 10 file it will report an error and stop the reading process.

Handling of undefined VRs

The VR (Value Representation) of a data element describes the data type and format of that data element's values. If IDL encounters an undefined VR while reading a DICOM Part 10 file, it will set that data element's VR to be UN (unknown).

Handling of retired and private data elements

Certain data elements are no longer supported under the v3.0 of the DICOM standard and are denoted as retired. Also, some DICOM implementations may require the communication of information that cannot be contained in standard data elements, and thus create private data elements to contain such information. Retired and private data elements should pose no problem to IDL's DICOM Part 10 file reading capability. When the IDLffDICOM object encounters a retired or private data element tag during reading a DICOM Part 10 file, it will treat it just like any standard data element: read the data value and allow it to be accessed via the IDLffDICOM::GetValue method.