Closed GoogleCodeExporter closed 9 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
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
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
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
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
Original issue reported on code.google.com by
vik...@google.com
on 21 Jan 2014 at 5:50