In the last set of blog posts in this series I talked about
how to deal with communication errors, causes for an image to be Unverified and
header errors. This post will discuss the errors that might occur when trying
to display the images caused by incorrect DICOM header encoding.
When an image is processed for display, it goes through a
series of steps, aka the Pixel pipeline. Think about this pipeline as a
conveyor belt with several stations, each station having a specific task, such
as applying a mask to the image, applying a window/width level, a look up
table, annotations, rotating or zooming the image, etc. These “stations” are
instructed by the information in the DICOM header, or taken from a separate
DICOM file called Presentation State for processing.
There are two categories of problems, the first set of problems
might be due to incorrectly encoded header instructions, and the second
category is the interpretation and processing caused by an incorrect software
implementation. Here are the most common issues:
·
Incorrect
grayscale interpretation and display – Images can be encoded as grayscale
or color. Grayscale images are identified either as MONOCHROME2 in the header,
which means that the lowest pixel value (“0”) is interpreted and displayed as
black, or MONOCHROME1 in which case the maximum pixel value (255 for 8 bits
images) is interpreted as black. Typically, MR and CT are encoded as
MONOCHROME2 and digital radiography MONOCHROME1. However, there is nothing that
prevents a vendor from inverting its data and using a different photometric
interpretation. Anytime an image is displayed inverted instead of in its normal
view, the MONOCHROME1-2 identification is the first place look. I have seen
problems where the software after an upgrade ignored the photometric
interpretation, causing all of CR/DR to be displayed correctly, but inverting
the CT/MR, or displaying the image correctly but the mask or background to be
inverted.
·
Incorrect
color interpretation and display – color images can be encoded in several
different manners, the most common one is using a triplet of Red, Green and
Blue (RGB). However, DICOM allows one to use several others (CMYK, etc.) and
also allows for sending a palette color in the header that the receiving
workstation has to use to map the color scale. Palette color is used if the
sender is very particular about the color, such as in nuclear medicine, unlike
color for ultrasound when it is used to indicate the direction of the blood
(red/blue). Having many different color encodings increases the chance that a
receiver does not display one of those encodings. I have seen this after data
migration where some of the ultrasound images from a particular manufacturer
did not display the color correctly on the new PACS viewer.
·
Failing
to display a Presentation State – The steps in the pipeline dealing with
image presentation (mask, shutters, display and image annotation and image
transformation such as zoom and pan) can be encoded and kept as a separate
DICOM file together with the study containing the images. Not every vendor will
implement all the steps correctly, and I also have seen ones that will only
interpret the first Presentation State and ignore any additional Presentation
States.
·
Incorrect
Pixel interpretation of the Pixel representation – Some modalities, notably
CT, can have negative numbers (Hounsfield units or HU) indicating that a
visualized tissue has an X-ray attenuation less than water, which is calibrated
to be exactly 0 HU. Some modalities will scale all the pixel values, especially
CT and PET. If the software does not interpret it correctly, the image display
will be corrupted.
·
Incorrect
interpretation of non-square pixels – Some modalities, notably US and
C-arms, have “non-square” pixels, meaning that the x and y direction have a
different resolution. The pixels need to be “stretched” through interpolation,
based on the aspect ratio, for example, if the ratio is 5/6, they need to be
extended in the y direction for another 1/6th, which is 16.6%. If
your images look compressed, which you’ll notice by the compressed text or, in
case of a C-arm, you’ll notice that circles become egg-shaped, that indicates the
software does not support non-square pixels. Except for looking kind of
strange, it might not impact image interpretation.
·
Shutters
incorrectly displayed – A shutter can be circular with a defined radius and
center point, or rectangular with defined x,y coordinates, intending to cover
collimated areas, which display as being very white to the radiologist. I have
seen some implementations ignoring the circular shutter, which makes the
radiologist who has to look at the white space very unhappy.
·
Overlay
display issues – Overlays used to be encoded in the PACS database in
proprietary formats, which is a big issue when migrating the data to another
PACS system. And, if encoded in a DICOM defined manner, there are several
options ranging from stand-alone objects, to bitmaps in the DICOM header,
embedded in the pixel data field, or, worst case being burned-in, i.e. replacing
the actual pixels with the overlay. If the overlays contain clinical
information, e.g. a Left/Right indicator on the image, it is important to check
how the overlays are encoded to make sure that when the data is migrated or
read from a CD on another system, the user will be able to see it. The same
applies for “fixing” burned-in annotations; don’t overlay a series of “XXX-es”
in case the name was incorrect, as they might not be displayed in the future.
The best way to get rid of incorrect burned-in annotations is to use an
off-line image editing routine, which functions as a “paintbrush” and
eliminates the pixel data.
The image pixel pipeline facilitates all the different
combinations and permutations of the different pixel encodings, which in
practice might not always be completely or correctly implemented. There is an
IHE profile defined, called “Consistent Presentation of Images,” check your IHE
integration statement of your PACS to determine whether it is supported,
meaning that the software implements a complete pipeline.
In addition, this profile has a detailed test plan and a set
of more than 200 images and corresponding presentation state files that are
available in the public domain and can be accessed from the IHE website under "testtools". I strongly
recommend that after the initial installation and with each subsequent software
upgrade, that you load these images and check to see if the pipeline works.
These test mages have different pixel encodings with the instructions in the
header negating the pixel display, for example, an image might be MONOCHROME1
with an inverted LUT to be applied, displaying the same as if it was MONOCHROME
2 with a regular, linear LUT.
Another good resource is the PACS fundamentals textbook that
explains the pipeline in great detail. The next blog post will be on Modality
Worklist issues.
