The Web Needs a Lossy 32bit Image Format – Bring JNG Back

eye catcher
It's photo-based with alpha, JNG would be a good choice [cc-by]

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.

You can quantize and dither PNG32 images with pngquant and pngnq. PNGOUT will also create this kind of PNG, but only if there are less than 257 colors to begin with.

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.

JNG to the Rescue!

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!

As it turns out Mozilla actually went with that, but they dropped support for JNG when they dropped support for MNG.

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.

Bring it Back

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:

figure 1
Figure 1: Current Decision Matrix (of pain)

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 Did It (and downloadable games, too)

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 Current State

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.

Comments

WebP developers promised to

WebP developers promised to implement alpha channel.

Google is big enough to convince other browser makers to support WebP, so the future is not as bleak as you think.

re: WebP developers promised to

Ye, I know that they are going to support alpha eventually, but as far as I can tell they haven't added it yet. Right now, the format is pretty pointless since it's just a different kind of JPG.

I don't see any big issue

I don't see any big issue with Jpeg-XR. Microsoft have made a legal promise not to sue anyone who implements the format: http://www.microsoft.com/interop/cp/default.mspx.

re: I don't see any big issue

Unfortunately, that doesn't mean anything. As I mentioned earlier, the patent situation is completely unclear (until all of them expired). Microsoft's license is also incompatible with the GPL, LGPL, and other copy left licenses. This means you'd have to implement it yourself - from scratch.

It really doesn't look very tempting.

JNG on the other hand is very straightforward. There are no patents and 99.99% of the required code is already there. In every browser, that is.

Why not SVG?

I know it’s a hack. But you can do all that with SVG (which also works without JS, in contrast to Canvas). And SVG support will be in all browser much sooner than any new bitmap format. Just take your JPG, a Mask (PNG or JPG), and a tiny SVG glue file. I tried it, and the SVG glue takes about 345B with gzip compression.

Here’s the new "JPEG with alpha mask" image format:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" width="96" height="96">
    <defs>
        <mask id="mask">
            <image xlink:href="gotchi_mask.png" height="96" width="96"/>
        </mask>
    </defs>
    <image xlink:href="gotchi_base.jpg" mask="url(#mask)" height="96" width="96"/>
</svg>

re: Why not SVG?

Yes, SVG would work (and I'm aware of that option). It requires 3 connections though.

Well, you could b64 encode the images and inline them (and gzip the result). Or use one JPEG for both and inline the SVG.

But I'd like to see something more straightforward. Something which can be used by everyone.

Post new comment

  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

More information about formatting options