New Mozilla Encoder Improves JPEG Compression

jlp2097 writes "As reported by Heise, Mozilla has introduced a new JPEG encoder (German [Google-translated to English]) called mozjpeg. Mozjpeg promises to be a 'production-quality JPEG encoder that improves compression while maintaining compatibility with the vast majority of deployed decoders.' The Mozilla Research blog states that Mozjpeg is based on libjpeg-turbo with functionality added from jpgcrush. They claim an average of 2-6% of additional compression for files encoded with libjpeg and 10% additional compression for a sample of 1500 jpegs from Wikipedia — while maintaining the same image quality."

Comments

Why aren't we using PNG?

[Anonymous Coward]

It's not lossy. I try to always use PNG.

Re:Why aren't we using PNG?

[Anonymous Coward]

Because PNG is not lossy.

Re:Why aren't we using PNG?

[prefect42]

If you're talking about simple web graphics, then yes, PNG is often a good choice. Lossy compression simply makes more sense for photos, as the compression ratio is that much better. Always using PNG is idiotic, as is always using JPEG. JPEG2000 is not our saviour.

Re:Why aren't we using PNG?

[jandrese]

Because truecolor PNG images are much larger (usually at least twice as large, often closer to 4 times larger) than a properly encoded JPG counterpart, and you can't see the difference with your naked eye.

Re:Why aren't we using PNG?

[omnichad]

I wish I had mod points. Thank you.

Re:Why aren't we using PNG?

[Millennium]

PNG is great for everything but actual photos, and should be used for just that: everything but photos. But photos really do need the extra boost from lossy compression.

Re:Why aren't we using PNG?

[bzipitidoo]

It's a shame JPEG2000 debuted dead on arrival thanks to patent encumbrances. Creation of a superior open lossy image compression standard seems to have been left behind in favor of video. We have PNG and Theora, but nothing free that improves on jpeg.

Re:Why aren't we using PNG?

[TheRealMindChild]

Maybe if it is an 800x600 res photo printed with a bad printer, but JPEG shittyness comes into play when you want to DO something with that image, instead of just looking at it from afar

Re:Why aren't we using PNG?

[Anonymous Coward]

I don't think patents are the problem. I would say it's more that jpeg2000 is slow as molasses, is trying to be lossless and lossy at the same time and failing at both - lossless is way larger than png, lossy throws away the advantage of downsampled YCbCr colorspace that jpeg has. It's not clearly superior to preexisting stuff, except for people with strange needs. Who in fact are using it. It just never went mainstream.

Re:Why aren't we using PNG?

[Guspaz]

Since I started looking at web pages with JPEG images, the speed of my internet connection has increased by roughly 345,000%, the size of my hard disk by 200,000%. Why is a 300% increase in image size a concern?

Re:Why aren't we using PNG?

[Anonymous Coward]

I agree.
I use PNG for everything except photos.
For photos I the camera raw format.

Re:Why aren't we using PNG?

[Bob the Super Hamste]

Because I remember watching graphics load line by line and that sucked.

Re:Why aren't we using PNG?

[Anonymous Coward]

Because JPEG is good enough and far smaller in many applications than PNGs.

Re:Why aren't we using PNG?

[Anonymous Coward]

But that's exactly what the parent said.

Re:Why aren't we using PNG?

[Anonymous Coward]

Yes it is. RTFM.

Re:Why aren't we using PNG?

[jandrese]

Seriously, try this yourself. Take a digital camera RAW and encode it with JPEG at reasonable settings (80 quality or so) and then compress it with truecolor PNG. Compare the file sizes. Now take a script that puts them up side by side and choose the better image. It should be the PNG right, because JPEG is lossy? I'd bet you would be hard pressed to beat random chance.

Now that's not to say you should use JPEG absolutely everywhere. Stuff like computer generated images with 1 pixel lines or text look awful with JPEG and compress awesomely with PNG--lots of big flat color spaces are very nice to a PNG encoder. For photographic images however, JPEG is the way to go. You get effectively the same quality and save a lot of bits. It's all about choosing the right tool for the job.

Re:Why aren't we using PNG?

[Waccoon]

It would help if many paint programs had a default JPEG quality level higher than 70%. That's okay when dealing with 10 megapixel photos that are only shown on the screen or destined for 4x6 prints. Not so nice when dealing with large prints or artwork. I hate seeing Death by JPEG on sites like DeviantArt all the time.

Re:Why aren't we using PNG?

[dryeo]

Since I started looking at web pages with JPEG images, my internet connection has almost doubled in speed and now there are pages that are basically unviewable.
Many locations don't have any other option then dial up and many more have various caps on the amount you're allowed to download before charges increase.

Re:Why aren't we using PNG?

[Your.Master]

Yes, and he's pointing out that the exact thing the parent said as an advantage for PNG is also its disadvantage.

A lossless compression format cannot compete with a good lossy compression format in terms of file sizes for arbitrary content, even though it wins by definition in terms of fidelity. The web, even today, is very bandwidth constrained and thus file sizes are one of the most important things to optimize against, for both the client and the server. Fidelity is often not a very important consideration.

Re:Why aren't we using PNG?

[TheRealMindChild]

But you are still talking about LOOKING at that photographic image. If it needs manipulated, you are doing yourself a large disservice by starting out with a JPEG source. Even as something as simple as scaling/zooming will wreak havoc on the outcome. Need to lighten it? Sharpen or blur some lines? AND THEN resave it? No sir. Not good

Re:Why aren't we using PNG?

[Guspaz]

