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.
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.)
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.
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.
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
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.
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.
>> 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.
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.
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.
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.
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.
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.
Correct, but this is the workflow that the engineers behind WebP recommend, so I think it's entirely fair to pick on it.
> Anyway, the rant elevated my knowledge very little. It was more like anti knowledge.
Then perhaps you weren't the target audience. I'm not a photographer, and the rant has offered me a little bit more perspective.
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.