Google Continues Pushing Its WebP Image Format

[zanny]

All I read was this and it was enough for me to totally agree with you.

Opus and Dalaa seem be proving great competency on Xiphs part to just toss out 30 years of cruft and figure out modern ways to get great balances of compression, latency, and decode time. I'd love to see what they could do with static images.

[profoundWHALE]

I'd rather Xiph.org was in charge, that's for sure.

All I read was this and it was enough for me to totally agree with you.

[tomato]

Which only libjpeg supports and all other (like the most used library for jpeg decoding - libjpeg-turbo) will never support.

why it will never support them? (honest question)

[quikee]

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.

Which only libjpeg supports and all other (like the most used library for jpeg decoding - libjpeg-turbo) will never support.

[psychoticmeow]

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.

[brent]

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.

[psychoticmeow]

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.

[joh22n]

Thanks for the explanation and link to mozjpeg, brent.

[tomato]

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?

[brent]

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.