3 ms·
The one time that I've found a practical application for WebP was when a client needed to fit a roughly 1-megapixel photograph in less than 5 kbytes of storage
by teuobk 15y ago
The one time that I've found a practical application for WebP was when a client needed to fit a roughly 1-megapixel photograph in less than 5 kbytes of storage space. JPEG starts falling off a cliff in terms of image quality once you push it to extreme compression factors (like down near quality-0), but WebP degrades very gracefully and relatively linearly.
The test images we put together turned into nearly unrecognizable blocky messes when compressed with JPEG, if they fit at all. The same test images, compressed with WebP, looked surprisingly decent and were quite usable.
That said, if our photo storage budget had been 10 kbytes instead of 5 kbytes, JPEG would have been fine for the project's purposes. It was that last little squeeze that really killed JPEG.
- ZeroGravitas 15y agoI remember a trick from the early web days of halving the resolution of a JPEG and then expanding the compressed result back to the original size. It'll be blocky, but much less blocky than just reducing the JPEG compression level for the same fize size reduction at the low end. I believe WebM does (or at least the format can do) this automatically in low bitrate situations, without the external user needing to understand what's happening on the encode or decode end. I don't know if WebP inherits this trick and that explains it's low bitrate performance or if it's just better in other ways.