Live data from Hacker News

MozJPEG 3.0

calendar.perfplanet.com

31–40 of 68 posts

Re: MozJPEG 3.0

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

  -quant-table 2
etc

Re: MozJPEG 3.0

#33
post #6

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

Re: MozJPEG 3.0

#34
post #27
post #19

Earlier quoted context omitted.

Ladies and gentlemen, you are hereby urged NOT to download binaries from random links on the internet - this specific link may or may not be innocent (I have no idea). But how do you know it is not trojaned?

fine, links deleted. Now everyone has to waste time compiling it.

And compiling and running unexamined source is completely safe. Unlike running a binary.

Re: MozJPEG 3.0

#35
post #8
post #7

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 benef…

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

Re: MozJPEG 3.0

#36
post #33
post #6

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)?

Re: MozJPEG 3.0

#38
post #8
post #7

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 benef…

> 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.

Re: MozJPEG 3.0

#39
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.

Re: MozJPEG 3.0

#40
post #37
post #32

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.
Post reply on HN