JPEG-LS - The good, the bad and the ugly

Following up on my previous post on JPEG2000 - the good, the bad and the ugly, I figured I would do the same for JPEG-LS which is another compression algorithm standardized by DICOM that is not well understood.  JPEG-LS is based on the LOCO-I algorithm developed by HP which happens to work very well for medical images.  Here is a high level block diagram of the LOCO-I algorithm:





The Good

1. JPEG-LS delivers one of the highest lossless compression ratios.  It often beats JPEG2000 by a small margin
2. JPEG-LS supports a variety of pixel formats - 8 bit gray, 16 bit gray, 8 bit color 
3. JPEG-LS supports lossy and lossless encodings.
4. JPEG-LS has a well supported open source C++ implementation named CharLS.  I have done an EMSCRIPTEN build of CharLS to javascript for use with cornerstone.  
5. Most applications supporting JPEG-LS are presumed to be using CharLS.  Since most people use the same library, there should be few interoperability issues  
6. JPEG-LS is extremely fast at encoding and decoding
7. JPEG-LS is simpler than other compression algorithms (e.g. JPEG2000) and is therefore easier to implement

The Bad:

1. Most applications supporting JPEG-LS are presumed to be using CharLS.  Bugs in the implementation may exist and be unknown since most applications use the same library
2. JPEG-LS has limited support for controlling image quality in lossy encoding mode
3. JPEG-LS has no support for progressive downloading
4. JPEG-LS depends on IP held by HP.  HP allows use of its IP for implementations that meet certain requirements

The Ugly:

1. JPEG-LS is not widely adopted in the industry.

NOTE: Corrections and clarifications are always appreciated, I will update this article as I receive them.  Thank you