Digital Imaging and Communication in Medicine (DICOM)

DICOM (digital imaging and communication in medicine) is the current standard for imaging formats and data transfer for use in medical applications and devices. In 1994, the ACR-NEMA standard (American College of Radiology, National Electrical Manufacturers Association) was transformed into the DICOM standard; the current version is 3.0.

The DICOM 3.0 Standard

Although sometimes only the imaging standard of DICOM is mentioned, DICOM is actually a network protocol based on a client-server architecture. If two members , which is obviously the minimum, participate on a DICOM communication, the client is called SCU (service class user ) and the server SCP (service class provider; Figure 3.44).

Figure 3.44. Simple DICOM Communication

As a first step, the SCU (e.g., a CT scanner) proposes to the SCP a list of services, the SCP (e.g., an imaging console) answers by sending a list of accepted (or possible) services, resulting in an association negotiation .

Modalities

Of course, a CT scanner is only one possibility. All methods used for the generation of medical images are called modalities . DICOM identifies all modalities by 2-letter acronyms; for example, ultrasound : US; computed tomography : CT; magnetic resonance : MR.

As discussed in Chapter 2, the methods of medical image generation are quite different. DICOM accommodates these different methods and defines the contents and the interpretation of the data.

Conformance

Once a medical equipment manufacturer decides to use DICOM, that manufacturer need not implement the entire standard. In a conformance statement, the manufacturer declares which parts of the standard are incorporated in the product. This makes it easier for the customer to understand the capabilities of the product and easier for the technician to estimate the communication possibilities with other products.

Compression

In most cases, DICOM images are not compressed in order not to lose any relevant medical information. On the other hand, DICOM provides possibilities for a number of compression techniques; one of them is JPEG. DICOM calls uncompressed images native and compressed images encapsulated .

DICOM File Format

Naturally, for us the DICOM image file format is of major interest. The following sections describe the most important issues.

Data Elements

The most fundamental block of a DICOM file is a data element (DE), which describes certain DICOM file attributes. In general, each DICOM file consists of a number of data elements and nothing else. DEs themselves can be divided into specific components :

• Tag
• Value representation (VR)
• Value length (VL)
• Value field (Figure 3.45)

Figure 3.45. Structure of a DICOM Data Element

Tags

The tag field identifies the type of information that follows in the value field; it consists of two 16-bit numbers: the Group Number and the Element Number. For example, a DICOM image requires the following group numbers :

• 0008 : examination data;
• 0010 : patient information;
• 0018 : image generation data;
• 0020 : information of image relationship to examination;
• 0028 : image display data;
• 4000 : overlay information;
• 7FE0 : image data.

Table 3.43 shows an example of the data elements of an image header, sorted by their group and element numbers.

As you can see, DICOM offers a lot of properties for the generation, display, and storage of medical images. The DEs are always sorted in ascending order by their tag numbers.

Value Representations (VRs)

VRs are optional 2-character acronyms for the additional description of the data contained in the DE. For example, the tag ( 0010 , 0010 ) has the VR "PN" (patient name ).

Because this information is redundant in combination with tags, VRs need not be present. If a data set does not contain VRs, it is referred to as having implicit VRs. An entire data set can only have either VRs or implicit VRs; it is not possible to mix both types.

Value Lengths (VLs)

The VL in the next field is used for two purposes:

• It gives the number of bytes of the following data field.
• It indicates the number of bytes to be skipped in order to jump to the next data element, which is helpful for a quick parsing of the data set.

The subsequent field, called Data Field or Value Field, contains the actual information of the data element.

Table 3.43. Tags of a DICOM Image Header

Group	Element	Group Description	Element Description
0008	0020	examination data	examination date
0008	0030	examination data	examination time
0010	0010	patient information	patient name
0010	0030	patient information	date of birth
0018	0050	image generation data	slice thickness
0020	0020	image relationship	orientation
0028	0030	image display data	pixel size
0028	1050	image display data	window center
0028	1051	image display data	window width

Nested Data Sets

DICOM can embed data sets within data sets; the unit is called a nested data set or sequence of items (SQ). For example, a DE for modality LuT (look-up table) sequence has the tag ( 0028 , 3000 ) and contains a set of data elements as its data value, all together forming the modality LuT.

Value Multiplicity (VM)

DE could contain more than one data field. This case is expressed in a VM. The value of a VM can be one of three types:

• a specific number (example: zoom factor ( 0028 , 0032 ));
• a maximum number;
• an unlimited number of values (example: other study numbers ( 0020 , 1070 )).

DICOM Image Storing

The pixel data of a DICOM image is stored in a DE and has a tag called Pixel Data ( 7FE0 , 0010 ). It is important to know that DICOM images can store 8 to 16 bits per pixel, compared to the usual 8 bits used in regular file formats. Therefore, an image with 8 bits per pixel stores the data in a single byte per pixel; images with 9 to 16 bits need 2 bytes per pixel. The following three data elements specify how the data is stored:

