search

qiqian / webp

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

Issues with WebP image rendering in Chrome 32 #185

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
What steps will reproduce the problem?
1. Open http://ref.pssplayground.com/vikasa/test_css/test.html in Chrome M31. 
There are two images css.webp & nexus.webp in the test.html. The two images 
render correctly in M31. Scroll up/down and the two images render fine.
2. Open the same link in M32. The first snapshot of the HTML page renders 
correctly. If you scroll up/down few times, the css.webp image disappears. 
Inspecting HTML element still shows image css.webp very much there. You can 
open that image stand-alone in another tab perfectly fine.
3. I tried re-encoding the css.webp image (by decoding it to PNG format and 
encoding it back to WebP format (lossless & lossy) and the problem doesn't show 
up. So there's some issue with Chrome re-repainting this specific bit-stream 
(css.webp) after scroll down/up.

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

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

Please provide any additional information below.

Original issue reported on code.google.com by vik...@google.com on 21 Jan 2014 at 5:50

GoogleCodeExporter commented 8 years ago 
This particular test image 
(http://ref.pssplayground.com/vikasa/test_css/css.webp) is actually truncated 
(by 1 byte):
RIFF size (from the RIFF chunk) is 5822, which means that the full file size 
should be 5822 + 8 (RIFF header size) = 5830.
However, the actual file size is 5829.

One can verify that 'webpmux -info css.webp' as well as 'vwebp css.webp' also 
report error on this image.

The Chrome code uses the WebPDemuxPartial() API, which is actually being 
lenient and decoding as many pixels as it can. I'm not able to repro the 
"Disappearing image" behavior, but I'll try to dig down further.

Action items:
1. Whatever encoder was used to generate this image may be outdated and/or 
buggy. They should use the latest libwebp 0.4.0 encoder.
2. I will probably add a stricter check in Chrome to immediately fail on such 
images, unless there's a strong reason not to do so.

Original comment by urv...@chromium.org on 22 Jan 2014 at 12:12

GoogleCodeExporter commented 8 years ago 
I took care of Action item 2 in: https://codereview.chromium.org/144553003/

Original comment by urv...@google.com on 24 Jan 2014 at 1:12

GoogleCodeExporter commented 8 years ago 
Have the same problem with these images.
Images was transformed from jpeg to webp with libgd2.1.0(libvpx1.3) (freebsd)

Original comment by Ivan.Pol...@lamoda.ru on 28 Jan 2014 at 2:02

Attachments:

GoogleCodeExporter commented 8 years ago 
A workaround would be to add the padding as a post process:

$ dd if=in.webp of=out.webp ibs=2 conv=sync

Original comment by jz...@google.com on 29 Jan 2014 at 8:04

GoogleCodeExporter commented 8 years ago 
note that a bug is opened upstream to address the issue directly:

https://bugs.php.net/bug.php?id=66590

Original comment by pascal.m...@gmail.com on 29 Jan 2014 at 9:13

GoogleCodeExporter commented 8 years ago 
I also made the decoder stricter, so that it detects error for such invalid 
bitstreams: https://gerrit.chromium.org/gerrit/#/c/68731/

Marking this as fixed from libwebp side.

The bugfixes for the encoders generating invalid bitstreams (like PHP one & 
libgd) can be tracked separately.

Original comment by urv...@google.com on 11 Feb 2014 at 2:23