Ecosystem being slow to adopt it is something that can be fixed or improved, but also more importantly (given jpegxl & avif comparisons) are things that will impact any new image format.
Meanwhile annoyances of the codec tend to be things that are dramatically harder to deal with. Like HEIC being a license minefield and also slow as shit. Or that many of these newer image codecs do not have ways to work with them in a memory efficient manner like jpeg does (see eg libjpeg-turbo's sample size & skip scanline options). Or WebP insisted on being in a RIFF container for... uh... absolutely no fucking reason whatsoever afaict. Fortunately RIFF is so trivial that this overhead doesn't actually matter in practice, but then HEIC & AVIF dials up the annoying container bullshit to 11 thanks to their video heritage with ISOBMFF
A 'RIFF' chunk containing formtype 'WEBP' and a mandatory 'VP8 ' or 'VP8L' chunk, and optional 'VP8X', 'ICCP','ANIM', 'ANMF', 'EXIF', 'XMP ' chunks and possibly some unknown chunks, where if any of these optional chunks appear 'VP8X' must be first, and with certain ordering restrictions on the chunks.
It is true that earlier spec versions only allowed the core 'VP8 ' or 'VP8L' chunk, and the spec does warn that some older software might not support files with the newer chunks, so they should only be used if really needed for best compatibility.
How much slower? I'm finding very conflicting numbers.
But on the timescale of "wow this still doesn't support webp" those patents will solve themselves soon.
software-decoded HEIC is around 100x slower than JPEG.
WebP is something like 20-50% slower than JPEG, so still solidly an order of magnitude faster than best case hardware-accelerated HEIC decoding.
I heard this argument against WebP about 3 times, each time I asked people what software exactly do they use that doesn't support WebP, they told me, I checked the support (downloaded the software and opened/edited WebP file), and it did support WebP.
I deemed this "I hate WebP" just a comment bait argument in social networks.
> I deemed this "I hate WebP" just a comment bait argument in social networks.
Go try adding a webp image to a Google doc and then reconsider your position.
Lacking support for WebP or for other common media is a flaw of a specific service.
Many websites accept videos only in mp4 + h264 + aac audio for some reason, while there are many other video formats and codecs which could be used on the web and in general. That doesn't mean the other formats or codecs are worse or annoying.
You have now seen evidence of poor webp compatibility. It exists. The people you said were making it up to bait you into commenting were probably being sincere. That's the entire point of the comment. The end.
I was curious because I use WebP pretty extensively for many years, and haven't seen any issues with it.
I don't consider web services to be a software. It's no news that many services don't support wide variety of formats, it's their decision. Missing WebP support is a minor inconvenience compared to other missing features of web services.
The article is about self-hosted website as far as I understand, so it doesn't matter what the external services support or not.
Though TBH I still use JPEG, PNG, or GIF, depending on use case, out of habit. The size saving for the same quality of lossy compression is not something I've found myself hankering for. It is different if you run a site that sends out millions of every image, but nothing I do is that popular and is never likely to be, and no one stuck on a really slow connection where the difference would matter to them is going to be accessing my stuff.
That is true in life.
EVs aren’t annoying, the charging infrastructure is.
Etc
OTOH, being able to charge while you are sleeping or working is pretty convenient.
Alternatively, my buddies EV does 700km to a charge. I’m not driving 7 hours straight without a good break.
I've owned EVs for a decade, and I've never actually waited for one to charge.
Both times I absolutely did notice the slow "refueling" times, but for 95% of my driving "around town" it is _so_ nice.
This feels like another point where people may not think about how this works in the real world. Sure, you may only have a regular plug for your car, but how long does the car stay in the garage? If you work ten hours a day, it's in the garage for 14 hours, which is plenty of time to charge the battery even if you have an hour+ commute and a slow charger.
Even going as fast as I can on a small car (45l tank), it takes about 6 minutes.
BYD flash charging is very close to that.
I've also encountered issues with some Linux distros not shipping webp support by default for their image viewers, for some reason, but it's been a while since I've set up a new Linux env so hopefully that's been fixed since.
A decoder can and should just do both. A MIME type/extension never really indicated what the contents are like, it just indicated the common restrictions of a file format.
You can't even know if a .bmp is lossy or lossless because of the palletized options and the many different pixel sizes available to the format.
You can usually guess most features for some file formats most of the time, but modern all image file formats have these optional features.
I personally avoid webp because of the tooling/compatibility issues.
Do you have a reliable source you can share which supports that claim?
Windows 10 is over 10 years old now
>I've opened both .webp and .avif on Windows 10 22H2 in Standard MS "Photos", "MS Paint", "Paint 3D" applications before posting the previous message.
>Just tested in older Windows 10 21H2, and yes, in this version Paint doens't open webp
That’s the whole point, though. If the tools I use don’t handle it properly, it’s annoying. Saying it’s an ecosystem problem doesn’t change that.
How long has it been now? And from what I’ve seen, even Google’s own stuff doesn’t always handle it. That’s not helping their case.
I appreciate Google isn't a monolith, but that lack of consistency makes it really hard to shake the impression certain tribes within it are at war with each other.
https://www.globalnerdy.com/2011/07/03/org-charts-of-the-big...
Switching all my images back to jpg solved it
Contrast this to, say, Apple - which when decides to push something, they go all in. And that's an example of top-down decision making.
I speculate the asymmetric push is a case of it solving Google’s problem (bandwidth cost) but not the end user’s problems (battery and latency).
Even formats like H.264 are being dropped from some hardware decode engines because it’s so easy to do on CPUs now, as can be seen even on the Raspberry Pi 5. Many software stacks will skip hardware JPEG decode even when available because it’s extra maintenance and debugging overhead for such a little gain.
Progressive decode is a feature that is good in theory but rarely used in practice. If you’re concerning yourself with power usage and memory footprints, progressive decode goes in the opposite direction. Users also don’t like progressive decode as much as developers think they will as it’s often perceived as something being broken.
I think WebP made reasonable tradeoffs for the way images are actually used and delivered.
CPU decode efficiency most certainly was not the reason h.264 was dropped on the Pi
And while hardware image decoders might be dubious, hardware video decoders are very much worth it.
Most photo/design apps don't seem to be using SOTA jpeg encoders, though, so I think webp looks better in comparisons like OP's than it actually is. You maintain all the ultra-fast decoding of jpg when you use a modern encoder, too.
It’s not always used when available. It can be a lot easier and safer while being fast enough to do it on the CPU. If the operating system has an image decoder path that will handle everything for you then it might be used (Apple hardware for example) but if you have to go out of your way to implement the API, common software will favor software decoding because nobody wants to maintain code testing branches for different hardware image decode platforms.
Are you arguing more people should turn it on? Or that it would be bad to?
Using it in a web-browser 360 panorama viewer enabled pretty substantial latency and storage improvements.
close to 4x iirc.
ditto large "xray" style orthographic images of building scans generated from pointcloud laser scan data.
avif was even better compression for some cases, but seems to take a long time to generate, and less widespread browser support. Will look at jpeg-XL .. but Im guessing it will be a while until it has widespread support
In JPEG file size grows exponentially with quality, which also means that "I can't tell the difference" decrease in JPEG quality makes a huge difference in file sizes.
By contrast, when using a modern format like WEBP or AVIF, a single encoder configuration produces decent looking results across a variety of input images.
The WebP encoder just has a switch when quality=100, then use the PNG-like format in .webp, otherwise use the JPEG-like format in .webp. WebP at quality < 100 will destroy text, sometimes worse than JPEG, because VP8 can't store color at full resolution. WebP at q=100 will blow up photo sizes by orders of magnitude, similarly to PNG.
AVIF and JPEG XL actually have ability to mix-and-match blurry and sharp compression modes within a single image.
Especially for animated images. Comparing webp or avif sizes to gif is easily a factor of five to ten when animated.
Encoding is a pain, to be sure; I ended up creating a workflow where my source would save things as PNG files (giant, but lossless) then running a avifenc (https://github.com/AOMediaCodec/libavif) to produce the avif, and trashing the PNG.
Decoding though, all browsers have support, it's great.
I don't delete my original source images, in case if I want to change the encoder parameters later, or if a newer encoder version improves quality.
Which is HUGE since it allows you to embed them wherever you can embed images. I'm still mad that browser vendors didn't just allow silent looping videos in <img> tags instead of giving us these animated image formats with weirdly gimped non-keyframe compression.
It feels more practical now to have a fast loading page with large images now without too much effort. It was far too much of a burden before to have to provide fallbacks to older formats, on top of different images for different screen sizes/densities.
I honestly think that all phones and even professional cameras should replace JPG with WEBP, we will have like 30% smaller photos.
The DNG format (for raw photos) allows JPEG XL compression (it used to allow only JPEG in the past). I wish some country made it mandatory for cameras to let user take photos in DNG (just like USB-C is mandatory in the EU).
I am happy that HEIC from Apple did not take off (as it was proprietary, protected by patents).
> I am happy that HEIC from Apple did not take off (as it was proprietary, protected by patents).
Canon, Nikon, Sony, Panasonic, and Fujifilm cameras all shoot HEIF these days.
I remember moving on to PNG when that was implemented in most browsers and suddenly you could do gradients that end in transparency...
[1] https://stackoverflow.com/questions/1852467/alpha-transparen...
> I’m wondering if/when newer standards like ... AVIF will be supported by Pixelmator Pro.
I'm assuming it would take a bit longer to deploy the site and having 2 or 3 different versions of the same image would use more space, but it shouldn't be hard that hard to use AVIF, even if Pixelmator doesn't support it at the moment. It would also ensure that those with older browsers can still view the image, something that won't happen if we only have AVIF or WebP.
Go straight to jpeg xl and/or avif when the they are mature.
Note that this is changing rapidly. Safari ships JXL, Chrome did a few days ago, and Firefox will in the next few days. Once this flows through to all the chromium based browsers we will see pretty much 100% support on the web.
Many image links that work for search engines don't work for the site and I have to download and then upload to a host to get an embeddable image link.
AVIF on the contrary has great animation support. It's essentially a AV1 video without sound, but with all the benefits of <img> browser tag.
https://files.catbox.moe/blnad2.avif (334 KB, 35 seconds, 352×352 18 fps)
I'd probably go avif/jpegxl today, but webp was ahead of it's time.
Globally seen connections get faster and storage gets cheaper and we have huge amounts of tools for dealing with PNG and JPEG, so what's the deal?
Sure, use images wisely, compress them accordingly, deliver images in the right size, that's all important stuff, but you have to do that with WebP, too.
So after all those years, I don't think WebP is really solving a problem that needed solving or am I missing something?
And I don't want to be wasteful, but I'm wondering if we are optimizing the right things, when we are throwing established toolchains overboard to save a few kB while we probably could be saving MB in other places.
The other annoying thing is the name, because surprisingly we use images in non-web-related contexts as well. Admittedly, PNG technically has a very similar issue, but it’s less in your face.
I mean really, really long. Hard lessons learned
