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.
Why care about JPEG XL?
Because it seems very promising.
source with details.
Rejection?
Google started working on JPEG XL support for chrome, then dropped it despite significant industry support. Apple is also in, by the way.
Why do that?
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.
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.
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.
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.
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.
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.
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)
I think Apple users have issues with Webm & Webp? But the issue here is using Apple products in the first place. Losing 90% of basic functionality is what you expect when using one of those.
All the memes I send to my friends on messenger basically come from Lemmy. I always have to download the image and use the phone image editor to crop it by one pixel. It then let's me save it, and it saves as jpg/png by default.
Skill issue, the only actual drawback is that some legacy systems whitelisted image extensions and haven't been updated. Even then just take a screenshot and upload that.
I don't know why, maybe because it's Sunday morning and I'm just drinking my coffee and browsing around while the rest of the house sleeps in, but this triggered a rabbit hole for me. I already have a lil plugin just for quickly saving direct to PNG or JPG when I right click a WebP in my browsers, but I SHOULDN'T GODDAMN HAVE TO.
WEBP as a wrapper (as coupled along with AVIF/AV1/VP8/etc) seems all about reassertion of corporate control of web file formats by pivoting codecs back toward patent encumbrance as a control factor, just without universal royalty hooks attached to anyone that touches even free and open software utilizing it. We were actually FREE of that bullshit for a short time. PNG has no patent encumbrance. GIF, MP3, MPEG-1, MPEG-2, MPEG-4 Part 2 all have expired patents and can be used freely.
[Don't get me wrong, MPEG as an org was and is pure corruption and greed, and MPEG-4 Part 2 adoption was fully diminished outside of 'free' circles based on their stated intention to apply a 'content fee' to the royalty requirements. It's obvious why VP8 -> AV1 had to happen one way or another to break their royalty cabal insanity, but it still doesn't taste good at all. https://en.wikipedia.org/wiki/MPEG-4_Part_2 ]
The consortium of companies behind WebP and AV1 are all taking part in the enshittification of the entire technology sector, from web sites and web apps, operating systems, and application ecosystems. Why would we ever trust them to not rug pull the 'irrevocable but revocable' patent license scheme? They only put it together in the first place to end run having to pay someone who was 'not them' any royalties for image/video/audio encoding.
Google hereby grants to you a perpetual, worldwide, non-exclusive, no-charge,
royalty-free,** irrevocable (except as stated in this section) patent license** to
make, have made, use, offer to sell, sell, import, transfer, and otherwise
run, modify and propagate the contents of these implementations of WebM, where
such license applies only to those patent claims, both currently owned by
Google and acquired in the future, licensable by Google that are necessarily
infringed by these implementations of WebM. This grant does not include claims
that would be infringed only as a consequence of further modification of these
implementations.
PNG was developed as an improved, non-patented replacement for Graphics Interchange Format (GIF)—unofficially, the initials PNG stood for the recursive acronym "PNG's not GIF".
AV1, VP8, VP9, and other modernized "open source" or "free" Video Codecs all appear to be patent encumbered.
This grant does not include claims that would be infringed only as a consequence of further modification of these implementations.
IANAL but what they're saying here seems to be "if you download our code and modify it and, with that modification, touch some other patent of ours we can still have your ass". That is, the license they're giving out only cover the code that they release. Which shouldn't be too controversial, I think.
The issue with codecs in general is that there's plenty of trolls around and coming up with any audio or video codec is probably going to hit one of their patents, so the best that FLOSS codecs can do is "we don't have any patents on this" or "we do have patents on this but license them freely, also, if someone else goes after you we're going to detonate a patent minefield under their ass". Patent portfolios have essentially reached the level of MAD.
Personally, IDGAF: Software patents aren't a thing over here. You only have to worry about that stuff if you're developing silicon.
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.
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.
The problem is AVIF. I mean I love AVIF (almost as much as JPEG-XL), but it doesn't work with anything except browser web pages, even after all this time.
My only concern with jpeg xl is... how do you know if the encoded file is losslessly compressed or not?
with jpg and png, one is lossless, one is not. But if all the files have a jxl extension, you can't know unless the encoder adds metadata for it, right?
I don't understand what people's problem with this format is except in the case of animated .gifs. I can view it. I can reupload it. It's still an image and it still works. The exception is animations. Animations always end up as a still image when saved in that format.
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.
But the best image format to download is the original one it was uploaded in, without the recompression of server-side conversion to a lossy webp which we're seeing all over the place.
Even if it wasn't, you could just convert it to .jpg if you felt strongly about it. Not as though there's a compatibility issue.
The complaint people are having is with resizing/manipulation after download. They want these enormous uncompressed files floating around on every website, in the off chance they plan to download it and manipulate it. 99.9% of the web needs to be full of megabyte sized image files for the 0.1% y'all want to play with.
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.
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...
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.
No I don't think it does but it works. Specifically I download webp pictures on pc and when I try to send them on WhatsApp it does not recognise them so I change the extension to JPG or PNG and it works it sends them and they can be viewed.