search

teasame / webp

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

Encoding bug causing noticeable color difference for one particular 16x16 block #145

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?

Using the attached golden-input-green-repro.png (a solid green image colored 
#007901), run the webp encoder to generate output files for each compression 
method:

for M in 0 1 2 3 4 5 6; do
  ./examples/cwebp golden-input-green-repro.png -m ${M} -q 90 -o stock-output-green-repro-m${M}q90.webp
done

What is the expected output? What do you see instead?

For M in (0, 1, 2), the output image has a noticeably off colored 16x16 sized 
block on the left side colored #009017 while the rest of the image is 
faithfully reproduced as #007901.  I've attached all the output files from 
above.

What version of the product are you using? On what operating system?

head -3 of ChangeLog:

abc0604 Merge "update NEWS" into 0.2.0
57cf313 update NEWS
25f585c bump version to 0.2.1

Note: If this gets fixed I'm curious to see the commit diff since it is an 
interesting bug.  Thanks again!

Original issue reported on code.google.com by CantStop...@gmail.com on 22 Mar 2013 at 6:22

Attachments:

GoogleCodeExporter commented 9 years ago 
Attached is a screencap of the glitch

Original comment by CantStop...@gmail.com on 22 Mar 2013 at 6:24

Attachments:

GoogleCodeExporter commented 9 years ago 
thanks for the report! i can repro and will have a look...

Original comment by pascal.m...@gmail.com on 22 Mar 2013 at 8:18

GoogleCodeExporter commented 9 years ago 
https://gerrit.chromium.org/gerrit/46374 should fix this.

Thanks for noticing! This was a long-standing bug where the saturation of 
quantized coeffs was
done at the wrong place. Normally, one wouldn't see the difference, and just 
wrongly assess the score
for a mode. But for low methods (-m 0 or -m 1) we don't change the decision and 
force some
mode without possibly changing them. Hence these 'wrong' mode were picked 
nevertheless, using
wrong saturation.

Original comment by pascal.m...@gmail.com on 24 Mar 2013 at 3:57

GoogleCodeExporter commented 9 years ago 
This fix:
3c8eb9a fix bad saturation order in QuantizeBlock

is available in 0.3.0.

Original comment by jz...@google.com on 3 Apr 2013 at 6:49