Show HN: gif.js - Fast GIF encoder using web workers
jnordberg.github.io
jnordberg.github.io
The idea is that when looking for longest match in the dictionary you don't match colors exactly, but instead allow some difference. That can reduce file size by 20-30% (here's my take on it in C: https://github.com/pornel/giflossy/commit/5a9adbc0feb899a228...)
Another optimization is to set pixels that are similar between frames to transparent color. That sometimes massively improves quality, as you only generate palette for part of the image (so the palette is better) and several frames overlaid together may give more than 256 colors.
As for the transparency trick, do you have some example i can have a look at? I didn't know you can layer gif frames on top of each other like that
this may not work for me though because i need to record a css-scaled, hard-edges (pixelated) canvas. (which works in ff but not in chrome) and want to do this at 60fps, so on each reqAnimationFrame.
maybe i can disable imagesmoothing on the canvas and scale each frame via callback before encoding it.
it could be potentially much easier on the encoder if it did its own scaling instead of being handed scaled frames for analysis. my canvases are typically very small.
for slightly more context, it's for clearer, scaled up pXY.js docs/demos here http://o-0.me/pXY/#scanning
http://www.sublimetext.com/~jps/animated_gifs_the_hard_way.h...
on drawback is that in needs canvas. it may seem strange that i was hoping not to use canvas for the docs/demos since my entire lib is canvas-centric. but i would like at least the docs not to look visually broken in ie8 even if all of the live canvas demos dont work. the primary reason was to have upscaled demos via nearest-neighbor in chrome, though.
[EDIT] nvm, "...or emulating it using overlaid div elements for older browsers. "