Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MozJPEG 3.0

calendar.perfplanet.com

Post reply on HN
Print view View original

41–50 of 68 posts

Re: MozJPEG 3.0

#41

Post by jacobolus »

ahoge wrote: post #30
BorisMelnik wrote: post #15

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…

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

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.

Re: MozJPEG 3.0

#42

Post by d0ugie »

Renaud wrote: post #35
d0ugie wrote: post #8

Earlier quoted context omitted.

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

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.

Re: MozJPEG 3.0

#43

Post by Hello71 »

georgef wrote: post #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 mar…

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

Re: MozJPEG 3.0

#44

Post by derf_ »

pornel wrote: post #12
leeoniya wrote: post #2

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

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.

Re: MozJPEG 3.0

#45

Post by cbr »

d0ugie wrote: post #42
Renaud wrote: post #35

Earlier quoted context omitted.

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.

Re: MozJPEG 3.0

#46

Post by auvi »

joshmoz wrote: post #32

FYI, I plan to officially release mozjpeg 3.0 tomorrow. Thanks for the writeup and your work on this release, Kornel!

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

Re: MozJPEG 3.0

#47

Post by ahoge »

joshmoz wrote: post #40
mp3geek wrote: post #37

Earlier quoted context omitted.

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?

Re: MozJPEG 3.0

#48

Post by beagle3 »

cabirum wrote: post #27
beagle3 wrote: 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.

No offence intended - buy you are in this case, a stranger giving a candy.

Some strangers with candy have no sinister intentions, but kids should still avoid them, because of the irreparable harm that those with sinister intentions will cause, all kids should avoid candy from strangers.

Re: MozJPEG 3.0

#49

Post by beagle3 »

jacobolus wrote: post #41
ahoge wrote: post #30

Earlier quoted context omitted.

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

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

Re: MozJPEG 3.0

#50

Post by bnolsen »

shmerl wrote: post #29
pornel wrote: post #13

Earlier quoted context omitted.

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