21 ms·
WebP is so great except it's not (2021)
- lelag 3y agoI clearly have "non-educated eyes" as I can't see any meaningful differences personally.
- vinaypai 3y agoSame here. Especially considering the ones supposedly "look like shit". The whole thing reads like a no-so-subtle brag about how his mighty photographer's eye can spot details that mere mortals can't.
- ageitgey 3y agoYour viewing environment will matter a lot. In a dark room with a bright monitor, the banding in the background of the example images is pretty bad (if you are looking for it). But if you have a laptop in a bright sunny room in front of a window causing back lighting, you probably won't be able to see it.
- gorlilla 3y agoIt's there. It's very noticeable once pointed out. It drastically distorts the images' 'softness' because of the harsh steps through the gradients. It does not appear as the artist intended for it to, which is the biggest issue.
- dontlaugh 3y agoIt depends greatly on your device. On my work windows machine I can see a bit of banding. On my phone, it's worse. On my macbook, it's atrocious.
- kome 3y agovery interesting, i could clearly see the difference - even before reading. and i'm using a 9-year-old MacBook Air 11'... not bad, but not exactly high-end stuff. fascinating how perception is different.
- neurostimulant 3y agoGood for you. Once you noticed the banding issue, you're cursed to see it everywhere.
- djha-skin 3y agoLike most folks you were probably simply looking at the foreground. The background around the edges of the shirt and the edges of the picture (depending on the image) noticeably change color from shot to shot without full screening it on my small Android 12 device. It's artifacts made in the background of the image that this poster is complaining about.
- squidbeak 3y agoMy sight's both poor and uneducated, but looking again after the defects are pointed out, they're pretty stark.
- ColonelPhantom 3y agoIt's such a shame Google decided to block adoption of JPEG XL: it's a strict improvement over classic JPEG (you can losslessly reencode JPEG to JXL and reduce the size, due to a better entropy coder in JXL!) and JXL has various other upgrades compared to 'classic' JPEG. In the meantime, let's hope AVIF or whatever manages to pick up the slack, and/or other browsers decide en masse to support JPEG XL anyway; that would be a bad look for Google, especially if even Apple decides to join in on the JXL party.
- jfeser 3y agoApple already has! Safari has Jpeg XL enabled by default.
- Latty 3y agoI must admit, I'm not sure why JPEG XL is viewed so favourably on HN, it's not something I know a ton about, but my understanding is that the big advantage of AVIF is that you can reuse hardware decoders built into devices for AV1 for the images. It being a strict improvement over JPEG is nice for the developers not having to go back to the source image for an upgrade, but that seems like a pretty small benefit that only matters during the transitional period. Meanwhile, if you are getting better battery life every time someone views an AVIF image, that's a huge benefit for the entire lifetime of the format, it seems to massively outweigh any advantage JXL has, to me.
- izacus 3y agoJPEG XL is viewed favorably on HN because it's the underdog to evil Google. Before they wrote their complaint article about Chrome removing support (after significant time of noone using the format), noone here gave it a thought. It's not like anyone is attacking Firefox for not enabling it either. This is not a format quality thing, this is "let's have a chance to complain about Google" thing again ;) I mean, this whole posted blog is doing a comparison on a single image. Anyone with a bit of thought would dismiss this as ridiculous in first second... but there's the Google name and the HN haters are out of the woods.
- V__ 3y agoI opened the first two pictures in separate tabs and switched quickly between them. There is zero difference. Tried it on two different monitors, Chrome and Firefox. Same with the pictures of the guy at the end. EDIT: The last comparison is webp twice, he linked it wrong. Here is the jpg one, still no difference: https://eng.aurelienpierre.com/wp-content/uploads/sites/8/2021/10/Shoot-Antoine-0044-_DSC0085-lossy-noise.jpg https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20...
- Zetobal 3y agoHere is the diff: https://imgur.com/a/QT8oNqj https://imgur.com/a/QT8oNqj >> To the non-educated eye, this might look ok, but for a photographer it’s not, and for several reasons. webp is a banding nightmare.
- rewmie 3y ago[dead]
- lm28469 3y ago> There is zero difference. There is a clear difference though, I can see it in all my monitors, from desktop to laptop and even mobile. It's especially visible in the top right quarter. That being said if you're not into photography you might just not care enough to see it
- vardump 3y agoI checked those images on a Macbook 16 M2 Max (standard P3-1600 nits preset), Chrome 120.0.6099.109. All of the WebP images had pretty bad posterization, while JPEG examples did not. Edit: You have to actually click for a full size image to see the truth. Those inline images had pretty bad compression artefacts, even the supposed lossless versions. So https://eng.aurelienpierre.com/wp-content/uploads/sites/8/2021/10/Shoot-Antoine-0044-_DSC0085-lossless.webp https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20... (full size lossless WebP image) looks fine, but inline version of the same image https://eng.aurelienpierre.com/wp-content/uploads/sites/8/2021/10/Shoot-Antoine-0044-_DSC0085-lossless-1200x675.webp https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20... looks terrible. Edit 2: The difference between... https://eng.aurelienpierre.com/wp-content/uploads/sites/8/2021/10/Shoot-Antoine-0044-_DSC0085- https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20... lossy-noise.jpg (216 kB JPEG) https://eng.aurelienpierre.com/wp-content/uploads/sites/8/2021/10/Shoot-Antoine-0044-_DSC0085-lossy-noise.webp https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20... (150 kB WebP) https://eng.aurelienpierre.com/wp-content/uploads/sites/8/2021/10/Shoot-Antoine-0044-_DSC0085-lossy-noise-96.webp https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20... (301 kB WebP) ... is pretty obvious. Both of the WebP examples, even that 301 kB version, show clearly visible posterization. I wonder if there's some issue with the WebP encoder (or the settings) he is using? Edit 3: It should be noted that monitor gamma and color profile might affect gradient posterization visibility.
- laserbeam 3y agoI know this is not constructive and I'm sorry, but I just can't read the text with those st and ct ligatures. It makes me feel like the author is trolling with them and I shouldn't take the text seriously. I know that's an exaggeration but that's what the design makes me feel.
- rokkamokka 3y agoIt does really mess up the typography
- muzani 3y agoIt's like that tiktok voice when used in technical demos. Just can't focus on anything else.
- catach 3y agoLuckily Reader Mode or disabling CSS takes care of the oddity.
- tzs 3y agoI wonder if that would still work if the ligature were done in Unicode instead of CSS?
- catach 3y agoInteresting question! The st and ct ligatures used in the article don't seem to be part of the precomposed Latin ligature set, and what is there strikes me as far less obnoxious [1,2]. I expect it's possible to hack something together with combining characters, but also that the visual result would be far too ugly for the tastes of anyone who was desiring ligatures in the first place. [1] https://en.wikipedia.org/wiki/Ligature_(writing)#Ligatures_in_Unicode_(Latin_alphabets) https://en.wikipedia.org/wiki/Ligature_(writing)#Ligatures_i... [2] https://superuser.com/questions/669130/double-latin-letters-in-unicode-ligatures https://superuser.com/questions/669130/double-latin-letters-...
- 3y ago
- bawolff 3y agoI dont get it. The author seems to care highly about image quality, but also wants to squeeze out as many bytes as possible? Bandwidth is cheap. If we are talking about photography as art, why would you be trying to scrap a few kb off in the first place?
- tommica 3y agoBecause not all countries have cheap or unlimited bandwidth
- maigret 3y agoAlso planes don't, so it's not a poor vs rich topic as many seem to make it be.
- rahen 3y agoYou missed the point he's making: webp requires 30% more data to achieve the same dynamic than jpeg, so there's no real use for it.
- bawolff 3y agoDid he make that point? The only time he thought they were equivalent was when using lossless mode, which is not a reasonable comparison. He never actually compared webp at 30% more quality than jpeg.
- rahen 3y ago> "WebP is actually 39 % heavier than JPEG 85 plus noise for a similar-ish look on this difficult picture, and still not totally as smooth as the JPEG (there is still a tiny bit of ringing). It’s also 30 % heavier than JPEG 90 with simple Floyd-Steinberg dithering."
- iainmerrick 3y agoHe did, about halfway through: WebP [lossy, 96] is actually 39 % heavier than JPEG 85 plus noise for a similar-ish look on this difficult picture, and still not totally as smooth as the JPEG (there is still a tiny bit of ringing). It’s also 30 % heavier than JPEG 90 with simple Floyd-Steinberg dithering.
- rado 3y agoYes, there is some banding, because it's a web format designed for small file size. 10-bit AVIF has smooth gradients in smaller size, thought not as well supported yet.
- iainmerrick 3y agoBut why should it be worse than JPEG in that respect? It's a much newer format and supposedly much better.
- seba_dos1 3y agoIt's just a happy accident that the way JPEG compresses things and smooths them out visually happens to be an advantage in this particular edge case.
- nicole_express 3y agoI wouldn't call it a happy accident; JPEG was carefully designed to look good for single-frames with the limitations of the human eye taken into account. WebP is based off of a video format, and tradeoffs there are very different.
- deleted 3y ago[deleted]
- hackererror404 3y agoIsn't this like anything else? No one size solution typically works for everything. If you are a photographer/artist and true close to perfect rendering is for you... don't use WebP as the format to present your images.
- snvzz 3y agowebp should have been skipped entirely. Let's focus on AVIF.
- account42 3y ago> Let's focus on AVIF. That's a weird way to write JPEG XL.
- snvzz 3y ago>JPEG XL What's the legal/licensing status of that? How does it compare technically to AVIF?
- arghwhat 3y agoHonestly, for these cases focus on JXL. It supports lossless re-packaging of existing JPEG with compression benefits, more or less matches AVIF while having much options for much better compression times. But if JXL isn't an option, definitely AVIF.
- axlee 3y agoUnless the OP is using a 8K monitor with professional color grading, I don't understand how he can say that some of these pictures are "looking like shit". They all look exactly the same to me on my regular 27" 1080p, on my 27" 2K or on my iPhone.
- lm28469 3y agoEasily visible on my air M1, 1080p gaming monitor and pixel 3
- rutierut 3y agoProbably if you’re working a lot with photography compression artifacts start to become a real eyesore. Especially the first lower quality webp image does look like shit to me but I also realize a lot of other people would not consciously notice. The banding is just not supposed to be there.
- rsp1984 3y agoThis seems to be in the same spirit as audiophiles claiming they can hear the difference between various speaker cables, or the "hints of dark chocolate" in wine tasting. Personally I see zero differences in the images on that page and unless the author has some really super-human vision abilities (possible! but unlikely) my guess is he doesn't either. WebP looks perfectly fine to me.
- lol768 3y agoIt's very easy to see the banding if you have a half-decent monitor. You don't even need to view the images fullscreen - and I say that as someone short-sighted with deuteranomaly.
- f1shy 3y agoI think deuteranomaly plays absolute no role in B&W images. And if any, helps to view defects that other don't. I have it. The artefacts are visible mostly in the background, where frankly I do not care.
- ageitgey 3y ago> This seems to be in the same spirit as audiophiles claiming they can hear the difference between various speaker cables, or the "hints of dark chocolate" in wine tasting. I can see why it would seem like that if you aren't seeing it, but it's not the case. The differences in color banding are pretty big if you are on a screen where you can see the background shading clearly. The brightness of your monitor and the relative brightness of your room will matter a lot. In a bright room, you might not be able to see the subtle banding in the background of the images. But if you are looking at a bright monitor in a dark room, the difference is very obvious.
- red_trumpet 3y ago> In a bright room, you might not be able to see the subtle banding in the background of the images. You are right. I just made my room dark to try this out, and now I can see the banding!
- cybrox 3y agoIt seems I have an uneducated eye by their standards, because I barely see any difference, which I'm happy to admit, but I think the author misses the point of webp completely. The format is intended to bring down the file size of graphics in general, not high-level photography which accounts for probably 0.5% of the images on the internet. This is a case of the best daily driver car won't be good enough for a race car driver.
- digging 3y agoYeah this article comes off as almost idiotic to me. It is entirely irrelevant unless you're supporting high-quality photography on your site, in which case, yeah obviously you're going to be careful about how you compress your images. For the vast majority of web images, use webp if it's smaller. Minuscule artifacts and judgy designers aren't going to get in the way.
- mihaic 3y agoThis article didn't go into the biggest problem with webp for me: the inconveninence of the format outside the browser compared to the small space saving. There are better formats (the video-codec inspired ones like heif, avif, and what might come out of h266, or even jpeg-xl), and webp just seems like a compromise without enough upside.
- RealStickman_ 3y agoWebP is actually based on a video codec. It's just that VP8 pretty much never caught on with hardware encoders/decoders apparently.
- acdha 3y agoVP8 was never competitive so most of the energy went into VP9, which did beat H264.
- hot_gril 3y agoIt beat H.264 in terms of quality/size but not in terms of hardware support. This is why Google Meet is the laggiest video conference software, they keep trying to make VP9 a thing while the others stuck with H.264. And now there's H.265.
- mihaic 3y agoI remember doing bluray re-encodes back in that day. x264 was simply better as an encoder when compared to vp8 and you knew that at least in terms of software everyone had a compatible decoder in their preferred codec-pack.
- hot_gril 3y agoOh yes, with uh websites where you download said re-encodes, there'd always be a few uploads with weird encoding and the author screaming in the comments that it's better and you gotta use the bleeding edge VLC before complaining that it doesn't work.
- bawolff 3y agoI can see some banding on the one labeled webp lossless. What gives? Is the banding in the source material? Are we using a different definition of "lossless" than i am used to? Edit: i think maybe my browser is scaling the photo which is adding artifacts. Edit2: maybe the thumbnails are scaled at different quality levels???
- RealStickman_ 3y agoYou have to open the images in a new tab to get the full res version. Then the webp lossless looks perfect.
- kmoser 3y ago> maybe the thumbnails are scaled at different quality levels??? Agreed, the WebP lossless version looks pretty bad when scaled by the browser. And since virtually no website/device shows images at their native resolution these days, that's something to consider. On the other hand, most people these days view websites on their phones, so those artifacts will be harder to see.
- bawolff 3y agoI dont even think its that - it seems like it was scaled badly by the author of the post not the web browser and that he is not actually displaying the lossless version. If you click on it it goes to the lossless version but the version dispkayed on page is not that version.
- kmoser 3y agoIt's even worse than what you said: the <img> tag has a srcset attribute with many possible values so different people may see different images depending on their browser's resolution. The one displayed to me was Shoot-Antoine-0044-_DSC0085-lossless-800x450.webp, which shows clear posterization at its native size as well as when it is further scaled down by the browser to 550x309.
- 3y ago
- kvrck 3y agoI don't get the point of complaining about losing such small details that non-educated eye can't see for a compression format. That's the whole point of compressing the image, isn't it? To me, it looks like webp does its job.
- truculent 3y agoOP is a photographer and is pretty clear about that being part of their motivation: > Stick to JPEG at 90 quality (or at least 85) if images matter to you, e.g. if you are a visual artist. If images are pretty decorations for your textual content, it doesn’t matter.
- barrkel 3y agoThe gradients on webp frequently look like video stills. Chroma subsampling reduces the density of available luminance approximations and the more heavily it's applied, the worse gradients look. High contrast high frequency details aren't affected much, but gradients can really suffer.
- CyberDildonics 3y agoChroma subsampling reduces the density of available luminance approximations Chroma means color, and color subsampling is used to avoid taking information out of luminance channels because they are more important, so it is actually the opposite of what you are saying here.
- barrkel 3y agohttps://www.google.com/search?q=gradient+banding+4:2:0 https://www.google.com/search?q=gradient+banding+4:2:0 There simply aren't enough bits of precision in the luma encoding for good gradient support most of the time, chroma fills the gaps, and chroma subsampling produces artifacts. Webp lossy only does 4:2:0 https://groups.google.com/a/webmproject.org/g/webp-discuss/c/6Nm_L-m6z-Y https://groups.google.com/a/webmproject.org/g/webp-discuss/c... These problems would go away with 10-bit AIUI. AVIF supports 10 bit but WebP does not.
- CyberDildonics 3y agoI think you're conflating a few different things. Chroma doesn't fill gaps, low resolution chroma channels introduce artifacts of their own. This is spatial resolution, 10 bit color channels is quantization resolution of the values. Everything contributes to banding artifacts, which are just noticeable changes in values when that are meant to be perceptually smooth, but the luminance channel is the most important, which is why it isn't subsampled. These are fundamentals of image and video compression and not unique to webp.
- zerocrates 3y agoI was going to say, it's not uncommon to see pretty bad banding in dark gradients with WebM/VP9, so this makes some sense.
- mngdtt 3y agoAll of these new formats like webp or avif look like shit. They look like screenshots from videos, which is what they literally are.
- rutierut 3y agoThe uncompressed WEBP image looks terrible to me with a lot of banding on Safari mobile. Did the author accidentally switch images or is Safari doing some “optimization”?
- ncruces 3y agoThere's pretty bad posterization in the background. If you can't see it, kick up your contrast. You don't need HDR levels of contrast to notice it.
- kome 3y agoClearly, from reading the comments here, most people don't see any difference. However, the argument still stands, and perhaps - precisely because of the comments here - it becomes even stronger: there is no point in using WebP.
- xmcqdpt2 3y agoThe article is talking specifically about portfolio pictures for photographers. I that case, it doesn't matter what most people see, it matters what the person hiring you sees. And if you are doing commercial product photography, the person hiring you is probably going to be an art director who has spent many days messing about with pictures to get smooth background on websites and in print.
- Beijinger 3y agoThe author may be right but he definitely does not understand the difference between good and good enough.
- iainmerrick 3y agoIs it really unreasonable for a photographer to have a higher standard of "good enough"? Anyway, his point is that JPEG was already "good enough", and WebP is not actually "good" for his purposes despite claims that it's better than JPEG for all purposes.
- 627467 3y ago> To the non-educated eye, this might look ok, but for a photographer it’s not, and for several reasons. There surely must be better examples to show "non-educated" plebs (to use the tone of the post) why webp is bad and to justify the post and the tone. I'm on Android, maybe this is why all pic quality look the same? Also - yeah, if you are making pics for educated eyes: don't use tech that is not suitable for educated eyes? Or don't outsource that decision making to others?
- deleted 3y ago[deleted]
- supriyo-biswas 3y agoSee the discussion here [1], you need to view it full size to be able to tell. [1] https://news.ycombinator.com/item?id=38653224 https://news.ycombinator.com/item?id=38653224
- chmike 3y agoA close up section of the same zone in the images would make them visible. I could hardly see the artefacts in the first place as my attention was caught with the highly contrasted parts of the images.
- afavour 3y ago…so essentially WebP is fine for mobile devices and the vast majority of desktop web cases. I’m fine with WebP not being a suitable format for permanent storage of photography.
- Izkata 3y agoNo, I can see it on Android without zooming in. Not well for sure, but it is there towards the corners.
- ubercow13 3y agoThe authors point is that if you are making this tech, you should have educated eyes. And given all the confident comments in this thread claiming the author is full of shit and there's no difference, I think their frustration is justified? If you can't see the difference in the first images that's fine but you probably shouldn't be confidently claiming to know better than the author, let alone designing an image codec.
- PetitPrince 3y agoA bit of context: Aurelien Pierre is known to be a major contributor to Darktable (open source raw developper / catalog ; in other words, an open source Adobe Lightroom), and is known to have strong opinion about the correct way do to stuff, to the point of abrasiveness and to the point where he has forked Darktable into its own stuff (Ansel; see HN discussion some times ago https://news.ycombinator.com/item?id=38390914 https://news.ycombinator.com/item?id=38390914 ).
- rpgbr 3y agoI’m all in .avif. Smaller files and excellent image quality. But I always have a fallback to .png or .jpg. We’re not there yet — looking at you, Edge, the only major browser that doesn’t support .avif.
- hannob 3y agoIs webp still relevant these days? You can use picture/source/srcset to provide different image formats depending on browser support. avif for modern browsers, jpg for maximum compatibility. Means people with old browsers will either get lower quality or a few more bytes, but that seems like an okay tradeoff.
- account42 3y agojxl for modern browser, jpg for the rest would be a much better solution, especially if the source is jpg
- lifthrasiir 3y ago> It’s not 100 % clean either, but much better. Granted, this is WebP re-encoding of an already lossy compressed JPEG, so we stack 2 steps of destructive compression. But this is what Google Page Speed insights encourage you to do and what a shitload of plugins enable you to do, while pretending it’s completely safe. It’s not. > I have seen a similar effect in other similar pictures : always pictures with large, smooth, gradients in the background, which happens a lot when some punctual-ish light falls off a wall. That’s not something accidental, smooth fall-off are actively built by photographers to create organic-looking backgrounds with just enough of texture to not get boring, yet discrete enough to not draw attention off the foreground/subject. I think this rant could have highlighted these paragraphs a lot more, because these are indeed problems. The first paragraph probably refers to [1] where it doesn't say too much about recompression artifacts, and the second paragraph is indeed a well-known issue of the lossy WebP format---it tends to create gradient bands that are particularly significant when viewed on big and bright screens. It is far-fetched to claim that this requires somehow trained eyes, rather it is more or less device-specific in my opinion. [1] https://developer.chrome.com/docs/lighthouse/performance/uses-webp-images?hl=en https://developer.chrome.com/docs/lighthouse/performance/use...
- acqq 3y agoIndependently of that article, I've experimented with webp to find out when I would use it, and concluded approximately the following (of course, somebody else can have different preferences and conclusions): - If you know how stills from mp4 videos or similar "look like" (when observed so that the compression artifacts are visible) -- that's more-or-less lossy webp. Not something you'd expect to achieve the best picture quality. - Probably because of its origins, that's also how lossy webp handles scanned or printed images: not good. I've concluded that I will use webp, but 1) to save the pictures for which I don't care which quality they have, and if I want to use up less bytes: specifically: if I want to save some visual information from some JPEG from somewhere only to store a picture of that not to preserve it in its full quality. 2) when serving the pictures, in scenarios where I want to reduce the amount of data delivered to others, when the artifacts I'm aware of aren't the issue. Everything else: still no.
- icehawk 3y agoThe banding is SUPER monitor dependent, its noticeable on my 4k monitor, super apparent on a different monitor with a terrible LCD panel, and not at all visible on my iPad. I wonder if the author took that into consideration.
- lifthrasiir 3y ago> not at all visible on my iPad. That is indeed surprising. Is it iPad or iPad Pro? It is technically possible that your monitors only support 8bpp color depth while your iPad Pro supports 10bpp (via the P3 color space) and the WebP file has a smooth gradient only when viewed with 10bpp or more. But I can't really believe that, as the original JPEG file still looks like 8bpp and doesn't have any further color profile attached.
- crazygringo 3y agoThat wouldn't make any sense unless there's something else going on. It could simply be an effect of brightness -- do you have your 4K monitor set to bright, while your iPad is much dimmer? (Remember Apple devices have adaptive brightness enabled by default as well.)
- derf_ 3y agoBack in the early 2010's I had a cheap Dell laptop with a 6-bit panel and an integrated Intel GPU. Video on that device had incredible banding, almost all the time, because as I understand it, the Linux drivers were relatively immature and did not do any dithering. A few years later a driver update enabled dithering and the bulk of the problem went away. As a video codec developer I was a little sad about that, actually. I had to start looking closer to see problems.
- tcfunk 3y agoI never gave it much thought until I started posting my 3d renders online. Began to find serious issues, especially around posterized backgrounds as the article mentions. A problem which is exacerbated by the vignettes that renderers offer.
- j1elo 3y agoComparing with Beyond Compare: https://imgur.com/a/xatzZt7 https://imgur.com/a/xatzZt7 -- Hoping the conversion doesn't add extra noise, I converted them (with ImageMagick: `convert image.webp image.png`) and compared them (Beyond Compare doesn't support WEBP). Of course I have a non-educated eye as the article puts it, but if still with machine help I cannot see a difference in light dithering, there must be something off. The second photo (of a man) is more clear in proving the point. This should probably have been used as the first example in the article.
- politelemon 3y agoWow,had no idea BC did images. I've been using it for years!
- scythe 3y agoI guess I don't get the context? WebP is barely supported. For decades the only choice in lossy compression is JPEG, which notoriously sucks for diagrams and basically anything that isn't a photograph. So the rest of the world finally gets a format they can use, and the photographers are angry that the world doesn't revolve around them anymore? So what if it is worse for photography? Should we continue chasing our tails for another ten years before we find the perfect format? I'm sick of data visualizations drowning in JPEG artifacts. I'm not opposed to AVIF or whatever, but I don't care about the author's complaints. JPEG is still there. If you want to use it, go ahead.
- PUSH_AX 3y agoAll the images look fine to me.
- lizknope 3y agoI wish Slack supported webp. I end up saving an image have to run "convert image.webp image.jpg" and then upload the jpeg
- withinboredom 3y agoFurther, with jpeg, there is progressive jpeg. Allowing an image to show up asap on slow connections instead of trying to load the whole thing all at once. When I'm on a 2g connection, I absolutely appreciate progressive jpegs, though they are pretty rare in the wild (and pagetest doesn't even recognize them).
- dvfjsdhgfv 3y ago> Second, I don’t know why all the techies around have a huge kink over sharpness, but the most challenging situations I have faced as a photographer were with smooth gradients. Or more accurately, gradients that should have been smooth and weren’t in the output. I can tell you why: because it's hard, i.e. it's hard to compress efficiently. So if someone claims a breakthrough, they either did something extremely smart, or cut some corners.
- pembrook 3y agoI've noticed the same issue with WebP and have gone back to JPG/PNG for most things (jpg for photos, png for UI-type images) I think the real problem is, like many of the commenters here, most people can't tell the difference because desktop monitors have been stuck in a deadzone of zero innovation for the last 10 years. I'm sure half the folks here are viewing his example images on a 2012-era HD 1920x1080 LCD, which is definitely part of the problem. It's bizarre. Smaller displays (Mobile phones) and larger displays (4k TVs) have fantastic pixel densities now considering their viewing distance. However any panel in the range of 20"-40" is stuck in the mid-2000s. Also, I think the author would have done us a favor by using example photos with lighter backgrounds (or changing the background color of his post to black). The harshness of the black images on white don't allow the eye to adjust enough to see the issue. If you put those images on a dark background its super easy to tell the difference.
- orbital-decay 3y ago>because desktop monitors have been stuck in a deadzone of zero innovation for the last 10 years. That's a weird thing to say unless the pixel density is your one and only measure. Regardless of that, the posterization should be perfectly visible on a 2012 FullHD monitor, or even a 1366x768 TN screen of a decade-old laptop. Most commenters here are probably viewing the pictures on a scale different from 1:1.
- pembrook 3y ago> That's a weird thing to say unless the pixel density is your one and only measure. Is it though? We now have OLED TVs and OLED smartphones. Where's our OLED PC monitors? On every measure, if you care about colors/contrast/black+white levels/resolution/density, the average computer monitor has fallen far behind. You can't even buy a smartphone that has a panel half as bad as most PC monitors on the market. And, at least in my area, you'd actually have to go to a lot of effort to find a non-4k TV.
- scrlk 3y ago> Where's our OLED PC monitors? https://www.displayninja.com/oled-monitor-list/ https://www.displayninja.com/oled-monitor-list/ Mainly targeted towards the gaming market at the moment.
- jonstewart 3y ago> here I am, loosing faith in humanity <sigh> Me, too, buddy. Me, too.
- rambambram 3y agoI might be missing something because I never delved into it, but my problem with WebP is I can't save images this way from my browser. Well, I can save them, but they don't show up when I try to view them on my system (Ubuntu Mate 20.04 on RPi4).
- loeber 3y agoYeah same. Huge annoyance. I just want to stick to the same-old universally-compatible file formats I've always enjoyed everywhere.
- Pxtl 3y agoIn general I've found that this shift to .webp breaks all the nice interoperability and composability we used to have with audio and video image files since there seems to be zero interest in making sure that simple familiar features like still work.
- smallstepforman 3y agoThe problem is not the format, but the software / OS you choose to use. There are OS’s that have image format libraries, and once a codec is installed, ALL apps gain the ability to use it. This was first done in the 80’s, so if your Ubuntu 20.04 doesnt support data translations, maybe its time to switch to something else.
- rambambram 3y agoMight be the OS indeed. Luckily I can make screenshots and save as jpg or whatever. No need to ditch Linux for me.
- AlienRobot 3y agoThey don't show up on older Windows versions either. The file explorer needs some sort of library to handle .webp thumbnails correctly. I'm pretty sure you can install something on Ubuntu to make them show. Maybe try a different file manager?
- jeroenhd 3y ago
- onurtag 3y agoIn my opinion the worst and most distinguishable downside of webp is the forced 4:2:0 chroma subsampling. On many images with bright colors you can clearly see the color and brightness loss without an educated eye. On comparison [1] you can clearly see that the top right balloon has lost its vibrant red color. On comparison [2] the bright blue neon art on the center has lost its brightness. [1] https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2022_10_04/index.html#clovisfest*1:1&JXL=m&WEBP=m&subset1 https://storage.googleapis.com/demos.webmproject.org/webp/cm... [2] https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2022_10_04/index.html#lufthansa-aviation-center-after-sunset-frankfurt-germany-near-airport-frankfurt-fraport-03*1:1&JXL=m&WEBP=m&subset1 https://storage.googleapis.com/demos.webmproject.org/webp/cm...
- ShamelessC 3y agoNot to stir yet stir another debate but yeah, definitely not able to perceive the difference in either of the examples you linked. It would be helpful if that site let you drag the vertical comparison bar at least. On an iPhone 14 display.
- mediumsmart 3y agoI can see it in the second link setting webp to small in the orange reflections above the rightmost outside needle tree htms. ... oh, you cant drag it? ...
- mediumsmart 3y agothank you for that link - it is detectable but in my eyes neglegible for website use. What about saturation? I have to ask, what could be the reason this gives me pale blue (other colors are okeyish) jpg > webp: cwebp -pass 10 -m 6 -nostrong -sharp_yuv -quiet -q 60 -sharpness 2 $1 -o
- layer8 3y agoThe simple truth is that JPEG is more than good enough and has ubiquitous support. There is no reason to switch to a different format and risk degradation or reduced interoperability for slightly smaller file sizes.
- 2OEH8eoCRo0 3y agoI don't understand fanatically chasing smaller image sizes when JPEG was good enough for the web of the 90's. There must be a different reason to throw some of the highest paid engineers in the world at WebP and it ain't generosity.
- acdha 3y agoGoogle spent a large amount of money purchasing On2. WebP and WebM were a way to show shareholders that they were seeing benefits from the acquisition, and if you look at Google’s traffic volume you could make an argument that even a modest size reduction would pay for the engineering time. The problem was that this was basically only true for the largest sites. If you’re YouTube or Netflix, it pays to optimize your video encoding but for most other sites the volume just isn’t there and the performance costs for anyone who uses a CDN cancel it out because you need a lot of traffic for each format before a 10-20% byte size reduction saves more time than the cache misses take.
- arp242 3y agoImages on the web of the 90s were also low-res and generally didn't look very good.
- superkuh 3y ago>Look at the original JPEG at quality 85 : <img class="lazyload" decoding="async" src="data:image/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==" data-orig-src="https://photo.aurelienpierre.com/wp-content/uploads/sites/3/2017/02/03-WEB-800x971.jpg https://photo.aurelienpierre.com/wp-content/uploads/sites/3/..." alt="" /> Sorry, I can't. That doesn't actually display any image at all in my browser because you're relying on javascript execution to switch the img src to it's actual source. You don't need to do this for lazyload to work anymore. There's browser native lazyload. Just put the actual image in the src.
- voidnap 3y agoI came here to say the same thing. It's bizarre how the author's attitude is that the webp authors should know better. Yet his blog cannot link to images properly without JavaScript. My browser supports lazy loading images and srcset; all the things he would want. It does that without JavaScript. Yet he tries to implement that in JavaScript and does not have a fallback to use the browser's native implementation. It's difficult to take him seriously in criticizing others' competencies when he, in a blog post about image quality, cannot include images with over-complicating things to the point of breakage. His point on color banding is clear and others have pointed out that the luma in 4:2:0 subsampling is terrible. But Google is not in the photography business. (Overlooking his attempt to convert from lossy compression to another lossy compression.) It is in the content business but only in so far as it furthers its advertising business. It is not in content for the same reason as the author so they don't share the same interests. Compare https://jpeg.org/jpegxl/ https://jpeg.org/jpegxl/ to https://developers.google.com/speed/webp/ https://developers.google.com/speed/webp/ > JPEG XL is designed to meet the needs of image delivery on the web and professional photography. If you search google's documentation on webp they mention photography like four times and never as "professional photography". It's honestly funny that he is surprised that Google is advocating for a file format that does not suit his needs as a professional photographer. Google is an advertising business; everybody knows this. Finally, I never see critics of (or anyone commenting on) webp mention that it supports transparency. What other format is someone to use if they want lossy transparency? It's great for small low quality thumbnails of images (like jpg or png) or animation (like gif) or video. You can throw just any input at ffmpeg and ask for a webp and it will give you something useful that represents one frame of the input. It fills that niche very well. Once JPEG XL because well supported, I'd like to use it; I hear good things. But it isn't well supported yet so webp is the only option for images with lossy transparency.
- rchaud 3y agoOutside of photographers, how many people are looking at super high-resolution images on the web? Even images that might have high-resolution versions are usually converted to a shrunken image 600px wide to fit inside the website's theme scaffolding. Is that really even worth shaving 15% off the file size? If bandwidth matters, websites should look to reduce the volume of useless stock images littering their templates. WebP seems like a gift to Cloudflare and the other companies that do the heavy lifting of caching and serving millions of images across multiple sites. For users, it's at best indistinguishable from JPEG, and at worst an obstruction to saving images from the web.
- marcyb5st 3y agoHonestly, I would have agreed wholly with you until I spend 1 month volunteering in Kiribati. 2/3G is the norm there and even few KBs would make a difference. It reminded me a lot of my childhood with 28/56k modems :/ Additionally, I believe countries like India, Pakistan, Bangladesh, ... are in similar situation infrastructure wise (please correct me if I am wrong) and so for 1/2B people would benefit from a slimmer web.
- deleted 3y ago[deleted]
- karmakaze 3y agoIf I cared about archive image quality (and I do), I wouldn't re-compress older images in a new format unless I could do so from uncompressed originals. Re-encoding from a lossy compressed source will make quality worse. Storage is cheap and getting cheaper. What would make sense is choosing safe settings for compressing new photos in the new format.
- Findecanor 3y ago> Re-encoding from a lossy compressed source will make quality worse. JPEG-XL is supposed to reencode old JPEG files into 20% smaller files without quality loss though. In context, Google has been holding JPEG-XL back by removing support for it from Chrome and refusing to reinstate it, claiming that it did not have good enough "incremental benefits compared to existing formats" such as webp.
- karmakaze 3y agoWow, I didn't know that. A top google result says: > It is possible to losslessly transcode JPEG images into JPEG XL. Transcoding preserves the already-lossy compression data from the original JPEG image without any quality loss caused by re-encoding, while making the file size smaller than the original. I wonder how it does that and why JPEG didn't notice it could. I would re-encode to JPEG-XL, when supported. So then the situation isn't that WebP is so great but rather Chrome's not so great.
- gruturo 3y ago> I wonder how it does that It's trivial to do: JPEG's last stage is a compression via Huffmann code - which is a really ancient, not particularly effective compressor. You simply decompress that stage, and compress with something more modern, yielding better savings. Stuffit did it in 2005. PackJPG in 2006. Brunsli (a Google project!) in 2019 - and it was one of the inputs to the JXL draft. Lepton did it in 2016. > and why JPEG didn't notice it could. Oh that's the best part - they did, all the way back in 1991. The JPEG standard allows you to choose for the last stage between Huffmann and Arithmetic Coding - which is way more effective. Unfortunately it was patent-encumbered and its support is low. It yielded 10%ish space saving which wasn't worth the compatibility headache (it has the same extension and mime-type of a Huffmann-encoded JPEG, so a webserver won't know if your browser supports it). If it only had used a different file extension it would probably be the dominant format today.
- deleted 3y ago[deleted]
- jollyllama 3y agoJust give me a good ol' jpg. Or a png. Not everything is compatible with webp yet, but when I want to feed in an image from google images, it doesn't work.
- wizb 3y agoVoting how appallingly obvious the banding is to me. Couple of questions over images being mixed up aside, this stuff is important. Perception is psychological. And image formats are political. Perhaps some truly do experience zero banding or artifacts. But to the rest of us... "There are four lights" https://www.startrek.com/en-un/news/the-four-lights https://www.startrek.com/en-un/news/the-four-lights
- palata 3y agoI find it interesting how many comments here (presumably from "tech guys") confirm what the author wrote: > So there is a real issue with the design priorities of image algos from tech guys who clearly lack historical and artistic background, and don’t talk to artists, who anyway have largely decided that they were above science, maths and other menial materialistic concerns. I am a tech guy, and when a photographer tells me that an image looks worse than another one, if I don't see it, my first reaction is more "can you try to explain to me why it is worse?" and less "I don't see a difference, so you must be wrong". I would be slightly offended if an artist told me that there was nothing wrong with `if (vAluE < 3 ) {return true; } else {{ return false;}}` just because they cannot see the problem.
- rollcat 3y agoTech guy working in media here. 100x this. I often can't tell the (perceptive) difference between video encoded with codec A and B, but I do have objective metrics such as bitrate, framerate, CPU/GPU power required to encode/decode, device quirks, etc. When I doubt, I always defer my decision until after I can consider the input from my colleagues.
- alexey-salmin 3y agoWhile I agree with the rational component of the article (webp may be inappropriate for artistic photos) I had to force myself to read it. The "t" in the font screws me up completely, I tried twice to wipe the screen of my phone then thought that maybe it's a background picture getting in the way. So overall I find author's aesthetic sense very questionable which contrasts with his high-moral-ground tone.
- walteweiss 3y agoHaha, I used iPhone’s reader mode, which I do most of the times.
- aidenn0 3y agoThe "t" or the "ct" ligature?
- DrNosferatu 3y agoOn mobile Safari there is no visible difference. Could there be some default optimization going on?
- noahamelia 3y ago[flagged]
- lofaszvanitt 3y agoJust use mozjpeg and throw away webp.
- kmeisthax 3y agoSo... why are we still having problems with banding in image compression? If anything, gradients should be the easiest things to compress in these images, because the compression algorithms work entirely in the frequency domain. Whatever is introducing banding here is adding more frequency coefficients and making the image bigger and worse at the same time. Did Google/On2 just not notice that they were crushing every gradient they encode or is are all the common WebP encoders doing some kind of preprocessing pass that crushes gradients and munges luma?
- edflsafoiewq 3y agoI would guess the problem is that on a slow gradient, each individual block is very close to a constant. The tiny AC coefficients tend to be quantized away, resulting in a visible transition along block boundaries. I thought the loop filter was supposed to help with this though.
- suzumer 3y agoWebp is encoded using limited ycbcr values as opposed to jpeg which uses full range ycbcr values. When converting jpeg to webp, there will be banding. Grayscale limited ycbcr when converted to full rgb during display ill also have banding. Webp really doesnt have a banding issue unless you convert jpeg or display purely grayscale content.
- hardcopy 3y agoEvery time I've used webp, I've been disappointed. And when I'm disappointed, I try jxl for giggles and find much better photo quality (especially fine gradients), at a much better file size. Let's cut our losses, ditch webp and move to jxl.
- michaelcampbell 3y ago> Every time I've used webp, I've been disappointed. In what way?
- tiffanyh 3y agoIs this blog a joke/prank? The images don't link to the correct filetype stated. - "JPEG, lossy, 85 : 184 kiB" → links actually to a WebP file (https://eng.aurelienpierre.com/wp-content/uploads/sites/8/2021/10/Shoot-Antoine-0044-_DSC0085-lossy-dithering.webp https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20...) - "JPEG, lossy, 85 : 211 KiB" → links actually to a WebP file (https://eng.aurelienpierre.com/wp-content/uploads/sites/8/2021/10/Shoot-Antoine-0044-_DSC0085-lossy-noise.webp https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20...) etc... So when the blog tells you that JPEG is so much better quality, the "jpeg" image that's actually being shown is a WebP image.
- deleted 3y ago[deleted]
- michaelcampbell 3y agoThis entire article reminds me of the ones a few decades about about the utter indignity of mp3's, and how us peasants that use it _AT ALL_ or at the very least with any bitrate under 320bps was just criminal. Then proceed to play the flac's in their car. Ok.
- bigbuppo 3y agoThis is more like MP3 versus one of those random codecs available for Windows 3.1 that had some big company behind it that one day got bored with codecs and now makes industrial pizza ovens. As google is a major proponent of WebP and Google is known for dropping projects and services with no notice, and the fact that webp gives very little value on the server side and webp creates objectively worse visual presentation, it would be best to consider WebP as deprecated for any new development. edit: I would also like to note that there is no technical reason to use WebP. The only reason it is used because Google is literally bribing you with "better rankings" for using webp. In other words, it is strictly marketing-driven.
- deleted 3y ago[deleted]
- theodorejb 3y agoHow does the quality compare at the same file size? It seems like all the comparisons have fairly significant file size differences.
- bigbuppo 3y agoThis is yet another reason why the WebP format has been deprecated, at least in these parts.
- Fice 3y agoFrom my own experience, JPEG quality and compression efficiency can differ a lot depending on the encoder implementation. It would make more sense to compare specific encoders rather than formats in general. In 2014 (WebP was released in 2010) Mozilla claimed that the standard JPEG format is not used to it's full potential [1] and introduced mozjpeg project that is still being updated [2]. I wonder how it compares today with current WebP implementations. [1] https://research.mozilla.org/2014/03/05/introducing-the-mozjpeg-project/ https://research.mozilla.org/2014/03/05/introducing-the-mozj... [2] https://github.com/mozilla/mozjpeg https://github.com/mozilla/mozjpeg
- ComputerGuru 3y agoI just finished dealing with a very complicated pipeline for an online media management database. WebP is great except when it's not, and when it's not, it really sucks. I'm going to go with a technical argument here instead of a subjective one, so there's no room for argument: WebP is billed as a replacement for PNG and JPG, and advertised heavily as being usable in both lossy and lossless modes for either. This is blatantly false. Alpha channel aside, PNG is, effectivelyᵗ, 32-bits per pixel, 8-bits for each of RGB. JPG is notably not; to make good use of compression in the frequency domain possible, RGB is usually converted from RGB to YUV/YCbCr. But JPEG lets you customize how this is done, and you can choose to use the default chroma subsampling of 4:2:0, upgrade to 4:2:2, or forego subsampling altogether and use 4:4:4 directly. WebP is, experiments aside, always 4:2:0 in default/lossy mode (regardless of the tuning profile chosen). Screenshots, vector graphics, text w/ anti-aliasing applied, etc. look absolutely horrendous to the trained eye if converted from RGB or RGBA to YUV 4:2:0. WebP is unusable for png transcodes at any quality except in lossless mode. I'm not hating on WebP - PNGs converted to lossless WebP are still a good bit smaller, at least for large sizes. But I absolutely despise how pathetically low and biased Google's benchmarks touting WebP as the be-all, end-all have been. And the toolchain is severely compromised, because you have to manually remember to specify lossless mode when compressing a PNG to WebP and that gets harder when it's an automated toolchain and the export is several steps removed from the input. And this becomes completely Mission Impossible™ when you have a lossless WebP and you want to generate a thumbnail from it because the heuristic is no longer "source extension is png" to determine if the output should be generated in lossless mode. IMO, the WebP toolchain *and all other toolchains like ImageMagick and libvips* should pass through the "lossless" property of WebP by default, because unlike with other formats, it tries too hard to be everything for everyone at once and will fall over on its face otherwise. I said I wasn't going to talk about the subjective side, but I just want to say that even for tiny thumbnails, we've found that their WebP versions need to be generated with at least quality 90 to ensure they will all (regardless of source image) be usable on non-mobile devices (hi-dpi ameliorates but does not resolve the situation, it's just the fact that you see the pixels physically larger); the smoothing effect for detailed real-world photos (think warzone photos with smoke and haze in the air, odd lighting, etc) is way too extreme at lower qualities. Again, the quality:size ratio is still better than JPEG, but not to the extent that Google advertised it to be, but more importantly, if you took Google at its word you would find WebP to be altogether unusable to begin with. (None of this was about converting already lossily compressed content into WebP; this is straight from source (where "source" is a lossless format like SVG, PNG, RAW, or something like a 24MP JPEG@Q95 being shrunk orders of magnitude) to WebP.) I played around some with AVIF, HEIC, and JPEGXL. AVIF has some severe color management issues that need to be ironed out in the various toolchains, though HEIC is a lot better in that regard but its lack of compatibility now and in the foreseeable future just makes it a dead end; but JPEGXL appears to be a really solidly built image codec with great potential, kneecapped primarily by adoption. ᵗ palletization can, but does not have to, affect this
- bitsandboots 3y agoFor what its worth, the website itself also isn't great. Had to turn off Enhanced Tracking Protection mode to not get text that scrolled off the screen, and then was met with weird fonts.
- angiosperm 3y agoCan I just say how happy I am to see the "ct" and "st" ligatures in the article text? I know that took the author extra effort to provide.
- angiosperm 3y agoI see: { font-family: 'Linux Libertine'; font-variant-numeric: oldstyle-nums; font-variant-ligatures: common-ligatures discretionary-ligatures contextual historical-ligatures; text-rendering: geometricprecision; font-kerning: normal; } I guess those are "historical ligatures". I personally persuaded the creator of the Linux Libertine face used in the page to add those to it.
- Izkata 3y agoI hate it, my brain wants to interpret it as a https://en.wikipedia.org/wiki/Inverted_breve https://en.wikipedia.org/wiki/Inverted_breve
- kwhitefoot 3y agoWhy aren't the competing images presented side by side? Having to scroll to examine them makes comparison very difficult, especially for those of us not blessed with an experienced photographer's eye.
- Izkata 3y agoMy issue with webp is that when it's animated, it seems random whether it gets treated as an image file like a gif or a video file. Any webp I save I have to convert to a real image file to ensure I can view/use it outside of a browser.
- hot_gril 3y agoWebp is like usb-c in a way, multiple different capabilities in one package. Might sound good on paper, but gets annoying.
- naet 3y agoI think the author is focusing on the wrong thing. They focused on the difference in format, when they should have focused on the compression. Different image processing programs will have different compression even when set to the same number (eg "80"). I think for a truly meaningful comparison you'd need to test a variety of images including full color with busy backgrounds as well as these b&w studio portraits on a smooth gradient type bg, and test a variety of programs like imagemagik, graphicsMagick, sharp, photoshop, whatever cloud offerings, etc. The other issue I see is use case. If you're a professional photographer trying to upload full size full quality photos, maybe just don't compress at all so you know your creative / editing work is completely preserved. That use case is not the average use case of a website displaying a reasonably sized image of reasonable quality. For many situations a significantly smaller image might be worth having a more compressed image, and for many images the compression won't be as noticeable as it is in a full resolution professional studio photo with a large gradient type background.
- urbandw311er 3y agoSo here’s what I don’t get about this post: > this is WebP re-encoding of an already lossy compressed JPEG Author is clearly passionate about imagery and quality, so why are they not re-encoding using the original file rather than a lossy copy?
- sheepshear 3y ago> So, I wondered how bad it was for actual raw photos encoded straight in darktable. Meaning just one step of encoding.
- gunapologist99 3y agoAVIF > webp. (too bad once again Safari lags behind)
- rsingel 3y agoHard to take this seriously with that obnoxious font that draws curlicues connecting letters like s and t.
- EdwardDiego 3y agoI did learn from it that there's a CSS property for ligatures, and the blog has set it to discretionary ligatures. https://developer.mozilla.org/en-US/docs/Web/CSS/font-variant-ligatures https://developer.mozilla.org/en-US/docs/Web/CSS/font-varian...
- wwalexander 3y agoSnarks at Safari for often not being instantly up to date with every rushed “web standard” from Google, then gripes about “Google monkeys” and the issues with…their rushed “web standard”. Pick your poison.
- deleted 3y ago[deleted]
- Unfrozen0688 3y agoI see the background dithering ring on my 1440p cheap 32" monitor that's a few years old now.
- stevage 3y agoBoy that ct ligature is distracting though.
- VoodooJuJu 3y ago>img.webp >vs >img.jpg https://imgur.com/gallery/rdzfp1g https://imgur.com/gallery/rdzfp1g
- __s 3y agoLossless webp is a good alternative to png. Why compare lossless eebp photo to lossy anything? I used to use png everywhere in openetg, so webp's a welcome improvement that's greatly reduced asset size Perhaps the article should be "In defense of JPEG" but that wouldn't get the clicks
- AlienRobot 3y agoimo, the problem isn't that WebP is bad for photos. The problem is that Google's Pagespeed Insights and consequently a lot of resources push WebP to you as a solution for your JPG problems. A lot of people have been duped into reencoding their JPEGs into WebPs for no reason. Also just my personal feelings, but I feel like Google doesn't care about people downloading images or using the internet as a permanent gallery for posterity. They don't care about making each individual image look as good as it can be, so someone can in 10 years visit an almost-defunct website or an abandoned account of some user and just view a photograph as a standalone work. It feels like the use-case they're concerned with are the huge 1200px wide, utterly useless and generally irrelevant stock images they forced everyone to put on their articles when they said AMP articles require an image that big. And of course, with the thumbnails automatically generated from such images. That is, WebP's concern seems to be just about the load on the web server, and it's not thinking about the image as a file (the sort you save on your computer). Then again, this is just my strongly opinionated guess based on nothing but the fact JPG was made before the web became what it is today, and WebP was released after mobile internet access surpassed desktop.
- siddheshgunjal 3y agoAuthor might be right about the gradient shifts in images after conversion, but at the same time, most of the websites are not using such color accurate images everywhere. Some are logos and some are with alpha channel. It is a fact that WebPs are lightweight assets to load on the user side which reduces bandwidth consumption for the user and your server. So use WebP where it's needed to save some loading time and bandwidth and use your preferred format where you want to show images as is. If you're planning to convert your images to WebP in bulk, I wrote a shell script: here's the link: https://medium.com/@siddheshgunjal82/bulk-convert-images-to-webp-82cd105acbc2 https://medium.com/@siddheshgunjal82/bulk-convert-images-to-...
- ksec 3y agoI now hope more people understand why I am pushing for JPEG XL, practically before anyone else on HN ( apart from its authors ). One thing I want to state is that nothing presented here about WebP are new. They have been there since the beginning ( 2010s ). The real problem is, quote: >>So there is a real issue with the design priorities of image algos from tech guys who clearly lack historical and artistic background, and don’t talk to artists And their marketing.
- yossi_peti 3y ago> As a photographer, I care about robustness of the visual output. Which means, as a designer, designing for the worst possible image and taking numerical metrics with a grain of salt. I think it's kind of silly how the author pooh-poohs averages and demands that whoever is working compression algorithms should focus on the worst possible image. If you know anything about information theory, you know that is literally mathematically impossible to make a compression algorithm that always performs well in the worst possible case.
- raajg 3y agoOn my 14in Macbook Pro I CANNOT TELL THE DIFFERENCE AT ALL
- jeroenhd 3y agoThe images inline in the blog are heavily compressed and look about the same. Click through to the actual demo files and the difference becomes obvious. I can see the difference on my LCD monitor from at least six years ago. WebP really struggles with gradients. I wouldn't use lossy WebPs for photography websites. AVIF does a lot better (-25% at no perceivable quality loss), but completely messes up the brightness on my PC for some reason; I think that's a Firefox bug. That's not to say WebP is necessarily a bad format. There are tons of images where it easily beats JPEG without quality degradation, but these images clearly show cases where it isn't. Personally, I use lossless WebP to replace PNGs on websites, thereby maintaining lossless quality without the PNG overhead. Lossy WebPs (and JPEGs) need to be hand-checked, though.
- abrookewood 3y ago"See the posterized ring in the background ?" Nope. I'm looking at this on a 2k 38" ultrawide monitor, comparing the two images at 190% zoom and I have no idea what I am looking at. I literally can't see a point of difference between them at all. I know my eyes aren't great, but is the difference really that noticeable? What am I missing?
- mediumsmart 3y agoSo true. Still have to find out how to avoid color bleach when converting to webp.
- skhameneh 3y agoI first browsed the article on mobile without adjusting my display brightness (generally set to low for eye comfort) and it took significant effort to see the issues. I then turned my brightness to 50% and immediately saw browser rendering issues the author may not have experienced themselves. The differences in various contexts are massive. It may be useful to take photos of my screen rendering the various artifacts at varied brightness. There are clearly some rendering optimizations (in different contexts) that create some horrible artifacts.