mozjpeg vs. libjpeg-turbo for on-demand web asset recompression

[lilith]

My use case is essentially an image resizing and re-compressing HTTP proxy.

Jpeg decompression speed matters a lot here, as input images can be orders of magnitude larger than output size. Jpeg compression speed isn't as important.

Does mozjpeg sacrifice decoding speed? If so, to what extent?

[jrmuizel]

Progressive JPEGs will be slower to decode than sequential ones. Other than that, decoding speed will dominated by resolution and file size.

[kornelski]

You can try yourself with tjbench bundled with mozjpeg/libjpeg-turbo:

 tjbench file.jpg

On my machine (3Ghz i7) mozjpeg-produced progressive file decodes at 72Mpx/s, and baseline (non-progressive) at 97Mpx/s.

To put it in perspective it's 128ms and 95ms to decode a full-screen JPEG on a "4K" display.

[dcommander]

@nathanaeljones It depends on a variety of factors, but if you are creating an image resizing proxy, then compression performance must be of at least some importance. It may not be as important as decompression, but please note that the compression slow-down in mozjpeg vs. libjpeg-turbo is severe-- as much as 50x. mozjpeg is not, under any stretch of the imagination, going to compress images quickly-- its compression performance is in fact many times worse than the unaccelerated IJG libjpeg.

Now, speaking specifically about decompression, I have observed that when an image is encoded using trellis quantization (using mozjpeg), that image does decompress more quickly than an image encoded without using trellis quantization (using libjpeg-turbo), but the tradeoff with compression performance is not very favorable. Some specific examples:

• If you start with a baseline JPEG image, adding multi-pass (optimized) entropy coding (supported by both libjpeg-turbo and mozjpeg) will improve the compression ratio by ~1-13% (average ~5%) on our test images (http://www.libjpeg-turbo.org/About/Performance), and decompression performance will be improved by ~2-11% (average ~6%), but compression performance will drop by about half.
• If you start with a baseline JPEG image, adding trellis quantization (supported only by mozjpeg) will improve the compression ratio by ~10-18% (average ~13%), and decompression performance will be improved by ~4-12% (average ~9%), but compression performance will drop by ~15-40x (average ~25x.) So you're sacrificing as much as 98% of your compression performance for only a few percent more decompression performance.
• If you start with a baseline JPEG image, switching to progressive entropy encoding with multi-pass optimization (supported by both mozjpeg and libjpeg-turbo) will improve the compression ratio by ~5-20% (average ~11%), but decompression performance will be reduced by ~65%, and compression performance will be reduced by ~90%.
• If you start with a baseline JPEG image, then switching to progressive entropy encoding with multi-pass optimization and adding trellis quantization (supported only by mozjpeg) will improve the compression ratio by ~15-25% (average ~20%), but decompression performance will be reduced by ~15-70% (average ~50%), and compression performance will be reduced by ~98% (50x.)

Conclusion: if your performance is primarily constrained by the CPU, then libjpeg-turbo will always produce the best results. If your performance is primarily constrained by the network, then there are some circumstances under which mozjpeg will produce better compression ratios, but only incrementally better, and at the expense of extremely high CPU usage. Also, it is worth noting that trellis quantization is not a lossless process, so in fact comparing results with it enabled and disabled is not a true apples-to-apples comparison.

[MrOutput]

for a use case of resizing images for the web, mozjpeg sacrifices encoding performance but increases decoding performance...is my understanding correct? If so, this is exactly what I need.

My main goal is decoding performance.

[kornelski]

@MrOutput yes, but as @dcommander pointed out the decoding performance is heavily affected by the choice of progressive vs baseline format. So choose one or another depending on whether you also care about download time.

If you focus strictly on decoding performance, disregarding download time, then mozjpeg still improves the situation slightly, but for this case use non-progressive JPEG.

For the web use case, where the total time to download and decode is important performance, then use MozJPEG with progressive (default), because the overall time is generally dominated by download time, and progressive further reduces amount of data to download.

[MrOutput]

@pornel thank you, I will use MozJPEG and progressive format then.