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.

[Anonymous Coward]

5% of image bandwidth saved for someone like Facebook is millions of dollars in operating expense. Get a clue.

Re:Hard to get excited.

[gstoddart]

and video is the vast majority of the internet

And yet, you're posting that on a web site which is mostly text.

I suspect a 5% decrease in size yields a very large percentage in bandwidth savings over time.

And there will always be people with slower links who will benefit from this.

Re:Hard to get excited.

[tysonedwards]

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.

Re:Hard to get excited.

[Sigma 7]

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.

Most videos (at least those linked to from meme-based image sites) are stored in GIF format, despite them taking twenty times the bandwidth/file size of the Youtube video they're based on.

Thus the best way to save space/bandwidth is to find a way to optimize compression of .GIF files.

Re:Hard to get excited.

[gstoddart]

But what fraction of videos on Facebook are actually served by Facebook?

Most of what I see on Facebook is just links to external sites, and Facebook doesn't host it at all.

Re:Hard to get excited.

[mythosaz]

I should use a smaller font then, I think.

Re:Hard to get excited.

[gstoddart]

Totally, going from 12pt to 10pt is a 20% savings. Got for a 6pt font and you can save 50%.

Add that to the 5% savings in the jpegs, and that's a lot of extra porn you can download before you fill the tubes.

Re:Hard to get excited.

[omnichad]

...low hanging fruit like cutting the 37% of their bandwidth used on videos by 20-30% by getting HEVC or VP9 really working well

If they wanted to tackle the low-hanging fruit, why not stop auto-playing video at all?

Re:Hard to get excited.

[Daniel Hoffmann]

Don't some video codecs use JPEG algorithms to encode the i-frames? This could translate in better video compression too.

Re:Hard to get excited.

[gstoddart]

If they wanted to tackle the low-hanging fruit, why not stop auto-playing video at all?

Ad revenue.

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:Hard to get excited.

[Russ1642]

Any company that can save millions from something this small is so big that millions don't mean anything.

Re:Hard to get excited.

[nickittynickname]

You know facebook owns instagram right?

Re:Hard to get excited.

[omnichad]

There is no ad revenue to be made from a video recorded by a friend starting to play automatically in my feed. It plays the video, not an ad.

Re: Hard to get excited.

[Kumiorava]

Even the biggest companies care about million(s). Reduction in operating expenses are always a good thing and if facebook can shave off million dollars a year without significant downsides they will take it gladly. Big companies didnt get big by being inefficient.

Re:Hard to get excited.

[makq]

And this is a great demonstration of why people hate IT departments.

Re:Hard to get excited.

[Gerald]

Most of the pages on my web sites have a combination of PNG and JPEG content and almost no video. Smaller images means faster page load times for my users.

Re:Hard to get excited.

[gstoddart]

I am aware of that fact, yes.

However, never having seen or given a damn about Instagram ... I have no idea of it supports videos or not.

I would have to take extra steps to watch videos on the internet.

Like installing Flash or caring. Thus far, I've done a remarkable job of doing neither.

Re:Hard to get excited.

[wonkey_monkey]

Luckily we don't care, because we're right.

Re:Hard to get excited.

[radish]

Don't forget storage. Bandwidth is one thing, but image storage is a big deal for sites like FB. They often store multiple copies of each one (e.g. at different sizes) and then you also have copies cached on CDNs etc, which also costs money. 5% isn't going to make or break the company, but it's worth investigating.

Re:Hard to get excited.

[SuricouRaven]

Yes. I've written a program that achieves a similar saving for PNGs and other lossless formats by making them very slightly lossy (It actually works by slightly adjusting the boundary between quantization bands, so no pixel ever changes value by more than a tiny, definable amount). What happens to it? No-one wants something like that, so it joins all my other dabbling in obscurity.

Re:Hard to get excited.

[aardvarkjoe]

Most videos (at least those linked to from meme-based image sites) are stored in GIF format...

