MozJPEG 3.0 | Hacker News Reader

MozJPEG 3.0

calendar.perfplanet.com

290 pointsssttoo64 comments

I'm reminded here that JPEG includes arithmetic encoding as part of the standard, but almost everyone uses Huffman because up until a couple years ago arithmetic encoding was patent-encumbered (the patents are expired now). Is anyone aware of a study like Mozilla's that considers JPEG-with-arithmetic-encoding? Or perhaps it does, and I failed to notice?

Most competing file formats seem to beat JPEG by only a slim margin, and what I've read on arithmetic encoding suggests it gives a ~5-10% gain, which would make that difference slimmer still, perhaps vanishing into the uncertainty of the usefulness of these quality benchmarks. Of course, there would be inertia to overcome to support it, as with a new format, but recompiling everyone's libjpeg is surely less work than adding support for whole new file formats. At the very least, it seems there might be a better effort/payoff ratio.

https://encrypted.google.com/search?q=arithmetic+encoding

If you're going to break backwards compatibility it would be better to spend the pain on a modern format instead of reviving an arcane and previously unimplemented part of the old JPEG. Like the article admits, we know how to do significantly better now, so a patent free HEVC alternative would be the logical target.

According to other comments and a mozilla bug[1] most/all browsers dont even support decoding these jpegs.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=680385

JPEG is absolutely awesome and this is a valuable addition.

I was using the very first release of the source back in the stone age or so. We took passport photo images with a video camera at reasonably high resolution and then scaled them down and compressed with PCX to save on storage.

Quality after compression was absolutely terrible.

Then Tom Lane came along with libjpeg and suddenly the quality was better than what we could print!

Too late to edit: PCX is lossless, what we did was reduce the higher frequency bits in the images before using PCX in order to achieve a reasonable compression ratio, in effect making a lossy wrapper around PCX. It was a pretty crude way of making this work and JPEG was so much better that it is hard to believe we managed to sell our customers on the original version. I should see if I can dig up some of those old images, they're interesting historically.

FYI, I plan to officially release mozjpeg 3.0 tomorrow.

Thanks for the writeup and your work on this release, Kornel!

Has it been 'uplifted into Firefox nightly/incoming?

We have no plans to use mozjpeg in Firefox, it will continue to use libjpeg-turbo. The decoder that comes with mozjpeg is unmodified from libjpeg-turbo, mozjpeg is focused on compression for those serving up images.

Why not use it for canvas.toDataURL?

I am waiting for 3.0 in HomeBrew! Thanks for the awesome work, mozjpeg has saved me a fair amount of network bandwidth.

What are you using it for?

Thank you for your work. As a heads-up, I do not see any reference to -quant-table option as mentioned in the linked blog in cjepg.1 on GH.

Also, I have a little script that uses imagemagick to watermark an image and then create a resized image smaller image for web. Does mozjpeg's cjpeg support 48bpp png or is there some better way to no lose some detail due to rounding by avoiding going from 24-bit RGB out of imagemagick to YCbCr?

beautiful! I had this file sitting on my desktop in compressed JPEG format. Text JPEGs are inherently bad and spit out ugly pics:

Original - 327kb - http://i.imgur.com/DTxTcLp.jpg

MozJPEG - 127kb - http://i.imgur.com/jVESWGS.jpg

Stared at both side by side and really struggled to tell the difference. Great job!

Sorry WebP is great but I just don't see it getting adapted unless all browsers get on board as well as big software. JPEG is practically a household name, photographers, artists, insta-grammers,all know what it is and short of a mild revolution I just don't see it.

How can you not tell the difference? Look at the "Humor, empathy, resilience", the characters 'r'/'i'/'n' are damaged.

There are more in the fourth column.

You're right, really big fail on those (and a t of integration, f from of), but otherwise it seems like a really good job.

Hope they post a bug report, that doesn't look like an acceptable artefact to me

Thanks for pointing this out! Filed a bug:

https://github.com/mozilla/mozjpeg/issues/139

I said in another comment that we'd release 3.0 tomorrow, we'll probably hold up the release to investigate this.

Wow, that was fast.

They already fixed the bug. I'm impressed.

Awesome to hear that.

@joshmoz Hopefully, you can re-run the image and share it with us in case we can find something else. :D

That's a 1bit scan saved as JPEG. This should have been saved as 1bit PNG.

http://i.imgur.com/2wAcBdL.png (23.43 KB)

For nicer looking images, scan as grayscale and then use Photoshop's Image -> Adjustments -> Curves to turn everything almost-white to white and everything almost-black to black:

http://i.imgur.com/ktj8WkE.png

Alternatively, do a high-DPI 1bit scan, convert the document to 8bit, and then scale it down.

