DICOM file notes

Created:  2/14/200
Last Modified: 2/23/2000
Version: cpmed 03d
Page from SRView  Notebook, Jim Nash, Synergy Research Inc.
Back to Contents



 These notes cover our implementation of a DICOM reader into SRView.

The DICOM reader was derived from NIH Image. That reader was written in Pascal and was based on a 1997 draft version of DICOM 3. It has been tested on a wide range of images. SRView's DICOM reader was updated to the final version DICOM 3.3, 1999.

A number of improvements were made relative to the NIH Image reader. These include:

 

Other files and documents.

DICOMimg.cc - is the DICOM reader. It depends on srString.cc for string services. It was designed to be called by image.cc which is a part of SRView.

The DICOM standard contains 14 "parts", each in its own PDF document. The PDF files can be downloaded from David Clunie's page, http://idt.net/~dclunie/dicom-status/status.html. I have the first 6 in case this link disappears. Here are the links to download:

part 1, Introduction and Overview
part 2, Conformance
part 3, Information Object Definitions
part 4, Service Class Specifications
part 5, Data Structures and Encoding
part 6, Data Dictionary
part 7, Message Exchange
part 8, Network Communication Support for Message Exchange
part 9, Point to Point Communication for Message Exchange
part 10, Media Storage and File Format for Data Interchange
part 11, Media Storage Application Profiles
part 12, Media Formats and Physical Media for Data Interchange
part 13, Print Management Point To Point Communication Support
part 14, Grayscale Standard Display Function

DICOM standard documents are refered to as ps3.1 through ps3.14. I will refer to a page number as "ps3.1-nnn", and may add "pdf-nnn" which gives the PDF document's page number for easy reference.

 

Definitions.

Definitions given by the DICOM standard is very complex. The salient definitions are repeated (and interpreted) here.

Attribute - describes some feature of the image. This includes Tag, Type, length, name, value.

Data Dictionary - a list of attributes including Tag, Type, name, but not length and not value. The Data Dictionary is used to know how to interpret a value.

Data Element - a Tag followed by a length followed by a value. The length tells how long the value is in bytes. The next tag, relative to the current tag, is found by adding the length plus eight bytes. The value may contain multiple numbers or it may contain a string, or it may point to an array, or it may be an image.

Data Set - a DICOM file. The Data Set consists of a sequence of Data Elements. This includes attributes and pixel data.

Little Endian - a coding scheme in which the least significant byte of an integer comes first in a byte stream. The opposite of Big Endian where the "big end" comes first.

Tag - a unique identifier for an attribute. It consists of two integers. The Tag is found in the image file and the Data Dictionary. When the DICOM reader finds a tag in a Data Set, it looks it up in the Data Dictionary.

Value Representation (VR) - the type or encoding of the value. The Type is found in the Data Dictionary. ps 3.5-15, pdf-21, contains a list of types in table ps 3.5-6.2-1. The Data Dictionary itself is contained in ps6.

 

Assumptions

DICOM uses the "Common character set of ISO 8859". We assume this is the same as what is commonly known as "ASCII". We have not checked.

Little Endian is the default ordering in DICOM. We assume that this is always true (ps 3.5-28).

This DICOM reader knows nothing of Service and is only concerned with Information Objects. The DICOM model combines Service and Object in a DICOM transmission.

We identify a group of DICOM files as belonging to the same image if they have the same Study Date (8,20) and Study Time (8,30).

The DICOM dictionary we use is taken, unmodified, from NIH Image. There is no reference to date, but I suspect it comes from about 1995.

 

Value representations

Here is a list of codes that we use and that DICOM defines to describe how values are encoded. The column 'interpret' shows how we interpret the data. We assume, for example, that a signed integer is the same as unsigned for cases where the unsigned integer is positive definite and never exceeds the range of the defined value. This restriction came from Pascal that does not handle unsigned. A detailed description of the DICOM value representations (VR), see document 5 (99_05dr.pdf), section 6.2.

 VR  interpret  name
 DS string represents a floating point number
 DA string Date, yyyymmdd
 TM string Time, hhmmss.sss ?
 IS string integer
 US integer unsigned 2 byte integer, little endian
 SS integer signed 2 byte integer, little endian
 UI string Unique Identifier, ex, "1.3.12.2.1107.5.8.1.123456789.1995..."

 

Attributes we use

For a description of attributes, refer to the third book of the DICOM standard (99_03dr.pdf). It is easiest to find an attribute by looking in the index. Find coding information in the code dictionary, DICOMdict.

 tag  coding  type  name  pages
 8, 20 DA  2  Study Date  3-129
 8, 30  TM  2  Study Time  3-129
 18, 88 DS  2 or 3 Slice Spacing (zVox) ?  3-186
 20, D  UI  1  Study Instance UID  3-129
 20, E UI 1 Series Instance UID  3-131
 20, 13   2 Instance Number (slice number)  3-139
 20, 32 DS 1 Image Position (relative to patient)  
 20, 1001  IS  1  Images in Acquisition (retired)  ret.
 20, 1002  IS  3 Images in Acquisition 3-140
 28, 2  US  1 Samples per Pixel (planes in file, zSize)  3-145
 28, 8  IS  1 Number of Frames  3-153
 28, 10  US  1 Rows (height, ySize)  3-145
 28, 11 US 1 Column (width, xSize)  3-145
 28, 30 DS 1 Pixel Spacing (yVox \ xVox)  3-144
 28, 100 US 1 Bits Allocated (8 or 16)  3-145
 28, 103  US  1  Pixel Representation  3-145
 7FE0 OX   Pixel Data  

 

Attributes we ignore

Here is a list of attributes we do not use, but perhaps should one day.

 tag  coding  type  name
 18, 50     Slice Thickness, may be useful for analysis
 20, 37 DS   Image Orientation (Patient) eg (0,1,0,0,0,1)
 

 



 Back to Contents