There are services (Opera's work quite well, Google has one too) that will re-compress any images to lower quality lossy formats and into a single response to avoid round-trips. I don't think big image files are really the main problem for people still on dialup.

Re:Why aren't we using PNG?

[BronsCon]

And this is relevant to this discussion because... why, exactly? We're talking about Mozilla's JPEG encoder generating smaller files, and we're talking about it in terms of bandwidth and transfer times. To me, that spells "will be displayed on a webpage", rather than "will be edited and re-saved, possibly through multiple generations". Of course you won't use this for your originals; JPEG should be considered an output format, not an archival or intermediary format, just like any other lossy format for any other type of media.

Re:Why aren't we using PNG?

[eulernet]

Because you are not only one in this world, you are probably in the 0.01 percentile of fast connections.

A lot of people like me have slow connections, so I *hate* big images, and particularly sites which put images everywhere.
I'm in a rural region, so I don't expect a faster connection anytime soon. And moving is not an option either.

There is a proverb that says that a picture is worth a thousand words, but it's not true with the Internet.

Re:Why aren't we using PNG?

[Guspaz]

There are plenty of services like Opera Turbo that will recompress all images as smaller lossy images. Why should all users get a degraded experience when those on slow connections have options to automatically recompress images to be better suited for their connections?

Re:Why aren't we using PNG?

[BronsCon]

On the web? No? Well that's what we're talking about right now.

Re:Why aren't we using PNG?

[Anonymous Coward]

An image is just a single frame video anyway. Just use Theora for everything.

Re:Why aren't we using PNG?

[eulernet]

Because the sites using lots of images tend to also use lots of Javascript.

I don't see why I should upgrade my computer to be able to browser the web.
The worst sites I browsed tend to put pictures everywhere, even (and especially) when unnecessary.

And don't make me laugh with the "experience" of the web.
Why do you think the simple Google search won over the "portal" search of Yahoo ?
Has simplicity become so irrelevant ?

Re:Why aren't we using PNG?

[Boycott BMG]

But why have the many successors to jpg that provide better lossy compression not caught on?

Re:Why aren't we using PNG?

[Anonymous Coward]

But why have the many successors to jpg that provide better lossy compression not caught on?

Without getting into a full-blown Doctoral Thesis, it's usually because either they suffer performance issues, or don't do nearly as good a job of preserving the visual integrity of the source image. JPG is a good balance of speed, quality preservation, and size of the compressed file.

Re:Why aren't we using PNG?

[TheRealMindChild]

I was told the same about pdfs :(

Re:Why aren't we using PNG?

[Anonymous Coward]

Many locations don't have any other option then dial up

That's simply not true, at least within the USA and most developed countries.
And if you're on dial-up, I'd recommend getting a browser add-on which will allow you to send a spoofed UID which identifies you as a mobile device, if the sites you go to don't have an easier way to view the "mobile" site. More and more sites these days are making "mobile" versions which have vastly reduced "overhead" in terms of graphical elements, and many of them are figuring out they can serve up a mostly uncompressed image to regular browsers and a much more highly compressed one to the mobile devices.

Re:Why aren't we using PNG?

[swillden]

But why have the many successors to jpg that provide better lossy compression not caught on?

Without getting into a full-blown Doctoral Thesis, it's usually because either they suffer performance issues, or don't do nearly as good a job of preserving the visual integrity of the source image. JPG is a good balance of speed, quality preservation, and size of the compressed file.

Nah, I think it's mostly because JPEG is good enough. JPEG2000, for example, also provides perfectly acceptable performance and quality, with significantly-reduced file sizes. But unlike JPEG, JPEG2000 decoders aren't already available everywhere. The slightly-reduced file size isn't sufficient justification for the risk that some users might not be able to see the photo. An improved JPEG encoder helps (a little) with file size without incurring the need for a new decoder, so it's immediately useful.

Re:Why aren't we using PNG?

[Anonymous Coward]

Usually because they are non-free.

Re:Why aren't we using PNG?

[Guspaz]

I don't see what javascript and computer upgrades have to do with PNG. Heck, the point of Opera's stuff was to run on lower-end devices. It was intended for use on mobile originally. And it still supports javascript.

Re:Why aren't we using PNG?

[arglebargle_xiv]

I think it's mostly because JPEG is good enough. JPEG2000, for example, also provides perfectly acceptable performance and quality, with significantly-reduced file sizes. But unlike JPEG, JPEG2000 decoders aren't already available everywhere.

It's the fax-machine effect, JPEG will be around forever because everything, and I mean everything, that creates, processes, manipulates, and displays images, speaks JPEG. If Jobs was still alive and decided that from now on iWhatever's were only going to do JPEG2000 (and it's not just for file size reasons, image quality is also vastly improved), you can bet that we'd have a surge in JPEG2000 adoption as soon as the first JPEG2000-only iWhatever was released.

(Personally I'd opt for JPEG-XR, which is more flexible than JPEG2000, addressing the 20-odd-years' worth of issues that have emerged since the original JPEG first saw widespread adoption, but since it was developed by Microsoft I'm nervous even mentioning it here. You never saw these lines, move along, move along...).

Re:Why aren't we using PNG?

[mebrahim]

Because 3x storage and bandwidth usage is more expensive than 1x. The difference is specially more noticeable in large scale for the hosters than for clients.

Re:Why aren't we using PNG?

[kuwan]

JPEG XR is actually quite good and is now an open standard. I recently did an extensive evaluation of JPEG 2000 vs. JPEG XR. While JPEG 2000 has slightly better compression quality (less visible artifacts) at the same file sizes it’s decode performance is substantially slower than JPEG XR (the same is true for encode performance, but decode is much more important). In my testing, one of the fastest JPEG 2000 libraries, Kakadu, is anywhere from 1.8 to 2x slower than JPEG XR at decoding files. Kakadu is a commercial framework, the open source OpenJPEG library is supposed to be substantially slower.

Compared to standard JPEG, JPEG XR has on average the same or very similar decode performance. The bottom line is that with JPEG XR you get compression quality and file sizes that are similar to JPEG 2000 with performance that is similar to standard JPEG. In my eyes, it’s the best successor available to replace JPEG. But it has a long uphill battle ahead of it.

Re:Why aren't we using PNG?

[Anonymous Coward]

Yes, and he's pointing out that the exact thing the parent said as an advantage for PNG is also its disadvantage.

A lossless compression format cannot compete with a good lossy compression format in terms of file sizes for arbitrary content, even though it wins by definition in terms of fidelity. The web, even today, is very bandwidth constrained and thus file sizes are one of the most important things to optimize against, for both the client and the server. Fidelity is often not a very important consideration.

Especially when fidelity is maintained for viewing purposes.

Re:Why aren't we using PNG?

[arglebargle_xiv]

While JPEG 2000 has slightly better compression quality (less visible artifacts) at the same file sizes itâ(TM)s decode performance is substantially slower than JPEG XR (the same is true for encode performance, but decode is much more important).

How much of this is due to hardware support for core JPEG operations in GPUs and (to a lesser extent) CPUs? If wavelet-based JPEG took off, would it just be a matter of time before hardware vendors added explicit support for it to their instruction sets, at which point the speed difference would vanish?

Re:Why aren't we using PNG?

[gzuckier]

Because the American public will always choose the worse technological alternative.
VHS over Beta
NTSC color tv
18 khz subcarrier FM stereo
44 khz CD over SACD
Intel 8086 over Motorola
IBM PC over Mac
Windows over OS/2
Chevy over Ford
etc.

Images in Firefox

[Larry_Dillon]

Now if Firefox could just scale images properly when viewing them.....

Seem Negligible

[ironicsky]

Seems like a negligible improvement. I mean really. With hard drive space plentiful, and bandwidth faster than most users can use at any given moment, saving 20-60Kb on a 1Mb file is like a fart in the wind, even for mobile users.

I'm with the AC in the first post, I use PNG for 90% of my images, since it supports transparency. The file may be slightly bigger, but who cares.

Re:Seem Negligible

[oji-sama]

Wikipedia might care.

Re:Seem Negligible

[Anonymous Coward]

Says the person who has no idea what the cost is to serve up content.

Re:Seem Negligible

[Anonymous Coward]

Seems like a negligible improvement. I mean really. With hard drive space plentiful, and bandwidth faster than most users can use at any given moment, saving 20-60Kb on a 1Mb file is like a fart in the wind, even for mobile users.

I'm with the AC in the first post, I use PNG for 90% of my images, since it supports transparency. The file may be slightly bigger, but who cares.

Anyone who has to serve thousands or tens of thousands of images will absolutely care. Their disk space requirements, bandwidth and the client's load time are all reduced. 10% is a noticeable is the threshold where change becomes noticeable.

Re:Seem Negligible

[Anonymous Coward]

1. People on Sat-links
2. People on mobile devices
3. People on dial-up
4. People running image heavy sites
5. People coding for contstrained environments (read: embedded devices)
6. Anyone who's answer to resource management isn't "throw more money at it"

*draws breath*

Re:Seem Negligible

[SJHillman]

I found switching large photographs on my site from png to jpeg led to a noticeable loadtime increase. It's not a lot, but it is noticeable. However, I'm sticking to PNG for any non-photographic images.

Re:Seem Negligible

[StripedCow]

If 2-6% is nothing, why not donate that percentage of your monthly salary to a good cause?

Re:Seem Negligible

[Zocalo]

It also reduces the time it takes to write the file out to disk or memory card. That could have a small knock on effect in a number of areas like the burst length on cameras and battery life on mobile devices (assuming that the new codec isn't much more CPU intensive). If the extra 10% compression improvement mentioned in the summary is from photographic images rather than illustrations then that could be quite a significant difference.

Re:Seem Negligible

[ironicsky]

I make regular contributions to charitable organizations on a regular basis. It gets deducted from my pay cheque every two weeks :)

Re:Seem Negligible

[Bert64]

A few KB saved by an end user on a high speed connection isn't much, but...
A few KB multiplied by millions of users accessing a single site soon adds up.
And it's also of benefit to those on slow or metered connections.

Re:Seem Negligible

[ThatsDrDangerToYou]

If 2-6% is nothing, why not donate that percentage of your monthly salary to a good cause?

Yes, please invest in my new bitcoin exchange. I'm calling it Mt. DevNull. Catchy!

Incremental improvements in compression are all you are going to get these days. The field is pretty mature, so 2-6% is exciting. Well, to compression geeks.

Re:Seem Negligible

[HetMes]

Would be interesting to calculate how much Wikipedia will save because of the delayed purchase of storage, and the slightly less bandwidth use.

Re:Seem Negligible

[Anonymous Coward]

Sounds like you've never been downwind of Cowboy Neal two hours after gorging at Taco Bell. The stench is unbearable.

Re:Seem Negligible

[ironicsky]

But it isn't 10%, its 2-6% :)

But I see the point, with large numbers of files served, it can add up.

Re:Seem Negligible

[Anonymous Coward]

To the narrow segment of people who have a kick ass computer, kick ass network (oc numbers you didnt know existed), and lots of free time. Then yes this is negligible.

If you have thousands of pictures that come in around 40 gig 10% is 4 gig. 4 gig of space you can do something *else* with. 4 gig of network space you can do something else with. 4 gig of data that did not need to be shoveled thru your server cpu. 4 gig of data that does not need to be read off the hard drive. Your end customer sees the data 10% faster.

Yeah this is a terrible idea who would want to get their data faster?! /sarcasm

Even the built in encoders for most PNG encoders are semi awful using zlib. I run them thru a few utils that give back the same image but compressed better.

jpegtran is a good util for shaving 5-10% off most jpegs out there.
pngout is pretty good for shaving 5-10% off most pngs out there.

Same picture no loss of quality just compressed differently.

Re:Seem Negligible

[DdJ]

The file may be slightly bigger, but who cares.

Anyone with a metered internet connection. Which is a depressingly large set of people, and signs are that it's going to get larger.

Re:Seem Negligible

[hawguy]

Seems like a negligible improvement. I mean really. With hard drive space plentiful, and bandwidth faster than most users can use at any given moment, saving 20-60Kb on a 1Mb file is like a fart in the wind, even for mobile users.

I'm with the AC in the first post, I use PNG for 90% of my images, since it supports transparency. The file may be slightly bigger, but who cares.

Seems like a negligible improvement. I mean really. With hard drive space plentiful, and bandwidth faster than most users can use at any given moment, saving 20-60Kb on a 1Mb file is like a fart in the wind, even for mobile users.

I'm with the AC in the first post, I use PNG for 90% of my images, since it supports transparency. The file may be slightly bigger, but who cares.

Slightly better? For full color photographs, PNG is *much* bigger. Anyone that's serving up a lot of images to users cares because of bandwidth and storage costs.

I picked a random Wikipedia image:

https://upload.wikimedia.org/w...

The 1200x900 JPG is around 300KB. I converted to PNG with Gimp, and the resulting file was 1.7MB - almost 6 times larger. The Filesize after converting with Imagemagick was about the same.

For busy websites, an improvement of 2-6% better jpeg compression can save significant money without changing the user experience at all.

I used to save my camera images as loss-less TIFF's or RAW's, but as my camera megapixels grew, the image sizes did too, and now I have so many megapixels that I don't even care that I'm throwing away some image quality by only saving JPG's... and I found that I rarely go back to edit older photos, I just look at them, or sometimes reprint them. No need to store files in a huge lossless format for that.

Re:Seem Negligible

[Daniel Hoffmann]

You start to care once you multiply those 2% across millions of users. Any savings at such basic level are multiplied by how often the resource is used. So no you don't care about this for your CRUD web application, but wikipedia saving 2% bandwidth translates in one less datacenter required which means thousands of dollars.

Re:Seem Negligible

[hawguy]

Slightly better? For full color photographs, PNG is *much* bigger. Anyone that's serving up a lot of images to users cares because of bandwidth and storage costs.

I picked a random Wikipedia image:

https://upload.wikimedia.org/w...

The 1200x900 JPG is around 300KB. I converted to PNG with Gimp, and the resulting file was 1.7MB - almost 6 times larger. The Filesize after converting with Imagemagick was about the same.

For completeness, I took a 94MB full color 6496x4872 TIFF and converted it to PNG (compressionlevel=9) and got a 64MB file. Then compressed the same TIFF to JPG (Quality=90), and got a 7MB file.

Re:Seem Negligible

[Chrisq]

Seems like a negligible improvement..

Yes WebP would be a better choice

Re:Seem Negligible

[Anonymous Coward]

Sure, for YOU. But what about people with limited bandwidth, cpus, and so forth? They care, and even a 10% savings on an image-intensive site (say, a lame mobile phone's gallery app) can make a huge difference over time. A few k quickly becomes a few megs. So if the price to get there is "just use a drop-in replacement for your jpeg encoder" then I say to hell with your doubts - I'll take even a seemingly-negligible improvement, not for me, but for my users.

Re:Seem Negligible

[Anonymous Coward]

Cause the goverment already sucks 60%

Re:Seem Negligible

[sootman]

Or anyone who serves gigabytes of content per hour and possibly terabytes per day -- google, facebook, wikipedia, imgur, etc.

Re:Seem Negligible

[petermgreen]

Serving static files is pretty cheap nowadays.

The main reason to keep image filesizes down on the web is to make life easier for those end users who are stuck on crappy dialup or cellular connections.

Re:Seem Negligible

[gaspyy]

This is not for the benefit of the users but for webmasters.
If you have a site with any decent amount of traffic, you pay for bandwidth and you have a content delivery network. 10% smaller images translates into 10% savings.
Moreover, Google takes site speed into account when ranking sites.

Re:Seem Negligible

[petermgreen]

jpegtran is a good util for shaving 5-10% off most jpegs out there.

Something to watch for with jpeg, "arithmetic coding" reduces your filesize compared to "huffman coding" but it also reduces compatibility. It caused me a fair bit of head scratching trying to work out why pdflatex wouldn't accept the jpegs that came out of jpegcrop (which started using arithmetic coding by default).

Re:Seem Negligible

[AmiMoJo]

Has anyone actually tried their code to see how effective it is? I don't have a system to compile it on at the moment.

Re:Seem Negligible

[Anonymous Coward]

Thus reducing the cost of the content for the end user, especially for those who are stuck on metered bandwidth.

Such reading comprehension failure is inexcusable. Clearly you also do no have an understanding of end-to-end costs.

Re:Seem Negligible

[DarkXale]

Its also worth to remember than for congested systems, a single percentage reduction in traffic will yield a significantly higher percentage improvement in service speed. 90% congestion to 85% congestion gives a huge reduction to average waiting times.

Re:Seem Negligible

[david672orford]

Seems like a negligible improvement. I mean really. With hard drive space plentiful, and bandwidth faster than most users can use at any given moment, saving 20-60Kb on a 1Mb file is like a fart in the wind, even for mobile users.

It would not be worth the effort for one website or even ten. But what is proposed is an improvement to the most commonly used JPEG implementation in the world. The cost will be amortized over millions of websites as software is upgraded over the next few years.

To see how this works, let's make up some numbers. Lets say that the whole effort will consume $100,000 worth of labor. Let's guess that within five years it will be installed on one million websites. That means it will cost $0.10 per website. Is it worth spending $0.10 per website to reduce the bandwidth use (and increase speed of loading) by a few percent?

As others have pointed out, improvements to this JPEG compressor would not reduce the size of existing static images. But it would help with images which are under the control of some kind of content managment system which recompress the images. Nowadays almost all non-trivial websites fit that description.

Re:Seem Negligible

[Anonymous Coward]

jpegcrop (which started using arithmetic coding by default).
Yeah one of the reasons I ended up with jpegtran. I use the 'change no settings' bit. So you end up with the same type of jpeg you started with. You can have it change types though to get more out of it.

Keep in mind many cameras use extremely low compression settings (but tend to use high settings in data loss with acceptable image loss). Because the cpu is rather weak in them. So they try to bash it out as fast as they can the flash.

jpegcrop actually changes the image. Which was one of my reasons for not using it.

Re:Seem Negligible

[Bengie]

For most, bandwidth is cheap and change is expensive in many ways, but a 10% difference is decent. I think people forget how useful periodic increases in efficiency is quite useful in the long run. So much of what we obsess about is not being more efficient, but faster. A 10% increase in efficiently for CPUs is easy to appreciate for less power usage, but bandwidth is much harder.

Re:Seem Negligible

[Anonymous Coward]

Wikipedia might care.

No. The Wikimedia Foundation only cares about donations and only pays lip service to the Free Content movement. In fact most foundation employees are kinda clueless about the English Wikipedia community and can barely use the software. I wont be surprised if the anti-net neutrality Wikipedia Zero comes to AT&T sponsored data.

Off the top of my head, examples of MediaWiki file bloat: If the color profile exists it is included with all thumbnails, so a 4 KB 40x40 thumbnail has a 200 KB color profile included. Scaled down pixel art or two tone images may be larger than their source image since "we're traded spatial resolution for spatial detail". Of course ImageMagik (as most photo software) doesn't gamma correct images (all of his examples are Wikimedia Commons images). And while I haven't looked too closely at the file output recently, PNGs included a full 8-bit alpha channel.

There's also a CPU concern as thumbnails are rendered and cached on the fly. I know when I did the absurd overhead report (We found a few .RAR as JPEGs) that pngout was a significant bottleneck in generating the report.

Re:Seem Negligible

[wonkey_monkey]

I found switching large photographs on my site from png to jpeg led to a noticeable loadtime increase.

Decrease?

Re: Seem Negligible

[Anonymous Coward]

Your government and insurance company are not charitable organisations.

Re:Seem Negligible

[SJHillman]

*facepalm* Yes, that would be the word I was looking for. They had me answering the Helpdesk phone today, so my brain is a little fried from too much user interaction.

Re:Seem Negligible

[hawguy]

Has anyone actually tried their code to see how effective it is? I don't have a system to compile it on at the moment.

Seems to work as advertised, if you don't care how long it takes to convert an image.

I compiled their source and ran their cjpeg against /usr/bin/cjpeg already installed on my system, and it did create jpegs that are 6 - 10% smaller in filesize with the same apparent image quality (I just zoomed in and eyeballed them side by side, I didn't do any extensive analysis).

However, at a quality level of 75, the Mozilla code took 10 times longer to run, while at a quality level of 90, the Mozilla code took nearly 20 times longer to run.

I only tested with a few images (with the lossless .ppm file ranging from 2MB to 90MB), so this was by no means a comprehensive test.

Re:Seem Negligible

[Ravaldy]

If your bandwidth as a provider of content is costing you 400K and you can reduce it by 1% by just using a new image standards, that's a nice 4K saving per year just on service. Now you have to decide if saving 4K will cost you more than 4K. In some cases it's not about saving money but rather avoiding the need to upgrade hardware and infrastructures.

Re:Seem Negligible

[Anonymous Coward]

The 1200x900 JPG is around 300KB

You can go way smaller without affecting perceived quality. Check it out at 217KB: http://imgur.com/l2oMNr0.jpg

Re:Seem Negligible

[Anonymous Coward]

Why not? Since when was a 4-10% reduction in file sizes a bad thing for users? Users will get to download smaller files, which can add up quickly to make a significant difference to many people with limited data plans. It sounds like a nice win for everyone involved to me.

Re:Seem Negligible

[Anonymous Coward]

Something to watch for with jpeg, "arithmetic coding" reduces your filesize compared to "huffman coding" but it also reduces compatibility.

You can thank patents for that. For most of JPEG's lifespan, arithmetic coding was patent-encumbered. Since it wasn't a mandatory part of the spec, almost nobody supported it.

Re:Seem Negligible

[Anonymous Coward]

I fail to see why you'd be against it at all. It is far less invasive than demanding that everyone adds a new image format to their software (let alone hardware), and it's far more likely to be supported by default.

I don't know about you, but a more or less free 5-10% win is fine by me. Argue all you want about the questionable merits of WebP but I'd rather Mozilla squeeze out more performance out of existing tech that will be with us for the decades to come than adopt a new format that doesn't seem like it will ever be feature-complete.

Re:Seem Negligible

[Chrisq]

..... a new format that doesn't seem like it will ever be feature-complete.

What features do you see WebP lacking. It uses the RIFF container format that allows XMP metadata, which itself can include EXIF data. It includes lossless and lossy modes, animation and alpha channel (transparency). What do you think is missing?

Re:Seem Negligible

[Pieroxy]

What features do you see WebP lacking

Ability to be displayed on most browsers?

Re:Seem Negligible

[WuphonsReach]

Personally, for archive-stuff, I wouldn't go lower then quality=95 which would probably be around a 14MB file (at a guess). Quality of 85-90 is fine for most websites, but you should really archive at 95-98 level.

Thumbnails can sometimes be pushed as low as 75-80 quality, but you start to notice the JPEG artifacts.

Re:Seem Negligible

[Anonymous Coward]

Ahem, to compare you need to start from the raw image every time.

raw -> jpeg, raw -> png, raw -> tiff.

Try different sceneries too.

Re:Seem Negligible

[Chrisq]

What features do you see WebP lacking

Ability to be displayed on most browsers?

Not really a limitation of WebP any more than "ability to be owned by most adults" would be a limitation of a Ferrari

Re:Seem Negligible

[Pieroxy]

So the price wouldn't be a limitation of the Ferrari? Well, it's up to you to ignore what most would consider the first limitation of the object... but still...

If WebP was available in all browsers like GIF, PNG and JPG, I would've had a deeper look into it. It's not. I couldn't care less about this file format. What use could I possibly find for it? What purpose does it serve for anyone? If you need lossy, go JPG. If you need lossless, go PNG. WebP doesn't fit any scenario...

Because it is bigger?

[Anonymous Coward]

Because it is bigger?

Exactly

[davebarnes]

PNG 8 to replace GIFs
PNG 24 to replace JPEGs

Re:Exactly

[Anonymous Coward]

What is the situation with APNG?

Re:Exactly

[LordNelsonthe2nd]

Yeah, I also love those stitched panoramas with a few GiB file size, really a great idea ;)

png is a great format of course and I use it a lot but such an generalization doesn't make any sense at all. Depending on the use case you have to decide which one you use.

Re: Exactly

[ewanm89]

1) PNG8 can support full alpha transparency.
2) PNG is better with fewer colours And blocks of one shade, as it compresses by merging close shades. JPEG is better to compress With lots of different colours like photos as it merges neighbouring pixels.

Re:Exactly

[Anonymous Coward]

Often the simplest solution doesn't cover the real world. Even with pngquant, a large photograph will be three times as large or more in PNG24 than JPEG. 300KB vs 100KB is nothing to sneeze at when you're on a mobile device and on the edge of cell coverage.

Not to mention the server bandwidth usage when the bill comes due.

Re: Exactly

[Anonymous Coward]

The type of transparency supported depends on who is defining PNG8. It can mean
8-bit indexed PNG with binary transparency, or it can mean 8-bit indexed PNG with
full transparency.

Usually it means the former because that's all the most common browser supported
back then. The question ocassionally comes up among the ImageMagick/GraphicsMagick
developers. It might be better to refer to the latter as PNG88, but for now we just
call them PNG.

Re:Exactly

[DarkXale]

A mess. Google refuses to have anything to do with APNG, preferring MNG instead. Firefox and Opera (up to v12) support APNG - but not MNG. Safari and IE supports neither.
General image software support is poor for both.

Re:Exactly

[Anonymous Coward]

DEATH TO MNG!

Re:Exactly

[Anonymous Coward]

It's extra funny now that Mozilla is refusing to implement WebP. What goes around...

Re: Exactly

[petermgreen]

Note that in paletted png files transparency is always handled by specifying alpha values for palette entries. Even if you are only doing simple binary transparencys so on a format level there is no real difference, it's just that some old browsers can't handle partially transparent palette values correctly.

Re: Exactly

[petermgreen]

It can mean
8-bit indexed PNG with binary transparency, or it can mean 8-bit indexed PNG with
full transparency.

IIRC in the format itself there isn't really a distinction, PNG transparency for indexed images is always handled by specifying alpha values for palette entries. It's just old versions of IE fail to handle them correctly.

Re: Exactly

[Anonymous Coward]

WebP has support for animation, with the advantage of supporting lossy compression in the animation. Even lossless and lossy compression together in the same animation: https://developers.google.com/speed/webp/faq#why_should_i_use_animated_webp. WebP may not necessarily be a replacement for JPEG, but perhaps it will become the new animated image format of choice.

Re:Exactly

[Boycott BMG]

Chrome doesn't have native MNG or APNG right now. They only support APNG through a plugin. Which is a shame because I am sick of seeing 256 color animated GIFs everywhere.

Reminds me of dialup

[Anonymous Coward]

In the dialup days you could use your ISPs web proxy that would super compress images using some proprietary version of JPEG (M-JPEG?) so that you'd get adequate quality and maybe 20x the compression.

These days people have 25mbit, 50mbit, 150mbit Internet connections so I wondered if it really matters? Then I realized yes it does because many websites stopped caring about how many MEGABYTES of stuff you have to download just to look at one page. Our local TV news had a store on it last year. There is an effort to help a large rural area to get high speed Internet, and they were showing how slow it is to load a single page on modern websites using dialup. Some pages could take 4 - 5 minutes to display. I remember how slow dialup used to be, and it wasn't that bad before. People put large images without caring about compression on their pages these days.

Re:Reminds me of dialup

[Blaskowicz]

These days people can use some wifi instead of paying for their own net connection. The resulting speed is highly situational but can be e.g. 70 to 90 KB/s downloads or less.

Re:Reminds me of dialup

[Anonymous Coward]

These days people can use some wifi instead of paying for their own net connection. The resulting speed is highly situational but can be e.g. 70 to 90 KB/s downloads or less.

In a rural area? Where your nearest neighbor is hundreds of feet away, well outside wifi range? Where if you don't have broadband, your neighbor certainly doesn't either? Or did you mean make the 30-45 minute drive out to the nearest McDonalds to use their wifi to check the news?

Re:Reminds me of dialup

[Blaskowicz]

I didn't want to get into details, but over here semi-private hotspots are popular and pretty ubiquitous (a significant subset of ISP provided routers double as a secure hotspot that doesn't interfere with the main user's home network). You them need codes related to the ISP at hand (some login/password). The use cases are if your DSL/broadband is down, or if your are on the move, or for "unofficial" use.

So that works in urban areas actually. Wifi isn't necessarily great if you connect to some router in the neighborhood, it goes through walls and perhaps congested spectrum and your transfer rates are limited and QoS'ed anyway. Still it can be very decent (with outage sometimes, high latency sometimes, low latency other times)

Compression/decompression speed/CPU cycles?

[Anonymous Coward]

What's the cost in time and/or CPU cycles for the 2-6% gain in compression?

Re:Still patented?

[tepples]

Where in the article are you getting anything about patents? The innovation here is to try multiple orders of sending the DCT coefficients ("figuring out which progressive coding configuration uses the fewest bits").

Needed for Digital Cameras

[crow]

My digital camera has horrible compression. I can load and save the pictures with pretty much any application, and the size of the files is reduced significantly without any noticeable image quality reduction. (And yes, I am saving it in the original size.) Maybe it's just my old Sony camera, but it's likely a common issue--I expect embedded compression in consumer devices worries more about simple and fast than best quality for the file size.

Re:Needed for Digital Cameras

[Anonymous Coward]

I reckon it is your old Sony camera that is the problem

Re:Needed for Digital Cameras

[bzipitidoo]

Do you know that the quality isn't being reduced? An image manipulation program like the GIMP may not make it too clear that it's redoing the lossy part and further reducing quality even if asked to save at the same quality,

jpegtran is a command line tool that can recompress a jpeg image without changing the quality. If the original compression was poorly done, jpegtran will shrink the file. If jpegtran can shrink your camera's photos, then you know your old camera does a hasty job on the compression. Yes, it is a common issue. Lot of these compression improvers work by more deeply exploring more choices in the compression algorithm, which takes more computing. That's how 7zip improves on zip and gz files.

Re:Needed for Digital Cameras

[Splab]

Does the loading and saving keep EXIF? My camera puts in a lot of EXIF information, stripping it out can save quite a bit of space.

Cellular

[tepples]

Not only rural areas. Tablets nowadays have more pixels than HDTV, yet cellular plans still have a single digit GB per month cap.

Re:Cellular

[Anonymous Coward]

I've seen how web designers do it. They make a really fancy PICTURE of what a web page should look like, and then use Adobe tools to automatically slice and output HTML, images, CSS, etc. Often when I work with web designers they just give me a picture of what it should look like and I have to manually craft the HTML, CSS, crop images, etc.

Compatible with all except what you want to use,

[Anonymous Coward]

is what I get from "compatible with the vast majority of decoders".

Sounds like it breaks something.

Because bandwidth is money

[Anonymous Coward]

Your source images should always be lossless and very high resolution. For geometric images, you should be using font glyphs for monochrome and SVG for multi-color or filtered content. For animated geometric images, you use SVG+SMIL. For a fallback (stupid Microsoft), you use animated GIF or JavaScript with SVG or canvas. For continuous tone images and some limited cases, you use WebP. For a fallback, you use JPEG for continuous-tone images, i.e,, photographs, and PNG for geometric images. Except for extremely simple and tiny images—less than 500 bytes—in which case GIF wins for size.

Seems like a lot of work, right? Why go through the trouble? Because SVG and font glyphs are commonly 90% smaller than PNG for geometric images. WebP is 10-20% smaller than JPEG. Images (and videos) take up most bandwidth on a site. The bigger the site, the bigger the difference in your bandwidth bill proportionally.

Oh yeah, and optimize those PNGs! pngquant to reduce your color palette when possible. PNGOUT for indexed images. Pngcrush for PNG24 and PNG32. And advpng to re-DEFLATE the output. Or use a program that bundle these tools.

Re:Because bandwidth is money

[Anonymous Coward]

For animated geometric images, you use SVG+SMIL. For a fallback (stupid Microsoft), you use animated GIF or JavaScript with SVG or canvas.

No need for JavaScript, just convert the SMIL into CSS animation within the SVG which works fine in IE10+

JPEG2000 is dead

[Anonymous Coward]

No other browser maker except Microsoft supports it, and no others even plan to. It doesn't compress better than WebP. Unlike WebP it doesn't have a lossless or paletted/indexed variant. So what is JPEG2000 even for? An alpha channel? With masking and other filter effects arriving in CSS, you can effectively add a selective alpha channel after the fact. Or just use WebP.

Firefox will be supporting WebP as soon as they consider it stable enough. Opera already supports it by moving to Blink. Chrome for Android supports it and consequently so does Android 4.4. If Safari gets it, kiss JPEG2000 goodbye forever. Microsoft simply doesn't control the space enough anymore to dictate features.

Re:JPEG2000 is dead

[Blaskowicz]

So, JPEG2000 is dead and WebP not alive yet.

Re:JPEG2000 is dead

[petermgreen]

JPEG is good enough that there is little motivation to build browser detection to serve up different formats to different browsers. So unless MS decides to support webp I don't see it taking off.

Re:JPEG2000 is dead

[K. S. Kyosuke]

Just serve WebP to anything except IE and you're fine. There also appears to be something interesting at http://webpjs.appspot.com/ .

Re:JPEG2000 is dead

[Anonymous Coward]

How about you don't do that, and instead consult the browser's accept header like a normal person.

Re:JPEG2000 is dead

[Anonymous Coward]

Because he's not a normal person, he's a commenter on slashdot.

Re:Can't wait

[Anonymous Coward]

Yesterday

I wish they would focus on WebP instead

[Flammon]

The resistance to support WebP in Mozilla seems to be more politically motivated than technical.

Re:I wish they would focus on WebP instead

[NegroponteJ.Rabit]

The resistance to support WebP in Mozilla seems to be more politically motivated than technical.

AMEN!!!! WebP is modern. JPEG, GIF and PNG are all older than most pop stars. Why do we use the image compression equivalent of MPEG1 still?

Seriously, this is so dumb. I continue using Firefox for two specific reasons (tagged bookmarks and Pentadactyl) but Vimperator and Pocket are making Chrome more tempting. I choose WebP (using the official encoder I build directly from Google's repository) for my online photo storage. Decades of photos and scans I would estimate occupy about 1/8th the space of JPEG with little perceptual difference. WebP really shines on very clean, noise-free images and occasionally I'll have 5 megapixel images compress down to under 200kb (variable block compression, it's the 21st century.

Few points about WebP. It might be nice for Google to fix encoder crashes with extremely large images, and maybe improve that GIF2WEB converter.

It is nice that Google provides an installer that makes Windows transparently handle WebP. Would love to see better support for it in KDE apps.

Re:I wish they would focus on WebP instead

[Anonymous Coward]

It seems only Google hasn't realised how awful VP8 is yet.

Re:I wish they would focus on WebP instead

[Anonymous Coward]

You mean like how Google refused to implement APNG when Mozilla asked them to, a decision which to this day has prevented animated PNGs from being useful on the web? Or how Google tempted everyone with VP8, waited for everyone to waste their time putting it into their software, and then decided to reneg on their promise to drop h264 support in Chrome?

Google hardly have any high ground in this debate, and WebP is hardly the only candidate to consider. Hell, just wait a couple months and even WebP will be obsoleted by some new version of WebP in its haughty quest to become the only image format we'll ever need.

Re:I wish they would focus on WebP instead

[roca]

Unfortunately WebP isn't all that good for a next-gen format.
http://people.mozilla.org/~jos...

Re:I wish they would focus on WebP instead

[Khashishi]

Can someone implement support as a plugin? Or is that non-trivial?

JPEG XR

[Anonymous Coward]

The resistance to support WebP in Mozilla seems to be more politically motivated than technical.

Why not add JPEG-XR as well?

https://en.wikipedia.org/wiki/JPEG_XR

Re:JPEG XR

[NegroponteJ.Rabit]

The resistance to support WebP in Mozilla seems to be more politically motivated than technical.

Why not add JPEG-XR as well?

https://en.wikipedia.org/wiki/JPEG_XR

"JPEG XR[3] (abbr. for JPEG extended range[4]) is a still-image compression standard and file format for continuous tone photographic images, based on technology originally developed and patented by Microsoft..."

Keyword in bold. Still, a very nice format.

Re:JPEG XR

[Anonymous Coward]

Excellent that you know how to read! Now, if your attention span was not limited to five paragraphs, maybe you could scroll down to the "License" section where it says how those patents affect you?

Re:JPEG XR

[spitzak]

Yes as of last April only:

"In April 2013, Microsoft released an open source JPEG XR library under the BSD licence.[41][42] ... the previously released "HD Photo Device Porting Kit"[43] was incompatible with the GNU GPL."

Re:JPEG XR

[kuwan]

That a software license covering a reference software implementation that Microsoft provided, not a patent license. They've made the patents freely available to implementers since 2007 as part of their Microsoft Open Specification Promise:

Microsoft has patents on the technology in JPEG XR. A Microsoft representative stated in a January 2007 interview that in order to encourage the adoption and use of HD Photo, the specification is made available under the Microsoft Open Specification Promise, which asserts that Microsoft allows implementation of the specification for free, and will not file suits on the patented technology for its implementation,[39] as reportedly stated by Josh Weisberg, director of Microsoft's Rich Media Group. As of 15 August 2010, Microsoft made the resulting JPEG XR standard available under its Community Promise.

JP2 is used, just not on the web.

[RandomUsername99]

Yeah, lots of universities use it for a lot of things, like scientific and cultural heritage images... they serve the images up, if need be, through the proprietary lurawave image server... not a great solution from a systems perspective, but it's what they like.

Personally, I think the lack of widespread adoption makes it a serious preservation concern.

MJPEG

[LarryRiedel]

Maybe this would be good for use with MJPEG for video editing.

Webp is amazing

[Stepnsteph]

Agreed, it's a much better choice. I actually converted my entire image library to .webp, and I use Irfanview to view the images. The filesize savings were huge, with no visible reduction in quality.

Some examples:
4.5 MB JPG -> 109 KB webp
3.66 MB JPG -> 272 KB webp
3.36 MB JPG -> 371 KB webp

One folder of mixed JPGs and PNGs with a total of 169 MBs was converted to webp. the total size of all contents of the folder ("directory", whatever you want to call it) was 6.44 MBs. I was so impressed that I kept records of the results.

Not only would this be HUGE for sites like Wikipedia, but it also significantly decreased the amount of space that I was using in my cloud storage account.

Honestly for all of their PR about a better, more open web, all we really get is the same old politics and attempts at controlling what is and is not the standards. They still behave like children. Mozilla, Google, I'm not taking sides. They're both at fault.

Re:Webp is amazing

[Anonymous Coward]

A 10x improvement strains credulity. I have to wonder if your files were special cases, maybe saved at 100% quality in jpg. After all, 4MB is pretty big for a typical jpeg, but without the resolution or the actual picture, it is hard to be confident.

Re:Webp is amazing

[fgouget]

Agreed, it's a much better choice. I actually converted my entire image library to .webp, and I use Irfanview to view the images. The filesize savings were huge, with no visible reduction in quality.

Some examples: 4.5 MB JPG -> 109 KB webp 3.66 MB JPG -> 272 KB webp 3.36 MB JPG -> 371 KB webp

It would help to know mor about your experiment. I can get quite big size improvements here by recompressing my camera's (Canon EOS) Jpeg files to... Jpeg! And with no visible quality difference either. They go from 6.7MB for the Canon file, to 3.1MB for quality 90 in imagemagick, 1.7MB for 75 and 1.4MB for 65. And ni your experiment the WebP quality scale may not exactly match the Jpeg one which makes comparisons even harder.

Re:Webp is amazing

[Pseudonym]

One of the problems with JPEG is that it works (caveat about luma/chroma subsampling) on 8x8 pixel blocks. This is great for medium-resolution images (e.g. 72-200dpi range), but not so great for high-resolution (e.g. 1200dpi).

I grabbed a 3032x1986 image (warning: large image), and here's what I got.

PNG, compression level 9: 6.1MB
JPEG 4:4:4 100: 2.7MB
JPEG 4:4:4 95: 1.2MB
JPEG 4:0:0 95: 0.9MB
WEBP 100: 1.5MB
WEBP 95: 0.5MB

Note that I have no experience with all of the WebP options. I just used -m 6 -q quality in both cases. This isn't a huge image, just a large one. So actually, I can believe the 10x figure above depending on what the original image was.

Re: Webp is amazing

[Anonymous Coward]

Some examples:
4.5 MB JPG -> 109 KB webp
3.66 MB JPG -> 272 KB webp
3.36 MB JPG -> 371 KB webp

To me those figures sound like you could have achieved much smaller file sizes with JPEG as well. I think it would be better to save the 4.5 megabyte JPEG image to a new JPEG file at 70% quality and compare that to the WebP version. 70% quality in a JPEG often looks pretty much the same as the original. It could be that the WebP image is still smaller, but it won't be such a dramatic difference and probably even less dramatic with Mozilla's new encoder.

Use JPEG2000 instead

[MobyDisk]

I would rather see JPEG 2000 support.

One word

[Anonymous Coward]

One word: mobile.

The experience for mobile users is often similar to using old-school dialup.

Responsive web design only partially solves the issue.

available in source code

[Anonymous Coward]

i thought it was a full program with menus and icons and stuff. didn't realize that it was only available in source code. guess i'll need to wait for someone to make it into a Windows 7 program or a plugin for Gimp.

JPEG is good enough

[bussdriver]

0) JPEG is past, present, and near future. Well supported everywhere.

1) JPEG optimization could be better. Mozilla is doing more of that.

2) Patents on enhancements to JPEG from minor obvious ones to significant compatibility breakers prohibit improvements. JPEG's final compression step was poor from the beginning and the better stuff was patented and unused. At least a decade ago StuffIt used modern binary compression to replace the final phase, which was exempt from existing patents; however, StuffIt patented this idea... it increased compression by 20-30% with no loss.

3) JPEG 2000 used a more modern encoding process probably similar to VP8 as far as the quantization and color space handling. Nobody uses JPEG2000 even though the smarter encoding makes compression artifacts less noticeable. The file size was not much smaller for all that extra RAM and CPU it took over JPEG - plus incompatibility. probably patents involved with it's demise as well.

4) Yet another JPEG replacement by a big corp... When everybody has MORE bandwidth, faster computers, and unimaginably more storage space on their smart phones than their desktops had in the late 90s. Why limit yourself with an obscure format to gain 30% more space when the storage you buy on sale at the end of this year will easily be 30% bigger than last year.

