Page 1 of 3 123 LastLast
Results 1 to 10 of 24

Thread: Google Continues Pushing Its WebP Image Format

  1. #1
    Join Date
    Jan 2007
    Posts
    14,373

    Default Google Continues Pushing Its WebP Image Format

    Phoronix: Google Continues Pushing Its WebP Image Format

    For web developers and server administrators, Google's Chromium blog has out an update on the adoption of the WebP image format within the Internet giant...

    http://www.phoronix.com/vr.php?view=MTYzOTc

  2. #2
    Join Date
    Jan 2010
    Posts
    358

    Default

    I sure hope it won't get any widescale adoption. The only actual advantage of WebP is the alpha channel. On the other hand, WebP is a lot more computationally intensive to decode and doesn't support 4:2:2 or 4:4:4 chroma subsampling. In addition, good optimizing JPEG encoders are already getting pretty close to WebP's compression efficiency. Furthermore, JPEG already includes some of the advertised advantages of WebP in the standard as optional features, such as a lossless mode and arithmetic coding.

    Also, a major issue with WebP is that the spec still isn't final and it isn't properly standardized, nor are there any efforts going on to get it standardized, as far as I can see. Typical Google pseudo-standard BS.

  3. #3
    Join Date
    Oct 2013
    Posts
    13

    Default

    Quote Originally Posted by brent View Post
    In addition, good optimizing JPEG encoders are already getting pretty close to WebP's compression efficiency.
    If what you say is true, then where does the 10% reduction in page load time come from?

  4. #4
    Join Date
    Oct 2009
    Posts
    343

    Default

    give me jpeg with transparency, and i will use it again

  5. #5
    Join Date
    Jan 2010
    Posts
    358

    Default

    Quote Originally Posted by johään View Post
    If what you say is true, then where does the 10% reduction in page load time come from?
    Simple: most JPEG encoders are pretty bad, because they've hardly seen any improvements in the last 10-15 years; on the other hand media compression research hasn't stood still, and we can easily spend some extra CPU cycles nowadays to improve the result. There are various commercial and open source tools that implement more efficient JPEG encoding, but so far few people use them. You can be pretty sure that WebP proponents won't use them for their comparisons.

    Lately Mozilla has been pushing for integration of these encoding tools into the widely used libjpeg, with their mozjpeg project. At the moment, it can losslessly reduce JPEG file size by 10% on average, but that's just the beginning.

  6. #6
    Join Date
    Oct 2012
    Posts
    148

    Default

    Quote Originally Posted by johään View Post
    If what you say is true, then where does the 10% reduction in page load time come from?
    do you think markedroids would compare their newest whizbang widget to the best on the market or just the regular stuff?

    also, who the hell cares about static images, isn't like 60% of internet network traffic video from Netflix and Youtube?

  7. #7
    Join Date
    Oct 2013
    Posts
    13

    Default

    Thanks for the explanation and link to mozjpeg, brent.

  8. #8
    Join Date
    Mar 2013
    Location
    Bulgaria for now
    Posts
    138

    Default

    Quote Originally Posted by brent View Post
    I sure hope it won't get any widescale adoption. The only actual advantage of WebP is the alpha channel. On the other hand, WebP is a lot more computationally intensive to decode and doesn't support 4:2:2 or 4:4:4 chroma subsampling. In addition, good optimizing JPEG encoders are already getting pretty close to WebP's compression efficiency. Furthermore, JPEG already includes some of the advertised advantages of WebP in the standard as optional features, such as a lossless mode and arithmetic coding.

    Also, a major issue with WebP is that the spec still isn't final and it isn't properly standardized, nor are there any efforts going on to get it standardized, as far as I can see. Typical Google pseudo-standard BS.
    I hope you recognise that even if WebP isn't as effective as JPEG (it is), that having alpha transparency alone would make it worthwhile.

    A few years ago I was involved in creating doctorwho.tv for BBCWW. This website currently has huge banner images that use alpha transparency, and I know for a fact that they'd like to have more elaborate images still. The problem with this is that these images are absolutely huge to download: one of the banners is 850KB alone, using WebP this same image would be served at roughly 150KB. You just can't do that with JPEG.

    Now it's true that you can get pretty decent compression with PNG these days using some fairly neat tools. But the problem with these tools is that they either require a human to check the results, or they require integration into existing software (in the case of BBCWW, into PHP extensions). Either the BBCWW ditches automatic image processing in favour of having humans curate all images at a huge cost, or they adopt WebP or another similar format.

    As for Google standardising WebP, do these not count as standards? Sure they've not been ratified by say the IETF, but that hasn't stopped a large number of applications from adding support. The only people holding up adoption at this point are Mozilla, and of course everyone's favourite, Microsoft.

  9. #9
    Join Date
    Jan 2010
    Posts
    358

    Default

    Quote Originally Posted by psychoticmeow View Post
    I hope you recognise that even if WebP isn't as effective as JPEG (it is), that having alpha transparency alone would make it worthwhile.
    It is as efficient as JPEG and might be a tad better, but it's not much better than JPEG, as Google wants you to believe. Alpha channel is a pretty interesting feature, I agree. It isn't what WebP is primarily marketed for, though.

    As for Google standardising WebP, do these not count as standards? Sure they've not been ratified by say the IETF,
    When I said standardization, of course I meant a regular standards track. For a format that wants to become a standard image exchange format, this is kind of a big deal. Standards bodies are vital for quality control and to decouple standards from the power of a single company. WebP is a pretty good example for why standards bodies are important: the spec is low quality, too brief and has been in constant flux since 2010, breaking backwards compatibility multiple times! VP8, which WebP is based on, has also been criticized for bad spec quality; much of the spec is verbatim C code taken from the reference implementation libvpx.

    but that hasn't stopped a large number of applications from adding support. The only people holding up adoption at this point are Mozilla, and of course everyone's favourite, Microsoft.
    Don't forget about Apple. Regarding the web, it's only Google that strongly supports WebP. No surprise.

  10. #10
    Join Date
    Mar 2013
    Location
    Bulgaria for now
    Posts
    138

    Default

    Quote Originally Posted by brent View Post
    It is as efficient as JPEG and might be a tad better, but it's not much better than JPEG, as Google wants you to believe. Alpha channel is a pretty interesting feature, I agree. It isn't what WebP is primarily marketed for, though.
    Yeah, you're wrong about WebP being equal, it was evaluated internally for BBCWW and found to be inline with Googles claims, the development done by Mozilla to improve it is largely irrelevant because it won't be available to their automated image processing system any time soon.

    Something else we found: these days you want to serve images to retina capable devices, to do this you want the image to be 2x the size it would be on a normal screen. Sounds like a pain right? You've got 4x the number of pixels to compress. Fortunately it's no problem at all, instead of serving a WebP at 80% quality, you can chop it down to 20-25% and because of the nature of retina displays you get an excellent looking image at an even smaller size.

    It even works for normal screens, because instead of displaying the image at 100% of its width you display it at 50% and let the browser scale it. The end result is pretty much the same, instead of serving a 100KB JPEG you're now serving a 60KB WebP. The same process applied to a JPEG results in a file roughly the same size as the original, for worse or equal quality to the WebP file.

    When I said standardization, of course I meant a regular standards track. For a format that wants to become a standard image exchange format, this is kind of a big deal. Standards bodies are vital for quality control and to decouple standards from the power of a single company. WebP is a pretty good example for why standards bodies are important: the spec is low quality, too brief and has been in constant flux since 2010, breaking backwards compatibility multiple times! VP8, which WebP is based on, has also been criticized for bad spec quality; much of the spec is verbatim C code taken from the reference implementation libvpx.
    I'd rather Xiph.org was in charge, that's for sure.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •