bananattack / fig Goto Github PK

The current LZW encoder is really slow for large GIF files right now, because for every pixel in the frame, it linearly searches the set of (prefix code, suffix char) pairs for an existing table entry that has prefix_codes[i] = old_code and suffix_chars[i] == pixel.

It could use some sort of hash-table or binary tree to speed up searching in the average case. Binary tree might be simpler to implement, since it's easier to figure out the insertion point than it is to write a good hash. And the linear case for a non-balanced binary tree is a bit simpler to write than writing probing / chaining for hash-table collisions.

Right now, the fig_image* type has an indexed representation (local palette, relative position/size) and a rendered canvas representation (BGRA, full-size).

Right now it's possible to render indexed images to canvas, but not the other way around.

It would be neat if there were tools for:

• automatically extracting the full set of unique colors from a BGRA image (in the worst case, an M x N image has M x N unique colors, but whatever)
• merging local palettes from separate frames together to make a globally unique palette.
• quantizing high-color palettes down to palette restrictions that GIF imposes and producing a conversion table that maps the high color indices onto the new reduced color set. This can then be used to generate an indexed image out of the BGRA canvas.
• (low priority) taking the delta between frames to optimize data for GIF disposal + partial updates, rather than completely erasing the previous frame each time.

The existing programs are good test cases of the library, but they're better as internal tests than real applications.

Right now:

• fig_gif2ppm: opens a GIF, and extracts the individual rendered frames as ppm. Who uses ppm??? The only real reason it uses this is because it's a text format is for quick dumping and debugging. Anyway, this serves as a good check that decoding works.
• fig_gif2gif: opens a GIF, and writes out a new GIF with nearly equivalent settings. For testing that loading and save will produce roughly the "same" gif.
• Useful tests for verification, but not useful for an end-user of the library.

Stuff I'd like to try:

• Something that algorithmically generates neat little animated GIFs.
• A little helper library to capture the last X seconds of a game in a circular buffer of graphical frames, and when the save button is hit, the game dumps the gif collection. Sort of like pico8's built-in gif capture, but for other kinds of games. Could be fun to see in low-demand game project, like FROG EGG: http://github.com/Bananattack/frogwizard
• mutate / "corrupt" a gif according to some parameters.
• interactive emscripten try-in-your-browser thing, write a small script, and it spits out a gif.