Google Is Already Experimenting With WebP2 As Successor To WebP Image Format

[Jon Sneyers]

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.

Lossy WebP v1 is VP8-intra. I don't know what lossy WebP v2 will be, but it looks like it may be some kind of somewhat simplified / modified variant of AV1-intra.
Extracting a frame from a WebM to turn it into a WebP v1 will only work if the WebM payload is VP8, not if it is VP9 or AV1.

I don't know to what extent WebP v2 will be backwards compatible (will it still decode WebP v1 files?), but it's clearly a completely new codec and WebP v1 decoders certainly will not be able to decode WebP v2 files. In terms of a transition path to adoption, this will be tricky. Browsers that claim support for "image/webp" will probably only support WebP v1, at least initially and in a long tail of non-upgraded devices. Will a new IANA media type be registered for image/webp2 ?

Avoiding generation loss by being able to extract a video keyframe and turn it into an image directly without introducing extra compression artifacts makes sense, but I don't think it is a hugely important thing, not even for e.g. YouTube (the video thumbnails are not just extracted frames, they are also downscaled, so re-encoding to a different format does not make much of a difference).

I don't think generation loss has been a big concern in the WebP v1 or v2 design, or if it was, they didn't really manage to make it very resilient generation loss. In all the generation loss testing I did, WebP always turns things in the most spectacular mess when you do repeated encodes.

[hsci]

Google is caring about itself? The have a lot of ideas but seem merely apply to Google itself.

HTTP 1.1 -> HTTP 2 -> HTTP 3
WebP1 -> WebP2
TCP -> QUIC which is some kind of UDP -> HTTP3

Do we see wide, stable and long term industry wide usage? Investing work in adaption requires a significant improvement. I understand that Google needs to reduce the throughput within their datacenters but that is side-effect of being a monopoly. I suggest adding download buttons near to their YouTube videos

Actually I appreciate their improvements to video codecs. These are significant and worth all effort. VP8 was a great thing.
And VP9.
Which is followed by AV1. Well...

[skeevy420]

First they should change this ridiculous name.

Agreed. WebP is what I do to spiders in the woods.

[cl333r]

This is a reduction to authority, thus your conclusion is invalid. There indeed may be something I don't know about or misappreciate, but you will need to show what it is.

If we start playing this game we'll end up nowhere. Here: you arguments are also invalid because you didn't show enough proof.

[dpeterc]

Can you explain why?

Personally, I do not hate it, but it sure has some ridiculous limitations:
- maximum image size 16383 x 16383
- no native support for dpi (have to use metadata XMP or EXIF, which makes it harder to write and decompress in a single pass)
- no way to disable chroma subsampling; you can do it in JPEG by specifying 4:4:4 subsampling
- no native colorimetry support, not even a way to specify sRGB or AdobeRGB 1998 (have to use EXIF metadata)
- no support for alternative color spaces like CMYK or CIE Lab (TIFF has it)
- metadata at the end of file (make it harder to extract image information without reading the image; necessary for image browsers)

Most of these stuff was available for years in JPEG or TIFF before WebP was created.
This makes WebP ill suited for any archival purposes.
It is just a format for quick display on web, nothing more, nothing less. Which is sad, since with a little better design, it could serve many other purposes.

[cl333r]

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

From what I read in the blog:
1) Responsive design - it was 100 times more important 10-20+ or so years ago when almost anyone was on dial-up or so.
2) Legacy friendliness - it's just about jpeg images, almost anyone who cares about quality uses png or better to begin with.
3) High Fidelity - it's greatly overrated, in your case it seems a SCAM (and I don't mean to be mean), because I transcoded to WebP the original image from your blog called "Can you see this, how does it look?" and the result was pretty much the same quality as the original at half your size (21KB vs 53KB) whereas on your blog at 53KB your WebP image SOMEHOW looks much worse than the "original". WTF?
After finding this out I had no reason to read any further.

[Lanz]

Meanwhile Gwenview can't even open WebP, at least not on Arch with the WebP libs installed.

[cl333r]

Meanwhile Gwenview can't even open WebP, at least not on Arch with the WebP libs installed.

It can on Kubuntu 20.10

[pal666]

Yeah, and why bother creating a new WebP2 when AVIF is already finished and known to be better than WebP2?

surely they must have some promised benefits over avif, but they aren't clear from article. i'd like to see them if they aren't "controlled by google"

[pal666]

AVIF sounds hip but is objectively worse and less featureful than FLIF and its successor JPEG XL. It is royalty-free as well.

Unfortunately nobody seems to understand this and chase the shiny AV1-derived thing instead.

unfortunately you don't seem to understand difference between lossless and lossy compression