by enz on 12/15/23, 11:32 AM with 393 comments
by pembrook on 12/15/23, 12:58 PM
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.
by V__ on 12/15/23, 11:46 AM
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...
by onurtag on 12/15/23, 1:40 PM
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...
by mihaic on 12/15/23, 12:00 PM
by 627467 on 12/15/23, 12:18 PM
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?
by PetitPrince on 12/15/23, 12:23 PM
by karmakaze on 12/15/23, 2:40 PM
What would make sense is choosing safe settings for compressing new photos in the new format.
by naet on 12/15/23, 6:51 PM
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.
by lelag on 12/15/23, 11:42 AM
by barrkel on 12/15/23, 12:03 PM
by kmeisthax on 12/15/23, 4:46 PM
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?
by wwalexander on 12/15/23, 8:16 PM
by bawolff on 12/15/23, 11:51 AM
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?
by hardcopy on 12/15/23, 4:55 PM
Let's cut our losses, ditch webp and move to jxl.
by rsingel on 12/15/23, 7:00 PM
by ncruces on 12/15/23, 12:07 PM
by urbandw311er on 12/15/23, 6:52 PM
> 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?
by icehawk on 12/15/23, 12:30 PM
I wonder if the author took that into consideration.
by superkuh on 12/15/23, 2:07 PM
<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.
by Fice on 12/15/23, 5:24 PM
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
by hannob on 12/15/23, 12:24 PM
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.
by bawolff on 12/15/23, 12:01 PM
Edit: i think maybe my browser is scaling the photo which is adding artifacts.
Edit2: maybe the thumbnails are scaled at different quality levels???
by jollyllama on 12/15/23, 3:07 PM
by tcfunk on 12/15/23, 12:31 PM
by yossi_peti on 12/16/23, 2:20 AM
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.
by ksec on 12/16/23, 2:14 AM
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.
by wizb on 12/15/23, 3:08 PM
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"
by dvfjsdhgfv on 12/15/23, 12:58 PM
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.
by lizknope on 12/15/23, 12:56 PM
by withinboredom on 12/15/23, 12:57 PM
by siddheshgunjal on 12/16/23, 1:30 AM
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-...
by skhameneh on 12/18/23, 10:56 PM
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.
by rambambram on 12/15/23, 1:31 PM
by Izkata on 12/15/23, 6:44 PM
by scythe on 12/15/23, 12:36 PM
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.
by rchaud on 12/15/23, 2:19 PM
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.
by hackererror404 on 12/15/23, 11:52 AM
by layer8 on 12/15/23, 1:59 PM
by kwhitefoot on 12/15/23, 6:18 PM
by j1elo on 12/15/23, 12:33 PM
--
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.
by AlienRobot on 12/16/23, 12:41 AM
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.
by rutierut on 12/15/23, 12:05 PM
by abrookewood on 12/16/23, 6:03 AM
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?
by __s on 12/15/23, 11:19 PM
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
by lofaszvanitt on 12/15/23, 4:46 PM
by axlee on 12/15/23, 11:54 AM
by bitsandboots on 12/15/23, 5:28 PM
by cybrox on 12/15/23, 11:57 AM
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.
by tiffanyh on 12/15/23, 5:01 PM
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.
by theodorejb on 12/15/23, 5:17 PM
by ComputerGuru on 12/15/23, 5:27 PM
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
by VoodooJuJu on 12/15/23, 10:58 PM
by stevage on 12/15/23, 10:04 PM
by Unfrozen0688 on 12/15/23, 9:11 PM
by rsp1984 on 12/15/23, 11:56 AM
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.
by bigbuppo on 12/15/23, 5:21 PM
by mediumsmart on 12/16/23, 7:42 AM
by lifthrasiir on 12/15/23, 12:28 PM
> 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...
by DrNosferatu on 12/15/23, 4:27 PM
Could there be some default optimization going on?
by kome on 12/15/23, 12:12 PM
by raajg on 12/16/23, 2:45 AM
by rpgbr on 12/15/23, 12:24 PM
by gunapologist99 on 12/15/23, 6:57 PM
by angiosperm on 12/15/23, 5:42 PM
by snvzz on 12/15/23, 11:52 AM
Let's focus on AVIF.
by PUSH_AX on 12/15/23, 12:55 PM
by ColonelPhantom on 12/15/23, 11:44 AM
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.
by laserbeam on 12/15/23, 11:47 AM
by palata on 12/15/23, 4:07 PM
> 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.
by michaelcampbell on 12/15/23, 5:12 PM
Then proceed to play the flac's in their car. Ok.
by mngdtt on 12/15/23, 12:04 PM
by jonstewart on 12/15/23, 1:12 PM
<sigh> Me, too, buddy. Me, too.
by Beijinger on 12/15/23, 12:16 PM
by rado on 12/15/23, 11:51 AM
by kvrck on 12/15/23, 12:02 PM
That's the whole point of compressing the image, isn't it?
To me, it looks like webp does its job.
