I have a DICOM image that I am reading using C# and converting it into a 16bit bitmap. The bitmap gets created but the image has DICOM overlays. I want to burn the overlay into the bitmap while creating the final dicom bitmap. I am unable to do that. Any help?
One way would be to create a bitmap of overlay data and merge the 2 bitmaps but I can not get the overlay data as bitmap also. I have captured the binary overlay data but how do I burn into a bitmap?
Thanks
On
There are two types of overlays:
1) Burned-In: is the original one. It uses higher bit(s) of monochrome pixeldata (that are outside of pixel range, for example, when BitsAllocated is 16 and BitsStored is 12, there are 4 unused bits per pixel (bits 12..15), that could be used for overlay. I'm not sure how it's done for signed images.
Note that there is no tag that specifies if an image has such overlay. (there is a tag called Burned In Annnotation (0028,0301), but it means something else).
2) Overlay module: a range of tags (group 0x600xx) is reserved for overlays. Each such group contains several tags along with a bitmap with 1 bit per pixel, where 1 means presence of overlay.
Note that it's not a standard GDI bitmap, lines are not aligned on DWORD boundary! (and I'm not sure if it uses the same bit endianness.)
A DICOM image can have several (up to 16?) such overlays. See part 3 of the standart for exact specifications.
On
Overlay Planes is always 1-bit per pixel where Overlay Bits Allocated is 1 and Overlay Bits Position (60XX, 0102) is always 0. One bit overlay data is encoded separately from Pixel Data element and Overlay Data (60XX, 3000) element is used for storing the data. Value representation for the Overlay data Element is OW. However, OB can be used for explicit VR encoding.
According to PS 3.5 of DICOM standard section 8.1.2, “Overlay Data is encoded as the direct concatenation of the bits of a single Overlay Plane, where the first bit of an Overlay Plane is encoded in the least significant bit, immediately followed by the next bit of the Overlay Plane in the next most significant bit. When the Overlay Data crosses a word boundary in the OW case, or a byte boundary in the OB case, it shall continue to be encoded, least significant bit to most significant bit, in the next word, or byte, respectively”.
The byte ordering of the 2-byte words (VR of OW) is dictated by the Endianness used in the encoding. So there is no padding used at the row boundary and it is encoded from left to right and top to bottom , a row at a time where overlay bit 1 is the first bit of the Overlay Plane (top left pixel).
Formally overlay data was allowed to be embedded in unused bits of Pixel Data (7FE0, 0010) and Overlay Bit Position (60XX, 0102) was used to indicate the unused bit in the pixel data in which overlay data was stored. In this type of encoding, Overlay Bits Allocated (60XX, 0100) should have the same value as Bits Allocated (0028, 0100) attributes of Image Pixel module. The value of Overlay Bits Allocated greater than 1 is the indication that overlay data is embedded in the pixel data.
Even group (6000-601F, eeee) is used for Overlay Planes encoding and a dataset can have maximum of 16 overlays per image.
The DICOM overlay is simply a bitmap mask. When rendering the image, I would suggest just traversing through the pixels, and in the case where the setting the pixel to white.
In the case of grayscale images, you'd have to check the photometric interpretation to see if it is MONOCHROME1 or MONOCHROME2. You would then have to check the bits allocated to see what the maximum pixel value is, and force the pixel values that have the overlay set to that value int he case of a MONOCHROME1 image. In the case of a MONOCHROME2 image, you'd have to set the pixels with the overlay enabled to the minimum pixel value.
In the case of a color image, you could change the pixel to a specific color, or to white if necessary to get the overlay to display.