E.g. when you go from 1600 DPI to 100 DPI, you have 16x16 1bit pixels per 8bit pixel. The result will look smooth and crispy.

1-bit images should generally be saved using JBIG2 compression (as far as I know the best lossless compression scheme for 1-bit images), rather than PNG. In some cases CCITT Group 4 compression might be used, for compatibility reasons, e.g. in a TIFF wrapper.

JBIG2 might be the best compression for bitmap images, but you probably never want to use its lossy mode for text images[0]

The fact that a single difference in a configuration bit (lossy/non-lossy) can introduce subtle and easy-to-miss errors (to the point that this went unnoticed by Xerox QA and thousands of their customers!) is an indication to me that while JBIG2 might be superior in terms of the compression it offers, it's not a solution I would use without very serious consideration and deliberation.

Just to make this more clear: if you borked the compression setting on jpeg, you get smeared images. If you bork the lossy/nonlossy flag on JBIG2, you get images that look great but may have a random letter or digit swapped for another.

[0] http://www.theregister.co.uk/2013/08/06/xerox_copier_flaw_me...

thank you! and great tips. the original image was something I grabbed from the web, part of some research. either way really appreciate the tips and the info.

Deringing (removing 'noise' around text and similar shapes in jpeg-compressed images) is awesome only in itself.

Hopefully this will find its way into image authoring tools.

wonder if SmartDeblur would benefit from this, also: http://smartdeblur.net/gallery.html

would adding dithering support to the encoder help with gradient smoothness? i know it helps a lot with non-compressed formats in addition to shrinking filesize (though it may not be the case with jpeg compression). you can toy with the params [1] and see that even dropping target palette color count by >50%, still gets good results with a dithering kernel selected. repo here [2], btw.

[1] http://o-0.me/RgbQuant/

[2] https://github.com/leeoniya/RgbQuant.js

Yes, some sort of deblocking in the decoder could go a long way, e.g.

http://johncostella.com/unblock/

This isn't something that can be done on the encoding side, so it's out of scope of MozJPEG.

I do think it may be worthwhile to spec a backwards-compatible extension for decoders that adds deblocking.

You could also just modulate the lambda used in the trellis quantization so that it is less aggressive in smooth blocks, and more aggressive in textured blocks. It's not as good as being able to change the quantizer, but you can get somewhere around half the benefits of real activity masking by changing lambda alone.

Thanks so much for this piece of art.

