Printable View
Hello,
We acquire radiology images and have the need to extract measurements
from them. These measurements are overlaid onto the bitmap image of the
DICOM file. However, when I try to see if these values are embedded
anywhere in the DICOM, I cannot find them. I have used DICOM
Inspector.NET. Is there any other utilities out there that will show
all DICOM tags and identifiers?
Thanks in advance
Mike McWhinney
elja, Inc.
eljainc wrote:[color=blue]
> Hello,
>
> We acquire radiology images and have the need to extract measurements
> from them. These measurements are overlaid onto the bitmap image of the
> DICOM file. However, when I try to see if these values are embedded
> anywhere in the DICOM, I cannot find them. I have used DICOM
> Inspector.NET. Is there any other utilities out there that will show
> all DICOM tags and identifiers?
>
> Thanks in advance
>
> Mike McWhinney
> elja, Inc.[/color]
There are multiple different DICOM tag editors/dumpers. That will allow
you to see this information if it is there and readily accessible. One
of them them is in the Oldenburg OFFIS DICOM Tookit DCMTK: dcmdump. See
[url]http://dicom.offis.de/dcmtk.php.en[/url]
However, what you see presented in a DICOM viewing application is not
neccessarily fully encoded entirely (or only in) the standard DICOM
tags included in the image.
Some/many PACS vendors encode measurements in private data elements
which most standards based tag dumpers will simply dump as hex values.
Others don't even put them in the image at all but instead just keep
them in their application database. Where they have been encoded as
private data elements, the reason the tag dumpers won't show the
information is the data type and or structure of the information in
private tags is by its nature, private. Private tags are indicated by
tags with odd-valued group numbers (the first four digits of the 8-hex
digit dicom attribute tag).
Measurement information can also be encoded into standard DICOM
elements in several ways. In some cases the modality will actually
"burn" the infromation into the pixel values. In other cases it can be
coded into the upper, unused bits of the pixel data bytes. Burned in
data is usually pretty obivous since it obscures the underlying pixel
data and cannot be toggled off. Overlay data is also usually pretty
obvious because , although it can be toggled off, it is clearly raster
information which "blows up" when the image is zoomed.
Another way in which measurement data can be encoded that is both a
vector graphic form and readable is as graphic annotation sequence.
These sequences can either be embedded in the image itself (discouraged
but is done, especially when measurement is performed on the modality)
or the annotation maybe embedded in a separate Presentation State
object, which references the annotated image --i.e. it is a stand alone
DICOM object containing, among other things, a graphic annotation
sequence and pointer to image which has been annotated and the location
of the annotation in the image. The association between the
presentation state object and image is encoded in the DICOM tag data
and is read by the viewing application which has received both objects.
The viewing application, through its internal logic, renders the
annotation on the image pixels. So, while you could find the annotation
data, you would have to retrace that same process the viewing
application used: find the image file, identify the presentation state
object which references it, then parse/dump the presentation state
object to find the graphic annotations (assuming this technique has
been used).
Yet another way measurements can be encoded are in DICOM structured
reports, again through a reference to the image, and an encoded
description of the measurement.
I mention this latter approach because of the limitations of the
presentation state graphic annotation encoding. It is intended to
encode presentation oriented data --ie. data indicating "Draw a line
from Pixel (x1,y1) to pixel (x2,y2)" or "draw a circle with 23 pixel
radius centered on (x3,y3)" and "draw text '4 mm'" at pixel (x4,y4),
etc. It does not encode information which says "4 mm length
measurement" or "4 mm diameter mass" at some specified location. The
graphic annotation approach does not encode any semantics to the
graphic annotations. Literally, the interpretation is left to the
viewer (person) who sees the graphics as they are rendered in the
image. If you're looking to search for, and digitally extract the
semantics of a measurement in the image, the graphic annotation
sequence isn't going to give it too you. DICOM structured reports do
provide this capability but they tend not to be widely supported where
their measurements are rendered and displayed with the image data
(outside of some relatively narrow domain implementations such as
viewing applications for echocardiography , ultrasound, and
mammography).
This subject has come up previously. David Clunie had mentioned there
was work in progress to add the ability to capture additional semantics
in image annotations. My interpretation of his comment at the time was
for a sort of light-weight , mini-Structured Report construct which
could be embedded into a presentation state object or directly into an
image for that matter. This work may have proceeded and incorporated
into the standard (a lot of things come into the standard under the
radar through DICOM correction proposals). I invite David to comment
on what might have happened with that work, its status in the standard,
and support in existing applications
[email]eric.goodall@gmail.com[/email] wrote:[color=blue]
> I invite David to comment
> on what might have happened with that work, its status in the standard,
> and support in existing applications[/color]
Receiving the agenda for the October Working Group 6 meeting today, I
can answer my own question. The new features for encoding measurements
and other "complex annotations" are part of Supplement 120: Extended
Presentation States. It is being worked in committee and is targeted
for release for Public Comment at the conclusion of the October
meeting.
Here's the current draft:
[url]ftp://medical.nema.org/medical/dicom/supps/sup120_08.pdf[/url]