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.

So I don't think display quality really is the problem here. Maybe the drivers, or post-processing filters. Or maybe everyone doesn't have an eye for this. I have an interest in image processing, and that's the kind of detail one tends to notice with experience. The author of the article is undoubtedly more experienced than me and noticing these details may even be part of his job. He most likely will be able to notice these problems on crappy monitors, as well as telling you in which way that monitor is crap.

Generally though i would expect wide gaumet monitors to make a significant difference for these types of artifacts

The examples are just bad. If you want to show something, screenshot and enlarge it to show the artifacts.

One might argue that if you need to enlarge it to see the artifacts, then the artifacts aren't perceptible enough and the codec is already good enough for the use case.

WebP image gradients just looked broken (posterized) except the lossless one, which was (obviously) perfect.

The difference is in color around the edges of the picture in the background change noticeably on a non-fullscreen image on my Android 12 device.

Yes! Where's the red underlines and diffs? I can see the background banding, but the foreground looks the same at a glance except that some of them look ambiguously "off" in ways that could just be placebo.

You'd think a visual artist would be more interested in visual communication and not just a wall of text with un-annotated photos.

After that it was pretty obvious what the author is talking about.

Wait... I agree for JPG but if you use lossless WEBP instead of PNG, isn't it simply the same pixels, just with a file about 30% smaller than the corresponding PNG file? (and 15% smaller compared to already heavily optimized PNG files like when using zopfli/optipng/etc.).

Isn't the "lossless" in "lossless WEBP" actually lossless when converting a PNG file to WEBP?

FWIW when you convert losslessly a PNG to WEBP, then decompress the WEBP back to a PNG file, then convert again that PNG back to a WEBP file, you get the exact same lossless WEBP file. It's also the same WEBP you get when you encode losslessly from either a PNG or that same PNG but "crushed" with a PNG optimizer.

On the technical side, webp support still isn't like png. Tried dragging a webp into Google Slides just now, got "unsupported image type," which is ironic. I'll try again in like 10 years.

Oh that's a good point.

I see lossless WEBP mostly as a way to save bandwith where PNG would have been used. If you've got a pipeline where, anyway, you already "crush" your PNG file, you may as well also generate a lossless WEBP file and serve that: all browsers support it. And you can fall back on the optimized PNG should the browser not support WEBP.

I mean: I use WEBP, but only lossless WEBP, as a replacement for PNG when I'd serve PNG files to browsers.

But for that one usecase: showing a PNG file in a webpage, I don't see that many downsides to lossless WEBP. It saves bandwith.

Also, if users download your images and use them elsewhere, webp will still be more annoying for them. Though it's not very common that you want them doing that anyway.

Any updated (modern) browser should be able to see webp just fine, I'd rather just serve it without a backup plan if I'm planning to have webp in my website.

There is a difference in the gradients of color. One hasn't the guy looking backlit and one doesn't.

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.

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.

https://computers.scorptec.com.au/computer/Oled-Monitor

They've been around for years.

PC monitors have been improving constantly with high refresh rates, local dimming HDR + 10 bit color, adaptive sync, OLED and more.

https://www.displayninja.com/oled-monitor-list/

Mainly targeted towards the gaming market at the moment.

- Framerate - Response time - Adaptive sync - (how prone to burn-in is OLED? Monitors often have way more static images to TVs)

I assume combing these all might just make it more expensive than just individually each feature

The much more complicated electronics plus Supply & Demand. Demand for TVs should be way higher then for high end monitors.

I just looked at the first two images of the post.

First on two mid end LCDs: one ASUS IPS from this year and one BenQ TN from 2012, both 24" 1920x1080 (~91 DPI). The difference between the images is clear on both.

