Simulator-Created .gif file size reduction (with aseprite)

[remco (Remco Burema d.b.a. Spelbaar)]

As you're probably aware, the Simulator has a neat feature built-in where it can just export a .gif for you, rather than have to bother with any external software -- especially since it captures the screen only. As you're probably also aware, high-framerate .gif's can become larger than this forum accepts quickly!

When I was cutting some slack out of my .gif files a while back, I noticed that;

• just re-exporting in aseprite took off a good chunk off of the file size, and,
• the file came with a 256 color palette, and if I re-indexed that to 2, I could shave off another one-tenth.

(I originally thought that this palette trick did most of the work (which would have been a bit strange in retrospect, since you'd think that the compression would have done most of the work already). -- In any case, have a how-to on doing just that aseprite. )

sidebar: .gif supports less colors in the palette

As far as I can figure out, 256 (or 8 bits per pixel when uncompressed) is the maximum color-depth for a single frame, not a fixed value. This is then used in a lookup table, the palette, stored within the file. The number of bits per pixel (so it's not completely arbitrary, it has to be a power of two), is settable in the header. It seems this was even present in the original 1987 specification -- and isn't changed in the current(?) 1989 specs. (Search for bits per pixel to find the relevant text.)

1. After opening up the original .gif, convert the color-space to RGB, rather than Indexed. (When the original is pure black and white, grayscale will also work.)
   

2. Create a 'new palette from sprite' with the entry in the palette-menu.
   

   

3. Set the number of colors to 2 before pressing OK in the popup.
   

   

4. Set the color-mode back to Indexed.
   

5. Admire results. (Only a small part of this comes from cutting the palette though, probably mostly due to omission of the other 254 colors of the palette saved with the file itself. The rest is just better compression.)
   

I guess this could also double as an enhancement request, but if I our team got something like this at work I'm pretty sure we'd defer it -- Then again we have the excuse of 'pull requests welcome'.

--

Feel free to share your own tips 'n tricks!

[matt (gingerbeardman)]

You can also do this on the using gifsicle: https://devforum.play.date/t/optimising-gifs-from-mb-to-kb/788 command line or GUI, there are multiple options for compression.

I'd be interested to hear how that compares to Aseprite.

[timboe (Tim Martin)]

I have been using Optimize animated GIF

[remco (Remco Burema d.b.a. Spelbaar)]

Hi @matt

From what I can tell, it's comparable. I still got a little bit better result (only for lossless) when using Aseprite, but it's fairly close. Using lossy compression gets a little further, but not that much.

Using the same file as in the 1st post;

• 2.85 MiB [original file size]
• 1.96 MiB [gifsicle and website, color reduction/single palette only]
• 1.86 MiB [via Aseprite]
• 1.79 MiB [gifsicle and website, lossy set to 200 (max on website)]

W.r.t. command-line tools, I briefly tried ImageMagick as well, but that seemed to get worse results.

I'm convinced that the website @timboe mentions (and several other online platforms) internally use(s) gifsicle. It basically has the same options, and produces the same output-size. So this comes down to personal preference. It's nice to have options! -- Personally, I think I prefer the non-website methods though. (Something to keep in mind is that the website defaults to 'lossy' as well, albeit at a lower rate -- this might not always be nice for pixel-art like a lot of Simulator .gif's will be.)

This is definitely not exhaustive. The comparison was done on one file after all

[matt (gingerbeardman)]

Thanks for doing this!

I agree, it's personal preference. Ideal!