While I don't disagree that the storing videos in GIF format is incredibly inefficient (and annoying), I somehow don't think that "meme-based image sites" are actually a significant fraction of internet bandwidth use compared to websites that use more standard video formats.

Re:Hard to get excited.

[BronsCon]

You know the Instagram app could do the image compression client-side, right? This would help there, as well, without costing Facebook a single extra CPU cycle.

Re:Hard to get excited.

[TechyImmigrant]

Luckily we don't care, because we're right.

No, you are wrong. This kind of analysis was debunked before I got to college 30 years ago.

Just because something on the computer takes more or less time doesn't mean the user isn't adapting and overlapping other behaviors during those 3 seconds. Do a controlled experiment and come back when you have real data.

If your analysis is so great why aren't you advocating moving to technologies that take less time to bring up a record? Or pre-loading the next record, or anything to save your oh-so precious 300 seconds per worker. I'm glad I don't work in your sweatshop.

Re:Hard to get excited.

[Selur]

so donating 60k isn't really much,..

Re:Hard to get excited.

[retchdog]

this kind of thing probably does help, but, yeah, not because of the magical linear time bank.

rather, something that keeps the user's attention often means less coffee breaks and chit-chat. waiting sucks.

Re:Hard to get excited.

[stewsters]

Who's to say they don't have a few coders working on better video codecs? They seem at least to be hiring for video chat: https://www.facebook.com/caree... Every bit counts with a site their size. Google doesn't even close its tags.

Re:Hard to get excited.

[Thud457]

They just ripped this off from Pied Piper. Probably can't even handle 3D video properly.

aw crap, I have shamed myself.

Re:Hard to get excited.

[tlhIngan]

Just because something on the computer takes more or less time doesn't mean the user isn't adapting and overlapping other behaviors during those 3 seconds. Do a controlled experiment and come back when you have real data.

3 seconds is long enough to be annoying, and short enough that an annoyed user will take longer than 3 seconds.

After the update, they'll waste 3 seconds each time. Then after a week, they'll use those 3 seconds to respond to a text on their cellphone, or an IM, or browse Facebook. So now that 3 second time takes 20 seconds to a minute because the user got bored waiting, switched to something else, then switched back much later.

So now that 3 seconds cost up to 60 seconds.

And if that happens often enough (100 minutes is over an hour), that 100 records may turn into 90 records.

Of course, it makes the assumption that the record opening time is instant - you click it, and it responds instantly. Now you click it and wait. Which makes a huge difference - it actually gives the appearance of slowness if you clicked and it instantly displayed versus you clicked and now have a wait. Most users would find a way to occupy themselves in that wait that takes far longer than 3 seconds.

Re:Hard to get excited.

[tepples]

Good luck getting Apple to add WebM support to iPod touch, iPhone, or iPad.

Re:Hard to get excited.

[Belial6]

Your math is a lie.

Re:Hard to get excited.

[narcc]

Perhaps it's because no one (importnat) has seen it? Put together a paper for the relevant ACM SIG conferences.

Re: Hard to get excited.

[bill_mcgonigle]

so, apparently it's only worth $60k to them.

Re:Hard to get excited.

[TechyImmigrant]

If the user opens a record and waits 3 seconds then spends 30 seconds staring at the record or typing in it or talking to a customer, then the UI is messed up.
The computer is pretty idle in the subsequent 30 seconds and can be loading the next form in the background.

The people who use my PoS like it not because of it's neato use of python and ncurses. They like it because it responds instantly, is very non modal and never required more than two or three keystrokes to complete a transaction. If you are paying 1000 people to use your badly designed UI, you need to fix the UI first.

Re:Hard to get excited.

[ArcadeMan]

But can your program beat the compression done by ImageOptim and ImageAlpha?

Re:Hard to get excited.

[Bite The Pillow]

Why would they transcode all existing images? They could re-scale the thumbnails, but they wouldn't dare touch the originals unless they were so massive it made sense to give it a go.

Thumbnails for new images, ignoring existing ones, would more than pay off in just one more world cup, simply by replacing the existing implementation with this one.

