[ronaldj]

We could make the web a lot faster and/or do some really cool stuff if we had a lossy image format with an alpha channel. It'd be nice this got picked up by all browser vendors. Sadly, I fear that they'll be squabbling over it, just like they are with VP8/Ogg/h.264.

I really believe that the companies involved in web standards are holding progress back at this point. At the same time, even if they all agreed to put this in tomorrow, we'd still be stuck supporting IE6-9 which will never have it. Being a web developer sucks sometimes.

[jws]

…if we had a lossy image format with an alpha channel…

Just what I thought last time this came up. Built it. No one came.

http://jim.studt.net/jpeg-alpha/

(I haven't looked at that code in 18 months, but it explores some options and lets you have JPEG images with alpha channels in your browser.)

[ronaldj]

I've actually used this technique before. You can also use an SVG clip path to do something similar in Firefox. When I used this technique I shipped the mask as a separate file as I wasn't familiar enough with the file format to realize I could attach it. The 63KB limit when attaching the mask to the image might be too close.

If you make an app that can take a PNG and convert it to JPEG with alpha channel can you let me know? I would be VERY interested in this.

[tagawa]

I, too, would like to see other browser vendors follow and I don't see the same obstacles as with video codecs so there's hope yet. Microsoft's plans for IE auto-updating should also help (if they decide to support WebP) but admittedly it'd still be a long wait for web developers.

We (Opera) started supporting WebP not long after its release and it's proved to be an effective improvement on JPEG. IIRC, there's a roughly 30%-40% reduction in image filesizes when used as part of our server-side compression feature (Turbo) which converts all JPEGs into WebP (among other stuff).

Of course, support in all modern browsers and being able to use WebP exclusively in public sites are not closely connected, unfortunately, but for sites with high image usage, detection for support and server-side image replacement could be worthwhile.

[ahoge]

We had such a format. It was called JNG. It's a JPG/PNG bastard which allows you to combine PNG or JPG color channels with a PNG or JPG alpha channel. Typically, it's around 20% of the size of a PNG32 image.

Unfortunately, Mozilla killed the format back in 2003, because the MNG (JNG is a subset) library added about 100kb to the installer. Yes, that was the primary reason. Their suggested alternative was to use Flash instead.

https://bugzilla.mozilla.org/show_bug.cgi?id=195280

(Note: The sizes of the libraries are the uncompressed sizes. The uncompressed size is completely irrelevant.)

[creamyhorror]

After reading this bugzilla thread, I searched and came across this interview with Stuart Parmenter, the Mozilla dev who essentially removed support:

--------------------

Parmenter: ...One of the probably biggest sort of conflicts was when-so I actually sort of own the MNG library I guess, and all the de-coders and everything. So we had this module owner system, so I guess I'm the module owner of that. And at some point, we had checked in this de-coder for the MNG format which is a multiple network-or I don't know what it stands for.

But it's basically animated PNGs. So animated GIFs were all the rage with, you know, I don't know, 1998 websites or something. And they-but GIF is basically is indexed formats and it only supports 656 colors and it only works with one bit alpha transparency. So either the pixel is there, it's not. Versus PNG, which has full-it has eight bit alpha support. So you can have 256 levels of alpha so you can-things can be translucent. As well as true color support. So you can see as many colors as you want. So basically, you try to do that.

But then something went wrong and they decided that it also needed to do all these things that, like, Flash can do. So it needed to sort of be a movie format and then it-it kind of went-something went wrong at some point. GIFs are very simple, animated GIFs are easy and they-it was basically a very big and complex thing. (emphasis added)

And then after having it in our product for, like, two or three years, we did some searchers and there were, like, fifty of these images on the web. So we decided-you know, we said, this is silly, this is like, four hundred kilobytes, you know, which was, like, three times bigger than all the other de-coders and the image library combined.

So we said, you know, this is-we don't need this anymore. So I removed it and we had a huge uproar. People were, like, "We can't believe you removed this, you know." It's, like-it was one of the, I think, probably one of the few cases where we've really gone in and said, "We're going to remove a feature that we had before." People apparently don't like that.

So I removed that. We had a lot of uproar and people said, "You know, why did you do this?" We said, "You know, we have this set of reasons. It's too big, it's too slow, it's-nobody's really actively maintaining it." What had happened is, the guy who was sort of working on it also said, "We should remove this." But then sort of the maintainer of sort of one of the MNG libraries and stuff that we were using said, "No, No, this is-you know, we'll get this fixed."

And it kind of got ugly for a while. But effectively what ended up happening was, we sort of have a system that's called a "drivers" which sort of-I guess they're in charge of the product releases and stuff or were. And sort of-it got raised up to there and in the end they sort of said, because I sort of said a thing. I said, "You know if you guys can get it under this size and you can do all these things, we'll take it, whatever."

But they never really did. And so they complained and complained and complained and they're still complaining to this day and this was, like, three years ago. So, you know, but in the end, driver said, "You know, figure out how to meet these requirements. Get an active maintainer, do these things." And nobody really has. They've made some effort but it's not really where we wanted to see it go.

I don't think they were really interested in meeting some of the requirements. I think they said, "You know, this is-." They were kind of just trying to chop random bits out and sort of mess with the functionality as opposed to sort of really reducing the size. (emphasis added)

So we got rid of it. A lot of people were mad and, you know, it just sort of-in that case, it just sort of-we just decided that was the right thing to do. But I think in other situations, you know, I think a lot of times it's sort of just very small. Like, I mean, that's kind of a big argument. But you get into a lot of much smaller ones about just kind of minor things or design things, architectural things.

--------------------

Attempting to even read this was infuriating (thanks to the verbatim transcription of none-too-eloquent speech), but it galls how some of the devs seemed anti-progress at the time. Cut off a new format with low adoption but a promising featureset, because Flash, a non-open plugin, could be used to achieve similar functionality? Would they have opposed CSS3 transforms and animation at the time, too?

The paragraphs I italicized shows how this guy thought the featureset was basically pointless - as far as I can tell from his fragmented speech, anyway - and that the size was a big deal. What I get from this is that he thought it wasn't a useful format, and so size was used as a justification to remove it.

Many salient counter-arguments were raised in that thread but essentially rejected out of hand without any engagement. Mozilla might not be a democracy, but it would have behooved them to listen to users/contributors/stakeholders more in this case.

[ahoge]

Oh boy, that "interview" was horrible. I now got a headache and want to punch something.

[Lazare]

Good god, that was INFURIATING. Let me summarize it:

Dev 1: MNG sux, lol. It's like, 100kb of wasted space.

Many Users: MNG is good, and the space is nothing!

Dev 1: Oh...well, lol, I'm bored maintaining it.

User: I wrote the library and I'll maintain it!

Dev 1: Oh, lol. MNG sux, and you suck too. Just use Flash or gifs, k?

Many Users: Those are proprietary and patent encumbered, and MNG has features they don't anyhow. This will break a ton of stuff, including the default theme! And MNGs are used a ton in Asia!

Dev 1: ...whatever, lol. Only losers use MNG, and I'll make a new gif for the theme.

Dev 2: Sounds good to me! Say goodbye to MNG support, losers.

Dev 1: lol!

Meanwhile, Firefox is still bloated, there's still a need for something like MNG, and Chrome is busy eating Firefox's lunch in large part because of the exact behaviour displayed on that bug.

sigh It makes me want to slap the two people involved. That thread should be used in a textbook of "how open source projects become large, bloated, and end up being run into the ground via a concerted effort to annoy users and keep people from joining the dev team". I don't think I've ever seen such a concerted effort to try and discourage a potential maintainer and rip out perfectly working useful code before.

[sitkack]

reading that bug report made me cry. The use of MNG in one session of web browsing would have saved more bandwidth than used by the extra space in the installer. wtf.

[ahoge]

Those fancy single page sites with lots of parallax effects and transformations often have 4-5 MB worth of PNGs. With JNG you can easily push it below 1 MB. (I tried this with several websites.)

To make matters worse, if you just support JNG and not all of MNG, you'd add maybe 5-10kB. The PNG and JPEG decoders do all of the heavy lifting. You'd just need a little bit of extra code for taking the file apart and splicing the channels together. All of the tricky stuff is already there.

[sitkack]

What keeps one from implementing a pure javascript implementation that renders to canvas? Do we need browsers to support formats anymore? With WebGL, WebCL, high speed JS and the canvas tag don't we have everything we need?

[ZeroGravitas]

There's already such javascript libraries in existence for WebP (they also do WebM).

http://webpjs.appspot.com/

http://libwebpjs.hohenlimburg.org/vp8/webm-javascript-decode...

(There's also a shortcut in browsers like Firefox that support WebM and not WebP where you can turn a WebP file into a single frame WebM video and display it to canvas).

I would imagine that's a good route for lesser known image and audio formats (possibly even video formats) and backwards compatability but I'm not sure it's currently ideal for most image decoding on the web.

Someone should really try it out and see though, it's probably only a matter of time before things like this start moving into javascript.

[pornel]

> We could make the web a lot faster and/or do some really cool stuff if we had a lossy image format with an alpha channel.

We do!

http://pngquant.org & http://pngmini.com/vs-webp/

Sadly, very few people know about it and make good use of it. Mostly it's lack of awareness and dominance of poor/outdated tools (cough Photoshop cough) that don't fully utilize formats we have.

[magicalist]

Those are really nice, and the gallery goes a long way toward making the case for it.

It's worth underlining the fact that "lossy" here means "really nicely dithered 256-RGBA-palette PNG8s", but (as the gallery examples demonstrate), that may be sufficient for most of the kinds of images that have significant transparency and that would be likely to be found on a webpage (even sprites for a canvas game).

Honestly, I would still like to see WebP support in spite of its drawbacks (thanks software patents!) for it's better definition of "lossy" and for saner alpha compression, but between better pngs from software like this and upcoming support for DXT5 in WebGL, most of the compelling market drivers may be gone.

[pornel]

There's also a second option — adaptive posterization — that reduces PNGs by ~30%. Useful for images that are too "colorful" for 256-color RGBA.

WebP is a fine format, but establishing a new format on the web is really hard. There's a graveyard of better JPEGs, and after 16 years since PNG was published, GIF is still alive and well. http://ycombinator.com/images/y18.gif

The web has strong preference for "good enough that works everywhere". IE6 was enough to discourage devs from using PNG, nad you won't see Google's WebP in IE or iOS anytime soon.

Nowdays you can decode WebP with JS, but size of a JS decoder and CPU time to run it will most often offset any savings from the format.

[albertzeyer]

I haven't really tried it yet but I wonder if you might get ugly artifacts if the alpha channel is lossy. Maybe it has to be exact.

[pmjordan]

You'd probably be OK as long as the alpha extremes (0 and 255) were lossless; everything in between could probably cope with being slightly off, especially if you could control the quality of alpha and YUV separately, and the YUV quality was (somewhat) weighted by alpha, with a 1 pixel "border" into transparent areas to support interpolation when scaling. Lossless alpha and lossy YUV is already a major improvement over the status quo, however.

[ChrisClark]

In a lossy WebP file with alpha, RGB is lossy but the alpha channel itself is lossless.

[ahoge]

Artifacts in the alpha channel are surprisingly subtle. Well, it makes sense if you think about it: The opacity is low, which makes those little details very hard to see.

A gray-scale JPEG with medium quality (even if it was written by a somewhat crude encoder) will look perfect if used as alpha channel in the vast majority of cases.