All notes


Both server and client component of DCMPRINT support the following DICOM services:

Basic Grayscale Print Management
Basic Color Print Management
Print Jobs
Presentation LUT

For SCP:

VerificationSOPClass                       1.2.840.10008.1.1
BasicGrayscalePrintManagementMetaSOPClass  1.2.840.10008.
BasicColorPrintManagementMetaSOPClass      1.2.840.10008.
PrintJobSOPClass                           1.2.840.10008.
BasicAnnotationBoxSOPClass                 1.2.840.10008.
PresentationLUTSOPClass                    1.2.840.10008.


BasicGrayscalePrintManagementMetaSOPClass  1.2.840.10008.
BasicColorPrintManagementMetaSOPClass      1.2.840.10008.
BasicAnnotationBoxSOPClass                 1.2.840.10008.
PresentationLUTSOPClass                    1.2.840.10008.


Open source projects

The DICOM standard does not support pixel data types other than signed and unsigned integer,
 and the maximum bit depth is 16.

"The z spacing is computed from the image position and orientation between two consecutive  slices."
0018,0050 Slice Thickness: 0.6
0020,0032 Image Position (Patient): x\y\z
0020,1041 Slice Location: z

"GDCM - Indeed the value for the spacing of the image could be coming from:"
0018,1164 ImagerPixelSpacing
0018,2010 NominalScannedPixelSpacing
0028,0030 Pixel Spacing: 1.11\1.11
0028,0034 PixelAspectRatio

0028,0102 Hight Bit: 15
0028,0103 Pixel Representation: 0-unsigned,1-signed

0018,5100 Patient Position: HFS = Head First Supine, HFDR = Head First-Decubitus Right, HFDL = Head First-Decubitus Left.

DICOM concepts


DICOM is known as NEMA standard PS3. So when you find a DICOM PDF with name "PS3.6" then it is the 6th chapter but not 3rd.

DICOM (Digital Imaging and COmmunication in Medicine) is a medical image archiving and communication standard written by American College of Radiology (ACR) and National Electrical Manufacturers Association (NEMA) jointly. Conformance to the standard makes the hospital Picture Archiving and Communication System (PACS) be able to handle with image data from different modalities of different manufacturers. From version 3.0, DICOM adopts the Object-Oriented design, and defines lots of entities and relations (the so called E-R model). Now let's study some concepts in DICOM.

Presentation Context

Presentation Context (PC) can be considered as a negotiated channel within a DICOM association, through which the application entities exchange data.

A proposed PC consists of: a presentation context ID (an odd in (0, 255], unique within the association), a SOP class, a list of proposed transfer syntaxes. When the peer accepts it, the list of transfer syntaxes is replaced with a single accepted one. Reference.

Only 128 Presentation context supported? (the Google groups actually make a mirror from narkive).

During association negotiation the Presentation Context ID in the Association Request and Association Accept PDUs is encoded in a byte field.

Although its not explicitly stated anywhere in the standard that 127 presentation contexts are allowed, its implied by the fact that the Presentation Context ID is encoded as a byte and must be an odd number.

This was identified as an issue a number of years ago, and DICOM Supplement 90 was developed to address the issue, which can be seen here:

Unfortunately, the supplement has not been widely adopted, as far as I know, although I know some of the DICOM toolkits do support it.

The relevant section is in part 8, section in table 9-13:

Presentation-context-ID values shall be odd integers between 1 and 255, encoded as an unsigned binary number. For a complete description of the use of this field see Section

WCF note: Odd intergers between 1 and 255 inclusively, which make a total number of 128 rather than 127. Every persentation context has the format: abstract syntax / transfer syntax.

DCMTK Doc on asconfig.

The key names are "PresentationContext1", "PresentationContext2" etc., in increasing order.  Each list must not contain more than 128 entries, due to the limitation of the DICOM network protocol to 128 presentation contexts per association.

SCU and SCP's Presentations Context

The following example shows one presentation context list that could be used by an association requestor (Store SCU) to negotiate both lossy-compressed and uncompressed transmission of DICOM ultrasound images.

