More of a historic curiosity these days, the legal reasons to avoid GIFs 20 years ago don't exist anymore, the LZW patents have expired.
That being said, PNG always had much stronger compression, in addition to supporting 24- and 32-bit color. Nowadays, we even have WebP that usually compresses better than PNG, and compresses far, far better than animated GIF. Animated GIF is a pretty ugly hack to the format, very inefficient for many common kinds of animations (or full-blown video as it's often used now); I've found that animated WebP can produce files around 10% the size of GIFs.
LZW is a lovely algorithm. It's simple enough to explain in a page of pseudocode and fast enough to run on 1980s hardware easily. The compression rate is "good enough." If not for the patent issue, there'd be no reason to switch to the marginally better Deflate (which was only created in response to the patent). A shame Unisys got greedy and killed it before its time.
Though that's got nothing to do with why GIFs got so popular. That's purely because GIF is the only format that could display animations on every browser since 1995. The timing of PNG was rather unfortunate - the PNG team had decided on not supporting animation because GIF animation was rare and adding it to the spec would've unnecessarily complicated things. They froze the spec, planning to submit it to W3C and IETF for standardization - and then Netscape, in full "move fast and break things" mode, released Navigator 2 with animated GIF support. So soon every GeoCities page is full of annoying sparkly GIFs, PNG only lets you make boring stills, and we've got to support both formats forever.
Well, a successor to JPEG called JPEG XL[1] that adds lossless compression, better lossy compression, the ability to further compress and then losslessly restore a traditional JPEG, HDR, animation, alpha channel, lots of other technical improvements, and a commitment by a long list of major players that if one of their patents is involved, it will be licensed at zero cost...is still scheduled to be officially published this month (Oct 2019).
Personally, I like LZ more than LZW because it doesn't have to slowly "build up" the dictionary in the same way as LZW nor need bit-I/O (because you can have an 8, 16, or 32-bit "indicator", followed by that many literal or length/distance pairs) and thus makes for an even simpler (and faster) algorithm. The only downside is that it's more asymmetric, in that compression is usually far slower than decompression (which can be faster than memcpy() - see http://www.oldskool.org/pc/lz4_8088 ) because the former has to do a lot of searching while the latter is mainly copying memory.
WebP should be replacing JPEG and PNG. I feel like JPEG/PNG is like the GIF of 1999, formats which can be completely replaced with no real drawbacks. The disk space and network savings alone could reduce energy consumption. Safari is the only browser without WebP support, and I don't think it makes sense to keep waiting on them. If Safari users start seeing websites with images that don't load, Apple will support WebP real quick.
One thing that would be nice would be a way to tell whether a WebP is lossy (in which case you should only edit/resize the original file, to prevent degradation), or lossless (edit as much as you please).
In economics, the Jevons paradox (/ˈdʒɛvənz/; sometimes Jevons effect) occurs when technological progress or government policy increases the efficiency with which a resource is used (reducing the amount necessary for any one use), but the rate of consumption of that resource rises due to increasing demand.
I think FLIF seems better as a PNG replacement. FLIF is a lossless format, although lossy encoding is also available. Still, PNG is much better than GIF, so GIF should not be used unless you need it for use with software that can't use PNG.
(This kind of lossy encoding would be possible with PNG too, but most PNG encoders don't have a lossy mode.)
(GIF is now patent-free, but PNG and FLIF are still better compression than GIF anyways.)
The FLIF author's next project FUIF is now partly the basis for JPEG XL which replaces (or at least aims to replace) PNG and all the other standard web formats.
Pngs get used for both for non photographic images and photographic images with alpha channel, and JPEG XL should win on both of those use cases.
It also cleverly has an upgrade story forexisting JPEGs so I imagine a fairly quick uptake where a proxy can recompress an existing sites images and get better size with no recompression loss.
This feature has been carried through to his work on JPEG XL, which is co-created with Google (using their Pik and Brunsli tech) and so fairly likely to get wide browser support.
In conjunction with HTTP2 to progressively load all visible images first, this is a killer feature for the web, simplifying thumbnails and responsive design while vastly speeding up page loads and improving caching.
If you factor in iOS, usage is actually quite significant. Almost a accounting for almost a third of the market, making it the second most popular browser.
Was the original focus on size or performance for animated GIFs? The more you compress something, generally the more processing is required to restore it. I started using the web in the mid 90s, and animated GIFs were everywhere.
Pretty sure the original focus was just getting something that worked to display an animation. Animated gifs are an archaic, inefficient video format. Each frame of video is included in the file. You can optimize with a global color table and a few tricks to help cut size but they're incredibly inefficient compared to modern alternatives. Bigger sites like Twitter/Facebook convert gifs to .mp4s and serve .mp4 where possible since it saves a lot of bandwidth.
I suspect the key to the explosion of animated gifs was that everything supported gif and that it was largely incapable of nefarious/annoying activity (unlike flash).
There's a fair bit of annoyance possible with GIFs, a fact I exploited when Google+ decided to:
1. Allow animations in the "Hero" user profile image.
2. Make that image permanently fixed to the top of the screen on the profile page.
3. As users increased window size to see more text and less hero, the image would scale to as much as 3/4 of the screen.
4. The hero was included on the "hover card" for users and would show up in all kinds of locations throughout the service. I still have that collection....
I spent an hour or so researching "annoying gifs", and settled on a rapid red-green-blue stroboscopic rotation. I don't know the cycle time, but it was probably a few times per second.
Google eventually relented. Well, they eventually shitcanned the whole site, but that's another story.
Trying to find animated images that weren't mind-bendingly annoying to me is how I ended up with the "space alien cat" image and avatar. The original had a rotating set of astronomical images in the glasses, I eventually applied the Crab Nebula as a static fill (tried the Cat's Eye, but ironically, it didn't work particularly well). That's the hero I use at several sites (Ello, Mastodon), and is the inspiration to the avatar I use as well.
Later at another site at which gratuitous annoying gif use was prevalent, I found a few static-but-apparently-moving optical illusion images, again to make the point that annoying images are annoying. The point was somehow missed by that crowd. That site also died.
TL;DR: animated gifs and even static images can be plenty annoying.
There is a trick where subsequent frames use transparency for non-changed parts of the image which gives a much better compression ratio than you might think.
Not all animated pixel art was for lack of video, just like not all ascii art was and is for lack of images. Recording a video is a wholly different process to animating a 16x16 smiley. If anything, at least by now, I think more people record video because they can't draw, than people draw because they can't afford the equipment or bandwith for video.
use transparency for non-changed parts of the image
In other words, similar to what video codecs do with "skipped macroblocks", except at a far more granular level. One wonders how efficient it would be if GIF was extended with things like motion vectors... but between the transparency/delta-enocding and the multi-palette "layering", you can sort of see the beginnings of a video codec.
There's also the trick where you can redefine the palette for each consecutive frame, and set the "delay" between frames to zero, in order to get more than 256 colors in a single image.
This is so horrendously inefficient it should be a crime. But it's still a GIF, and anything that can display animated GIFs can display it too.
Not that that means it will display entirely correctly. Browsers generally treat delays of 0 or 1 centiseconds as errors, and instead sit on that frame for a tenth of a second.
At the data rates we had available in the 90's, size was performance over the internet.
I am absolutely incredulous that people choose to use a GIF over a proper video format to share video on places like Reddit in this day and age. I don't understand the motivation to do so.
Well, these days imgur/gfycat will encode your gif as a video. Not sure I even see gifs much anymore.
Also, where have you been able to casually upload video to share quick bites like a cat making a funny face? You aren't going to upload a 12 second silent video to youtube. Up until very recently, gifs were the only permissible way to share this sort of content.
The huge advantage of gif was that it went in the <IMG> element. It behaves like a picture that moves, and can be uploaded to picture hosting services.
> Then your browser should have an option to mute-embedded-video-by-default. Problem solved.
I think you don't understand the modern web. If something is crappy the user shall have it. JS was always considered crappy but now is the best new thing.
And you also missed tbe latest web/UI/UX development. From the web designer point of view the user is an idiot which must be punished for every attempt to customize something.
> Don't blame a web video format/standard for UI failures.
They are not UI failures. They are done on purpose.
Because it's a "gif" not a WebP. If you want a format to catch on, the language needs to roll off the tongue. Even though I hate the word "podcast" and it sounds apple specific even though it's not, it sound a lot better than WebP.
I got the impression from the spec that it was originally designed to support retaining the compression dictionary across frames, which would have produced much smaller files at no cost to the decoder. But this wasn't explicit, it didn't get implemented, and the second spec ruled it out.
It could have very easily been better. I'm not sure what the moral is.
But not supported by iOS Safari. And APNG not supported by edge. That's why sites like imgur use mp4 videos as an alternative to GIFs.
It's not that a bad deal though, one minute of video is roughly 7Mo for something close to DVD quality. I had GIFS lasting a few seconds weighting way more, with terrible quality.
Yeah, it's a time capsule, sure, but a wonderful one. Just this part alone had me rolling: "Actually, they're going to draw on them with red markers -- setting fires in public places is against the law in California."
I'm not that well-versed in the matter, is WebP already supported widely? I mean, not just on desktop and advanced smartphones?
>I've found that animated WebP can produce files around 10% the size of GIFs.
For nicely optimized GIFs like these https://iwdrm.tumblr.com/ then WebP really struggles. Try to convert some of them to WebP and you'll see the result is often bigger than the original GIF.
If you have aliased pixels, gifs can compress much better than video formats. It's really a shame when sites like twitter mangle those files into worse-looking and larger video files.
And as a side note: png does not strictly compress better; sometimes the ability to use palette indexes that are smaller than 8 bits is an advantage.
That being said, PNG always had much stronger compression, in addition to supporting 24- and 32-bit color. Nowadays, we even have WebP that usually compresses better than PNG, and compresses far, far better than animated GIF. Animated GIF is a pretty ugly hack to the format, very inefficient for many common kinds of animations (or full-blown video as it's often used now); I've found that animated WebP can produce files around 10% the size of GIFs.