and by pouring out i mean drinking it.
💀
@icedquinn
I do wonder what Google were thinking with pulling out support out of Chrome already, when they barely put it in, and it wasn't even a default feature either.
i really do not understand why google spent all the effort merging FLIF and JXL and making the whole format to completion and then just going
YEET they claim it's been out two years and not successful yet this is the level of dumb that is CDPR spending all the time fixing up the red engine only to immediately switch to UE5
@icedquinn
Let's be honest, there's wasn't any demand for webp either, and there still isn't that much. It didn't stop Google from pushing it VERY hard.
google pushes industrial amounts of images so it really gets the youtube costs down to ship webp thumbnails.
as my test just showed it's really massive savings. multiplied by howeverfuck many thumbnails get downloaded per minute.
@icedquinn
I saw, but the issue I always have with the webp tests, is that they're usually done with something like q75, compared with jpeg at >q90, and then they ignore the significant quality loss.
At the very least you should test both at same q, but even then webp can be so bad, that it needs a bigger q factor than a jpeg to achieve similar final quality.
@icedquinn
The defaults for webp usually lands around 75-80. Did a quick test for imagemagick, and it seems that with no quality parameter given, it defaults to 99 (tested for jpeg and webp). It's quite ludicrous how big of a file size difference going from q 99 to 100 gives. Definitely NEVER test any image format at q100. It completely skews any result.
>lowering quality made the image garbage in an instant
By how much did you lower. I'm sure going q65 or lower fucks it up a lot, but imo anyone going that low with any image format is just plain ol' stupid to begin with. 80-96 has always felt the sweet spot for me, for any image format I've tested. Anything below 80 has never been worth it.
>tends to fuck up the chromatics somewhat
Yes. Avif does the same.
lossless is always gonna be a bigger
than perceptive lossless.
i dunno what webp/avif are doing. i tried opening the spec but it was 800 pages.
@icedquinn
Webp/avif are kinda weird. Being video codec derivatives, I think they get to play looser with chroma and other stuff, because normally you'd get another frame in a split second that would compensate for the loss of information of the previous one.
But in a still picture, you never get that. Webp suffers from that. Avif manages to perform well despite that. Which makes me wonder, just how powerful a good, high quality encoded AV1 must be. I haven't had the pleasure of experiencing that to be honest.
someone did this with ETC where the official compressor just brute forces all the combinations of quadruplets and takes forever. so they just made some bullshit heuristics instead, and that one packs ETCs in real time (obviously not as good.)
depending on the size of your tiles nowadays you can just take a huge corpus of test images, break them in to blocks, and train some babys first convnet to predict which of the 30-something specific tools exist in an AV1 tile should be used on this particular part of it. i don't think any of the encoders do, though.
@icedquinn
jpeg doesn't have lossless though, and it still inflates a lot, going from 99 to 100.
webp, in imagemagick does seem to go for lossless at q100, confirmed.
i did find changing the error distance in jxl is less of a mess than the quality setting. lowering quality made the image garbage in an instant, but lowering error tolerance just made it progressively blurrier.
webp, video codec as it is, tends to fuck up the chromatics somewhat