PNG really wasn't intended to the be a format for photographs. It can't even store EXIF data. As a lossless format, it can work for photographs but as the article is surprised to find out, it doesn't do a good job of compressing them.
I'm not impressed at this particular demonstration for just that reason. Does WebP provide a savings against jpeg for these photos?
The important question: how does a WebP encoded screenshot look? if there's a huge field of a single color and some text written on the field, are there visible artifacts all around the text? This is a use case for PNG, and one where people can plainly see why a lossless format exists.
> Does WebP provide a savings against jpeg for these photos?
A deceptively hard to answer question!
Why is it hard?
Because both jpeg and WebP (which is really just a VP8 intra frame) can represent images with a variable amount of bits.
But it gets even trickier! How do you measure "savings"? Certainly you can produce 2 images with the same (or similar) bitrates with both webp and jpeg, but how do you say one is better than the other? How can you lower webp's bitrate until it's "quality" measure is the same as jpeg?
Quality metrics such as PSNR, SSIM, and VMAF all exist to try to give a "quality" metric. However, they all have their own flaws that allow an image compression format to get worse subjective quality will improving their objective score (For example, codecs that optimize for PSNR tend to be more blurry than codecs that target SSIM. Grass ends up looking like big blobs of green).
In fact, because x264 was often being beat by other codecs in those metrics they went out of their way to add "cheat" modes for the encoder! You can tell x264 to target PSNR or SSIM :D. Neither are the default.
Just some fun thoughts. Subjectively, I'd say WebP and the newer AVIF or HEIF does a better job than Jpeg (to my eyes). However, I could see why others might disagree.
> Subjectively, I'd say WebP and the newer AVIF or HEIF does a better job than Jpeg (to my eyes). However, I could see why others might disagree.
They can do great with a clean original. But with an original that was already carefully mastered in JPEG format, with quality set to the bare minimum to get a good output... well, lossy compression is lossy, and when there isn't any margin for more loss, the results won't be good. (It's also true that since different lossy algorithms are, well, different, the interaction of two algorithms can be truly awful to look at).
Unfortunately, there are very few image editing pipelines which let one master in anything other than JPEG, PNG, or GIF.
I have a feeling it won’t be better, but for lossy-1 to lossy-2 conversion, has anybody tried using some ML algorithm to ‘recover’ the lost information from the lossy-1 image and then using the lossy-2 algorithm? It would give that algorithm an input that looks more like what it’s designed for.
Adding JpegXL to discussion. For still images it's about the same as AVIF, for high-compression samples AVIF have upper hand, for high-quality samples JpegXL feels better. Also, JpegXL is much faster, simpler, allows progressive encoding
> Does WebP provide a savings against jpeg for these photos?
“WebP seems to have about 10% better compression compared to libjpeg in most cases, except with 1500px images where the compression is about equal.”[1]
mozjpeg JPEGs + AVIF in a <picture> element is the way to go now. You will probably always want to serve JPEGs as an alternative WebP and AVIF and that makes WebP is a waste of disk space for lossy compression of photographs.
I'm amazed the “WebP is such a goated format” blog post made in to the front page of HN.
It's not really a "mode", it's a completely different codec that appears to have been invented by a single random guy at Google and they just released it one day. Much like the rest of WebP.
I'm aware of that, search for my other reply to this thread. Also that single random guy [1] is one of the co-authors of Brotli, WOFF2 and many image compression algorithms including JPEG XL.
I thought you had gravely misunderstood the article because the author leads with discovering the lossless compression support of WebP and even compares it to advanced lossless compression tools like PNGOUT so I thought he wasn't comparing apples and oranges.
But no. He DOES in fact compare lossy to lossless in the end, arguing the difference is hardly perceptible anyway. Which it is! I could see the loss of chroma when opening them on my desktop here. I don't understand. JPEG also compresses a photo better than PNG? What's the point?
This is just confusing. Sure, for personal use, do whatever you like, but in a comparison...
It would be interesting to see WebP Lossless vs PNGOUT. And/or WebP vs Mozjpeg. :)
It's the first one, though it's hopefully hard to find actual software that has that problem unless you're intentionally seeking out versions from around 2012.
> However, the big point here is that without doing any of that, WebP seems to keep the quality I prefer while also reducing the size (doesn’t matter to me whether it’s lossy or lossless).
Not just images but specifically photographs for web distribution. if that's not as far away from intended PNG use cases as can be, it’s getting there.
The root domain is pronounced "goat sex," although from the earliest days I'd heard of it, people were referring to it as just "goatsie" domain name goatse.
I've definitely heard of "goat" as a noun meaning that, but "webp is such a goated format" sounds more to me like the writer thinks people try to laud it as the goat when it actually isn't. I guess it's because it sounds like the passive voice; "is goated" makes it sound like someone else is doing the goat-ing, at which point for something subjective and desired like "goat", "goating" sounds like it's being used as a more modern slang for "astroturfing" or something.
> I've definitely heard of "goat" as a noun meaning that, but "webp is such a goated format" sounds more to me like the writer thinks people try to laud it as the goat when it actually isn't.
Funnily enough the article kind of does that, doesn't it.
WebP is a decade older than "state of the art" for this, and that difference costs a significant number of bytes.
The issue for me is it looks like an accidental autocorrect of the word “goatse” which internet users from an earlier pre-Facebook era may find more familiar than the verbifying of what was an acronym that is starting to be used as the original word but in a new adjective way.
I'm continually amused that this has become such a common expression. The first time I remember hearing something similar was in Infinite Jest where one character was the P.G.O.A.T (Prettiest Girl Of All Time).
Hi! This is the author of the post here. Thank you all for your input and discussion of the term "goated" and different photo formats! I'm not super into photography, I focused mainly on what looks good from a casual browsing experince and also saves space for me.
I want to note that there are formats that are meant to supersede WebP, such as AVIF and JPEG XL, however, AVIF (69.25%, I also mainly use Safari) [1] and JPEG XL (0%) [2] are not as nearly adopted as WebP is (91.38%) [3]. Usage taken on April 13th, 2022. Also, get a browser released after 2013.
You would have achieved similarly amazing compression results if you had converted your PNGs to ordinary jpgs - no "state of the art stuff" required. You say you don't care whether it's lossy or lossless as long as it looks good - why were you using such an inappropriate format for photos on the web in the first place?
True, jpegs would have achieved similar. I liked PNGs over the years because of the alpha channel, which was super useful. WebP is the only format I know that is both lossy and has an alpha channel.
I agree with you, it might not have chosen the best example pictures to use. Something with an alpha channel png->webp could be a better showcase. Thanks
I want WebP to work, but when I use it on my website the colors are different than the original JPEG files. This is a problem because I'm a photographer and those subtle differences can make a photo feel flat and dead.
I'm guessing either the JPG or the WebP didn't have the right color profile embedded, or one of them is missing the color profile. This stuff is still a nightmare right now. Colors are something everyone in the technology stack needs to work on getting right.
My problem with webp is that lossy mode only supports 4:2:0 chroma subsampling which can make bright colors look worse in some situations. The sharp_yuv parameter helps but it can also introduce visible changes that did not exist beforehand.
At Christmas I ran an experiment to convert all my blog images to webp. It worked well and my savings were around 50%. I haven't made the leap to make the move for the simple reason that webp isn't considered a "native" format in the main. I lose things like image previews when I'm navigating around my file system. That kind of thing. I think I'm also made slightly nervous by seeing so few others seeming to use it. Still might make the leap but haven't yet
Despite the snark here, I think it’s good that someone’s excited about discovering something and wrote about it. I haven’t looked at webp in a while, so maybe I’ll try again.
OT but I just hate that firefox converts images to webp by default. The downloaded file is NOT whats at that URL. Having another format to deal with and not well supported is super annoying. I tried once to disable this in the “advanced settings” but it broke something and had to revert.
Please have a simple checkbox in the standard settings page and have it disabled by default!
Some website backends have multiple image formats available. Their frontend will tell the browser to load webp preferentially with code like this. Browsers that don't support webp will just fall back to jpeg or whatever.
The html looks something like this:
<figure>
<picture>
<!-- Load webp if browser supports it -->
<source media="(max-width: 500px)"
data-srcset="image.webp"
type="image/webp">
<!-- Load jpg if browser doesn't support webp -->
<source media="(max-width: 500px)"
data-srcset="image.jpg"
type="image/jpeg">
<!-- Fallback to this -->
<img src="image.jpg">
</picture>
</figure>
I process images on upload to be available in multiple sizes and formats. I serve webp first since the (normally) smaller size makes the page faster for users.
Source? Are you absolutely certain that the webserver is not transparently converting jpeg to webp and serving it under the same url? Cause that’s how every bug report about FF saving images as webp ends up getting resolved.
In case you don't want to install an extension, search in about:config for "image.webp.enabled" and set it to false. Worth mentioning, there's also a "image.avif.enabled" entry.
That is not the same thing. This addon does not modify "image.webp.enabled" or "image.avif.enabled", it modifies the accept header. If you modify the preferences you mention you will still be served AVIF and WebP, but viewing will break...
It doesn't convert them, but when it makes an additional request to download the file, the server might (depending on MIME hell, etc.) send back a different format. This is real and annoying.
First, not entirely sure what "goated" means, but whatever floats your boat.
Next, comparing a lossless format like PNG against a lossy format like webp ... what's the point unless all of his webp files are losslessly compressed.
Last, if one wants to dive down the lossy image format rabbit hole, then webp is definitely very old news, jpeg XL [1][2] is - for example - much more cutting edge.
Not in this case, but comparing lossless PNG with lossy WebP makes sense because PNG is the only other format on the web that supports alpha channel. There’s no lossy format for that other than WebP.
thank you! Yeah, I looked at those as well, but as a safari user, AVIF was just a no go and JPEG XL, looking cool though, is not adequately supported by anything (maybe just yet?)
I'd rather have JPEG XL personally. The other one that's really cool is Basis Universal, which is unique among compressed image formats in that it decodes directly to a GPU compressed texture in VRAM, resulting in way less memory usage and bandwidth consumption when the image is displayed. That's right, it remains compressed even as you view it!
The reason why I'm mainly excited about .avif is that it'll run on the same hardware that decodes .av1 files. Means encoders will very easily be hardware accelerated - great for services or bulk encoding projects.
Hardware decoders tend to have strict limits on things like picture size, which video complies with and random still images often don't. So compatibility is not guaranteed.
Neither is quality of course. Video encoders aren't always tuned for still images and it's even harder to tune a hardware encoder.
One thing I haven't seen stated here yet is that WebP is apparently a low resilience format: lose a few bytes and your image is dead.
Still, it's extremely light and is much better than JPG for photos and PNG for simpler visuals. You can easily shave off an extra 50% file size off a standard optimized PNG image without any incurring any significant loss of quality, and even more if you're ready to accept higher losses.
For Linux Mint users out there, the OS doesn't ship with an image viewer for the WebP format. qView is a really nice open source option Mint users may want to look into. You can also find Nemo file manager right-click actions on Github (Linux Mint Nemo WebP Converter Actions).
I dunno, to me all photos in article are extremely oversaturated hurting my eyes, can't even see difference. I don't understand motivation of people oversaturating their photos.
Who the heck use PNG for photos and then compare it with WebP optimized for photos? He should have used at least JPEG, JPEG XL, AVIF or whatever other suitable format for photos.
This comparison doesn't make sense even if I ignore the fact all photos regardless of format are extremely oversaturated to the point it almost hurt my eyes.
I tried webp for my photo blog (https://roambyland.com/) but the quality was noticeably worse and I've never gone back. Its not there yet unfortunately.
That's such a cool website! Definitely, if someone focuses on photography, I am not fully into the field to know the best practices, simply trying out new and small things that I find around.
however AVIF only has about 65% market penetration.
If you ran a serious webserver, it would make more sense to do automatic on the fly conversion using mod_pagespeed. This way it handles browser support for you.
A decent proportion of the .JPGs and .GIFs being rendered on sites I visit are actually now .WEBP files with the headers set. So I'm seeing lots of people already making this translation invisibly. You only notice when you try to save the images.
Or when you notice quality loss because the original JPEG has significantly higher quality than whatever it got transcoded to.
Seriously, people, stop transcoding to "newer, better" formats at lower quality. Just stop. I should never have a better experience if I set up an older browser that doesn't accept your newfangled stuff. Either manage to get the quality right (easier said than done) or just don't transcode stuff.
(This is much easier to get right if you are also shrinking an image.)
It seems to be pervasive for people to grossly overestimate the savings they can get, looking e.g. at how MPEG-4 TV channels are generally lower quality than MPEG-2 channels. And the biggest HEVC torrents are at most less than half the size of the AVC torrents, usually only like a quarter the size.
It's a little small of you since file extensions generally have no actual relation to formats. There's nothing stopping you from naming yours .wbp, although I wouldn't expect most programs to accommodate you.
I just changed one to .wbp to test with paint.net. The Open File dialog doesn't even have a mask that allows me to show the file. Dragging and dropping resulted in the program complaining, "The image type is not recognized, and cannot be opened" despite WebP having a recognizable header. But I lay that at the feet of the application, not the format.
In the end, it's okay to be a little small sometimes. I've held grudges for less myself.
The problem with webp is that if you use a good jpg encoder the filesize/quality improvements are negligible especially with the higher parsing time for webp. The problem is like with x264 bad encoders from adobe.