So let me re-phrase. Mozilla open source people who can work on stuff because they want to, or can attribute some generic benefit, have teamed up with one of the largest image hosts in terms of active usage, to see if their benefits also help the image host. If this had not been a news item, no one would have noticed. Is FaceBook using subscription fees to make investment in minor advancements instead of something useful? No, it looks like they are just trying stuff out, kinda like they always do.

So what's the down side here that we need to shit on this news about?

Re:Hard to get excited.

[Mal-2]

Most videos (at least those linked to from meme-based image sites) are stored in GIF format...

While I don't disagree that the storing videos in GIF format is incredibly inefficient (and annoying), I somehow don't think that "meme-based image sites" are actually a significant fraction of internet bandwidth use compared to websites that use more standard video formats.

Not to mention that our poster child for "meme-based image sites" now supports webm, and the format has become incredibly popular there.

Re:Hard to get excited.

[spacefight]

It keeps you longer on Facebook, so FB can show you more ads. More impressions, more clicks.

Re:Hard to get excited.

[SuricouRaven]

No, but it works through different means: My thing + imageoptim > either alone.

Re:Hard to get excited.

[SuricouRaven]

I'm just a hobbyist tinkerer, I have no qualifications between a not-very-good engineering diploma and no idea how to go about something like that.

Re:Hard to get excited.

[ArcadeMan]

But you can also do three types of colour reducing with ImageAlpha and then compress further with ImageOptim.

Re:Hard to get excited.

[omnichad]

No, it doesn't. I don't keep a Facebook tab open, mostly for that reason.

Re:Hard to get excited.

[Shirley Marquez]

One fundamental difference. Improving the JPEG encoding used by Facebook would reduce their bandwidth use without requiring users or browser developers to do anything. Moving to H.265 or VP9 video encoding requires two things: that browsers add support for those video formats (some have already done that), and users upgrade to browser versions that include the support.

Most likely, Facebook would not transcode existing images; unless they saved the originally uploaded files (rather than the transcoded ones they made when they were uploaded) that would involve generation loss and thus a degradation of image quality. They would use the new encoder when they transcode new uploads. YouTube DOES retain the original uploads (though they did not in the early days which is why many older videos are only available in 240p or 144p) so they have been able to re-encode videos as new formats become available.

Tiny bumps in JPEG performance

[chrylis]

and still no merge of the working WebP patch that was proposed four years ago because NIH.

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

Re:Tiny bumps in JPEG performance

[rrp]

One problem with your logic is that WebP isn't just a replacement for jpeg. Sure it can be used that way, but WebP also supports alpha channels and animations. And yes, you can argue that we can just use a HTML5 video for that (except I've only heard of Chrome supporting transparent videos at the moment...), but it's much more complicated than creating a WebP with those features, and it can be shown on a website with a simple img tag, IMHO. And being able to take for example a 10 MB animated gif and shrink it down to around a 1 MB animated WebP seems like a worthy enough cause to me.

Re:Tiny bumps in JPEG performance

[rrp]

WebM is great for what it does. I definitely support tools that use WebM to replace gifs, like gfycat. But it still can't do transparency (except in Chrome) and as I said it's more complicated than creating a WebP with those features. There are some things that only WebP can do at the moment, which is why it shouldn't just be dismissed like Mozilla has done.

Re:Tiny bumps in JPEG performance

[roca]

We agree that alpha channel and animations are required features for any next-gen image format, but that doesn't change the analysis. It doesn't make sense to try to get WebP support everywhere for those features or for small compression gains, when in a couple of years or less we could introduce a new format with those features and big compression gains.

Re:Tiny bumps in JPEG performance

[Njovich]

so we know a much better format than WebP is technically available *now*. [...] 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).

So what you are saying is that for the next few years (plus the past 4 years), WebP was available for you to use, better than mozjpeg is even now (and having a bunch of extra features like lossless compression, animations, alpha channel), but you will not use it because you are waiting for some hypothetical file format that may exist in a few year and will provide better compression?

