Recent Changes - Search:

libjpeg-turbo Home

About libjpeg-turbo

Downloads

Documentation

Reports

Position Statements

Developer Info

Contact

Performance

This article compares the performance of libjpeg-turbo with libjpeg and with the Intel® Integrated Performance Primitives (Intel® IPP), one of the most popular proprietary JPEG codecs on the market.

Test Images

vgl_5674_0098.ppm: A frame capture from the 3D Studio Max Viewperf test. This frame represents a movie set with significant wireframe and texture content (1240 x 960 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.)

vgl_6548_0026.ppm: A frame capture from the UGS NX Viewperf test. This frame represents a grayscale wireframe rendering of an engine block with partial transparency (1240 x 960 pixels.)

artificial.ppm: Ray-traced content from http://www.imagecompression.info/test_images/ (8-bit version, 3072 x 2048 pixels.)

nightshot_iso_100.ppm: Photographic content from http://www.imagecompression.info/test_images/ (8-bit version, 3136 x 2352 pixels.)

The Viewperf frame captures, which can be downloaded from here, are meant to represent workloads that might be encountered by VirtualGL and TurboVNC. They were chosen because, as a group, they contain a variety of frequencies and color counts, and quantitatively, they were among the most difficult Viewperf frame captures to compress. They all had below-average compression ratios, but none of them were corner cases.

The photograph was chosen because its performance was typical of other photographic images in the test image set. The ray-traced image was chosen for its high color count. In general, the ray-traced image performed similarly to the Pro/E frame capture, so future tests may omit the latter.

Test Methodology

For each test image, the tjbench program (available in the libjpeg-turbo distribution) was used to measure the compression and decompression performance and the compression ratio obtained when compressing the test image as a JPEG image and then decompressing the JPEG image back to its original, uncompressed form. tjbench measures these metrics for four chrominance subsampling settings: grayscale, 4:2:0, 4:2:2, and 4:4:4. The following tjbench command-line options were used:

tjbench {image} 95 -rgb -qq

For comparison, tjbench was built and run against the (now obsolete) TurboJPEG/IPP library, which implements the TurboJPEG API on top of the Intel® Integrated Performance Primitives (actually, an older version of tjbench, called jpgtest, was used, since it still supports the legacy version of the TurboJPEG API used by TurboJPEG/IPP.)

Additionally, the TurboJPEG wrapper library from libjpeg-turbo was built against libjpeg v6b and v8d, and tjbench was thus used to test the performance of those libraries. A repository of the IJG code releases with TurboJPEG and tjbench added can be found here.

Results

The raw data can be found in the following spreadsheet: libjpegturbo-1.3.ods

libjpeg-turbo Speedup Relative to Other Codecs, Non-Grayscale Compression/Decompression (1.0 = equal performance)
 libjpeg-turbo x86-64libjpeg-turbo x86
 CompressionDecompressionCompressionDecompression
libjpeg v6b3.68 - 5.292.12 - 3.323.40 - 4.752.43 - 4.24
libjpeg v8d3.66 - 5.791.95 - 3.853.19 - 5.222.29 - 4.96
Intel® IPP v7.10.922 - 1.210.811 - 1.180.710 - 1.100.650 - 1.26

In the most general terms, libjpeg-turbo is 2.1 - 5.3x as fast as libjpeg v6b and 2.0 - 5.8x as fast as libjpeg v8d. libjpeg-turbo is also 81 - 121% as fast as Intel® IPP when using x86-64 code and 65 - 126% as fast as Intel® IPP when using x86 code.

libjpeg-turbo's primary weakness relative to IPP is 32-bit performance, particularly on Intel processors and even more particularly on legacy Intel processors. This is largely due to the Huffman encoder/decoder running out of registers and having to swap some inner loop variables back and forth from memory. The Huffman codec optimizations in libjpeg-turbo reduced this effect somewhat, but it could not be eliminated entirely. Another weakness of the libjpeg-turbo codec is subsampling. In general, it takes more of a relative hit from enabling chrominance subsampling than IPP does. The other area in which IPP excels is compressing high-frequency content, such as images with sharp lines. Thus, the disparity between IPP and libjpeg-turbo is the most pronounced on the 3D Studio Max image and the least pronounced on the photograph and the ray-traced image. All of these represent potential areas for improvement in libjpeg-turbo.

IPP has some weaknesses, however. Perhaps the most notable is that the 64-bit version requires SSE3 code in order to perform optimally, so libjpeg-turbo will have a clear advantage on older Opteron and Athlon64 systems that lack the SSE3 instruction set.

Fast Upsampling and Fast IDCT

The TurboJPEG wrapper library, which was used when benchmarking libjpeg-turbo, is configured to use settings that duplicate, as closely as possible, the image quality of Intel® IPP. Thus, the fast integer forward DCT, the slow integer inverse DCT, and slow (AKA "fancy" or "smooth") chrominance upsampling are enabled in the underlying libjpeg API (NOTE: the TurboJPEG wrapper uses the slow integer forward DCT for JPEG qualities 96-100, but the above tests were all conducted with quality=95.)

Enabling fast (AKA "merged") chrominance upsampling in the decompressor improved decompression performance for chrominance-subsampled JPEGs by as much as 15-20% relative to the results above. Whether or not the quality loss from merged upsampling is noticeable depends on the image. As the name implies, "smooth" upsampling averages out the subsampling error in the chrominance planes, but this can also reduce the sharpness of lines and other high-frequency features in the image. Merged upsampling can sometimes produce a sharper output image, but one in which the subsampling error is more visible. Enabling fast chrominance upsampling can be accomplished by passing a flag of TJ_FASTUPSAMPLE to tjDecompress*() (TurboJPEG API) or by setting cinfo.do_fancy_upsampling=TRUE (libjpeg API.)

Enabling the fast IDCT in the decompressor improved decompression performance across the board by 3-13%, relative to the results above, with very little overall loss in quality. Enabling the fast IDCT can be accomplished by passing a flag of TJ_FASTDCT to tjDecompress*() (TurboJPEG API) or by setting cinfo.dct_method=JDCT_FASTEST (libjpeg API.)

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 December 20, 2014, at 03:54 AM