Mozilla Doubles Down on JPEG Encoding with mozjpeg 2.0

An anonymous reader writes: Mozilla today announced the release of mozjpeg version 2.0. The JPEG encoder is now capable of reducing the size of both baseline and progressive JPEGs by 5 percent on average (compared to those produced by the standard JPEG library libjpeg-turbo upon which mozjpeg is based). Mozilla today also revealed that Facebook is testing mozjpeg 2.0 to see whether it can be used to improve the compression of images on Facebook.com. The company has even donated $60,000 to contribute to the ongoing development of the technology.

Comments

Hard to get excited.

[tysonedwards]

Sorry, it is hard to get excited about marginal improvements in still raster image compression. Yes, rasters are really important and everything, but at the same point images themselves are so absurdly small already compared to the likes of video technologies, and video is the vast majority of the internet. Seems like a better use of their time to focus on making HEVC or VP9 more capable.

Re:Hard to get excited.

[Charliemopps]

And when Facebook is saying that only 1.48% of their bandwidth is going towards images. That puts said reduction 5% reduction at a new percent of 1.41% at the expense of increased CPU time to transcode all existing images, which is itself not free. It is a marginal savings, even for an organization the size of Facebook. It certainly adds up over time, which is great, but when there is really great low hanging fruit like cutting the 37% of their bandwidth used on videos by 20-30% by getting HEVC or VP9 really working well (would then be 26% total), then that is a way to save significant money not just in Bandwidth but in Disk Space for retention as well.

I deal with this sort of thing all day at work... you're not appreciating the scale of small adjustments.
For example: I recently got asked to approve an upgrade to internet explorer on an enterprise network.
I tested, and replied back that In one application, there was a 3 second delay in opening records. I declined approval and said this issue would have to get fixed before I could sign off on it.

Lots of managers had your attitude... it's only a 3 second delay!

So I had to present my reasoning in a meeting to explain:
We have approximately 1000 users that will be affected.
They each open, on average, 100 records per day.
They get paid an average of $15/hr
1000 users times 100 records = 100,000 records per day
Times 3 seconds = 300,000 seconds
Divided by 60 = 5000 minutes
Divided by 60 again = 83.33hrs
Times $15/hr = $1250

Not fixing that issue would cost the company roughly $1250 per day!
It's nearly a half a million dollar per year problem!
The fix is an increase in memory that would cost the company a 1 time charge of less than $20k.

Scale matters.

Re:Tiny bumps in JPEG performance

[roca]

The reason we're not merging WebP in a hurry is because it's not very good. The study results linked to in the article show that WebP isn't much better than mozjpeg. (This is especially clear in the second part of the study where mozjpeg is tuned for SSIM.) On the other hand the study shows HEVC *is* much better than WebP/mozjpeg, so we know a much better format than WebP is technically available *now*. We can't simply adopt HEVC as is due to patent licensing issues, but we should be able to create an unencumbered format with similar or better performance (e.g. using VP9 or Daala as a base). It doesn't seem like a good idea to try to move to WebP when we know a better format is coming fairly soon (probably within a couple of years).