When '-mixed' option is given, each frame would be heuristically chosen
to be
encoded using lossy or lossless compression.
The heuristic is based on the number of colors in the image:
- If num_colors <= 31, pick lossless compression
- If num_colors >= 194, pick lossy compression
- Otherwise, try both and pick the one that compresses better.
Change-Id: I908c73493ddc38e8db35b7b1959300569e6d3a97
Specifically:
- Merge OptimizeAndEncodeFrame with WebPFrameCacheAddFrame: they use the same
if-else structure.
- Move maintenance of 'prev_canvas' and 'curr_canvas' to util.
- Move ReduceTransparency() and FlattenPixels() calls to SetFrame(): This is in
preparation for the next patch: which will try try lossless encoding for
each frame, even when '-lossy' option is given.
- Make most methods static inside util.
No changes to output expected.
Change-Id: I1f65af25246665508cb20f0f6e338f9aaba9367b
helps during lossless compression.
10% average saving, but that's mostly on what was previously
'difficult' cases, where the gain is ~30-50% actually.
Non-difficult cases are mostly unchanged.
Tested over ~7k random web gifs.
Change-Id: I09db4560e4ab09105d1cad28e6dbf83842eda8e9
We reduce transparency by turning some transparent pixels into
corresponding RGB values from previous canvas.
This improves compression by about 23%.
Change-Id: I02d70a43a1d0906ac09a7e2dc510be3b2d38f593
