libjpeg-turbo | About / Performance

NOTE: This article describes the performance of libjpeg-turbo 1.1.0, but there were no significant performance changes between it and the current version, so the data should still be valid. jpgtest is now called tjbench.

The performance of libjpeg-turbo was measured using the jpgtest program (available in the libjpeg-turbo 1.1.0 distribution, as well as in the VirtualGL and libjpeg-turbo source repositories) and a series of test images, which are described below. The 3D test images can be downloaded from here.

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.)

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

The 3D frame captures were chosen because they represent workloads that are difficult for JPEG to compress. Thus, they have below average compression ratios, but none of them are corner cases. The photograph was chosen because its performance was typical of other images in the test image set.

The raw data can be found in the following spreadsheet: libjpegturbovsipp.ods

General Performance Notes

For non-grayscale JPEG compression and decompression, libjpeg-turbo is between 1.8x and 4.5x as fast as libjpeg v6b.

For non-grayscale JPEG compression and decompression, libjpeg-turbo 64-bit is between 80% and 137% as fast as TurboJPEG/IPP. libjpeg-turbo 32-bit is between 60% and 127% as fast as TurboJPEG/IPP.

libjpeg-turbo's primary weakness relative to TurboJPEG/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 optimizations performed by the VirtualGL Project 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 TurboJPEG/IPP does. The other area in which IPP excels is compressing high-frequency content, such as images with sharp lines. Thus, the disparity between TurboJPEG/IPP and libjpeg-turbo is the most pronounced on the 3D Studio Max image and the least pronounced on the photograph. All of these represent areas that could benefit from further optimizations.

TurboJPEG/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

One important note about image quality and performance: The TurboJPEG/OSS library, which was used for all of the benchmarks on this page, is configured to use settings that duplicate, as closely as possible, the image quality of TurboJPEG/IPP. Thus, the fast integer forward DCT, the slow integer inverse DCT, and slow chrominance upsampling are used in libjpeg (NOTE: TurboJPEG/OSS uses the slow integer forward DCT for JPEG qualities 96-100, but these tests were all conducted with quality=95.) Significant decompression performance (at the expense of increased subsampling artifacts) can be gained on chrominance subsampled images by enabling fast (AKA "merged") chrominance upsampling. This is accomplished by passing a flag of TJ_FASTUPSAMPLE to tjDecompress() (TurboJPEG) or by setting cinfo.do_fancy_upsampling=FALSE (libjpeg.)

Restart Markers

The Huffman decoding optimizations in libjpeg-turbo do not handle restart markers in a way that makes libjpeg happy, so they are automatically disabled when decompressing a JPEG image that has restart markers. This can cause the 64-bit decompression performance to drop by as much as 15% and the 32-bit decompression performance to drop by as much as 20%. Since many consumer packages, such as PhotoShop, use restart markers when generating JPEG images, this prevents images generated by such packages from achieving full decompression performance with libjpeg-turbo (although they will still decompress much faster than with libjpeg v6b.)