On Jul 4, 10:49 pm, Naveen wrote:
> I have a question on the display of DICOM images which are lossy
> compressed. Lets assume that I have a 12 bit unsigned image (i.e. Bits
> stored = 12, bits allocated = 16, high bit = 1) with the pixel values
> ranging from 0-4095 . Now because of the lossy compression if the
> pixel value 4095 becomes 4096 how should the image be displayed ?
> Should the software assume that it is an unspecified overlay embedded
> inside pixel data or try to correct it by bringing back the pixel into
> the valid limit?

Just a small correction, high bit is 11 and not 1.

On Jul 4, 7:51*pm, Naveen wrote:
> On Jul 4, 10:49 pm, Naveen wrote:
>
> > I have a question on the display of DICOM images which are lossy
> > compressed. Lets assume that I have a 12 bit unsigned image (i.e. Bits
> > stored = 12, bits allocated = 16, high bit = 1) with the pixel values
> > ranging from 0-4095 . Now because of the lossy compression if the
> > pixel value 4095 becomes 4096 how should the image be displayed ?
> > Should the software assume that it is an unspecified overlay embedded
> > inside pixel data or try to correct it by bringing back the pixel into
> > the valid limit?
>
> Just a small correction, high bit is 11 and not 1.

I have seen this happen in the past:

http://groups.google.com/group/comp....e201ccb23fae5d

The DICOM header said it was a 10bits dataset, thus I truncate
anything above this value (1023). I have to do this anyway to support
legacy overlay stored in the upper bits of the pixel.

HTH
-Mathieu

On Jul 4, 11:42 pm, Mathieu Malaterre
wrote:
> On Jul 4, 7:51 pm, Naveen wrote:
>
> > On Jul 4, 10:49 pm, Naveen wrote:
>
> > > I have a question on the display of DICOM images which are lossy
> > > compressed. Lets assume that I have a 12 bit unsigned image (i.e. Bits
> > > stored = 12, bits allocated = 16, high bit = 1) with the pixel values
> > > ranging from 0-4095 . Now because of the lossy compression if the
> > > pixel value 4095 becomes 4096 how should the image be displayed ?
> > > Should the software assume that it is an unspecified overlay embedded
> > > inside pixel data or try to correct it by bringing back the pixel into
> > > the valid limit?
>
> > Just a small correction, high bit is 11 and not 1.
>
> I have seen this happen in the past:
>
> http://groups.google.com/group/comp....wse_thread/thr...
>
> The DICOM header said it was a 10bits dataset, thus I truncate
> anything above this value (1023). I have to do this anyway to support
> legacy overlay stored in the upper bits of the pixel.
>
> HTH
> -Mathieu

Thanks Mathieu for your reply.. But I still have doubts about the
scenario described by Martel in the thread you mentioned. What if
somebody is really storing some private information in the upper
unused bits of the pixel data and not mentioning about it 0x60xx
group ? Currently I am also cleaning up the upper bits of the image
depending upon the high bit and overlay bit position (if overlay is
embedded inside pixel data). But if I cleanup like that I'll end up in
displaying black spots on the image exactly as you mentioned. Do you
think storing some private information in the unused bits of the pixel
data is a practical scenario ? or it is just a theoretical case ?

On Jul 5, 5:34*pm, Naveen wrote:
> On Jul 4, 11:42 pm, Mathieu Malaterre
> wrote:
>
>
>
> > On Jul 4, 7:51 pm, Naveen wrote:
>
> > > On Jul 4, 10:49 pm, Naveen wrote:
>
> > > > I have a question on the display of DICOM images which are lossy
> > > > compressed. Lets assume that I have a 12 bit unsigned image (i.e. Bits
> > > > stored = 12, bits allocated = 16, high bit = 1) with the pixel values
> > > > ranging from 0-4095 . Now because of the lossy compression if the
> > > > pixel value 4095 becomes 4096 how should the image be displayed ?
> > > > Should the software assume that it is an unspecified overlay embedded
> > > > inside pixel data or try to correct it by bringing back the pixel into
> > > > the valid limit?
>
> > > Just a small correction, high bit is 11 and not 1.
>
> > I have seen this happen in the past:
>
> >http://groups.google.com/group/comp....wse_thread/thr...
>
> > The DICOM header said it was a 10bits dataset, thus I truncate
> > anything above this value (1023). I have to do this anyway to support
> > legacy overlay stored in the upper bits of the pixel.
>
> > HTH
> > -Mathieu
>
> Thanks Mathieu for your reply.. But I still have doubts about the
> scenario described by Martel in the thread you mentioned. What if
> somebody is really storing some private information in the upper
> unused bits of the pixel data and not mentioning about it 0x60xx
> group ? Currently I am also cleaning up the upper bits of the image
> depending upon the high bit and overlay bit position (if overlay is
> embedded inside pixel data). But if I cleanup like that I'll end up in
> displaying black spots on the image exactly as you mentioned. Do you
> think storing some private information in the unused bits of the pixel
> data is a practical scenario ? or it is just a theoretical case ?

It is forbidden by the standard AFAIK.
If you are paranoid (we all are), then trigger something when the
upper bits are not zero (while doing the cleanup check if value after
cleanup == value before).

-Mathieu