[flagged]
WebP is so great except it's not (2021)
241–250 of 411 posts
Re: WebP is so great except it's not (2021)
#242Earlier quoted context omitted.
> Where's our OLED PC 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.
Only on the unusual high-end gaming monitors.
OLED is overwhelmingly reserved to high-end TVs and phones as well, so I think that point is moot.
Re: WebP is so great except it's not (2021)
#243Earlier quoted context omitted.
It beat H.264 in terms of quality/size but not in terms of hardware support. This is why Google Meet is the laggiest video conference software, they keep trying to make VP9 a thing while the others stuck with H.264. And now there's H.265.
I remember doing bluray re-encodes back in that day. x264 was simply better as an encoder when compared to vp8 and you knew that at least in terms of software everyone had a compatible decoder in their preferred codec-pack.
Oh yes, with uh websites where you download said re-encodes, there'd always be a few uploads with weird encoding and the author screaming in the comments that it's better and you gotta use the bleeding edge VLC before complaining that it doesn't work.
Re: WebP is so great except it's not (2021)
#244I 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...
The author is complaining about the consequences of recompressing images, which are also black and white and have a huge gradient background, and also, the post is full of flaws. I don’t know, Hacker News is better as less of a Hacker Rants.
> which are also black and white and have a huge gradient background
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.
Re: WebP is so great except it's not (2021)
#245I find it interesting how many comments here (presumably from "tech guys") confirm what the author wrote: > 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…
While I agree with the rational component of the article (webp may be inappropriate for artistic photos) I had to force myself to read it. The "t" in the font screws me up completely, I tried twice to wipe the screen of my phone then thought that maybe it's a background picture getting in the way.
So overall I find author's aesthetic sense very questionable which contrasts with his high-moral-ground tone.
Re: WebP is so great except it's not (2021)
#246Earlier quoted context omitted.
I will respond to you since you posted about this so called "SINGLE IMAGE" three times in this post already. 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 Chr…
To make a conclusion about how a codec handles image features you need to to quantitative comparison across a big enough data set to make conclusions about any kind of generalized quality. 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…
> To make a conclusion about how a codec handles image features you need to to quantitative comparison across a big enough data set to make conclusions about any kind of generalized quality.
>
> 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?
Re: WebP is so great except it's not (2021)
#247I find it interesting how many comments here (presumably from "tech guys") confirm what the author wrote: > 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…
First of all, the tone of the article invites equally acerbic criticism. Calling devs “image coding douchebags” is not exactly going to win anyone over.
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.
Re: WebP is so great except it's not (2021)
#248I'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 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.
Re: WebP is so great except it's not (2021)
#249Just use mozjpeg and throw away webp.
Re: WebP is so great except it's not (2021)
#250So... 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 gradient they encode or is are all the common WebP encoders doing some kind of preprocessing pass that crushes gradients and munges luma?