PresentationContext1 = UltrasoundImageStorage\JPEGBaseline
PresentationContext2 = UltrasoundImageStorage\Uncompressed
PresentationContext3 = UltrasoundMultiframeImageStorage\JPEGBaseline
PresentationContext4 = UltrasoundMultiframeImageStorage\Uncompressed

In the case of an association acceptor (SCP), each SOP class must appear only once in the list. The following example would be a valid transfer syntax list for an SCP, accepting only uncompressed ultrasound images:

PresentationContext1 = UltrasoundImageStorage\Uncompressed
PresentationContext2 = UltrasoundMultiframeImageStorage\Uncompressed

SOP class

Service Object Pair (SOP) stems from odd object orientated origins of DICOM. In practice, each object only has one directly associated service (Storage).

A Service-Object Pair (SOP) Class is defined by the union of an Information Object Definition (IOD) and a DICOM Service Elements (DIMSE). The SOP Class definition contains the rules and semantics which may restrict the use of the services in the DIMSE Service Group or the Attributes of the IOD.

Examples of Service Elements are Store, Get, Find, Move, etc.
Examples of Objects are CT images, MR images, but also include schedule lists, print queues, etc. Reference.

A class defines a certain functionality consisting of a combination of a Service and an Object, which make up the Pair - e.g. CT Storage is an example of an SOP Class.

DICOM has two different types of services, the composite and normalized services. Each SOP class is part of either the composite family or the normalized family. The DIMSE commands are identified as either composite or normalized commands, e.g. C_Get and N_GET. The composite commands operate on objects that are composed of several real world entities. A normalized object, however, consists of a single real world entity. Each DICOM standard SOP Class is identified with a Unique Identifier (UID). These SOP Class UIDs are issued by NEMA so that they can be used by the software that performs the actual negotiation, as well as to specify which SOP class it represents.

It is critical to match up the UIDs between a sender and receiver, because the description of the SOP Classes can be very similar, such as in the case of the new and old versions of some of the SOP classes. The SOP class UIDs specify precisely which standardized DICOM services and objects are being used.Reference.

Verification SOP Class

The Verification SOP Class consists of the C-ECHO DIMSE-C service. No associated Information Object Definition is defined. The SOP Class UID shall be "1.2.840.10008.1.1". Reference.

Composite Instance

Ref. A Composite Instance is the official DICOM term for a persistent storable object. Whilst most composite instances are Images (with pixel data), DICOM has plenty of other Composite Instance types, such as:


DICOM services use a limited number of basic DICOM operations (officially called DIMSE operations). See this reference for c-get, c-echo, c-move, etc.

Composite operations

Normalized operations

Normalised Operations: These are themselves akin to simple database operations, and are used a "building block" for more complex services such as printing.





Association Rejection

Contexts Rejection

Contexts Rejection happens during the association negotiation but unlike Association Rejection which kills the association, it rejects some or all the Presentation Contexts proposed by SCU, according to the SCP's own rules.

DICOM Modality worklist (MWL)

BlogSpot: dicomIsEasy.

DICOM Modality Worklist is a task manager just like a piece of paper with short text and a check box or the tasks application on your iPhone (or Android). The most obvious benefit WML brings is that there’s no need to reconcile all kind of miss spelled names in the PACS because the patient name is no longer keyed in on the modality workstation but received electronically via the MWL query. The fact that the requested procedure is also received electronically reduces the chance for doing the wrong procedure to the wrong patient. Combined with Modality Performed Procedure step (MPPS), that allows the modality to report the task status, take ownership over the task and checkmark it as done when completed, the up side is obvious.

The most basic abstraction of a task is a short description of what should be done and a checkbox. The MWL data model is a bit more complicated and has two levels.

The top, parent, level is called “Requested Procedure” (RP) and holds the information about the patient (name, id), the study (accession number, study instance UID) and the procedure. The procedure can be described as text using attribute (0032,1060) "Requested Procedure Description" or in a more sophisticated manner using the (0032,1064) "Requested Procedure Code Sequence" where static tables of codes and meanings can be used to configure and maintain procedures in the RIS or HIS.

