WebP (Lossless April 2012)

[cbloom]

As for deblocking: We're currently struggling with this issue as well, and trying to come to a conclusion of wether or not to include it in tests. There are arguments for and against it, and it's not quite so easy. Conceptionally, any postprocessing is not part of the standard, so you're not testing a standard, but an implementation of it, and the output of any codec could be improved by post-filtering.

The problem is that the competitors generally have some kind of deblocking. AVC and HEVC have it in the standard. JPEG-XR does it inherently as part of the lapped transform. So to compare them against JPEG without a deblocker is not really apples to apples.

Block artifacts at low bit-rate is by the far the most visible flaw in JPEG and is so easy to fix with a deblocker!

It would be nice if there was a standard after-JPEG deblocker! BTW I like the Nosratinia deblocker a lot. It's too slow on the CPU but parallelizes very well and is super fast on a GPU.

That's currently happening in a joint MPEG/JPEG ad-hoc, and I don't have finite results yet. Again, for me it looks as if AVC does have an advantage here - and of course our folks from WG11 also know about HVS-properties, so there's something in their reference code.

Yeah I agree, I'm sure that AVC/HEVC will eventually be the best still image coder once the perceptual model is better understood.

MPEG world lives in YCbCr, thus their images are always in YCbCr, and losses due to the color decorrelation transformation are not accounted for in MPEG experiments. JPEG "thinks" in RGB, and has a more end-to-end approach (but see above).

Indeed this is a big issue that most people neglect. x264 loses something like 2 dB of PSNR (in RGB) through bad color space and downsampling of chroma. Most of the MPEG papers and charts report error in YCbCr so miss this aspect.

I don't quite understand your point here. If the outcome of the experiment is that it is bad below 1bpp, then this is what it says. It's a fact that it is terrible below 1bpp. Of course, the full story is in the R/D curves (or R/Q curves, actually, for whatever Q you believe in).

The problem is that the summary blurbs for things like HEVC say "better than JPEG by up to 10 dB !" . What they don't say is that improvement happens only at 0.25 bpp and less.

NO! It's not "patent free"! It's at best "royalty free" as the MPEG-LA agreed in a cross-license agreement. That is, they believe (I'm not a lawer, so I don't claim to believe here anything anymore) that some patents in the MPEG-LA pool apply to VP8, though MPEG LA provides a royalty free access to such IPs. That's something very different to "patent free".

Yeah okay, fair point, but for developers who want to use an image format in their app, it's in a much more useable legal state than J2K or AVC which are unpleasantly encumbered. Sadly anything that doesn't have official MPEG-LA clearance has to be considered dangerous. So in a practical sense, developers who want to be sure they are safe (and not pay a license) have to use JPEG or webp.

[thorfdbg]

The problem is that the competitors generally have some kind of deblocking. AVC and HEVC have it in the standard. JPEG-XR does it inherently as part of the lapped transform. So to compare them against JPEG without a deblocker is not really apples to apples.

Well, maybe. In XR, it is part of the transform and the specification, so you don't quite have a choice to pick that, or another. Postprocessing has a somehwhat more arbitrary character. J2K doesn't have any blocks, does this count as "deblocking filter"? The border line is not so clearly defined, which is exactly why I'm hesitating to take a clear position. It's not quite well thought-through at this moment.

Here is another problem: We usually do not define encoders, only decoders - which gives you some freedom. For example, to select the quantization matrices in JPEG or the R/D optimizer in JPEG 2000, so you can adapt to various coding goals. Trouble now: Consider we would know that postprocessing is done at the decoder, one could, vice versa, an encoder to such a specific decoder and get an overall quality improvement of this specific combination. Is this a valid "improvement" and is it "conforming"? Even more so if combined with the reference decoder, which then might get even worse results? Is this valid to lower the quality on the reference decoder if the quality is improved on a special decoder on encoder-modification techniques?

Block artifacts at low bit-rate is by the far the most visible flaw in JPEG and is so easy to fix with a deblocker!

Blocking, and ringing, and of course Gibbs artefacts.

It would be nice if there was a standard after-JPEG deblocker! BTW I like the Nosratinia deblocker a lot. It's too slow on the CPU but parallelizes very well and is super fast on a GPU.

Don't give me ideas. We're re-visiting JPEG right now anyhow (JPEG XT, including a backwards compatible lossless and HDR coder), so maybe that *is* an idea for another part... Need to check with others, but I'm right now quite busy.

The problem is that the summary blurbs for things like HEVC say "better than JPEG by up to 10 dB !" . What they don't say is that improvement happens only at 0.25 bpp and less.

That's the usual "marketing bullshit". Marketing people like to cut down quality to a single number. I also once had the idea to define a standard quality measure, but that's quite hard, and most people in the group did not see a good market chance for such a standard. All we have now are the AIC guidelines for codec evaluation, which are for my taste, too loose to fill this gap.

But for developers who want to use an image format in their app, it's in a much more useable legal state than J2K or AVC which are unpleasantly encumbered. Sadly anything that doesn't have official MPEG-LA clearance has to be considered dangerous. So in a practical sense, developers who want to be sure they are safe (and not pay a license) have to use JPEG or webp.

I'm actually not quite clear what the resolution now was, i.e. whether Google got a transmittable licence, and whether they actually forward the rights to their developers and users. The usual rule here is that reference software does not transfer any IP rights, and users have to do that by their own - which goes back to an unfortunate ISO regulation we cannot change. It means for J2K, for example, that you get an implementation for free, and you get also the licenses for free, but you need to write to the companies nevertheless.

It's complicated...

[Intrinsic]

0.3.0 is out

https://code.google.com/p/webp/downloads/list

- 3/20/13: version 0.3.0
  This is a binary compatible release.
  * WebPINewRGB/WebPINewYUVA accept being passed a NULL output buffer
    and will perform auto-allocation.
  * default filter option is now '-strong -f 60'
  * encoding speed-up for lossy methods 3 to 6
  * alpha encoding can be done in parallel to lossy using 'cwebp -mt ...'
  * color profile, metadata (XMP/EXIF) and animation support finalized in the
    container.
  * various NEON assembly additions
  Tool updates / additions:
    * gif2webp added
    * vwebp given color profile & animation support
    * cwebp can preserve color profile / metadata with '-metadata'

For the full changelog you'll need to download the source tree file.