How much more CPU / watts will WebP cost you over JPEG?

I don't care how good it is; it has to be patent free, widespread, and proven.

Re:Still patented?

[petermgreen]

I thought the world moved on from JPEG a long time ago.

Either you are trolling or you operate in some strange niche that is isolated from the rest of the world

Back in the real world jpeg is by far the dominant format for lossy compression of photographic images. The wide compatiblity of jpeg has outweighed the advantages of more modern formats.

Still patented?

There have been a number of patent claims against baseline jpeg over the years but afaict none of them have really stuck.

There was also previously a patent on the optional arithmetic coding feature but that has since expired.

no SAT

[tepples]

Many locations don't have any other option then dial up

Are they all on a north face of a mountain? Because if there's a tall building in the way, the area is probably urban enough to get DSL or DOCSIS, and if there isn't a mountain in the way, it can more than likely get satellite.

Accurate replacement for Huffman

[Anonymous Coward]

Regarding data compression, it's worth to mention that there is a new approach to entropy coding (ANS) - while Huffman is fast but inaccurate, arithmetic coding is accurate but slow, this one is both fast and accurate.
Some implementation and sources: https://github.com/Cyan4973/FiniteStateEntropy

Re:Still patented?

[Pieroxy]

JPEG is the MP3 of images. Goo enough and so ubiquitous that nobody even tries to compete anymore.