The child level is called "Scheduled Procedure Step" (SPS) and holds attributes relevant to the modality and the actual procedure to be made. A single requested procedure may hold more than one SPS if the request is for a multi-modality study, for example a chest X-Ray and a CT or whatever combination, or if for example two protocols should be applied (e.g. Chest and Abdomen). As a modality, we will use the data in the RP to identify the patient and eliminate re-typing of the name and ID and the SPS to determine what exactly to do.

The DICOM images that the modality will create should use the attributes received from the MWL. When MWL is implemented, the Study Instance UID is generated in the RIS so if a multi-modality procedure is done, each modality will create a series and attach it to the Study by using the Study Instance UID received in the MWL query.

1. An order is made for an imaging service, let’s say for example a chest X-Ray. The order can be made in various ways. For example it can arrive as a HL7 message from the HIS (Hospital Information System), or it can be that the patient walks in an the order is made at the reception desk.
2. The order is scheduled and assigned to the X-Ray machine or Room that will perform the exam. If there are many X-Ray machines, the order may be assigned to one of them. The assignment is made by setting the AE title on the order and setting a date. The exact way it is done, is very much the business of the worklist manager implementation. DICOM only defines the data model entities. The relevant entity for this is scheduled procedure step. It’s an abstraction of a task with description of what should be done, when it should be done and who should do it.
3. When the X-Ray machine makes a modality worklist query, it gets the list of scheduled tasks and performs them.


Entity and Relation. In a Object-Oriented world, entity and relation are self-explained. For example, a patient and an image series are both entities, and a patient and his/her own image series are related. In a DICOM diagram, a square box is used to represent an entity while a rhombus box is used to represent a relation.
Object. An object has its own attributes and methods. It is capsulated and can be inherited.
Information Object Definition (IOD) is an abstraction of the information entity. It is what the dicom commands work on.
Service. The functions provided by an object.
Service Object Pair (SOP) is the basic element in DICOM communication, it contains Information Object D (IOD) and (DIMSE).

Free UID

This website claims to provide free UID for both software implementations and for image and other objects. The medical connections is a UK based corp.


What is DICOMDIR? Don't confuse it with the directory containing your dcm files, or with the multi-frame dcm file. It is just a file in the root directory in standard DICOM CD/DVD, recording the paths of dicom files on the media.


Another ref. Ref.

Dicom tag values

Element types

PN, Person Name

Explain the ^ in DOE^JOHN. Elements of type PN (VR - Value Representation, remember) i.e. that their value represent a Person Name follow a notation shared by DICOM and HL7. The ^ is called component separator and it separates the elements of the Person Name which are by order: Family Name^Given Name^Middle Name^Prefix^Suffix. Here are some examples:

Usain Bolt would be “BOLT^USAIN”
President Barak Hussein Obama II would be “Obama^Barak^Hussein^President^II”


The groups are organized as follows:

0000 Command
0008 Identifying
0010 Patient
0018 Acquisition
0020 Relationship
0028 Image Presentation
4000 Text
6000-601E (even) Overlay
7FE0 Pixel Data


Tag Name VR (value representation)
0008, 0052 QueryRetrieveLevel CS (code string, 16 bytes maximum.). Example: study
0010, 0010 PatientName PN (person name, 64 bytes maximum.).
0010, 0020 PatientID LO (long string, 64 bytes maximum.).
0020, 000D StudyInstanceUID UI (unique identifier, 64 bytes max).
0020, 000E SeriesInstanceUID UI (unique identifier, 64 bytes max).
0008, 9205 PixelPresentation COLOR: Image better displayed in color with palette LUT, but displayed in grayscale is also a fallback choice.
MONOCHROME: Image better displayed in grayscale. No palette LUT is supplied.
MIXED: Used only in enhanced CT/MR image module.
TRUECOLOR:. Image should be displayed in color only.
0028, 0002 SamplesPerPixel US (unsigned short).
0028, 0004 PhotometricInterpretation CS ().
MONOCHROME2: grayscale, and 0 is black.
MONOCHROME1: grayscale, and 0 is white. Such as in fluoroscopic images.
YBR_FULL. YBR_FULL_422. YCbCr color space used in JPEG.
0028, 0006 PlanarConfiguration US.
0: color interlaced, e.g. the data is arranged pixel-wise and then channel-wise. It is default way.
1: color separated, e.g. the data is arranged in color-planes. It is rare but used in RLE compression.
0028, 0008 NumberOfFrames IS.
0028, 0010 Rows US (unsigned short).
0028, 0011 Columns US (unsigned short).
0028, 0100 BitsAllocated US.
0028, 0101 BitsStored US. In some CT, its pixel value is between 0 and 4096, and only 12 bits are enough. The remaining 4 bits may be used for overlay.
0028, 0102 HighBit US.
0028, 0103 PixelRepresentation 0: unsigned. 1: signed.
0028, 1050 WindowCenter DS.
0028, 1051 WindowWidth DS.
0028, 1052 RescaleIntercept DS.
0028, 1053 RescaleSlope DS.
0028, 2110 LossyImageCompression CS.
0028, 2112 LossyImageCompressionRatio DS.
0028, 2114 LossyImageCompressionMethod CS.
7FE0, 0010 PixelData The pixel data.

