181–190 of 319 posts
Earlier quoted context omitted.
Shouldn't those patents be expiring soon? Edit: Did some more research and the patent risk appears to have passed as of 2016. Still nobody seems to have interest in JPEG2000.
It’s too compute intensive
Earlier quoted context omitted.
You can argue the toss over quality, but JPEG can't do transparency while WebP can. So if you need transparency, you need to compare the size savings to PNG, not JPEG. WebP is the clear winner there.
WebP also supports animation, which is important because GIFs are notoriously large.
2 years later
We have too many different formats! Let's make a new standard!
shrug
Earlier quoted context omitted.
You can argue the toss over quality, but JPEG can't do transparency while WebP can. So if you need transparency, you need to compare the size savings to PNG, not JPEG. WebP is the clear winner there.
WebP also supports animation, which is important because GIFs are notoriously large.
Every time I run an image comparison, the webp version looks worse and yet Google insists it's the same quality. It's baffling. 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…
It's the same situation with VP9. It's supposed to be a competitor to HEVC, but in reality lack of serious psychovisual optimizations in any of the publicly available encoders make it at best on par with x264 compression-wise, while being significantly more computationally expensive. 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?
Earlier quoted context omitted.
It’s too compute intensive
That's kind of scary for something developed in the 90s. It was originally run on Pentiums, K6s, PPC 604s, and the like and it's still too expensive for a Ryzen 7?
Earlier quoted context omitted.
It’s too compute intensive
That's kind of scary for something developed in the 90s. It was originally run on Pentiums, K6s, PPC 604s, and the like and it's still too expensive for a Ryzen 7?
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.
Earlier quoted context omitted.
You can argue the toss over quality, but JPEG can't do transparency while WebP can. So if you need transparency, you need to compare the size savings to PNG, not JPEG. WebP is the clear winner there.
If transparency was the main issue, adding transparency to JPEG sounds easier than coming up with a completely new encoding, especially a lossy one.
Earlier quoted context omitted.
How? Do you know how many binaries link to some old version of libjpeg? You're breaking 99.9% of the world and 80% of it is stuff that can't even be recompiled, probably. In fact, JPEG 2000, which was standardized, in, well, 2000, already has transparency support, and 20 years later still have no meaningful support.
On the web you can do it with SVG. https://github.com/leni536/trans_jpg
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.
Earlier quoted context omitted.
You can argue the toss over quality, but JPEG can't do transparency while WebP can. So if you need transparency, you need to compare the size savings to PNG, not JPEG. WebP is the clear winner there.
WebP also supports animation, which is important because GIFs are notoriously large.
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.