[ars]

This is not true:

"A GIF is literally a sequence of independent images squeezed into the same file. An mp4 video can take advantage of all kinds of fancy compression techniques like keyframes and forward-predictive frames."

That's not why the mp4 is smaller. A GIF is not [just] independent images, you can have each frame reuse pixels from previous frames.

The mp4 is smaller because lossy jpeg compression is used on each frame, while the gif stores each frames losslessly.

This has implications from the predictive frames as well - the jpeg is lossy, so two almost similar parts of the images can be considered "the same", while the gif is not, so they must be identical in order to compress that way, and the realities of video noise makes that unlikely.

[anon4]

Not quite true yourself :).

GIFs store deltas, true, but they are still raster images.

H.264 on the other hand contains specific techniques for compressing sequential frames, including things like recording only pixel motion for some frames. You can see it in those "corrupt movies" gifs (which on twitter would be mp4s... talk about irony) where you take a clip and remove some keyframes from it - then transformations are applied on the wrong blocks and you get really weird things like someone's head splitting open and stuff flowing into each other.

Additionally keyframes in movies are usually compressed with even more loss than standard jpegs. In most cases only the Y channel is recorded at full resolution and the two colour channels - U and V - are recorded at half.

There is also motion-jpeg which really is literally a sequence of jpeg images.

[vernie]

JPEG does the same chroma subsampling as H.264

[bhashkarsharma]

I think http://www.reddit.com/r/brokengifs collects such things.

[mikeash]

Just a nitpick, JPEG always encodes the color channels at half resolution. It's amazing how difficult it is to notice this, though.

[brigade]

No, there are 4:4:4 and 4:2:2 modes in JPEG.

H.264 also defines such modes, but no consumer hardware decoders support them so they aren't commonly used.

[mikeash]

My mistake, I must have been going off what's common versus what's allowed. Thanks for pointing it out.

[dunham]

Apple's jpeg animation hack used 4:4:4 so the blocks wouldn't interfere with each other. It's a neat hack, worth reading about if you haven't seen it yet: https://docs.google.com/document/pub?id=1GWTMLjqQsQS45FWwqNG...

[mikeash]

Holy moly. What a hack.

[pornel]

I was able to halve size of GIFs with lossy LZW compression:

https://pornel.net/lossygif

With a good palette (which most software is terrible at) and proper delta frames (without artificial differences created by blindly applied diffusion) GIFs can be 1/4th of the size you get from an average GIF maker.

Still, it's a terrible video codec.

I think trauma caused by awful plugins like RealPlayer and QuickTime made people stuck thinking that "animated images" and "proper video" are completely different things. But with native video support in browsers IMHO there should be no divide between <video> and GIF at all. It's the same thing, except the latter wastes more bandwidth, needs more memory or CPU (to enable seeking, used when you switch tabs) and can't be hardware-accelerated.

[4ad]

> needs more memory or CPU (to enable seeking, used when you switch tabs)

Gif is pretty bad, yes, but somehow I can browse pages with thousands of gifs. I can't browse pages with thousand of embedded videos.

[pornel]

> Gif is pretty bad, yes, but somehow I can browse pages with thousands of gifs. I can't browse pages with thousand of embedded videos.

That's true, but it's not limited by compression, only by assumptions/optimizations in the browsers.

For example browsers try very hard top stop decoding GIFs that are not currently visible on the screen. This could be done even better with a properly seekable video codec, but it's just not implemented.

[4ad]

No argument there. I was just stating a reason why gif-heavy site operators are reluctant to switch to video. It's chicken and the egg. They won't switch because video is not as optimised yet, the browser vendor has no reason to optimise video further because sites usually don't have that many embedded videos.

[Kayou]

Sorry but H264 does not use JPEG for its keyframes, although it's not very different. There are a lot of differences between GIF and H264, like H264 specifies that you can use multiple reference frames, which is not the case with Animated GIF. Also H264 has motion compensation, which does not exist with GIF.

GIF basically rewrites completely a part of the picture, while the remaining part is reused. And if you consider that a rewrite of a small part of the frame to reuse the remaining part from the previous frame is just displaying a new gif on top of a part of the old one, the you can consider that it is a sequence of independent images. Maybe they don't all have the same size and are not meant to be displayed at the same position, but they are independent in the sense that you don't need a previous or future frame to display one frame.

And I wouldn't refer to GIF as lossless, except maybe if your original animation used only 256 simultaneous colors per frame. You lose information by down-sampling your colors.

[eridius]

It's not just lossless/lossy. GIF is also rather primitive; you can store a delta from frame to frame, but the delta has to include every pixel that changed. A lossless animated format invented today wouldn't have that restriction, it would support things like pixel motion (which e.g. H.264 has).

Some years ago there were multiple efforts to produce animated PNGs. There was MNG (Multiple-image Network Graphics, which could contain both PNG and something called JNG) in 2001, and more recently, APNG (Animated PNG) in 2008. The problem here is the spotty support for these formats. AFAIK MNG is effectively dead. I thought APNG was as well (with Firefox being the only browser to support it), but interestingly, the Wikipedia page claims that Safari 8.0 (the upcoming version in OS X 10.10 and iOS 8) supports it. Chrome, Opera, and IE don't, but there is a Canvas-based library for rendering APNG which could presumably be used to polyfill support if you wanted to experiment with APNG.

In any case, the point here is that something like APNG probably has much better compression than GIF while still being lossless (I haven't done any actual comparisons here, but the PNG format itself has support for a lot of fancy compression stuff that GIF doesn't).

---

Reading a bit more, I'm actually really surprised to see that Safari 8.0 apparently supports APNG. It seems that the PNG Group officially rejected APNG back in 2007, which means that libpng will never support APNG.

[feld]

APNG is used heavily in the gaming (slot machine) industry.

[eridius]

Really? How curious. Why APNG? I would have assumed slot machines would want specific control over their animations and so would use something actually designed for that sort of control.

[feld]

No idea, but when I worked in a casino for several years you could see the APNG files being loaded during boot.

[underwater]

GIF can have individual pixels that are preserved frame to frame, but an MP4 can do much more. A GIF is lossy because you lose color information.

[alanh]

Totally true, ars. I came here to nerd-rage that, no, a GIF is NOT “literally a sequence of idependent images.” That is NOT what makes common video formats use less bandwidth, and I thank you for making this clear.

One thing you can do with video that you can’t do with GIF is programmatically describe motion — shift frame to the left, for example. GIF, you’d have to re-draw it all.