Thread 106281457

>Supported by every major browser
>Mandatory support in Android 14
So why is WebP still everywhere? There is no excuse to use that pile of shit.

>>106281457 (OP)
Is the file size not smaller on webp?
Also the vast majority of android users are using versions lower than that.
https://gs.statcounter.com/os-version-market-share/android

>transparency support
>animation support
>hires-friendly and photo-friendly compression

Why doesn't this site support it yet?

>>106281457 (OP)
AVIF-encoding is much more resource-intensive than WebP, which still makes WebP the format of choice for a lot of properties that ingest images in a live content processing pipeline instead of prebaking.
E.g. social media.

(I'm not kidding, it literally takes 2x the amount of computing resources. Which makes it awful at scale.)

>>106281579
AV1 hardware encoding is supported by nearly every major vendor besides Apple being a notable exception.

I've learned that image formats aren't as simple as they appear to be. For example AVIF is a terrible replacement for PNG/GIF and that's what Webp is good at. However the best image format to replace PNG/GIF is actually Jpeg-XL but being a newer than Webp means it uses more resources so adoption might not happen for a while.

Replacing JPG is where there seems to be monstrous amounts of bickering and squabbling however. Sometimes AVIF will produce the smallest file size, sometimes Jpeg-XL, and sometimes even Webp.

I don't know, to me personally it sounds like we're just going to be stuck with a bunch of different image formats but if weak hardware is a factor Webp to replace PNG/GIF + JPG to replace uhhhhh JPG seems like a good combo for now. Else Jpeg-XL + AVIF.

GOD it's such a drag they couldn't just build a fucking all-in-one replacement for all this shit.

>>106281716
>GOD it's such a drag they couldn't just build a fucking all-in-one replacement for all this shit.
JPEG-XL
>Replacing JPG is where there seems to be monstrous amounts of bickering and squabbling however. Sometimes AVIF will produce the smallest file size, sometimes Jpeg-XL, and sometimes even Webp.
JPEG-XL

>>106281729
we don't want yet another format of ANY kind, anon, not even the "it'll catch on! two more weeks!" kind
webp had to be shoved down throats for years and people still hate it

>>106281661
I personally hate hardware encoding because of the poor compression makes it barely any better than an older codec.

Like a really well done H.264 encode can actually compete with a hardware encoded AV1 encode. I know that's video but I imagine it's should be analogous to image encoding as well since video = series of images.

>>106281740
>we

>>106281751
i refuse to redeem your pet project file format, anon, and most will agree with me

>>106281762
>most

>>106281771
>all of humanity is a hivemind except you
whatever helps you sleep at night instead of spending it all regretting your donation to the meme format fund

>>106281661
That still doesn't scale well enough horizontally, sadly, and rather than go the GPU route it has prompted companies like Pulsar to create a custom hardware-assisted encoder that can be flashed to an FPGA. Look up "Pulsar-AVIF"

>>106282151
>companies like Pulsar
*companies like Bluedot
(Apologies, fingers typing faster than brain thinking.)

>>106281729
I used to think this was the solution but it doesn't seem much better than Webp at least for my images.

Webp
https://gofile.io/d/3MJMED

JPEG-XL
https://gofile.io/d/O6aR71

Both achieve around the same file size so I don't see the problem with using Webp desu.

>>106282299
JPEG-XL losslessly shrinks JPEGs. Nobody is using these formats in the wild to make more efficient lossless images (PNG) they're using them on a CDN to squash lossy images (JPEG)

WebPiss

>>106281457 (OP)
I encoded an image and its dark-mode counterpart to WebP and AVIF (all losslessly) and for light mode WebP was smaller but for dark mode the AVIF was smaller (or maybe it was the reverse)
So I stuck with WebP

>webp
>jfif
>avif
>jpgxl
FUCKING STOP

>>106284282
This could unironically be the new DRM. Goyim toyim won't dare pirate .jqvifp because nothing made in the last 10 years fucking supports it. The only way you'll be able to decode it is if you buy a modern day DRM and spyware infested kosher "smart" phone.

>image.jpg
>download it
>it's webpiss or avifuckoff
I let chatgpt write me a script so I can give it the URL and it gets the proper file, fucking ridiculous that this is necessary. I sent modified headers before but many websites just shit themselves completely

>>106284282
Either make JPEG support transparency or make PNG have smaller file sizes for high-res images.

>>106281457 (OP)
>Android 14
56.5% of devices are on a lower version
https://apilevels.com
I expected a worse score than that 2bh

>>106281716
OK Daiz

>>106285548
OK Daiz

So on a serious note someone actually tested this and yeah AVIF just isn't going to replace PNG anytime soon.

>>106283710

>>106285577
Dude nobody gives a shit about PNG, 99% of images on the web are lossy and AVIF dominates there

>>106287673
Yeah because PNG fucking sucks. Jpeg XL is the solution to that problem so we don't even have to use lossy slop anymore.

Why do you want to use lossy slop so badly?

>>106287709
But AVIF absolutely obliterates JewXL when it comes to lossless. JewXL is only slightly better for lossy photography. Why do YOU want lossy slop so badly?

>>106287772
Oh sorry I thought I was in a different but related thread lol

>>106283710

>>106287772
>absolutely obliterates

>>106288143
@grok is this true?

AVIF completely destroys photos. Encode a high quality human portrait with grain generated by cameras in dark areas to AVIF and watch it become a different photo altogether

>>106281457 (OP)
Turns out people who use video codecs for encoding images aren't the brightest

>>106287772
>But AVIF absolutely obliterates JewXL when it comes to lossless
anon, AVIF lossless is LESS effective than taking a bitmap file and putting it into a zip archive.

AVIF lossless is useless bloat, it's only increasing the attack surface and complexity of the format for no tangible benefits, because it is so horrid.

>>106281716
or just use webp everywhere
problem solved

>>106291043
webp is mediocre at everything

>>106287673
why are you lying?

>>106291043
Yeah I mean it would cut down on all the bandwidth being hogged by PNG and GIF but JPG wouldn't die. Pragmatically speaking it would still be beneficial.

>>106291125
I don't get this "look at me, I'm on a technology board and I don't know how technology works!" meme.

>>106291819
>I don't get this "look at me, I'm on a technology board and I don't know how technology works!" meme.
same,
It's the same retard shilling failed google formats every single day, getting BTFO the same every single day, but it won't stop him from lying and shilling.

>webp is much slower to en/decode than jpg, but results in larger files than jpeg-xl in all cases
>webp lossless is much slower than png, and results in larger files than jpeg-xl lossless in 90% of cases
webp is a bad option if you need performance and a bad option if you need small sizes, it is mid

It's almost as if all the formats that are based on video codecs are bad.

>>106285422
If it's about website use, you could also load a jpg as an image or background-image and then add a CSS clip mask from a separate png: https://developer.mozilla.org/en-US/docs/Web/CSS/mask-image

>>106291897
How is a 2021 image format (Jpeg XL) going to give you better performance than a 2010 image format (Webp)? Don't you realize how utterly deranged and unhinged this sounds?

OFC Webp lossless won't be as good as Jpeg XL but this is offset by lower CPU resources being used.

>>106291897
And again Jpeg XL is still the best replacement we have for PNG/GIF if you look at compression efficiency only but this is being dishonest with people as it's not the whole picture. You're going to drive people away from Jpeg XL with your bullshit dishonesty, think about that you mongol.

https://siipo.la/blog/whats-the-best-lossless-image-format-comparing-png-webp-avif-and-jpeg-xl

>>106281457 (OP)
Webp can do lossless bettern than png, avif lossless isn't functional because it was never meant to do that. So webp for lossless, avif for lossy, though I still provide a webp lossy fallback just in case

>>106292480
Webp + AVIF is such a weird combo imho. It should either be Webp + JPG or Jpeg XL + AVIF. Anything else feels like we're asking for another 12 image formats to be created...

Do you "people" have slow internet? I use PNG for everything.

>>106292936
If you are just a consoomer it doesn't matter for you but I only have a gigabit uplink on my server so if I used png for all images in my websites I'd need to rely on a cdn the moment I get significant traffic, it'd also be annoying to my users who are still using mobile data with caps

>>106293111
JPG is perfectly fine for lossy images.

>>106292936
>>106293111
I'm on mobile and have unlimited data but even I still think we should reduce file size of things so everything loads faster.

>>106293219
Depends on the image type.

>>106293219
Not really, it's a lot less efficient than avif and degrades a lot after a few reencodes, while avif doesn't degrade visibly even after millions of reencodes. Avif can also do animated images replacing the garbage GIF format, and supports transparency. Webp is a lot better than jpeg too (on average about 30% more efficient, supports taansparency, it does degrade more visibly after reencodes than avif but still takes a lot more to look like shit than jpeg) so I use it as the fallback.

Also webp lossless for the images that are better off lossless is significantly more efficient than png

>>106293111
Have you considered designing your websites with white users in mind?

>>106281457 (OP)
WebP is shit because it's used as a means of submarining. If I'm browsing a site and I see a file named 1755361129212977.png that I want to save, I'm expecting a PNG. Or if it's named 1755361129212977.webp, hey, great, I know it's WebP. But it's a middle finger when you expect to be served with one container and get a totally different one entirely.

>>106293630
How does that change the fact that my server's uplink will be the bottleneck? If my images are 1MB of size on average for example I can only serve 128 of them at the same time on my gigabit connection, a cdn will help but it wouldn't save me at a certain scale (and the bill for the cdn usage isn't free or insignificant after a certain point either anyway)

The real main reason most websites put effort into compression isn't for the users, the bottleneck is sending it to all the users, and in the case of platforms with lots of user uploaded media also storing it

>>106293840
It's funny that websites were fine serving pngs and jpgs for decades, on much weaker hardware with much lower bandwidth.
Meanwhile you act as if you are on a 56k dial up.

Your website should not exist. It is a (You) issue.

>>106294220
The scale of websites and the quality of the media the users expect has raised since then, you'd rather be getting the shitty overcompressed jpegs that most sites had back then instead of getting a much better looking image for that same size?

>>106292428
>>106292457
If you are too dumb to read and understand written words, there is no point to talk to you.

The argument made is that webp is neither the fastest one, nor the most efficient one. It is a mediocre compromise.
jpeg-xl results in the smallest file size, but is slow to encode.
png is the fastest, but is large.
In your graph, webp is over 4 times slower than png.

>>106294330
>the quality of the media the users expect has raised since then
Really?
I would say, it is the opposite. Thanks to google, it decreased.
Like a 1080p youtube video looks nowadays like a 480p video looked years ago, because it uses horrid AV1 compression.
A jpeg that get autoconverted into webp or avif, looks worse. It's literally a lossy-to-lossy conversion. So we lose quality here as well. But that doesn't stop google from pushing webp slop in their image search.
Back in the day, people listened to audio CDs, nowadays they listen to mediocre spotify.

And you, by shilling for lossy-to-lossy compression ALSO want to serve LOWER quality.

>>106294330
>the media the users expect has raised since then
Then the discussion is over, because only jpeg-xl has lossless transcoding.
There is no other format that can take an existing jpeg and make it smaller without losing quality.

>>106294369
Barely any websites ever took the uploaded files without reencoding them because the source was likely to be overkill for the web, even when it was to the same codec. Might as well do the reencode to a more efficient format that also won't degrade as much as jpeg on possible future reencodes

>>106294445
Most websites never took the source files without reencoding them so it doesn't matter, no one ever took your jpeg uploads without recompressing them to a size that looks like shit for jpeg, avif allows the quality hit to be a lot less bad if we stick with the same target size.
Of course jpeg xl is a lot better specially for reencoding jpeg photography archives without any quality loss, but it got killed by fagman for web

>>106294560
>actually, quality doesn't matter anyway
dropped, sage
kill yourself, Daiz, fingolians are subhumans

>>106294611
It matters but not the point of not reencoding overkill source files at all for the web, barely any websites ever allowed you to upload gigant jpegs without reencoding them. Jpeg xl would sure be nice to avoid extra quality loss while doing this but it got killed so what do you want people to do about it?