3 ms·

Want WebP today? Implement it in JavaScript

32 points by devongovett 16y ago

user24 16y ago
damn, I was going to do this! Hah, it's a good idea. Actually I was going to have something like this: <img src="foo.webp" onerror="makecompat();"> where makecompat gets the webp data and implements the webp algorithm to draw the image onto a canvas which replaces the image element. That way any browser that supports canvas would be able to support webp, and it would 'fail forward'. But still, this is a cool script, and I'll certainly use it if I want webp images.
- seanalltogether 16y ago
  Your idea would be far more valuable then the one presented here. This script only adds support for WebP images within browsers that already support WebM, which seems like a trivial task for those specific browser vendors to support anyway.
  - user24 16y ago
    Yeah, when I read the headline I thought it was my idea, was disappointed to read that it wasn't quite as good as I'd envisaged. I have no immediate plans to implement this idea though, as I don't think I really have time. But if people keep talking to me about it then I'll probably be convinced to think about it some more. At the moment what you see in my post is as far as it goes. I don't know how much more would be required to get a proof of concept going. I suspect it'll be pretty heavy work. edit: thanks for the encouragement by the way. I thought it was a cool idea too.
  - antimatter15 16y ago
    I tried porting VP8, but the spec is huge (the allegedly incomplete bitstream specification is 104 pages), and performance-wise, it couldn't compare to a native webm/vp8 implementation. I guess i'll give it another shot. I'm not exactly sure how much of vp8 is part of the interframe prediction, because WebP only contains a single intraframe, it might be practical to implement a small subset.
    - user24 16y ago
      how about a serverside implementation? Try loading native webp, if that fails, send the webp data to a webp-to-png service and render in png on the client. Performance would probably be fine, and imagemagick or something similar will probably support webp soon so the server won't require us to write a whole webp implementation.
      - antimatter15 16y ago
        That negates the purpose of a bandwidth-efficient lossy image format.
        user24 16y ago
        even my original idea would require a double-hit to the server, because I don't think you can extract data loaded into an image element through JS, so you'd have to read the src attribute and re-request it via XHR as raw data, and then parse that into a replacement canvas element. The main benefit is being able to default to webp, and save all your resources in that format alone, and provide a fallback for browsers which don't support it, instead of having to provide 2 sets of images and serve different ones depending on the browser.
    - seanalltogether 16y ago
      Oh believe me I'm not knocking you for having NOT done it, as I can't imagine how much work it would take to write a valid WebP parser in javascript.
- thwarted 16y ago
  If only the lowsrc attribute hadn't been deprecated, it would have use in a number of cases, similar to this. With the fallback, it's kind of like content negotiation, which no one really uses, but closer to the presentation layer.
deleted 16y ago
[deleted]

32 points by devongovett 16y ago

damn, I was going to do this! Hah, it's a good idea. Actually I was going to have something like this: <img src="foo.webp" onerror="makecompat();"> where makecompat gets the webp data and implements the webp algorithm to draw the image onto a canvas which replaces the image element. That way any browser that supports canvas would be able to support webp, and it would 'fail forward'. But still, this is a cool script, and I'll certainly use it if I want webp images.

seanalltogether 16y ago
Your idea would be far more valuable then the one presented here. This script only adds support for WebP images within browsers that already support WebM, which seems like a trivial task for those specific browser vendors to support anyway.
- user24 16y ago
  Yeah, when I read the headline I thought it was my idea, was disappointed to read that it wasn't quite as good as I'd envisaged. I have no immediate plans to implement this idea though, as I don't think I really have time. But if people keep talking to me about it then I'll probably be convinced to think about it some more. At the moment what you see in my post is as far as it goes. I don't know how much more would be required to get a proof of concept going. I suspect it'll be pretty heavy work. edit: thanks for the encouragement by the way. I thought it was a cool idea too.
- antimatter15 16y ago
  I tried porting VP8, but the spec is huge (the allegedly incomplete bitstream specification is 104 pages), and performance-wise, it couldn't compare to a native webm/vp8 implementation. I guess i'll give it another shot. I'm not exactly sure how much of vp8 is part of the interframe prediction, because WebP only contains a single intraframe, it might be practical to implement a small subset.
  - user24 16y ago
    how about a serverside implementation? Try loading native webp, if that fails, send the webp data to a webp-to-png service and render in png on the client. Performance would probably be fine, and imagemagick or something similar will probably support webp soon so the server won't require us to write a whole webp implementation.
    - antimatter15 16y ago
      That negates the purpose of a bandwidth-efficient lossy image format.
      - user24 16y ago
        even my original idea would require a double-hit to the server, because I don't think you can extract data loaded into an image element through JS, so you'd have to read the src attribute and re-request it via XHR as raw data, and then parse that into a replacement canvas element. The main benefit is being able to default to webp, and save all your resources in that format alone, and provide a fallback for browsers which don't support it, instead of having to provide 2 sets of images and serve different ones depending on the browser.
  - seanalltogether 16y ago
    Oh believe me I'm not knocking you for having NOT done it, as I can't imagine how much work it would take to write a valid WebP parser in javascript.
thwarted 16y ago
If only the lowsrc attribute hadn't been deprecated, it would have use in a number of cases, similar to this. With the fallback, it's kind of like content negotiation, which no one really uses, but closer to the presentation layer.

deleted 16y ago

[deleted]