WebP not ready for prime time until it supports other than 2x2 chroma subsampling

[pdk...@gmail.com]

I've made a thread previously about poor results I had using WebP with a particular image, which I added a lengthy reply to some weeks ago - it was never posted. Maybe the board ate it, I don't know. Anyway, I've decided to make a new thread because of some additional insight I gained.

This is the image. 

http://cdn01.nintendo-europe.com/media/images/05_packshots/nintendo_3ds_6/PS_3DS_DrKawashimasDevilishBrainTraining_enGB.png

Encoded to best possible quality lossy WebP.

$ cwebp -q 100 -m 6 file.png -o file.webp

$ dwebp file.webp -o file.webp.png

The quality of the image is poor. It didn't occur to me until now that most flaws are typical signs of chroma subsampling! As listed below.

Red is dull and blurry. Noticeable in DEVILISH, 3 in 3DS, the O in FOCUSED, and the red background with black pictographs. While not quite red, the orange icon in the upper right corner is also blurry and slightly brownish. Most notable of all flaws however is the very blurry intersection between red and green at the bottom.

So how does JPEG compare to that? Let's try. I'm using quality 100 to focus on chroma subsampling.

$ convert file.png -quality 100 -sampling-factor 4:4:4 -interlace Line file_1x1.jpg # auto-set when omitted

$ convert file.png -quality 100 -sampling-factor 4:4:0 -interlace Line file_1x2.jpg

$ convert file.png -quality 100 -sampling-factor 4:2:2 -interlace Line file_2x1.jpg

$ convert file.png -quality 100 -sampling-factor 4:2:0 -interlace Line file_2x2.jpg

Quality of 1x1 is excellent. Both 2x1 and 1x2 have faint blurriness - barely noticeable unless you know and want to notice. Unlike 2x1 however, 1x2 moderately blurs the intersection between red and green at the bottom. Less than 2x2 though, which is just as blurry as WebP.

How does this translate to file size? I've re-run with quality 90 for WebP and JPEG.

88455 file_1x1.jpg

73398 file_1x2.jpg

73155 file_2x1.jpg

64403 file_2x2.jpg

49348 file.webp

WebP wins by quite a margin. At same chroma subsampling, quality is better than JPEG. It has (mostly noticeable at 2x zoom) less mosquito noise and ringing(?). Still, until it supports less destructive chroma subsampling, I cannot use it.

[Pascal Massimino]

Hi

On Mon, Oct 14, 2013 at 11:12 AM, <pdk...@gmail.com> wrote:

I've made a thread previously about poor results I had using WebP with a particular image, which I added a lengthy reply to some weeks ago - it was never posted. Maybe the board ate it, I don't know.

oh, sorry about that. This list is manually moderated for spam-removal, your message must have fall through the cracks.

 

Anyway, I've decided to make a new thread because of some additional insight I gained.

This is the image. 

http://cdn01.nintendo-europe.com/media/images/05_packshots/nintendo_3ds_6/PS_3DS_DrKawashimasDevilishBrainTraining_enGB.png

Encoded to best possible quality lossy WebP.

$ cwebp -q 100 -m 6 file.png -o file.webp

$ dwebp file.webp -o file.webp.png

The quality of the image is poor. It didn't occur to me until now that most flaws are typical signs of chroma subsampling! As listed below.

Red is dull and blurry. Noticeable in DEVILISH, 3 in 3DS, the O in FOCUSED, and the red background with black pictographs. While not quite red, the orange icon in the upper right corner is also blurry and slightly brownish. Most notable of all flaws however is the very blurry intersection between red and green at the bottom.

It turns out there is also some inaccuracies during RGB->Chroma UV conversion. Because this particular image has

fine outlined colored features, the lack of gamma correction during U/V averaging shows up.

I've uploaded this tentative patch: https://gerrit.chromium.org/gerrit/67540

which is likely to fix the discoloration of fine features.

It's still 'tentative' because it's ... quite slow. All these calls to powf() make it for a 4x slowdown during RGB->YUV conversion.

