WebP lossy and WebP lossless often get mixed up. They are substantially different. While the former is mostly just outdated VP8 4:2:0, it is fast and more pleasing to the eye than JPEG at low quality and more practical there, given it has transparency. The latter is a pretty good option for ARGB images offering 25% improvement over PNG [1], and 20-40% on top of that with near-lossless compression.
People point out that WebP isn't ideal, that there are better alternatives etc.
All that may be true, but the most relevant factor here is Google and Microsoft backing WebP. Google has the power to push through its own inventions due to Chrome's market share. If you want less of that, use Firefox.
Meanwhile, Mozilla hasn't given up on better formats, as the article points out.
While I like a lot of the new capabilities of the web, I sometimes feel like it's Google strong-arming them into existence, and the rest has to follow.
Which makes Google Chrome a modern day IE. They push basically proprietary nonsense into the web that eventually gets scrapped or forced into being an open spec at which point its harder to redefine since it became a "works on my browser" implementation.
The original problem with IE was its implementation of early CSS drafts - an open standard with specs. They just picked the “wrong” version of such specs and pushed it with their commercial strength. Everyone else was then caught between the choice of implementing the real (better) spec, or lose compatibility with IE.
Similarly, Google now picks the standards it likes, and everyone else is caught between the choice of investing in those or lose compatibility with Chrome. Not much of a difference.
I feel that Safari (mobile one) is way closer to the IE6 status with its ban of competition on platform, lack of standardised features and heavy handed management.
You can easily replace Chrome, it's not even a platform default. You're forbidden from replacing Safari.
I'm not sure why you're voted down. Mobile Safari has thrown some really bizarre and awful bugs at a few projects I've worked on, and given how critical mobile experiences are these days, it's genuinely a pain in the ass. It's a very nice mobile browser for the most part, but what it gets wrong is enough to make me kind of loathe having to deal with it.
That's surprising. I was under the impression that it was already supported since they support WebM.
The Wikipedia article [0] says they started evaluating adding support in 2016. Following the source links to this bug report [1]. From a quick glance at the discussion there, it's not obvious to me that they've settled on adding in WebP support.
What we need is buy-in from Apple. Although I'd be much more excited about them adding WebM support so we can finally drive the last nail in the GIF coffin. Does anyone know why they pulled it out? If I had to take a shot in the dark, maybe it doesn't perform well on mobile or it consumes too much power?
Maybe this is a dumb question, but why will we be supporting both WebM and animated WebP? According to the Wikipedia article, WebP also has animation support.... But isn't that kinda redundant? Do they solve different problems? You can just create WebM containers without an audio stream.
While we're on the subject of adding new image formats to the web, does anyone know if there's any interest in adding FLIF support [2]? When it came out it seemed much more interesting to me, but it looks like it never picked up steam.
As an aside, can I just say fuck CNET? Here they used a shitty linking practice which I always find incredibly annoying. Instead of linking to primary sources, they add some useless tag links along with references to old CNET articles. How about linking to the relevant bug reports, asshole?
WebM uses more memory, it is less widely supported, uses more resources when playing, and is currently less efficient compression-wise than WebP.
About FLIF, I was recently checking it and it's indeed a very interesting format. Notably because it can be used on any type of image. I assume it hasn't pickep up steam because it doesn't have the backing of any big sponsor. Google is pushing WebP, and introducing another format at this time is probably not worth it.
FLIF is interesting, yes, but after doing some more research into it I came to the conclusion it doesn't hold any promise as an image format for the web.
The progressive streaming is a cool trick, but if you actually use the progressive stream to embed lossy images in your web page, you end up with lower quality than if you had just used JPEG in the first place, never mind something newer. The difference was pretty stark.
WebP is reasonably fast, this can't be said about the other image formats. I tested WebP, FLIF and BPG when I was looking for a PNG alternative and WebP seemed to be the best choice all-around. The only downside of WebP is that it doesn't work with images larger than 16383 pixels in width or height.
2^14 pixels in both directions with 4 bytes per pixel (ARGB) puts the pixel data at a maximum size of 2^30 bytes. Just barely enough to be indexed using a 32-bit integer (even a signed one if you want)
Looks like WebP uses RIFF data chunks [1] (which look a lot like the old Amiga IFF file format), and the size of such a chunk is a 32-bit integer. Besides, 16k width/height ought to be enough for anyone ;)
I take photos of trains [1] and regularly run into file format limitations as the photos can easily reach hundreds of thousands of pixels wide.
Besides, modern cameras such as the Sony a7R II are already producing photos 8000 px wide, and the upcoming 100 megapixel cameras such as the Fujifilm will do 12000 px wide images. It's very easy to hit the limit if you're planning to shoot any panoramas.
Sorry for the ignorant question, but what does it mean for a format to be "fast"? Does it takes less time to compress the image? and why would that matter in 99% of cases?
That's too bad. WebP was a bad idea released several years too early, now it's stuck with VP8 and the only color format is 8-bit 4:2:0 which is just not good enough. Please don't use it.
It's better than JPEG and PNG for most uses, with smaller image sizes. Even 4:2:0 is better than the sRGB usually used in PNG. I'd rather have this now than wait another few years for a few niche usecases (where TIFF can still be used)
Looking at CanIUse [1][2], it seems like the HEIF support is in macOS itself, and not the Safari browser. I wouldn't be surprised if the Windows version of Safari didn't support it.
Every format looks like a bad idea released too early when you're looking 8 years back at it. At least lossless WebP is better than PNG. Is there something better by now? Yeah, but 8 years from now when everything actually supports and uses it you'll have the same thoughts.
There is something better by now, so why add it now?
I actually don't think this about other formats - for instance MP3 is 25 years old and I think it's just fine to support it. It's patent free and its quality limit is all you need for many applications.
This isn't true for VP8, our eyes are just harder to please. (And On2 was never the best codec developer…)
Unless I'm mistaken, while AVIF may be "right around the corner", it's still quite a way off relative to the speed of technological advances. Unless I'm mistaken AV1 is very far from finalized or being a realistic option for the web, and as AVIF will effectively just be a still-image subset of AV1 it's going to take some time as well. (I'm still very excited about it, however.)
I suspect they might be motivated by the rapid way in which HEIF seems to be taking over. My understanding is that comparatively, the patent situation of WebP is much better. If you're a company concerned about software patents on the web, it might suddenly seem that throwing your weight behind WebP as a way of avoiding the proliferation of HEIF is worthwhile.
I think there are a couple bugs and contradictions between the spec and reference implementation that are being ironed out, but the bitstream is now frozen.
AV1 is enabled for video in the next release of Chrome, and the current release of Firefox has it behind a flag IIRC. The spec has been finalized since early this year, and the results are stunning: You can produce recognizable, sometimes perfectly passable, images at around one tenth of a bit per pixel.
Try the "clovisfest" test image here[0], with the most recent AV1 snapshot on the right, and MOZJPEG (the most advanced JPEG encoder on the market, AFAIK) on the left, with both set to the "Tiny" target bitrate (0.1bpp). Smooth, continuous grades look hideous on JPEG up to pretty high bitrates, and JPEG never quite reproduces hard edges or sharp specks properly; AV1 excels at both of these.
Indeed, strange that Microsoft decided to support WebP and not wait for AVIF [1]. Mozilla had said that if at least one browser in addition to Chrome supports WebP, then they will consider supporting it, so looks like they are just fulfilling that promise [2].
WebP has its drawbacks, like no support for HDR content. AVIF supports it and Netflix would like to use it for video thumbnails.
AVIF is primarily a lossy format, the place were WebP shines is in it's lossless mode. Being able to replace PNG as the de facto standard lossless format would yield better compression while still decoding and encoding faster.
I recall how much joy I felt when my company's IT retired IE 7 and force-upgraded everyone to IE 8. So much polyfills and crutches that we could get rid of... (It was about the same, to a lesser extent, when moving the minimum requirement up to IE 9. That's the point where I stopped thinking about browser support.)
similar market forces at play - apple users use safari coz it is the default browser so you have to develop for safari first not web first just like ms wanted you to develop for IE first not web first.
It's actually the only browser engine on iOS, all the third party ones are just skins on it with convenience features like syncing with their desktop counterparts.
Doesn't Safari support JPEG 2000 in exchange? And Safari was the one that introduced the newer picture element for enumerating responsive image choices (though to the dismay of HTML semanticists as HTML rather than CSS) wasn't it?
Not really, Firefox and Chrome supported the picture element well before Safari did. It was part of the nascent HTML5 standard.
I believe what WebKit introduced was the analogous CSS image-set property, which likely influenced the picture's element's development (but image-set still hasn't managed to escape draft-spec territory).
Patent complications do seem to be a factor, but it's unclear if in practice it'd be "loads of money", as the project page suggests many existing systems already have licensed decoding capabilities.
Also, one of the patent pools covering HEVC announced in 2016 that software-only implementations would be royalty-free:
Good to see Firefox join the party, even tough it's 4 years late.
Serving multiple content types based on the http accept header sent by the browser is easy to setup. [1]
So Chrome and Firefox users can benefit from the better webp compression while Safari and IE can stick to jpeg.
[1] https://wooptoo.com/blog/serving-webp-today/
I'd like to see the opposite; Browsers having support for more image formats, especially the legacy ones from 20+ years ago (PCX, ART, ILBM, MAC etc.). That way interesting and useful imagery from days gone by aren't lost forever when the few remaining decoders never get ported to newer operating systems.
This is fantastic to see. I hope Firefox will also isolate sites for better Spectre protection like Google did with Chrome. Takes more RAM but the added protection, IMO, is well worth it.
Had heard they are working on it. But had not heard a date?
Mobile web consumption is now the majority of web engagement. Given that, iOS Safari's reluctance speaks volumes. I bet this has anything to do with technology, and more with Apple's business rivalry with the open web.
Given how iOS Safari is the least standards compliant browser of our time (other than the now defunct IE), I'm surprised they even implemented webassembly & webRtc (they didn't implement the data channel)
I'm afraid not – none of the available demos seem to work, but I don't know why that would be the case. All I can say is that I worked with the technology pretty extensively, and was absolutely able to use a data channel between Chrome and Safari 11 on both desktop and mobile without any issues.
I'm sorry, this is not correct. Like I said, I used data channels in Safari on iOS only a few weeks ago, and I'm not making that up!
Since you're not convinced, I looked into it a bit more, and the reason most of the available demos don't work is down to a difference in behaviour between Safari and other browsers, probably to do with address selection for the connection. WebRTC can leak private network configuration in some cases, so Safari seems to be pretty strict in that it requires `getUserMedia` to be called before allowing a data-channel-only to be established.
I made this into a small demo (https://codepen.io/anon/pen/GYrqGL) and you can see after a couple of clicks of 'connect' that a data channel connection is established and works as expected. This is a bit of a privacy/usability tradeoff. But data channels are very much implemented in Safari.
[1] https://developers.google.com/speed/webp/docs/webp_lossless_...