• Bits allocated ( 0028 , 0100 ): the number of bits for each pixel, which can be only 8 or 16.
• Bits stored ( 0028 , 0101 ): the number of bits containing meaningful image data; for example, 12.
• High bit ( 0028 , 0102 ): gives the position of the most significant bit (MSB); for example, if BS = BA, then HB = BA “ 1.

The Samples per Pixel DE ( 0028 , 0002 ) defines the number of color channels per pixel. Gray-scale images have a value of 1, RGB images of 3.

The Photometric Interpretation DE ( 0028 , 0004 ) stores information about how the pixel data is to be interpreted. The respective code string can be one of the following:

• MONOCHROME1 : gray-scale image with black as the maximum value and white as the minimum.
• MONOCHROME2 : gray-scale image with white as the maximum value and black as the minimum.
• PALETTE COLOR : color image using a color LuT (samples per pixel = 1). The respective tags are:
  • ( 0028 , 1201 ): red,
  • ( 0028 , 1202 ): green,
  • ( 0028 , 1203 ): blue.
• RGB : color image; samples per pixel = 3.
• HSV : color image; samples per pixel = 3.
• ARGB : RGB image with an additional alpha channel containing more image information or overlays; samples per pixel = 4.
• CMYK : color image; samples per pixel = 4.
• YBR_FULL : color image using YC b C r channels; samples per pixel = 3.
• YBR_FULL_422 : same as above with 4:2:2 color sampling.
• YBR_PARTIAL_422 : same as above with Y restricted to 220 levels, C b and C r restricted to 225 levels.

The Planar Configuration DE ( 0028 , 0006 ) specifies the arrangement of the pixels in a color image:

• 000 : pixel by pixel;
• 001 : plane by plane.

Most of this information was taken from the AccuSoft ImageGear Medical Plug-In, 2001 User's Guide , which comes with the respective software.

DICOM Functions in LabVIEW

To use DICOM functions in LabVIEW, you have to install a DICOM SDK, which may be available for free or as evaluation versions from the Internet. I used AccuSoft (www.accusoft.com) DICOM Communication SDK in my exercises; it provides a SDK based on DLL32 and OCX32 as well.

Before you can use the ActiveX controls coming with the SDK, you must import them into LabVIEW. Select Tools/Advanced/Import ActiveX Controls... to open a window that lists all of the ActiveX controls registered on your system (see Figure 3.46). Here, look for DcSdk Control, press OK, and save the control under a specific name. Afterwards, the control appears in the Controls Palette under Custom Controls (Figure 3.47).

Figure 3.46. ActiveX Control Import List

Figure 3.47. Imported ActiveX Control

Exercise 3.4: DICOM Communication.

Verify the importation of the AccuSoft DICOM Communication SDK by using an Invoke Node and select the property VersionCompileDate from the pop-up menu. My version displays "Jan 15 2001" (see Figure 3.48 for further details).

 

Figure 3.48. Verification of the Correct Import of Accusoft DICOM Comm SDK in LabVIEW

Other tools let you work with DICOM images in LabVIEW and IMAQ Vision; unfortunately , they are not available for free. In the following exercise I worked with the Medical Imaging Toolkit, again to be found at www.accusoft.com. An evaluation version of this software works for five days.

After the toolkit is installed, two additional ActiveX controls must be imported into LabVIEW:

• ImageGear ActiveX (ImageGear is a basic toolkit for image processing by AccuSoft) and
• MEDXCtl Class.

With these two additional controls, you can do the following exercise.

Exercise 3.5: Importing DICOM Images (additional software required).

Using Image Gear and Medical Imaging ActiveX controls (or similar controls), build a VI that imports DICOM images into LabVIEW and IMAQ Vision. If the import is successful, all of the image processing and analysis functions of IMAQ Vision can be applied to DICOM images.

Figure 3.49 shows a possible solution. The image is transferred via the clipboard to an IMAQ window; to get the image there, you need both imported ActiveX controls. First of all, ImageGear needs to know that you intend to use the evaluation version of the Medical Imaging Toolkit; on the other hand, the Medical Imaging Toolkit requires the name of the ImageGear software (frame 0 of the sequence in Figure 3.50).

As a second step, load the image into ImageGear and copy it onto the clipboard (frame 1). Be careful, and verify the correct implementation of the Medical Imaging Toolkit (frame 0); otherwise , ImageGear will not load DICOM images.

 

Figure 3.49. Loading DICOM Images into LabVIEW and IMAQ Vision

Figure 3.50. Frames 0 and 1 of Exercise 3.5

The property nodes of frame 0 in Exercise 3.5 can be replaced by the following Visual Basic code in other applications:

Gear.ExtFile = "IGMedx.ocx" Gear.ExtCode = "EVAL" Gear.ExtPass = "PASSWORD" MED1.DestGearControl = "Gear" Gear.LoadImage = "filename.dcm" Gear.ClipboardCopy = TRUE

Image Processing