原文:http://www.mccauslandcenter.sc.edu/crnl/tools/jpeg-formats
Introduction
This article describes the different forms of JPEG compression specified for DICOM files, the dominant image format for medical imaging. The DICOM standard currently specifies 35 different ways an image could be embedded into a DICOM file. These formats are referred to as the Transfer Syntax (http://www.dicomlibrary.com/dicom/transfer-syntax/). Here I describe the most popular Transfer Syntaxes that use JPEG formats. 图像压缩格式就是传输句法。
Baseline JPEG
Common in DICOM: Transfer syntax 1.2.840.10008.1.2.4.50 describes the 8-bit standard classic lossy JPEG that is identical to the most common JPEG images created by digital cameras and used on the web page. 常见的是:传输句法1.2.840.10008.1.2.4.50 描述了8位标准的经典有损JPEG,这和数码相机常用的JPEG图片以及网页上常用的格式相同。These are easy to support – you can typically decode these using the API of your operating system, or for universal support use the popular IJG library or the elegant nanoJPEG library. To convert a dicom image to this format you can use dcmcjpeg with the command “./dcmcjpeg +eb in.dcm out.dcm”.
Rare in DICOM: Transfer syntax 1.2.840.10008.1.2.4.51 describes the standard lossy JPEG format but extended to store higher precision (e.g. 12 rather than 8 bits per pixel, yielding up to 4095 distinct colors). Standard JPEG libraries can not handle these images. The typical solution is for developers to recompile a version of the IJG library to support this pixel format. However, the resulting library is no longer able to cope with the 8-bit images. Fortunately, this format appears to be exceptionally rare: someone who demands high precision data is probably not interested in lossy compression. If you insist on creating one of these images you can use the command “./dcmcjpeg +ee in.dcm out.dcm”.Compressed lossless JPEG
Common in DICOM. Transfer syntaxes 1.2.840.10008.1.2.4.57 and 1.2.840.10008.1.2.4.70 refer to a lossless JPEG format that is exceptionally rare outside of the medical domain (and completely different from both the lossless JPEG-LS and lossless JPEG-2000 encoding formats). While this was fully described in the JPEG ISO/IEC 10918-1:1994 T.81 (09/92), it did not gain traction outside of medical imaging (where GIF and PNG became the most popular lossless formats). This legacy lossless JPEG is a simple format, and only uses the Huffman encoding without the typical discrete cosine transforms (DCT). However, the fact that these images are typically saved with 16-bit precision means it is not supported by most libraries, and they generate an error saying they can not decode “SOF type 0xc3”.
I have written my own library to support this format, though other tools (e.g. dcmtk) use custom-patched variations of the IJG library. This is not a very efficient compression method, and personally I would strongly recommend users investigate file-based compression (.zip, or disk driver enabled compression) over this arcane format. This is the default output of dcmcjpeg, probably explaining its widespread popularity, for example the command “./dcmcjpeg in.dcm out.dcm” generates a DICOM image with format 1.2.840.10008.1.2.4.70, while the command “./dcmcjpeg +el in.dcm out.dcm” generates an image with syntax 1.2.840.10008.1.2.4.57.Compress lossless JPEG-LS
Virtually unknown in DICOM in theory, the JPEG-LS standard looked promising: better compression than the ancient lossless JPEG, and simpler to implement than the JPEG2000 formats. While I have seen test images with transfer syntaxes 1.2.840.10008.1.2.4.80 and 1.2.840.10008.1.2.4.81, these remain exceptionally rare. I do not support this.Compressed JPEG2000 (lossy and lossless)
Rare in DICOM:Transfer syntaxes 1.2.840.10008.1.2.4.90, 1.2.840.10008.1.2.4.91 and 1.2.840.10008.1.2.4.92 refer to JPEG2000 based compression. This is very different from the other JPEG methods, using wavelets rather than DCT. This is a technically impressive format – at extreme compression ratios it does not have the blocky artifacts of conventional JPEG. At typical compression ratios it tends to produce files that are perhaps 15% smaller than conventional JPEG. However, adoption has been very slow, perhaps because conventional JPEG is good enough and most JPEG2000 libraries are hard to integrate. In my experience the Jasper library is elegant, but it does have problems with some 16-bit images. On the other hand, the OpenJPEG library is cumbersome, the calls have changed a lot between versions, is poorly documented, but is very robust. In my experience, these images remain rare (perhaps since dcmcjpeg does not yet support them). For samples see the Osirix Examples.