Can we please have the old Mozilla back that was more interested in building a great browser than having petty conflicts over formats?

Re:Tiny bumps in JPEG performance

[AmiMoJo]

So what if WebP is only slightly better than mozjpeg? That isn't a reason not to include the patch. Even a slight improvement is worthwhile for site owners and people on limited speed connections. What reason is there NOT to include it?

Re:Tiny bumps in JPEG performance

[olau]

I think the reason is that once it becomes widespread, all browsers will have to carry the support forever, not just distributing the code but also maintaining it (fixing security bugs etc.).

Re:Tiny bumps in JPEG performance

[rrp]

WebP already has big compression gains. Just not in comparison to a static jpg. But compared to an animated gif it's a huge savings. I know I'm not going to convince you or Mozilla to change your positions, but to outsiders, who aren't involved in the browser wars, it seems rather silly that you guys won't add support for this just because something better might come alone a few years down the road, when there's nothing else available to do it now.

The future turned out to not be so cool

[CRCulver]

A decade ago, nerds sometimes posited that in the future, connectivity will be so fast, RAM/storage space so large, and processors so powerful that the world might just switch to lossless formats. Here we are in 2014 still trying to trim a couple of percentage points off JPEG file sizes, and web designers still advise keeping images under 100k each or so.

Re:The future turned out to not be so cool

[mwehle]

Yes, but this is still 2014, not the future, silly!

Re:The future turned out to not be so cool

[gstoddart]

Yes, but this is still 2014, not the future, silly!

Correct, now is now.

But back then, now was then, and now was in the future. Of course, now 'then' was back then, and was the past. In the future, now will also be in the past, as will then. But by then, then will be now and then will be the present. The future present, not the current present.

So, soon, when now is later, the then now will be then, and now will still be in the past. But by then we won't have to worry, because it will be now, and I've already told you what happened.

Every now and then you need to remember which now, which then, how long until then is now, or how long ago then then was now.

Then you can say that you did know now what you knew then. Of course, when you say now then, it will be a different now than now, because it will be then.

It's all very complicated now, but by then it will make perfect sense.

Re:The future turned out to not be so cool

[mythosaz]

It's all very complicated now, but by then it will make perfect sense.

Colonel Sandurz: Try here. Stop.
Dark Helmet: What the hell am I looking at? When does this happen in the movie?
Colonel Sandurz: Now. You're looking at now, sir. Everything that happens now, is happening now.
Dark Helmet: What happened to then?
Colonel Sandurz: We passed then.
Dark Helmet: When?
Colonel Sandurz: Just now. We're at now now.
Dark Helmet: Go back to then.
Colonel Sandurz: When?
Dark Helmet: Now.
Colonel Sandurz: Now?
Dark Helmet: Now.
Colonel Sandurz: I can't.
Dark Helmet: Why?
Colonel Sandurz: We missed it.
Dark Helmet: When?
Colonel Sandurz: Just now.
Dark Helmet: When will then be now?
Colonel Sandurz: Soon.
Dark Helmet: How soon?

Re:The future turned out to not be so cool

[gstoddart]

I'm fairly certain they'd all drop the obsession with lossless formats that they had when a large image was 640 x 480.

In 1994, more than a few of us were using dialup modems, and we wouldn't have believed you.

Or, more accurately, we wouldn't have been willing to wait 20 years for porn at that resolution.

Like so many things, people who say "in 20 years we'll be doing this" tend to get laughed at. Because the track record of people predicting what we'll be doing in 20 years is pretty sketchy.

Re:The future turned out to not be so cool

[Desler]

That's because those nerds were idiots.

Re: The future turned out to not be so cool

[loufoque]

Not if they use pngcrush first.

Re:The future turned out to not be so cool

[Guspaz]

Corporal: Sir.
Dark Helmet: What?
Corporal: We've identified their location.
Dark Helmet: Where?
Corporal: It's the Moon of Vega.
Col. Sandurz: Good work. Set a course, and prepare for our arrival.
Dark Helmet: When?
Corporal: Nineteen-hundred hours, sir.
Col. Sandurz: By high-noon, tomorrow, they will be our prisoners.
Dark Helmet: WHOOOOOOO?!?!?

