Your 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.
It'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.
very 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.
Like 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.
It'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.
I 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.
JPEG 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.
I don't know, I liked it on its merits before. I'm sure others did too.
Seamless legacy support is very valuable. And it still performs pretty well compared to competitors. I think it's a good default for a lossy network format.
Firefox nightly has support according to https://jpegxl.io/tutorials/firefox/, of course you're wrong that nobody is attacking FF, but given its tiny niche compared to Chrome it's obviously much less consequential, so the volume attacks on Chrome would dwarf anything FF-related (Safari was also criticized, and they've recently added support)
> after significant time of noone using the format
That's also fasle, this is too new of a format for any significant time of no use to materialize, besides, requiring flags that vast majority of users will not enable is a huge factor limiting widespread use
The support was never complete to begin with, so the removal wasn't due to nobody using it. Some rivalry between different teams inside Google is more likely.
What a shit take. JXL did have plenty favorable responses on HN before Google removed it for reasons that they never applied to their own formats. And FF did get plenty of complaints for not supporting JXL but those are often shut down with the opposite variant of your take.
As I work with codecs I've been following the situation quite closely and the attention to XL was pretty much zero until Google decided to not support it.
Moreover, this whole topic is about a comparison over a SINGLE IMAGE. Anyone who ever came close to codecs would immediately dismiss this as ridiculous. Yet here we are.
I will respond to you since you posted about this so called "SINGLE IMAGE" three times in this post already.
Ackchually, the blog post contains a comparison over TWO IMAGEs. But since you work with codecs, surely you understand that the blog post is complaining about how WebP interacts with gradients in general and not just about the specific images in the blog post.
JXL was getting plenty of attention before the Chrome debacle. Of course it was less than WebP and AVIF but JXL wasn't getting pushed or championed by anyone (other than Cloudinary I think) so JXL didn't have the marketing powers the others had.
To make a conclusion about how a codec handles image features you need to to quantitative comparison across a big enough data set to make conclusions about any kind of generalized quality.
This goes triple for modern codecs like JPEG XL, VP8/9, AV1/AVIF, etc. because they deliberately make tradeoffs when compressing based on how the image will SEEM to people, not how pixel correct it is. Note just how many people say they barely notice a problem - this is where WebP made the tradeoff. JPEG did it elsewhere (e.g. text).
Cherry-picking a single image is useful only for fanboy screeching.
> To make a conclusion about how a codec handles image features you need to to quantitative comparison across a big enough data set to make conclusions about any kind of generalized quality.
>
> Cherry-picking a single image is useful only for fanboy screeching.
Do you really expect a photographer to prepare a quantitative codec comparison benchmark? All they have is anecdotal evidence, and I think it is fair for them to criticize and make decision based off of their own anecdotal evidence.
> This goes triple for modern codecs like JPEG XL, VP8/9, AV1/AVIF, etc. because they deliberately make tradeoffs when compressing based on how the image will SEEM to people, not how pixel correct it is. Note just how many people say they barely notice a problem - this is where WebP made the tradeoff. JPEG did it elsewhere (e.g. text).
No one is going to sit here and claim that WebP performs better on all images or JPEG performs better on all images. Obviously there is going to be some kind of tradeoff.
TBH, my gripe with WebP is not that it's worse than JPEG. IMO it is in fact better than JPEG in most cases.
My problem is that it is only an incremental improvement over JPEGs. We are breaking compatibility with the universal image formats and we get the following benefits:
- 15-25% better compression
- animation
- transparency
- lossless compression
On the other hand, we could break compatibility, adopt JXL and get the following benefits:
- lossy compression on par with WebP
- animation
- transparency
- lossless compression that is marginally better than WebP
- actually kinda not break backwards compatibility because you can convert JPEG -> JXL losslessly
- enhanced colorspace support
- progressive decoding
- very fast decode speed
- support for ultra-large images
Adopting WebP would be great. But why adopt WebP when instead you can adopt JXL which is superior in terms of features and on par in terms of compression?
The author explains why thinking in terms of averages "across a big enough data set" isn't enough.
>Call me crazy, but I don’t give a shit about averages. For a gaussian "normal" process, probabilities say half of your sample will be above and half will be below the average (which is also the median in a gaussian distribution). If we designed cars for the average load they would have to sustain, it means we would kill about half of the customers. Instead, we design cars for the worst foreseeable scenario, add a safety factor on top, and they still kill a fair amount of them, but a lot fewer than in the past. [...]
>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. And that whole WebP hype is unjustified, in this regard. It surely performs well in well chosen examples, no doubt. The question is : what happens when it doesn’t ? I can’t fine-tune the WebP quality for each individual image on my website, that’s time consuming and WordPress doesn’t even allow that. I can’t have a portfolio of pictures with even 25 % posterized backgrounds either, the whole point of a portfolio is to showcase your skills and results, not to take a wild guess on the compression performance of your image backend. Average won’t do, it’s simply not good enough.
JPEG XL research, development and maintenance happened/happens mostly at Google Research. Chrome devs removed it from Chrome, but it is still a codec built mostly by Google.
JPEG may be fast enough for all of that, but is that also true for these newer ones? Decoding the .heic pictures from my old iPhone takes 1-2 seconds on my laptop(!!) As near as I could find out that's because the iPhones and macBooks and such all have hardware support for that, and my ThinkPad doesn't.
According to the article I've linked above, JXL has twice as many points (don't remember actual speed comparison numbers) in the decoding speed comparison, and is also more parallelizable
To be honest I find that a little bit too vague to be useful.
I can't find clear numbers on this, but on e.g. [1] I read it's not too fast, but I didn't try to reproduce their results, and according to some comments a number of factors can greatly affect performance.
AVIF kinda needs hardware decoding, because otherwise it’s considerably more expensive than the traditional codecs. Even with hardware decoding, I’m not sure if AVIF is actually faster/chaper—compared in https://jpegxl.io/articles/faq/#%E2%8F%A9speedfeatures, “AVIF” takes 7× as long as libjpeg-turbo to decode, and I don’t believe hardware encoders tend to bring that big a performance difference over software, but I’m really not sure.
AVIF reduces the amount of traffic required, but will tend to consume more power. This is the general compression tradeoff.
(Other formats often have hardware decoding support too, incidentally. But a lot of the time they’re ignored as too much effort to integrate, or buggy, or something.)
> AVIF reduces the amount of traffic required, but will tend to consume more power. This is the general compression tradeoff.
Mobile devices on battery are connected wirelessly, so traffic consumes a lot of power. The faster the radio can power back down the better, so CPU time is usually a worthwhile trade.
You kind of ignore the case where almost every device is going to do AV1 hardware decoding (which very much appears to be the trend), if that is significantly faster/cheaper battery wise then AV1 still has a big advantage. Comparing single-core software decoding speed seems like a benchmark designed to make JXL look good, not something that actually matters.
> AVIF reduces the amount of traffic required, but will tend to consume more power. This is the general compression tradeoff.
Again, you seem to be ignoring hardware decoding. Dedicated silicon can be many magnitudes more efficient than doing something in software. To take an extreme example with a ton of effort into the efficiency: look at mining bitcoin on a CPU vs an ASIC. I'm not saying the difference will be that big, but it may well be worthwhile.
As to buggy/too much effort/cost of hardware, that's precisely why it makes sense to piggy-back on AV1, a format that already has a lot of incentive to implement in hardware, and the work already done to make it work well. You need that kind of compression for video, and people are putting in the effort to make it work well, so AVIF gets that effectively for free.
Video codecs as used for images also have big disadvantages since they weren't designed for many picture-focused workflows
> only matters during the transitional period.
which can be decades, so this matters a lot
> it seems to massively outweigh any advantage JXL has
Since you haven't listed any other advantages outside of downplaying the compatibility during transition, so that's hard to weigh. Also, it's not like, if we're talking about the whole lifetime, hardware couldn't add support
The advantage is increased battery life and performance, which is way more important to most end users than any of the advantages I've seen for JXL. People are not pixel-peeping different images to compare quality, they are annoyed when their battery dies.
As to hardware adding support for JXL, that seems extremely unlikely: image decoding is less impactful than video decoding, and the cost of adding custom decoding silicon to a chip is very high, as is adding support to software for that hardware. Being able to piggy-back on the work already done for video meaning you get that stuff for free makes it way more viable. AV1 decoding is already out there in virtually every new device, and rolling out hardware support is very slow, it's massively ahead in that respect.
Jpeg-XL is light enough to not require hardware support.
Did you tried to transcode a PNG to avif? It's painful. Not the case with Jpeg XL.
Meanwhile I urge you to read this article. Jpeg XL has way more features than avif.
Hardware decoding can mean less battery usage, which is very big for end users.
I just don't think any of those features matter as much a battery life, most of them are about encoding speed which just seems wildly unimportant to me: encoding may be more work, but generally you view images far more than you make them, and admins and creators are in a better position to spend the time/effort to encode something, and hardware encoding may well end up making it a non-issue anyway.
People are out there running `zopflipng` and the like to try and get better sizes at the cost of more work at encode time, so it seems like that priority isn't just me.
I have problems w/ AVIF that are like the ones that guy has with WebP. Please don’t post a link to the F1 car sample image because I think that image sucks (e.g. a reflection from a surface near the driver’s head gets replaced with a different but plausible reflection.)
JXL is an image codec - it can afford to be less efficient (it's not! Other way around, rather) and not be hardware accelerated as its typical use case is not to present 30-60 images per second like in a video codec, it will not affect the battery life of a device in any meaningful way. Also, AV1 hardware decoding is far, far from ubiquitous so many users would not benefit at all from it.
But - back to JXL vs WebP:
I think Google had genuinely good intentions with WebP, but the effort was somewhat ruined by their culture: they relied too heavily on metrics which aren't always a good proxy for image quality, because humans looking at pictures don't scale, and Google does things that scale. We now have a codec with good metrics, but looks poor.
It's based on the intraframe coding of the VP8 format - a video codec - and I think it suffers from that. Looks OK in a video, but bad in stills where you have more time to notice its warts
Most importantly, it's almost always produced by recompressing a jpeg and causing a generation loss. I don't know of any phone or camera which produces native WebP (maybe some recent pixels? Dunno), and any professional device used in RAW mode usually implies the participation of someone who cares about the finished product and will not want WebP (and will resent when it's used without their consent by webmasters wishing to tick a box in pagespeed, as the author mentions). JXL has a lossless recompression mode in which it just replaces the Huffmann compression stage of an existing JPEG with something more modern, and this results in a pixel-accurate image which is 20% smaller than the original file - this already eat WebP's claimed space saving, and then some, with no generation loss. Based on this fact alone, there shouldn't even be a discussion.
....but let's have a discussion anyway. A JPEG -> JXL lossless recompression isn't conceptually new - Stuffit (remember them?) did it in 2005, with not enough traction sadly (unsurprisingly since there were patents and licensing costs). Basically it's _still_ a JPEG - if you decompress the final stage of a JPEG, and the final stage of a JXL (or a .SIF), you get the exact same bytestream. While yet another amazing testament of JPEG's longevity and relevance, it is also concerning: How could Google do worse than that??? When basically rezipping (with a modern algo) the existing DCT macroblock bytestream of a 30 year old codec beats your new codec, you should just trash it.
Edit:
...but I forgot to answer your question. Why is JXL viewed so favorably on HN? Because it doesn't suck, and we're sad that Google decided to be a roadblock, and pushing for their own thing, which instead sucks. At least AVIF is way better than WebP, even though it's a monster, computationally.
What you're ignoring is that WebP is from the year 2010. JPEG XL is from 2022. Incidentally, JPEG XL is also a Google project, making your ranting about how bad they're at image formats pretty funny.
Hi!
I'm aware that JXL partially originates from Google's PIK - and also Brunsli??, but I had indeed forgotten that WebP started in 2010, wow, 13 years old already.
I'll therefore correct my statement: "How could Google do worse than that??? When basically rezipping (with a modern algo) the existing DCT macroblock bytestream of a 18 year old codec beats your new codec, you should just trash it."
Also, Stuffit's SIF format is still 5 years prior to 2010 so that point stands.
I didn't compare with stuffit. If it's better than JXL recompression, perhaps they had put more focus on lossless recompression. Perhaps they had less realtime constraints in decoding speed.
Google haven’t explicitly decided to block adoption of JPEG XL. They removed an incomplete implementation from Chromium which had never been shipped, because it was a maintenance burden and they weren’t ready to commit to supporting it. That’s quite a different thing. It may indicate a broader strategic direction, but it doesn’t necessarily.
That charitable interpretation would have been okay unless the Chrome team (yes, "Google" is not a single entity here) tried to publish a faulty benchmark [1] that has been thoroughly criticized [2] which never has been answered so far.
Yeah, I'm quite hopeful that this is one where the developer backlash will cause a U-turn. I suspect it was seen as something that most people didn't care about, and now that it's clear that they do then likely something will be done about. I can't see any reason why Google would be strongly against it's inclusion.
The called it technically inferior based on opinions. They didn't do a thorough technical review, and why would they, they have webp. This was absolutely a strategical thing, it's naive to think it isn't.
Agreed. It's especially infuriating that their arguments against jxl would have applied to webp too (even more so) but for some reason that was pushed trough (as were other Google formats).
Seems Safari has it enabled by default now, and Apple has support at the OS level. Firefox at least has it under a flag. Chrome team are the odd ones out here.
I 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:
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
I 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.
the second image and the third image are half resolution of the other, yeah some posterization is visible in Shoot-Antoine-0044-_DSC0085-lossless-1200x675.webp, but it's half resolution and he purposefully added a high frequency noise for his test then averaged the noise point trough resizing, and well, of course it's blurry.
> I wonder if there's some issue with the WebP encoder (or the settings) he is using?
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.)
> 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.
It's not, it's just that people who spend thousands of dollars and hours into photography are more susceptible to care. Same with music, most people are fine with $15 earphones while musicians or music enthusiasts will find them disgusting.
Music is probably a bad example of your point, as that field is famous for audiophiles insisting they can hear a difference for various things only for them not being able to tell the difference in a double blind test.
Just because there are some 'extreme' weirdos in the audiophile space, doesn't mean that there is no difference between cheap and expensive equipment.
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.
I can readily tell the difference on the guy's forehead. The webp version has less dynamic and looks like a big white spot, while jpeg has more shades.
I did the same, and it took me a long time to spot it, but in the upper-right corner you see circles in the WebP version. It's outside the centre of attention, so it's not that obvious. Actually, it wasn't until I saw the second picture and knew what to look for that I spotted this in the first picture.
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.
The first picture is very hard to spot imo. I had to zoom in a bit to spot it initially. You'll see the "blockiness" is slightly worse in the webp version. (Left side of the image, head height)
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.
I thought it was pretty clear. I'm not even running any monitor/computer setup. The light behind her is clearly different, it almost looks like a photo with different lighting.
I can see a difference in the gradients, but in practical use on the average website does that even matter?
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.
You either have a bad screen or limited eyesight, it's quite funny to me that this is the most upvoted comment.
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 looking at an LG UltraFine, which as far as I know, is not a bad screen, but I can't really tell.
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.
At 50 y/o my eyesight began to fail and yet the differences in the pictures are freaking obvious. As in: it's impossible to not see how huge the differences are.
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.
> 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)
It's definitely an objective phenomenon but there's two factors at play: first is the monitor quality. I have two monitors of the same model number but made in different years with obviously different panels (color reproduction is all over the place between them), and the banding is obvious in one monitor but not the other. I can drag the window between screens and it disappears. On my iPhone, it's very obvious.
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.
If I view the full images of the first two in two Chrome tabs, two Firefox tabs, or download them and open then both in Preview on a 27" 5k iMac and flip back and forth between the two I see nothing changing.
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.
This whole thread feels like one of those "I can tell the difference between an MP3 encoded at 320 kbit/s and one encoded at 256 kbit/s!" audiophile threads. Yes, there are probably people out there with well-calibrated ears who can, but I am sure not one of them. FWIW I have a 27" 5k iMac and can't even remotely see any difference between the images.
There's a clear difference between the JPEG and WEBP versions. Especially on the background on the right of the man.
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.
Lots of replies here saying either: "I can't see the difference" or "Wow the difference is stark".
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.
JPEG XL is clearly superior in almost all contexts, but Google killed it and then Apple is trying to support it now. Unless Google reverses its stance though it will stay dead.
The thing that I like the best about jxl is how consistent the reference encoder is. If I need to compress an entire directory of images, cxjl -d 1.0 will generate good looking images at a pretty darn small size.
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.
The author is complaining about the consequences of recompressing images, which are also black and white and have a huge gradient background, and also, the post is full of flaws. I don’t know, Hacker News is better as less of a Hacker Rants.
> which are also black and white and have a huge gradient background
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.
The author just makes a ton of mistakes. Many photographers competently shoot and store RAW, and many know better than to mass convert low quality JPEGs to WebP. It’s HIS work, he can choose to make as few or as many mistakes with presenting it as possible. So I don’t think he’s representative of most photographers. It’s a technical discipline.
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.
I don't see any difference either on Windows on either of my monitors.
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.
It could also be a browser issue implementing webp. There's a decade-old bug in Chrome, where they're using the wrong color profile for CSS, so colors are brighter than in other browsers. It's extreme enough that one of the designers I worked with spotted it in passing just glancing at my Firefox window, which led down a rabbit hole finding the bug report.
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...
> I wonder if the author's issue is due to the author using a Mac.
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?
> I 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.
For clarity if anyone is still confused, on Wikipedia's example image, look at the snakes's shadow - that's what's happening to the background in the blog's image.
I didn't know the word "posterization", so I'd describe this (slightly?) more simply as a stepped gradient instead of a smooth gradient.
The same image rendered with different os/hardware will almost always look different.
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)
I 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.
Interesting 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.
U+FB06 (LATIN SMALL LIGATURE ST) does display the same as the obnoxious ligature in the article if you have the right font. I actually used that for the "st" in the word "still" in my comment above.
In the HN comment editor it is the same as in the article, with that stupid curve connecting the s and t.
In the rendered comment in Chrome, Firefox, and Safari on my Mac it is using for regular comment text some font where the s and t are joined much less obtrusively. In fact at first I thought HN was replacing the U+FB06 on output with separate s and t. E.g., these two look very similar for me: still still.
For rendered code blocks on Safari and Chrome it is using the font that has the curve. On Firefox it does not have the curves. Here is a code block example:
Very small, curly hairs... hmm. (I might have thought the same thing while reading this on the toilet... so you can imagine the extra layer of credibility that afforded.)
It's how English was written in the "olden times". At that time, little flairs (such as ligatures) were pretty common, and were very fanciful. Some simpler ligatures (like ff) survive today, but embellished ones (like ct) were toned down. It's just a stylistic choice to draw them one way or another, but it's jarring to see the fancier ones in "modern" texts because we're used to the simpler styles.
Fun fact: The German "eszsett" (ß; U+00DF) is a ligature for "ss" (specifically the "long s"[0] and a normal "s") that evolved over time to be one "letter".[1]
To me it just feels out of place, like a calligraphy ligature got accidentally mixed with a standard serif font. From what I've seen this kind of ligature is usually applied to many other letter combinations as well, in which case it at least looks consistent.
> It's how English was written in the "olden times".
Exactly.
(skipping some minor details)
When we started printing instead of writing, we dumbed the letterset down into fewer mechanical pieces. Thus earlier printers in English had to use the letter 'f' for the discarded "long 's'" letter, back when the long 's' was still expected by readers.
And that dumbed-down letterset was the one that then made it to typewriters and then our keyboard today.
According to the Wikipedia page for eszett [0] it evolved from "sz", as the name "eszett" suggests. (I only realized the link with "z" when I saw "tz" ligatures on street signs in Berlin.) Given that its typographic origin is sz, and given that its name literally says sz, I wish the spelling reformists had gone for sz rather than ss!
It's one way it was written, I bet. If my experience from old Norwegian church books is any indication, there were a lot of ligature fads. Some liked to replace all double consonants with a single consonant with a line over, for instance. It had a good couple of decades.
Do we really need to continue this stuff on computer screens.
Ligatures are old fashioned in English but still very common in French. Some ligatures are actually mandatory (like the oe in cœur, heart) while others like st are pretty common in proper typefaces such as those used for novels. The author is probably French (Aurélien).
I've been writing almost exclusively in cursive for my entire life past age 8 and that font looks crazy to me. I learned both D'Nealian and Zaner-Bloser in different schools and have seen a lot of my grandmother's writing, which was semi-Spenserian.
The stroke just doesn't go in the right direction for those ligatures. My guess is that this font is based on a French (or maybe other latin) script.
But also French typographical ligatures (well beyond the syntactic ones that are mandatory) aren't really related to cursives, they are a typographical convention. like the cursive s doesn't look like s and wouldn't have a ligature with t from the top of the t in cursive. (However, at least for French cursives it's common to do a single cross for double tt which I guess is a ligature?)
I also only learned cursives in school. In fact writing in script was forbidden and not taught at all.
I couldn't read it because it was a tiny column of text at a tiny font size with the rest of the screen being wasted space. Thank goodness for reader view.
The ligatures are definitely an unusual artistic choice...seems like the sort of thing you'd finally get used to 4 chapters into a book, but until you're immersed in it, it's quote distracting.
The font looks much less ill-defined and irregular if I tell the browser to enlarge the text to 130%. There are still some issues at that size.
But I'm not going to judge it by how it looks after I do a manual adjustment. The way it's presented is terrible. It somehow manages not to fit into the pixel grid of my 15-inch 3840x2160 screen. These are not large pixels!
I assumed they were intentional for editorial effect: deliberately designed to disrupt the flow of a reader attempting to follow the text, in the same way that he claims the compression artefacts disrupt the perception of a skilled photographer trying to use the heavily compressed webp and jpeg images.
I wiped my phone screen a few times until I accepted it is part of the text. Is that a toggle in the text editor? And if it is then should reader clients have a counter toggle for it? I'm thinking autocrlf style.
This site made me add my first-ever global Stylus sheet:
* {
font-variant-ligatures:unset!important;
}
I'm pretty infuriated that this is necessary, why would someone abuse readability so much for their own personal satisfaction about how "cool and unique" they are? Usability. Comes. First.
It's their website. They can do with it whatever the hell they want with it. They owe random people on HN exactly nothing. And you can also do whatever the hell you want on your website, because that's your website.
You also need to reset "font-feature-settings" by the way.
Yeah, that got on my nerves too. Ligatures (like kerning) are supposed to help make reading more fluent and otherwise blend in, not stand out like a sore thumb. Really not sure what those ligatures are supposed to say - "wow, look how cool this font is, it has ligatures!!!"?!
I didn't really understand what everyone was talking about since I use a combination of uMatrix and noscript and noscript blocks webfonts by default.
But, after whitelisting his site, eh, it didn't bother me. I guess it's what one is used to.
Agreed, I don't understand why anyone would use ligatures like that on body text. Add them to titles you want to look particularly fancy if you must but please don't mess with the readability of anything longer than a paragraph.
I read this comment. I thought, "wow typical HN, someone has taken the time to write this big blog post and the top comment is about some stupid little typographic detail."
Did 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.
> "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."
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.
The author is also a web designers that primarily use wordpress. Wordpress website owners these days would put their site into pagespeed insight and that tool will advise that images to be converted to webp, then demand their web guy to do it. I imagine the author got tired of seeing images on their sites ruined but can't do anything because that's what the clients want to tick off a box in pagespeed insight.
Because it's a substantial amount of effort to upgrade to the "new" tech, and he's showing that the "new" tech is actually worse than the "old" tech of reliable old jpeg.
It's more nuanced than that: the author compares two lossy compressions and gives their opinion about which one is better.
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.
The repeated callouts to PageSpeed imply that their concerned about search placement, which is understandable for the profession. If your site is bumped off the first page because Google doesn't like that you're still using JPEG that's lost income for you.
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?
Yes, 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.
I 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.
Isn'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.
Honestly, 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.
Unless 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.
Probably 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.
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.
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.
It'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.
> 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.
To me the banding in the "lossless" (do words mean nothing anymore !?) webp pictures is super clear and looks like how I'd expect low quality JPEGs to look.
It's the same kind of artifact that makes certain movies look terrible over netflix, those that have large dark blank spaces. Maybe you shouldn't look to closely because once you see it, it'll ruin your enjoyment of certain compressed media forever.
And by the way I don't think the comparison with audiophile equipment is fair. In the audiophile case we are talking about using very similar output hardware to output what is effectively the same signal. Here we have huge differences in file size (35% and more between JPEG and WEBP, a lot more than that for true lossless), and taking diffs between them shows very much that the signal isn't the same.
There is a compression limit under which you can see it's compressed, right?
So it makes sense that there is some threshold sensitivity where a picture starts appearing "lossless". That threshold is going to be different from device to device and person to person.
It 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.
Yeah 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.
This 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.
It 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.
I 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.
Oh 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.
Google marketed it that way but I could never reproduce a meaningful size savings without noticeable quality loss. You need to serve a LOT of video before even the top-end 10% savings was worth it, especially if your traffic was spread across many items so doubling your storage cost cancelled out a fair chunk of the total. I have no doubt that YouTube saw a savings but I don’t know how many other sites did, and I would be curious what the savings was relative to the extra power used by the millions of client devices which could’ve streamed H.264 at 10% CPU versus having the fan on high.
If users don't have hardware accelerated video decoding, it's so bad that it actually hurts the experience. I can't imagine that being worth the space savings. There doesn't have to be a good reason YouTube does it, it might just be someone wanting to insert their tech, which I'm pretty sure is the reason Meet uses it.
My favorite is the URL ends with jpg but when you save the image you get a fucking WebP. Thanks everyone for breaking the Internet in the name of Google. The best.
Even worse that the original blog post, because of this you may be dealing with a JPEG image, converted to WEBP, and then back to JPEG. And then maybe someone edited that JPEG and it got converted back to WEBP!
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!
I 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???
> 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.
I 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.
It'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.
OP 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.
The 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.
Chroma 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.
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.
I 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.
Like video, webp uses limited ycbcr, as opposed to jpeg which uses full ycbcr. This leads to grayscale jpeg looking perfect on monitors that use full rgb values, as opposed to webp which will have slight banding issues when displaying grayscale content.
The 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”?
Clearly, 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.
The 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.
Is 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.
> 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?
A 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.
…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.
The 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.
Still, the author could do more to highlight the differences using zooms and annotations. The banding in the background is particularly strong and would help their point to highlight visually to the reader.
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.
If you tried and couldn't see, it might be like others say that it's more visible on certain monitors and setups. But then, again - if you are designing codecs or choosing them, you probably want a monitor that makes it easy to see these things. I can see them on my old iPhone screen.
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.
> But then, again - if you are designing codecs or choosing them, you probably want a monitor that makes it easy to see these things
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.
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. ;)
The author's point is deeply stupid. As he admits:
> 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
Most of the comparisons are encoded from source. The one that isn't is because re-encoding is a specific recommendation from the services that they are criticising. They are specifically showing that yes, that's a bad idea.
For starters, anyone that ever worked with a codec, will know that you don't compare them with ONE SINNGLE IMAGE.
This whole basic idea of the blog post is just to generate more whining and clicks and not to actually make a comparison between formats that's worth a basic smell test.
This cuts against WebP more: all of Google’s marketing was “it’s a third smaller!!!!” and then when you looked they were comparing it to unoptimized libjpeg outout and using computational metrics like SSIM which only crudely approximate what humans notice about image quality.
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.
Criticism of cherry-picking cuts against WebP because the marketing campaign for that codec relied on cherry-picking both the least optimized JPEG codec and the most favorable metrics for comparison. If you had humans comparing images or enabled JPEG optimization you saw far less exciting numbers for WebP - usually under 10% savings, not uncommonly negative – and there were other formats which consistently outperformed it. You can see the mood around that time here:
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.
Except the problem isn't in a single image, it is a pattern that is frequently there and the image was only used to demonstrate it. WebP has this problem way back as one of the reason others were hesitant to support it except Google.
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.
A 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 ).
I’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.
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.
> 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.
Independently 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.
410 comments
[ 3.2 ms ] story [ 290 ms ] threadThe whole thing reads like a no-so-subtle brag about how his mighty photographer's eye can spot details that mere mortals can't.
fascinating how perception is different.
It's artifacts made in the background of the image that this poster is complaining about.
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.
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.
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.
Seamless legacy support is very valuable. And it still performs pretty well compared to competitors. I think it's a good default for a lossy network format.
> after significant time of noone using the format
That's also fasle, this is too new of a format for any significant time of no use to materialize, besides, requiring flags that vast majority of users will not enable is a huge factor limiting widespread use
Moreover, this whole topic is about a comparison over a SINGLE IMAGE. Anyone who ever came close to codecs would immediately dismiss this as ridiculous. Yet here we are.
Ackchually, the blog post contains a comparison over TWO IMAGEs. But since you work with codecs, surely you understand that the blog post is complaining about how WebP interacts with gradients in general and not just about the specific images in the blog post.
JXL was getting plenty of attention before the Chrome debacle. Of course it was less than WebP and AVIF but JXL wasn't getting pushed or championed by anyone (other than Cloudinary I think) so JXL didn't have the marketing powers the others had.
This goes triple for modern codecs like JPEG XL, VP8/9, AV1/AVIF, etc. because they deliberately make tradeoffs when compressing based on how the image will SEEM to people, not how pixel correct it is. Note just how many people say they barely notice a problem - this is where WebP made the tradeoff. JPEG did it elsewhere (e.g. text).
Cherry-picking a single image is useful only for fanboy screeching.
Do you really expect a photographer to prepare a quantitative codec comparison benchmark? All they have is anecdotal evidence, and I think it is fair for them to criticize and make decision based off of their own anecdotal evidence.
> This goes triple for modern codecs like JPEG XL, VP8/9, AV1/AVIF, etc. because they deliberately make tradeoffs when compressing based on how the image will SEEM to people, not how pixel correct it is. Note just how many people say they barely notice a problem - this is where WebP made the tradeoff. JPEG did it elsewhere (e.g. text).
No one is going to sit here and claim that WebP performs better on all images or JPEG performs better on all images. Obviously there is going to be some kind of tradeoff.
TBH, my gripe with WebP is not that it's worse than JPEG. IMO it is in fact better than JPEG in most cases.
My problem is that it is only an incremental improvement over JPEGs. We are breaking compatibility with the universal image formats and we get the following benefits:
- 15-25% better compression
- animation
- transparency
- lossless compression
On the other hand, we could break compatibility, adopt JXL and get the following benefits:
- lossy compression on par with WebP
- animation
- transparency
- lossless compression that is marginally better than WebP
- actually kinda not break backwards compatibility because you can convert JPEG -> JXL losslessly
- enhanced colorspace support
- progressive decoding
- very fast decode speed
- support for ultra-large images
Adopting WebP would be great. But why adopt WebP when instead you can adopt JXL which is superior in terms of features and on par in terms of compression?
>Call me crazy, but I don’t give a shit about averages. For a gaussian "normal" process, probabilities say half of your sample will be above and half will be below the average (which is also the median in a gaussian distribution). If we designed cars for the average load they would have to sustain, it means we would kill about half of the customers. Instead, we design cars for the worst foreseeable scenario, add a safety factor on top, and they still kill a fair amount of them, but a lot fewer than in the past. [...]
>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. And that whole WebP hype is unjustified, in this regard. It surely performs well in well chosen examples, no doubt. The question is : what happens when it doesn’t ? I can’t fine-tune the WebP quality for each individual image on my website, that’s time consuming and WordPress doesn’t even allow that. I can’t have a portfolio of pictures with even 25 % posterized backgrounds either, the whole point of a portfolio is to showcase your skills and results, not to take a wild guess on the compression performance of your image backend. Average won’t do, it’s simply not good enough.
Here the reasons why Chrome devs made the difficult decision to remove JPEG XL from Chrome: https://groups.google.com/a/chromium.org/g/blink-dev/c/WjCKc...
Thats why, to my knowledge, nobody even bothers to use hardware jpeg encoders/decoders on phones/laptops, despite many bits of silicon having them.
I can't find clear numbers on this, but on e.g. [1] I read it's not too fast, but I didn't try to reproduce their results, and according to some comments a number of factors can greatly affect performance.
[1]: https://old.reddit.com/r/jpegxl/comments/zwftn2/libjxl_on_an...
AVIF reduces the amount of traffic required, but will tend to consume more power. This is the general compression tradeoff.
(Other formats often have hardware decoding support too, incidentally. But a lot of the time they’re ignored as too much effort to integrate, or buggy, or something.)
Mobile devices on battery are connected wirelessly, so traffic consumes a lot of power. The faster the radio can power back down the better, so CPU time is usually a worthwhile trade.
> AVIF reduces the amount of traffic required, but will tend to consume more power. This is the general compression tradeoff.
Again, you seem to be ignoring hardware decoding. Dedicated silicon can be many magnitudes more efficient than doing something in software. To take an extreme example with a ton of effort into the efficiency: look at mining bitcoin on a CPU vs an ASIC. I'm not saying the difference will be that big, but it may well be worthwhile.
As to buggy/too much effort/cost of hardware, that's precisely why it makes sense to piggy-back on AV1, a format that already has a lot of incentive to implement in hardware, and the work already done to make it work well. You need that kind of compression for video, and people are putting in the effort to make it work well, so AVIF gets that effectively for free.
I can understand why jxl isn't a dominant web format, but I don't see where avif has any place being a web format currently.
Video codecs as used for images also have big disadvantages since they weren't designed for many picture-focused workflows
> only matters during the transitional period.
which can be decades, so this matters a lot
> it seems to massively outweigh any advantage JXL has
Since you haven't listed any other advantages outside of downplaying the compatibility during transition, so that's hard to weigh. Also, it's not like, if we're talking about the whole lifetime, hardware couldn't add support
As to hardware adding support for JXL, that seems extremely unlikely: image decoding is less impactful than video decoding, and the cost of adding custom decoding silicon to a chip is very high, as is adding support to software for that hardware. Being able to piggy-back on the work already done for video meaning you get that stuff for free makes it way more viable. AV1 decoding is already out there in virtually every new device, and rolling out hardware support is very slow, it's massively ahead in that respect.
https://cloudinary.com/blog/the-case-for-jpeg-xl
I just don't think any of those features matter as much a battery life, most of them are about encoding speed which just seems wildly unimportant to me: encoding may be more work, but generally you view images far more than you make them, and admins and creators are in a better position to spend the time/effort to encode something, and hardware encoding may well end up making it a non-issue anyway.
People are out there running `zopflipng` and the like to try and get better sizes at the cost of more work at encode time, so it seems like that priority isn't just me.
But - back to JXL vs WebP:
I think Google had genuinely good intentions with WebP, but the effort was somewhat ruined by their culture: they relied too heavily on metrics which aren't always a good proxy for image quality, because humans looking at pictures don't scale, and Google does things that scale. We now have a codec with good metrics, but looks poor.
It's based on the intraframe coding of the VP8 format - a video codec - and I think it suffers from that. Looks OK in a video, but bad in stills where you have more time to notice its warts
Most importantly, it's almost always produced by recompressing a jpeg and causing a generation loss. I don't know of any phone or camera which produces native WebP (maybe some recent pixels? Dunno), and any professional device used in RAW mode usually implies the participation of someone who cares about the finished product and will not want WebP (and will resent when it's used without their consent by webmasters wishing to tick a box in pagespeed, as the author mentions). JXL has a lossless recompression mode in which it just replaces the Huffmann compression stage of an existing JPEG with something more modern, and this results in a pixel-accurate image which is 20% smaller than the original file - this already eat WebP's claimed space saving, and then some, with no generation loss. Based on this fact alone, there shouldn't even be a discussion.
....but let's have a discussion anyway. A JPEG -> JXL lossless recompression isn't conceptually new - Stuffit (remember them?) did it in 2005, with not enough traction sadly (unsurprisingly since there were patents and licensing costs). Basically it's _still_ a JPEG - if you decompress the final stage of a JPEG, and the final stage of a JXL (or a .SIF), you get the exact same bytestream. While yet another amazing testament of JPEG's longevity and relevance, it is also concerning: How could Google do worse than that??? When basically rezipping (with a modern algo) the existing DCT macroblock bytestream of a 30 year old codec beats your new codec, you should just trash it.
Edit: ...but I forgot to answer your question. Why is JXL viewed so favorably on HN? Because it doesn't suck, and we're sad that Google decided to be a roadblock, and pushing for their own thing, which instead sucks. At least AVIF is way better than WebP, even though it's a monster, computationally.
I'll therefore correct my statement: "How could Google do worse than that??? When basically rezipping (with a modern algo) the existing DCT macroblock bytestream of a 18 year old codec beats your new codec, you should just trash it."
Also, Stuffit's SIF format is still 5 years prior to 2010 so that point stands.
Having an immediate upgrade path to all pictures from the past is too good an opportunity to pass up.
We rarely get a free “compress losslessly” button for our archives.
[1] https://storage.googleapis.com/avif-comparison/index.html
[2] https://cloudinary.com/blog/contemplating-codec-comparisons
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...
>> 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.
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
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
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.
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.
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.
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...
4k Dell monitor, Safari on a Mac.
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.
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.
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 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.
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.
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.
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.
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?
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.
See my post lower in this thread.
https://news.ycombinator.com/item?id=38656046
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)
[1] https://en.wikipedia.org/wiki/Ligature_(writing)#Ligatures_i...
[2] https://superuser.com/questions/669130/double-latin-letters-...
In the HN comment editor it is the same as in the article, with that stupid curve connecting the s and t.
In the rendered comment in Chrome, Firefox, and Safari on my Mac it is using for regular comment text some font where the s and t are joined much less obtrusively. In fact at first I thought HN was replacing the U+FB06 on output with separate s and t. E.g., these two look very similar for me: still still.
For rendered code blocks on Safari and Chrome it is using the font that has the curve. On Firefox it does not have the curves. Here is a code block example:
Fun fact: The German "eszsett" (ß; U+00DF) is a ligature for "ss" (specifically the "long s"[0] and a normal "s") that evolved over time to be one "letter".[1]
[0]: https://en.wikipedia.org/wiki/Long_s
[1]: https://en.wikipedia.org/wiki/File:Sz_modern.svg
Exactly.
(skipping some minor details)
When we started printing instead of writing, we dumbed the letterset down into fewer mechanical pieces. Thus earlier printers in English had to use the letter 'f' for the discarded "long 's'" letter, back when the long 's' was still expected by readers.
And that dumbed-down letterset was the one that then made it to typewriters and then our keyboard today.
[0] https://en.wikipedia.org/wiki/%C3%9F
Do we really need to continue this stuff on computer screens.
The stroke just doesn't go in the right direction for those ligatures. My guess is that this font is based on a French (or maybe other latin) script.
https://commons.m.wikimedia.org/wiki/File:Ligature_typograph...
But also French typographical ligatures (well beyond the syntactic ones that are mandatory) aren't really related to cursives, they are a typographical convention. like the cursive s doesn't look like s and wouldn't have a ligature with t from the top of the t in cursive. (However, at least for French cursives it's common to do a single cross for double tt which I guess is a ligature?)
I also only learned cursives in school. In fact writing in script was forbidden and not taught at all.
The whole font is bad. It looks pixilated and blurry, which can only be explained by that being the intended look. It's bizarre.
https://i.imgur.com/WE1tbIB.png
The ligatures are definitely an unusual artistic choice...seems like the sort of thing you'd finally get used to 4 chapters into a book, but until you're immersed in it, it's quote distracting.
But I'm not going to judge it by how it looks after I do a manual adjustment. The way it's presented is terrible. It somehow manages not to fit into the pixel grid of my 15-inch 3840x2160 screen. These are not large pixels!
* { font-variant-ligatures:unset!important; }
I'm pretty infuriated that this is necessary, why would someone abuse readability so much for their own personal satisfaction about how "cool and unique" they are? Usability. Comes. First.
You also need to reset "font-feature-settings" by the way.
what a glorious world we live in
Turns out a CSS rule does this:
Then I went to read the text and... :(
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?
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!
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 is based off of a video format, and tradeoffs there are very different.
Let's focus on AVIF.
That's a weird way to write JPEG XL.
What's the legal/licensing status of that?
How does it compare technically to AVIF?
But if JXL isn't an option, definitely AVIF.
The banding is just not supposed to be there.
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.
The artefacts are visible mostly in the background, where frankly I do not care.
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.
You are right. I just made my room dark to try this out, and now I can see the banding!
It's the same kind of artifact that makes certain movies look terrible over netflix, those that have large dark blank spaces. Maybe you shouldn't look to closely because once you see it, it'll ruin your enjoyment of certain compressed media forever.
And by the way I don't think the comparison with audiophile equipment is fair. In the audiophile case we are talking about using very similar output hardware to output what is effectively the same signal. Here we have huge differences in file size (35% and more between JPEG and WEBP, a lot more than that for true lossless), and taking diffs between them shows very much that the signal isn't the same.
There is a compression limit under which you can see it's compressed, right?
https://vole.wtf/kilogram/
So it makes sense that there is some threshold sensitivity where a picture starts appearing "lossless". That threshold is going to be different from device to device and person to person.
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.
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.
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!
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.
That's the whole point of compressing the image, isn't it?
To me, it looks like webp does its job.
> 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.
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.
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.
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?
[1] https://news.ycombinator.com/item?id=38653224
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.
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.
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...
> 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
This whole basic idea of the blog post is just to generate more whining and clicks and not to actually make a comparison between formats that's worth a basic smell test.
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.
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.
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.
> 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/use...
- 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.