Recent Changes - Search:

libjpeg-turbo Home

About libjpeg-turbo




Position Statements

Developer Info


Part 1: Lossless SmartScale

<< | Introduction | Part 2: Quality vs. Size >>

Test Images

artificial.ppm: Ray-traced scene from (8-bit version, 3072 x 2048 pixels.)

nightshot_iso_100.ppm: Photographic content from (8-bit version, 3136 x 2352 pixels.)

vgl_6434_0018.ppm: A frame capture from the Pro/ENGINEER Viewperf test. This frame represents an exploded rendering of a race car with smooth shading and lighting (1240 x 960 pixels.)

The collection of photographic images from, tested as an aggregate group (768 x 512 or 512 x 768 pixels, 24 images.)

Test Platform

  • Dell Precision T3500
  • 2.8 GHz quad-core Intel Xeon W3530
  • 4 GB memory
  • CentOS Enterprise Linux 5.8

Test Methodology

jpeg-8d was used to encode each test image into a lossless SmartScale file, using the IJG's recommended switches:

cjpeg -rgb -block 1 -arithmetic

With jpeg-9, an additional color transform was added which claims to significantly improve the compression, so this was evaluated as well. The switches used in jpeg-9 were:

cjpeg -rgb1 -block 1 -arithmetic

The performance/compression ratio tradeoff of arithmetic encoding was also evaluated. In all cases, the -arithmetic switch provided significantly better performance and compression, so the Huffman results are not included below.

For comparison, cwebp v0.2.1 was used to compress the source images into the webp format. The best-performing settings for lossless encoding were used:

cwebp -lossless -q 0 -m 0

Since cwebp cannot read PPM files, a PNG file with no compression was generated for each test image, in order to make the overhead of reading the input image match that of the JPEG and PNG cases as much as possible.

For comparison, Thomas Richter's JPEG-LS implementation, hereafter referred to as "jpeg-ls", was used to compress the source images into the JPEG-LS format. The following settings were used:

jpeg -c -ls 0 -cls

For comparison, Microsoft's jxrlib was used to compress the source images into the JPEG XR format. The default settings in JxrEncApp were used.

For the performance metrics, the execution time of the encoder program was measured using the Un*x time command, and the result represents the average of 5 runs in which no significant variations were observed.

To obtain the most consistent performance, only 1 CPU core was used.

jpeg-8d, jpeg-9, jpeg-ls, libwebp, and jxrlib were built with 64-bit code and maximum compiler optimizations (-O3.)


 artificial.ppmnightshot_iso_100.ppmvgl_6434_0018.ppmKodak images
 Comp. ratioTime (s)Comp. ratioTime (s)Comp. ratioTime (s)Comp. ratioTime (s)
PNG quality=65.0651.153.0921.654.9080.221.7112.47
PNG quality=7511.121.292.8318.4611.500.241.7856.41
PNG quality=9011.280.971.8332.3112.570.231.5992.99
JPEG XR4.5700.752.7551.373.3200.172.2041.49

With the exception of the Kodak images, it was always possible to find a PNG mode that compressed both better and faster than lossless SmartScale, although doing so required some foreknowledge of the image type. Apparently, the computer-generated content responded better to higher zlib levels, and the photographic content responded better to a higher level of filtering. The overall level of compression with the jpeg-9 implementation of lossless SmartScale was, in the aggregate, similar to that of the "default" PNG settings in ImageMagick, so this newest iteration of lossless SmartScale does at least demonstrate an adequate compression ratio to compete with PNG. However, it should be noted that this newest lossless SmartScale variant requires jpeg-9. It and the previous iteration of the SmartScale format are not standards, and no one really knows whether or how they might change in the future.

Furthermore, comparison with JPEG-LS, which is a standard, revealed only one case in which lossless SmartScale produced a higher compression ratio-- 12% higher on vgl_6434_0018.ppm, and jpeg-9 took twice as long as jpeg-ls to achieve this. There was also only one case in which jpeg-9 was able to compress significantly faster than jpeg-ls-- 18% on nightshot_iso_100.ppm, but jpeg-9 also produced a proportionally lower compression ratio on the same test.

jpeg-9 generally compressed the computer-generated content quite a bit better than JPEG XR did, but it was also proportionally slower. On the photographic content, the compression ratios were similar between jpeg-9 and JPEG XR, but JPEG XR was 3-5 times as fast as jpeg-9

The performance of the SmartScale encoder needs a lot of improvement before lossless SmartScale could reasonably be used as a substitute for PNG. Theoretically, this could be done by implementing similar types of SIMD optimizations to the ones used in libjpeg-turbo or even by extending the existing SIMD extensions to accommodate the new block sizes. Accelerating the arithmetic entropy codec would also be necessary. This work, although feasible, would represent a significant undertaking. Even if it were possible to accelerate the encoding of SmartScale by 2-4x, as was achieved with baseline JPEG in libjpeg-turbo, the resulting performance for the above images would still only be in the range of 3-7 Megapixels/second, which is not sufficient for streaming or remote display purposes. The resulting performance would also be no better than libpng.

webp proved to be the codec to beat in terms of compression ratio. Its performance was significantly slower than libjpeg on nightshot_iso_100, but on the rest of the images, it performed in the ballpark of libjpeg, and it compressed much better in all cases.


Lossless SmartScale is clever, but it does not generally accomplish anything that can't already be accomplished better with webp, and in most cases, the same task can also be accomplished as well or better, and more quickly, using PNG. Furthermore, the performance and compression ratio of lossless SmartScale are generally worse than that of the JPEG-LS standard, and in the isolated cases in which they aren't, lossless SmartScale provides either an equal or worse performance vs. compression ratio tradeoff.

Given that the new structure field in jpeg-9 was added solely to support the "subtract green" color transform for lossless SmartScale, the above research calls into question whether that feature was worth breaking backward ABI compatibility with jpeg-8. In fact, the new color transform could have been implemented as an additional JPEG colorspace constant without breaking ABI compatibility.

<< | Introduction | Part 2: Quality vs. Size >>

Creative Commons LicenseAll content on this web site is licensed under the Creative Commons Attribution 2.5 License. Any works containing material derived from this web site must cite The libjpeg-turbo Project as the source of the material and list the current URL for the libjpeg-turbo web site.

Edit - History - Print - Recent Changes - Search
Page last modified on August 18, 2017, at 04:44 PM