An IDLffDICOM object contains the data for one or more images embedded in a DICOM Part 10 file. The API to the IDLffDICOM object provides accessor methods to the basic data elements of a DICOM file, namely the group/element tag, value representation, length, and data values. Additional methods deal with the file header preamble, data dictionary description for individual elements, and embedded sequences of elements. Most methods take a DICOM group/element tag as a parameter. An alternative parameter to the DICOM tag in some methods is the reference. A reference value is a LONG integer that is unique to each element in the DICOM object. This value can be used to directly access a specific element and to differentiate between elements in the DICOM file that have the same group/element tag. Valid reference values are always positive.
See IDLffDICOM Object DICOM Conformance Summary for information regarding IDL DICOM file reading support.
Note: See IDL Feature Support for a list of platforms that support DICOM file reading.
The IDLffDicomEx object greatly expands on the capabilities of the IDLffDICOM object and requires an additional license key to access the functionality. The IDLffDicomEx object includes methods for reading and writing pixel data to a DICOM file, and specifying the data compression. You can also add, modify, or remove public and private DICOM attribute tags, public and private sequences, and sets of repeating tags within sequences.
Superclasses
None
Creation
See IDLffDICOM::Init.
Properties
Objects of this class have the following properties. See IDLffDICOM Properties for details on individual properties.
Methods
This class has the following methods:
Version History
IDLffDICOM Object DICOM Conformance Summary
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).
|
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).
|
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).
|
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.