accessing data in dicom files -凯发k8网页登录

the dicom (digital imaging and communication in medicine) format describes how to compose messages to send between imaging modalities (e.g., computed tomography (ct), magnetic resonance (mr), and ultrasound devices) and defines a set of operations for transmitting them across a network. these messages can also be written to files for offline storage on a picture archiving system, cd, or other type of storage device. dicom-formatted messages combine images and metadata to create a rich description of a medical imaging procedure. this format is extremely detailed, with a specification that is more than 2,500 pages long.

matlab and the image processing toolbox provide easy access to dicom data. accessing data in dicom files becomes as easy as working with tiff or jpeg images. this article presents examples of using dicom and provides background information about the format.

before dicom: chaos

dicom has significantly improved communication between medical devices and lowered the cost and complexity of integrating hardware and software solutions. before dicom, each manufacturer used proprietary image formats and communications protocols to connect their hardware solutions with third-party products. integrating medical hardware and software from different vendors meant translating from one vendor's protocols to another's. this process was chaotic and fraught with difficulty. a cottage industry developed to provide data translation services.

with the advent of dicom as a formal standard in 1993, one protocol replaced many protocols and formats. dicom is the common format, easing integration of solutions from different vendors. for example, it is possible to integrate a mr scanner from ge medical systems with a picture archive system (pacs) from agfa and another vendor's film printer without using translation devices. integration isn't limited to just hardware. software such as matlab that supports dicom can share images with all of these devices, provided that each of the hardware devices has implemented the necessary dicom services.

a simple first example

in medical imaging, a patient is subject to an imaging study, which may contain multiple series of images. each series is performed on a single modality such as an mr, ct, or x-ray device and can have multiple related images. suppose that we have a study consisting of a series of 20 transverse mri brain images and we want to read them into matlab. (these 20 images are stored in 20 dicom files with names such as brain_017.dcm, which you can download from if you want to run the examples.) let's suppose we know that each image is 256-by-256 and contains signed 16-bit data. we can read the series with the following code:

% preallocate the 256-by-256-by-1-by-20 image array.
x = repmat(int16(0), [256 256 1 20]);

% read the series of images.
 for p=1:20
   filename = sprintf('brain_d.dcm', p);
   x(:,:,1,p) = dicomread(filename);
end

% display the image stack.
montage(x,[])

after running this code, the matlab workspace contains a 4-d array with the image data, and a plot of the mr slices appears.

you can use matlab and the image processing toolbox to perform multiple tasks with this data. for example, matlab provides sophisticated volume visualization techniques to reconstruct a 3-d surface from these slices and then apply surface and lighting effects. the example in the help section for the isocaps function shows this implemented. the imtransform and tformarray functions in the image processing toolbox make it easy to extract slices in different orientations from the transverse data. for example, the "" example shows how to extract saggital slices from a similar dataset. you can also use the morphology functions within the image processing toolbox to perform operations such as image segmentation, feature extraction, and image statistics. alternatively, you can write your own functions to perform volume estimation, shrinkwrapping, etc.

accessing dicom metadata

in the previous example, we made several assumptions as we preallocated the storage array. all of these assumptions were based on metadata that exists in the dicom file. furthermore, the values of the image pixels are limited to a narrow band in the total possible dynamic range of the image, so we had to pass an empty array as a special argument to montage to rescale the data. let's use the metadata attributes in the dicom files to (1) intelligently preallocate our array and (2) rescale the data values to fill the 16-bit dynamic range.

because all images in a series must have the same dimensions and bit-depth, we only need to get the metadata from one image in the series to preallocate the array. the image processing toolbox function dicominfo returns the metadata from a dicom file.

as you can see, there are many metadata values, or attributes. the values for "rows," "columns," and "bitsstored" tell us exactly what we need to know, and we can rewrite the code that reads the image stack.

nrows = info.rows;
ncols = info.columns;
nplanes = info.samplesperpixel;
nframes = 20; % the number of files in the directory

x = repmat(int16(0), [nrows, ncols, nplanes, nframes]);

for p = 1:nframes
  fname = sprintf('brain_d.dcm', p);
  x(:,:,:,p) = dicomread(fname);
end

we still have to take for granted that the image contains signed data&msdash;a "pixelrepresentation" value of "1" indicates that type of data-but the rest of the information that we need is easily obtained. we can use this metadata along with the imlincomb function in the image processing toolbox to rescale the image data to fill the entire 16-bit dynamic range. the linear combination to rescale the grayscale values is "y = (x - b) * m", where b is the minimum x value and m is a constant ratio derived from the input and output ranges.

% keep track of the minimum and maximum pixel values.
minpixels = repmat(0, [1, nframes]);
maxpixels = repmat(0, [1, nframes]);

for p = 1:nframes
  fname = sprintf('brain_d.dcm', p);
  info = dicominfo(fname);
  minpixels(p) = info.smallestimagepixelvalue;
  maxpixels(p) = info.largestimagepixelvalue;
end

% rescale image to start at 0.
b = min(minpixels);
m = 2^16/(max(maxpixels) - b);
y = imlincomb(m, x, -(m * b), 'uint16');

details about dicom metadata

as shown in the previous example, a typical dicom file contains numerous attributes. the reason for this is that dicom messages encapsulate all of the information about a medical imaging procedure, including details about the patient, study, imaging modality, and image series in addition to the image frame stored in the file. together, all of these attributes comprise an information object.

the dicom specification contains numerous information object definitions (iods), such as mr image, ultrasound multiframe image, and radiotherapy plan. the dicom files in the examples above contain mr image information objects. dicomread understands most iods that are listed in the dicom specification.

