Interpretation of stored pixel values. - DICOM
This is a discussion on Interpretation of stored pixel values. - DICOM ; Hello,
Last [two] question[s] from me tonight . Hopefully simple ones.
Let's say you have an unsigned DICOM image with bits allocated = 16,
bits stored = 10, but high bit = 12:
bit 15 bit 0
Then if I ...
-
Interpretation of stored pixel values.
Hello,
Last [two] question[s] from me tonight
. Hopefully simple ones.
Let's say you have an unsigned DICOM image with bits allocated = 16,
bits stored = 10, but high bit = 12:
bit 15 <--- AAASSSSS SSSSSAAA ---> bit 0
Then if I encounter the following pixel value:
00000000 00001000
Where those low 3 bits are not included in "bits stored", is that
value 1, or is that value 8? In other words, do "bits stored" + "high
bit" simply define a bit mask that should be applied to pixel values
read from a file, or do they also define which bit should be treated
as the least-significant bit when stored values are converted to
internal representations?
Now, second question, say I encounter this pixel value:
00011111 11111000
This is the largest value that could be stored given the pixel format.
Should this be thought of as the absolute maximum value that the
scanning equipment could ever possibly obtain? Or should it be simply
thought of as some arbitrary value in some arbitrary place in the
range of all possible values that could come from that equipment? In
other words, let's say a machine can generate a value of, I dunno,
4096. But for this particular scan, the maximum value it actually
generated was, say, 15. Would it be reasonable, then, for that machine
to only set bits stored to 5, since 5 bits is all that is required to
store all the pixel values encountered in a particular scan?
I know this second question is pedantic, but it's more to make sure
I'm thinking about it correctly than anything else. A mistake I had
made once was taking a DICOM image generated from a CT scanner, and
using a 16-bit unsigned internal representation, and shifting all the
values loaded from the file some number of bits to the left so that
the "high bit" in the file lined up with bit 15 in the internal
representation. I had done this before I had a good idea of what was
going on, and it turned out to be a costly mistake for various
reasons. The reason I had done this is because I had been thinking
about it purely as image data, where "all meaningful bits on" equated
to "full white" in my head. So like I said, just trying to make sure
I'm thinking about it right.
Thanks,
Jason
-
Re: Interpretation of stored pixel values.
> Last [two] question[s] from me tonight
. Hopefully simple ones.
> Let's say you have an unsigned DICOM image with bits allocated = 16,
> bits stored = 10, but high bit = 12:
I think this is not allowed
high bit = bits stored-1 is required by the standard I think
-
Re: Interpretation of stored pixel values.
Jason,
> Last [two] question[s] from me tonight
. Hopefully simple ones.
> Let's say you have an unsigned DICOM image with bits allocated = 16,
> bits stored = 10, but high bit = 12:
>
> bit 15 <--- AAASSSSS SSSSSAAA ---> bit 0
>
> Then if I encounter the following pixel value:
>
> 00000000 00001000
>
> Where those low 3 bits are not included in "bits stored", is that
> value 1, or is that value 8?
This is value 1. Bits Stored plus High Bit is not only a bit mask,
but defines which bit is the LSB in each pixel cell.
> In
> other words, let's say a machine can generate a value of, I dunno,
> 4096. But for this particular scan, the maximum value it actually
> generated was, say, 15. Would it be reasonable, then, for that machine
> to only set bits stored to 5, since 5 bits is all that is required to
> store all the pixel values encountered in a particular scan?
Since the Image Pixel Module is defined on SOP Instance level, each
image in a series could, in theory, have different values for
Bits Allocated, Bits Stored, and High Bit.
In practice I have never seen any such case.
Best regards
Marco Eichelberg
OFFIS
-
Re: Interpretation of stored pixel values.
Great! Thanks Sascha and (once again) Marco for clearing that up. 
-Jason