Truly Lossless JPEG2000 Compression
This posting used to have the tag "-- Except for Grayscale?" appended to the end of the title. That is no longer needed; see the bottom of the post for an explanation. We have been implementing University of Michigan's DLXS software, and DLXS uses JPEG2000 for its image masters. We have been investigating reports of perceived changes in images in the conversion from our old media server to DLXS, and along the way I discovered an important fact: the default parameters for two popular JPEG2000 codecs results in an irreversible transformation. Here is how to address that.
Testing For Equivalence
We performed four tests to determine whether the source image was equivalent to the converted image. Three tests use Photoshop:
- On a pixel-by-pixel basis, at high magnification, we looked for differences in the RGB and CMYK values between the source TIFF and the converted JPEG2000 image.
- Comparison by copying and pasting the JP2 on top of the TIF image and selecting "Difference" blending mode between the layers. We then look at the histogram of the resulting image. It should be all black, which shows as a black bar on the far left of the histogram view with the mean, median and standard deviation values all exactly 0.
- Using "Images > Calculations..." with 100% opacity difference blending between source images (the TIFF and the JP2) with the results put into a new document shows in a completely black image. (This is likely equivalent to the test above, but we do it just to be sure).
Another test uses geoimgcmp, which is part of GeoJasPer version 1.3.2. This command should return "0":
1 | |
Jasper via ImageMagick
The first thing we tried was Jasper 1.701 as compiled into ImageMagick 6.2.9. The command looked something like this:
1 | |
I ran though the tests, though, and it would appear Jasper/ImageMagick is not using the reversible (integer) wavelet transform.
Kakadu
Next we tried Kakadu. Although it is commercial software, it is relatively inexpensive and we acquired a developer's license for our work on the Ohio Digital Resource Commons. A straight compress doesn't get one a reversible transformation:
1 | |
A colleague did offer some help in the form of parameters that he uses to achieve truly lossless compression:
1 2 | |
The parameters mean this (from the Kakadu usage documentation):
Creversible=yes- Reversible compression?
-rate -,1,0.5,0.25- One or more bit-rates, expressed in terms of the ratio between the total number of compressed bits (including headers) and the product of the largest horizontal and vertical image component dimensions. A dash, "-", may be used in place of the first bit-rate in the list to indicate that the final quality layer should include all compressed bits. Specifying a very large rate target is fundamentally different to using the dash, "-", because the former approach may cause the incremental rate allocator to discard terminal coding passes which do not lie on the rate-distortion convex hull. This means that reversible compression might not yield a truly lossless representation if you specify `-rate' without a dash for the first rate target, no matter how large the largest rate target is.
Clevels=5- Number of wavelet decomposition levels, or stages.
Note that this implies this important default as well.
Corder=LRCP- Default progression order. The four character identifiers have the following interpretation: L=layer; R=resolution; C=component; P=position. The first character in the identifier refers to the index which progresses most slowly, while the last refers to the index which progresses most quickly.
Conclusions
- Although one might expect the default options for image conversion programs to be lossless, ImageMagick's 'convert' and Kakadu's 'kdu_compress' commands do result in lossy transformations.
- For our sample images, using the Kakadu command line options "
Creversible=yes -rate -,1,0.5,0.25 Clevels=5" do appear to result in lossless transformations for source TIFF images.
Thanks go out to Rob Buckley, Ron Murray, Kevin DeVorsey, Greg Coats, and David Taubman for their help in figuring this out.
4-May-2007 Update
There used to be a third conclusion above that said: "For our sample greyscale images, we have not yet found a way to perform a lossless transformation to JPEG2000 when a downstream derivative is JPEG; there are perceptible differences between the JPEG created from the TIFF file versus the JPEG created from the losslessly compressed JPEG2000 file." David Taubman's message on the Kakadu mailing list caused me to go back and look at this again. I think I found an error in the way I was creating the test images. With that fixed, I can show empirically that a JPEG derived from the lossless JP2 is exactly the same as the JPEG derived from the TIFF (when using identical parameters for the conversion). That, along with the earlier finding that the TIFF and the JP2 are identical would seem to mean that the differences in the RGB/CMYK values displayed in Photoshop were a red herring.
In response to the question of the lossy settings as a default, Dr. Taubman also notes "that quality is somewhat better (particularly at reduced resolutions) when viewing lossy compressed images using the irreversible options rather than the reversible." There are reasons for this, primarily due with what I understand as the elimination of image signal noise through through the act of lossly compression, but they are too complicated to address in this already-too-large correction text.
The text was modified to update a link from http://wordnet.princeton.edu/perl/webwn?s=red+herring to http://wordnetweb.princeton.edu/perl/webwn?o2=&o0=1&o7=&o5=&o1=1&o6=&o4=&o3=&s=red+herring&i=1&h=1000#c on January 20th, 2011.
The text was modified to remove a link to http://homepage.mac.com/gregcoats/jp2.html on November 8th, 2012.