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
DICOM provides mechanism for supporting JPEG-LS Image Compression and DICOM standard PS 3.5 Annex A defines two different Transfer Syntaxes that reference the JPEG-LS Standard (ISO/IS-14495-1 (JPEG-LS Part 1). The Transfer Syntax with a UID of "1.2.840.10008.1.2.4.80" is lossless (bit preserving) and Transfer Syntax with a UID of "1.2.840.10008.1.2.4.81" is lossy (near-lossless) compression schemes.
I had a similar problem and I solved using @JohnnyQ hints in this way:
conda install -n myenv -c clinicalgraphics gdcm
conda install -n myenv -c anaconda pillow
Also you can use pip install ...
to install gdcm and pillow.
Take a look at https://pydicom.github.io/pydicom/stable/image_data_handlers.html
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
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:
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).