
Experimenting with Mozjpeg 2.0 - jgrahamc
http://blog.cloudflare.com/experimenting-with-mozjpeg-2-0
======
kyriakos
Summary: mozjpeg slightly better than libjpeg-turbo but slower to compress.

cloudflare assigned an engineer to optimize the library for speed and they
plan to contribute the optimizations back.

~~~
jgrahamc
I don't understand the point of this type of comment. It's a summary of
something short (that didn't need a summary) and it misses critical
information.

~~~
kyriakos
what jewel said. I always read comments first.

~~~
sp332
It doesn't really need a "summary" though. Maybe you could add something to
the conversation? Like "Oh, I didn't know libturbo was that slow" or "I'm glad
Cloudflare is contributing back to the project."

~~~
ehsanu1
It doensn't "need" a summary. But it's nice for those of us who check comments
before bothering with the actual article.

------
pornel
They're sticking to lossless optimizations, so they're only benefiting from
the "jpegcrush" part of mozjpeg that chooses separation of progressive scans
for best compression.

The difference would be bigger if they used mozjpeg for lossy (re)compression
as well, as then they'd also get trellis quantization.

~~~
jgrahamc
Polish also does lossy compression if the user selects it. This blog post
looked at mozjpeg performance in the 'lossless' case.

~~~
joshmoz
I don't think that fact that you're only looking at lossless compression is
clear enough in the post. People see "JPEG" and "compression" and they assume
you're talking about lossy compression. The post doesn't include the word
"lossless" to describe what you're doing, people have to figure it out.

Happy to hear you're seeing benefits from mozjpeg, and I look forward to the
results of your work optimizing run-time performance. Thanks for giving
mozjpeg a shot, publishing your results, and contributing back!

------
frik
The last paragraph mentions that Cloudflare uses LuaJIT (and C++ Aho-
Corasick).

Cloudflare uses the OpenResty web server (Nginx+LuaJIT), that's quite
interesting: [http://blog.cloudflare.com/pushing-nginx-to-its-limit-
with-l...](http://blog.cloudflare.com/pushing-nginx-to-its-limit-with-lua).
OpenResty is one of the top performing web servers in this well known
benchmark:
[http://www.techempower.com/benchmarks/](http://www.techempower.com/benchmarks/)
, [http://openresty.org/](http://openresty.org/)

------
jsnell
The zlib fork with "massive performance improvements" appears to perform worse
than the earlier and actively developed zlib performance patch set from Intel
[1]. Why start from scratch?

[1] [https://github.com/jtkukunas/zlib](https://github.com/jtkukunas/zlib)

~~~
Ono-Sendai
I noticed they had a zlib fork as well. The Zlib team (mark adler?) hasn't
merged in the intel patches as far as I know. Maybe someone needs to make some
kind of official fork of zlib, development on it seems to be stalled.

------
skal65535
Mozjpeg's gain come partly from using progressive JPEG encoding, which is also
available in libjpeg-turbo. See the post [http://www.libjpeg-
turbo.org/About/Mozjpeg](http://www.libjpeg-turbo.org/About/Mozjpeg) from
libjpeg-turbo's author. And actually, the photo_3.jpg picture in the blog-post
_is_ progressive jpeg. So the command line for a fair comparison should
probably be: jpegtran -outfile out.jpg -optimise -copy none -progressive
in.jpg

~~~
jgrahamc
Thanks for pointing this out. I went back in and checked and I was using the
-progressive option on the jpegtran command and so the comparison was done
with -progressive.

However, when I generated the image in the blog post I didn't do that and so I
have rerun it. Updating the blog post now.

~~~
skal65535
oh, ok. Thanks for the update!

------
pdknsk
I've done some limited tests myself, and I'm not convinced by mozjpeg (yet).
While savings can be quite significant, up to 10% for large images, there is
definitely quality loss, albeit minor. Trellis seems to lay a faint blurriness
over the whole image. I admit it's difficult to notice at 1:1 resolution and
objectively a good trade, but I'm still wary and will wait for further
improvements.

------
Siecje
So switch to mozjpeg 2.0? You only need to compress once. You have to serve
the file many times, and it reduces storage space.

~~~
jgrahamc
Yes, but we'd pay the price of higher CPU.

~~~
kyriakos
If by 'we' you mean the users, I don't think it makes any difference to the
decoding process.

~~~
ominous_prime
'we' in this case means cloudflare, where jgc is employed

------
bhouston
I am very curious about the zlib improvements. I would like to see more
details about that.