Re:The future turned out to not be so cool

[toejam13]

A decade ago, nerds sometimes posited that in the future, connectivity will be so fast, RAM/storage space so large, and processors so powerful that the world might just switch to lossless formats. Here we are in 2014 still trying to trim a couple of percentage points off JPEG file sizes, and web designers still advise keeping images under 100k each or so.

Some of that is due to the rise of mobile computing. The computing power and data connectivity of mobile handsets are running about a decade behind desktop computers, so the least common denominator problem has remained somewhat static. And even as that market matures, rural areas and users will continue to lag for some time.

In addition, for any increase in computing power and data storage, we've often seen an equal increase in resolution and bit depth. A decade ago, 480p videos were the norm. Now we're now up to 1080p videos. Within a decade, it'll be 2160p videos. Same deal with digital cameras that have jumped from 5MP or less to 20MP or more today.

I'd argue that lossless formats like FLAC and ALAC were adopted early in the audio world because music files have generally remained fixed at 44.1kHz × 16bit × 2 channels. Movies have somewhat settled at 48.8kHz × 24bit × 6 channels (with 192kHz being the ceiling). They're also relatively small from the start. Lossless formats in the video world outside of the editing room or archival repository don't make sense. Same with raw image formats for cameras.

We've also seen an increase in the number of users, which in turn results in an increase in the amount of data. How many MySpace visitors were there in 2006? How about Facebook today? About ten times as many. And Facebook encourages more uploading than MySpace did. If people are satisfied with good enough, it just doesn't make economic sense to go lossless.

Re:The future turned out to not be so cool

[Lehk228]

I remember back when images over 15k needed to have a damned good reason for being over 15k

Re:The future turned out to not be so cool

[petermgreen]

I think the largest PNG file that I've been aware of was under 500KB.

I'm sure i've seen bigger.

A 1080p frame in uncompressed RGB is about 6MB. Afaict PNG gets of the order of a 3x ratio on photographic data so we are probablly talking a couple of megs of png if someone lifts a frame from a 1080p video.

You should be able to download that in less than 1/6th of a second with 24mb.

Unfortunately the intenet architecture doesn't handle short connections well. The TCP/IP stack doesn't know what the available bandwidth is so it has to be conservative initially. On high bandwidth but also high latency connections (e.g. user in europe, server in the USA or vice-versa) it often doesn't reach the full speed available before the transfer is over.

I just took a screenshot of my dual-monitor desktop and it was about 125KB. And that's just saving it with MS-Paint

This is pretty meaningless without knowing what was on the desktop at the time.

Re:The future turned out to not be so cool

[ChunderDownunder]

