sk65535

you know, industry / browser people talk to each other. But not necessary on social media. Or publicly.

For a recap of WebP history: https://bit.ly/image_ready_webp_slides

If you look at slide #14, you'll see Opera was an early adopter. Firefox published a "No" blog-post in 2013, and Safari removed WebP support from Sierra preview in 2016, eventually adding it back in 2020. Stuff happened.

And yes, when WebP was created there was a real, non-incremental, need for a Web-oriented image format. Nowadays, it's just incremental improvement on this idea for browsers.

(disclaimer: WebP initiator here)

AVIF is equivalent in decoding complexity, even in software. It's not order of magnitude different. Encoders OTOH can be as slow as you want them to be.

if you re-arrange you have to wait for the bitstream to finish downloading, and thus lose the 'display something early on' feature.

rule of the thumb: progressive JPEG costs ~3x more resources (CPU, memory) than baseline JPEG.

With baseline jpeg, you can blit the decoded blocks to screen directly and forget about it.

For progressive, you have to buffer the whole image (in DCT format!) and do the idct / color-space conversion on all passes.

iirc, back in ~99, Unreal Engine was doing dithering on the u/v coordinates (!!) for texture mapping instead of bilinear interpolation. They used fixed Bayer matrix.

This was quite faster, visually pleasant, and was adapting nicely to viewing distance.

Try freezing some close-up frames around 0:45 here: https://www.youtube.com/watch?v=aXA3360awec

Tim Sweeney called this technique "ordered texture coordinate space dither", apparently:

https://www.flipcode.com/archives/Texturing_As_In_Unreal.sht...

[one of WebP2 author here]

This 'new' WebP format is not radically different, but just pushes the same use-cases further (The web. Not archival. Not camera capture.), sticking to simplicity and usefulness.

10 years is a long time since WebP-v1, and techno has evolved since. We can go much lower in bitrate for still-good-enough quality, and that's what we're interested in exploring.

AVIF was designed starting from a video codec, similar to WebP-v1 in the early stages, and this has some drawbacks (that later we needed to correct in WebP, that was confusing). WebP2 is aiming at images-on-the-web right away, and not as an afterthought.

More details about the last 10 years of WebP and some WebP2 features: http://shorturl.at/BEMV8

video format usually take up too much memory: what you gain in efficiency costs in resources. Conversely, animated WebP are dirt cheap: one buffer only, written over and over.

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.

WebP version 2 is in the work at AOM: https://www.youtube.com/watch?v=zogxpP2lm-o

It is complementary to AVIF (which targets photo capture more than delivery over the web).

WebP2 is like WebP: keep it simple, with only useful and efficient features, no fancy stuff. And aim at very low bitrate, it's the current trend, favoring image size over pristine quality.

Progressive rendering uses ~3x more resources on client side. So, instead, better have efficient 300-bytes thumbnails in the header.