That's because WebP focused so strongly on being a GIF equivalent that it also dropped all things that made WebM efficient and instead adopted GIF's awfully inefficient architecture (just dumb frames overlaid on top of each other, without motion vectors or predicted frames).
Safari shows how it can be done: it supports silent MP4/H.264 straight in <img>. You get all the ease of use GIF, order of magnitude smaller file, and hardware acceleration.
It's unintuitive, but well-compressed videos are cheaper to decode than dumb "animation" formats, because file size differences are so massive that it's cheaper to decompress a small amount of complex data than to chew through vast amounts of poorly compressed data.
Also worth noting that all the alternative browsers on iOS are just reskinned versions of Safari as well.
https://caniuse.com/#search=animated%20png
Edit- I was unaware the recently-announced Safari 14 Technical Preview adds support for WebP too! Making both formats viable for all browsers, finally.
Update: nope. Maybe another year :(
Or let me rephrase, why is WebP as a animated picture / video format insufficient?
Then, there's optim being made in WebP to allow fast jump to keyframe, even when there's transparency. Video codec don't allow that, and you can have an arbitrary long torture sequence of transparent frame that needs to be decoded back when the video comes in the view again.
Last, animation are usually low-fps (~10fps): there, video codec don't perform very well and are basically keyframes. So the difference isn't as great as one would think.
Oh, and hardware need a 'reset' between decoding tasks, to reconfigure memory, and decoding can't be parallelized.
<video autoplay muted> says the same thing.
In fact, JPEG 2000, which was standardized, in, well, 2000, already has transparency support, and 20 years later still have no meaningful support.
And you aren't breaking it. In a theoretical world where transparency got added to JPEG, software that doesn't support it will show a fully opaque JPEG (adding transparency in a backwards compatible way isn't rocket science). Compare that to using WebP instead, where software that can't handle it won't even show the image.
It's not theoretical. It's the JPEG XT spec. It adds alpha channel and HDR to standard JPEG in a backwards-compatible manner.
* A webp version with transparency, which won't be supported by most clients but the ones which do will support everything
* A JPEG version without transparency, or with "faked" transparency (i.e. baked-in background color), which will be supported by basically everyone but with less quality.
That way, if the client is capable of loading the "good" version it will, and if it can't then it will load the "good enough" version.
SVG is such an underappreciated technology that is in every browser. Why do icon fonts exist when you could just use SVGs just like you do PNGs and JPEGs? You can even inline them in your HTML so there isn't an additional HTTP request if you want.
Edit: Did some more research and the patent risk appears to have passed as of 2016. Still nobody seems to have interest in JPEG2000.
There is simply no reason why people in 2016 or now would be interested in a format from 2000 that was a patent minefield until at least 2016.
Are people just more cavalier about the patent risk these days? The problem with JPEG2000 wasn't the patents we knew about, it was the possibility of submarine patents. People were still wary after the GIF debacle. Nobody wanted to be charged $0.05/image after the fact when they've delivered literally billions of images. Plus the courts were seen as very favorable towards patent holders, even when they were acting in bad faith.
These design decisions all made sense when clock rates were exponentiating, but they're all nightmares now that we rely on branch prediction and memory prefetching and superscalar execution units. The codec is simply not a good fit for the computing architectures we have today.
Arguably not a good choice for the year 2000, either, considering that all high performance CPUs at that time were out-of-order, superscalar and deeply pipelined.
They've subsequently improved that — OpenJPEG is quite good now https://github.com/uclouvain/openjpeg — but probably missed the window for adoption barring a major upset, which is a shame because it's a very powerful codec and has some neat tricks like progressive decoding (imagine if you could have one file in storage and your responsive design simplify specified the HTTP range requests to get for successively large resolution images?). You could ship it in a browser using WASM but I think the browsers are — not without cause — being really reluctant to add new formats and the ensuing security risks without a good reason, and without browser support no format will be more than a niche.
Every iOS and macOS device supports JPEG 2000… that should be pretty meaningful.
As an example, we could talk about the number of connected IoT devices that are supported and up to date, and it's probably in the billions. But compared to the number of connected out of date and unsupported devices, it's likely inconsequential in comparison by metrics of total numbers, percentage of a whole, and importance (alternatively, total number of unsupported and possible exploitable devices does matter, because of what it implies about how they can be used destructively).
If you want transparent JPEGs on your web page that works.
Back then the number of GETs was really important, so stuffing the mask into the JPEG made sense. Now with our HTTP/3 and QUIC world that isn't such a big deal.You might be better off just using a CSS mask image.
There are some situations where transparency is legitimately needed but im not sold it can justify webp and all that comes with it.
They display an image. Bit if a weak argument to say they dont matter when theyre being used to create the same final outcome.
Raster graphics and vector graphics can't be compared because sure, you could create 2 million vector squares with individual positions, sizes and colors and align it into a 16:9 grid or you could just use a jpg. The latter being a fraction of the size and processing power needed to display it.
We're discussing transparency and the use case for it. I dont think ive ever heard of someone wanting transparency in a photo. The only times i see the need is if theyre doing something that is better off in a vector format. I.e. png, which is being supplanted by svg, which alleviates the size problems raised about pngs.
I.e. webp is a format solution in search of a problem.
Downvoted, wow, petty.
OK, but they do. It's pretty common for someone to cut out an object in a photo and have a transparent background.
JPEG "can't" do depth maps either, and yet it manages to do them just fine.
"Portrait mode" on Android is simply JPEG + greyscale JPEG embedded in metadata.
If anyone really wanted transparency, it is very easy to add it to JPEG.
That said, in practice, transparency is not needed in non-vector / non-generated graphics formats. The nature doesn't really have an alpha channel, photographs certainly do not.
Transparency is extra information, and can be passed along as such.
Even if transparency was add to JPEG right now, it would take sometime to become available everywhere, and you would have tons of legacy devices showing broken transparency.
The advantage of a new format that supports transparency from is interception is that every device that is compatible with it will display it correctly. So there is no issue with some devices supporting the format partially.
JPEG is optimized for photos, which don't have transparent parts.
SVG and PNG are optimized for graphics.
So, if you need transparency, WEBP is probably not the format you'd choose anyway.
It is pretty common to have anime characters where you remove the background to use as reactions, and while you can use PNG in those cases it makes the images huge. WebP makes it ideal for those cases, this is even the case that I saw this being used in some image boards (specially also including animation, another thing that is popular).
Just because you can't think in a use case there isn't mean that there isn't a use case.
Not only does the best JPEG encoder perform as good if not better than the best WebP encoder. With a JPEG Repacker [1] JPEG file size could easily be 20% smaller. If you have to support a new format with relatively little benefits, why not just support using the repacked instead.
You'll probably know this already, but Brunsli made it into the JPEG XL standard. I'm quite happy about it!
[1] https://en.wikipedia.org/wiki/Joint_Photographic_Experts_Gro...
TL;DR: We're now at "Draft International Standard" stage; soon we'll enter "Final Draft International Standard" stage and at that point the bitstream is effectively frozen and adoption can start. The officially ISO-published International Standard will take until first half of 2021, but the codec should be ready to use before that.
Its only appeal is that it's royalty-free, but since all devices that support VP9 decoding also support h.264, is it really worth it?
MP3 is competitive with AAC and far more compatible, if you use LAME. Same with JPEG and WebP, or x264 and VP9. All 3 of those encoders deliver higher quality AND better encoding speed than their competitors.
Switch encoders before you switch formats.
There exist other VP9 encoders, but all for specialized purposes.
No, it did not.
> whereas libvpx did not see the same kind of love and most of the work came from Google's employees.
You're getting your facts wrong: x264 was developed by a very small open source community, with at most 5 developers on it, on their free time, while libvpx got quite a few people from Chrome Media Team paid to work for years on it.
AFAIK they don't? They use some of the metrics which are provided in Lighthouse (Largest Contentful Paint, First Input Delay, Cumulative Layout Shift) all play a role in ranking, but the score itself is meaningless.
There's been some level of performance weighting for a while (but only very slight and mobile-only), but I don't actually know what metric they were using for that (this was from ~2018, before any of those metrics landed in Blink).
Could you share your comparisons? From the ones I've seen, it looks like WebP significantly outperforms JPEG encoders[0].
[0]: https://wyohknott.github.io/image-formats-comparison/#endeav...
So the only place they can target is where JPEG starts to break down: When you've cranked the quality knob down to 20 and you're seeing macroblocks and other artifacts in the image. But this is a niche use case as network speeds continue to improve every year.
The worst part is that they have to compete with free, and that's never easy, especially if you're talking about "well, it's still distorted, but the distortion is less displeasing to the eye", also you need to configure some pain in the ass licensing system and work out how to do the payments.
Because a great proportion of people browsing the web have slow connections and/or data caps.
> How about more quality and the same filesize?
We're already able to get acceptable quality.
That doesn't matter one bit. See "webpages are doom".
>We're already able to get acceptable quality.
Apparently not when some examples are worse.
Even if the above were just an individual... bafflement? and not an actual issue, the size savings really don't seem worth the compatibility hassle, the extra manpower/workflow complexity to support 2 formats, the additional storage (and caching) caused by this duplication.
And the above is if it's done RIGHT. 80% of people outside this forum won't understand that you're not supposed to convert from a lossy format to another, and just convert jpegs to webp.
Webp seems so pointless. A progressive jpeg with an optimized Huffman table can be understood by a 27 year old decoder without issues, achieves 90% of the quality/size claims of webp and can be produced losslessly from your source jpegs. This is without even touching Arithmetic Coding (also lossless, part of the official standard, but poorly supported due to some software patents, even though they all expired by now), or playing with customized DCT quantization matrices to get more compressible outputs (incurs a generation loss, but produces standard files).