DICOM图像浏览器

Image Viewer using Digital Imaging and Communications in
Medicine (DICOM)
Trupti N. Baraskar
Department of Information Technology, Maharashtra Institute of Technology, Pune University, Maharashtra, India Email: trupti_001@, baraskartn@
Mobile No. +91-9922789956, +91-20-25462867
Abstract- Digital Imaging and Communications in Medicine is a standard for handling, storing, printing, and transmitting information in medical imaging. The National Electrical Manufacturers Association holds the copyright to this standard. It was developed by the DICOM Standards committee. The other image viewers cannot collectively store the image details as well as the patient's information. So the image may get separated from the details, but DICOM file format stores the patient's information and the image details. Main objective is to develop a DICOM image viewer. The image viewer will open .dcm i.e. DICOM image file and also will have additional features such as zoom in, zoom out, black and white inverter, magnifier, blur, B/W inverter, horizontal and vertical flipping, sharpening, contrast, brightness and .gif converter are incorporated.
Keyword - Digital Imaging and Communication in Medicine (DICOM), National Electrical Manufacturers Association (NEMA), Information Object Definitions (IOD), Value Representation (VR).
I.Introduction
DICOM stands for Digital Imaging and Communication in Medicine. The DICOM standard addresses the basic connectivity between different imaging devices and also the workflow in a medical imaging department. The DICOM standard was created by the National Electrical Manufacturers Association (NEMA) and it also addresses distribution and viewing of medical images. The standard comprises of 16 parts [1] and it is freely available at the NEMA website: ./dicom.html[2] .Within the innards of the standard are also contained a detailed specification of the file format for images. The latest version of the document is as of 2008[3]. In this article present a viewer for DICOM images DICOM Image File Format
This present a brief description of the DICOM image file format. Like other image file formats, a DICOM file consists of a header, followed by pixel data. The header comprises of the patient name and other patient particulars and image details. Important in the image details are the image dimensions - width, height and image bits per pixel. All these details are hidden inside the DICOM file in the form of tags and their values. Before it gets into tags and values, a brief about DICOM itself and related terminology is in place. In what follows, this explains only those terms and concepts related to a DICOM file. In particular, this does not discuss the communication and network aspects of the DICOM standard. Everything in DICOM is an object - medical device, patient, etc. An object, as in object oriented programming is characterized by attributes. DICOM objects are standardized according to IODs (Information Object Definitions). An IOD is a collection of attributes describing a data object. In other words, an IOD is a data abstraction of a class of similar real world objects which defines the nature and attributes relevant to that class [4]. DICOM has also standardized on the most commonly used attributes and these are listed in the DICOM data dictionary [6]. An application which does not find a needed attribute name in this standardized list may add its own private entry, termed as a private tag; proprietary attributes are therefore possible in DICOM. Examples of attributes are study date, patient name, modality, transfer syntax UID, etc. As it can be seen, the attributes require different data types for correct representation. This “data type” is termed as Value Representation (VR) in DICOM. There are 27 such VRs defined[5], and these are AE, AS, AT, CS, DA, DS, DT, FL, FD, IS, LO, LT, OB, OF, OW, PN,
SH, SL, SQ, SS, ST, TM, UI, UL, UN, US, and UT. For example, DT represents Date Time, a concatenated date time character string in the format YYYYMMDDHHMMSS.FFFFFF&ZZXX. An important characteristic of VR is its length, which should always be even. Characterizing an attribute are its tag, VR, VM (Value Multiplicity) and value. A tag is a 4 byte value which uniquely identifies that attribute. A tag is divided into two parts, the Group Tag and the Element Tag, each of which is of length 2 bytes. For example, the tag 0010 0020 (in hexadecimal) represents Patient ID, with a VR of LO (Long String). In this example, 0010 (hex) is the group tag, and 0020 (hex) is the element tag. The DICOM data dictionary gives a list of all the standardized group and element tags. Also important is to know whether a tag is mandatory or not. For data element type, five categories are defined - Type 1, Type 1C, Type 2, Type 2C, and Type 3. One more important concept is transfer syntax. In simple terms, it tells whether a device can accept the data sent by another device. Each
CP1324,I nt e r nat i onal Conf e r e nc e on M e t hods and M ode l s i n Sc i e nc e and Te c hnol ogy (I CM 2ST-10)
e di t e d by R. B. Pa t e l a nd B. P. Si ngh
© 2010 A m e r i c a n I ns t i t ut e of Phys i c s 978-0-7354-0879-1/10/$30.00
device comes with its own DICOM conformance statement, which lists all transfer syntaxes acceptable
to the device. Transfer syntax tells how the transferred data and messages are encoded. Part [5 ] of the DICOM standard gives the transfer syntax as a set of encoding rules that allow application entities to unambiguously negotiate the encoding techniques (e.g., data element structure[8], byte ordering, compression) they are able to support, thereby allowing these application entities to communicate. (One more term here - Application Entity is the name
of a DICOM device or program used to uniquely identify it.)
Transfer syntaxes for non-compressed images are:
x Implicit VR Little Endian, with UID
1.2.840.10008.1.2
x Explicit VR Little Endian, with UID
1.2.840.10008.1.2.1
x Explicit VR Big Endian, with UID
1.2.840.10008.1.2.2
Images compressed using JPEG Lossy or Lossless compression techniques have their own transfer syntax UIDs. A viewer should be able to identify the transfer syntax and decode the image data accordingly; or display appropriate error messages if it cannot handle it. More points on a DICOM file, it is a binary file, which means that an ASCII-character-based text editor like notepad does not show it properly. A DICOM file may be encoded in Little Endian or Big Endian byte orders. Elements in a DICOM file are always in ascending order of tags. Private tags are always odd numbered. With this background, it is now time to develop into the DICOM File Format. A DICOM file consists of Preamble: comprising of 128 bytes, followed by, Prefix: comprising of the characters 'D', 'I', 'C', 'M', followed by, File Meta Header: This comprises, among others, of the Media SOP Class UID, Media SOP Instance UID, and the transfer syntax UID. By default, these are encoded in explicit VR, Little Endian. The data is to be read and interpreted depending upon the VR type. Data Set comprising of a number of DICOM Elements, characterized by tags and their values. The main functionality of a DICOM Image Reader is to read the different tags as per the transfer syntax and then use these values appropriately. An image viewer needs to read the image attributes - image width, height, bits per pixel and the actual pixel data. The viewer presented here can be used to view DICOM images with non-compressed transfer syntax. Open DICOM files with Explicit VR and Implicit VR Transfer Syntax, read DICOM files where image bit depth is 8 or 16 bits. Read a DICOM file with just one image inside it. Read a DICONDE file (a DICONDE file is a DICOM file with NDE - Non Destructive Evaluation - tags inside it). Display the tags in a DICOM file.
Enable user to save a DICOM image as JPEG/GIF. This viewer is not intended to check whether all mandatory tags are present, open files with VR other than Explicit and Implicit - in particular, not to open JPEG compressed loss and lossless files. To read old DICOM files - requires the preamble and prefix for sure. Earlier DICOM files do not have the preamble and prefix, and just contain the string 1.2.840.10008 somewhere in the beginning. For the viewer, the preamble and prefix are necessary to read images which are not 8 bit or 16 bit in bit depth. In particular not to open color images, to read a sequence of images. Problem:
Other file format used in modern times doesn’t have the facility to obtain the image of the patient and the related details together in the same document thus more storage space is required and difficulties are faced by the user.
Solution:
We can develop a viewer that that displays the patient details and image details in just one click and in just one file thus making it convenient for the end user. It also takes less storage space.
II.Block Diagram Of DICOM File
Structure
Figure 1. Block Diagram of DICOM file format
File Header:
The header consists of a 128 byte File Preamble, followed by a 4 byte DICOM prefix. The header may or may not be included in the file [9].
Preamble Prefix
128 bytes
=??? ???
4 bytes = ‘D’, ‘I’, ‘C’, ‘M’
Table 1: DICOM File Header
The DICOM standard does not require any structure for the fixed size preamble. It is not required to be structured as a DICOM data element with a tag and a length. It is intended to facilitate access to the images
and other data in the DICOM file by providing compatibility with a number of commonly used computer image file formats. If the File preamble is not used by an application profile or a specific implementation, all 128 bytes shall be set to 00H. This is intended to facilitate the recognition that the preamble is used when all 128 bytes are not set as specified above. The file preamble may for example contain information enabling a multi-media application to randomly access images stored in a DICOM data set. The same file can be accessed in two ways: First by a multi-media application using the preamble and second by a DICOM application which ignores the preamble. The four byte DICOM prefix shall contain the character string "DICM" encoded as uppercase characters of the ISO 8859 G0 Character Repertoire. This four byte prefix is not structured as a DICOM data element with a tag and a length.
Sample output:
Figure 2. Image view at DICOM file format
Data Set:
Data Element: A unit of information as defined by a single entry in the data dictionary [6]. An encoded Information Object Definition (IOD) attribute that is composed at a minimum three fields: Data Element Tag, Value Length, and Value Field. For some specific transfer syntaxes, a data element also contains a VR field where the value representation of that data element is specified explicitly.
Data Element Tag: A unique identifier for a data element composed of an ordered pair of numbers (a group number followed by an element number).
Data Element Type: Used to specify whether an attribute of an Information Object Definition. This translates to whether a Data Element of a Data Set is mandatory, mandatory only under certain conditions, or optional.
Data Set: Exchanged information consisting of a structured set of Attribute values directly or indirectly related to Information Objects. The value of each Attribute in a Data Set is expressed as a Data Element. A collection of data elements ordered by increasing
data element tag number that is an encoding of the values of attributes of a real world object.
Pixel Data: Graphical data (e.g., images or overlays) of variable pixel-depth encoded in the pixel data element, with value representation OW or OB. Additional descriptor data elements are often used to describe the contents of the pixel data element.
Value Field: The field within a data element that contains the value(s) of that data element.
Value Length: The field within a data element that contains the length of the value field of the data element
Value Representation (VR): Specifies the data type and format of the value(s) contained in the value field of a data element. A data set represents an instance of a real world information object. A data set is constructed of data elements. Data elements contain the encoded values of attributes of that object. The construction, characteristics, and encoding of a data set and its data elements are discussed here.
Data Elements: A Data Element is uniquely identified by a Data Element Tag. The Data Elements in a Data Set shall be ordered by increasing Data Element Tag Number and shall occur at most once in a Data Set. There are 2 types of data element
Standard Data Elements have an even Group Number that is not (0000, eeee), (0002, eeee), (0004, eeee), or (0006, eeee). [5]
Private Data Elements have an odd Group Number that is not (0001, eeee), (0003, eeee), (0005, eeee), (0007, eeee), or (FFFF, eeee).
Although similar or related Data Elements often have the same Group Number; a Data Group does not convey any semantic meaning
Note: A Data Element shall have one of three structures. Two of these structures contain the VR of the Data Element (Explicit VR) but differ in the way their lengths are expressed, while the other structure does not contain the VR (Implicit VR). All three structures contain the Data Element Tag, Value Length and Value for the Data Element. See Figure 2.Implicit and Explicit VR Data Elements shall not coexist in a Data Set and Data Sets nested within it. Whether a Data Set uses Explicit or Implicit VR, among other characteristics, is determined by the negotiated Transfer Syntax
Figure 3. Data set and Data elements structure
Data Element Field:
A data element is made up of fields. Three fields are common to all three data element structures; these are the Data Element Tag, Value Length, and Value Field.
A fourth field, Value Representation is only present in the two Explicit VR Data Element structures. The definitions of the fields are [6]:
Data Element Tag: An ordered pair of 16-bit unsigned integers representing the group number followed by element number.
Value Representation: A two byte character string contains the VR of the data element. The VR for a given data element tag shall be as defined by the data dictionary. The two characters VR shall be encoded using characters from the DICOM default character set.
Value Length:A 16 or 32-bit (dependent on VR and whether VR is explicit or implicit) unsigned integer containing the explicit length of the value field as the number of bytes (even) that make up the value. It does not include the length of the data element tag, value representation, and value length fields.
A 2-bit length field set to undefined length (FFFFFFFFH). Undefined lengths may be used for data elements having the Value Representation (VR) Sequence of Items (SQ) and Unknown (UN). For data elements with value representation OW or O
B undefined length may be used depending n the negotiated transfer syntax.
Value Field: An even number of bytes containing the Value(s) of the Data Element. The data type of value(s) stored in this field is specified by the data element's VR. The VR for a given data element tag can be determined using the data dictionary [6], or using the VR field if it is contained explicitly within the data element. The VR of standard data elements shall agree with those specified in the data dictionary. The value multiplicity specifies how many values with this VR can be placed in the value field. If the VM is greater than one, multiple values shall be delimited within the value field. The VMs of standard data elements are specified in the data dictionary value fields with undefined length are delimited through the use of sequence delimitation items and item delimitation data elements.
RGB Color Model:
A color in the RG
B color model is described by indicating how much of each of the red, green, and blue is included. The color is expressed as an RGB triplet (r, g, b), each component of which can vary from zero to a defined maximum value. If all the components are at zero the result is black; if all are at maximum, the result is the brightest represent able white [11, 12, and 13].These ranges may be quantified in several different ways: From 0 to 1, with any fractional value in between. This representation is used in theoretical analyses, and in systems that use floating-point representations. Each color component value can also be written as a percentage, from 0% to 100%.ting, the component values are often stored as integer numbers in the range 0 to 255, the range that a single 8-bit byte can offer (by encoding 256 distinct values).High-end digital image equipment can deal with the integer range 0 to 65,535 for each primary color, by employing 16-bit words instead of 8-bit bytes. For example, the full intensity red is written in the different RGB notations as given table 2:
Notation RGB triplet
Arithmetic(1.0, 0.0, 0.0) Percentage(100%, 0%, 0%)
Digital 8-bit per channel(255, 0, 0)
Table 2. RGB Notation
In this paper the digital 8-bit model as the input file is in binary for the RGB model and the ASCII code of the color has been used in almost all the algorithms of the features of the DICOM Image Viewer.
III.System Architecture
Description:
Parser: It is the first and the most important part of the project. It separates the data set and the image. The input to parser is .dcm file (i.e. a binary file) which is version 1.3, standardized by NEMA [10]. The output i.e. image and data set is then passed on to next stage. DICOM Header: The header is the part which makes DICOM different from all the other file formats. The header encompasses of patient details and image information like pixel representation, height, width, file data length etc. Thus in this stage we read patient details and image information so that they can be processed further.
Display Details: The Header details which are processed in the above stage are displayed.
Image Processing: In this stage, various features like Zoom In, Zoom Out, Blur, B/W inverter, Horizontal and Vertical flipping, Sharpening, Contrast, Brightness and .gif converter are incorporated. The final processed image in then passed onto the next stage.
DICOM Image Viewer: The final image is displayed in this stage.
IV.
Implementation Images:
Figure 5. Image and Text Viewer
Figure 6. Invert Image
Figure 7. Blur image
Figure 8. White Inverter image
Figure 9. Zoom In Image
Figure 10. Sharpen Image
Figure 11. Flip Horizontal Image
[10]Boqiang Liu, Minghui Zhu, Zhenwang Zhang, Cong
Yin, Zhongguo Liu and Jason Gu* “Medical Image
Conversion with DICOM” IEEE2007
[11]Foley J., A. van Dam, Fejner S. Hughes J., Computer
graphics - principles and practice, Second edition,
Addison-Wesley, 1996
[12]Gonzales R., R. Woods, Digital Image Processing,
Adison Wesley, 1993
[13]Marion A., An Introduction to Image Processing,
Chapman and Hall, 1991
Figure 11. Save Image File
V.Conclusion
The primary aim of this paper is to study “.dcm” file
format and develop an image viewer with some
enhanced features like Zoom, invert, brightness,
sharpen and save image as “.gif” format.
Implementation of algorithms e.g.. blur, horizontal
flipping, vertical flipping black and white inversion
etc. Benefits of the “.dcm” file format and image
viewer provides a greater leap to the present medical
scenario further helps for the future development of
video player for CT scan and MRI. Display the x-ray
image and the patient details together. Converts
“.dcm” file to “.gif” file format. It is cost-effective in
and helpful to health care industry. Because of the
DICOM viewer images can be captured and
communicated more quickly helps physician to
make diagnosis sooner and treatment decision can be
made quickly.
References
[1]Mario Mustra, Kresimir Delac, Mislav Grgic “Overview
of the DICOM Standard” 50th International Symposium
ELMAR-2008, 10-12 September 2008, Zadar, Croatia
[2]The DICOM Standard, /
[3]Digital Imaging and Communications in Medicine
(DICOM), NEMA Publications,"DICOM Standard",
2008, available at:
ftp:///medical/dicom/2008/
[4]National Electrical Manufacturers Association “Digital
Imaging and Communications in Medicine (DICOM)”
Standards Publication PS 3.3-2004, 2009
[5]National Electrical Manufacturers Association “Digital
Imaging and Communications in Medicine (DICOM)”
Standards Publication PS 3.5-2004, 2009
[6]National Electrical Manufacturers Association “Digital
Imaging and Communications in Medicine (DICOM)”
Standards Publication PS 3.6-2004, 2009
[7]National Electrical Manufacturers Association “Digital
Imaging and Communications in Medicine (DICOM)”
Standards Publication PS 3.7-2004, 2009
[8]National Electrical Manufacturers Association “Digital
Imaging and Communications in Medicine (DICOM)”
Standards Publication PS 3.10-2004, 2009
[9] “DICOM file structure.html
Copyright of AIP Conference Proceedings is the property of American Institute of Physics and its content may not be copied or emailed to multiple sites or posted to a listserv without the copyright holder's express written permission. However, users may print, download, or email articles for individual use.。