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

351–360 of 411 posts

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

#351

Post by bawolff »

kmoser wrote: post #326
bawolff wrote: post #35

I can see some banding on the one labeled webp lossless. What gives? Is the banding in the source material? Are we using a different definition of "lossless" than i am used to? Edit: i think maybe my browser is scaling the photo which is adding artifacts. Edit2: maybe the thumbnails are scaled at different quality levels???

> maybe the thumbnails are scaled at different quality levels??? Agreed, the WebP lossless version looks pretty bad when scaled by the browser. And since virtually no website/device shows images at their native resolution these days, that's something to consider. On the other hand, most people these days view websites on their phones, so those artifacts will be harder to see.

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

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

#353

Post by catach »

tzs wrote: post #225
catach wrote: post #12

Earlier quoted context omitted.

Luckily Reader Mode or disabling CSS takes care of the oddity.

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/wiki/Ligature_(writing)#Ligatures_i...

[2] https://superuser.com/questions/669130/double-latin-letters-...

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

#355

Post by CyberDildonics »

barrkel wrote: post #347
CyberDildonics wrote: post #199

Earlier quoted context omitted.

Chroma subsampling reduces the density of available luminance approximations Chroma means color, and color subsampling is used to avoid taking information out of luminance channels because they are more important, so it is actually the opposite of what you are saying here.

https://www.google.com/search?q=gradient+banding+4:2:0 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.

I think you're conflating a few different things. Chroma doesn't fill gaps, low resolution chroma channels introduce artifacts of their own.

This is spatial resolution, 10 bit color channels is quantization resolution of the values. Everything contributes to banding artifacts, which are just noticeable changes in values when that are meant to be perceptually smooth, but the luminance channel is the most important, which is why it isn't subsampled.

These are fundamentals of image and video compression and not unique to webp.

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

#357

Post by kmoser »

bawolff wrote: post #351
kmoser wrote: post #326

Earlier quoted context omitted.

> maybe the thumbnails are scaled at different quality levels??? Agreed, the WebP lossless version looks pretty bad when scaled by the browser. And since virtually no website/device shows images at their native resolution these days, that's something to consider. On the other hand, most people these days view websites on their phones, so those artifacts will be harder to see.

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

It's even worse than what you said: the 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.

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

#358

Post by gruturo »

jsnell wrote: post #277
gruturo wrote: post #206

Earlier quoted context omitted.

JXL is an image codec - it can afford to be less efficient (it's not! Other way around, rather) and not be hardware accelerated as its typical use case is not to present 30-60 images per second like in a video codec, it will not affect the battery life of a device in any meaningful way. Also, AV1 hardware decoding is far, far from ubiquitous so many users would not benefit at all from it. But - back to JXL vs WebP: I…

What you're ignoring is that WebP is from the year 2010. JPEG XL is from 2022. Incidentally, JPEG XL is also a Google project, making your ranting about how bad they're at image formats pretty funny.

Hi! I'm aware that JXL partially originates from Google's PIK - and also Brunsli??, but I had indeed forgotten that WebP started in 2010, wow, 13 years old already.

I'll therefore correct my statement: "How could Google do worse than that??? When basically rezipping (with a modern algo) the existing DCT macroblock bytestream of a 18 year old codec beats your new codec, you should just trash it."

Also, Stuffit's SIF format is still 5 years prior to 2010 so that point stands.

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

#359

Post by edflsafoiewq »

karmakaze wrote: post #188

If I cared about archive image quality (and I do) , I wouldn't re-compress older images in a new format unless I could do so from uncompressed originals. Re-encoding from a lossy compressed source will make quality worse. Storage is cheap and getting cheaper. What would make sense is choosing safe settings for compressing new photos in the new format.

Okay, but that isn't really the point. You can start from a perfect gradient saved as a PNG and you will still see that WebP has visible banding at -q100 while JPEG is visually transparent at -q90.

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

#360

Post by __s »

Lossless webp is a good alternative to png. Why compare lossless eebp photo to lossy anything?

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

Post reply on HN