Now the remap is calculated from the old palette to the new palette when
the "Remap" button is pressed. In this way we can remap after loading
a new palette (fix#737), or after generating an optimized palette, or
changing colors (fix#563).
With this change now we add a "mask" image/parameter in rotation
functions. In this way we can identify which specific pixels are
inside the original mask/selection, and in opaque mode we can
include/scale/rotate all those pixels inside the mask, whatever
value they are, even if they are the mask color.
Fixes#730
This fixes a problem generating invalid RGBA entries for an optimized
palette. (E.g. Generating non-opaque pixels when we feed the algorithm
only with opaque pixels.)
- Correct usage of disposal methods (and possibility to generate records
with "restore previous frame" disposal method)
- Create color maps for each frame when necessary
- Remove options to dither RGB images (to simplify encoder)
- Better palette creation depending on local colormaps
- Reuse palette colors from previous frames
- Use frame transparent index correctly
- Convert to RGB automatically if the image has more than 256 colors
- Remove onPostLoad()
- Add progress bar feedback
There are gif files that use a subset of the original color map remapping
used entries into first indexes. E.g. the main palette contains 256 colors,
but then a frame can use 4-bit per pixel to reference 16 colors from the
original 256 color palette.
When we converted an Indexed image to RGB, the original sprite
transparent color was being kept but the mask color of all its images
was reset to 0. With this change we kept the same mask color on all images
to avoid an assert() in the render code.
Anyway the whole RGB <-> Indexed conversion should be reviewed in these
cases. I think there are some situation where a transparent color = 0 is
expected in RGB sprites (as we shouldn't be able to change the transparent
color of an RGB sprite).
