291–300 of 411 posts
Earlier quoted context omitted.
OLED is overwhelmingly reserved to high-end TVs and phones as well, so I think that point is moot.
My base iPhone 12 mini from years ago has OLED, so do a lot of cheaper Android phones. Gaming displays are far less common than these.
Earlier quoted context omitted.
VP8 was never competitive so most of the energy went into VP9, which did beat H264.
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.
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.
> The examples are just bad. If you want to show something, screenshot and enlarge it to show the artifacts. Yes! Where's the red underlines and diffs? I can see the background banding, but the foreground looks the same at a glance except that some of them look ambiguously "off" in ways that could just be placebo. You'd think a visual artist would be more interested in visual communication and not just a wall of text…
After that it was pretty obvious what the author is talking about.
Earlier 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…
>Call me crazy, but I don’t give a shit about averages. For a gaussian "normal" process, probabilities say half of your sample will be above and half will be below the average (which is also the median in a gaussian distribution). If we designed cars for the average load they would have to sustain, it means we would kill about half of the customers. Instead, we design cars for the worst foreseeable scenario, add a safety factor on top, and they still kill a fair amount of them, but a lot fewer than in the past. [...]
>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. And that whole WebP hype is unjustified, in this regard. It surely performs well in well chosen examples, no doubt. The question is : what happens when it doesn’t ? I can’t fine-tune the WebP quality for each individual image on my website, that’s time consuming and WordPress doesn’t even allow that. I can’t have a portfolio of pictures with even 25 % posterized backgrounds either, the whole point of a portfolio is to showcase your skills and results, not to take a wild guess on the compression performance of your image backend. Average won’t do, it’s simply not good enough.
Earlier quoted context omitted.
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.
For me it's the horrible layout. For God's sake, stop making narrow columns of text. Having the text take up most of my monitor is much more pleasant to read.
Earlier quoted context omitted.
I must admit, I'm not sure why JPEG XL is viewed so favourably on HN, it's not something I know a ton about, but my understanding is that the big advantage of AVIF is that you can reuse hardware decoders built into devices for AV1 for the images. It being a strict improvement over JPEG is nice for the developers not having to go back to the source image for an upgrade, but that seems like a pretty small benefit that…
Then doesn't that follow the line of argument for why AV1 isn't being adopted, either? Namely, lack of hardware support? I can understand why jxl isn't a dominant web format, but I don't see where avif has any place being a web format currently.
Earlier quoted context omitted.
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.
The "t" or the "ct" ligature?
Earlier quoted context omitted.
I must admit, I'm not sure why JPEG XL is viewed so favourably on HN, it's not something I know a ton about, but my understanding is that the big advantage of AVIF is that you can reuse hardware decoders built into devices for AV1 for the images. It being a strict improvement over JPEG is nice for the developers not having to go back to the source image for an upgrade, but that seems like a pretty small benefit that…
AVIF kinda needs hardware decoding, because otherwise it’s considerably more expensive than the traditional codecs. Even with hardware decoding, I’m not sure if AVIF is actually faster/chaper—compared in https://jpegxl.io/articles/faq/#%E2%8F%A9speedfeatures , “AVIF” takes 7× as long as libjpeg-turbo to decode, and I don’t believe hardware en coders tend to bring that big a performance difference over software, but I…
> AVIF reduces the amount of traffic required, but will tend to consume more power. This is the general compression tradeoff.
Again, you seem to be ignoring hardware decoding. Dedicated silicon can be many magnitudes more efficient than doing something in software. To take an extreme example with a ton of effort into the efficiency: look at mining bitcoin on a CPU vs an ASIC. I'm not saying the difference will be that big, but it may well be worthwhile.
As to buggy/too much effort/cost of hardware, that's precisely why it makes sense to piggy-back on AV1, a format that already has a lot of incentive to implement in hardware, and the work already done to make it work well. You need that kind of compression for video, and people are putting in the effort to make it work well, so AVIF gets that effectively for free.
Earlier quoted context omitted.
This cuts against WebP more: all of Google’s marketing was “it’s a third smaller!!!!” and then when you looked they were comparing it to unoptimized libjpeg outout and using computational metrics like SSIM which only crudely approximate what humans notice about image quality. I did the same comparison the author did when WebP came out but used an optimized JPEG encoder and found the same conclusion: when you produced…
In what way does "anything cut" against anything when you do cherry picked single datum point comparison? There isn't a codec pair in this world where you can't make a cherry picked comparison where one of them is worse (I've done plenty of those).
https://calendar.perfplanet.com/2014/mozjpeg-3-0/
Even a decade later, however, Google repeats the 25-34% claim and their performance tools tell developers they should use a modern format, which by sheer coincidence means the one they invented rather than the best ones on the market.