Breaking Eggs And Making Omelettes

Topics On Multimedia Technology and Reverse Engineering


On WebP and Academic Exercises

October 1st, 2010 by Multimedia Mike

Yesterday, Google released a new still image format called WebP. To those skilled in the art, this new format will be recognizable as a single VP8 golden frame with a 20-byte header slapped on the front (and maybe a little metadata thrown in for good measure). We have a MultimediaWiki page and a sample ready to go.

Further, I submitted a patch to ffmpeg-devel for FFmpeg’s img2 handling system to decode these files. FFmpeg should support processing these files soon… if anyone cares. This leads into…

The Point, or Lack Thereof
Since yesterday’s release, I have read a whirlwind of commentary about this format, much of it critical and of the “what’s the point?” variety. For my part, I can respect academic exercises, a.k.a., just trying random stuff to see if you can make it work. That’s pretty much this blog’s entire raison d’être. But WebP transcends mere academic exercise; Google seems to be trying to push it as a new web standard. I don’t see how the format can go anywhere based on criticisms raised elsewhere — e.g., see Dark Shikari’s thoughtful write-up — which basically boil down to WebP not solving any real problems, technical, legal, or otherwise.

How did WebP come to be? I strongly suspect some engineers noticed that JPEG is roughly the same as an MPEG-1 intraframe, so why not create a new still frame format based on VP8 intraframes? Again, I can respect that thinking– I have pondered how a still image format would perform if based on VP3/Theora or Sorenson Video 1.

Google claims a significant size savings for WebP vs. standard JPEG. Assuming that’s true (and there will be no shortage of blog posts to the contrary), it will still be some time before WebP support will find its way into the majority of the web browser population.

But this got me thinking about possible interim solutions. A website could store images compressed in both formats if it so chose. Then it could serve up a WebM image if the browser could support it, as indicated by the ‘Accept’ header in the HTTP request. It seems that a website might have to reference a generic image name such as <img src="some-picture.image">; the web server would have to recognize the .image extension and map it to either a .jpg or a .webp image depending on what the browser claims it is capable of displaying.

I appreciate that Dark Shikari has once again stuck his neck out and made a valiant — though often futile — effort to educate the internet’s masses. I long ago resigned myself to the fact that many people aren’t going to understand many of the most basic issues surrounding multimedia technology (i.e., moving pictures synchronized with audio). But apparently, this extends to still image formats as well. It was simultaneously humorous and disheartening to see commenters who don’t even understand the application of, e.g., PNG vs. JPEG: Ahem, “We already have a great replacement for jpg: .PNG”. Coupled with the typical accusations of MPEG tribalism, I remain impressed D. Shikari finds the will to bother.

Still, I appreciate that the discussion has introduced me to some new image formats of which I was previously unaware, such as PGF and JPEG XR.

Posted in General | 4 Comments »

4 Responses

  1. Drazick Says:

    I think WebP is useless.
    I would appreciate if Google support JPEG XR.

  2. Owen S Says:

    I agree with the “Just use JPEG XR” sentiment. It has more features, reportedly achieves better compression… And has conquered perhaps the biggest hurdle: IE9 already supports it.

    Someone just needs to write a GPL compatible decoder (MS have released an open source decoder; just annoyingly one under a license which seems to be intentionally GPL incompatible… and just GPL incompatible.)

    (And yes I know JPEG XR is patented… But MS have released the related patents under their open specification promise, so its clear to implement)

  3. Diego E. “Flameeyes” Pettenò Says:

    Mike, take what Owen said and add cleanroom support for it in FFmpeg, and we’ll be set :D

    No seriously, I totally agree regarding the “what’s the point” situation, Google has been really throwing tons and tons of stuff around lately and looking at what sticks; sometimes people seem to try making things stick just because they come from Google (think Wave).

    OTOH, what you said above about Apache is already very well feasible, and has been done for a very long time, it’s called mod_negotiation:

    It just need to be properly configured.

  4. Multimedia Mike Says:

    @Flameeyes: Thanks, I had a feeling that should already be possible (mod_negotiation).