Literally, you answered your own question. From the user end, unsupported file types of any frequently shared format are garbage. No one cares on the user end about server space. They care about sharing a funny image. They don't care about 2 extra ms of load speed. They want shit to just work.
It's the same reason Open Office sucks. You can't rely on it to just work. As much as dev's hate it (myself too), reliability is king. Webp fails this measure, badly.
Semi-related, I'm still salty about Google's rejection of JPEG XL. I can't help but remember this when webp discussion crops up, since Google were the ones who created it.
Don't know, many possible reasons. In fairness, even Mozilla hasn't decided to fully invest in it, and libjxl hasn't defined a stable public API yet.
That said, I don't believe that's the kind of issue that'd stop Google if they wanted to push something forward. They'd find a way, funding, helping development, something.
And unfortunately for all of us, Google Chrome sort of... Immensely influences what the web is and will be. They can't excuse themselves saying "they'll work on it, if it gains traction" when them supporting anything is fundamental to it gaining traction in the first place.
You'd have to believe Google is acting in good faith for the sake of the internet and its users. I don't think I need to explain why that's far from guaranteed and in many issues incredibly unlikely.
Useless mini-rant
I really need a single page with all this information I can link every time image standards in the web are mentioned. There's stuff I'm leaving out because writing these comments takes some work, especially on a phone, and I'm kinda tired of doing it.
I still hold hope for JPEG XL and that Google will cave at some point.
Ah no worries. I found it a little bit difficult to believe that the decision wouldn't be questioned by the company if it didn't align with its overall goals. That would be weird.
Not sure what you mean by "Google killed it". JPEG XL proposal was only submitted in 2018 and it got standardized in 2022. It has a lot of features which are not available in browsers yet, like HDR support (support for HDR photos in Chrome on Android was only added 8 months ago, Firefox doesn't support HDR in any shape at all), no browsers support 32 bits per component, there's no support for thermal data or volume data, etc. You can't just plug libjxl and call it a day, you have to rework your rendering pipeline to add all these features.
I'd argue that Google is actually working pretty hard on their pipeline to add missing features. Can't say the same about Mozilla, who can't even implement HDR for videos for over a decade now.
Yeah, why keep a feature which doesn't work? Once they add missing stuff to the renderer, they'll add XL support back. But I guess that will take a few years.
Just imagine if there was an actual open consortium not spearheaded by monied commercial interests that could temper recent Google decisions. They've lost a lot, if not all, of their goodwill with old guard, open web standards nerds. And the old guard that still actively support their standards influencing schemes now make too much money to stop.
Sorry, is this comment meant in jest? If not, could you explain what exactly you mean by "no need for a converter?"
I'm pretty sure that's not how it works. No actual file data conversion is happening when you do that unless you're using additional tools e.g. browser extensions.
Hey, thanks for the input. I'd like to read more about this, but I can't seem to find anything related online. Anything else you could share?
Just checking, you sure you're not confusing fallback-to-another-format when the browser doesn't support webp? Because that's a bit of separate issue, and not a terribly relevant one since all major browsers have supported webp for a while now.
I think I know what you're talking about, and I think you might have misunderstood a few things. I'll explain my point and I'd appreciate it if you could confirm later whether it helped, or if I'm the one who misunderstood you.
"Saving as..." is, usually, just for setting the name of the file. The full filename, extension included. The extension is just another part of the name. It doesn't define what rules the file's contents actually follow. They're for other purposes, such as helping your operating system know which software to use when opening each file. For example:
User double clicks a .pdf
System: Oh, I should try opening this in Adobe Acrobat.
But that doesn't mean the file is actually a PDF. You can change the extension of any file, and it won't automatically be converted to that extension (unless a specific feature has been added to make that implicit conversion). You could give an executable a .pdf extension and your system might then try opening it in Acrobat. Of course, it won't work—there's no way the system could have automatically made that conversion for you.
So you might wonder, why does your (fake) PNG—which is really just a webp with an incorrect extension—still work just fine? You can open it, view it, send it. What's the trick?
Thing is, the software that actually deals with those files doesn't even need to care about the extension, it's a lot smarter than that. These programs will use things like magic bytes to figure out what the file they're handling really is and deal with it appropriately.
So in this scenario, the user could save a webp file as PNG.
funny cat.png (still a webp!)
Then they might double click to open it.
System: How do I open a .png again?
.webp -> try the image viewer
.jpeg -> try the image viewer
.png -> try the image viewer (there it is)
And finally, the image viewer would correctly identify it as a webp image and display it normally.
The user might then assume that, since everything works as expected, they properly converted their webp to a PNG. In reality, it's all thanks to these programs, built upon decades of helping users just make things work. Same with Discord, Paint.NET, etc. Any decent software will handle files it's meant to handle, even if they aren't properly labeled.
If you were to check the file contents though, using a tool like file, czkawka to find incorrect extensions, or even just checking image properties, it should still be identified as a webp.
I didn't try it myself as you said because, to my understanding of files and software, doing so made no sense. But again, do tell if I got something wrong or misinterpreted your comment.
Are you sure? Maybe your image viewer adapts to the magic number and recognizes the webp file as webp anyway. I believe the formats are fundamentally different.
Note: this DOES NOT convert the file (obviously) although it will force it to be 'usable' in certain cases. If you bring the same file to a program that cannot work with webp format (ex. Da Vinci Resolve), it will crash or not show. To non-creators this is not an issue, but for creators: have fun figuring out which images you've saved are actually webp and won't work later on.
I know webp has become much less annoying after windows finally added webp support to photos after w11, so 'advice' like this tends to work more often than not. Just use a browser extension and convert it properly if you intend to spread an image...
On Android, use Share image from Firefox or similar, then click the edit icon before sharing (on the share sheet that pops up), then just immediately share without modifications. It'll share it as a new PNG I'm pretty sure. Dang Facebook Messenger that won't accept WebP and I have to do this so many times.
Cinnamon hasn't been keeping up for years. When I tried Mint again when I went full-time linux last year, and found the same unfixed bugs from three years prior, I ditched it forever.
The format has been around for 13 years, and is objectively superior to its predecessors. By now it is actually set to be replaced by avif and jpgxl which are even better.
At this point running into cases where it doesn't work makes me question the software, not the format.
No offense but Mint is not a great example. They are behind in general. Still figuring out Wayland, fractional scaling and VRR, things which KDE has supported in stable releases for some time now. KDE even is getting HDR along with Cosmic and SteamOS, something Mint isn't even close to. Mint kernels are older than Ubuntu's, which are hardly new. I used to love Mint, but they are falling further and further behind KDE, Gnome, and System76 (PopOS and Cosmic). To me it seems the new distros for newbies are Fedora, Debian, and a few derivatives like Nobara, UBlue, and PopOS.
I hate it as much as anyone else at the moment, and maybe I'm just an optimist, but once more support starts rolling out I think it's going to be great.
None of my friends had Signal and I've only been able to convince two of them to install it. They only use it to message me. Some have WhatsApp, but most use only Instagram or Facebook Messenger, which both don't support my .webp memes.
Linux and Android handles .webp just fine tho, in windows try open source image viewer like imageglass and everything gonna work just fine, speaking from experience i had, just as most people here i hated that webp doesn't open until i understood that open source image viewers handle it just fine, then i liked that file format cause it's versatile i mean, it can be picture or animation like gif, and compression feels better
I can't speak for all distros and DEs, and I also don't do many image related things, but I'm using Linux Mint Cinnamon and the default desktop background manager doesn't support .webp. Sometimes I see a cool image that I want to use and I have to convert it; other times, when I notice it's .webp, I just give up on that image.
Pretty much everything supports it now, and in case you haven't noticed pretty much all the images on Lemmy are webp because it lets instances save tons and tons on bandwidth and storage.
The next "better but not yet supported" image format is .avif.
Now we just need a Brennan Lee Mulligan flavored fully charged rant about the billionaire class of corporatists forcing webp with its patent encumbrance on us all.
I actually decided to use avif on my project. But both this and webp is as fast as I know, not supported in any default image viewer on windows. Which is rater annoying, but I moved on to better programs for tgat anyways.
Avif is second to jxl though, some of the downsides of being a video format is that you loose progressive loading (only top to bottom iirc), degrades on re-encodes, and some other things I can't think of. Avif gets a win because if you have a av1 decoder you already have a avif decoder too! But since it is a video frame essential there are some downsides since some image specific features can't or won't be added.
Not the end of the world, but out of the few apps that don't fit in the 'pretty much everything' group, messenger is one of them and I can't share a good bunch of memes on Lemmy with my friends because of that. I usually end up screenshotting my own screen because of that.
Every time I have to fire up my Fb account, I'm stunned at how shit React is. It's appalling how bad that framework has become. Maybe if they cared about implementing solid code and less about raping your life of metadata in order to sell you the worst products on the planet thru their "partners" things would be better.
What doesn’t support avif? Even Apple devices support it and they are usually the last to adopt anything. I’ve crushed all my website using it and it turns a 1MB image to 80KB without quality loss, absolutely amazing compression!
In websites it works great, there isn't a browser around that can't deal with it. Same how with when webp was new you'd run into it all over the web because there they were just better and worked fine.
It's everything else that isn't ready yet. My older android device can't deal with them in apps, no AV1 decoder maybe? Dunno.
Not many processors have AV1 hardware decoders yet (Apple thru them in on their M3's last year and latest iPhone 15 Pros) so I can't see it being that. There's also software decoding that works fine. My wallpaper on macOS has been avif since last year (Sonoma) and works without issue. I don't think it works in Windows 10 tho. No issues with the latest Ubuntu and I'm not familiar at all with Android OS.
In any case, I think it's the best thing to come out in a long time. My website with raw PNGs was about 120MB. I crushed those PNGs with noticeable quality loss down to 50MB. I then crushed the original 120MB down to 60MB with minimal to no visual quality loss using webp. But I got it down to 25MB without loss using avif at 85% compression. Just insane performance, couldn't be more impressed!
Okay can someone please explain why Facebook Messenger on my phone keeps saying it can't support gifs? Yes yes I'm an old man, but on the other hand what the fuck, fucking gifs? Are they devolving faster than Google?
(Also like, the gif feature built into Facebook Messenger itself. The longer I think about this problem, the more I think the app is just throwing the wrong error)