4 ms·

Lossless and Transparency Encoding in WebP

38 points by valyala 15y ago

richbradshaw 15y ago
Finally! A lossy transparent format, supported by a browser that a large % of people use! Does anyone know a good way to provide webp with a fallback, short of sniffing the UA? I've tried using mod_negotiation (http://httpd.apache.org/docs/2.0/mod/mod_negotiation.html http://httpd.apache.org/docs/2.0/mod/mod_negotiation.html), but Chrome doesn't sent the webp mime type, so I can't get it to work... Anyone know of a solution?
- icebraining 15y ago
  Well, you could use Javascript: try to load a 1x1 WebP file using Image() and then choose the right URL for the images on the page depending on the result. Add normal <img> tags inside <noscript> with the PNG/JPG versions for graceful degradation. http://stackoverflow.com/questions/5573096/detecting-webp-support http://stackoverflow.com/questions/5573096/detecting-webp-su...
- comex 15y ago
  At a guess, file a bug against Chrome?
- maggit 15y ago
  This is what the Accept-header is for, but unfortunately browsers do not really give helpful values in this header. I've also heard from people working with web browsers that the Accept-header wouldn't work well for the real web anyway. Sigh. :(
pavpanchekha 15y ago
This is incredible! If the claimed benefits are true (and the WebX team seems to be pretty honest about their numbers) this is now a better format than PNG, JPEG, and GIF, all at once, as well as covering some other options (lossy + transparent) that could be interesting. WebP, with recent metadata and ICC support, and these new additions, is starting to look like a serious image format that we might have good reason. If Google can encourage Firefox to start supporting it, it might even see significant usage. Just think --- one image format covering all the use cases you care about, one optimization tool, one backend to thumbnail user images, you name it. Man, PNG was such a nice binary format, though. sniff
- gcp 15y ago
  1) Quoting source page: "The bit stream specification has not been finalized". This is something other implementers want to stay clear from for now, let alone it gets deployed in the wild and you have massive compatibility issues, or need to bloat all supporting software to support now-long outdated bitstreams (hi Vorbis!). 2) "If Google can encourage Firefox to start supporting it". Yeah, like they did with WebM, and then completely backstabbing Firefox by never actually removing H.264 support from Chrome, despite claiming to going to do it for many months. If the Firefox developers don't have total amnesia, I think they're going to need a lot of encouragement.
  - ZeroGravitas 15y ago
    point 2 is just a little overdramatic considering all the other support that Google offers for WebM e.g. buying it for $130 million in the first place, supporting it in Chrome and Android, converting the entire Youtube back catalog, producing reference hardware encoders and decoders and giving the designs away for free, etc. etc. Chrome and Firefox in desktop and Opera and Android in mobile have enough combined share to shift the market on this if they want to. I'd hope and assume that Mozilla's decision making would be a bit more related to their mission to support an open web than to petty recriminations for percieved slights.
    - gcp 15y ago
      Chrome and Firefox in desktop and Opera and Android in mobile have enough combined share to shift the market on this if they want to. Yes, meaning dropping support for H.264. Firefox did this, Chrome did not (I'm not sure what Opera does?). What's the conclusion? Google doesn't particularly care to shift the market in favor of their own format, or thinks it will burn its other fingers too much in doing so. Meanwhile, H.264 is used everywhere, including for Firefox users, who get to enjoy it over the now-deprecated Flash. Do you see a problem looming here for "supporting the open web"? I'd hope and assume that Mozilla's decision making would be a bit more related to their mission to support an open web than to petty recriminations for percieved slights. Does WebP advance an open web? Let's see, is there some actual standard describing it, or do you have to blindly lump in a big chunk of Google code to support it? (That's a real question)
rvavruch 15y ago
Chicken and egg. Designers will not use a format not supported by the majority of browsers and browsers see no need to implement new formats unless people are asking for them. It goes against the web design principle of making your site usable to all users regardless of what they are browsing with to use an image format that is not widely supported. This principle is backed by users who will simply leave your site in disgust if they are asked to jump through hoops to use it. Very few designers will be willing to maintain two versions of all their images just because one of the formats is a bit smaller. Microsoft has it's own range of newish web image formats that never caught on. History suggests IE is unlikely to support anything "not made here" unless it is forced to. The competition to Microsoft's image formats, JPEG2000, never caught on either. Firefox has an infamous open bug about adding it in dating back to 2000: https://bugzilla.mozilla.org/show_bug.cgi?id=36351 https://bugzilla.mozilla.org/show_bug.cgi?id=36351 - over 11 years! Despite what it looks like in the last comment, my Firefox 8 still does not have support. The last image format that managed to make it was PNG, and that was almost over a decade ago, although alpha support in PNG was added comparatively recently to IE. Last time I checked MNG (PNG's answer to animated GIFs) still wasn't widely supported. Sorry to be such a downer, lack of support for JPEG2000 was a let down for me. As I see it Firefox, Opera and Safari will all need to support this first, before web designers in general will even consider using it. Only once a significant number of web designers are clamouring for it will IE slowly add support for it. Only then will it see wide use. Tool support is vital too, most importantly Adobe PhotoShop. No web designer I know of is going to muck about in the commandline with imagemagick.
- gcp 15y ago
  Firefox has an infamous open bug about adding it in dating back to 2000: https://bugzilla.mozilla.org/show_bug.cgi?id=36351 https://bugzilla.mozilla.org/show_bug.cgi?id=36351 - over 11 years! Despite what it looks like in the last comment, my Firefox 8 still does not have support. The bug was WONTFIX-ed more than 2 year ago, so it will probably never support it. As I see it Firefox, Opera and Safari will all need to support this first, before web designers in general will even consider using it. ...and this was the reason for the WONTFIX: https://bugzilla.mozilla.org/show_bug.cgi?id=36351#c98 https://bugzilla.mozilla.org/show_bug.cgi?id=36351#c98 I sense some chicken and egg problems here. I'm guessing neither side though the improvements compared to complexity of adding support are worth it. I'm not sure WebP changes the equation.
sp332 15y ago
* flashes the DarkShikari signal * :) I wonder if just adding LZMA or PPMd compression to PNG (instead of deflate) would have the same size improvements, with the benefit of keeping PNG's very nice binary format.
pornel 15y ago
WebP's compression is good, but there's an often forgotten PNG8+alpha format that is a form of lossy compression as well. Although PNG8+a compression isn't as good as lossy WebP, it is availble now, and it is compatible with all browsers. Comparison: http://pngmini.com/vs-webp/ http://pngmini.com/vs-webp/ Source code: https://github.com/pornel/improved-pngquant https://github.com/pornel/improved-pngquant
morsch 15y ago
When reading about this I came up with the idea of rendering a JPEG on a canvas element with a PNG (or grayscale JPEG) as a transparency map. This would give you alpha-channel JPEG on most browsers right now. Sweet huh? ... and of course, it's been done: http://jim.studt.net/jpeg-alpha/ http://jim.studt.net/jpeg-alpha/ :) It's even been on Hacker News, though not to much attention: http://news.ycombinator.com/item?id=1772760 http://news.ycombinator.com/item?id=1772760

38 points by valyala 15y ago

Finally! A lossy transparent format, supported by a browser that a large % of people use! Does anyone know a good way to provide webp with a fallback, short of sniffing the UA? I've tried using mod_negotiation (http://httpd.apache.org/docs/2.0/mod/mod_negotiation.html http://httpd.apache.org/docs/2.0/mod/mod_negotiation.html), but Chrome doesn't sent the webp mime type, so I can't get it to work... Anyone know of a solution?

icebraining 15y ago
Well, you could use Javascript: try to load a 1x1 WebP file using Image() and then choose the right URL for the images on the page depending on the result. Add normal <img> tags inside <noscript> with the PNG/JPG versions for graceful degradation. http://stackoverflow.com/questions/5573096/detecting-webp-support http://stackoverflow.com/questions/5573096/detecting-webp-su...
comex 15y ago
At a guess, file a bug against Chrome?
maggit 15y ago
This is what the Accept-header is for, but unfortunately browsers do not really give helpful values in this header. I've also heard from people working with web browsers that the Accept-header wouldn't work well for the real web anyway. Sigh. :(

pavpanchekha 15y ago

This is incredible! If the claimed benefits are true (and the WebX team seems to be pretty honest about their numbers) this is now a better format than PNG, JPEG, and GIF, all at once, as well as covering some other options (lossy + transparent) that could be interesting. WebP, with recent metadata and ICC support, and these new additions, is starting to look like a serious image format that we might have good reason. If Google can encourage Firefox to start supporting it, it might even see significant usage. Just think --- one image format covering all the use cases you care about, one optimization tool, one backend to thumbnail user images, you name it. Man, PNG was such a nice binary format, though. sniff

gcp 15y ago
1) Quoting source page: "The bit stream specification has not been finalized". This is something other implementers want to stay clear from for now, let alone it gets deployed in the wild and you have massive compatibility issues, or need to bloat all supporting software to support now-long outdated bitstreams (hi Vorbis!). 2) "If Google can encourage Firefox to start supporting it". Yeah, like they did with WebM, and then completely backstabbing Firefox by never actually removing H.264 support from Chrome, despite claiming to going to do it for many months. If the Firefox developers don't have total amnesia, I think they're going to need a lot of encouragement.
- ZeroGravitas 15y ago
  point 2 is just a little overdramatic considering all the other support that Google offers for WebM e.g. buying it for $130 million in the first place, supporting it in Chrome and Android, converting the entire Youtube back catalog, producing reference hardware encoders and decoders and giving the designs away for free, etc. etc. Chrome and Firefox in desktop and Opera and Android in mobile have enough combined share to shift the market on this if they want to. I'd hope and assume that Mozilla's decision making would be a bit more related to their mission to support an open web than to petty recriminations for percieved slights.
  - gcp 15y ago
    Chrome and Firefox in desktop and Opera and Android in mobile have enough combined share to shift the market on this if they want to. Yes, meaning dropping support for H.264. Firefox did this, Chrome did not (I'm not sure what Opera does?). What's the conclusion? Google doesn't particularly care to shift the market in favor of their own format, or thinks it will burn its other fingers too much in doing so. Meanwhile, H.264 is used everywhere, including for Firefox users, who get to enjoy it over the now-deprecated Flash. Do you see a problem looming here for "supporting the open web"? I'd hope and assume that Mozilla's decision making would be a bit more related to their mission to support an open web than to petty recriminations for percieved slights. Does WebP advance an open web? Let's see, is there some actual standard describing it, or do you have to blindly lump in a big chunk of Google code to support it? (That's a real question)

rvavruch 15y ago

Chicken and egg. Designers will not use a format not supported by the majority of browsers and browsers see no need to implement new formats unless people are asking for them. It goes against the web design principle of making your site usable to all users regardless of what they are browsing with to use an image format that is not widely supported. This principle is backed by users who will simply leave your site in disgust if they are asked to jump through hoops to use it. Very few designers will be willing to maintain two versions of all their images just because one of the formats is a bit smaller. Microsoft has it's own range of newish web image formats that never caught on. History suggests IE is unlikely to support anything "not made here" unless it is forced to. The competition to Microsoft's image formats, JPEG2000, never caught on either. Firefox has an infamous open bug about adding it in dating back to 2000: https://bugzilla.mozilla.org/show_bug.cgi?id=36351 https://bugzilla.mozilla.org/show_bug.cgi?id=36351 - over 11 years! Despite what it looks like in the last comment, my Firefox 8 still does not have support. The last image format that managed to make it was PNG, and that was almost over a decade ago, although alpha support in PNG was added comparatively recently to IE. Last time I checked MNG (PNG's answer to animated GIFs) still wasn't widely supported. Sorry to be such a downer, lack of support for JPEG2000 was a let down for me. As I see it Firefox, Opera and Safari will all need to support this first, before web designers in general will even consider using it. Only once a significant number of web designers are clamouring for it will IE slowly add support for it. Only then will it see wide use. Tool support is vital too, most importantly Adobe PhotoShop. No web designer I know of is going to muck about in the commandline with imagemagick.

gcp 15y ago
Firefox has an infamous open bug about adding it in dating back to 2000: https://bugzilla.mozilla.org/show_bug.cgi?id=36351 https://bugzilla.mozilla.org/show_bug.cgi?id=36351 - over 11 years! Despite what it looks like in the last comment, my Firefox 8 still does not have support. The bug was WONTFIX-ed more than 2 year ago, so it will probably never support it. As I see it Firefox, Opera and Safari will all need to support this first, before web designers in general will even consider using it. ...and this was the reason for the WONTFIX: https://bugzilla.mozilla.org/show_bug.cgi?id=36351#c98 https://bugzilla.mozilla.org/show_bug.cgi?id=36351#c98 I sense some chicken and egg problems here. I'm guessing neither side though the improvements compared to complexity of adding support are worth it. I'm not sure WebP changes the equation.

sp332 15y ago

* flashes the DarkShikari signal * :) I wonder if just adding LZMA or PPMd compression to PNG (instead of deflate) would have the same size improvements, with the benefit of keeping PNG's very nice binary format.

pornel 15y ago

WebP's compression is good, but there's an often forgotten PNG8+alpha format that is a form of lossy compression as well. Although PNG8+a compression isn't as good as lossy WebP, it is availble now, and it is compatible with all browsers. Comparison: http://pngmini.com/vs-webp/ http://pngmini.com/vs-webp/ Source code: https://github.com/pornel/improved-pngquant https://github.com/pornel/improved-pngquant

morsch 15y ago

When reading about this I came up with the idea of rendering a JPEG on a canvas element with a PNG (or grayscale JPEG) as a transparency map. This would give you alpha-channel JPEG on most browsers right now. Sweet huh? ... and of course, it's been done: http://jim.studt.net/jpeg-alpha/ http://jim.studt.net/jpeg-alpha/ :) It's even been on Hacker News, though not to much attention: http://news.ycombinator.com/item?id=1772760 http://news.ycombinator.com/item?id=1772760