Hmm this is a bit odd given AVIF, but I wonder if it's more aiming at being a stopgap way of having small images that decode on CPU faster than AVIF, which would make sense I guess...
Announcement
Collapse
No announcement yet.
Google Is Already Experimenting With WebP2 As Successor To WebP Image Format
Collapse
X
-
Originally posted by davidbepo View Postwhy even do this? WebP is already good, for the best u want AVIF
As for WebP, its crowning achievement is that of lossless compression, where it outshines the de facto lossless standard PNG in every metric, and by the sound of it, they are improving on it in WebP V2.
- Likes 3
Comment
-
Originally posted by cl333r View PostNetflix doesn't seem fond of JPEG XL [1], in their huge blog they only mention it as a one short paragraph. Do you think both Netflix and Google engineers are stupid?
- Likes 1
Comment
-
I see a lot of comments here talking about using different formats, but I think they miss the obvious usecase for webp (and webp2). If you want to extract an image from a webm media file, you have a frame that is already encoded using a lossy encoder. Throwing that frame in to another random image format which is lossy will cause additional artifacts in the image which you want to try to avoid. So, by having an image format that works more inline with the webm media, it might be possible to reuse the first encoding used for the media, and hence avoid any additional rendering artifacts. Webp and Webp2 may never replace any of the big image formats, but maybe that was never the idea.
- Likes 2
Comment
-
Originally posted by cl333r View PostNetflix doesn't seem fond of JPEG XL [1], in their huge blog they only mention it as a one short paragraph. Do you think both Netflix and Google engineers are stupid?
Maybe they are politically or otherwise biased. Naturally, as both Google and Netflix are part of AOM, I could imagine a legal bias towards a technology that is protected by AOM — or just a bias towards a technology they have already sunk some manpower into.
Originally posted by cl333r View PostI suspect they're not, thus there must be something we don't know about or misappreciate.
- Likes 2
Comment
-
Originally posted by wswartzendruber View Post
JPEG XL's royalty status is murky at best. The reference implementation is available under an Apache-2.0 license, but going by the license text, only that implementation is covered as royalty-free.
Anyone is free to make alternative royalty-free implementations of JPEG XL, either by forking the reference implementation or by starting from scratch.
Of course it is impossible to guarantee that there will never be a patent troll who claims to hold patents relevant to JPEG XL. That is true for all royalty-free technology, also e.g. AVIF or WebP. But the actual contributors to the JPEG XL standard have made a strong commitment to making a royalty-free codec; in fact the Apache-2.0 license helps us to fight patent trolls since it contains defensive termination clauses exactly for that purpose.
- Likes 3
Comment
-
Originally posted by cl333r View PostNetflix doesn't seem fond of JPEG XL [1], in their huge blog they only mention it as a one short paragraph. Do you think both Netflix and Google engineers are stupid?
I suspect they're not, thus there must be something we don't know about or misappreciate.
[1] https://netflixtechblog.com/avif-for...ng-b1d75675fe4
We'll have to see whether or not Netflix will be fond of JPEG XL once JPEG XL becomes available as an option, i.e. once the bitstream is completely frozen and the library api and other tooling aspects are sufficiently stable. AVIF has the advantage of being available right now, but it also has its disadvantages.
I wrote a blogpost half a year ago to make a preliminary comparison of JPEG XL, AVIF and HEIC: https://cloudinary.com/blog/how_jpeg...r_image_codecs
- Likes 5
Comment
-
An issue with Google/Alphabet, or anyone else, designing an image format to satisfy their use-case is that it imposes significant costs on everyone else. While a 'better' still image format could well benefit Google/Alphabet by decreasing their storage requirements (and maybe cpu requirements), imposing it on the world via market control of web-browsers also means that everyone else's image processing software needs to support it. This is not cost-free. A benefit of a standards-based approach is that it is also a 'level-playing field' based approach.
Of course, one can have a philosophical argument about the freedom to not follow standards, allowing market-based competition to choose the winner (like, for example the battle between VHS and Betamax video standards), and in a free market, such arguments have merit. However, it is not a free market. I have started seeing sites that are 'best viewed with Chrome', or indeed work only with Chrome as a browser, which is pushing minor participants into being required to support whatever Chrome does.
The international standards process is by no means perfect, and can be gamed and subverted, with RAND as well as the shenanigans around the acceptance of ISO/IEC 29500:2008, however pushing 'standards' that benefit market dominant players is not compatible with a free market.
Basing still-image formats on video compressors will not give you the best still-image format.
- Likes 3
Comment
-
Originally posted by hellomoto View Post
Can you explain why?
In September 2010, Fiona Glaser, a developer of the x264 encoder, wrote a very early critique of WebP.[19] Comparing different encodings (JPEG, x264, and WebP) of a reference image, she stated that the quality of the WebP-encoded result was the worst of the three, mostly because of blurriness on the image. Her main remark was that "libvpx, a much more powerful encoder than ffmpeg's jpeg encoder, loses because it tries too hard to optimize for PSNR" (peak signal-to-noise ratio), arguing instead that "good psycho-visual optimizations are more important than anything else for compression."[19]
In October 2013, Josh Aas from Mozilla Research published a comprehensive study of current lossy encoding techniques[60] and was not able to conclude WebP outperformed JPEG by any significant margin.
Comment
Comment