Just a few years ago, I encountered a very similar problem to yours when I created a custom palette in the RGB color mode then converting to the indexed color mode. IIRC all gif format uses the indexed color mode and I had to change the color slightly from the original until Aseprite saves the file with correct colors to avoid this behavior.
Hi @imLisia. The GIF format is limited to 256 new colors per new frame and also does not support an alpha channel for colors.
When the sprite exceeds the GIF color limitation, Aseprite has to approximate the colors, this is probably your case.
To know how many colors are you using you can use the ‘New Palette from Sprite’ command:
Go to *Options in the Color Bar
“> New Palette from Sprite* click OK”. select 10000 colors to give room to all the colors in the sprite.
Currently you can simplify the color palette automatically via “New Palette from Sprite” and limit to 256 colors (you can try Octree or RGB5A3 color mapping methods).
Some history about the color limitation:
The GIF format can contain a palette of 256 colors per frame (for example, a 3-frame gif can contain 256 colors in the first frame, 128 in the second, and 256 in the last), but Aseprite currently supports a global palette for all the animation. Therefore, these ways of working with colors conflict with each other, so we are working to make the two scenarios compatible in some way (pending issues: Improve GIF encoding · Issue #2754 · aseprite/aseprite · GitHub).
At the moment the safest practice to not loss color information when exporting to GIF is to work with a color palette of 256 colors.