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

51–60 of 68 posts

Re: MozJPEG 3.0

#51

Post by shmerl »

bnolsen wrote: post #50
shmerl wrote: post #29

Earlier quoted context omitted.

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.

Re: MozJPEG 3.0

#52

Post by BorisMelnik »

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

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.

Re: MozJPEG 3.0

#53

Post by joshmoz »

mikhailt wrote: post #16
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…

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.

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.

Re: MozJPEG 3.0

#54

Post by zurn »

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…

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.

Re: MozJPEG 3.0

#55

Post by CookWithMe »

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.

Re: MozJPEG 3.0

#56

Post by Retra »

beagle3 wrote: post #48
cabirum wrote: post #27

Earlier quoted context omitted.

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.

Is there even any evidence that any children have ever been hurt by strangers with candy?

Re: MozJPEG 3.0

#57

Post by Kiro »

auvi wrote: post #46
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.

What are you using it for?

Re: MozJPEG 3.0

#58

Post by beagle3 »

Retra wrote: post #56
beagle3 wrote: post #48

Earlier quoted context omitted.

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.

Is there even any evidence that any children have ever been hurt by strangers with candy?

http://lmgtfy.com/?q=lured+with+candy

(In some of the results "Police declined to tell", and some describe the same incident, but that's just the first page with the first search term that came to my mind).

Re: MozJPEG 3.0

#59

Post by iopq »

d0ugie wrote: post #8
Timmmmmm wrote: 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…

Your site doesn't work as of right now.

Re: MozJPEG 3.0

#60

Post by chkuendig »

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…

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

Post reply on HN