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

371–380 of 411 posts

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

#371

Post by worewood »

iSnow wrote: post #145
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 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.

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

#372

Post by ksec »

I now hope more people understand why I am pushing for JPEG XL, practically before anyone else on HN ( apart from its authors ).

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.

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

#373

Post by tzs »

catach wrote: post #353
tzs wrote: post #225

Earlier quoted context omitted.

I wonder if that would still work if the ligature were done in Unicode instead of CSS?

Interesting question! The st and ct ligatures used in the article don't seem to be part of the precomposed Latin ligature set, and what is there strikes me as far less obnoxious [1,2]. I expect it's possible to hack something together with combining characters, but also that the visual result would be far too ugly for the tastes of anyone who was desiring ligatures in the first place. [1] https://en.wikipedia.org/wik…

U+FB06 (LATIN SMALL LIGATURE ST) does display the same as the obnoxious ligature in the article if you have the right font. I actually used that for the "st" in the word "still" in my comment above.

In the HN comment editor it is the same as in the article, with that stupid curve connecting the s and t.

In the rendered comment in Chrome, Firefox, and Safari on my Mac it is using for regular comment text some font where the s and t are joined much less obtrusively. In fact at first I thought HN was replacing the U+FB06 on output with separate s and t. E.g., these two look very similar for me: still still.

For rendered code blocks on Safari and Chrome it is using the font that has the curve. On Firefox it does not have the curves. Here is a code block example:

  still
  still

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

#374

Post by yossi_peti »

> 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 literally mathematically impossible to make a compression algorithm that always performs well in the worst possible case.

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

#375

Post by ttoinou »

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…

You're taking the bare definition of "worst". He was not talking about compressing random noise

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

#376

Post by bawolff »

kmoser wrote: post #357
bawolff wrote: post #351

Earlier quoted context omitted.

I dont even think its that - it seems like it was scaled badly by the author of the post not the web browser and that he is not actually displaying the lossless version. If you click on it it goes to the lossless version but the version dispkayed on page is not that version.

It's even worse than what you said: the tag has a srcset attribute with many possible values so different people may see different images depending on their browser's resolution. The one displayed to me was Shoot-Antoine-0044-_DSC0085-lossless-800x450.webp, which shows clear posterization at its native size as well as when it is further scaled down by the browser to 550x309.

Damn, between that and some people having wide gaumet monitors no wonder everyone is fighting.

This almost feels like a troll post.

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

#377

Post by bawolff »

GuB-42 wrote: post #248
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 have no problem seeing the artefacts on both my 2012-era displays. One of them is a rather good at the time 30" 2560x1600 IPS monitor, the other is an entry-level 27" TN 1080p TV. 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…

Someone else noted the author is sending different images to different monitor types... so no wonder everyone is seeing different things.

Generally though i would expect wide gaumet monitors to make a significant difference for these types of artifacts

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

#378

Post by ShamelessC »

onurtag wrote: post #152

In my opinion the worst and most distinguishable downside of webp is the forced 4:2:0 chroma subsampling. On many images with bright colors you can clearly see the color and brightness loss without an educated eye. 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.google…

Not to stir yet stir another debate but yeah, definitely not able to perceive the difference in either of the examples you linked. It would be helpful if that site let you drag the vertical comparison bar at least. On an iPhone 14 display.

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

#380

Post by jeroenhd »

rambambram wrote: post #147

I might be missing something because I never delved into it, but my problem with WebP is I can't save images this way from my browser. Well, I can save them, but they don't show up when I try to view them on my system (Ubuntu Mate 20.04 on RPi4).

That's pretty weird. I'm on Ubuntu 23 and WebP images work the same as JPGs or PNGs.

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?

Post reply on HN