Fix issue where color data is discarded in fully transparent
areas when -resize -exact.
BUG=webp:397
Change-Id: I58ce8d5ae172d5d0f0138e07c7df3a3c6cbd0019
The graphical bug happens when there is a frame disposed to background
color, followed by another frame that does not blend, and their areas
don't fully overlap. Only the previous frame clears its part of the
viewport. The fix consists in clearing the screen for the previous and
the current frame if needed.
Change-Id: I3425cf7297f0c7b2cf13a3a61b517cc0b1c031d8
Option -usebgcolor may be used to display ANIM background color (or white if no ANIM chunk), blended on top of checkerboard. By default this is disabled (old behavior) to easily see transparent areas. Spec says that "background color MAY be used", so it's an option.
Key b may be pressed to toggle ANIM background color display. There are visual artifacts (leftovers) when toggling during an animation. This is already the case for rescaling, toggling info etc. (fixing it implies storing viewport render or rendering whole animation from start till current frame).
BUG=webp:394
Change-Id: If9ab898b2eac77226f30f062d522f9861789ef8f
Container spec indicates that background color is written
in BGRA byte order, but glClearColor() parameters are RGBA.
Anyway the checkerboard is displayed right after glClear()
calls so it replaces background color.
In response to webp-discuss/TkLHALGaHaM
Change-Id: Ief5435fadfd6a422b881a9dc240b5e8dc6546e19
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
