Using Mozjpeg to Create Efficient JPEGs | Hacker News Reader

Using Mozjpeg to Create Efficient JPEGs

hacks.mozilla.org

58 pointsrnyman26 comments

I am waiting until 3.0 when they roll out their plan for ABI compatibility (it currently masquerades as jpeg62 but is not compatible), and decide on a defacto way to detect if you are building against vanilla libjpeg(-turbo) or mozjpeg (currently you can check for some of their struct members, but they have not stated if they will be going away or not when ABI compatibility is addressed).

At that point I plan to submit a patch to ImageMagick to detect it and enable the user options if mozjpeg is being used. I believe downstream support in libraries like ImageMagick is key to adoption, rather than adding makeup to a pig (input support for N formats in cjpeg).

Robert at Mozilla here. I'd love to talk more, how do I best reach you? Or you can e-mail me at firstname [at] mozilla [dot] com

Hey, I'm 'Daemon404' on FreeNode and Mozilla IRC, or you can grab my FOSS email from my GitHub account or FFmpeg/Libav's git repo.

Thanks, emailed

It's interesting that Mozilla has chosen to use an image with so much red, which makes JPEG (at their settings) look relatively poor even at quality 100. You cannot optimise the limitations of 2x2 chroma subsampling.

I am also not convinced by Trellis yet. In my tests, it introduced a faint blur. In fairness though, I only tried 4:4:4 and not 4:2:0 as Mozilla apparently does. In the latter case, additional blur may not be noticeable.

You can 'optimize' encode-time by using better chroma downsampling, but really the issue is usually on the client side upsampling (a lot of libs use terrible nearest neighbor for 'speed').

As for trellis, you should play with the different metrics available (MS-SSIM etc), but I agree I have not been wowed yet.

Yes, optimise is the wrong word. I meant optimise away really, but that's still not quite right. The WebP authors are actually working on improving chroma subsampling, because VP8 limits WebP to 2x2.

mozjpeg has such a bug opened too: https://github.com/mozilla/mozjpeg/issues/8

This isn't exactly new ground beign covered here, nor is it tied to one image format, so I wish people would be a little less NIH-y sometimes...

I'd love to be able to use jpegoptim or mozjpeg but the trouble is choosing the right quality level. As Steve Souders says in his comment on TFA, it's not possible to experiment with varying quality levels when you have hundreds of images to optimize.

Because we haven't been able to solve that problem yet, we use JPEGmini, a proprietary (but not that expensive) vendor solution.

You ought to take a look at jpeg-archive: https://github.com/danielgtaylor/jpeg-archive (the bbcq-like is similar to jpegmini's weighting).

If you'd like to test how the latest Mozjpeg performs check us out at https://kraken.io/web-interface and choose "lossless".

We've already implemented this in http://filepicker.io so you don't need to do anything if you are already on the service.

Any chance of Mozilla releasing a node.js plugin that wraps the library?

I'd also be really interested in an ASM compiled version that's easy to use from node (and possibly the browser).

Anyone have more details on exactly what cjpeg does? What sets this apart from a solution like JPEGoptim?

Mozilla recently improved the JPEG encoder. They claim 5% smaller files then libjpeg-turbo. https://news.ycombinator.com/item?id=8036959

jpegoptim optimizes Huffman tables. Mozjpeg's cjpeg always does it, plus:

* jpegcrush/jpegrescan trick: tweaks details of progressive JPEG for maximum compression (each scan gets its own Huffman table, and JPEG can arbitrarily divide data into scans). That's 5%-10% improvement over jpegoptim.

* if you're creating a new JPEG or lowering quality of an existing one, then it uses trellis quantization. In the lossy compression step instead of naively throwing away data, it evaluates lots of combinations to find best bang-for-the-buck combination. That's an extra 5% improvement in quality/filesize ratio.

"cjpeg" is the basic command-line tool for making use of the mozjpeg library to create JPEG images.

libjpeg-turbo and IJG JPEG libraries also have "cjpeg" tools as their basic command-line encoder. The tool for mozjpeg works almost exactly the same way, but it has some extra option flags, can take JPEG input (the others can't), and re-defines the "-baseline" option to something more intuitive (see v2.1 release notes).

I've not seen significant ( > ~1%) improvement over jpegoptim.

How does mozJPEG compare with WebP in terms of size with the same quality?

Hate progressive jpegs. Always sit there and squint for a second with Google images till a second later when hi-res pops-in. Just let it render and I'll take the 4% efficiency hit.

You can use progressive jpegs without progressive rendering. Google images isn't even using this, they are displaying a very low-res photo immediately, and loading a higher quality one in the background.

(and FYI, most sites that optimize their images (e.g. Facebook) use progressive jpegs for efficiency).

Just what your designer always wanted - a command line tool to create jpegs!

The designer will usually provide very high quality PNG's/PSD's. It's up to the developers to scale it down to the optimal size for each device.

I agree, and as stated in my other comment, I believe it needs downstream support to be adopted properly.

To that end I plan to add support to ImageMagick, and perhaps write a PS plugin.

Pngout, optipng, deflopt, jpegtran, gifsicle, cwebp, zopfli, and so forth are all command line tools.

I'm not really sure why you think that this stuff is meant for designers. Recompressing images is a frontend optimization. It's something you automate. It's a task for machines, not humans.

If you care about jpeg size you're probably already using a build/preprocessing system on your assets. This is just another tool in the chain.

Reply on news.ycombinator.com