Psychedelic images after lossy compression

[simonmd]

Hi all..I was hoping someone could shed some light on this.

After enabling lossy compression on StoreSCP for CR images like so:

[calling=PACS,cuid=1.2.840.10008.5.1.4.1.1.1]JPLY(0.4:JPEG Lossy Compression with quality=0.40:35.0)

 Images are being compressed with Transfer Syntax UID: 1.2.840.10008.1.2.4.51 (JPEG Extended). But when I try to view them with OsiriX, I get this funky looking thing:

Anyone know what's going on? When I try to view them through the web interface or directly through the WADO URL, the images don't get rendered, but the logs show no error.

Here (https://www.dropbox.com/s/0qe62zbr7bj5d7l/funky.dcm) is the DICOM file for your analysis. My configuration is:

• i686 running Ubuntu 12.04.4 LTS 32 bit.
  
• java version "1.6.0_30"
  
• OpenJDK Runtime Environment (IcedTea6 1.13.1) (6b30-1.13.1-1ubuntu2~0.12.04.1)
  
• OpenJDK Server VM (build 23.25-b01, mixed mode)
  
• dcm4chee mysql 2.17.3

Any help would be greatly appreciated!

Simon

[nicolas...@gmail.com]

It would be interesting to have the original image to understand. It seems the encoding does not handle correctly the VOI LUT. The resulting image should not keep a VOI LUT. The pixel data is shifted of 2 pixel (HighBit 14). I am not sure any jpeg decoder will support that.

The image above is the result of an auto level preset. If the VOI LUT is applied, the image is totally white.

(0028,0100) [US] BitsAllocated: 16
(0028,0101) [US] BitsStored: 12
(0028,0102) [US] HighBit: 14
(0028,2110) [CS] LossyImageCompression: 01
(0028,2112) [DS] LossyImageCompressionRatio: 35.0
(0028,2114) [CS] LossyImageCompressionMethod: ISO_10918_1
(0028,3010) [SQ] VOILUTSequence: 1 item
--> ITEM #1
-->(0028,3002) [SS] LUTDescriptor: 16384\8192\16
-->(0028,3003) [LO] LUTExplanation:
-->(0028,3006) [OW] LUTData: binary data

[simonmd]

The image comes from an AGFA NX CR digitizer. I'll see if I can get my hands on an original image directly from it.

However, we have received images from such devices before. Am I wrong to understand the culprit might be the lossy compression being performed by dcm4chee, (java imageio)? Or do you think there is something inherently strange about the image sent?

FYI, images sent from the same device but with JPEG LS Lossless compression on the StoreSCP look normal.

[nicolas...@gmail.com]

I guess the compression is not handled correctly because the VOI LUT has 14-bit LUT and the images seems to have 12-bit pixel data. The final image should have at least a bitstrored of 14 and no VOI LUT (as the pixel values can change during the lossy jpeg compression).

[simonmd]

Here's a link to an original image directly from the digitizer, not a CR but a Mammography image, but we have the same problem with these.

https://www.dropbox.com/s/rhz5qs1zy4it3dn/funky2.dcm

Am I to understand then that the image itself, as generated by the digitizer, is encoded incorrectly with a 14-bit LUT and 12-bit pixel data?

[nicolas...@gmail.com]

This image has been scanned with 8-bit pixel depth. I would be very surprised that the jpeg lossless compression can produce an image like you mentioned at the beginning.

[simonmd]

Of course, you are right, my apologies. That image apparently came from a patient CD burned from the digitizer, but it obviously converts it to 8-bits.

I will try to get my hands on an uncompressed image transferred directly to our dcm4chee.