lossy WebP compression / VP8 support

[HugoSmits86]

We currently only implement VP8L (lossless) in NativeWebP. The “lossy” variant is actually the full VP8 video codec wrapped as an image format, which means:

• Completely different algorithm: VP8 uses DCT transforms, quantization, intra-prediction, loop filtering, and complex entropy coding—far more than VP8L’s simple predictors and entropy coder.

• Huge codebase: Google’s libwebp encoder runs to over 100K lines of optimized C/C++; reimplementing that in a “native” language is essentially building a new video codec from scratch.

I’m interested in exploring a pure-native VP8 encoder, but this will be a significant effort, and even once functional it will almost certainly not match the compression efficiency or speed of Google’s highly optimized libwebp. If you’d like to help, PRs targeting modular pieces (like a standalone DCT library or a simple rate-distortion quantizer) would be a great start.

[ivanjaros]

I'm no expert on video codecs but most data savings happen because not every video frame has to be a full frame, it can be just a series of diffs based off of a full frame that came before, as long as there is enough shared data up until the current frame. So for images, which are a essentially single video frame, does it even make sense to even attempt to go for the lossy version?

[HugoSmits86]

Although WebP’s “lossy” mode is based on VP8 it only ever uses a single I-frame (no inter-frame diffs), so you won’t get the temporal savings videos do. However, you still gain huge space-vs-quality wins from VP8’s intra-frame DCT + quantization + entropy pipeline compared to VP8L’s simple predictors, so a native lossy encoder does make sense for high-quality images (i.e. photographs).

It's basically like JPEG versus PNG.