About EPR_Uint16 file
Moderator: Moderator Team
-
- Posts: 40
- Joined: Thu, 2008-09-18, 09:20
- Location: Japan
About EPR_Uint16 file
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
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
Maty
-
- ICSMED DICOM Services
- Posts: 2217
- Joined: Fri, 2004-10-29, 21:38
- Location: Oldenburg, Germany
-
- Posts: 40
- Joined: Thu, 2008-09-18, 09:20
- Location: Japan
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
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
Maty
-
- ICSMED DICOM Services
- Posts: 2217
- Joined: Fri, 2004-10-29, 21:38
- Location: Oldenburg, Germany
You are mixing Pixel Representation and Photometric Interpretation. Pixel Representation is about signed or unsigned pixel data.The Pixel Representation is MONOCHROME2.
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.(0028,0101)-(US) : Bits Stored : 10
[...]
But, the largest value of the pixel is over 2000!
Basically, I would recommend that you read about the grayscale transformation pipeline in the DICOM standard.
-
- Posts: 40
- Joined: Thu, 2008-09-18, 09:20
- Location: Japan
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
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
Maty
-
- ICSMED DICOM Services
- Posts: 2217
- Joined: Fri, 2004-10-29, 21:38
- Location: Oldenburg, Germany
With "Pixel Representation" I was referring to the DICOM attribute (0028,0103). From DICOM part 3:
EPR_Uint16 refers to the internal pixel representation that is used by the DicomImage class (in this case, unsigned integer with 16 bits).Data representation of the pixel samples.
Each sample shall have the same pixel representation.
Enumerated Values:
0000H = unsigned integer.
0001H = 2's complement
-
- Posts: 40
- Joined: Thu, 2008-09-18, 09:20
- Location: Japan
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
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
Maty
Who is online
Users browsing this forum: No registered users and 0 guests