Migrate to Australia, then. :(

The ghost of Uncle Rupert and Big Coal will still be dominating. Our current treasurer, Joe Quixockey, tilts at Canberran windmills.

And I just want Firefox not to shit itself

[drinkypoo]

G+ is making FF crash its ass off these days. It would be a fun paranoid speculation to imagine that Google knows of bugs in FF which can be triggered with mundane code to make my browser asplode, but even if it were true it would be irrelevant because mundane code shouldn't blow up Firefox.

Re:And I just want Firefox not to shit itself

[The MAZZTer]

Start Firefox up in safe mode and see if it still happens. Chrome did right doing extensions the way they did... the way Firefox did it, it's near impossible to tell the difference between a problem caused by the browser or one of its addons.

Re:And I just want Firefox not to shit itself

[Ash-Fox]

That's only an issue for adblock+ users.

Re:And I just want Firefox not to shit itself

[gstoddart]

That's only an issue for adblock+ users.

Not a problem if you don't use G+. Certainly not my problem.

Re:And I just want Firefox not to shit itself

[Megane]

I instead have a non-paranoid speculation that the FireFox people keep adding new buggy features faster than Google can swerve to avoid the bugs. So I use SeaMonkey instead.

Re:And I just want Firefox not to shit itself

[gstoddart]

Or, alternately, Google introduces the suck faster than anybody else can counterbalance it.

Just sayin'.

Re:And I just want Firefox not to shit itself

[H0p313ss]

G+ is making FF crash its ass off these days.

If only there was a simple workaround for this, but it's just not coming to me.

Re:And I just want Firefox not to shit itself

[drinkypoo]

I find the web unusable without Adblock+, especially on my kiddie-grade 5Mbps max WISP connection. And Chrome's Adblock+ is still inferior to Firefox's, or I'd run chromium.

Re:And I just want Firefox not to shit itself

[drinkypoo]

The current extended support release of Firefox eats memory until the browser croaks or the offending tab is closed

Yeah, I wasn't going to go into that, but I actually tried that release hoping that an ESR release would be a good thing. But I guess I should have known better. I followed ESR on G+ for a while. That was a mistake. ;)

Re:And I just want Firefox not to shit itself

[Ash-Fox]

I find the web unusable without Adblock+, especially on my kiddie-grade 5Mbps max WISP connection.

I don't. I have a simple proxy.pac file that sends a few annoying advertiser domains to use a proxy connection on 255.255.255.255 (and for US-access only sites, hits my local ssh proxy to one of my US servers).

I should also note that I travel frequently (Monday through Friday) and I am often on mobile Internet.

Re:And I just want Firefox not to shit itself

[Ash-Fox]

Not a problem if you don't use G+

And that's how the day was saved by Captain Obvious.

Save even more bandwidth for facebook users!

[BenJeremy]

Take all landscape photos and crop 33% of the space on the left side and 33% on the right side. I see they already do this to widescreen videos taken on smart phones.

I just saved 66% of their bandwidth, and made the images more appealing to hipsters and guidos!

Re:Save even more bandwidth for facebook users!

[gstoddart]

Bah, you could replace 33% of all Facebook pictures with cute cat photos, and nobody would even know the difference.

NIH, or once-bitten twice-shy?

[Millennium]

Google has deliberately killed more technologies than Microsoft ever just let wither and die, and Mozilla has been burned by this more than once. At this point, I'd say it's quite reasonable to demand that Google provide some assurances that it's not going to flake out this time.

Re:NIH, or once-bitten twice-shy?

[STratoHAKster]

Google has deliberately killed more technologies than Microsoft ever just let wither and die, and Mozilla has been burned by this more than once.

Really? You just throw this assertion out there without spending the extra few seconds to name a few of these technologies? I'm really curious.

Re:NIH, or once-bitten twice-shy?

[amRadioHed]

Google has killed services before that cost them money to continue operating, that's not the same thing as an open source codec at all.

Re:NIH, or once-bitten twice-shy?

[rrp]

The problem with APNG is that it was not adopted and is not supported by the PNG group. That means the official libpng source has no support for it and will never have support for it. Thus making it a non-standard. Instead the PNG group chose to support MNG. So Google chose to go with the standards; they're not just doing it "because reasons."

Re:NIH, or once-bitten twice-shy?

[Elbart]

WebM?

HSA decoder

[ponos]

AMD recently presented HSA-enabled jpeg decoding. That would also be an interesting addition. Make these shaders work a little...

http://developer.amd.com/resou...

Secret new facebook image compression method!

[linebackn]

Here is how their new compression method works. It reduces all images down to a single one or zero. If the bit read in is one, it display a picture of a cat. If it is zero, it displays a picture of Peter Griffin farting. And as a bonus, if no bit can be read, it displays the goatsex guy.

Formal verification

[Burz]

Why indeed would Mozilla waste their resources on this when stability and security on web clients ought to be their greater concern?

If it were up to me, I would start with self-contained date formats like JPEG that browsers handle frequently, and put that code through a formal verification process. Eventually, maybe even HTML rendering and the browser could be subject to formal verification. This could strengthen computer security dramatically.

Facebook could do more

[stewsters]

If Facebook really wanted to help reduce global bandwidth and was willing to play hardball, they would just switch their images to webP suddenly, and display a message to update your browser if you cant see them. Microsoft would have to fold if suddenly their browser didn't show images. Not sure if FB is large enough to survive the backlash, but if they are we could see new codecs in IE within the month.

No WebP in any web browser for iPad

[tepples]

Microsoft would have to fold if suddenly their browser didn't show images.

With Apple holding a monopoly on web browser engines on 36 percent of tablets, it arguably has room to play hardball with Facebook.

Re: Worthless

[fatgraham]

Next week

Balderdash.

[jensend]

Any "nerd" who posited that bandwidth and storage concerns would be so totally irrelevant that we'd happily waste 10-20x as much of them for practically zero benefit was not so much a "nerd" as a total idiot. Having more bandwidth means you want to do more with it, not waste it for no reason.

Real "nerds" worth the cred understand that not only does lossy compression provide great results at small fractions of the sizes of the best lossless representations, but research into lossy compression also helps us understand the structure of real-world information, intelligence, and human perception in new ways.

A future where we have lossy formats which achieve results equal to today's formats in a quarter the bandwidth because we've come to better understand the structure present in real-world signals and the ways humans perceive and interpret information is a cooler and more exciting future than one in which we [url=http://scholarlykitchen.sspnet.org/2012/01/19/the-hidden-expense-of-energy-costs-print-is-costly-online-isnt-free/]waste exajoules of energy and help destroy the planet[/url] by sending each other millions of terabyte-sized high resolution lossless cat videos.

oops

[jensend]

that'd be this link

that'll teach me to use preview esp. when I've been spending too much time on sites where the article discussions use bbcode

What we really need

[ArcadeMan]

What we really need is a new container format that combines the image data of a JPEG with the 8-bit transparency layer of a PNG image.

Re:What we really need

[petermgreen]

It exists, it's called JNG but support for it is poor :(

Re:What we really need

[ArcadeMan]

And even if support for it was added tomorrow, we probably couldn't use it for another decade or so because of Internet Explorer (insert version numbers still in use today).

Not JPEG2000?

[Anonymous Coward]

As long as the renderers support it, and it doesn't come saddled with unFRANDly baggage, it will probably do fine.

However, Mozilla has a questionable track record, when it comes to support for standard media.

As a Web developer, it rankles me to have to store double the size of the video on my server, just so that stubborn developers can have their way.

False equivalence

[Bite The Pillow]

False equivalence. Facebook could use that $60k to fund/bribe inclusion of WebP, or maintain their own build of AssWeasel or whatever fork they want to call it.

Or they could entice users with "if you want to see pictures, click here". That works really well, and the facebook using billions might convert to something other than firefox.

Or, they could be supportive of this new tech and not use their massive market share to clobber open source into submission.

On the other side of the argument, NIH is a terrible summary of this link, found on the page you linked to.

http://muizelaar.blogspot.com/...

WebP seems like it has grown a lot - which means keeping up with another imaging library and testing something that is continually changing. Given the limitations mentioned, it hardly seemed worth the effort. And problems with the new patch abound - no tests, breaking Windows build, and devolution into a discussion forum.

Take the opinion that you don't care either way, and read through that bug with an open mind. It's hoseshit, top to bottom, and I don't blame anyone one bit for keeping WebP out.

How does it compare to JPEGmini?

[XNormal]

JPEGmini is a proprietary implementation of the same concept : fully compatible implementation of a JPEG compressor that does better than libjpeg at the cost of much higher CPU use.

I'm not convinced webP is better

[AC-x]

I'm not convinced webP is better, I've done a quick comparison and to my eyes JPEG beats it on like for like file sizes:

40k jpeg vs 40k webP (images converted to png for your viewing convenience)

Compared to the lossless original (one of Google's own webP comparison images) the webP version has lost more chroma resolution, leading to desaturation in parts and blurring of strong colour details like the red arm band.

It would be nice as a replacement for PNGs with alpha channels though.