WebP is so great except it's not (2021)
eng.aurelienpierre.com
eng.aurelienpierre.com
I think the real problem is, like many of the commenters here, most people can't tell the difference because desktop monitors have been stuck in a deadzone of zero innovation for the last 10 years. I'm sure half the folks here are viewing his example images on a 2012-era HD 1920x1080 LCD, which is definitely part of the problem.
It's bizarre. Smaller displays (Mobile phones) and larger displays (4k TVs) have fantastic pixel densities now considering their viewing distance. However any panel in the range of 20"-40" is stuck in the mid-2000s.
Also, I think the author would have done us a favor by using example photos with lighter backgrounds (or changing the background color of his post to black). The harshness of the black images on white don't allow the eye to adjust enough to see the issue. If you put those images on a dark background its super easy to tell the difference.
That's a weird thing to say unless the pixel density is your one and only measure. Regardless of that, the posterization should be perfectly visible on a 2012 FullHD monitor, or even a 1366x768 TN screen of a decade-old laptop. Most commenters here are probably viewing the pictures on a scale different from 1:1.
Is it though? We now have OLED TVs and OLED smartphones.
Where's our OLED PC monitors?
On every measure, if you care about colors/contrast/black+white levels/resolution/density, the average computer monitor has fallen far behind.
You can't even buy a smartphone that has a panel half as bad as most PC monitors on the market. And, at least in my area, you'd actually have to go to a lot of effort to find a non-4k TV.
https://www.displayninja.com/oled-monitor-list/
Mainly targeted towards the gaming market at the moment.
- Framerate - Response time - Adaptive sync - (how prone to burn-in is OLED? Monitors often have way more static images to TVs)
I assume combing these all might just make it more expensive than just individually each feature
The much more complicated electronics plus Supply & Demand. Demand for TVs should be way higher then for high end monitors.
https://computers.scorptec.com.au/computer/Oled-Monitor
They've been around for years.
PC monitors have been improving constantly with high refresh rates, local dimming HDR + 10 bit color, adaptive sync, OLED and more.
There is a difference in the gradients of color. One hasn't the guy looking backlit and one doesn't.
The examples are just bad. If you want to show something, screenshot and enlarge it to show the artifacts.
Yes! Where's the red underlines and diffs? I can see the background banding, but the foreground looks the same at a glance except that some of them look ambiguously "off" in ways that could just be placebo.
You'd think a visual artist would be more interested in visual communication and not just a wall of text with un-annotated photos.
After that it was pretty obvious what the author is talking about.
The difference is in color around the edges of the picture in the background change noticeably on a non-fullscreen image on my Android 12 device.
WebP image gradients just looked broken (posterized) except the lossless one, which was (obviously) perfect.
One might argue that if you need to enlarge it to see the artifacts, then the artifacts aren't perceptible enough and the codec is already good enough for the use case.
Wait... I agree for JPG but if you use lossless WEBP instead of PNG, isn't it simply the same pixels, just with a file about 30% smaller than the corresponding PNG file? (and 15% smaller compared to already heavily optimized PNG files like when using zopfli/optipng/etc.).
Isn't the "lossless" in "lossless WEBP" actually lossless when converting a PNG file to WEBP?
FWIW when you convert losslessly a PNG to WEBP, then decompress the WEBP back to a PNG file, then convert again that PNG back to a WEBP file, you get the exact same lossless WEBP file. It's also the same WEBP you get when you encode losslessly from either a PNG or that same PNG but "crushed" with a PNG optimizer.
On the technical side, webp support still isn't like png. Tried dragging a webp into Google Slides just now, got "unsupported image type," which is ironic. I'll try again in like 10 years.
Oh that's a good point.
I see lossless WEBP mostly as a way to save bandwith where PNG would have been used. If you've got a pipeline where, anyway, you already "crush" your PNG file, you may as well also generate a lossless WEBP file and serve that: all browsers support it. And you can fall back on the optimized PNG should the browser not support WEBP.
I mean: I use WEBP, but only lossless WEBP, as a replacement for PNG when I'd serve PNG files to browsers.
But for that one usecase: showing a PNG file in a webpage, I don't see that many downsides to lossless WEBP. It saves bandwith.
Also, if users download your images and use them elsewhere, webp will still be more annoying for them. Though it's not very common that you want them doing that anyway.
Any updated (modern) browser should be able to see webp just fine, I'd rather just serve it without a backup plan if I'm planning to have webp in my website.
So I don't think display quality really is the problem here. Maybe the drivers, or post-processing filters. Or maybe everyone doesn't have an eye for this. I have an interest in image processing, and that's the kind of detail one tends to notice with experience. The author of the article is undoubtedly more experienced than me and noticing these details may even be part of his job. He most likely will be able to notice these problems on crappy monitors, as well as telling you in which way that monitor is crap.
Generally though i would expect wide gaumet monitors to make a significant difference for these types of artifacts
The "issue" is that monitors last a LONG time. And thats good. We dont touch them or fiddle with them. They tend to just work. Phones and shit we keep dropping and breaking, then the battery gets bad.
Also for gaming you may even want 1080p 200hz monitor for high refresh rate and FPS over pixel density.
They really don't...
Recently I’ve been dabbling in HDR video, but I realised that the exercise is futile because I can’t send the results to anyone — unless they’re using an Apple device.
I just looked at the first two images of the post.
First on two mid end LCDs: one ASUS IPS from this year and one BenQ TN from 2012, both 24" 1920x1080 (~91 DPI). The difference between the images is clear on both.
And before posting, to make sure, I pulled out a 15" 1024x768 (~85 DPI: basically the same) NEC TN LCD from 2002. And a NEC CRT roughly 15" viewable 1024x768 from 1998. Both on VGA connectors (so there is the typical noise from that, which still doesn't cover up the posterization). The difference between the images is clear on both.
All monitors viewed from 3' away.
People are simply accommodated to poor image quality, including posterization. AAA FPS video games display it on static art backgrounds in the loading menu, and I can never tell if they are intended. Show them a 240Hz monitor with 30ms input lag and 5 frames of overshoot artifacts and viewing angles worse than 1998, and they'll be wowed.
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.
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.
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.
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)
On comparison [1] you can clearly see that the top right balloon has lost its vibrant red color. On comparison [2] the bright blue neon art on the center has lost its brightness.
[1] https://storage.googleapis.com/demos.webmproject.org/webp/cm...
[2] https://storage.googleapis.com/demos.webmproject.org/webp/cm...
I have to ask, what could be the reason this gives me pale blue (other colors are okeyish) jpg > webp:
cwebp -pass 10 -m 6 -nostrong -sharp_yuv -quiet -q 60 -sharpness 2 $1 -o
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!
There surely must be better examples to show "non-educated" plebs (to use the tone of the post) why webp is bad and to justify the post and the tone.
I'm on Android, maybe this is why all pic quality look the same?
Also - yeah, if you are making pics for educated eyes: don't use tech that is not suitable for educated eyes? Or don't outsource that decision making to others?
And given all the confident comments in this thread claiming the author is full of shit and there's no difference, I think their frustration is justified? If you can't see the difference in the first images that's fine but you probably shouldn't be confidently claiming to know better than the author, let alone designing an image codec.
His font choice is terrible for my legibility. Maybe for others it's great. But it made the already difficult article that much harder to read. And I like this topic. I already seriously question his sense of what is reasonable and good and for what purpose. His purposes are so alien to mine that his opinion ends up being pretty irrelevant to mine. I wish him well with his.
I can't see the things he's pointing out in the images, and I tried and tried.
I use webp extensively, there have been zero complaints from users about the images. But I don't make art sites. I make software people use to get stuff done. I don't transfer images above maybe 50-80k. Art, aside from modest marketing, is most definitely not the point.
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.
What would make sense is choosing safe settings for compressing new photos in the new format.
JPEG-XL is supposed to reencode old JPEG files into 20% smaller files without quality loss though. In context, Google has been holding JPEG-XL back by removing support for it from Chrome and refusing to reinstate it, claiming that it did not have good enough "incremental benefits compared to existing formats" such as webp.
> It is possible to losslessly transcode JPEG images into JPEG XL. Transcoding preserves the already-lossy compression data from the original JPEG image without any quality loss caused by re-encoding, while making the file size smaller than the original.
I wonder how it does that and why JPEG didn't notice it could. I would re-encode to JPEG-XL, when supported. So then the situation isn't that WebP is so great but rather Chrome's not so great.
It's trivial to do: JPEG's last stage is a compression via Huffmann code - which is a really ancient, not particularly effective compressor. You simply decompress that stage, and compress with something more modern, yielding better savings. Stuffit did it in 2005. PackJPG in 2006. Brunsli (a Google project!) in 2019 - and it was one of the inputs to the JXL draft. Lepton did it in 2016.
> and why JPEG didn't notice it could.
Oh that's the best part - they did, all the way back in 1991. The JPEG standard allows you to choose for the last stage between Huffmann and Arithmetic Coding - which is way more effective. Unfortunately it was patent-encumbered and its support is low. It yielded 10%ish space saving which wasn't worth the compatibility headache (it has the same extension and mime-type of a Huffmann-encoded JPEG, so a webserver won't know if your browser supports it). If it only had used a different file extension it would probably be the dominant format today.
Disk space is cheap. It's most likely not worth the 20% compression to lose your original images (and possibly lose metadata as well--it's quite hard to robustly retain all vendor-specific MakerNotes, for example).
Also if you decide to forgo the reversibility you can get a bit more out of it as JXL is actually a superset of JPEG, so it can read the JPEG stream and convert it to JXL without complete recompression - it will just use more efficient structure of JXL and much more efficient (ANS vs. Huffman) entropy encoding. The additional savings compared to the reversible mode aren't big however.
Guetzli is a slow high quality jpeg encoder. One can use jpegli for that need nowadays, 1000x faster...
I think for a truly meaningful comparison you'd need to test a variety of images including full color with busy backgrounds as well as these b&w studio portraits on a smooth gradient type bg, and test a variety of programs like imagemagik, graphicsMagick, sharp, photoshop, whatever cloud offerings, etc.
The other issue I see is use case. If you're a professional photographer trying to upload full size full quality photos, maybe just don't compress at all so you know your creative / editing work is completely preserved. That use case is not the average use case of a website displaying a reasonably sized image of reasonable quality. For many situations a significantly smaller image might be worth having a more compressed image, and for many images the compression won't be as noticeable as it is in a full resolution professional studio photo with a large gradient type background.
The whole thing reads like a no-so-subtle brag about how his mighty photographer's eye can spot details that mere mortals can't.
fascinating how perception is different.
It's artifacts made in the background of the image that this poster is complaining about.
Chroma means color, and color subsampling is used to avoid taking information out of luminance channels because they are more important, so it is actually the opposite of what you are saying here.
There simply aren't enough bits of precision in the luma encoding for good gradient support most of the time, chroma fills the gaps, and chroma subsampling produces artifacts.
Webp lossy only does 4:2:0
https://groups.google.com/a/webmproject.org/g/webp-discuss/c...
These problems would go away with 10-bit AIUI. AVIF supports 10 bit but WebP does not.
This is spatial resolution, 10 bit color channels is quantization resolution of the values. Everything contributes to banding artifacts, which are just noticeable changes in values when that are meant to be perceptually smooth, but the luminance channel is the most important, which is why it isn't subsampled.
These are fundamentals of image and video compression and not unique to webp.
Did Google/On2 just not notice that they were crushing every gradient they encode or is are all the common WebP encoders doing some kind of preprocessing pass that crushes gradients and munges luma?
I thought the loop filter was supposed to help with this though.
Webp really doesnt have a banding issue unless you convert jpeg or display purely grayscale content.
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?
Let's cut our losses, ditch webp and move to jxl.
In what way?
https://developer.mozilla.org/en-US/docs/Web/CSS/font-varian...
> this is WebP re-encoding of an already lossy compressed JPEG
Author is clearly passionate about imagery and quality, so why are they not re-encoding using the original file rather than a lossy copy?
I wonder if the author took that into consideration.
That is indeed surprising. Is it iPad or iPad Pro? It is technically possible that your monitors only support 8bpp color depth while your iPad Pro supports 10bpp (via the P3 color space) and the WebP file has a smooth gradient only when viewed with 10bpp or more. But I can't really believe that, as the original JPEG file still looks like 8bpp and doesn't have any further color profile attached.
It could simply be an effect of brightness -- do you have your 4K monitor set to bright, while your iPad is much dimmer? (Remember Apple devices have adaptive brightness enabled by default as well.)
As a video codec developer I was a little sad about that, actually. I had to start looking closer to see problems.
<img class="lazyload" decoding="async" src="data:image/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==" data-orig-src="https://photo.aurelienpierre.com/wp-content/uploads/sites/3/..." alt="" />
Sorry, I can't. That doesn't actually display any image at all in my browser because you're relying on javascript execution to switch the img src to it's actual source. You don't need to do this for lazyload to work anymore. There's browser native lazyload. Just put the actual image in the src.
It's bizarre how the author's attitude is that the webp authors should know better. Yet his blog cannot link to images properly without JavaScript. My browser supports lazy loading images and srcset; all the things he would want. It does that without JavaScript. Yet he tries to implement that in JavaScript and does not have a fallback to use the browser's native implementation. It's difficult to take him seriously in criticizing others' competencies when he, in a blog post about image quality, cannot include images with over-complicating things to the point of breakage.
His point on color banding is clear and others have pointed out that the luma in 4:2:0 subsampling is terrible. But Google is not in the photography business. (Overlooking his attempt to convert from lossy compression to another lossy compression.) It is in the content business but only in so far as it furthers its advertising business. It is not in content for the same reason as the author so they don't share the same interests.
Compare https://jpeg.org/jpegxl/ to https://developers.google.com/speed/webp/
> JPEG XL is designed to meet the needs of image delivery on the web and professional photography.
If you search google's documentation on webp they mention photography like four times and never as "professional photography".
It's honestly funny that he is surprised that Google is advocating for a file format that does not suit his needs as a professional photographer. Google is an advertising business; everybody knows this.
Finally, I never see critics of (or anyone commenting on) webp mention that it supports transparency. What other format is someone to use if they want lossy transparency? It's great for small low quality thumbnails of images (like jpg or png) or animation (like gif) or video. You can throw just any input at ffmpeg and ask for a webp and it will give you something useful that represents one frame of the input. It fills that niche very well.
Once JPEG XL because well supported, I'd like to use it; I hear good things. But it isn't well supported yet so webp is the only option for images with lossy transparency.
In 2014 (WebP was released in 2010) Mozilla claimed that the standard JPEG format is not used to it's full potential [1] and introduced mozjpeg project that is still being updated [2]. I wonder how it compares today with current WebP implementations.
[1] https://research.mozilla.org/2014/03/05/introducing-the-mozj... [2] https://github.com/mozilla/mozjpeg
You can use picture/source/srcset to provide different image formats depending on browser support. avif for modern browsers, jpg for maximum compatibility. Means people with old browsers will either get lower quality or a few more bytes, but that seems like an okay tradeoff.
Edit: i think maybe my browser is scaling the photo which is adding artifacts.
Edit2: maybe the thumbnails are scaled at different quality levels???
Agreed, the WebP lossless version looks pretty bad when scaled by the browser. And since virtually no website/device shows images at their native resolution these days, that's something to consider.
On the other hand, most people these days view websites on their phones, so those artifacts will be harder to see.
This almost feels like a troll post.
I think it's kind of silly how the author pooh-poohs averages and demands that whoever is working compression algorithms should focus on the worst possible image. If you know anything about information theory, you know that is literally mathematically impossible to make a compression algorithm that always performs well in the worst possible case.
One thing I want to state is that nothing presented here about WebP are new. They have been there since the beginning ( 2010s ). The real problem is, quote:
>>So there is a real issue with the design priorities of image algos from tech guys who clearly lack historical and artistic background, and don’t talk to artists
And their marketing.
Perception is psychological. And image formats are political.
Perhaps some truly do experience zero banding or artifacts.
But to the rest of us... "There are four lights"
I can tell you why: because it's hard, i.e. it's hard to compress efficiently. So if someone claims a breakthrough, they either did something extremely smart, or cut some corners.
(GitHub works if you rename it to a .png or .jpg file, but it's a hack).
If you're planning to convert your images to WebP in bulk, I wrote a shell script: here's the link:
https://medium.com/@siddheshgunjal82/bulk-convert-images-to-...
I then turned my brightness to 50% and immediately saw browser rendering issues the author may not have experienced themselves. The differences in various contexts are massive. It may be useful to take photos of my screen rendering the various artifacts at varied brightness. There are clearly some rendering optimizations (in different contexts) that create some horrible artifacts.
Browsers like Chrome like to associate themselves with WebP for some weird reason, but file explorers, image editors, album viewers, and everything else support WebP just fine.
I don't know what you use, but I use Nautilus, Gnome Image Viewer, and Pinta/GIMP. Perhaps the three years of improved software support make the difference?
WebP is barely supported. For decades the only choice in lossy compression is JPEG, which notoriously sucks for diagrams and basically anything that isn't a photograph. So the rest of the world finally gets a format they can use, and the photographers are angry that the world doesn't revolve around them anymore?
So what if it is worse for photography? Should we continue chasing our tails for another ten years before we find the perfect format? I'm sick of data visualizations drowning in JPEG artifacts.
I'm not opposed to AVIF or whatever, but I don't care about the author's complaints. JPEG is still there. If you want to use it, go ahead.
Is that really even worth shaving 15% off the file size? If bandwidth matters, websites should look to reduce the volume of useless stock images littering their templates.
WebP seems like a gift to Cloudflare and the other companies that do the heavy lifting of caching and serving millions of images across multiple sites. For users, it's at best indistinguishable from JPEG, and at worst an obstruction to saving images from the web.
Additionally, I believe countries like India, Pakistan, Bangladesh, ... are in similar situation infrastructure wise (please correct me if I am wrong) and so for 1/2B people would benefit from a slimmer web.
The problem was that this was basically only true for the largest sites. If you’re YouTube or Netflix, it pays to optimize your video encoding but for most other sites the volume just isn’t there and the performance costs for anyone who uses a CDN cancel it out because you need a lot of traffic for each format before a 10-20% byte size reduction saves more time than the cache misses take.
--
Hoping the conversion doesn't add extra noise, I converted them (with ImageMagick: `convert image.webp image.png`) and compared them (Beyond Compare doesn't support WEBP).
Of course I have a non-educated eye as the article puts it, but if still with machine help I cannot see a difference in light dithering, there must be something off.
The second photo (of a man) is more clear in proving the point. This should probably have been used as the first example in the article.
The problem is that Google's Pagespeed Insights and consequently a lot of resources push WebP to you as a solution for your JPG problems.
A lot of people have been duped into reencoding their JPEGs into WebPs for no reason.
Also just my personal feelings, but I feel like Google doesn't care about people downloading images or using the internet as a permanent gallery for posterity. They don't care about making each individual image look as good as it can be, so someone can in 10 years visit an almost-defunct website or an abandoned account of some user and just view a photograph as a standalone work. It feels like the use-case they're concerned with are the huge 1200px wide, utterly useless and generally irrelevant stock images they forced everyone to put on their articles when they said AMP articles require an image that big. And of course, with the thumbnails automatically generated from such images. That is, WebP's concern seems to be just about the load on the web server, and it's not thinking about the image as a file (the sort you save on your computer). Then again, this is just my strongly opinionated guess based on nothing but the fact JPG was made before the web became what it is today, and WebP was released after mobile internet access surpassed desktop.
Nope. I'm looking at this on a 2k 38" ultrawide monitor, comparing the two images at 190% zoom and I have no idea what I am looking at. I literally can't see a point of difference between them at all. I know my eyes aren't great, but is the difference really that noticeable? What am I missing?
I used to use png everywhere in openetg, so webp's a welcome improvement that's greatly reduced asset size
Perhaps the article should be "In defense of JPEG" but that wouldn't get the clicks
The banding is just not supposed to be there.
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.
The images don't link to the correct filetype stated.
- "JPEG, lossy, 85 : 184 kiB" → links actually to a WebP file (https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20...)
- "JPEG, lossy, 85 : 211 KiB" → links actually to a WebP file (https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20...)
etc...
So when the blog tells you that JPEG is so much better quality, the "jpeg" image that's actually being shown is a WebP image.
I'm going to go with a technical argument here instead of a subjective one, so there's no room for argument: WebP is billed as a replacement for PNG and JPG, and advertised heavily as being usable in both lossy and lossless modes for either. This is blatantly false. Alpha channel aside, PNG is, effectivelyᵗ, 32-bits per pixel, 8-bits for each of RGB. JPG is notably not; to make good use of compression in the frequency domain possible, RGB is usually converted from RGB to YUV/YCbCr. But JPEG lets you customize how this is done, and you can choose to use the default chroma subsampling of 4:2:0, upgrade to 4:2:2, or forego subsampling altogether and use 4:4:4 directly.
WebP is, experiments aside, always 4:2:0 in default/lossy mode (regardless of the tuning profile chosen). Screenshots, vector graphics, text w/ anti-aliasing applied, etc. look absolutely horrendous to the trained eye if converted from RGB or RGBA to YUV 4:2:0. WebP is unusable for png transcodes at any quality except in lossless mode.
I'm not hating on WebP - PNGs converted to lossless WebP are still a good bit smaller, at least for large sizes. But I absolutely despise how pathetically low and biased Google's benchmarks touting WebP as the be-all, end-all have been. And the toolchain is severely compromised, because you have to manually remember to specify lossless mode when compressing a PNG to WebP and that gets harder when it's an automated toolchain and the export is several steps removed from the input. And this becomes completely Mission Impossible™ when you have a lossless WebP and you want to generate a thumbnail from it because the heuristic is no longer "source extension is png" to determine if the output should be generated in lossless mode. IMO, the WebP toolchain *and all other toolchains like ImageMagick and libvips* should pass through the "lossless" property of WebP by default, because unlike with other formats, it tries too hard to be everything for everyone at once and will fall over on its face otherwise.
I said I wasn't going to talk about the subjective side, but I just want to say that even for tiny thumbnails, we've found that their WebP versions need to be generated with at least quality 90 to ensure they will all (regardless of source image) be usable on non-mobile devices (hi-dpi ameliorates but does not resolve the situation, it's just the fact that you see the pixels physically larger); the smoothing effect for detailed real-world photos (think warzone photos with smoke and haze in the air, odd lighting, etc) is way too extreme at lower qualities. Again, the quality:size ratio is still better than JPEG, but not to the extent that Google advertised it to be, but more importantly, if you took Google at its word you would find WebP to be altogether unusable to begin with.
(None of this was about converting already lossily compressed content into WebP; this is straight from source (where "source" is a lossless format like SVG, PNG, RAW, or something like a 24MP JPEG@Q95 being shrunk orders of magnitude) to WebP.)
I played around some with AVIF, HEIC, and JPEGXL. AVIF has some severe color management issues that need to be ironed out in the various toolchains, though HEIC is a lot better in that regard but its lack of compatibility now and in the foreseeable future just makes it a dead end; but JPEGXL appears to be a really solidly built image codec with great potential, kneecapped primarily by adoption.
ᵗ palletization can, but does not have to, affect this
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?
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.
> 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.
Could there be some default optimization going on?
I can see the difference on my LCD monitor from at least six years ago. WebP really struggles with gradients. I wouldn't use lossy WebPs for photography websites. AVIF does a lot better (-25% at no perceivable quality loss), but completely messes up the brightness on my PC for some reason; I think that's a Firefox bug.
That's not to say WebP is necessarily a bad format. There are tons of images where it easily beats JPEG without quality degradation, but these images clearly show cases where it isn't.
Personally, I use lossless WebP to replace PNGs on websites, thereby maintaining lossless quality without the PNG overhead. Lossy WebPs (and JPEGs) need to be hand-checked, though.
{
font-family: 'Linux Libertine';
font-variant-numeric: oldstyle-nums;
font-variant-ligatures: common-ligatures discretionary-ligatures contextual historical-ligatures;
text-rendering: geometricprecision;
font-kerning: normal;
}
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.
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.
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
[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:
still
stillFun 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]
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.
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:
font-variant-ligatures: common-ligatures discretionary-ligatures contextual historical-ligatures;Then I went to read the text and... :(
> So there is a real issue with the design priorities of image algos from tech guys who clearly lack historical and artistic background, and don’t talk to artists, who anyway have largely decided that they were above science, maths and other menial materialistic concerns.
I am a tech guy, and when a photographer tells me that an image looks worse than another one, if I don't see it, my first reaction is more "can you try to explain to me why it is worse?" and less "I don't see a difference, so you must be wrong".
I would be slightly offended if an artist told me that there was nothing wrong with `if (vAluE < 3 ) {return true; } else {{ return false;}}` just because they cannot see the problem.
So overall I find author's aesthetic sense very questionable which contrasts with his high-moral-ground tone.
document.body.insertAdjacentHTML('beforeend','<style>p { font-variant-ligatures: common-ligatures discretionary-ligatures contextual;}</style>')
But besides this, I found typography of that article quite nice; interesting that there are thin spaces before "?" and "!" and wide spaces (not double spaces) after sentences - also "old school" (and often frowned upon). I guess some WP plugin does it, but I admit don't remember seeing seen this anywhere else recently. (And I like it.)
And AFAIK, all HCI literature seems to agree with me.
Secondly, there’s a bizarre assumption here that someone can’t be both a tech guy and an artist, which is nonsense.
Thirdly, there’s a likely incorrect assumption here that artists weren’t consulted, or that the authors of the format weren’t aware of the tradeoffs that were being made.
mp3 is "worse" than flac but if you say it sounds bad I'll absolutely tell you you're wrong and to get off Hi-Fi forums.
That appears to be the author's specific complaint against WEBP, and seems fair.
Then proceed to play the flac's in their car. Ok.
edit: I would also like to note that there is no technical reason to use WebP. The only reason it is used because Google is literally bribing you with "better rankings" for using webp. In other words, it is strictly marketing-driven.
<sigh> Me, too, buddy. Me, too.
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.
WebP is based off of a video format, and tradeoffs there are very different.
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.