I’ve been using JPEGMini trial [http://www.jpegmini.com/] for a while. How does this compare?

I just ran a quick comparison:

Original: 250kB http://files.sina.is/original.jpg

Compressed by JPEGmini Lite: 133kB http://files.sina.is/jpeg-mini.jpg

Compressed by MozJPEG 3.0 @ Medium: 82kB http://files.sina.is/moz-medium.jpg

Compressed by MozJPEG 3.0 @ High: 141kB http://files.sina.is/moz-high.jpg

Thanks, but unfortunately it's not that good of a comparison since the original is already heavily compressed. Could you do another with a less compressed original image (and, preferably, more color variation)?

So does it mean that Daala compression can be used to produce some new image format when it will be ready (similarly to how WebP was produced from VP8)?

Yes, Daala is doing exactly that:

http://people.xiph.org/~xiphmont/demo/daala/update1.shtml

Thanks, that's a good overview. Hopefully something better than JPEG and WebP will come out of Daala still images.

based on my experience with bpg compression of 39 megapixel image takes 2s with jpeg turbo (the original is a raw tiff but already cached). same image bpg is 8m30s. this is on an ivy bridge xeon. i was wanting to smash a few hundred thousand of these 39mp images for transport and backup storage but unacceptible time wise. how much faster would daala be than hvec?

Daala's methodology of video compression differs from HEVC, namely it optimizes the perceived quality of the image. So in theory it can be computationally lighter, because it can save on areas which are affecting perception less. But it's not there yet.

Here is an overview of this idea: http://jmvalin.ca/video/spie_pvq_abstract.pdf

I'm not sure though how exactly it translates into still images compression efficiency. For video they do plan to eventually beat HEVC both on quality and algorithmic delay.

Since it's mentioned in the article: Does anyone have experience with lossy png tools?

I'm currently working on a project that needs alpha channels. I've been optimizing the images with pngcrush, which helped (interestingly, images put out with Adobe products where already pretty optimized, but I'm generating thumbnails locally with sips, where pngcrush often saves 60+%).

Still, for photographic images, file size often remains multiple times larger than what I'd expect from a high-quality JPEG.

>Does anyone have experience with lossy png tools?

I do. Lossy PNGs work great for images with not a lot of colors. I use pngquant and optipng a lot in my work to compress a lot of PNG images with practically no visual quality loss.

For very colorful images, lossy (quantized & dithered) PNGs just don't work, though. They just end up looking nasty with larger filesizes than what high quality JPG gives you.

There's also a method for true-color lossy PNGs that blurs instead of dithering: https://speakerdeck.com/pornel/lossy-png-for-true-color-imag... (https://github.com/pornel/mediancut-posterizer). It's not as efficient as PNG8, but still better than nothing :)

Ditto what Diaz said. The author of this article BTW also makes some rad lossy PNG tools. I took a 3MB website down to under 1MB recently, the majority of which were screenshots.

I use optipng and pngquant together myself... it's been a while since I've looked though... here's the contents of my "!Drag PNG here to Optimize (pngquant and optipng as png8).bat" file ... should be able to do similar in bash/zsh script.

    @echo off

    set batchdir=%~d0%~p0

    :start
     
    "%batchdir%pngquant.exe" --ext .q.png --force --verbose 256 %1
    "%batchdir%optipng.exe" -force -o4 -out "%~dpn1.opt.png" "%~dpn1.q.png"

    del "%~dpn1.q.png"

    shift
    if NOT x%1==x goto start

    rem pause

Looks awesome but I hope there is a better naming convention for the quant tables than

  -quant-table 2

etc

This is totally awesome. Nothing bothers me more than seeing that awkward noise around images I export from Photoshop. Someone mentioned this already, but I hope this finds its way into the apps I use.

On a totally unrelated note, Denny, the dude that dropped the first comment on that post, is not a stand-up guy.

I have a feeling that nobody would really bother with WebP for its compression, but does JPG/PNG have:

* Lossy compression with alpha channels. * Efficient lossless compression of photo-like images. * Efficient compression of photo-like and diagram-like images in the same format (and in the same image, e.g. screenshots containing photos). * Good lossy compression of diagram-like images.

No.

> nobody would really bother..

I did, last summer, converted all images (35K) on my NSFW hobby site (check profile) to WebP with no jpeg fallback or shabby javascript decoder (which don't work on very high res images), and haven't looked back.

On my journey to 1000ms-to-glass with a site like mine, I'm going to go with the format that gives me dramatic size savings, thank you Google.

That said, I can see how it benefits Firefox users not to be able to render WebP... sigh.

It would be helpful if 4chan followed my lead by at least allowing users to post WebP with something like mod_pagespeed running.

Your profile doesn't say anything.

4chan? They've only started to serve static content from a cookie less domain about a year ago http://chrishateswriting.com/post/68794699432/small-things-a.... When it's a known web performance technique for quite some time. Jeff Atwood did this at Stack Overflow in 2009 http://blog.stackoverflow.com/2009/08/a-few-speed-improvemen...

What particular sorcery do you use that prevents your site from serving Firefox browsers?

An nginx redirect based on user agents to an apology and a list of download links to WebP friendly browsers. I used to include a link to a Firefox fork that supported WebP natively, but no one bothered.

I made a sort of Google+ companion to the site which I'd bump them onto but I still haven't gotten the hang of not getting banned.

ngx_pagespeed would be another way of serving WebP to supporting browsers and JPEG to others.

Yes, but not when storage, bandwidth, money, a desire to deliver only the best user experience (or nothing) and pushing WebP are concerns.

By the way, it's remarkable when running an image-heavy site how much bot/mass downloader traffic relative to humans vanish when turning away Firefox user agents.

> I'm going to go with the format that gives me dramatic size savings, thank you Google.

As far as I've seen, testing has shown that WebP is not dramatically better than JPEG, as long as you're using a clever encoder (like MozJPEG, which is what we're talking about). If you have evidence to the contrary, I'm sure the MozJPEG guys would appreciate a test-case!

> That said, I can see how it benefits Firefox users not to be able to render WebP... sigh.

Instead of spending energy on dubious WebP, Mozilla spends energy on improving JPEG (which benefits everybody now) and Daala (which will hopefully benefit everybody eventually). I think it's a pretty sensible trade-off.

Your site doesn't work as of right now.

• Currently you can use lossy PNG: http://pngmini.com/lossypng.html

• There's a draft for gracefully-degrading JPEG eXTensions that add all the features you want http://www.jpeg.org/jpegxt/index.html (by encoding classic JPEG + residual image hidden in JPEG metadata).

WebP is a bit of a hack: it has JPEG-like algorithm for photos (VP8) and a custom PNG-like algorithm for lossless. Technically it's not much different than having JPEG and PNG and using same filename extension for both.

JPEG 2000 and JPEG XR have truly scalable algorithm that can support lossy and lossless.

Reply on news.ycombinator.com