iods are defined in terms of smaller functional units, or modules, which correspond to specific real-world objects, such as patients, imaging equipment, etc. the hundred-or-so modules in dicom describe everything that could be combined to make a dicom information object. for example, the following table lists the modules that constitute an mr image iod:

modules in the mr image iod:

module description patient details about the patient general study general information about the study, a set of imaging procedures patient study (u) information about the patient at the time of the study general series general information about one particular imaging procedure frame of reference information to spatially relate images in a series general equipment general information about the image modality that produced the series general image details that identify and describe an image within the series image plane slice thickness/location/spacing and other orientation details image pixel the actual image pixels and information on how to interpret them contrast/bolus (c) details about medication given at the time of imaging mr image values specific to magnetic resonance imaging overlay plane (u) graphics or bitmapped text to display with a particular image voi lut (u) information to transform the contrast or intensity of the image sop common date/time of message creation and other generic dicom details

some modules, such as patient, general study, general equipment, and image pixel, are found in many iods. other modules appear only in specific iods. the mr image module, for example, is only part of the mr image iod.

the iod contains modules that describe the patient, study, series, and images for a particular medical imaging procedure. also, notice that some modules have a "(c)" or "(u)" near their name, which means that for this iod they are "conditionally required" or "user optional" modules; the conditional and user optional modules may or may not appear in every mr image iod. for example, the contrast/bolus module will only appear if medication is given at the time of imaging, and the voi lut module does not have to be implemented by the device that writes the dicom file.

all of the modules and attributes are defined in ps 3.3 of the dicom specification, which are available online from the . additionally, all of the defined attributes are listed in a data dictionary. vendors sometimes define private attributes that are specific to their hardware. while you do not need to do anything special to read private attributes with dicomread or dicominfo, if you want to provide additional information about attributes that are not part of the dicom specification, you can provide your own data dictionary.

writing dicom files

we will now create a new dicom file. writing a new file requires an image and metadata. we created a new image with the scaled data in one of the examples above, and dicomwrite and dicominfo will help us create the metadata we need.

to write a dicom file, simply use dicomwrite in the image processing toolbox. currently, this function supports creating secondary capture (sc) image iods, which contain all of the pixel data and metadata necessary for correctly interpreting the image. essentially, an sc image is similar to what you would generate with a framegrabber, or if you had generated the image yourself from scratch or from another image (as in the example above). metadata about the patient, image, and study will be present, but information about the original hardware that produced the image will not.

to write the tenth frame of the scaled image using default metadata to a new file, use dicomwrite with its basic syntax:

frame = y(:,:,:,10);
filename = 'brain_scaled_10.dcm';
dicomwrite(frame, filename)

in this example, dicomwrite infers the metadata that is required, filling in blank values where appropriate. to override default values, provide dicomwrite with a structure containing attributes:

info = dicominfo('brain_001.dcm');
dicomwrite(frame, filename, info)

dicomwrite picks the values that apply to the secondary capture iod and ignores the rest. when dicomwrite makes a new file, it is actually performing two operations. first, it creates a secondary capture information object. then it encodes the information object's attributes, turning them into a stream of bytes that are written to the output file. this last step demonstrates the dicom concept of services.

a service provides a set of concrete actions to perform on objects. common services include storage, print management, verification, and query/retrieve. when dealing with network messages, services are implemented by adding extra attributes to the message and then sending a series of instructions to the receiving machine or application, which deciphers the extra attributes to figure out what to do with the message. when working with dicom files, the attributes are added to the file, and writing or reading the file replaces the transfer of instructions.

writing a file containing dicom data is very much like performing the storage service. essentially, the iod's attributes plus those for the storage service are combined and "frozen" when written to disk. reading the file "thaws" the iod and service attributes, and the entire context of what to do with the information is preserved.

encoding rules found in the dicom standard provide the algorithm for transforming attributes into a series of bytes to be transmitted or stored. different byte-ordering schemes can be used during encoding, and image pixels can be compressed using numerous techniques, such as jpeg or run-length encoding. in the calls to dicomwrite above, the files are encoded using so-called "implicit vr, little endian" style, and the pixels are not compressed.

working together

a host of transfer syntaxes unambiguously define how to decode a dicom message. one of these transfer syntaxes appears at the beginning of a dicom network transmission or at the start of a dicom file. if both the sender/writer and receiver/reader support the same transfer syntax, communication proceeds. otherwise, communication fails. the dicom features in matlab and the image processing toolbox support the most commonly used transfer syntaxes.

with all of these possibilities-iods, optional modules, services, and transfer syntaxes-it can be difficult to know exactly how well two modalities will interact. implementing a service requires knowing which attributes to send or receive. furthermore, making the service useful frequently requires knowing what kind of data to put into attributes and verifying that the information is correct. consequently, few manufacturers support the full set of "service-object pairs" that are possible in dicom. in addition, different applications support different transfer syntaxes.

fortunately, every application that implements part of dicom should know what it supports. manufacturers publish the information about the services, iods, and transfer syntaxes that they support in dicom conformance statements. by comparing statements from two different vendors, you can identify whether the two applications can share information.

limitless possibilities with dicom

dicom makes it easy to acquire and put medical images into a file. it is becoming more prevalent in the medical field.

many medical device manufacturers and software manufacturers are adding dicom to just about any product that can work with medical images and data.

using matlab with the image processing toolbox provides easy access to medical images, modality metadata, and patient information within dicom files. they also provide numerical and image processing algorithms, gui-building tools, and visualization techniques. with matlab, the image processing toolbox, and dicom it is possible to quickly view medical images, design and test new modalities, and create gui-driven medical image analysis systems.