Why should I subtract my pixel values of dicom image from 2^15 when I'm using dcmtk?

Question

I'm using dcmtk to read dicom images and I have following attribute with the new samples :

(0028,0004) Photometric Interpretation: MONOCHROME2
(0028,0010) Rows: 512
(0028,0011) Columns: 512
(0028,0030) Pixel Spacing: 0.4688\0.4688
(0028,0100) Bits Allocated: 16
(0028,0101) Bits Stored: 16
(0028,0102) High Bit: 15
(0028,0103) Pixel Representation: 1
(0028,0106) Smallest Image Pixel Value: 0
(0028,0107) Largest Image Pixel Value: 2732
(0028,1050) Window Center: 1366
(0028,1051) Window Width: 2732

I use the getOutputData(16) to read int16_t data. It's surprised me, because the values are negative near to -1*(2^16) and when I subtracted the values by 2^15 everything seems ok and I can see the images! :-(

Now I have two questions :

1. Why should I subtract the value 2^15 and it goes ok? There is no padding value available on image!
2. In document of getOutputData, it's speaking about The rendered pixel data is alway unsigned.. What does it means specially when my image data is signed because the (0028,0103) attribute is saying it to me? If this method is not proper, so can I get real data by dcmtk?

Answer 1

I found the answer. It had explained here by good offic developers. See the page 2. It's completely related to DCMTK toolkit.

Answer 2

the DICOM header says that data is stored in DICOM file as a signed value, but it looks like that the documentation says that getOutputData converts it to an unsigned value. so, try reading the output of getOutputData as an uint16_t instead of int16_t.

Answer 3

According to the documentation getOutputData applies the presentation VOI before rendering so you always get unsigned data. So, if you ask for 16 bit data you will get pixels ranging fron 0 to 65535, regardless of the min and max values specified in the dataset; this because the returned data is meant to be displayed, it is not the original data stored in the image. I think you should just right shift the values by 8 bits, or just ask for 8 bit data (even if the image is 16 bits): I don't think that your graphic card can handle 16 bits if grayscale anyway.

Answer 4

Never used dcmtk, but it looks like you have to apply the slope/intercept parameters of the modality VOI in order to obtain the correct numbers.

See rescale slope and rescale intercept and Window width and center calculation of DICOM image.

Answer 5

The key is the Pixel Representation (0028,0106) data element.

PixelRepresentation = 0 -> unsigned
PixelRepresentation = 1 -> signed

In your case, you have a value of '1', so you must read and interpret the values as signed integers.

You can find additional information here.