this is potentially exactly what i've been looking for. i posted about where i ended up, using screen recording to capture canvas animations to gifs just a week ago https://news.ycombinator.com/item?id=5691742
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.
not sure if i fully understand what you are trying to do, but encoding 60 frames per second will be hard. If you already know the color palette it might be possible, this lib spends about 80% of the time doing the color reduction.
yes, the color palette is small and known in advance. http://i.imgur.com/wypWt11.gif is representative of the output. so ideally i would be able to predefine the palette and then hook the encoder into a callback from my reqAnimFrame loop.
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.
interesting, i think i've been noticing this but wasn't sure what was going on. in my case it's more important to show each frame than to get a specific fast fps. guess i'll have to resort to frame grouping where i need the speed.
Are you aware of the solution the author or Sublime Text came up with? It uses a PNG plus JSON metadata plus javascript plus canvas to create a tiny animation:
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. "
The discussion when he published[1] it is probably also worth looking into, as people discussed pros and cons of this technique, and alternatives. Which is kinda what you're looking for, right?
That's cool. Have you tried to make GIF compression lossy?
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.
That's really interesting, i had a look at your test images and they look great (http://pornel.net/lossygif for the curious :) definitely something worth implementing
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
The GIMP includes an "Optimize (for GIF)" command (it might be in gimp-gap) that deletes all pixels in subsequent frames that are equal to the most recent value for that pixel. Unfortunately, GIMP doesn't support per-frame/per-layer colormaps.
I guess "fast" is bit relative. I get reported 1-3 second render times, meanwhile imagemagick converts the image from png->gif in about 40 milliseconds.
16 comments
[ 2.9 ms ] story [ 54.1 ms ] threadthis 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. "
[1] https://news.ycombinator.com/item?id=4532146
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