About EPR_Uint16 file

[m-ishihara]

Hi DICOM @ OFFIS,

Thank you for your everyday's support.
BTW, I have a question about one of the EPR_Uint16 file.
I looked into the bit data from the tag infomation of the file, the bit data is as follows;

(0028,0100)-(US) : Bits Allocated : 16
(0028,0101)-(US) : Bits Stored : 12
(0028,0102)-(US) : High Bit : 11

Oddly enough, Window Center and Window Width data from the tag infomation are as follows;

(0028,1050)-(DS) : Window Center : Multiple values : 2025
(0028,1051)-(DS) : Window Width : Multiple values : 4050

I think the bit data and the window data are inconsistent.
Although the data range is from -2048 to 2047, the pixel range is from 0 to 4050.
Can you believe?
If you know about the EPR_Uint16 file, please let me know!

Thanks,

Maty

[Jörg Riesmeier]

The VOI Window is not necessarily limited to the range of pixel values ... if the rendered image looks odd then the VOI Window is probably incorrect - otherwise not

Btw, what are the values for Pixel Representation and Rescale Slope/Intercept?

[m-ishihara]

Hi Jörg,

Thank you for your reply.
The Pixel Representation is MONOCHROME2.
BTW, another data of EPR_Uint16 has the similar problem, but not the same problem.
The bit data from the tag is as follows;

(0028,0100)-(US) : Bits Allocated : 16
(0028,0101)-(US) : Bits Stored : 10
(0028,0102)-(US) : High Bit : 9

But, the largest value of the pixel is over 2000!
I'm very comfused about the data of EPR_Uint16 file.
Which data can I believe in the world?

Thanks,

Maty

[Jörg Riesmeier]

The Pixel Representation is MONOCHROME2.

You are mixing Pixel Representation and Photometric Interpretation. Pixel Representation is about signed or unsigned pixel data.

(0028,0101)-(US) : Bits Stored : 10
[...]
But, the largest value of the pixel is over 2000!

Depending on the Modality transformation, the internal representation might exceed the range you are expecting from the Bits Stored value. Btw, this is the reason why I was asking for Rescale Slope/Intercept.

Basically, I would recommend that you read about the grayscale transformation pipeline in the DICOM standard.

[m-ishihara]

Hi Jörg,

I'm sorry I was confused.
The only thing that I understand is that the Pixel Representation is EPR_Uint16.
Is it the answer that you expected?

BTW, my understanding of the following tag data;

(0028,0100)-(US) : Bits Allocated : 16
(0028,0101)-(US) : Bits Stored : 12
(0028,0102)-(US) : High Bit : 11

is as follows;

===Bit row===
|15|14|13|12|11|10| 9| 8| 7| 6| 5| 4| 3| 2| 1| 0|
<------------ Arrocated data width ---------------->
.....................<------ Used width for data ------->
.....................<s><--- Bits for integer value ---->
s means Sign bit(If there is a bit, it means munus.)

If you think there seems to be some misunderstanding, please let me know!

Thanks,

Maty

[Jörg Riesmeier]

With "Pixel Representation" I was referring to the DICOM attribute (0028,0103). From DICOM part 3:

Data representation of the pixel samples.
Each sample shall have the same pixel representation.
Enumerated Values:
0000H = unsigned integer.
0001H = 2's complement

EPR_Uint16 refers to the internal pixel representation that is used by the DicomImage class (in this case, unsigned integer with 16 bits).

[m-ishihara]

Hi Jörg,

Thank you for your quick reply and useful information.
BTW, the point this time is that the modified pixel data makes errors in the DCMTK after filtering.
I am now developing dll in order to filter the pixel data to investigate the medical image.
But the modified data after filtering would be larger or smaller than the original data, more than 10 times in some cases, although the modified data is less than 65535.
The error would occur in the VOI Lut process.
Do you think that seems likely?
If so, please let me know how to avoid the errors.

Thanks,

Maty