That's why more work is needed here, but you get the idea.

So how does JPEG compare to that? Let's try. I'm using quality 100 to focus on chroma subsampling.

$ convert file.png -quality 100 -sampling-factor 4:4:4 -interlace Line file_1x1.jpg # auto-set when omitted

$ convert file.png -quality 100 -sampling-factor 4:4:0 -interlace Line file_1x2.jpg

$ convert file.png -quality 100 -sampling-factor 4:2:2 -interlace Line file_2x1.jpg

$ convert file.png -quality 100 -sampling-factor 4:2:0 -interlace Line file_2x2.jpg

Quality of 1x1 is excellent. Both 2x1 and 1x2 have faint blurriness - barely noticeable unless you know and want to notice. Unlike 2x1 however, 1x2 moderately blurs the intersection between red and green at the bottom. Less than 2x2 though, which is just as blurry as WebP.

Yes, it occurs that his red/green separation line is exactly in a middle of a 2x2 block, leading to averaging blur.

Translated one pixel above, it would have been ok-ish!

 

How does this translate to file size? I've re-run with quality 90 for WebP and JPEG.

88455 file_1x1.jpg

73398 file_1x2.jpg

73155 file_2x1.jpg

64403 file_2x2.jpg

49348 file.webp

WebP wins by quite a margin. At same chroma subsampling, quality is better than JPEG. It has (mostly noticeable at 2x zoom) less mosquito noise and ringing(?). Still, until it supports less destructive chroma subsampling, I cannot use it.

So, yes the lack of chroma 4:4:4 can be visible on some images. It still seems (from the stats i looked at) 

like an acceptable fraction of problematic images. Since the initial VP8 format didn't have

it, we didn't forced to introduce it at the inception of WebP in order to not break the compatibility.

But yes, agreed, its lack shows on some images once you spotted it.

skal

[pdknsk]

I tried the patch. What I noticed was very little. The red 3 in 3DS is very slightly more vibrant. The O in FOCUSED as well, but is also slightly blurrier, because the red circles bleed into the white circles a bit more. It's quite minimal and I only really noticed by switching the images back and forth.

But yes, agreed, its lack shows on some images once you spotted it.

It makes me almost sad (really) that WebP is hindered by this. It cannot play out its advantages over JPEG. If you want to make a lossy, but still excellent quality image, WebP cannot compete.

Now one could argue if I need such excellent quality images, why not use lossless WebP. It's a good point, but please compare file size of the same image.

217794 file.webp

That's more than double file size for very little quality difference. If lossy WebP had 1x1 it'd probably be around triple.

[Pascal Massimino]

Hi,

On Thu, Oct 17, 2013 at 1:22 PM, pdknsk <pdk...@gmail.com> wrote:

I tried the patch. What I noticed was very little. The red 3 in 3DS is very slightly more vibrant. The O in FOCUSED as well, but is also slightly blurrier, because the red circles bleed into the white circles a bit more. It's quite minimal and I only really noticed by switching the images back and forth.

thanks for testing the patch! will try to make it work faster...

 

But yes, agreed, its lack shows on some images once you spotted it.

It makes me almost sad (really) that WebP is hindered by this. It cannot play out its advantages over JPEG. If you want to make a lossy, but still excellent quality image, WebP cannot compete.

Now one could argue if I need such excellent quality images, why not use lossless WebP. It's a good point, but please compare file size of the same image.

217794 file.webp

That's more than double file size for very little quality difference. If lossy WebP had 1x1 it'd probably be around triple.

 so, there's another possibility i'd like to propose, if 1x1 is really needed (agreed, sometimes it is).

you can:

 a) double the dimension of the source (Lanczos resizer preferred)

 b) compress to WebP using a slightly lower quality than the initially planned one, and

 c) downscale by 2x at decoding/display time to recover to initial dimension

It's my impression this would still be some gain over JPEG 1x1.

Here's a script that would do this:

#!/bin/sh

convert in.png -filter lanczos -resize 912x818 in2.png

