11 ms·
Guetzli: A New Open-Source JPEG Encoder
- dmitrygr 10y agoCool, but neither the article nor the paper (https://arxiv.org/pdf/1703.04416.pdf https://arxiv.org/pdf/1703.04416.pdf) mention just how much slower it is.
- robryk 10y agoIt's about 1 MPixel / minute on a typical desktop. The other paper mentions that it's extremely slow, but truly we did forget to give actual numbers there.
- walrus01 10y agoWorth noting that a great deal of lossy image compression methods currently in use were developed in the mid to late 1990s, when a 90 MHz Pentium was an expensive and high end CPU. Spending CPU time to do the one time compression of a lossless image to lossy is not as expensive in terms of CPU resources as it used to be.
- Prodibi_Olivier 10y agoTo share my experience, I tried today with a 50mpx image: it took me 1 full hour and it constantly used 10% of my CPU. But the quality was great (even sharper?)!
- i80and 10y agoSome comparison with the mozjpeg encoder here: https://github.com/google/guetzli/issues/10 https://github.com/google/guetzli/issues/10 TLDR: > We didn't do a full human rater study between guetzli and mozjpeg, but a few samples indicated that mozjpeg is closer to libjpeg than guetzli in human viewing.
- corybrown 10y agoVery cool. I'm not an expert, but does JPEG generally have a ton of flexibility in compression? Why so much difference in sizes?
- JyrkiAlakuijala 10y agoThree main methods: 1) YUV420 vs YUV444. Guetzli practically always goes for YUV444. 2) Choosing quantization matrices. 3) After normal quantization, choose even more zeros. JPEG encodes zeros very efficiently. When doing the above, increase the errors where it matters least (certain RGB values hide errors in certain components, and certain types of visual noise hides other kind of noise).
- TD-Linux 10y agoStep 3), choosing more zeros, can be generalized with trellis quantization, which does a search for the best values to encode for each block for the best distortion-per-rate score, where distortion can be any metric (edit: apparently guetzli does some sort of whole frame search for this). mozjpeg does trellis with effectively the PSNR-HVS metric. Because the other two steps are only one setting that affects the entire picture, I do wonder how Guetzli would perform if it was just a wrapper around mozjpeg.
- dmitrygr 10y agoThe more bits you're willing to lose during quantization, the more zeroes the resulting bitstream will have, the better it will compress. The more bits you lose during quantization, the more ringing and artifacts you can expect after the IDCT process. So the tradeoff is quite literally artifacts for smaller size. this compressor seems to be cleverer about where to lose data than libjpeg.
- iainmerrick 10y agoYes, JPEG encoding has a ton of flexibility. You rearrange each block of pixels using the discrete cosine transform, which tends to pack more significant values towards one corner, and then you have lots of freedom over how to quantize those values. See https://en.wikipedia.org/wiki/JPEG#Quantization https://en.wikipedia.org/wiki/JPEG#Quantization On top of that, you could tweak the quantized values themselves to make them more compressible.
- mattpavelle 10y agoI'll run some of my own experiments on this today, but I'm initially concerned about color muting. Specifically looking at the cat's eye example, in the bottom of the pupil area there's a bit of green (reflection?) in the lower pupil. In the original it is #293623 (green) - in the libjpeg it is #2E3230 (still green, slightly muted). But in the Guetzil encoded image it is #362C35 - still slightly green but quite close to grey. In my experience people love to see colors "pop" in photos (and photography is where JPEG excels) - hopefully this is just an outlier and the majority of compressions with this tool don't lose color like this.
- jacobolus 10y agoIn general if you want to avoid any color changes in blobs a few pixels in size, you’ll want to take it easy on the compression, and take the hit of a larger file size in trade. I suspect that if you give this algorithm twice the file size as a budget, that green color will come back.
- mattpavelle 10y agoI agree, giving more file size may get us our colors back. And after some experimentation I'd like to be able to confirm something a bit abstract like, "Guetzli is good for reducing artifacts by sacrificing color" or some such snippet. It would definitely have its uses as such. Or maybe it's great all around and I just found one bad example?
- JyrkiAlakuijala 10y agoGuetzli sacrifices some chromaticity information, but tries to keep that in balance with the intensity loss. Guetzli sacrifices colors much less than the commonly used YUV420 mode -- the common default mode in JPEG encoding.
- natch 10y agoAgree, that difference is very striking side by side to me at least. Maybe not to everyone, but I hope they have some people with very good color perception on their team so they'll be able to see the difference.
- ktta 10y agoI wonder how Dropbox's Lepton[1] compresses JPEGs encoded using Guetzli. Since they already pack more info/byte would there be noticeable compression? Someone out there must have tried this. [1]:https://blogs.dropbox.com/tech/2016/07/lepton-image-compression-saving-22-losslessly-from-images-at-15mbs/ https://blogs.dropbox.com/tech/2016/07/lepton-image-compress...
- Scaevolus 10y agoI'd expect it to still save >20%. Lepton uses arithmetic encoding instead of Huffman (-10%), and predicts each 8x8 block based on its neighbors (-20%). Guetzli shouldn't interfere with either of these.
- JyrkiAlakuijala 10y agoWhen we pack guetzlified JPEGs we see slightly smaller wins than with stock JPEGs. Think -14% for guetzlified JPEGs vs. -20% libjpeg JPEGs.
- sschueller 10y agoLots of Swiss German coming from Google lately. Zöpfli, Brötli and now Guetzli. I'm still hoping for a Google Now that understands Swiss German :)
- post_meridiem 10y agoI'm Swiss German and don't understand half of the Swiss German dialects. Swiss German must be the ultimate hard case for machine translation.
- Cyph0n 10y agoI'm assuming it's because the work originated in their R&D labs in Zurich?
- cimnine 10y agoThere's a huge Google lab in Zurich [1], probably that's why. [1] https://careers.google.com/locations/zurich/ https://careers.google.com/locations/zurich/
- m_mueller 10y agoI'm a bit sad but I guess I could have seen it coming ;-). https://github.com/muellermichel/guetzli https://github.com/muellermichel/guetzli
- s3nnyy 10y agoAlthough Zurich's software engineers are as expensive as those in the Bay area, Google employs 1500 of them and they bought a new building next to the main train station to hire hundreds of new ML / AI experts. (Full disclosure: I am a programmer and I try to match programmers with Zurich's startups for a living.) So, if you want to move to Zurich, you find my e-mail address in my HN-handle. Read more about Switzerland in my semi-famous blogpost "8 reasons why I moved to Switzerland to work in tech": https://medium.com/@iwaninzurich/eight-reasons-why-i-moved-to-switzerland-to-work-in-it-c7ac18af4f90 https://medium.com/@iwaninzurich/eight-reasons-why-i-moved-t...)
- kozak 10y agoWow, "webmasters creating webpages" is something that I haven't heard for a very long time! I'm nostalgic.
- vladdanilov 10y agoI'm working on a similar thing (http://getoptimage.com http://getoptimage.com). While Guetzli is still visually better and a bit smaller in file size, it's terribly slow and requires a lot of memory. But it's a great experiment. So much knowledge has been put into it. I believe using a full blown FFT and complex IQA metrics is too much. I have great results with custom quantization matrices, Mozjpeg trellis quantization, and a modification of PSNR-HVS-M, and there's still a lot of room for improvement.
- 21 10y agoWould it be possible to accelerate Guetzli on a GPU?
- pitaj 10y agoIt appears that FFT can be GPU accelerated. Nvidia has cuFFT which claims to be 10x faster.
- dbaupp 10y agoI'd expect this to behave quite differently to cuFFT: the transforms are likely to be small (either length 8 1D FFTs, or 8x8 2D FFTs) and thus synchronisation overhead is likely to dominate if one was to try to parallelise within a transform (other than via SIMD). However, this small size does mean that the transforms can be written out to have "perfect" data transfer and branching behaviour, so that they parallelise well at JPEG's natural parallelisation granularity (the 8x8 pixel blocks).
- vladdanilov 10y agoIt's block-based so definitely yes.
- alexcroox 10y agoAny plans for a Wordpress plugin like TinyPNG has? We use that currently but TinyPNG's JPG output leads to visible pixilation.
- leetbulb 10y agoI use ImageOptim (https://imageoptim.com https://imageoptim.com) for small tasks. For larger tasks, https://kraken.io https://kraken.io is nuts.
- SloopJon 10y agoThe Github README says, "Guetzli generates only sequential (nonprogressive) JPEGs due to faster decompression speeds they offer." What's the current thinking on progressive JPEGs? Although I haven't noticed them recently, I don't know whether they're still widely used.
- theandrewbailey 10y agoI use progressive JPEGs if they have a smaller filesize, which is true most of the time.
- TD-Linux 10y agomozjpeg also generates progressive JPEGs by default, for the same reason.
- E6300 10y agoAs a user, I dislike progressive images because of the ambiguity regarding when they've finished loading.
- nsuser3 10y agoAs a user, I love progressive images because I can see the whole image very fast. (I don't have to wait for it)
- londons_explore 10y agoI don't really understand why they would be slower to decode. It's really just the same data ordered differently in the file. I can see that if you try to render an incomplete file you might end up "wasting" effort blitting it to the screen and stuff before the rest of the data is decoded. But if thats a concern, one can simply rearrange the data back to scanline order and decode as normal?
- robryk 10y agoThey are slower to decode mostly due to decreased cache locality. In sequential JPEGs you read one block worth of data, make pixels out of it, and write the pixels out. In progressive encoding, you need to write the pieces of coefficients back to memory at every scan -- the whole image won't fit into cache -- so there's one more memory roundtrip for every pixel. Also, there's just more symbols to decode in total.
- phkahler 10y agoDoes it support 12-bit jpeg?
- Wapmild 10y agoLook www.mild.n.nu seo guide
- d--b 10y agoWhy spend a lot of time improving jpeg instead of spending time promoting a HEVC-based standard like that one? http://bellard.org/bpg/ http://bellard.org/bpg/
- wolf550e 10y agoBecause patents.
- johansch 10y agoAnd slowness of cross-browser deployment. Both for stupid and very valid reasons. As an example of the latter: I think Opera Mini (which I ran the development of for its first decade) still has somewhere around 150-200 million monthly unique users, down from a peak of 250M. Pretty much all of those users would be quite happy to receive this image quality improvement for free, I think. (Assuming the incremental encoding CPU cost isn't prohibitive for the server farms.) Opera Mini was a "launch user" of webp (smartphone clients only) for this particular reason. Many of those users devices are Nokia/Sony Ericsson/etc J2ME devices with no realistic way of ever getting system-level software updates. They are still running some circa 2004 libjpeg version to actually decode the images. It's still safe because the transcoding step in Opera Mini means that they aren't exposed to modern bitstream-level JPEG exploits from current web, but it underscores why any improvements targetting formats like JPEG is still quite useful. Opera Mini for J2ME actually includes a very tiny (like 10k iirc) Java-based JPEG decoder since quite a few devices back then didn't support JPEG decoding inside the J2ME environment. It's better than having to use PNG for everything, but because it's typically like 5x-10x slower than the native/C version even in a great JVM of the time it really only makes sense to use as a fallback.)
- mtgx 10y agoIf anything, they would spend the time to make it AV1-based, which apparently was expected to come out this month: http://www.streamingmedia.com/Articles/Editorial/-110383.aspx http://www.streamingmedia.com/Articles/Editorial/-110383.asp... http://aomedia.org/about-us/ http://aomedia.org/about-us/
- tannhaeuser 10y agoIs JPEG2000 with progressive/resolution-responsive transcoding still a thing or is HTML <picture> the way to go for responsive images (or maybe WepP)?
- purerandomness 10y agoJPEG2000 died a bitter patent death.
- userbinator 10y agoActually, it's alive and well in the form of embedded images in PDFs, where it's known as JPXFilter. Most of the ebooks (scans) I've downloaded from archive.org use it. If it didn't have any huge advantage I doubt they would've chosen it over standard JPEG. The real problem, as far as I can see, is that JPEG2000 is really slow to decode due to its complexity.
- acdha 10y agoModern implementations are decent but there's no open source implementation in that class. OpenJPEG is improving but it's much slower than Kakadu (which is what CoreImage uses) or Aware.
- boxerab 10y agoshameless plug for my JPEG 2000 codec: https://github.com/GrokImageCompression/grok https://github.com/GrokImageCompression/grok . Performance currently around 1/3 Kakadu
- acdha 10y agoHeh, yes - I've been following that since you announced it. It'd be really nice if we could start getting the OSS toolchain onto a JP2 implementation with decent performance — I think jasper really soured the reputation for many people.
- 10y ago
- discreditable 10y agoPrevious discussion: https://news.ycombinator.com/item?id=13377539 https://news.ycombinator.com/item?id=13377539
- onion2k 10y agoSort of related, but what's the story with fractal image compression? When I was at university (~20 years ago) there was a lot of research going in to it, with great promises heralded for web-based image transfer. There was a Netscape plugin that handled them. They seemed to just disappear in the early 2000s.
- dbbolton 10y agoSeems to have been patent-encumbered and largely abandoned in the commercial world, but there is a FOSS library called fiasco (.wfa files) that is included with netpbm, available on most *NIX systems. http://manpages.ubuntu.com/manpages/xenial/man1/netpbm.1.html http://manpages.ubuntu.com/manpages/xenial/man1/netpbm.1.htm... https://github.com/l-tamas/Fiasco https://github.com/l-tamas/Fiasco
- ehsankia 10y agoNew formats are generally a huge pain in the media worlds... Huge companies like Google have been trying to get webp for years and it's still not there, and it's also why they're still putting so much effort into png/jpg.
- TD-Linux 10y agoI think this paper was part of it, which showed that the advantages of fractal image compression could equivalently be achieved with smooth wavelets and efficient representation of zerotrees, except with a lot more speed and flexibility (sorry no PDF): https://www.researchgate.net/publication/5585498_A_wavelet-based_analysis_of_fractal_image_compression https://www.researchgate.net/publication/5585498_A_wavelet-b...
- i336_ 10y ago> sorry no PDF No directly-linkable PDF :P https://news.ycombinator.com/item?id=12374235 https://news.ycombinator.com/item?id=12374235
- mutagen 10y ago
- countryqt30 10y agoTogether with Google services, we also created a SWISS-German language school in Zurich: https://www.schweizerdeutsch-lernen.ch/ https://www.schweizerdeutsch-lernen.ch/
- pjsg 10y agoAs the author of the original libjpeg (back in 1991), I think this has been a long time coming! More power to Google.
- JyrkiAlakuijala 10y agoThank you for giving such a present for all of us! JPEG was in my opinion really ahead of its time, is still impressive, and many of the engineering compromises between simplicity and efficiency are just brilliant.
- nothis 10y ago>More power to Google. Careful what you wish for!
- tomcam 10y agoThanks so much for libjpeg. You totally rock.
- fratlas 10y agoThank you for writing such beautiful software.
- agumonkey 10y agoImpressive :) What are you on these days ? image codecs still ?
- pjsg 10y agoNo -- computer security -- which is a fascinating field. There are arms races here between the good people and the bad people. It isn't clear that the forces of good are winning. It is a Red Queen problem. The original libjpeg code was written to try and change the Usenet News binary pictures groups over from GIF to JPEG (so that more images would fit down the rather narrow transatlantic pipe that I had at the time). The choice of license turned out to be a good one (it predated the GPL V2) -- who knows what would have happened if we (the precursor to the IJG) had chosen that one.
- londons_explore 10y agoThis seems to be optimizing for a "perceptual loss function" over in https://github.com/google/butteraugli/blob/master/butteraugli https://github.com/google/butteraugli/blob/master/butteraugl... Looking at the code to that, it looks like 1500 lines of this: double MaskDcB(double delta) { PROFILER_FUNC; static const double extmul = 0.349376011816; static const double extoff = -0.894711072781; static const double offset = 0.901647926679; static const double scaler = 0.380086095024; static const double mul = 18.0373825149; static const std::array<double, 512> lut = MakeMask(extmul, extoff, mul, offset, scaler); return InterpolateClampNegative(lut.data(), lut.size(), delta); } The code has hundreds of high precision constants. Some even seem to be set to nonsensical values (like kGamma to 0.38) Where did all of them come from? The real science here seems to be the method by which those constants were chosen, and I see no details how it was done.
- nothis 10y agoSo... machine learning? (Sorry for buzz-wording)
- JyrkiAlakuijala 10y agoIt is old school: 100000+ cpu hours of Nelder-Mead method (+common tricks) to match butteraugli to a set of 4000 human rated image pairs created with an earlier version of Guetzli and specially-built image distortion algorithms.
- myle 10y agoTo those who didn't notice, that's one of the authors, well also took large part in previous related work.
- londons_explore 10y agoHow did you protect against overfitting? How about local maxima? Some of your constants look surprising to say the least. Most notably: * The gamma value of 0.38 (when most studies suggest 1.5 - 2.5 for human eye gamma) * The significant difference in the vertical and horizontal constants (when as far as I know human eyes are equally sensitive to most distortions independant of angle).
- kzrdude 10y agoI wonder, does google's blog pick up that I can't read their web page due to javascript blocking? Do they evaluate how many readers are turned away due to such issues?
- matt4077 10y agoLarry Page doesn't care, but it does keep Sergey up at night.
- kup0 10y agoSo far the results have been useful for me. It's been able to reduce size on some tougher images that other optimizers would ruin quality-wise.
- whywhywhywhy 10y agoGreat tech, shame about the name
- deleted 10y ago[deleted]
- j0hnM1st 10y agoMacOS setup and testing with Lenna https://agileblaze.com/google-guetzli-image-compression-setup-on-macos/ https://agileblaze.com/google-guetzli-image-compression-setu...
- mkj 10y agoNice work. And yet google images still has horribly compressed low resolution thumbnails...
- wildpeaks 10y agoJust tried the precompiled binary from: https://github.com/google/guetzli/releases https://github.com/google/guetzli/releases and I'm getting "Invalid input JPEG file" from a lot of images unfortunately.
- iagooar 10y agoThis Swiss naming of algorithms really gets old, especially if you speak (Swiss) German...
- rurban 10y agoNice Makefile, jirki. I really have to look into premake which generated it. But I get a gflags linking error with 2.1 and 2.2 with -DGFLAGS_NAMESPACE=google. This is atrocious. "google::SetUsageMessage(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)" Without this it works fine. Guess I still have some old incompat gflags headers around. EDIT: The fix on macports with 2.2 installed default into /usr/local is: make CXX=g++-mp-6 verbose=0 LDFLAGS="-L/usr/local/lib -L/opt/local/lib -v" CFLAGS=-I/usr/local/include i.e. enforce gflags 2.2 over the system 2.1
- drdebug 10y agoThis really looks great. I really wish the author(s) could provide a detailed overview of the human vision model algorithm being implemented, what it is doing and why, so we could reproduce an implementation, may be even provide improvements? Otherwise amazing work.
- ZeroGravitas 10y agoHow relevant to web pages is this? The blog makes it sound like that's the target but the paper has this line: "Our results are only valid for high-bitrate compression, which is useful for long-term photo storage." Do the author's think the size/quality benefits still show up when targetting lower bitrates/qualities that are more common on the web? Do they intend to try to prove it?
- JyrkiAlakuijala 10y agoQuality-wise, Guetzli is applicable to about 50% of the JPEG images in the internet. The other half is stored with lower than 85 quality, and Guetzli declines to attempt to compress to that quality. Another limitation is that Guetzli runs very slowly. This gives a further limiting axis: Guetzli in its current form cannot be applied to a huge corpus of images. Perhaps this covers half of the images on the internet. So, let's say that Guetzli is 25% relevant to the web pages.
- shmerl 10y agoHow does it compare to mozjpeg?
- saltysalty 10y agoI am not an expert, but AFAIK JPEG is a lossy format. The comparison is purely based on the size, and I couldn't find anything in the paper about data loss compared to other encoders. Can someone please explain why is this a fair comparison?
- janwas 10y agoWe did an experiment with comparisons of Guetzli and (slightly larger) libjpeg output: https://arxiv.org/abs/1703.04416 https://arxiv.org/abs/1703.04416 Turns out that 75% of the 614 ratings are in favor of the Guetzli version.
- simplehuman 10y agohttp://getoptimage.com/ http://getoptimage.com/ is better
- underlines 10y agoif it may benefit anyone, i used this simple batch file to test out the lower bound -quality 84 with drag and drop of one/multiple images on win 86-64: echo Drag and drop one or multiple jpg or png files onto this batch file, to compress with google guetzli using a psychovisual model if [%1]==[] goto :eof :loop echo compressing... guetzli_windows_x86-64.exe -quality 84 %1 "%~dpn1_guetzlicompressed%~x1" shift if not [%1]==[] goto loop echo DONE i'm concerned about the color changes that are clearly visible throughout the whole image.
- JyrkiAlakuijala 10y agoGuetzli runs the whole image to the same specified quality -- when artefacts start to emerge, they are everywhere, not just in one sensitive area. Guetzli can be more likely worth its cpu cost at a higher quality, around 92-96.
- sam-mueller 10y agoAre there any plans to make Guetzli available as a library for iOS and Android? Would be great to process images right on device with this level of compression.