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.