cwebp in2.png -m 6 -q 75 -o out.webp

dwebp out.webp -o tmp.png -nofancy  

convert tmp.png -filter lanczos -resize 456x409 out.png

feh in.png out.png in2.png tmp.png

skal

[pdknsk]

I actually tried sth. similar already, inspired by this session at Google I/O this year.

http://io13-high-dpi.appspot.com/#22

Trying with this image, it works well to avoid chroma problems, but adds a resizing related slight blurriness to the whole image. The problem is also, resizing to 50% in browsers is low quality (at least until image-rendering from CSS4 is implemented).

[Pascal Massimino]

Hi,

note: i've submitted a revised fast version of https://gerrit.chromium.org/gerrit/#/c/67540/

Thanks to look-up tables, there shouldn't be any visible speed-diff now.

I also tuned the exponent value a bit. It's not the optimal one for your particular pictures, but

it overall is satisfying on a wider range of cases i tested.

Thanks for bringing this issue up!

skal

[Vlastimil Miléř]

Hi skal,

since WebP is supposed to be sRGB, I would recommend to keep the
standard sRGB gamma of 2.2. In that case, 12 bits is not enough, but
16 is OK. The LUT would be too big to be effective, but piecewise
linear approximation seems to be fine. This is what I am using:

struct CGammaTables
{
WORD m_aGamma[256];
BYTE m_aInvGamma[256+4];

CGammaTables(float a_fGamma)
{
float const fMul = (1<<16)-1;
for (ULONG i = 0; i < 256; ++i)
{
m_aGamma[i] = powf(i/255.0f, a_fGamma)*fMul+0.5f;
}
for (ULONG i = 0; i < 256; ++i)
{
m_aInvGamma[i] = powf(i/255.0f, 1.0f/a_fGamma)*255.0f+0.5f;
}
// it can happen due to rounding errors
for (ULONG i = 0; i < 4; ++i)
m_aInvGamma[i+256] = 255;
}

inline BYTE InvGamma(ULONG const a_n) const
{
BYTE const* const p = m_aInvGamma+(a_n>>8);
return *p+(((a_n&0xff)*(p[1]-*p)+0x80)>>8);
}
};

> --
> You received this message because you are subscribed to the Google Groups
> "WebP Discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to webp-discuss...@webmproject.org.
> To post to this group, send email to webp-d...@webmproject.org.
> Visit this group at
> http://groups.google.com/a/webmproject.org/group/webp-discuss/.
> For more options, visit
> https://groups.google.com/a/webmproject.org/groups/opt_out.

[Pascal Massimino]

Hi,

i'm bumping up this ooooold thread with some progress:

On Mon, Oct 14, 2013 at 11:12 AM, <pdk...@gmail.com> wrote:

I've been working on an improved RGB->YUV sub-sampler lately, which would address color clipping in a more precise

manner. Patch is not ready yet (quite experimental, and slow), but should be soon.

Attached is the *webp* file at quality 85 (~47k size). As seen, the color shift is somewhat improved.

Hope to finish this patch for the 0.4.1 release.

skal

[pdk...@gmail.com]

Well done! Color vibrance is much improved, and on the blurriness, in particular the dark edges when colors bleed into each other are reduced. Most noticeable on the otherwise typical ugly 2x2 red in the large 3 of 3DS. Overall blurriness is also reduced. I suspect though, the latter part requires some fine tuned parameters so may not be applicable.

I've noticed sth. unrelated but interesting in the new image. The white stripe on the right has a minor shadow on the left, and the left-most line of the shadow is somewhat cyan-ish (in the middle). WebP moves the line one pixel to the right and also strengthens it slightly. I hadn't noticed the line before in the PNG, but this made it noticeable. JPEG at 2x2 also moves the line one pixel, but doesn't strengthen it.

PS. The original image seems to have moved. It's at this web page, in case someone else wants to reproduce.

http://www.nintendo.co.uk/Games/Nintendo-3DS/Dr-Kawashima-s-Devilish-Brain-Training-Can-you-stay-focused--723315.html

