The key lesson here is not about a specific image format or company, but the fact that even a very light assertion or even hint of proprietary restrictions can kill or handicap a nascent technology or protocol in the bud.
The age of early hypertext was awash in such cases. The University of Minnesota only mentioned that they might introduce a charge for gopher servers, effectively killing the protocol. Various early conferencing and hypertext systems, including one from Sun Microsystems (NEWS?), and a few models from Microsoft, existed. Somewhere, Tim O'Reilly has commented about the early days of O'Reilly & Associates where he was looking at various options and made the early decision to not get locked into any one proprietary system, a choice which has paid handsomly.
The whole phenomenon of prortocol creation, promotion, evolution, and quite often, stagnation, is a fascinating and understudied one IMO. The role of non-market players, particularly government standards organisations, the military, and academic fields, is extraordinarily underappreciated.
Completely agree with and the sad thing is I don't even know where to point someone to learn about bout the roll that "government standards organisations, the military, and academic fields" play, except to talk to leaders of individual W3C groups.
A lot of discussion of early web technologies, like MOSAIC and HTML, took place in newsgroups that are still recorded and displayed online.
Not sure I've seen protocol discussions there (just never bothered to look) but it shows a whole lot of academics and government employees in the mix, and some commercial actors as well.
It's disappointing since those programs succeeded beyond the dreams of avarice but were not designed to gather publicity. The fact that so much of our economic growth is undergirded by public research funding is forgotten even by direct beneficiaries.
I was going to suggest the IETF and RFCs as a trove of standards-setting activity. There should be a few other similar ones.
There's an interesting transition as those groups moved from small (able to fit into a VW Bug, bus, or small bar) to large (auditorium, or multi-campus groups), and the relative frictions in new developments.
Past a certain scale, the easiest way to change a standard is to move forward, either abandoning or ignoring backwards compatibility.
Both software languages and various social networking protocols (there are ... many) are interesting cases in point. Mastodon is in many ways IRC v. 2.0 (and there are any number of competing contenders). There actually was (and/or is, depending on your judging criteria) a Usenet II, though it's seen limited popularity.
Another good source on much of this would be the late Pieter Hintjins. See for example:
> A lot of discussion of early web technologies, like MOSAIC and HTML, took place in newsgroups that are still recorded and displayed online.
Which is why I'm devastated how much new conversation about how things are put together is generally not hosted by the organizations involved, but is stored places like issues on Google Code (all gone), SourceForge (increasingly difficult and likely will begone), GitHub (which people don't seem to like to believe will one day delete their data); imagine if some of these early standardization efforts had done all of their communication on Internet protocols using the contemporary equivalent of Yahoo Groups or Google+--maybe using CompuServe or AOL?--and all of that work was now only around due to haphazard archiving efforts. (Google+ really burns me, as there was so much discussion of how things in the Android ecosystem works--particularly among all of the third-party forks, such as CyanogenMod--which is now just deleted and gone :/.)
I did a talk a few years ago on the history of layout in CSS, and those newsgroups were an invaluable source of information for why decisions were made.
I'm only vaguely aware of this myself, though there are a few places I've learned to look.
A history of the Brooklyn Bridge and its builder notes, apparently as a form of admiration, that he designed every detail down to the nuts and bolts. Thing is, that's because he had to. There were no standard fasteners. (The book doesn't detail this, it's just a passing reference I happened to catch.) David McCullough's The Great Bridge: https://www.worldcat.org/title/great-bridge-the-epic-story-o...
Herbert Hoover, as US Secretary of Commerce, instituted the National Bureau of Standards (now the NTIS, I think), which among other things standardised weights, measures, and yes, fasteners. Rather hagiographically addressed here: http://lcweb2.loc.gov:8081/ammem/amrlhtml/inhoover.html
Joanne Yates has written on such thrilling topics as the evolution of the interoffice memo and standarisation of business communications (and though I'm writing tongue in cheek, I really do find the work fascinating), and has been working on a book on standards and their evolution. I've not read it but it may be of interest. Engineering rules : global standard setting since 1880https://www.worldcat.org/title/engineering-rules-global-stan...
There was a fairly popular book on containerised freight shipping that came out within the past five years or so called The Box That Changed the World which looks at the standardisation of containerisation: https://www.worldcat.org/title/box-that-changed-the-world-fi...
Somewhere someone commented that one of the computer containerisation standards was simply a bunch of people coming to an agreement as to how to organise and and do things. My history with Linux has taught me that various packaging formats and systems (and the infrastructure surrounding them) have profound consequences and impacts, for users, adminstrators, and software producers.
I wish I could point to a single source and say "read this", but I'm really not aware of one presently.
The details of printing signatures and folios, and having the pages come out the way you want them to when bound, is another minor fascination. As are canons of page design.
The key lesson here is not about a specific image format or company, but the fact that even a very light assertion or even hint of proprietary restrictions can kill or handicap a nascent technology or protocol in the bud.
Is it? Gifs have been wildly successful. Today, many web deverlopers prefer newer formats like png for both technical and philosophical reasons, but gifs continue to make up a huge fraction of internet pictures. The average 12 year old knows what a gif is.
Also: because gifs are so predominantly used for animations and not static images, I've taken to using a client-side CSS style that renders all gifs as transparent, unless specifically hovered over.
This very rarely affects anything other than animations. People simply aren't using gifs for images as a matter of course today. For photos, it's largely jpeg (vastly higher compression, though lossy), for text-based images, png, though SVG is making inroads, particularly for data visualisations.
Gif owned lossless image formats before Unisys asserted their patent. In the aftermath, PNG was created, even animations shifted elsewhere -- mp4 and, though also proprietary, Flash. SVG popped up later, but fills some rolls previously held by gif.
And simply using or supporting gifs became an issue -- it was political. That's not something you want to have happen to your standard.
Depends on what you mean by "know". If you mean "moving picture that is not a video", sure they do. But if you showed them an APNG they will probably call it a GIF as well.
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.
> In 1984 the writer Stewart Brand observed that "Information wants to be free. Information also wants to be expensive. Information wants to be free because it has become so cheap to distribute, copy, and recombine -- too cheap to meter. It wants to be expensive because it can be immeasurably valuable to the recipient." The result, he said, is a tension that "will not go away."
Information is so incredibly cheap to distribute and copy today that I forget it was still very cheap to do so even before the Internet.
Brand was prescient about the tension not going away. Thirty-five years on, we've got paywalls, news aggregation, streaming music, vinyl records, all fighting it out.
Many times if GIF is converted to video it will ruin the pixel art, or in some cases even produce bigger file [1]. I get the efficiency argument for conversion to video, but in some cases it is a no-go. There should always be an option to not convert to video.
The dancing star gif posted in that github issue is 5,464 bytes in the original form and only 4,015 bytes when converted to a VP9 webm (with alpha channel) using ffmpeg's default settings.
> "There should always be an option to not convert to video."
I disagree. The conversion should be automatic. The converted result should then be compared against the original, and whichever is smaller should be sent to users. There may well be gifs that are smaller than their conversions, but I don't trust users to know which those are. Let the computer compare the two and make an objective decision.
What people call GIFs (however they pronounce it!) are nowadays more likely to be delivered as video files in reality.
It's more of a human-centric label for "short+looping+silent+autoplay video" than a tech-centric file format. A tad ironic given there's no longer a patent issue on the actual format.
I don't understand why so many people think they're "correcting" me.
First of all, it's external, not internal. There's no such thing as gifv format. It's just <video> with webm and mp4 but silent. That's the whole point. It's the whole reason why I commented and why they felt the need to create "gifv" which doesn't actually exist, lol.
Nothing on imgur's homepage will display without executing javascript. And no webm inside of a .gifv name will run in a loop without javascript. In fact getting it to run the first time requires user interaction or javascript execution too.
There is no such thing as a gifv file. Imgur just names the file that way when serving standard mp4 videos. Any device capable of playing mp4 files can view them. The whole thing is a marketing ploy.
I have seen that. However, I have found that if you delete the "v" at the end of the URL then you will just get a animated GIF file which you can view with any program that supports animated GIF.
I doubt people will move away from the term GIF. Whatever optimizations we do to the format (short, silent, looping video) will still be referred to as gif. Too late for a name change.
Anyone have an estimate of how much revenue increase the patent office received as a result of allowing software patents while knowing nothing at all, whatsoever about software?
How many of the things have been granted? How many filed? How much are the filing fees? How much are typical lawyering fees for it.
There are many among us who feel it is the actions of pure parasites on genuine tech innovation in software and systems so it's a question of how much was gouged by that decision (intentionally or otherwise).
The other one that could be interesting to know is the descriptive stats on salaries for patent attourneys specialising in software vs people being paid to program software.
I think you missed the point of my comment : as long as JavaScript is enabled, the website can bypass the "Video decoding API" and just show the media in a <canvas> tag.
Of course, we might be able to find a middle ground between disabling JS entirely and auto-playing all media, but it may be very hard, and that "middle ground" might be changing as website developers find new way to deliver auto-playing media that bypasses the browser's restrictions.
I'm not sure I've seen a whole lot of GIFs in the wild lately - mostly they seem to be getting converted to mp4 on the fly by most of the hosting services, no?
And it completely falls apart sometime. GIFs actually work but try browsing Reddit’s video alternative to GIFs anywhere outside of the reddit office and it struggles to even play for a second.
We have engineers replacing tech that works with their half baked barley functioning versions that lose all the benefits of sharing and remixability of a GIF file.
I don't understand what you're saying. I'm sure the video files reddit serves are perfectly playable in standard video players, since web browsers can obviously handle them. If download bandwidth is the concern, you should know it would be even worse with gif files, which are much larger than visually equivalent animated gifs. If reddit were serving up real gifs, they would load even slower.
Video files are easier to share, on account of being smaller, and easier to edit since you can use real video editing tools which is a lot easier than editing a gif frame by frame in gimp.
The only sense in which gifs are superior is they're easier to write a parser/renderer for from scratch, but I think that's relevant to virtually nobody.
Video: loads video player controls (slowly); waits; doesn’t start playing; starts playing but doesn’t let me choose volume quickly enough; stops playing; loading; jumps several seconds; appears to be at the end but isn’t finished loading; won’t loop; try to rewind or jump to position; doesn’t work; UI controls appear to have disconnected from anything; can’t rewind replay or watch; get annoyed; reload page entirely or quit it.
This is where you dismiss everything I’ve written with an “it doesn’t happen” because “you’re sure” videos are “perfectly playable” and “obviously work”, but you’re wrong, they don’t, they have glaring huge UX failure modes I hit all the time for years on mobile Safari with a normal person not mega fast internet connection.
None of that is the format, it sounds like your media player (or whatever js webshit reddit has implemented in their abominable redesign...) is just shit. "Mega-fast" internet would benefit you more for gifs than it would for real video formats, on account of those gifs being larger. Why do you think reddit wants to serve you video files instead of gifs? They're not doing it to fuck with you, I promise. They do it because it saves them bandwidth, and therefore it saves you bandwidth too. The solution to your problems is not using an obsolete inefficient image format for video; rather the solution to your problems is getting software that isn't totally broken.
Since your so skeptical, let's put some numbers to it: Here is a gif: https://0x0.st/zY8f.gif It's a staggering[0] 3.5MB, on a 56kbps connection it would take you over eight minutes to download it. I uploaded this gif to imgur, who then converted it into this mp4: https://0x0.st/zY8O.mp4 It's less than 700KB. On a 56kbps connection it would take you less than two minutes to download this. This is not an atypical example, an order of magnitude improvement is pretty typical when converting gif "videos" into real video formats.
Eight minutes vs two minutes... you tell me, which is faster? The faster your internet connection gets the narrower the gap gets, which is opposite of the trend you're suggesting. These conversions benefit people with slow internet more than they benefit those with fast internet.
[0] (For shits and giggles, I also encoded a VP9 webm with ffmpeg: https://0x0.st/zY8v.webm From what I understand you cannot play this on your iphone (because Apple), but it's less than a tenth the size of the original gif and looks identical to my eye.)
> None of that is the format, it sounds like your media player (or whatever js webst reddit has implemented in their abominable redesign...) is just st.
Re-read my comment this was exactly my point. We swapped something that worked everywhere for a custom players on every site and re-encoding therefore destroying what the artist intended.
GIFs are short, silent looping videos that work nothing like videos in consumer appliances have ever worked: they don't have pause, rewind or fast-forward controls; part of the effect is that on the first run they tend to run in slow-mo as they progressively download and subsequently run snappy, at times startlingly so.
No technical committee or even loose-consensus-running-code working group would ever come up with anything like that. The mode of pop-culture remixing that GIFs epitomize could never have been anticipated; the value that defaulting to silence delivers has still not gotten through to news sites (good ones, too!) that autoplay talking video over your headphones or god forbid the open plan office; it's even been reported[0] that porn works better for women in GIF mode.
That's because GIFs were never conceived for video. Consumer computer video was never conceived for pop culture remixing (despite having the experience of turntables to pick from). Porn was never conceived for women, for that matter.
GIFs are legacy left for us from a time between the fall of the Berlin Wall and the erection of the EU castle when everyone expected planning and bureaucracy to lose out to spontaneity bordering on anarchy. Many important HN recurring themes are here: privacy vs. normalized surveillance, free speech x hate speech x rogue counter-establishment right-wing speech, the freaking Mac App Store. Every "hacker" that defaults to the safe repressive position is someone who would rather that GIF looked that those barely-working WebM or whatever embeds found on Wikipedia, with little transport controls, bureaucratic efficiency and that wrongthink GIF memes were somehow blocked by "good DRM, DRM that prevents Putin from attacking the system".
Which system? The one that brought us Medium.com when we used to have Geocities. But we'll always have GIFs.
Actually GIFs were originally mainly for still image transfer — that they had more than 5 frames of animation is a recent phenomenon due to rising data transfer rates.
All this pop culture stuff comes over a decade from when the GIF was invented.
The age of early hypertext was awash in such cases. The University of Minnesota only mentioned that they might introduce a charge for gopher servers, effectively killing the protocol. Various early conferencing and hypertext systems, including one from Sun Microsystems (NEWS?), and a few models from Microsoft, existed. Somewhere, Tim O'Reilly has commented about the early days of O'Reilly & Associates where he was looking at various options and made the early decision to not get locked into any one proprietary system, a choice which has paid handsomly.
The whole phenomenon of prortocol creation, promotion, evolution, and quite often, stagnation, is a fascinating and understudied one IMO. The role of non-market players, particularly government standards organisations, the military, and academic fields, is extraordinarily underappreciated.