A dicom image has a raw data of byte size: ROWS * COLUMNS * NUMBER_OF_FRAMES * SAMPLES_PER_PIXEL * (BITS_ALLOCATED/8). see reference.

Here are some good references:


DICOM UID encoding rules are defined as follows: Another good reference introducing UID:


Free online dicom server:

Multi-frame DICOM

DICOM-CD forum.

A multi-frame DICOM file with DCM_NumberOfFrames set to 150 frames and DCM_FrameTime set to 20 milliseconds. It's expected to see a playback at 50 FPS which is about 3 second in length.


Good datasets

Testing tools


Pass BodyParts in DICOM worklist 关于worklist传递部位的一点收获分享以及疑问.

Difference between Acquisition Number (0020,0012) and Instance Number (0020,0013)?

Usually we use Instance Number to decide the Instance order in a series. Acquisition Number is just a fallback, at least in eFilm. See Reference.

How to keep DICOMs on server

Reference. You may choose whatever you want for these values, but the Series Number should correspond to the specific Series (identified by the Series Instance UID) and should be unique inside the Study (identified by the Study Instance UID) which is containing the series.

Consequently, the Instance Number should correspond to the specific Instance (identified by the SOP Instance UID) and should be unique inside the specific Series (identified by the Series Instance UID).

I hope this makes it clearer.

If your application is working on a Study and generates a Series that should be displayed first, assign the first Series Number to it, e. g. "1". The Image to be displayed first in the Series (e. g. topmost of the Image Stack) should be assigned the first Instance Number, e. g. "1".

Then the next Series may be numbered "2" and has also Instances in there Numbered "1", "2", ... - I hope you get it, please come back to me if you did not.



Overlay Type







Attribute Name Tag Type Attribute Description
MR Diffusion Sequence (0018,9117) 1 Identifies the diffusion parameters of this frame. Only a single Item shall be included in this sequence.
>Diffusion b-value (0018,9087) 1C Diffusion sensitization factor in sec/mm2. This is the actual b-value for original frames and those derived from frames with the same b-value, or the most representative b-value when derived from images with different b-values. Required if Frame Type (0008,9007) Value 1 of this frame is ORIGINAL. May be present otherwise.
>Diffusion Directionality (0018,9075) 1C Specifies whether diffusion conditions for the frame are directional, or isotropic with respect to direction.
Defined Terms:
To be used when Frame Type (0008,9007) value 4 equals DIFFUSION_ANISO or Diffusion b-value (0018,9087) is 0 (zero).
Required if Frame Type (0008,9007) Value 1 of this frame is ORIGINAL. May be present otherwise.
>Diffusion Gradient Direction Sequence (0018,9076) 1C Sequence containing orientations of all diffusion sensitization gradients that were applied during the acquisition of this frame. Only a single Item shall be included in this sequence. Required if Diffusion Directionality (0018,9075) equals DIRECTIONAL May be present if Diffusion Directionality (0018,9075) equals BMATRIX.
>>Diffusion Gradient Orientation (0018,9089) 1C The direction cosines of the diffusion gradient vector with respect to the patient Required if Frame Type (0008,9007) Value 1 of this frame is ORIGINAL. May be present otherwise.
>Diffusion b-matrix Sequence (0018,9601) 1C The directional diffusion sensitization expressed as a 3x3 matrix with diagonal symmetry (with six unique elements from which the other elements can be derived). The rows and columns of the matrix are the X (right to left), Y (anterior to posterior) and Z (foot to head) patient-relative orthogonal axes as defined in Section C. The values are in units of ms/mm2. Only a single Item shall be included in this sequence. Required if Diffusion Directionality (0018,9075) equals BMATRIX.
>>Diffusion b-value XX (0018,9602) 1 The value of b[X,X].
>>Diffusion b-value XY (0018,9603) 1 The value of b[X,Y].
>>Diffusion b-value XZ (0018,9604) 1 The value of b[X,Z].
>>Diffusion b-value YY (0018,9605) 1 The value of b[Y,Y].
>>Diffusion b-value YZ (0018,9606) 1 The value of b[Y,Z].
>>Diffusion b-value ZZ (0018,9607) 1 The value of b[Z,Z].
>Diffusion Anisotropy Type (0018,9147) 1C Class of diffusion anisotropy calculation.
Required if Frame Type (0008,9007) value 4 equals DIFFUSION_ANISO.



