Using the five images described in [this article](https://libjpeg-turbo.org/About/Performance), I compared ``` TJ_OPTIMIZE=1 tjbench {image} 95 -rgb -quiet -progressive ``` with ``` TJ_ARITHMETIC=1 tjbench {image} 95 -rgb -quiet -progressive ``` (NOTE: you can add `-benchtime 0.001 -warmup 0` to speed things up, if you just want to measure the compression ratio rather than the performance. Replace `-quiet` with `-qq` to generate spreadsheet-friendly results.) Compression ratio improvement with progressive arithmetic coding vs. optimized progressive Huffman coding was 2.4-10.2% (average 7.7%.) For the set of [Kodak test images](http://r0k.us/graphics/kodak), compression ratio improvement with progressive arithmetic coding vs. optimized progressive Huffman coding was 1.7-8.8% (average 5.2%.)
Bug 680385 Comment 31 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Using the five images described in [this article](https://libjpeg-turbo.org/About/Performance), I compared ``` TJ_OPTIMIZE=1 tjbench {image} 95 -rgb -quiet -progressive ``` with ``` TJ_ARITHMETIC=1 tjbench {image} 95 -rgb -quiet -progressive ``` (NOTE: you can add `-benchtime 0.001 -warmup 0` to speed things up, if you just want to measure the compression ratio rather than the performance. Replace `-quiet` with `-qq` to generate spreadsheet-friendly results.) Compression ratio improvement with progressive arithmetic coding vs. optimized progressive Huffman coding was 2.4-10.2% (average 7.7%.) For the set of [Kodak test images](http://r0k.us/graphics/kodak), compression ratio improvement with progressive arithmetic coding vs. optimized progressive Huffman coding was 1.7-8.8% (average 5.2%.) For the complete set of [8-bit RGB test images](http://imagecompression.info/test_images) (the aforementioned set of five test images I typically use contains two of these), compression ratio improvement with progressive arithmetic coding vs. optimized progressive Huffman coding was 3.0-12.1% (average 7.9%.) The image with 12.1% improvement (spider_web.ppm) was an outlier. Without that image, the improvement was 3.0-10.4% (average 7.7%), which was very similar to the results from the set of five test images I use. (NOTE: that's why I use those images. Even though the origin of the first three images is somewhat odd, those five images have historically proven to represent a good range of "typical" JPEG codec behavior.)
Using the five images described in [this article](https://libjpeg-turbo.org/About/Performance), I compared ``` TJ_OPTIMIZE=1 tjbench {image} 95 -rgb -quiet -progressive ``` with ``` TJ_ARITHMETIC=1 tjbench {image} 95 -rgb -quiet -progressive ``` (NOTE: you can add `-benchtime 0.001 -warmup 0` to speed things up, if you just want to measure the compression ratio rather than the performance. Replace `-quiet` with `-qq` to generate spreadsheet-friendly results.) Compression ratio improvement with progressive arithmetic coding vs. optimized progressive Huffman coding was 2.4-10.2% (average 7.7%.) For the set of [Kodak test images](http://r0k.us/graphics/kodak), compression ratio improvement with progressive arithmetic coding vs. optimized progressive Huffman coding was 1.7-8.8% (average 5.2%.) For the complete set of [8-bit RGB test images](http://imagecompression.info/test_images) (the aforementioned set of five test images I typically use contains two of these), compression ratio improvement with progressive arithmetic coding vs. optimized progressive Huffman coding was 3.0-12.1% (average 7.9%.) The image with 12.1% improvement (spider_web.ppm) was an outlier. Without that image, the improvement was 3.0-10.4% (average 7.7%), which was very similar to the results from the set of five test images I use. (NOTE: that's why I use those images. Even though the origin of the first three images is somewhat odd, those five images have historically proven to represent a good range of "typical" JPEG codec behavior.) As far as disk space, that's the raison d'etre for mozjpeg. It's intended as an offline tool for recompressing and optimizing existing JPEG images to save space. By combining optimized progressive Huffman coding with other techniques (trellis quantization, etc.), mozjpeg generally produces smaller JPEG files than can be produced using progressive arithmetic coding, and the files it produces are compatible with any browser. However, the tradeoff is that generating those files is extremely slow compared to generating "plain" optimized progressive Huffman images using libjpeg-turbo.