A new (slow) open source JPEG algorithm makes images 35% smaller and looks better than older compression systems

So it’s extremely slow now. What are the chances it won’t be improved inside of a year?

Now imagine if Microsoft owned it.


It would be as intuitive and productive as Word. :+1:


I just ran this on a whole slew of images. “Slow” is true - and the memory use is kind of drastic as well; I think a couple of 12Mpix images peaked over 6GB. Not the sort of thing you run automatically on uploaded images on your dinky 1GB-RAM VPS. Still, it does what it claims, and I hope it’s possible to prune the memory usage a bit. (It might not be - I have no idea what sort of structures this builds internally.)


I tried this on my MacBook Air over the weekend (would have used my Windows desktop but guetzli requires dark magic to run on Windows right now). It’s interesting but I doubt you’ll see it on even backends any time soon.

The memory and CPU time involved are intense.

What’s kind of funny to me is BBS ran the screenshot I uploaded through some other library and increased the file size by about 3kb. :smiley:


Revolutionary compression algorithm even comes with a customized logo


For the CPU issue, one would think this would be a good place to let a GPU do the heavy lifting instead. I’ve certainly found that to be the case for video transcoding. An AMD FX-6100 (yeah, I know, Bulldozer sucks) can’t transcode 1080i MPEG-2 to H.264 in real time, but NVENC-enabled ffmpeg on the same system, using an Nvidia GTX 960 at the “slow” setting can do it over 7x faster than real time.


Whether or not a GPU would help depends entirely on how this new algorithm works.
If it’s easy to parallelise then a GPU may help, but otherwise it’s not going to make any difference.

1 Like


Album name!

You mean it would piss me off with ‘features’ like the Ribbon and difficult alignment that instead works flawlessly and smoothly in LibreOffice?


I read an article a couple of days ago (which naturally I can’t now find) saying that Guetzli is basically much the same as MozJPEG, but much slower. I’ve had pretty good results using this online encoder in the past: https://mozjpeg.codelove.de/

See also: http://www.jpegmini.com/

Is the encoder available for public use? I didn’t notice a link to it in the articles or paper.

It’s available on GitHub.


I’m going to use this as an excuse to link to BPG.

Sometimes I daydream about the bandwidth savings BPG would provide for animated gifs on this BBS alone.


I’ve read some comparisons between the two. Like with most lossless compression of comparable quality, the benefits vary depending on what you’re compressing with each. In terms of CPU and RAM usage during the compression phase, mozjpeg is currently the clear winner. Whether it’ll stay that way is unclear at the moment (the current implementation of guetzli seems pegged to a single core; if it can be threaded and run in a VM like Ruby or Java usually are, it might be faster).

Which one will result in a smaller, nicer looking image is going to depend on the original image. If I was building a service right now, I’d go with Mozilla’s library. In six months or a year, who knows?

Jpegmini seems to be involved in a lot of AstroTurfing right now. I’m not saying they’re not good but I don’t trust them because of the AstroTurf.


It can also do mail merge, arrays are indexed from 1, and it tries to upsell you to OneDrive.


it is slow because it uses more compression optimization passes and a larger data look back window. they are planning on adding some GPU optimizations, but it isn’t ever going to be a real-time compressor, rather a pre-processing compressor. You wouldn’t have apache run this on the fly, but you might pre-compress all your images prior to uploading them, especially the critical ones.

~ 1 minute / MPixel on a 2.6 GHz Xeon

1 Like

Holy crap! That’s the bee’s knees!

But given the total lack of traction APNG has garnered (granted, that’s only a fraction as awesome as this), has the situation been locked in since the 90s?

Maybe we all need to just be like, BPG! BPG! BPG! all of the time…

1 Like

BPG seems like a better solution given that the decoder can be included in the web page, so the browser doesn’t have to support it natively.

Cool BPG uses HEVC 256. I’ve been impressed with HEVC 256. It works significantly better on originals, compared to recompressing, and on higher resolution over lower.

1 Like

This topic was automatically closed after 5 days. New replies are no longer allowed.