with loop_compatibility disabled (the default), non-zero loop counts
will be incremented by 1 for browser rendering compatibility. the max,
65535, is a special case as the muxer will fail if it is exceeded; avoid
increasing the limit in this case. this isn't 100% correct, but should
be close enough given the high number of iterations.
BUG=webp:382
Change-Id: Icde3e98a58e9ee89604a72fafda30ab71060dec5
This is to harmonize the -h/-version options on all our examples.
+ added GetAnimatedImageVersions() method to anim_util.*
Change-Id: I2304a1c29e310682e97f236d3867274a192a7a09
this is consistent with web browser behavior as well as various
transcoding tools (ffmpeg, gif2apng, etc).
also: update anim_diff to account for this new behaviour.
BUG=webp:379
Change-Id: I70cc72a6b401ef32b73cd182a3f12d993d495bf4
For large images overflowing the partition0, we re-do a number
of passes but were forgetting to reset the block_count[].
This was leading to incorrect summary.
+ some cosmetic fixes here and there
BUG=webp:355
Change-Id: Ie87158d7f177f8efdca429b146cfcd0e81652d2f
if a single text file name is supplied as argument
(e.g.: 'webpmux my_long_list_of_frames.txt'), the command
line arguments are actually parsed from this file.
Tokenizer will remove space, tabs, LF, CR, returns, etc.
+ changed ImgIoUtilReadFile() to return a null-terminated
data, for convenience.
+ misc clean-up in the code
BUG=webp:355
Change-Id: I76796305641d660933de5881763d723006712fa9
---
this results in flickering with animated webp + alpha. disabling the
option is a workaround to restore the behavior to the previous release.
BUG=webp:365
Change-Id: Iac7fcc0d483837e76cc54ad3f26c4e0e5511e31d
the incorrect bit was being extracted from the lossless bitstream header
causing the alpha flag in VP8X to be misreported. previously the
signature byte was ignored in the calculation of the offset.
since:
8ba1bf61 Stricter check for presence of alpha when writing lossless
images
BUG=webp:361
Change-Id: I7c618b5f01a37f5e4b799dee11a7949efaf88046
This patch fixes the compatibility for loop-count handling.
This aims at addressing the change in Chrome handling of loop-count
prior to M63.
Before M63: loop-count interpretation was aligned to GIF's behaviour in
Chrome, but incompatible with WebP's spec. In particular, you couldn't
loop exactly once.
Post-M63: loop-count in WebP is really the total number of loops. Gif2webp
will convert correctly from a GIF source by adjusting the loop count.
Note: The Chrome version can be retrieved from the User-Agent
string (chrome://version).
An M63 version will contain the pattern:
Chrome/63.x.xxxx.xx
for instance.
Change-Id: Ie6dc13227e6498f4d7af2f09247913648997648a
A command line tool to print out the chunk level structure of
WebP files along with basic integrity checks.
BUG=webp:330
Change-Id: Ic69f646f649abb655b1854621d99afedeed158d7
Encoder:
We were always using ExtraSamples=1, which means associated-alpha.
But we don't need the (lossy) excursion to rgbA format. We can save
the samples as RGBA directly, by changing ExtraSamples to '2'.
The TIFF encoder now checks the colorspace properly, to handle
premultiplied format as well as non-premultiplied.
Decoder:
The result of TIFFReadRGBAImageOriented() is always pre-multiply.
So, in case an alpha channel is present, we need to unmultiply it before
calling WebPPictureImportRGBA().
See:
https://www.itu.int/itudoc/itu-t/com16/tiff-fx/docs/tiff6.pdf (page 31)
and also http://www.asmail.be/msg0055469184.html
Change-Id: I3258bfdb0eb2e1a53d6c04414f55edb2926c938c