Dicom Communications

Roles in C-Get

This discussion in DCMTK forum said:

The default role means that the association requestor is the SCU and the association acceptor is the SCP. For a successful C-Get operation, the c-store operations must reverse the roles. So, your getscu should propose SCP role for MR image storage. If you are using the last snapshot, you will find the function addPresentationContext() in DCMSCU class that takes the role of the SOP class as a parameter.

You can find explanation for role selection negotiation in PS 3.7 D.3.3.4. For C-Get operation look at PS 3.4.

Therefore, in DCMTK, we have

for (Uint16 i = 0; i < numberOfDcmLongSCUStorageSOPClassUIDs; i++) {

Query and Retrieve

There are three Query/Retrieve Information Models:

There are four levels:

For example, the patient level is the top level and contains Attributes associated with the Patient Information Entity (IE) of the Composite IODs as defined in PS 3.3. Patients IEs are modality independent.

The Study Root Query/Retrieve Information Model is identical to the Patient Root Query/Retrieve Information Model except the top level is the study level. Attributes of patients are considered to be Attributes of studies.

The previous is referenced from

Web service


// Query request.
<DICOM:FindMove xmlns:DICOM="">
        <Attribute Tag="00100010">FEROVIX</Attribute>
        <Attribute Tag="00080050">1210490</Attribute>
        <Attribute Tag="00080054"/>

// a DICOM C-FIND results message with the SOAP response envelope removed:
<DICOM:Results xmlns:DICOM="">
        <Attribute Tag="00080005" VR="CS">ISO_IR 100</Attribute>
        <Attribute Tag="00080016" VR="UI">1.2.840.10008.</Attribute>
        <Attribute Tag="00080018" VR="UI"></Attribute>
        <Attribute Tag="00080052" VR="CS">IMAGE</Attribute>
        <Attribute Tag="00080054" VR="AE">PACS</Attribute>
        <Attribute Tag="00080056" VR="CS">ONLINE</Attribute>
        <Attribute Tag="0020000D" VR="UI"></Attribute>
        <Attribute Tag="0020000E" VR="UI"></Attribute>
        <Attribute Tag="00200013" VR="IS">188</Attribute>
        <Attribute Tag="00880130" VR="SH"/>
        <Attribute Tag="00880140" VR="UI"/>

// C-MOVE request messages are set up exactly the same as C-FIND request messages. The only difference is the inclusion of a MoveDestination element in the XML query message.
// C-MOVE request:
<DICOM:FindMove xmlns:DICOM="">
        <Attribute Tag="PatientID">fWT0KTL</Attribute>
        <Attribute Tag="AccessionNumber">1210490</Attribute>

A Composite IOD is an Information Object Definition which represents parts of several entities included in the DICOM Model of the Real-World. Such an IOD includes Attributes which are not inherent in the Real-World Object that the IOD represents but rather are inherent in related Real-World Objects.

The following conventions are used to define the types of keys used in Query/Retrieve Information Models.

Symbol		Description
U		Unique Key Attribute
R		Required Key Attribute
O		Optional Key Attribute

# 0008,0052=SERIES must be capitalized!
# Since specifying SeriesIUID, so the Q/R level 0008,0052 is series but not study or patient.
# I encountered "Identifier does not match SOP Class", and found out it was beause of the previous two reasons.
# You have to configure at your DCM4CHEE to add the ae: movescu yourIP 5004.
movescu -d -P -k 0008,0052=SERIES -k PatientID=patID -k StudyInstanceUID=StudyIUID -k SeriesInstanceUID=SeriesIUID -aec DCM4CHEE -aem movescu --port pacsPort pacsIP 11112
Note: DCMTK findscu accepts four strings for 0008,0052: PATIENT, STUDY, SERIES, IMAGE.

Reference: C-MOVE Service Parameters.

How to get the number of instances? is a good reference.

Note that:

Attribute Name Tag Attribute Description
Number of Patient Related Studies (0020,1200) The number of studies that match the Patient level Query/Retrieve search criteria
Number of Patient Related Series (0020,1202) The number of series that match the Patient level Query/Retrieve search criteria
Number of Patient Related Instances (0020,1204) The number of composite object instances that match the Patient level Query/Retrieve search criteria
Number of Study Related Series (0020,1206) The number of series that match the Study level Query/Retrieve search criteria
Number of Study Related Instances (0020,1208) The number of composite object instances that match the Study level Query/Retrieve search criteria
Number of Series Related Instances (0020,1209) The number of composite object instances in a Series that match the Series level Query/Retrieve search criteria
SOP Classes in Study (0008,0062) The SOP Classes contained in the Study.

The following shows how to use findscu to do queries.

# STUDY: Find studyDate, studyTime, studyIUID.

findscu -P -k PatientID=7100297871 -k 0008,0052=STUDY -k StudyInstanceUID="" -k StudyDate="" -k StudyTime="" -aec DCM4CHEE 11112 2>&1 | tr -d '[]()\000' | grep -e "StudyInstanceUID\|StudyDate\|StudyTime" | cut -d ' ' -f4

# SERIES: Modality, SeriesIUID, NumberOfSeriesRelatedInstances.

findscu -S -k 0008,0052=SERIES -k StudyInstanceUID="1.2.840.113704.1.111.976.1398840889.1" -k SeriesInstanceUID="" -k 0020,1209="" -k Modality="" -aec DCM4CHEE 11112 2>&1 | tr -d '[]()\000' | grep -e "SeriesInstanceUID\|Modality\|NumberOfSeriesRelatedInstances" | cut -d' ' -f4

Retrieving the "Modality" in a C-FIND


Find related DCM tags

Go to dicomtags website, type search keywords in "Search by Description: Tag Description" box. For example, if you want to search Modality-related tags, type "modalit". Don't use the full spelled "modality", since you may miss the plural form "modalities", for example "ModalitiesInStudy".

How to check whether PACS support c-get?

With getscu -d, info like the following shows c-get is not supported:
D: Presentation Contexts: 
D:   Context ID:        1 (Abstract Syntax Not Supported) 
D:     Abstract Syntax: =GETPatientRootQueryRetrieveInformationModel 
D:     Proposed SCP/SCU Role: Default 
D:     Accepted SCP/SCU Role: Default


ITK mhd says RAI for FFS images?

I was severely confused by this, before I re-read the following paragraphs from this kitware page:

The InsightSNAP tool in InsightApplications (which has a great IO loader by the way), uses the following: When it says LPS it means the x axis is RUNNING FROM left to right, the y axis is running from Posterior to Anterior, the z axis is running from Superior to Inferior.
This is exactly the same as what DICOM means when it says RAI.

Now it is clear now: When DICOM says LPS, it means the direction the axises point to; while MHD syas RAI in AnatomicalOrientation, it means the direction the axises run from. In short, the MHD AnatomicalOrientation is always flipped in all dimensions when compared to DICOM patientPosition. Nevertheless, the TransformMatrix in MHD is conformant.


Weasis is a multipurpose web-based DICOM viewer with a highly modular architecture. Weasis can be easily connect to any PACS supporting WADO via a web portal or as an XDS-I consumer in an IHE (Integrating the Healthcare Enterprise) environment. Reference.