JPEG Lossless in DICOM

Question

In the DICOM spec one of the Transfer Syntaxes is 1.2.840.10008.1.2.4.70 defined as JPEG Lossless, Nonhierarchical, First- Order Prediction (Processes 14 [Selection Value 1]).

What does "JPEG Lossless, Nonhierarchical, First- Order Prediction (Processes 14 [Selection Value 1])" mean? Is this format the same as JPEG-LS? This page seems to indicate that there is some difference (JPEG-LS is listed in the bottom section).

Is is possible to read or write this format in Python? Looking over the docs for Pillow is no clear to me that the format is supported.

This post is somewhat relevant.

Answer 1

JPEG Lossless First Order

Identical to the main JPEG lossless, but with a constrained value for the
predictor, giving a slightly simplified algorithm, with slightly greater
speed, but slightly less compression on most images (2-5% typically)
(from medicalconnections wiki)

You may have a look at GDCM for encoding jpeg compressed dicom images. GDCM Wiki Link

Answer 2

JPEG Lossless and JPEG-LS are very different implementation for image compression. JPEG lossless is defined in standard document: ITU-T T.81, ISO/IEC IS 10918-1, while JPEG-LS is defined in ITU-T T.87, ISO/IEC IS 14495-1.

JPEG-LS is a very different approach from all other JPEG-* compression family, since in its lossy form it is setup with a maximum bias from the original pixel. So you can generate a lossy JPEG-LS from an input file, where at maximum the difference in between the generated pixel and the original one, the difference is -say- 2.

Most toolkit on UNIX wont support JPEG Lossless originally because of some patent issue with the arithmetic codec:

• http://en.wikipedia.org/wiki/Arithmetic_coding#US_patents

Therefore IJG (aka libjpeg) is a very limited implementation of ITU T.81 and only provides by default on UNIX distribution the lossy 8bits compression form of the standard (sequential & progressive but not hierarchical). Neither the lossy 12bits, nor the lossless 16bits is available. Technically the 12bits lossy should be possible, but since it requires a recompilation most (all?) distributions do not ship this "dual" library.

All of the above is also correct when using the new libjpeg-turbo implementation, since libjpeg-turbo is only an optimized (binary compatible) version of the original libjpeg (version 6b to be precise).