Relationship between stored values (SV) and Hounsfield (HU)
Jiye An
Recently, I met a problem of converting from stored values (SV) to
Hounsfield (HU). This file comes from a CT scan.
I have got that the tag "Pixel Representation", (0028, 0103) is 0001H.
So the pixel representation of each sample is 2's complement. Also I
got the tag "Rescale Intercept", (0028, 1052) is -1024 and "Rescale
Slope", (0028, 1053) is 1. So the relationship between stored values
(SV) and Hounsfield (HU) should be HU = SV - 1024.
Here comes my question. The SV of many background pixels is 8000H.
Forgot to say, the "Bits Stored" of this file is 16. So because it is
2's complement, the decimal form is -32768. According to the above
formula, I will get the HU = -32768-1024 = ?. It overflows the range
of a 16-bit signed integer. So how should I deal with it?
I have seen two methods:
1. The Visualization Toolkit(vtk) provides a DICOM reader class which
can parse a DICOM file. It converts the 8000H by HU = 8000H - 1024 =
7C00H = 31744. You can go to http://www.vtk.org for detals about vtk.
2. PiView, a commercial DICOM viewer, convert this values to -1024. I
can get this by measure the pixel value on the displayed image. But I
don't know how it converts them.
In my opinion, it seems the PiView result is better to accept. Because
there are also some pixels whose SV is 0001H, 0002H around the 8000H
ones. If I perform the convertion, I will get the HU = -1023, -1022,
etc. So converting 8000H to -1024 will maintain a continuity among
those adjacent pixels.
But I wonder if there are some rules for me to convert 8000H to -1024
in this situation? And acturally, how should I deal with these pixels,
like vtk, or PiView, or should I use some other methods?
Any suggestion will be appreciated. Thank you in advance.
Jiye An
David Clunie
> Here comes my question. The SV of many background pixels is 8000H.
> Forgot to say, the "Bits Stored" of this file is 16. So because it is
> 2's complement, the decimal form is -32768. According to the above
> formula, I will get the HU = -32768-1024 = ?. It overflows the range
> of a 16-bit signed integer. So how should I deal with it?
>
> I have seen two methods:
>
> 1. The Visualization Toolkit(vtk) provides a DICOM reader class which
> can parse a DICOM file. It converts the 8000H by HU = 8000H - 1024 =
> 7C00H = 31744. You can go to http://www.vtk.org for detals about vtk.
>
> 2. PiView, a commercial DICOM viewer, convert this values to -1024. I
> can get this by measure the pixel value on the displayed image. But I
> don't know how it converts them.
>
> In my opinion, it seems the PiView result is better to accept. Because
> there are also some pixels whose SV is 0001H, 0002H around the 8000H
> ones. If I perform the convertion, I will get the HU = -1023, -1022,
> etc. So converting 8000H to -1024 will maintain a continuity among
> those adjacent pixels.
>
> But I wonder if there are some rules for me to convert 8000H to -1024
> in this situation? And acturally, how should I deal with these pixels,
> like vtk, or PiView, or should I use some other methods?
Hi
You raise an issue that confuses a lot of people, both on the creating
and displaying side.
The Pixel Padding Value (0028,0120) attribute, though part of the
General Equipment Module, is primarily a CT-related issue.
In the past, CT scanners reconstructed the raw data into images of
a circular form, yet images are stored as squares or rectangles.
Knowing this, to be able to detect the padding pixels and compress
them to save memory or disk space, some scanners would pad
the perimeter outside the circular reconstructed area with a distinct
value from those values that could occur within reconstructed pixels.
When such images were converted into DICOM, the plan was presumably
to record that value in (0028,0120) Pixel Padding Value.
The following questions arise however, which are not well addressed
by the standard, and have been interpreted differently by different
vendors.
- Must the Pixel Padding Value (0028,0120) be a valid value within
the number of Bits Stored (0028,0101), as opposed to Bits Allocated
(0028,0100); e.g. if Bits Stored is 12 and Bits Allocated is 16,
and the data is unsigned, then is a padding value of > 4095 legal ?
In practice, there have been vendors who have sent padding values
outside the Bits Stored range.
- Is the Pixel Padding Value (0028,0120) to be interpreted before or
after application of the Rescale Intercept (0028,1052) (or slope
for that matter, though a slope of other than 1 is unusual) ? I
think the intent is that the padding value be interpreted as
matching the stored pixel values (i.e. what is encoded in (7FE0,
0010), and not after conversion to, say Hounsfield Units, and
everyone creating such images seems to have interpreted it that
way.
- Must the output of the interpretation of the stored pixel values
(in terms of Bits Stored (0028,0101) and Pixel Representation
(0028,0103), plus the special handling of the pixel padding value,
plus the application of Rescale Intercept (0028,1052) (and slope)
be representable in a signed or unsigned 16 bit value ?
- Can an image claim to be unsigned (a Pixel Representation (0028,0103)
of 0) and yet have a Rescale Intercept (0028,1052) of, say -1024 ?
Obviously yes, since the output of rescaling is HU, which may be
negative; indeed this is a common pattern from some vendors.
Likewise, an image may claim to be signed (a Pixel Representation
(0028,0103) of 1), yet have no negative values, and still have a
Rescale Intercept (0028,1052) of, say -1024; for some vendors though,
they will be signed and have a zero intercept value.
This latter question is extremely important and incorrect assumptions
in this regard can result in display pipelines that fail to render
an image that really does use all 16 bits of a signed or unsigned
word. Since this is a rare occurrence, but does happen, the handling
of the pixel padding value often manifests itself as a sort of special
case of the use of the full available dynamic range of the data.
Complicating matters are other peripherally related issues such as:
- vendors change their pixel padding value of choice over time; for
example with GE it used to be 0x8000; then folks complained that
(poorly implemented) displays were handling this badly (e.g.
showing the background as white rather than black), so they came
up with various "less negative" values, such as -2000 dec, which
would be handled by lesser workstations as if they were valid
pixel values, but less dense (more black) than air ... of course
this gets mixed up with whether or not one subtracts the rescale
intercept first and so on, but in general works
- vendors make mistakes as their choices evolve over time, for
example, GE went to a less negative value for padding that they
actually stored in the pixel data, but forgot to update the
attribute Pixel Padding Value (0028,0120)
- can Rescale Slope (0028,1053) ever be other than 1 ? Yes it can,
but surprisingly few display systems account for this
- the VOI LUT (window center/width) operation applies AFTER the
rescaling; i.e. the center is specified in HU in the case of CT
The bottom line for a display system is essentially as follows:
- there are few reasons to detect the padded pixels and handle them
specially, one just needs to be able to display them sensibly,
i.e. as black and not white
- to do a histogram of pixel values (e.g. to guess a good window)
is about the only reason I can think of to exclude these pixels
- one cannot just ignore the pixels that are padding values and
assume they will "behave" as if they were within the normal
range of pixel values, since from many vendors and scanners
they will not be
- one cannot assume the pixel padding value will fit in the Bits
Stored (0028,0101) range of values
- one cannot assume that the bits above the Bits Stored (0028,0101)
range of values (i.e. above the high bit) will be zeroes, or will
contain 1's for sign extension of signed pixel representations,
or not contain overlay - i.e. one cannot just ignore Bits Stored
(0028,0101) and treat every stored pixel as if it is a valid 16
bit unsigned or signed value
- one cannot just add some fixed value (like 0x8000) to every supposedly
signed pixel representation pixel value, adjust the interpretation
of rescale intercept appropriately, and assume that extremely positive
or negative values will not wrap around ... in some cases such as
we are discussing they will
Since there are many performance reasons to try to stay within a
16 bit word for internal operations, the best way I have found to
deal with this is as follows:
- preserve the notion that some 16 bit images are signed and some are
not internally - trying to force everything into one or the other
always fails for some use cases - i.e. one has to have two pipelines
or a pipeline parameterized by the sign
- handled pixel padding specially, in the sense that every pixel that
has a value that equals Pixel Padding Value (0028,0120) is mapped
into the most black pixel value possible in the internal representation,
for example 0 in unsigned representations and 0x8000 in signed
representations; in addition you may want to check for some known
vendor bugs by assuming certain values are padding values even if
they are not so described in Pixel Padding Value (0028,0120); for
example I check for 0x8001 as well
- mask all high pixels if they are unsigned and sign extend all negative
pixel values if they are signed
- do not assume that the output of rescaling results in a 16 bit value;
this may necessitate floating point calculations when creating the
LUT that transforms the internal stored 16 bit representation into
whatever the VOI LUT or linear window center/width operation map
into P-values (e.g. 0 to 255) to drive the calibrated display - some
implementations do the calculation for every pixel, others do it when
populating the LUT with a value for every possible (or used) input
pixel
You may be interested in a set of test cases that I made to address the
question of whether or not a display handles extreme permutations of
bit depth and signedness:
http://dclunie.com/images/signedrange/
Whatever you decide to do, regardless of the padding value issue, you
choice should correctly display all these images.
Your question prompts to me to consider extending that data set with a
variety of possible values for Pixel Padding Value (0028,0120) as well,
since that is not covered by those test images.
david
PS. What VTK is doing is I presume going to give you a white surround,
which is not correct.
PPS. To put things in perspective, I began checking the use of pixel
padding by various CT images, mostly from fairly recent scanners,
with the following results so far. The fields are in
the following order, with an empty field if the attribute (e.g. Pixel
Padding Value) was not present in the data set.
pixelPaddingValue,bitsAllocated,bitsStored,pixelRepresentation,rescaleSlope,rescaleIntercept,
manufacturer,manufacturerModelName,softwareVersion
,0x0010,0x000c,0x0000,001.000000E+00,-01.024000E+03,"SIEMENS ","SOMATOM PLUS 4","VC10C "
,0x0010,0x000c,0x0000,1 ,-1000 ,"Philips ","Mx8000 IDT","2.5 "
,0x0010,0x000c,0x0000,1 ,-1000 ,"Philips ","Mx8000","2.12"
,0x0010,0x000c,0x0000,1 ,-1000 ,"Philips ","Mx8000","2.211 "
,0x0010,0x000c,0x0000,1 ,-1000 ,"Philips ","Mx8000","2.2111"
,0x0010,0x000c,0x0000,1 ,-1024 ,"SIEMENS ","Emotion ","VA40C "
,0x0010,0x000c,0x0000,1 ,-1024 ,"SIEMENS ","Plus 4Volume Zoom ","VA40C "
,0x0010,0x000c,0x0000,1 ,-1024 ,"SIEMENS ","Plus 4Volume Zoom 02","VA40C "
,0x0010,0x000c,0x0000,1 ,-1024 ,"SIEMENS ","SOMATOM PLUS 4","VC10C "
,0x0010,0x000c,0x0000,1 ,-1024 ,"SIEMENS ","SOMATOM SPIRAL HP ","VB41A "
,0x0010,0x000c,0x0000,1 ,-1024 ,"SIEMENS ","Sensation 4 ","VA40C "
,0x0010,0x000c,0x0000,1 ,-1024 ,"SIEMENS ","Volume Access ","VA40C "
,0x0010,0x000c,0x0000,1 ,-1024 ,"SIEMENS ","Volume Zoom ","VA40C "
,0x0010,0x000c,0x0000,1 ,-1024 ,"SIEMENS ","Volume Zoom ","Vds6.0"
,0x0010,0x000c,0x0000,1 ,-1024 ,"Siemens ","Somaris/5 3D Postprocessing ","VA40C "
,0x0010,0x000c,0x0000,1 ,-1200 ,"Philips Medical Systems ","AVEU",""
,0x0010,0x000c,0x0000,1 ,-1200 ,"Philips Medical Systems ","Philips CT Aura ","CT Backend Release 1.5.1 (C200) "
,0x0010,0x000c,0x0000,1.000000,-1000.000000,"Philips ","CT-3 IDT","2.5B8 "
,0x0010,0x000c,0x0000,1.000000,-1000.000000,"Philips ","CT-3 IDT","3.0 "
,0x0010,0x000c,0x0000,1.000000,-1000.000000,"Philips ","Mx8000 CT-1 ","2.51"
,0x0010,0x000c,0x0000,1.000000,-1000.000000,"Philips ","Mx8000 DUAL ","2.21"
,0x0010,0x000c,0x0000,1.000000,-1000.000000,"Philips ","Mx8000 IDT","2.5 "
,0x0010,0x000c,0x0000,1.000000,-1000.000000,"Philips ","Mx8000","2.21"
,0x0010,0x000c,0x0000,1.000000,-1000.000000,"Philips ","Mx8000","2.211 "
,0x0010,0x000c,0x0000,1.000000,-1024.000000,"SIEMENS ","Emotion ","VA40C "
,0x0010,0x000c,0x0000,1.000000,-1024.000000,"SIEMENS ","SOMATOM PLUS 4","VC10C "
,0x0010,0x000c,0x0000,1.000000,-1024.000000,"SIEMENS ","Sensation 16","VA70C "
,0x0010,0x000c,0x0000,1.000000,-1024.000000,"SIEMENS ","Sensation 4 ","VA40C "
,0x0010,0x000c,0x0000,1.000000,-1024.000000,"SIEMENS ","Volume Access ","VA40C "
,0x0010,0x000c,0x0000,1.000000,-1024.000000,"SIEMENS ","Volume Zoom ","VA40C "
,0x0010,0x000c,0x0000,1.000000,-1024.000000,"SIEMENS ","Volume Zoom ","Vds6.0"
,0x0010,0x000c,0x0000,1.000000,-1024.000000,"Siemens ","Somaris/5 3D Postprocessing ","VA40C "
,0x0010,0x000c,0x0000,1.000000,-1024.000000,"Siemens ","Somaris/5 3D Postprocessing ","VA40C-W "
,0x0010,0x000c,0x0000,1.000000,-1200.000000,"Philips Medical Systems ","AVE1",""
,0x0010,0x000c,0x0000,1.000244,-1024 ,"SIEMENS ","Volume Zoom ","VA20Q "
,0x0010,0x000c,0x0000,1.0002441 ,-1024 ,"SIEMENS ","Plus 4Volume Zoom ","VA20Q "
,0x0010,0x000c,0x0000,1.0002441 ,-1024 ,"SIEMENS ","Plus 4Volume Zoom 02","VA20R "
,0x0010,0x0010,0x0000,0.833333,0 ,"Philips Medical Systems ","Philips CT Aura ","CT Backend Release 1.5.1 (C200) "
,0x0010,0x0010,0x0001,1 ,-1024 ,"GE MEDICAL SYSTEMS","HiSpeed CT/i","05"
,0x0010,0x0010,0x0001,1 ,-1024 ,"GE MEDICAL SYSTEMS","HiSpeed QX/i","LightSpeedApps100.3_HSQXI_M3.1"
,0x0010,0x0010,0x0001,1 ,-1024 ,"GE MEDICAL SYSTEMS","LightSpeed Plus ","LightSpeedApps14.13_2.8.2L_H2.1M4 "
,0x0010,0x0010,0x0001,1 ,-1024 ,"GE MEDICAL SYSTEMS","LightSpeed Plus ","LightSpeedApps2.3.7_H2.3M4"
,0x0010,0x0010,0x0001,1 ,-1024 ,"GE MEDICAL SYSTEMS","LightSpeed Plus ","LightSpeedApps305.4_H3.1M4"
,0x0010,0x0010,0x0001,1 ,-1024 ,"GE MEDICAL SYSTEMS","LightSpeed Power","LightSpeedApps2.5_hp.me "
,0x0010,0x0010,0x0001,1 ,-1024 ,"GE MEDICAL SYSTEMS","LightSpeed QX/i ","LightSpeedApps10.5_2.8.2I_H1.3M4"
,0x0010,0x0010,0x0001,1 ,-1024 ,"GE MEDICAL SYSTEMS","LightSpeed QX/i ","LightSpeedApps2.3.7_H2.3M4"
,0x0010,0x0010,0x0001,1 ,-1024 ,"GE MEDICAL SYSTEMS","LightSpeed Ultra","LightSpeedApps303.1_H3M4"
,0x0010,0x0010,0x0001,1 ,-1024 ,"GE MEDICAL SYSTEMS","LightSpeed Ultra","LightSpeedApps305.4_H3.1M4"
,0x0010,0x0010,0x0001,1 ,-1024 ,"GE MEDICAL SYSTEMS","LightSpeed16","LightSpeedApps401.8_H4.0M4"
,0x0010,0x0010,0x0001,1 ,-1024 ,"GE MEDICAL SYSTEMS","LightSpeed16","LightSpeedverrel"
,0x0010,0x0010,0x0001,1 ,0 ,"GE MEDICAL SYSTEMS","HiSpeed ","6.03"
,0x0010,0x0010,0x0001,1 ,0 ,"GE MEDICAL SYSTEMS","LightSpeed Plus ","LightSpeedApps14.13_2.8.2L_H2.1M4 "
,0x0010,0x0010,0x0001,1 ,0 ,"GE MEDICAL SYSTEMS","LightSpeed Plus ","LightSpeedApps2.3.7_H2.3M4"
,0x0010,0x0010,0x0001,1 ,0 ,"GE MEDICAL SYSTEMS","LightSpeed QX/i ","LightSpeedApps10.5_2.8.2I_H1.3M4"
,0x0010,0x0010,0x0001,1 ,0 ,"Picker International, Inc.","PQ5000","4.6B2 (Q"
,0x0010,0x0010,0x0001,1 ,0 ,"TOSHIBA ","Asteion ","V1.71ER004"
,0x0010,0x0010,0x0001,1 ,0 ,"TOSHIBA ","Asteion ","V1.76ER002"
,0x0010,0x0010,0x0001,1.000000,-1024.000000,"GE MEDICAL SYSTEMS","HiSpeed CT/i","05"
,0x0010,0x0010,0x0001,1.000000,-1024.000000,"GE MEDICAL SYSTEMS","LightSpeed Plus ","LightSpeedApps14.13_2.8.2L_H2.1M4 "
,0x0010,0x0010,0x0001,1.000000,-1024.000000,"GE MEDICAL SYSTEMS","LightSpeed Plus ","LightSpeedApps2.3.7_H2.3M4"
,0x0010,0x0010,0x0001,1.000000,-1024.000000,"GE MEDICAL SYSTEMS","LightSpeed Plus ","LightSpeedApps303.1_H3M4"
,0x0010,0x0010,0x0001,1.000000,-1024.000000,"GE MEDICAL SYSTEMS","LightSpeed Plus ","LightSpeedApps304.3_H3.1M3"
,0x0010,0x0010,0x0001,1.000000,-1024.000000,"GE MEDICAL SYSTEMS","LightSpeed Plus ","LightSpeedApps305.4_H3.1M4"
,0x0010,0x0010,0x0001,1.000000,-1024.000000,"GE MEDICAL SYSTEMS","LightSpeed QX/i ",""
,0x0010,0x0010,0x0001,1.000000,-1024.000000,"GE MEDICAL SYSTEMS","LightSpeed QX/i ","LightSpeedApps10.5_2.8.2I_H1.3M4"
,0x0010,0x0010,0x0001,1.000000,-1024.000000,"GE MEDICAL SYSTEMS","LightSpeed QX/i ","LightSpeedApps2.3.7_H2.3M4"
,0x0010,0x0010,0x0001,1.000000,-1024.000000,"GE MEDICAL SYSTEMS","LightSpeed Ultra","LightSpeedApps301.1_2.9C_20010628_H3M3"
,0x0010,0x0010,0x0001,1.000000,-1024.000000,"GE MEDICAL SYSTEMS","LightSpeed Ultra","LightSpeedApps305.4_H3.1M4"
,0x0010,0x0010,0x0001,1.000000,-1024.000000,"GE MEDICAL SYSTEMS","LightSpeed16","LightSpeedApps401.8_H4.0M4"
,0x0010,0x0010,0x0001,1.000000,-1024.000000,"GE MEDICAL SYSTEMS","LightSpeed16","LightSpeedverrel"
,0x0010,0x0010,0x0001,1.000000,-3072.000000,"GE MEDICAL SYSTEMS","LightSpeed Plus ","LightSpeedApps2.3.7_H2.3M4"
0xc000,0x0010,0x0010,0x0001,1 ,-1024 ,"GE MEDICAL SYSTEMS","GENESIS_FOREIGN ",""
0xc000,0x0010,0x0010,0x0001,1.000000,-1024.000000,"GE MEDICAL SYSTEMS","GENESIS_FOREIGN ",""
0xf800,0x0010,0x0010,0x0001,1 ,0 ,"Philips ","TOMOSCAN A ",""
0xf830,0x0010,0x0010,0x0001,1 ,-1024 ,"GE MEDICAL SYSTEMS","HiSpeed CT/i","05"
0xf830,0x0010,0x0010,0x0001,1 ,-1024 ,"GE MEDICAL SYSTEMS","HiSpeed QX/i","LightSpeedApps100.3_HSQXI_M3.1"
0xf830,0x0010,0x0010,0x0001,1 ,-1024 ,"GE MEDICAL SYSTEMS","LightSpeed Plus ","LightSpeedApps14.13_2.8.2L_H2.1M4 "
0xf830,0x0010,0x0010,0x0001,1 ,-1024 ,"GE MEDICAL SYSTEMS","LightSpeed Plus ","LightSpeedApps2.3.7_H2.3M4"
0xf830,0x0010,0x0010,0x0001,1 ,-1024 ,"GE MEDICAL SYSTEMS","LightSpeed Plus ","LightSpeedApps305.4_H3.1M4"
0xf830,0x0010,0x0010,0x0001,1 ,-1024 ,"GE MEDICAL SYSTEMS","LightSpeed Plus ","LightSpeedAppsh2.2m3.11c_2.9E_1.1_20011011_H2.2M4 "
0xf830,0x0010,0x0010,0x0001,1 ,-1024 ,"GE MEDICAL SYSTEMS","LightSpeed Power","LightSpeedApps2.5_hp.me "
0xf830,0x0010,0x0010,0x0001,1 ,-1024 ,"GE MEDICAL SYSTEMS","LightSpeed Pro 16 ","LightSpeedverrel"
0xf830,0x0010,0x0010,0x0001,1 ,-1024 ,"GE MEDICAL SYSTEMS","LightSpeed QX/i ","LightSpeedApps10.5_2.8.2I_H1.3M4"
0xf830,0x0010,0x0010,0x0001,1 ,-1024 ,"GE MEDICAL SYSTEMS","LightSpeed QX/i ","LightSpeedApps2.3.7_H2.3M4"
0xf830,0x0010,0x0010,0x0001,1 ,-1024 ,"GE MEDICAL SYSTEMS","LightSpeed Ultra","LightSpeedApps305.4_H3.1M4"
0xf830,0x0010,0x0010,0x0001,1 ,-1024 ,"GE MEDICAL SYSTEMS","LightSpeed16","LightSpeedApps401.8_H4.0M4"
0xf830,0x0010,0x0010,0x0001,1 ,-1024 ,"GE MEDICAL SYSTEMS","LightSpeed16","LightSpeedverrel"
0xf830,0x0010,0x0010,0x0001,1 ,0 ,"GE MEDICAL SYSTEMS","HiSpeed CT/i","05"
0xf830,0x0010,0x0010,0x0001,1 ,0 ,"GE MEDICAL SYSTEMS","LightSpeed Plus ","LightSpeedApps2.3.7_H2.3M4"
0xf830,0x0010,0x0010,0x0001,1 ,0 ,"GE MEDICAL SYSTEMS","LightSpeed QX/i ","LightSpeedApps10.5_2.8.2I_H1.3M4"
0xf830,0x0010,0x0010,0x0001,1.000000,-1024.000000,"GE MEDICAL SYSTEMS","HiSpeed CT/i","05"
0xf830,0x0010,0x0010,0x0001,1.000000,-1024.000000,"GE MEDICAL SYSTEMS","LightSpeed Plus ","LightSpeedApps14.13_2.8.2L_H2.1M4 "
0xf830,0x0010,0x0010,0x0001,1.000000,-1024.000000,"GE MEDICAL SYSTEMS","LightSpeed Plus ","LightSpeedApps2.3.7_H2.3M4"
0xf830,0x0010,0x0010,0x0001,1.000000,-1024.000000,"GE MEDICAL SYSTEMS","LightSpeed Plus ","LightSpeedApps303.1_H3M4"
0xf830,0x0010,0x0010,0x0001,1.000000,-1024.000000,"GE MEDICAL SYSTEMS","LightSpeed Plus ","LightSpeedApps304.3_H3.1M3"
0xf830,0x0010,0x0010,0x0001,1.000000,-1024.000000,"GE MEDICAL SYSTEMS","LightSpeed Plus ","LightSpeedApps305.4_H3.1M4"
0xf830,0x0010,0x0010,0x0001,1.000000,-1024.000000,"GE MEDICAL SYSTEMS","LightSpeed QX/i ","LightSpeedApps10.5_2.8.2I_H1.3M4"
0xf830,0x0010,0x0010,0x0001,1.000000,-1024.000000,"GE MEDICAL SYSTEMS","LightSpeed QX/i ","LightSpeedApps2.3.7_H2.3M4"
0xf830,0x0010,0x0010,0x0001,1.000000,-1024.000000,"GE MEDICAL SYSTEMS","LightSpeed Ultra","LightSpeedApps301.1_2.9C_20010628_H3M3"
0xf830,0x0010,0x0010,0x0001,1.000000,-1024.000000,"GE MEDICAL SYSTEMS","LightSpeed Ultra","LightSpeedApps305.4_H3.1M4"
0xf830,0x0010,0x0010,0x0001,1.000000,-1024.000000,"GE MEDICAL SYSTEMS","LightSpeed16","LightSpeedApps401.8_H4.0M4"
0xf830,0x0010,0x0010,0x0001,1.000000,-1024.000000,"GE MEDICAL SYSTEMS","LightSpeed16","LightSpeedverrel"
0xf830,0x0010,0x0010,0x0001,1.000000,-3072.000000,"GE MEDICAL SYSTEMS","LightSpeed Plus ","LightSpeedApps2.3.7_H2.3M4"
0xfa24,0x0010,0x0010,0x0001,1 ,0 ,"GE MEDICAL SYSTEMS","HiSpeed NX/i","5.52"
0xfa24,0x0010,0x0010,0x0001,1.000000,0.000000,"GE MEDICAL SYSTEMS","HiSpeed ","6.03"
Jiye An
I want to know how can I transform from stored values (SV) 0x8000 to
-1024 by the "Rescale Intercept" (0028, 1052) is -1024 and "Rescale
Slope" (0028, 1053) is 1.
Is there some other DICOM tags needed for transformation?
Thank you in advance.
Best Regards,
Jiye An
an_...@hotmail.com (Jiye An) wrote in message news:<f3aff1b4.04021...@posting.google.com>...
Doug Sluis
http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&oe=UTF-8&group=comp.protocols.dicom&selm=402E0D09.5020305%40dclunie.com
- doug
an_...@hotmail.com (Jiye An) wrote in message news:<f3aff1b4.0402...@posting.google.com>...
Jiye An
with this DICOM tag (0028, 0120) before. I still have some questions.
> Since there are many performance reasons to try to stay within a
> 16 bit word for internal operations, the best way I have found to
> deal with this is as follows:
>
> - preserve the notion that some 16 bit images are signed and some are
> not internally - trying to force everything into one or the other
> always fails for some use cases - i.e. one has to have two pipelines
> or a pipeline parameterized by the sign
I will always remember this.
>
> - handled pixel padding specially, in the sense that every pixel that
> has a value that equals Pixel Padding Value (0028,0120) is mapped
> into the most black pixel value possible in the internal representation,
> for example 0 in unsigned representations and 0x8000 in signed
> representations; in addition you may want to check for some known
> vendor bugs by assuming certain values are padding values even if
> they are not so described in Pixel Padding Value (0028,0120); for
> example I check for 0x8001 as well
I don't quite understand. Unsigned representations, for example, do
you mean I must replace all the pixel values equal to the Pixel
Padding Value with 0x8000? And how can I know which value I shoud deal
with? 0x8001 for example.
>
> - mask all high pixels if they are unsigned and sign extend all negative
> pixel values if they are signed
Do you mean extend 0x8000 to 0xffff8000 before the next rescaling
prodedure?
>
> - do not assume that the output of rescaling results in a 16 bit value;
> this may necessitate floating point calculations when creating the
> LUT that transforms the internal stored 16 bit representation into
> whatever the VOI LUT or linear window center/width operation map
> into P-values (e.g. 0 to 255) to drive the calibrated display - some
> implementations do the calculation for every pixel, others do it when
> populating the LUT with a value for every possible (or used) input
> pixel
>
I know the rescaling results may overflow. For example, the images I
am dealing with has a Pixel Padding Value of 0x8000. After rescaling,
they will be 0x7C00. In decimal form, I can say -32768 - 1024 =
"31744".
As you said, this is a very confusing problem for both creating and
displaying. And you listed many exsiting questions and some solving
suggestion. But I think I didn't quite catch you.
To simplify this problem, can I just do the following to display a
DICOM image?
- Get the "Pixel Padding Value", (0028, 0120)
- As suggested in C.7.5.1.1.2 of PS 3.3 - 2003, replace the pixel
stored values that are the same as padding value with 0 or
2^BitsStored - 1 according to Photometric Interpretation, (0028,0004).
By doing this, I can not take into account how the vendors generate
the padding value.
- Rescale the stored values to Hounsfield by HU = m*SV + b.
My example will be:
- Pixel Padding Value is 0x8000.
- Replace all 0x8000 with 0, since Photometric Interpretation is
MONOCHROME2.
- Rescale these pixles will result: 0 - 1024 = -1024.
Do you think this is OK? And can this work for any DICOM image?
Jiye An