And before posting, to make sure, I pulled out a 15" 1024x768 (~85 DPI: basically the same) NEC TN LCD from 2002. And a NEC CRT roughly 15" viewable 1024x768 from 1998. Both on VGA connectors (so there is the typical noise from that, which still doesn't cover up the posterization). The difference between the images is clear on both.

All monitors viewed from 3' away.

People are simply accommodated to poor image quality, including posterization. AAA FPS video games display it on static art backgrounds in the loading menu, and I can never tell if they are intended. Show them a 240Hz monitor with 30ms input lag and 5 frames of overshoot artifacts and viewing angles worse than 1998, and they'll be wowed.

The "issue" is that monitors last a LONG time. And thats good. We dont touch them or fiddle with them. They tend to just work. Phones and shit we keep dropping and breaking, then the battery gets bad.

Also for gaming you may even want 1080p 200hz monitor for high refresh rate and FPS over pixel density.

They really don't...

Recently I’ve been dabbling in HDR video, but I realised that the exercise is futile because I can’t send the results to anyone — unless they’re using an Apple device.

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/20...

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/20... (full size lossless WebP image) looks fine, but inline version of the same image 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/20... lossy-noise.jpg (216 kB JPEG)

https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20... (150 kB 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.

I played around with online optimizers and IrfanView which I had locally. IrfanView got the results they did, no matter what else I tuned, obvious degradation at 90. Online optimizers were not even comparable in how bad they were.

edit: I found Squoosh [0], which has WebP V2 compression marked as unstable. It’s far better, half the size of JPEG 90, but it’s still degraded in comparison. Also, it saves as wp2 file, which neither Chrome nor FF support natively.

[0]: https://squoosh.app/editor

He's re-encoding the JPEG compressed images. That is a huge mistake.

> 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.

Tried it with a Windows laptop connected to a Samsung LS32A800 32" 4k display. Laptop has factory default settings. Chrome 120. The monitor is pretty low end for a 4k model.

Monitor's picture settings: Custom, brightness 81, contrast 75, sharpness 60, gamma mode1 and response time fastest.

Switched between those three "Edit 2" images blindly, yet the issues are obvious also on this combination.

The JPEG version looks better compared to WebP ones. (Also, this goes against my prior general assumptions about JPEG vs WebP quality.)

One easy difference to spot is the background in this pair is posterized (https://en.wikipedia.org/wiki/Posterization) in webp but not in jpg:

https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20...

https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20...

I didn't know the word "posterization", so I'd describe this (slightly?) more simply as a stepped gradient instead of a smooth gradient.

And many people commented the same. These simply aren't small differences.

People who cannot see the differences or who only see them after taking a close look should realize something: there are many people for whom the differences are going to be immediately obvious.

That's one possible conclusion. Another is that some people are overstating how obvious it is. I don't mean this as an insult - there's plenty of cases where people's stated perceptions and preferences disappear when tested under strict conditions (hello Audiophiles).

So - it's not immediately obvious whether claims such as yours are trustworthy.

(for the record I can see the difference but it's fairly subtle on my screen)

Second is how much each person's brain interpolates. I got used to those visual artifacts on the web in the early 90s so my brain started doing its own interpolation. It took reading the entire article and flipping tabs back and forth to compare images before I noticed the difference. Now I can't unsee it in other images that I recently converted to webp for a project.

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

For the second image, I opened the jpeg 90 [1] and webp 90 [2] versions. Comparing those two, there are clear banding issues to the right of the neck. Slightly less visible are the darker bands circling around the whole image, though still noticeable if you know where to look.

Comparing the jpeg 90 version with either webp lossless, jpeg 100 or jpeg 95, I can spot some very slight banding in the jpeg 90 version just to the right of the neck. Very difficult to spot though without zooming in.

[1] https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20...

[2] https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20...

I wonder if the author's issue is due to the author using a Mac. Back when I was at Google working on VR images, my work machine was a Macbook and my home machine was a normal Windows desktop. I realized that images looked worse on my laptop's screen because the native resolution of the display hardware was something like 4000 (numbers made up because I don't remember the specs) but the display was set to 3000. So OSX would incorrectly rescale the image using the wrong gamma curves. Since I was trying to calibrate VR headsets, I spent way too much time looking at gamma test images like https://www.epaperpress.com/monitorcal/gamma.html where a high res pure black + pure white grid is shown next to a set of grays. That was how I realized that my Mac was incorrectly resizing the graphics without being properly gamma aware. I also realized that if I set the OS resolution to 2000, it would use nearest neighbor instead of bilinear filtering and the gamma issue would go away. My Windows desktop had the OS running at the native resolution of the display so this wasn't an issue there. This also wasn't an issue if I had an external monitor hooked up to the Mac and set to its native resolution.

Apple users tend to say "it just works" which is true 90% of the time. But there are cases like this where it doesn't "just work" and there was no easy way to force the OS to run at its native resolution on that specific laptop.

Edit: I tested with the second set of images (the upper body shot) and the problems with the gradient are visible there. But I still can't see a different when quickly flipping through the first part of images on my properly calibrated native-resolution monitor. I _can_ see some banding on one of my monitors that was intentionally miscalibrated so that I could read text better.

https://bugs.chromium.org/p/chromium/issues/detail?id=44872

Total aside, y'know how people do things like make their smartphones greyscale (or at least mute the colors a bit) to reduce smartphone addiction? It wouldn't surprise me if these over-saturated colors were part of why Chrome got so popular so fast...

It is not, since I tested positive on Linux. What post processing would any OS even do on an image when you view it in a new tab as one is meant to do for this tutorial?

It's not so easy to see if the browser zooms the image, so make sure to open the image and set zoom to 100%. I also need to keep my face fairly close to my screen (12" 1920×1080, so not that large).

That said, in the context of showing off your photography I can understand considering these kind of artifacts undesirable, even though they're perfectly fine for a lot of other uses. On my own website I spent quite some time downgrading my mugshot to be as small as possible without too many artifacts – it's now 4.9K in WebP, vs. 9.2K in JPEG before. Maybe that was a tad obsessive though...

I do think the author doesn't quite appreciate that most people are not photographers, and that for most images quality doesn't actually matter all that much.

Different operating systems and monitors have different default gamma curves for rendering brightness and black levels. Monitors are most likely either uncalibrated, or _can't be calibrated_ to render a greyscale with just 64 brightness levels distinctly.

TFA is calling attention to "posterization" in their portrait backgrounds. They expected the grey background to have a smooth gradient, but, depending on your monitor, you should see visual jagged stair-steps between different grey levels.

When an image uses a color palette that's insufficiently variable to render the original image colors with high fidelity, that's "posterization."

(I paid for my college doing high-end prepress and digital image services, and got to work with a ton of really talented photographers who helped me see what they were seeing)

4k Dell monitor, Safari on a Mac.

There is definitely something changing though, because if I open each in Preview, switch Preview to full screen, set the view to be actual size, and take a full screen screenshot, the screenshot for the WebP image is 14% smaller than the one for the JPEG.

If I use screen zoom to go way in and then flip between the two images I can finally see some changes. The JPEG background has more small scale variation in shade. In the hair there are some white streaks that aren't quite as long in the WebP. Lots of small changes in the shirt, but it is about 50/50 whether or not any given difference there looks better in the JPEG or the WebP.

My takeaway as a non-photographer is: "different tools for different uses". If you're posting photography where image quality matters then use JPEG or another format that you think displays the image best. If you're writing a blog post with screenshots or other images where minute quality doesn't matter that much then use WebP.

[1]: https://caniuse.com/jpegxl

Using mozjpeg (SPEG), or openjpeg (JPEG 2000) or cwebp, and I want to get even close (in bpp) to what cjxl does on the default I have to use different settings for b&w vs color and line-art vs photos.

There are clear bands of various shades of grey that circle out of the brighter areas behind the face and from the mid-right edge. They appear to join about two thirds from the middle to the right edge. That artifacting is most notable at full size, but is still visible on the smaller size on the web page.

>> 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.

Photography portfolios are the one use case where having gigantic JPEG 90 images might make sense I suppose. Although everyone is going to get annoyed at your loading times.

See my post lower in this thread.

https://news.ycombinator.com/item?id=38656046

That's the entire point of this article. Rather than picking a dozen different kinds of images at random, it considers the problem within the very specific context of actual photographs, made by actual professional photographers, with specific (yet not uncommon) artistic/stylistic choices.

It's like showing why an audio codec sucks for cellos. Yes, there is going to be a hundred other things you may want to record (like a podcast, a rock band, etc), and most of them will not be cellos, but still that doesn't change the fact that the codec sucks for cellos.

I guess the more technically interesting POV would be to suggest a solution. Probably he should use the black and white profile with HEIF and serve the WebP only to search engines, using the modern image tag.

Or, you could put Y information in the unused UV plane for WebP. I guess you could also decompress the original JPEGs better for the purpose of conversion. While not for him, it takes about 100 lines of JavaScript to author a Mobile Safari-compatible image bitstream, which is very little. The MediaCodecs API is great.

Anyway, the rant elevated my knowledge very little. It was more like anti knowledge. Like if you were to integrate the rant into an LLM, it would produce worse recommendations.

There's definitely very ugly "banding" going on in the gradients on the WebP versions i say as someone who's worked extensively with UX and interfaces.

I'm on a M2 Macbook Air.

I've read all the comments, and zoomed way in. I can see it on one of the pairs if I pay attention, but on most of them, I still am not sure how to even look for the difference.

Last time I had a vision check, I got a 20/15, which is supposed to be better than "normal". It may have declined since then.

I don't think it's a monitor or eyesight thing. I think I don't know "how" to look for the effect I'm supposed to be seeing.

While people might not be able to tell the difference between $50 and $5000 speaker cables, anybody will be able to the hear the difference between $50 and $5000 speakers.

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/cm...

[2] https://storage.googleapis.com/demos.webmproject.org/webp/cm...

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

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?

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.

His font choice is terrible for my legibility. Maybe for others it's great. But it made the already difficult article that much harder to read. And I like this topic. I already seriously question his sense of what is reasonable and good and for what purpose. His purposes are so alien to mine that his opinion ends up being pretty irrelevant to mine. I wish him well with his.

I can't see the things he's pointing out in the images, and I tried and tried.

I use webp extensively, there have been zero complaints from users about the images. But I don't make art sites. I make software people use to get stuff done. I don't transfer images above maybe 50-80k. Art, aside from modest marketing, is most definitely not the point.

There may be a connection [1].

If we assume some of the people designing codecs, that he curses in this piece, end up reading it, he may simply have wanted to make sure they do remember. ;)

[1] https://hbr.org/2012/03/hard-to-read-fonts-promote-better-re...

It reminds me of how sometimes you see a huge billboard hideously strong 10 foot wide JPEG compression artifacts. It was someone's job to make those, too.

You keep bringing this up. I don't really care. Someone designing a codec may have put this apparent problem case on the don't-care list as well. I would be in general agreement with the designer's priorities for a reasonable web codec.

I have, with some care, selected webp as a general codec for web use on most of my sites. Nobody is complaining, and my page weights and development speed is improved. I don't have to fret between png+transparency and jpg to minimize asset size while maintaining it's usability. I just use webp and most of the time it's a size/speed win with good enough quality.

Not every codec needs to be artist and photographer approved.

> WebP re-encoding of an already lossy compressed JPEG

So... all this shows nothing. Is webp worse than jpeg? Not addressed. He re-encoded jpeg to webp and it somehow didn't magically cure the compression artifacts he's seeing! Who coulda thunk!

Any comparison starts with taking the originals, encoding to jpeg and webp, and comparing that. Or he could repeatedly encode original -> jpeg -> jpeg and compare that to what he has, which is original -> jpeg -> webp

I was able to see it without full screening.

Look at the man with his face screwed up. Look at the edges of his shirt near his shoulders.

In the pictures that had bad image quality, there is a sort of glow around his shoulders, as if they are backlit.

In the pictures that had a good image quality, The gradient was smooth. There was no backlit glow around his shoulders; it just looked like a smooth gradient background image.

To be clear, I'm not a photographer. I'm a DevOps engineer. The last time I professionally wrote a line of JavaScript was at least 11 years ago.

It's easy enough to see.

[1] https://news.ycombinator.com/item?id=38653224

I did the same comparison the author did when WebP came out but used an optimized JPEG encoder and found the same conclusion: when you produced subjectively equivalent images, the savings were more like -10% to +15% and for web sites which didn’t get Google-scale traffic the performance impact was negative since it made caching less effective and you had to support an entire new toolchain.

There isn't a codec pair in this world where you can't make a cherry picked comparison where one of them is worse (I've done plenty of those).

https://calendar.perfplanet.com/2014/mozjpeg-3-0/

Even a decade later, however, Google repeats the 25-34% claim and their performance tools tell developers they should use a modern format, which by sheer coincidence means the one they invented rather than the best ones on the market.

A large chunk of the hn commentors are debating over banding they can or can't see in a best case scenario WEBP image. The reality is the bulk of the WEBP images look horrible, something I've started to really notice only recently. Of course, you can "clean" the images by using different generative upscaling processes now, which is pretty ironic how much electricity we are using because someone wanted to save 45kb.

Also this reminds me a lot about GIFs being converted to JPEGs. 25~ years ago there was a lot of nice, clean GIF screenshots (256 colors was all you needed) that got destroyed by JPEG.

Google tells developers to use WEBP but has no problem serving petabytes of video ads no one wants to watch!

What would make sense is choosing safe settings for compressing new photos in the new format.

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.

Disk space is cheap. It's most likely not worth the 20% compression to lose your original images (and possibly lose metadata as well--it's quite hard to robustly retain all vendor-specific MakerNotes, for example).

Also if you decide to forgo the reversibility you can get a bit more out of it as JXL is actually a superset of JPEG, so it can read the JPEG stream and convert it to JXL without complete recompression - it will just use more efficient structure of JXL and much more efficient (ANS vs. Huffman) entropy encoding. The additional savings compared to the reversible mode aren't big however.

> 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.

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.

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.

It's artifacts made in the background of the image that this poster is complaining about.

fascinating how perception is different.

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.

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...

These problems would go away with 10-bit AIUI. AVIF supports 10 bit but WebP does not.

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.

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?

I thought the loop filter was supposed to help with this though.

Webp really doesnt have a banding issue unless you convert jpeg or display purely grayscale content.

Let's cut our losses, ditch webp and move to jxl.

In what way?

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?

It is not honest to say "use my compression algorithm, it is better" and then, when people point out that it is actually worse, to say "well if you care about quality, you should not compress anyway". It doesn't make the algorithm any better.

It can also be an issue if a client asks for WebP. Do you give in and deliver a lower quality image and allow your art to be displayed in a degraded manner? Losing future clients who think your photos look bad. Or refuse out of dignity and lose the current client?

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.

> Bandwidth is cheap.

Labour is not. Just leave your jpegs as-is!

https://developer.mozilla.org/en-US/docs/Web/CSS/font-varian...

> 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?

I wonder if the author took that into consideration.

As a video codec developer I was a little sad about that, actually. I had to start looking closer to see problems.

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.

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.)

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-mozj... [2] https://github.com/mozilla/mozjpeg

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.

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.

Edit: i think maybe my browser is scaling the photo which is adding artifacts.

Edit2: 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.

This almost feels like a troll post.

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-...

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

(GitHub works if you rename it to a .png or .jpg file, but it's a hack).

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.

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?

Browsers like Chrome like to associate themselves with WebP for some weird reason, but file explorers, image editors, album viewers, and everything else support WebP just fine.

I don't know what you use, but I use Nautilus, Gnome Image Viewer, and Pinta/GIMP. Perhaps the three years of improved software support make the difference?

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.

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.

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.