Image format for the web, a real world example

Well, we all know about JPEG image format. It’s good, but not perfect. Yet, there is not much competitor to replace it. Why ?

Let’s see.

Advantages of JPEG

  1. It’s old, so all software know how to deal with it.
  2. The picture quality vs file size is good
  3. It’s what comes out of your digital still camera, so, like me, we don’t have time to rework the picture
  4. It can store metadata

Bad features of JPEG

  1. It’s lossy. Very lossy (and yes, I know there is a lossless profile in JPEG standard, but nobody use it)
  2. No alpha channel, no transparency possible
  3. No animation

My use case

Let’s analyze a typical use case. I take pictures of my dog. I want my Grandma to see them.

So, I copy the files to my home NAS, and give the URL to Grandma.

Then Grandma calls me, because the files are takes forever to display.

Why ? Because my camera takes really huge pictures: 1) I’m lazy or 2) I want to keep my pictures with the highest quality possible, and no, I’m not using a RAW format because I don’t have time for post processing.

No problem, let’s rescale the pictures so they can be uploaded / downloaded without having to wait for Hell to freeze.

A little bit of math gives this:

  1. My uplink is around 1Mbps (xDSL link)
  2. The highest resolution Grandma could see is 1080p (on her FullHD screen)
  3. Let’s then scale and recompress to 1920×1080 all my picture collection so grandma could see it.
  4. I want to limit the time of receiving to only 3s per picture (else, it’s very painful, and Grandma will stop in the middle of the folder)
  5. So, a picture should be, at worst ~300kB
  6. Ok, let’s try to make 1080p picture with JPEG at 300kB size per picture.
  7. Check them, just in case… Oh! It’s a disaster.


Well, as it does not work with JPEG, some other format should do it, right ?

On one hand, we have WebP (promoted by Google). It’s free, it’s powerful, and does not have any of the defect of JPEG. But… it’s not supported by Microsoft Internet Explorer, nor Apple Safari, nor Mozilla Firefox natively.

Microsoft promotes its own standard, JPEG XR (which is bad in all cases).

Mozilla promotes using JPEG but with a “better” encoder – it’s a scam, you’ll see below.

Apple does not promote any new format, I guess they are fine with 4MB JPEG pictures.

On the other hand, we have HEVC standard (H265) which, when hacked by Fabrice Bellard, creates a new contender for still image compression.

So I’ve tested all of them.

Here are the results for similar file size (less than 0.3% file size difference between them):

This is the BPG file format based on HEVC (H265) intra image coding

This is the BPG file format based on HEVC (H265) intra image coding

This is the output of MozJPEG "optimized" encoder. Notice how leaky the color are

This is the output of MozJPEG “optimized” encoder. Notice how leaky the color are

This is the current encoding using WebP default compression

This is the current encoding using WebP default compression

The result of this test is to disprove the “nice” curves on Mozilla image comparison test you can find on the internet. Currently “optimized JPEG” is as bad as JPEG output. Notice how I’m not going to the very low file size, you don’t see the blocks.

Ok, so when comparing WebP and BPG (HEVC), we can see that contours are better preserved in BPG (look at the hand of the baby), but the color leaks (look at the grey right shoulder’s border with the tree in the back).

IMHO, it’s clear that WebP and BPG are a step above JPEG (I’ve made many other tests, they all confirm these conclusions). WebP tends to be a little bit more blurry than BPG, but without a trained eye, it’s hard to spot.

Ok, then it’s clear that we should use WebP or BPG, so let’s try to use any of them.

WebP is supported natively in Chrome. This means that any code that use the native Image will support WebP.

In the other browsers, you have to resort using webpjs code. It’s quite fast to decode (user will not notice it : < 200ms). However, it uses the Canvas to render the decoded picture, so if you are using any other Javascript code that requires a picture loaded with “new Image” (like any preloader, WebGL texture) you’re out of luck. Also, webpjs is provided without source code (it’s ‘packer’ code) and with zero documentation so you can’t call a decoding function yourself to hook in your preloading code.

For BPG, there is a emscripten built of FFMPEG tailored only for HEVC decoding provided by Fabrice Bellard. Unfortunately, Emscripten work is nice, but it’s large to fetch, slow to run (typical decoding time of > 1s). Encoding also take ages (althrough there is probably room for improvment here, HEVC is still young). Since it’s canvas based too, it suffers from the above problem, but on all browsers. Also, and probably the worst issue, BPG rely on HEVC which require licensing (since you are distributing a “player”).

From the (few) visual improvement, I don’t see the point of BPG compared to WebP. Maybe this is going to change in the future, but for now, WebP is still the best contender.

Right now, I think Mozilla obstination not to include WebP natively is like schizophrenia.

They already are distributing a WebP decoder, because they support WebM/VP8 video decoder and a (basic) WebP picture is just a VP8 picture. Yet, they “object” that WebP is too bad to worth maintaining it. Then why do they support WebM then ?

In their other head, they claim that (their) JPEG is better than WebP (which is clearly not the case, WTF Mozilla? Do you look at output pictures, or you just watch the output graph from whatever tool you are using ?), occulting all the other features of WebP provides (like transparency, animation support, interlaced). Even if they reach proprietary’s JPEG optimizer results like this company, they’ll still fail because JPEG standard does not provide enough to squeeze bit out of the files (not even speaking of all the patents infringed in the process).

If Mozilla embraced WebP, then the other browsers would follow because Chrome + Firefox is more than half the browser market.

Right now, we are struck with a “black box” javascript code that does not fit very well because they are narrow minded.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s