I always wondered why browsers don't support any lossy 32bit image format. With opaque images you can always pick a suitable image format, which will be reasonably small while looking reasonably good. There are always some trade-offs, but that's alright.
If it's photo-based (or just a plain photo), JPG is a great choice. If there are less than 257 colors a PNG8 will work great. If it's also very tiny (like a 1x13 gradient) a GIF might be even a tad smaller than a PNG8. If there are only a few thousand colors and little noise (i.e. there are large areas filled with a solid color), a PNG24 should work great.
Now, if you throw alpha channels into the mix, things become a bit annoying. PNG8 and GIF support so called "bitmask transparency", which marks one specific color as fully translucent. PNG8 actually supports one transparency value per palette entry. This means it's effectively like an RGBA palette with up to 256 values. This option is somewhat less well-known and the support by most tools is also somewhat lacking.
So, this area is covered pretty well by current browsers. However, once you need a "few" more colors, you'll run out of options. There is only PNG32 and – as we all know – PNG is a poor choice for photo-based images. Well, of course it will look perfect (it's lossless after all), but it will be prohibitively huge.
It's sorta ironic, but my first idea was hack up the PNG format and add some extra chunk (sorta what APNG did). As I learned a couple of weeks ago, such a thing actually exists. It's called JNG and it uses PNG as container and the RGB data is stored as JPG in an extra chunk.
Perfect, let's go with that!
The primary reason was file size:
* mng decoder module is roughly the same size as all the other image decoders and libpr0n logic combined. Linux sizes: 261796 libimglib2.so 241492 libimgmng.so MS-Windows sizes: 155024 imglib2.dll 170336 imgmng.dll
That's like a bad joke, really. On one site I had to use one PNG32, which was over 300kb in size. JNG would have saved about 250kb. And that's just one site and one hit.
But it gets worse, both Windows libraries are about 325kb in size. Uncompressed, that is. With LZMA compression (which is typically used by any good installer), the size would be reduced by more than 50%. So, even if a user visits that site just once, it would have been worth it.
Another reason which caught my eye:
* animated gifs and flash (and possibly svg in the future) cover much of the feature set of mng. jng is a bit more interesting, but not in ways that most people will care about.
I really love the promotion of Flash there. Stuff like that just won't happen nowadays. :)
But yes, JNG is indeed "a bit" more interesting. I'm not really sure what he meant with that attached remark though.
I don't care about MNG, but JNG should really be a no-brainer. A look at the current decision matrix should be all you need:
Also, the whole MNG library isn't necessary if you only want JNG. If you can read JPG and if you can also read PNG, you already got more than 99% of the code you need for JNG. The only thing that's missing is a little bit of glue. I guess it's even less than APNG required (or would require), since there is no timing involved.
Flash does support something akin to JNG with the DefineBitsJPEG3 tag. JPEG is used for RGB and something similar to PNG is used for the alpha channel. So, asking for use cases isn't really necessary. It's used by zillions of SWFs for one simple reason: It's a lot smaller than using something like PNG32.
Many games in the downloadable category emulate JNGs by splicing JPG and PNG (or gray-scale JPG) together. You can do the same thing with Canvas, by the way.
Since download sizes directly affects the revenue, indie game developers typically do all obvious and straightforward optimizations. For web games this is even more critical, because there will be even less income per download and the download time drastically affects the user experience. It doesn't really matter if it's a site or a game – long loading times will always hurt.
I also think it would create some new options for designers. As you can see in that decision matrix above, anything with many colors and translucency is something you really shouldn't do right now. PNG32 is just too heavy and it gets extremely heavy very quickly.
The most relevant items over at Bugzilla are probably these two:
So yea, it looks pretty bleak right now. But there isn't anything which replaced JNG. JPEG2000 or JPEG XR would work of course, but we need to wait another decade until the patents (and/or submarine patents) expired. We can't really use those two formats yet. No one wants to repeat that GIF fiasco. JNG is perfectly fine in that regard, by the way. It's just PNG and JPG after all.