[Pascal Massimino]

Hi,

On Tue, Jul 1, 2014 at 1:33 PM, <pdk...@gmail.com> wrote:

Well done! Color vibrance is much improved, and on the blurriness, in particular the dark edges when colors bleed into each other are reduced. Most noticeable on the otherwise typical ugly 2x2 red in the large 3 of 3DS. Overall blurriness is also reduced. I suspect though, the latter part requires some fine tuned parameters so may not be applicable.

actually, i've disable most compression param here (like filtering strength, etc.) in order to focus primarily

on the color-space conversion.

 

I've noticed sth. unrelated but interesting in the new image. The white stripe on the right has a minor shadow on the left, and the left-most line of the shadow is somewhat cyan-ish (in the middle). WebP moves the line one pixel to the right and also strengthens it slightly. I hadn't noticed the line before in the PNG, but this made it noticeable. JPEG at 2x2 also moves the line one pixel, but doesn't strengthen it.

no worry, these are just artifact of the experimental code: i haven't taken care of the special filtering case at boundary yet.

skal

PS. The original image seems to have moved. It's at this web page, in case someone else wants to reproduce.

http://www.nintendo.co.uk/Games/Nintendo-3DS/Dr-Kawashima-s-Devilish-Brain-Training-Can-you-stay-focused--723315.html

--

You received this message because you are subscribed to the Google Groups "WebP Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webp-discuss...@webmproject.org.
To post to this group, send email to webp-d...@webmproject.org.
Visit this group at http://groups.google.com/a/webmproject.org/group/webp-discuss/.

For more options, visit https://groups.google.com/a/webmproject.org/d/optout.

[pdknsk]

In that case, well done. It's a substantial improvement IMO.

[Pascal Massimino]

Hi,

On Tue, Jul 1, 2014 at 3:24 PM, pdknsk <pdk...@gmail.com> wrote:

In that case, well done. It's a substantial improvement IMO.

For info, an initial version of the code has just been checked in [1].

You can now experiment with it directly, by adding '-pre 4' option as

pre-processing directive.

Example: cwebp PS_3DS_DrKawashimasDevilishBrainTraining_enGB.png -pre 4 -o test.webp

produces the attached output. 

Next, i'll work on speeding this up so it can be the default conversion in the incoming releases.

[1] https://gerrit.chromium.org/gerrit/#/c/71213/

[pdknsk]

For this image, improvement is massive. It actually looks better than 2x1 JPEG IMO, and at smaller file size. I tried a few images, and results are similar. It's interesting though that PSNR barely registers this improvement. Someone needs to invent a new metric.

It does increase file size by some percent, but it's a good trade. With one image though, file size increases ~40% (and more with decreasing quality setting). It still has 2x1 JPEG beat, but with varying margin. It's attached.

In another image I noticed an anomaly at low resolution. It's the arm of the red pikmin on the right. And the lower half of the antenna of the lobster wobbles slightly. Also attached.

PS. Google should trumpet this improvement on all channels when it's officially released.

[pdknsk]

PS. Just to be clear, these are the source images.

[Brendan Bolles]

On Aug 15, 2014, at 12:20 PM, Pascal Massimino wrote:

> For info, an initial version of the code has just been checked in [1].
> You can now experiment with it directly, by adding '-pre 4' option as
> pre-processing directive.

Hey Skal, I pulled in the latest HEAD, but I get a crash running cwebp on Windows. My build command looks like this:

cd ..\..\..\ext\libwebp
nmake /f Makefile.vc CFG=debug-static ARCH=x64
nmake /f Makefile.vc ..\obj\debug-static\x64\lib\libwebpmux_debug.lib CFG=debug-static ARCH=x64
nmake /f Makefile.vc ..\obj\debug-static\x64\lib\libwebpdemux_debug.lib CFG=debug-static ARCH=x64


Running cwebp, I'm not specifying any arguments except input and output. Just using defaults.


Brendan