teasame / webp

Automatically exported from code.google.com/p/webp
0 stars 0 forks source link

bad compression of black-red patterns #98

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
  cwebp test.png -q 40 -af -m 6 -sns 37 -strong -o test.webp
with the attached 'test.png' produces the attached 'test.webp'  (v0.1.3)
which exhibit unsatisfying compression of black dot on the driver's arm.

-sns is likely untuned for this case

Original issue reported on code.google.com by pascal.m...@gmail.com on 8 Dec 2011 at 12:38

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by pascal.m...@gmail.com on 8 Dec 2011 at 12:38

GoogleCodeExporter commented 9 years ago
Using similar settings, SNS only helps a tiny bit(100 vs 0). Filtering doesn't 
seem to be the culprit. I've shifted the hue of the image several times, and 
found that the dots on his chest & arm only appear when it's green, and to a 
lesser extent cyan and orange (as these mixed colors also contain green). Red, 
pink/purple & blue cause the dots to be thrown out.

While it's natural to expect lossy compression to emphasize green, this is 
still a problem because detail is still visibly thrown out at higher quality 
levels like -Q 95. See the attached for an example:

Original comment by sean...@gmail.com on 28 Aug 2012 at 12:21

Attachments:

GoogleCodeExporter commented 9 years ago
The problem arises mostly because most of the signal is contained in the "V" 
plane when the dots are black-over-red. The luminance plane is mostly flat. See 
the attached picture where the source has been converted to YUV444 planes.
WebP-lossy uses YUV420 format, where U and V planes are downsampled. Hence the 
"blurry" aspect of the dots, even at high quality. JPEG compression with yuv420 
colorspace would result in the same artifacts. But not when using yuv444.
Going forward, the plan would be to add layers in webp so that we can encode 
the residual difference between yuv420 and yuv444 representations.
Also, the 'fancy' upsampler could be modified to be more 'edge-directed' when 
converting from YUV420 to RGB.

Original comment by pascal.m...@gmail.com on 4 Sep 2012 at 8:00

Attachments:

GoogleCodeExporter commented 9 years ago
Issue 125 has been merged into this issue.

Original comment by pascal.m...@gmail.com on 6 Sep 2012 at 8:31

GoogleCodeExporter commented 9 years ago
The new '-pre 4' option does recover the black dots. See attached result for 
'cwebp -pre 4 test.png -o test_new.webp' (compared to normal output 
test_old.webp)

Marking as fixed for now.

Original comment by pascal.m...@gmail.com on 18 Aug 2014 at 8:54

Attachments: