Anatomy of a GIF
GIF stands for Graphics Interchange Format. By GIF, we are talking about the GIF98A image file format, which is what Ulead GIF Animator 5 creates. You can read up at https://en.wikipedia.org/wiki/GIF. If you are wondering, I pronounce it with a hard 'g' sound, as the G in GIF is for Graphics. I don't care how the inventor pronounces it. :)
But if you want the information in simpler terms, a gif is a bitmap, or a grid of pixels of up to 256 colors. It has a color palette, which is the list of colors used, and can have up to 256 entries. In an animated gif, each frame can have it's own palette. However, this will increase the file size. A global palette is better - one palette for all frames. The tradeoff is that your animation may be less colorful. When animating, the choice is up to you.
Knowing what the innards of a gif looks like - the individual bitmaps for each frame of an animation - may help you in understanding what optimizing does, how to keep file size down, the impact of the frame removal method used, etc. You can see those innards in Ulead GIF Animator 5, by using the Index Editor. If you've been paying attention when you optimize and save a gif, you'll notice there's an option in the Save dialog to "open in index editor." You can access it from here, or go to the GA5 Programs Files folder, and look for IdxEd.exe
This is not a tutorial on how to use the index editor - let's get that straight right now. I never use it. It does somewhat resemble version 4 of Ulead GIF Animator, though. I haven't used that in many years...
Examing the inner workings of a gif will help one understand things like what optimization does; why the file size of a gif is what it is, and perhaps an idea how to trim it down without optimization; and other things.
The first frame will (usually) appear to be a complete picture. It's what comes in the subsequent frames that may look a bit odd.
Let's have a look at a gif animation found on the internet. (I have no idea who the creator is, or what software was used, so cannot provide them any credit.) It's 120 x 120 pixels, and 146 KB (149,539 bytes) in size, with 21 frames.
In the Index Editor view, we see the actual bitmap in each frame. Oddly, this animation's first frame is named "3: Frame" - what happened to 1 and 2? We also see the color palette for the frame. The frame removal method for each frame is "do not remove." Frame delay is 0. That's why the horse in the animation can run so fast! Your browser may display the horse running rather slowly - but if you view the animation in other software such as IrfanView, it's racing along.
As you examine each frame, you can see what information it contains. The first frame is the complete picture; as the removal method is "do not remove," the second frame's pixels are "painted overtop" the previous frame's pixels. Also note, in the palette of the first frame, there is no transparent color. In subsequent frames, there is. So any pixels that show up as that color (color 255 in the palette, black) are not visible, they are transparent, so the previous frame's pixels that those transparent pixels cover are still visible. I hope that didn't come out too confusing... Note that the palette has 256 colors, numbered from 0 to 255.
As you can see, each frame after the first has a lot of information, that is, new pixels to paint over the previous frame. This adds to the file size. Using a unique palette for each frame also increases the file size.
So after looking at each of these frames, how can we clean this animation up and reduce the file size, without using GIF Animator 5's optimization feature? Well, by eliminating all those different pixels. The background of the image, the moon and sky, shouldn't be different from frame to frame, but they are. So we can trace out the background, copy and paste it, move it to the top of the object manager, and make it visible in all frames with the Synchronize Objects button. I also did a copy/paste of the odd little bump formation that passes by, and put those above the background in the object manager.
I changed the frame delay from 0 to 5 (5/100ths of a second), which helps it look more realistic as far as running speed. There was some other minor tweaking done. It was optimized to use a global palette, and trimmed this down to 70,850 bytes (including comment block). That's a reduction of 78,690 bytes, over half the original file size! Even if we preserve the local palettes, the file size still comes in much lower, at 88,026 bytes, using 256 colors.
If we optimize using 32 colors, that trims it down to 40,872 bytes, including comment block. The original was 149,539 bytes - a reduction of almost 109,000 bytes!
Save those two tweaked samples above. From your GIF Animator 5 program files folder, run IdxEd.exe, open those animations from within the index editor, and have a look at the difference from the orginal. You can see how the tweaking halved the file size. Below is the Index Editor view of the 32 color version. The pale blue part on the top half is the section of the image that still displays that area from frame 1. Only the bottom part is new information, so we've saved quite a bit of file size by eliminating the need to include that top portion on every subsequent frame, as the frame properties for all frames is set at Do Not Remove.
If you feel brave, poke around with the index editor, but be careful! If you're going to try editing a gif, edit a copy, just in case you make a mistake.
I hope you found this at least a little educational and interesting. Happy animating!