Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebP is so great except it's not (2021)

eng.aurelienpierre.com

Post reply on HN
Print view View original

381–390 of 411 posts

Re: WebP is so great except it's not (2021)

#381

Post by skelpmargyar »

Unfrozen0688 wrote: post #341
pembrook wrote: post #124

I've noticed the same issue with WebP and have gone back to JPG/PNG for most things (jpg for photos, png for UI-type images) 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…

Not true. Monitors now are 1440p or 4k. Even at work for me. 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.

You also can't write software bad enough that you're forced to upgrade your monitor due to poor performance.

Re: WebP is so great except it's not (2021)

#382

Post by quikee »

Semaphor wrote: post #116
vardump wrote: post #20

Earlier quoted context omitted.

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

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

They ceased development on WebP2.. don't think they could've come up with anything better than AVIF or JXL already have anyway.

Re: WebP is so great except it's not (2021)

#383

Post by jeroenhd »

raajg wrote: post #379

On my 14in Macbook Pro I CANNOT TELL THE DIFFERENCE AT ALL

The images inline in the blog are heavily compressed and look about the same. Click through to the actual demo files and the difference becomes obvious.

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.

Re: WebP is so great except it's not (2021)

#384

Post by stemlord »

worewood wrote: post #371
iSnow wrote: post #145

Earlier quoted context omitted.

I have an extremely hard time perceiving any difference on a 27" 4K monitor. I am not even sure I really see them. The examples are just bad. If you want to show something, screenshot and enlarge it to show the artifacts.

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

But we are philistines not pro photographers

Re: WebP is so great except it's not (2021)

#385

Post by dbttdft »

pembrook wrote: post #124

I've noticed the same issue with WebP and have gone back to JPG/PNG for most things (jpg for photos, png for UI-type images) 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…

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

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.

Re: WebP is so great except it's not (2021)

#386

Post by dbttdft »

sxp wrote: post #254
V__ wrote: post #4

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

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 bec…

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

Re: WebP is so great except it's not (2021)

#387

Post by dbttdft »

yossi_peti wrote: post #374

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

The type of image shown here is a common use case. There's no arguing that it's a statistically insignificant case.

Re: WebP is so great except it's not (2021)

#388

Post by dbttdft »

Unfrozen0688 wrote: post #341
pembrook wrote: post #124

I've noticed the same issue with WebP and have gone back to JPG/PNG for most things (jpg for photos, png for UI-type images) 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…

Not true. Monitors now are 1440p or 4k. Even at work for me. 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 tend to just work

They really don't...

Re: WebP is so great except it's not (2021)

#389

Post by suzumer »

kmeisthax wrote: post #250

So... why are we still having problems with banding in image compression? If anything, gradients should be the easiest things to compress in these images, because the compression algorithms work entirely in the frequency domain. Whatever is introducing banding here is adding more frequency coefficients and making the image bigger and worse at the same time. Did Google/On2 just not notice that they were crushing every…

Webp is encoded using limited ycbcr values as opposed to jpeg which uses full range ycbcr values. When converting jpeg to webp, there will be banding. Grayscale limited ycbcr when converted to full rgb during display ill also have banding.

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

Re: WebP is so great except it's not (2021)

#390

Post by quikee »

mceachen wrote: post #366
Findecanor wrote: post #262

Earlier quoted context omitted.

> Re-encoding from a lossy compressed source will make quality worse. 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.

Careful with the JPEG-XL re-compression, though--depending on how you're re-encoding, jxl may use SSIM to evaluate for visual losslessness, and the whole point of TFA is that SSIM is blind to posterization, but (some) humans aren't. 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-specifi…

JXL has Guetzli lossless JPEG compressor integrated into the standard so it produces reversible and completely standard compliant JXL images that are 15-20% smaller size. Reversible in sense that you can still convert the image back the original JPEG, that is bit exact file as the input JPEG was (it takes care of all the metadata also - it has to).

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.

Post reply on HN