Trouble compressing lossy jpegs

All other questions regarding DCMTK

Moderator: Moderator Team

Post Reply
Message
Author
dwballance
Posts: 9
Joined: Thu, 2005-02-24, 09:15

Trouble compressing lossy jpegs

#1 Post by dwballance »

I've been using DCMTK for a while in an app to do both lossy and lossless compression on a variety of image types. Currently, 8-bit monochrome and color images compressed in both formats open normally in viewers, and lossless 12-bit images do too. However, lossy 12-bit images are generating "read beyond end of file" type messages in every viewer I use. When I look at the headers, the lossless and lossy images differ in one unusual manner - the lossless ones show 16 bits allocated, 16 bits stored and 15 as the high bit, whereas the lossy images show 16 allocated, 12 stored, and 11 high.

I am trying test my theory that the bit depth is the problem by trying to force 16 as the BitsStored value, both by setting the tag explictly and by passing "16" as the argument for the register-codec pForcedBitDepth parameter, but it always gets set to 12. I'm also using the 2_4 encoding syntax, which works great for the 8-bit images and in prior testing worked will for the higher bit depths as well.

I'm stumped as to why these 12/16 bit lossy images are not viewable, and why I can't control the bits stored. (Curiouly, they used to work, several months ago, but something changed and even older versions of my code stopped working...) Any suggestions would be most appreciated.

Thanks.
--Dennis

Marco Eichelberg
OFFIS DICOM Team
OFFIS DICOM Team
Posts: 1446
Joined: Tue, 2004-11-02, 17:22
Location: Oldenburg, Germany
Contact:

#2 Post by Marco Eichelberg »

The lossy JPEG algorithm does not support more than 12 bits/sample, this is why the lossy JPEG codec in DCMTK will forcably downscale images to 12 bits if they have more than that.
There are not too many viewers that support 12 bits/sample JPEG compression (extended sequential) anyway - probably you should check that before tweaking the compressed binary.

dwballance
Posts: 9
Joined: Thu, 2005-02-24, 09:15

#3 Post by dwballance »

Ah - so it sounds like I might be better of sticking with lossless format JPEG compression on those 12-bit images, correct? I had not considered lack of support from viewers as the source of the problem. (What is strange is I could have sworn that I was successful for quite a while in compressing the 12-bit images in a fashion that was readable by viewers...maybe I was downsampling to 8-bit or using lossless and not realizing it.)

Also - is there another compression format (besides extended sequential) that I should try?

--Dennis

Marco Eichelberg
OFFIS DICOM Team
OFFIS DICOM Team
Posts: 1446
Joined: Tue, 2004-11-02, 17:22
Location: Oldenburg, Germany
Contact:

#4 Post by Marco Eichelberg »

No, probably not. Many viewers support lossless JPEG (which may contain up to 16 bits/sample) and lossy JPEG baseline which is limited to 8 bits/sample. Any viewer that does not support extended sequential mode with 12 bits/sample is quite unlikely to support any of the more advanced compression schemes, and most of those have meanwhile been retired from the DICOM standard anyway. Of course you can try the RLE encoder (dcmcrle) instead, but for most images this is not really an alternative.

dwballance
Posts: 9
Joined: Thu, 2005-02-24, 09:15

#5 Post by dwballance »

Thank you!

Post Reply

Who is online

Users browsing this forum: Ahrefs [Bot], Bing [Bot] and 1 guest