With PNG24 you'd at least get better colour depth. In which case why not use the same Dispose None technique in APNG (https://wiki.mozilla.org/APNG_Specification#.60fcTL.60:_The_...) and a polyfill (https://github.com/davidmz/apng-canvas) to provide cross-browser support?
Actually it might be preferable to always use the polyfill if you want to do something like the Apple thing where you can scrub around the video. Still doesn't have I-Frames to do frame-skip during fast movements though.
You can update multiple rectangles each with 0ms delay. Issue is that most browsers don't like dealing with 0ms updates, and will consider rectangle update a frame update. Some browsers will silently increase delays. [1]
You can pause once all necessary rectangles for frame have been updated. [2]
You can have full colour image provided that it is built from multiple rectangle updates, where each rectangle contains its own colour map. [3]
[1] : Browsers not respecting GIF rectangle update delays : http://nullsleep.tumblr.com/post/16524517190/animated-gif-mi...
[2] : gifsicle [image] --delay [delaytime] #[start]-[end] : http://linux.die.net/man/1/gifsicle
[3] : True Colour GIF : http://phil.ipal.org/tc.html
The smarter encoders would encode most of that rectangle as transparent and let the previous frames show through.
Gimp, Filters > Animation > Optimize (for GIF)
In context of the original post, of course, there's not much the ipad can do since the subpixel AA is already encoded in the image.
Code is available at https://github.com/sublimehq/anim_encoder, although you'll undoubtedly need to do some wrangling to use it for your own projects.
In truth, I didn't want to get into the quagmire of real video formats, and producing something that works everywhere.
It seems all the GIF encoders out there just take the easiest way out. GIF itself (from what little studying I've done of the spec) isn't such a terrible "codec" to work with, and it has features comparable to basic, decent video codecs. It has the potential to be decent (color space issues aside). The problem is with the crappy-ass encoders that take the laziest approach possible, rendering each frame separately, literally not cross-optimizing anything, applying random dithering in hopes it'll look OK on the pathetic monitors that were the best the 80s had to offer, and trying to do it all with as little RAM and CPU time as possible with no regard for searching for similarities across frames and finding ways to optimize the results appropriately.
There's no reason a good GIF encoder couldn't do what you did in your post. I don't know if one actually exists - I gave up on GIF long ago, after a string of horrendous failures similar to yours, where even the simplest animations would result in 1 MiB outputs and have horrible dithering banding throughout.
Add to that the similar disregard in decoding in browsers - where a 256 KiB GIF takes a full 45 seconds to load (stuttering and freezing for 20 seconds at a time) on a 50mpbs connection running on an i7 CPU as a result of the combined failure of encoders and decoders alike. It's pathetic.
APNG is at least a chance to wipe the slate clean.
Anyway, nifty animator there. Thanks for sharing, it'll really come in handy for screencast demos.
Graphics(/Image)Magick http://www.imagemagick.org/Usage/anim_opt/
Why do you need metadata to describe where the "patches" are located? Why not simply putting all frames one below another, where all unchanged areas are transparent? In case missing transparency support in old browsers is an issue, just use a special unused color instead. Since PNG does a very good job in compressing away those empty areas, the resulting image won't become noticeably bigger.
Is there any reason for which you excluded this option?
From memory PNG doesn't compress as well as you may intuitively think in this scenario, with the resulting files being around 3X the size.
Also, it's interesting to note that out of 31,000 open issues on the chromium site, APNG support is at #9 counting by user votes. http://code.google.com/p/chromium/issues/list?sort=-stars...
I'm only saying this because it's interesting that the same problem has been solved by very similar methods at almost the same time (SublimeText HQ being the first by a couple of months).
Preparation, this code sets hash[y][x] to the sum (overflow is ok) of all pixel values in the region to the top left of the pixel at x,y.
This should done for both the image and the thing we want to find in it.
hash[0][0] = pixel[0][0];
for (x=1; x < width; ++x) {
hash[0][x] = hash[0][x-1] + pixel[0][x];
}
for (y = 1; y < height; ++y) {
hash[y][0] = hash[y-1][0] + pixel[y][0];
for (x = 1; x < width; ++x) {
hash[y][x] = hash[y][x-1] + hash[y-1][x] - hash[y-1][x-1] + pixel[y][x];
}
}
Now, when we look for a match for a small image , we could check if the sum of the pixels match by doing following comparison
hashSmallImg[smallheight-1][smallwidth-1] == hash[offsetY+smallheight-1][offsetX+smallwidth-1] - hash[offsetY][offsetX+smallwidth-1] - hash[offsetY+smallheight-1][offsetX] + hash[offsetY][offsetX]
If this fails we know for sure the pixels wont match.
Illustrated: http://i.imgur.com/dHMKj.png
A 2-dimensional state machine might be possible, but I don't know how.
I have python-scipy, python-numpy and opencv installed.
And then convert APNG to GIF using this: http://sourceforge.net/projects/apng2gif/
It would be interesting to compare the results...
