Oct 10, 2010 at 9:49 AM

This thread will document news: Major changes to CharLS, applications, and JPEG-LS in general.

Oct 10, 2010 at 9:54 AM
Edited Oct 10, 2010 at 9:57 AM

JAI/DCM4CHE causing problems for 16 bit images.

I recently received a report that my codec does not read JPEG-LS images produced by DCM4CHE.
The report is consistent with the DCM4CHE issue:
I think i figured out the root cause, which appears to be a bug when JAI calculates some JPEG-LS default parameters (called T1, T2, T3 in the Jpeg-LS standard). I learned that the JAI codecs is a project that is not actively worked on, and no fix is to be expected. 
Based on my current understanding of the problem, I believe that:
- It is possible to patch existing images by patching in a JPEG marker segment.
- It is possible to make JAI produce correct bitstreams IF it is possible to override the default value for the relevant parameters at compression time.
- It is possible to make JAI read conformant bitstreams correctly, also by patching in a JPEG marker segment. 

I will follow up on this once I find out more.

Oct 10, 2010 at 10:03 AM

1.0 release coming up!

I will spend some time in the coming weeks to verify and close the remaining workitems, and publish the current svn trunk as the 1.0 release. It is entirely possible that there are going to be no code changes, but some additional testing is required to prove that. Stay tuned!

Oct 11, 2010 at 7:09 PM

Patch for Java Advanced Imaging IO/DCM4CHE images!

I was able today to decode an existing (faulty encoded) image encoded with JAI toolkit.  What JAI does wrong is that for 16 bit images, the calculation of the default encoder parameter values T1, T2, and T3 is wrong.

Luckily JPEG-LS allows you to choose your own values for T1-T3. You do this by inserting what is called an LSE marker segment. The JAI images can be fixed by inserting an LSE marker segment that specifies the T1-3 values that were used to encode the image. The easiest place to add the segment is by inserting it after the first two bytes of the compessed Jpeg-LS stream (example in C++):

unsigned char marker_lse[] = { 0xFF, 0xF8, 0x00, 0x0D, 0x01, 0xFF, 0xFF, 0x01, 0x02, 0x04, 0x03, 0x11, 0x04, 0x00, 0x40 };
rgbyteCompressed.insert (rgbyteCompressed.begin() + 2, marker_lse, marker_lse+15);

This should be done only if:

- the image was encoded as exactly 16 bits per sample

- you know the image was encoded with JAI

- the image does not already contain an LSE marker segment.


To check if the image already has an LSE marker segment, JlsReadHeader can be used to scan the Jpeg-LS header (prior to modifying it) and check the value custom.T1. If it is nonzero, that means the image already contains an LSE marker that specifies T1-3. That could be done by future JAI implementations, to ensure that new images are valid JPEG-LS, and still readable by old version of their own library (assuming they implemented the LSE marker). It could also mean that earlier in the chain, someone has applied this fix.

After patching the compressed bitstream, it is now a valid JPEG-LS bitstream and should be decodable by conformant JPEG-LS implementations (like CharLS).

Nov 9, 2010 at 10:52 PM

1.0 Release is here!

In the last weeks, I have used my scarce spare time to verify and close remaining issues, and make occassional fixes. Actually, It took me a week to find a spare hour to write the release notes.  But the 1.0 release is here now. See the downloads section for details.

Next feature I'll work on will be large image support (bigger than 65K squared), and stream-to-stream compression. That's a nice feature for 1.1.

Jan 14, 2011 at 7:00 AM

There is a new version of the OFFIS DICOM toolkit (3.6.0) that uses CharLS for JPEG-LS compression/decompression.  

You can download it at: