Latest WEBP codec supported in RealWorld Paint

Published by Vlasta on April 5th 2013.

Google's WEBP reached 0.3.0 - Mozilla still unconvinced. Although I am a WEBP fan, I perfectly understand Mozilla's position. The Google's image format is still new and rough. Neither the specification nor the libwebp are ready to be widely used. I just spent a couple of days integrating the latest version of libwebp into my freeware image editor and here is a summary of my experiences.

Try it yourself

If you want to play with the latest webp, grab the portable version or the installer of RealWorld Paint (updated April 5th). The latest WEBP codec will read and write animated or fragmented webp images, it should preserve EXIF and XMP data and if there is a color profile in the read image, it should be applied and the image should be converted to sRGB.

Why I am using 'should' instead of 'will' so much? Because there is no reference data to test with. Testing with just my own data is no real testing. It is likely that there are errors and be careful when saving to webp in RWPaint.

Problems of WEBP

In my opinion, WEBP must address the following 3 problems, before it will be ready for general use on the web.

1. No sensible way to optimize semitransparent animations - WEBP specification does not allow effective optimization of semitransparent animations by only updating a rectangle that differs from the previous frame. A workaround is possible, but it involves erasing affected region using an artificial frame with 0 duration. GIF has similar option, but since some (all) browsers do not correctly handle frames with 0 duration and instead of merging them, they display them for a brief period of time, I will not consider this a viable optimization strategy for now.
2. Mixing lossy and lossless - you may think that a format that supports both lossy and lossless compressing is a good thing. It may be, for geeks (remember JPEG 2000?). For normal people, this is a source of confusion. They know to use JPG for photos, PNG for semitransparent drawings, GIF for animations. If they are told to use WEBP for all of them, they would, but don't expect them to decide correctly when to use the lossy and lossless compression. If someone converts a JPG to a lossless WEBP and publishes it, they have just made the web a bit worse. It may eventually be my responsibility as an image editor author to come with an algorithm that decides for users what compression would be best to use. If the libwebp contained this algorithm, it would help all users of the library and limit the number of dissatisfied end users. Can libwebp afford to ignore this problem?
3. Brings no significant advantage - yes, it is true, that WEBP images are usually slightly smaller than PNGs or JPGs of the same quality. But we live in an age, where internet speed is no real issue and becoming less and less important. WEBP brings one thing that is new - lossy semitransparent image compression. Though, I have seen cases, where the same semitransparent image using the lossy compression was twice the size compared to a lossless copy. The support for semitransparent animations is not a new thing either as APNG has been around for a couple of years (though Chrome refuses to implemenent it) and it has superior optimization options and backward compatibility with PNG.

I hope the WEBP team will not take this blog post as attack on them. I am a fan of webp and it may become the best image format for web use one day. If all the mentioned issues are addressed appropriately, I'll be very happy.

Possible solutions

#1 is easy - just fix the specification.

#2 is harder - consider using a different extension for the lossless version. Or at least add a function to libwebp that would analyze the compressed image and recommend compression methods.

Not sure what you can do about #3? Here is an idea for you. Most of webs are slow, because they need to load a lot of small images, not one large image. Extend WEBP and let it contain multiple images in one file. Extend the html spec and let individual images be accessed for example like this:

<img src="icons.webpx#home" /> <img src="icons.webpx#about" />

A bit about the WEBP - APNG war

Firefox has APNG and Chrome has WEBP. While the Chrome team refuses to support APNG, the Firefox team refuses to support WEBP.

The conflict is invisible, but pretty intense. There are numerous topics on both teams' support and development forums, where agitated users (usually web developers) are begging (or threatening) the teams to support either WEBP or APNG. These topics usually get closed or merged or are ignored by the teams.

Here is a nice topic about APNG from 2009. Nobody from the Chrome team responded. And there are many more topics with similar fate - just search for APNG. Fans of APNG went as far as creating an extension for Chrome that adds APNG support to it.

And here is a topic about WEBP on Firefox bug tracker. The discussion is quite heated.

To tell the truth, I believe Mozilla is the more responsible of the two. Adding a new image format to a web browser is a major decision that affects tens of millions of computers. A bad decision is extremely hard to undo. There were breaking changes in the WEBP format in the past and some early users have problems recovering pictures saved with earlier versions of libwebp. I expect there will be changes in the future (fragments are not part of the current spec and animations could use some work to be competitive with GIF and APNG). WEBP needs better support in more image editors. It must be easy to create WEBP images from PHP (and other web languages) on standard server setups. When these conditions are met, it would make sense to support WEBP in all web browsers. At this point, its support in Chrome is a political move, not a rational and a responsible one.

Recent comments

Stephen Konig registered user on April 5th 2013

Thanks for your feedback! With respect to #2 -- I actually don't think most users understand the difference between lossy, lossless, etc., or when to use PNG, JPEG, etc. What we see more often is that people are confused by these different formats and don't understand when you should use one or the other. Having one format is better in this regard.

But where I would agree with you is that we need better tools to automate the process of choosing the right settings. Services like PageSpeed do this, and we need more tools like it. Aside from a small number of very technical folks who understand image formats, most users would be better served by having the computer make these decisions for them.

As for Firefox, they have recently decided to re-look at WebP support: https://bugzilla.mozilla.org/show_bug.cgi?id=856375

Thanks!
Stephen

Vlasta site administrator on April 5th 2013

I am glad you support the idea of automated selection of compression setting - that would fix #2.

I also agree that there are people, who are confused by JPG and PNG, but I believe the number of people, who DO understand them is much greater than the number of people, who know how to choose between lossy and lossless. They had years to learn it.

Max Stepin registered user on April 6th 2013

Nice, you added 0.3.0 support before Chromium!

I'm also concerned about #2, the formats that tried to do too much (like TIFF or MNG) don't have a good track record. It's better to focus on just one thing, but do it really well. And I like when lossy and lossless are in separate formats, if I'm saving something in PNG, there is no worry about forgotten "lossy" checkbox somewhere in settings.

But at this point it's too late to remove anything from WebP. They could still add more features, though.

And it does seems like Mozilla is more open-minded. At least they're responding and willing to discuss the WebP on technical terms. Chromium bug for APNG is simply closed for comments.

Recently I wrote the code for native APNG support in Chromium:
https://groups.google.com/a/chromium.org/d/msg/chromium-dev/2xvXNJMsgxc/2CJ9jl-jItcJ
TL;DR: long discussion with plenty of FUD, nobody raised any technical issues over my code or the format itself, rejected anyway.

Vlasta site administrator on April 6th 2013

APNG is a neat little thing, I have been using it on this web in the gallery section for years. It was surprisingly easy to generate APNGs from PHP on a standard LAMP setup. Chrome and IE users get GIFs with jagged edges .

Why Chrome refused to support APNG is beyond me - for years, it has been (and ATM still is) the only format that supported smooth transparency. Politics... Google has the power and wields is as they see fit. I am sorry to hear that the time you invested into the APNG patch will probably be wasted.

Since APNG does not seem to be happening, the only thing I wish now, is that WEBP animation and other features are as good as possible as soon as possible.

Mikey Z registered user on April 8th 2013

I really think that this one's cool, but I wonder if its a good thing to make more types of images if there are others that work as well. :/ Each has its own advantages, but the ones that are just another version of something else I just wonder what the point is. I see the useful differences between GIFs, JPEG, PNG, and Vector images, but what's special about the two new ones?

Anonymous on August 22nd 2013

its not hard for the users to learn how to use the sliders to select the right preset of compression. that is nothing tehnical and nothing hard to learn. i think making the program to automate selection is pushing it.

the things today are more and more made for some wide mayority of users that expect a situation that only require them to press next> next> next>. but i think this automation does more harm then use. after all, a computer cannot actually make decisions for you, if it did, user would be obsolete : ) in all that automation, power is lost.

i don't think its hard for any user out there to understand when he/she should choose this preset, or that preset, even a tooltip help could be provided to educate them what is the setting good for. its no different then a game that tutorials you through the gameplay in first few missions and actually teaches you how to play it. i don't beleive this would be any more complicated.

and below the presets for example, you could have more advanced preset options, possibly even as a collapse/show item, to let the more advanced users customize all the power they need. and if someone wants to learn about them, explain them in tooltips (or some other way of help developed through future)

things are to be as simple as possible, but not any more simple then that, as someone said.. and today, it seams the web and everything adapts to the ignorence of users instead of educating them about it. it is like a skill that instead you are to learn, it learns from your ignorence and becomes.. as simple as our lack of knowledge. computers aren't toys and while i realise things are not supposed to be somewhat complicated as a linux terminal or winapi for the average user they are not supposed to be too simple either. its exactly like lossy compression.. you push the sliders too far to the left, the details are lost, too simple, you push the sliders too far to the right, the filesize is unecesserely huge, too complicated. i beleive a balance should be found and where standards are heading to, i'd say we are a bit compressing it too hard on some places and pushing the quality way high on the other but its rare to see some balance where all details are preserved but are presented in a simple way.

slightly off topic: i like the user interface of rwpaint though, i switched to it from gimp because it has it all in a single window and simple but still as powerful, and i could probably even say better then gimp, but that is my opinion of course : )

Anonymous

Signed comments carry more weight! Don't be a stranger - log-in or register. It only takes few seconds.