Talk:GIF/Archive 1

Archive 1

transparency

Could anyone add some words about the transparency features of GIF-palette and animated GIF (evenutally with comparison over the PNG format) ?

Transparent backgrounds in a gif image are created by using a color which is not used anywhere else in the gif frames as the background color. It is best to have the gif frames in bmp format before compiling them to avoid edge dithering. Before compiling a gif with transparency, use a graphic editor such as Paint Shop Pro or some other editor capable of creating transparency. All BMP frames are opened in the graphic editor, use 'Save As' gif for each frame, and select the option to target the background color for removal before saving the individual frames in gif format. The transparent background gif is then compiled from the individual gif frames.

I just did, please look it over closely.--branko

article structure - pronunciation

The pronunciation information seems trivial. I think rather than interrupting the flow of the GIF format history it should be placed at the end of the article. Evan Donovan 03:59, 25 February 2006 (UTC)

No, this is one of the more important issues here - it's the reason I looked it up in the first place, to settle a bitter argument with a co worker.

patent issues

A source which states that the algorithm for creating GIFs can be freely used for non-commercial software:

http://www.rasip.fer.hr/research/compress/algorithms/fund/lz/lzw.html (at the bottom of the page)

Is this a Unisys page? If not, it can hardly be used as a source for the statement that the algorithm can be used freely for non-commercial software.--branko

A Unisys page doesn't mention this http://www.unisys.com/about__unisys/lzw/ but the page is not specifically addressing free software.

If Unisys only mentions that they are asking licensing fees for LZW, and does not specifically mention libre or gratis software, then this means that Unisys is expecting money for ALL use of LZW, even in libre and gratis software.

Just because Unisys does not go after each and every instance of patent infringement does not mean they won't go after you.--branko

The GNU netpbm package contains about two hundred file converters for graphical file formats. It is accompagnied by a file COPYRIGHT.PATENT, which gives the following information:

Unisys owns a patent on LZW compression, which is used by ppmtogif, and maybe on LZW decompression, which is used by giftoppm. IBM also owns a patent that may cover the GIF tools. Unisys offers a license of the patent for trivial use for $5000. Its patent expires in 2003. Neither company has ever enforced the patent against trivial users of it. <http://news.cnet.com/news/0-1005-200-1713278.html> is an article dated April 18, 2000 on the issue. <http://www.unisys.com/unisys/lzw/> is Unisys' view of the matter. For information from another perspective, see <http://burnallgifs.org>.

The following Netpbm components may be restricted by this patent: ppmtogif, giftopnm.

A good substitute for GIF if the patents are a problem is PNG (see pngtopnm, pnmtopng), which was developed with a primary purpose of not using any patented technology.

You can also use the -nolzw option on ppmtogif to avoid using the LZW patent. The images so generated are larger than traditional LZW-compressed GIFs, but any GIF decoder can decode them just the same.

This doesn't really answer the issue. Any comments?

In its animated form, GIF seems to be used mainly for annoying, bandwidth-intensive banner ads and unnecessary animated junk on websites, like rotating text headings, flashing bullets and obnoxious animated icons. Animated GIFs take up lots and lots of CPU cycles in Netscape for some reason. most people who make amateur animated GIFs don't do any optimisations, making them hideous to use. Unisys waited until GIF was a de facto standard on the Web before springing license fees on people. Thus, the compressed GIF format is a TOOL OF EVIL!!! (why don't Microsoft have anything to do with it?) However, before Unisys sprung its booby trap on the Web, the GIF format(s) were a Good Thing, nicely complementing the JPEG format. Then, two graphics file formats covered most anything you wanted to do (except vector images). Now, all sorts of different formats are being used...

The seventh reason is that the compression algorithm it uses is patented by Unisys (under U.S. Patent 4558302), who have been known to charge licensing fees to coders who write software to maniuplate GIFs. That's the wonderful thing about standards... there are so many to choose from!

Oh, and 256 colour palette limitation is actually appropriate for an indexed palette graphic file format... now, if only there was an RLE GIF compression format... (sigh) and error correction has never been much a part of most image files, either...

1. The palette maxes out at 256 colors!
2. Its many variations make it hard to implement.
3. Its alpha channel is just one transparent palette entry.
4. The interlacing takes too long to render readable text
5. No error correction
6. It pretends to be a VIDEO compressor as well!

It seems the last poster here has written a general anti-gif rant rather than posting stuff in appropriate sections as for the patent issue that is now pretty much dead and burried (there is the IBM patent but that has never been enforced and i'm pretty sure that the unisys patent would be rather strong prior art against it). Plugwash 01:53, 5 Apr 2005 (UTC)

I tried to localize the discussion of the Unisys LZW patent to this page. To do that I removed the discussion from List of software patents and LZW and replaced them with links to GIF#Unisys and LZW patent enforcement. I added a sentence from the LZW page about gzip since that wasn't covered here, but the discussion on the patent page in large part contradicts what is on this page which seems more neutral, so I didn't retain any of that information. --JeffW 21:02, 15 February 2006 (UTC)

Also merged info from the Unisys page. --JeffW 21:13, 15 February 2006 (UTC)

If the patent info is to be localised anywhere it should probablly be at LZW though i'd like to see at least a summary and any gif specific info kept here. Plugwash 22:55, 15 February 2006 (UTC)

Yes and no. It was an LZW patent, but the controversy was exclusively on the use of that patent in GIFs. At least I never heard of any controversy over any other use of the patent. --JeffW 00:45, 16 February 2006 (UTC)

Well there was the replacement of compress with gzip by gnu. I dunno if that was in response to actual threats or just the knowlage they could happen though. Plugwash 00:48, 16 February 2006 (UTC)

How to say Gif

I believe the last person to edit over the way to say gif is wrong. The word is often said with the hard g but it supposed to be said like it was spelled jiff. I can't confirm this however.

I have updated the article to illustrate that there really is no definitive way of pronouncing Gif, and that there are in fact more pronunciations than the two choices put forward. Here is the text of my edit

"Gif" can be pronounced with either a soft g as in "giraffe" or a hard g as in "gift". Despite arguments to the contrary, both versions carry equal weight since no pronuciation was specified by the format's creators. There is no evidence to suggest that one pronunciation is in use more than another, and indeed, outside of the English language there are a number of further variants.

mmm it should be mentioned that gif with a hard g is unambiguos whilest jif reffers to a common brand of cleaner and and alternative file extention for jpeg files.

Also, a hard g is more like the original starting g in: "Graphics Interchange Format". However, people will usually pronounce something based on their first impressions, and good luck trying to get them to change! If you saw the acronym "GIFT", as an english speaker you would most likely pronounce it with a hard g, even if you later found it stood for "Generalised Index Facility Toolbox". There aren't any common words that start with 'gif-' in english using a soft g, and few that even contain it (like spongiform), so it usually defaults to a hard g. Just as a hypothetical side note, how would you pronounce the acronym "CIF", seeing as c should default to a soft s sound in all instances (meanings of CIF [1])

But, I think the most obvious solution is, acronyms should not be pronounced. Especially such ones as WWW and WWII, where saying the acronym takes more syllables than saying the words they represent. If you say "Graphic Interchange Format file" instead of gif file, then everyone will be happy. Even the ones that think the last F stands for file, and say "It is redundant to say gif-file, and don't say pin-number either." Splarka 20:32, 6 Apr 2005 (UTC)

what about if you had to say www.hotmail.com? saying worldwideweb.hotmail.com would be wrong thats a different (and probablly invalid address). Similarlly gif is the actual filename extention of gif files graphics interchange format is just an abstract name. So sometimes you have to pronounce acronyms because over time the acronym has taken on a different meaning from the base words it was formed from. Plugwash 01:53, 4 September 2005 (UTC)

Anyone using the argument that it should be a hard 'g' because it stands for 'graphical' had better start saying 'jay-feg', as the 'p' stands for 'photographic'. (unsigned comment by 83.146.62.110 moved to end of discussion by plugwash)

Can anyone provide a source for the statement that the soft-g pronunciation is more prevalent? i've only met one person to pronounce it that way, but he also pronounced warez like juarez. is it a regional or national thing? -- stubblyhead | ^T/_c 06:28, 28 March 2006 (UTC)

I agree, provide evidence or this claim is ripped out. Plugwash 06:54, 28 March 2006 (UTC)

I think that we should at least mention the situation in the article and point out the two common ways to pronounce GIF. At the moment, there's absolutely no mention of pronunciation in the article. Gordeonbleu 21:15, 15 April 2006 (UTC)

Thats because an anon just ripped out the entire section. i've put the section back. (it seems someone had already removed the unsourced claims) Plugwash 21:46, 15 April 2006 (UTC)

I'm surprised that no one has mentioned (either in the article or here in the talk page) The GIF Pronunciation Page. It would be nice if someone could add this to the article, as a source and/or external link. --Cotoco 04:15, 18 September 2006 (UTC)

I worked side-by-side at CompuServe with Steve Wilhite, the creator of Gif. I can personally verify that it's pronounced with a soft g (like the peanut butter Jif). As a parent, would you want people mispronouncing your child's name? In other words, if you named your son Gerry (Jerry), would you want people pronouncing the name like Gary? Please, out of respect for Steve, use the pronunciation that he intended. Thank you 65.60.165.146 00:07, 4 January 2007 (UTC)

Image?

It wouild be nice if there were some illustrative .gif, like the examples at JPEG and PNG. Something like one of the rotating globes or something would show the fact that .gifs are usually used for moving images. I did a Google search for all the .gifs in Wikipedia, but couldn't find anything appropriate. — Asbestos | Talk 12:59, 30 Mar 2005 (UTC)

what about an animated gif made from photos or video like this one?

[2] A video file converting into a looping animated .gif

BMP?

"The Windows bitmap format is preferred for images in computer software because bitmaps can be displayed quickly and that speed is more important than reduced file size." Bull****, thats only used by the windows people for their screenshots! I *never* use bmp for anything! It's a silly bloated format, so bloated that it can even load *slowly* just because of it's size.

Gimme XCF, TGA, or TIFF. And I use XWD (X Window Dump) for screenshots, and then convert them to PNM. If I want to spread them, I convert the PNM to 8 bit color PNG or just JPEG (depending on the image).

Browser support

The article states:

All popular web browsers support PNG images, although it is interesting to note that as of the beginning of 2005, a number of popular browsers including Internet Explorer still have several issues with the PNG format.

I thought IE was the only one that had "issues". What are the others? --Yath 22:24, 4 Apr 2005 (UTC)

GIF can have more than 256 colors

It is an incorrect simplification to say that "GIF gives a choice of only 256 of those colors per image". As a Gif89a image can have multiple image blocks ("frames" in animated gif jargon), and each of these can have its own local palette, one can layer these image blocks, using the transparency index to reveal parts of the layers below, to create gifs with any number of colors. RodC 12:22, 18 Apr 2005 (UTC)

apparently it is possible to achive more than 256 colors with dirty tricks involving the animation features but i've never seen this technique used in practice and i doubt it works with all decoders. Plugwash 12:48, 18 Apr 2005 (UTC)

I'm curious, Plugwash: What's "dirty" about it? I've used this technique a few times: don't have an example with me right now but will post later. It will work with any gif reader that understands the Gif89a format, which includes most web browsers used today. It may not work, of course, with all displays -- if one uses a VGA or other 256-color table-based display only one LUT can be available at one time. RodC 13:05, 18 Apr 2005 (UTC)

hmm i don't really know much about this myself. I found http://phil.ipal.org/tc.html which has some more info but not a great deal. From what was said here i thought it basically invovled using the animation features to display the various bits without putting a delay between them. However mspaint opens the demo truecolor gif on that site correctly which makes me think its not directly related to the animation features. I will try that image on some other editors soon as well reading some spec documents to see if they reveal anything

The only real use i can see for this is truecolor animations or possiblly getting a truecolor image into some really obscure app but i don't see much use in the general case now we have png.Plugwash 13:19, 18 Apr 2005 (UTC)

note to self: read http://members.aol.com/royalef/gifabout.htm#specs and see if i can make sense of exactly how truecolor gifs are achived. Plugwash 13:52, 18 Apr 2005 (UTC)

i think the only way i'm going to get to the bottom of this is to write some code for gif file manipulation myself (i mean low level exploration and manipulation not viewing and editing). that demo truecolor gif draws slowly in every browser i've tried it in but i dunno if it is the browsers or the file. Plugwash 12:37, 21 Apr 2005 (UTC)

I believe the two factors concur, but I'm only speculating. Besides file size, what could be creating an overhead is that the gif decoder has to substitute a new palette every time. BTW, I think the term "truecolor gif" is misleading. No matter how many colors you have in a gif image, it will still be a palette-based image, and what pixels refer to are indexes to the palettes, not actual RGB values. RodC 12:52, 21 Apr 2005 (UTC)

right BUT i've done some other testing that goes against that idea

• mspaint loads that file pretty much instantly (and completely)
• it loads at the SAME speed in all browsers i've tried and it makes no difference whether i load it into them from the website or from the local hdd.

as i see it thier are two possibilities

• the creator of that website put the delay in on perpose to prove the point
• browsers force a minium delay between the seperate images that make up the gif.

as to your point about "truecolor gif" being misleading my take on this is if you can put an arbitary truecolor image in and get it back out without the color destruction step of putting the whole image into a pallette then its just a way of encoding the truecolor data and the image as a whole can be considered truecolor. How is an image like this any less truecolor than one passed through an algorithm like deflate? Plugwash 16:41, 21 Apr 2005 (UTC)

Hmm, interesting. This is really a philosophical point. See, if you have a truecolor image that just happens to have 256 colors or less (it's a 16x16 pixels image, for instance) you can encode it without color loss as a regular one-palette gif87. Would you still call this a truecolor image? If not (and why not?), at what point do you start to call an image truecolor? As I see it, the actual number of colors in an image is largely irrelevant as regards this discussion. That the colors in such image are indirectly called through indexes to one or more palettes is what defines it as an indexed-color image. Cheers. RodC 19:51, 21 Apr 2005 (UTC)

ok well i just finished coding an app capable of following the structure of a gif file and making the metadata availible in a (sort of) human readable format and i can clearly see that thier are no delays or user interaction requests specified in that file. so either the browsers are doing something very inefficiant regarding pallettes (such as registering every new pallete with windows or similar OR they are assuming the image is an animation and placing a minimum delay between the individual frames. 130.88.116.97 13:33, 22 Apr 2005 (UTC)Plugwash 13:39, 22 Apr 2005 (UTC)

Just a thought: Another way to have a truecolor image stored in gif is to have several GIF files stacked on top of each other (there are a few ways to do this in html), with all but 256 colors in each layer as transparent. There wouldn't be much point in doing it this way (the same could be said about the above way too), but it could be done. Yet another method would be to have a bunch of 16x16 (8x32, 4x64, etc) gifs, each representing 256 pixels, side by side in a table with no cellpadding, cellspacing or border. Splarka 04:06, 25 Apr 2005 (UTC)

As the author of the referenced example page, and the developer of ANGIF, I figured I should chime in here with my perspectives.

GIF had the image blocks ("Image Descriptor") in GIF87a even before GIF89a added the time delay feature. So I could argue that these image blocks were not originally intended to be related to the time dimension. I suspect that the GIF format was either intended as development for, or derived from, some kind of work done at CompuServe to create a fixed screen size layout scheme. Displayable text was not added until GIF89a, so it is unclear how workable GIF87a could have served that goal. Nevertheless, a full display of multiple blocks, each with its own local color pallette, is (as far as I can tell) fully compliant with GIF87a. It doesn't have a basis in animation. Rather, both animation and "true color GIF" have a basis in the existance of multiple blocks. So these features are peers, not one derived from the other. Genuine animation came along when Netscape created and supported an extension that allowed specifying a loop behaviour.

The ANGIF package is an uncompressed GIF implementation. That makes the images larger for sure. But even with compression, each block has to have a new pallette, and the compression has to start over in initial state. The more colors there are, and the more they are spread around to force breaking up into more blocks, the larger the file. The worst case is an image that has so many colors it forces each block to cover 256 or fewer pixels. Then the image is effectively in the local color pallette, which is not compressed.

Is this a hack? As I see no violation in GIF87a, I would say it's not. But it is most likely not something the GIF developers expected or intended, so in that sense it could be said to be a hack. I came up with this after I had done something else that would likely be labeled somewhere between a hack and insane. I created an HTML page which consisted of a very large table with each cell containing a 1x1 pixel GIF that encoded a specific single color. The original purpose was to test rendering speed of IE vs NS browsers at the time (I recall this was around version 3 of each). IE won by a huge margin on this test, loading a 512x512 image in about 3 seconds on a 166 MHz PC under Windows 98. NS took over 50 seconds to render the same thing on the same machine. It was shortly after that when I started developing ANGIF, and I was thinking of using tiny GIF blocks as a test for browser rendering speeds that way (both did a lot better). It was during development of ANGIF that I realized I could include an algorithm to recursively partition an image until the parts became small enough to have no more than 256 colors. I proceeded that way because I saw it as a means to deal with the occaisional iconic image that would end up with more than 256 colors (though usually not much more). The usual case for me was long smooth gradient bars wider than 256 pixels. They usually ended up with no more than 4 GIF blocks, and that seemed reasonable.

Whether this should be called "true color" or not may need to consider the limitations that exist in other formats that are referred to as "true color". I used the term like that because BMP was labeled by some as "true color", as well as some video display cards around the time 24-bit color was becoming the norm for PC video. Here ( http://inet-police.com/gaia/gif-24.html ) is another page that has some info under the terminology "full color GIF". Maybe that is a suitable alternative term in place of "true color GIF". --PhilHoward 17:38, 9 July 2006 (UTC)

This discussion got me interested in the so called "true color" GIFs and I did a little testing. Maybe something I noticed will clarify some confusion (or introduce more). As Plugwash noted, when you open the true color GIF (tc217.gif in the example page) in MS Paint, it displays instantly and correctly--possible because Paint is not "animation aware", however a quick test shows Paint doesn't do a simple merge of all the frames, but simply interprets the file the way it was intended to be. Other applications treat it a little differently:

• Paint Shop Pro 9 only displays the very first 16x16 "frame" in the file rather than the full 217x217 "canvas" and shows a notice that only the first frame was imported.
• Animation Shop 3 reads the file as an animation having 173 frames, each built on the previous with an additional 16x16 block and having a 0ms delay--even though Animation Shop only allows delays as short as 1ms. If you attempt to re-save the image with Animation Shop, you end up with a completely corrupted GIF that nothing can display, not even Animation Shop.
• Photoshop CS displays it like Paint Shop Pro 9 does, except it displays the entire 217x217 canvas, with everything except the upper-left 16x16 block being transparent. It also warns that only the first frame was displayed.
• Windows Picture & Fax Viewer fails gracefully with the informative message that "Drawing failed."

So, from an initial viewpoint, it appears that if the application is expecting that a GIF with multiple frames is going to be animated, it will probably render the image incorrecty or incomplete. --Nick, 65.100.221.52 07:31, 31 July 2006 (UTC)

• PhotoShop CS2 - same thing as Photoshop CS
• ImageReady CS2 - Hmm...

Screeny >> http://img291.imageshack.us/img291/5835/picox6.jpg --XIIICats 11:50, 3 August 2006 (UTC)

Image

I added the image of the rotating globe (Image:Rotating earth (small).gif) because it's one of the most common illustrations done using gif on the web, and because I thought that the article needed a relevent image like the JPEG and PNG articles do.
An alternative image would be a simpler one, like Image:Cube Animation.gif, or any of the images that can be found at c:Category:Animation.
— Asbestos | Talk 22:16, 9 July 2005 (UTC)

450 kilobytes is a bit too large for an image that loads with an article. --Yath 03:30, 10 July 2005 (UTC)

i like the image but i agree its a bit big not too much of a problem for adsl users like me but probablly a pita for those on dialup. can anyone give information on how this image was made. IE was compression used and was the animation done efficiantly (ie only sending the changes in each frame)? Plugwash 23:04, 10 July 2005 (UTC)

No information about how it was made, sorry. You can try asking User:Marvel, who made the original. You can also see if he'd make a smaller version or another picture (he says he's open to requests), or just use one of the rotating shapes from c:Category:Animation. Sorry I don't have any better information. — Asbestos | Talk 10:27, 11 July 2005 (UTC)

someone recently replaced the image with a horriblly distracting animation (and i reverted). I like the globe for another reason too, if you look carefully at it you can see the color quantisation so its showing two things about gif in the one image. Plugwash 00:40, 4 September 2005 (UTC)

The quantization is not GIF-specific, however, and could easily be avoided (8 bits are enough for just about any full-colour image at screen resolution, ISTR) quota 09:43, 27 February 2006 (UTC)

Btw i just used gifsicle to optimise the globe animation and knocked just over 100K off the filesize. Its still big though.

I just uploaded one of my gif images (flying P-51 Mustang- only 11KB) to the wiki gallery which shows animation and transparency, but have no clue how to link it. I'm an animator, not a linker. If you want to use it, link it in. - http://en.wikipedia.org/w/index.php?title=Image:Mustang-ani-t.gif&diff=prev&oldid=82392086

truecolor vs truecolour

Truecolour would seem correct for the british english which this article is in but truecolor is by far the more common form online (877,000 vs 24,700 on a google test) both are currently used in the article. Comments please. Plugwash 14:34, 20 September 2005 (UTC)

• I don't know which is right, but there seems to be this edit war ping-pong going on for some unknown reason. The article says it was invented in AMERICA, so shouldn't the spelling be in AMERICAN English? Wahkeenah 04:31, 8 December 2005 (UTC)

The article was created 10-9-01 with British English. Wiki policy is that both conventions are correct, but in cases of dispute the original takes precedence. So British it is.

Be careful. Some of you are perilously close to breaking the three-revert rule, and this will get you blocked. So quit it! Pollinator 16:45, 8 December 2005 (UTC)

indexed color

I am hoping someone can add more about the advantages or special applications of indexed color, as opposed to the limitations. (One example in mind is a map generator, which re-works a 256-color GIF. This base image depicts regional borders in black on a white background. However, the pixels in each region are assigned a unique index number, and so the regions can be selectively colored by editing the palette entries.)Levinel 08:35, 4 October 2005 (UTC)

True OTOH gif doesn't provide any way to specify alternate pallettes so you'd need to provide that information seperately and you would need a special viewer. So this is content probablly more relavent to a general page on indexed color than a page on gif.

I was referring to a cgi application that generates maps on-the-fly - for web pages. At the time it was developed, I think only GIF could be used in this manner, and perhaps still is best suited. So, this map generator is a practical, though unconventional application of GIF. (An operational example can be found at http://cnps.org/inventory.) But yes, I suppose indexed color should also have its own article. Levinel 09:26, 7 October 2005 (UTC)

neat trick ;) though very bandwidth ineffician't since you presumablly have to re-send the entire gif every time you change pallette and that gif will have far more color depth than needed.

P.S. the only two times gif is appropriate on the web are 1: if you need compatiblity with extremely old browsers or 2: if you need animation all the rest of the time png is a far better choice. Plugwash 11:28, 7 October 2005 (UTC)

speed

Can anyone comment on the speed-of-animated-GIFs-in-different-browsers issue? I haven't been able to find anything definitive about this in Google, but it definitely is an issue. Image that are OK in IE are ridiculously quick in Firefox. pfctdayelise 01:38, 23 January 2006 (UTC)

Can you show us an example of a GIF file with this problem? --Zundark 09:18, 23 January 2006 (UTC)

If the delay per frames is set to something below 50ms (0, 10, 20, 30, 40, etc), can act oddly. Different browsers, viewers, and editors, and even different systems (the speed of the machine sometimes becomes the delimiter) will show them at different speeds. My mozilla shows them faster if I move the mouse, as does Irfanview (if I move it over the menu items), for example. To prevent this, I just make sure all frames are at least 50ms (20 frames per second is fine in most cases). Splarka (rant) 09:46, 24 January 2006 (UTC)

Actually, I have found that 50ms and below appears to cause Internet Explorer 6.0 to set the time between frames to a default of 100ms. Bottom line is that if the time for a frame is 60ms or above, IE will respect the time you entered, if it is 50ms or below (or no frame speed set at all) then IE appears to set the speed to 100ms. So, because of this, the slowest frame speed you can have in IE is 60ms. This really is very annoying and hopefully it will be fixed IE 7, but I doubt that. ngamradt 22:29, 22 February 2006 (UTC)

This article didn't answer my question in a way that I could understand

This article did not help me answer my question about GIFs.

I had been told that GIF only "supports" 256 colors, and that graphic artists need to be careful to use only these 256 "websafe" colors when working with GIFs, because any other colors could not be faithfully stored usiig GIFs.

I wondered if this was true, and if so, where I could see all 256 colors laid-out side-by-side.

The article opens by saying, "GIF is a bitmap image format for pictures with up to 256 distinct colours." Later it says, "the maximum number of colours available for each frame is 256... The limitation to 256 colours seemed reasonable at the time of GIF's creation.."

But the article never made clear to me (a relatively unsophisticated graphic artist) whether it was referring to 256 specific colors, or not. I just wanted to know if my favorite lime green (B5D81E)is supported by the GIF format!

So I had to turn to another source, and voila, the answer to my question (courtesy of Rick Matthews at Wake Forest University):

"GIF creates a table of up to 256 colors from a pool of 16 million. If the image has fewer than 256 colors, GIF can render the image exactly. When the image contains many colors, software that creates the GIF uses any of several algorithms to approximate the colors in the image with the limited palette of 256 colors available."

Why doesn't the article say anything that simple to understand?

Jrbrunger 08:50, 26 February 2006 (UTC)

- Because your question has nothing to do with the .GIF file format. The issues surrounding websafe colours have nothing to do with how the image is encoded, but how it is displayed by the client. No matter how you represent your image (BMPs, JPGs, PNGs, SWF, et. al.), the issue of websafe colours still applies (or doesn't, depending on the combination of OS and hardware used by the viewer). While the article could indeed have pointed out that the palette used by GIFs is not set in stone, this would be overstating the obvious somewhat: there does not, to my knowledge, exist a single image format with a fixed palette. If you wanted your question answered, maybe you should have looked in Web colours.

- FWIW, the websafe colours are ones that won't be corrupted (or, in turn, corrupt the rest of the display) when displayed by an operating system that is using a colourdepth of only 256 colours. 256 colour display modes (at least on the most common implementations) are palletised, so they can display more than a fixed set of 256 colours, but they only support one palette of 256 colours for the entire screen. In order to display images, the OS must put together a palette that contains all the colours that all the images and applications on screen are using. If there are more than 256 colours to be drawn on screen, this is obviously not possible. In this situation, most OSes dither down to the web-safe colours, and so an image that uses only web-safe colours will never get its colours changed (most OSes use only web-safe colours in drawing their widgets so they won't get dithered).

- Oh, and no your lime green is not a web-safe colour. Websafe colours are of the following form: [00,33,66,99,CC,FF][00,33,66,99,CC,FF][00,33,66,99,CC,FF]. A simple rule of thumb is that if you have any digit that's not divisible by 3, or if you have any component where the units is a different digit from the 16s, the colour is not websafe. The closes websafe colour to B5D81E would be something like CCCC33, or CCFF00.

GIF can use a plate of 256 colors for each block, and really it would be odd if it was limited to only specific 256 colors. It is possible to simply test it out and check if it has to be specific 256 colors, but however it can generate a plate with colors from all accross the entire RGB "pool", a bit less than 17 million colors (8 to the power of 8 to be exact). GIF is pretty limited to 256 colors more or less, however you can get around it by using more block, as seen here - http://phil.ipal.org/tc.html Nefzen 22:22, 23 August 2006 (UTC)

color or colour?

make up your mind.

Um, why -- they are both valid spellings. Or is it beyond the average reader to grasp that these are the 'same' word? Should we always use the same spelling -- just, perhaps, to make it easier for the purveyors of spelling-check programmes?  :-) quota

If there's any dispute on the topic, the fact that Compuserve is a U.S. company would seem to incline towards "color"... AnonMoos 19:51, 28 March 2006 (UTC)

So? They didn't invent either color or colour :-). quota 11:44, 29 March 2006 (UTC)

Perceptive, Adaptive, and Selective

Would it be beneficial to outline the differences between these three? Or is this terminology used only by Adobe Photoshop? Gordeonbleu 21:10, 15 April 2006 (UTC)

Can you give us some more context on where exactly theese terms occour? Plugwash 01:40, 8 May 2006 (UTC)

In Photoshop, when using "Save to Web As", selecting GIF will bring up a drop-down menu with "perceptive", "adaptive", "selective", and "web". "Web" seems to refer to web-safe colors only. I'm not sure what kind of GIF differences the other three carry. Gordeonbleu 06:39, 9 May 2006 (UTC)

From the context I suspect they are options related to color reduction. I also stronly suspect they are photoshop specific terms. Plugwash 17:12, 9 May 2006 (UTC)

Feb 2006 has passed, and IE7 is coming

Does this mean that the article is out of date, and in fact the patent no longer applies? Also, Internet Explorer 7 Beta 2 is now widely available, and the PNG issues have been fixed! yay!

Possible plagiarism on another site?

I was just browsing the web, and I noticed that the site at [3] looks as if it was copied almost word-for-word from this article. What should be done? ThefirstM 22:12, 16 May 2006 (UTC)

Have a look at Wikipedia:Mirrors and forks. Zetawoof^(ζ) 06:01, 20 May 2006 (UTC)

Only Animation Format?

Apart from the SWF format of Macromedia Flash, GIF is the only widely used image format to support animation. It is frequently used to make small animations and short, low-resolution films for web pages. I suspect SVG can be added to this list, if not today, very soon. SVG is supported in Opera and Firefox, at least. —The preceding unsigned comment was added by Mdwyer (talk • contribs • CheckUser • page moves • block • block log • edit count).

Rule one of the web: if it can't be used in IE most websites can't consider using it. Plugwash 23:17, 28 June 2006 (UTC)

Actually it can. It's not natively supported so it requires a plugin that is not included by default. Then again, Flash also requires a plugin, even in Firefox (not surprising given it's propriety nature). Perhaps the primary difference is that the Flash plugin is fairly easy to obtain and it's used so ubiqitously that most people will have the Flash plugin. Nil Einne 17:12, 12 August 2006 (UTC)

I think its reasonable to say that its hard to get an installed base for a format through the web alone, people are getting more and more scared of installing software they have never heard of and any firm that used drive by tactics would quickly become something many people didn't wan't to associate themselves with and a target of antispyware products.

I think MS actually shipped flash with windows at one point (i got "macromedia shockwave flash" as an option when i did a win98 install recently). I suspect it was this that at least partially got flash the critical mass.

afaict acrobat reader and quicktime got out into the installed base and public mindset through retail packaged software (PDF was often used for manuals and quicktime for video support), i'm not sure how realplayer made its impact. Plugwash 17:34, 12 August 2006 (UTC)

<img src="http://www.gifninja.com/Workspace/432620f8-5f85-48ec-8b86-d8a8b8d5b952/output.gif">-

I would like to add this or a different low resolution video animated GIF to the main GIF page. How do I go about doing this? Please someone message me if you can. Thank you

True colour renders fine in MSIE & Firefox

"Unfortunately, most web browsers seem to assume that this multi-image feature will only be used for animation and insert a minimum delay between images." I tested this assertion with the demo link provided, and it's not true: the 32K-colour GIF renders fine in Mozilla Firefox 1.5.0.4 and IE 6.0.2900.1800.2180.…. Seahen 21:09, 1 July 2006 (UTC)

When i tested it in both IE and firefox it rendered fine in the end but there was a noticeable delay between blocks that could not be attributed to network delay as it rendered just as slow when loading from local storage. Plugwash 11:43, 31 July 2006 (UTC)

Tested it in Opera 9.02, IE7 beta 3, and Firefox 1.5.0.6, and in all browsers there's a delay visible: it takes 19 seconds to fully load the image! Like Plugwash said, when loading from hard disk it's just as slow. -- Sander 16:20, 9 September 2006 (UTC)

Also see the delay in Seamonkey 1.0.4 . It really is rendering it frame by frame.

2 images removed

Removed the following -

With pictures like this you can see the restriction of 256 colours. The image is quite coarse-grained.

A rotating globe in GIF format. If you look carefully at the seas you can see unevenness caused by the colour reduction using an inappropriate technique.

Can you see the grain and colour-reduction without downloading larger versions? —Preceding unsigned comment added by 212.199.22.115 (talk • contribs)

Yes. Did you remove them because the dithering is hard to see? Maybe the article needs better images to illustrate this phenomenon. But in the meantime, they are better than nothing. --Yath 07:18, 15 August 2006 (UTC)

Yes i most certainly can see the dithering and color reduction bands, have you tried a decent monitor test sequence recently? Plugwash 18:07, 15 August 2006 (UTC)

GIF is a 24-bit RGB bitmap image format ???? It's not I think.

Look at this edit by an IP user 16 days ago. They claim that GIF was an 24-bit image format. It seems if there's no interest in this article: Noone reverted it. --Patrick Maitland 19:30, 23 August 2006 (UTC)

24 bit RGB is GIF's colour space. Compare PI1 (as used on the Atari ST), which has a 9-bit colour space. See also the bit in the article about truecolour GIFs. —Preceding unsigned comment added by 80.168.238.159 (talk • contribs)

• GIF (like many other formats in indexed color mode) uses a 256-color palette that selects colors from 24-bit colorspace. Therefore, it can technically display 16.8 million colors, but only 256 of them in a single image. Still, if something in the article causes confusion, it should be rephrased. - Sikon 03:30, 11 September 2006 (UTC)

IBM Patent

There isn't any mention of IBM's patent held over the GIF format in this article. [NOTE: added tides post-comment]DevAnubis 22:10, 28 September 2006 (UTC)

Is there a reason for this or is it ok for me to add details about it?

it was removed by JeffW with the edit summary "IBM not enforcing a patent isn't noteworthy" (i don't personally feel strongly either way on this issue). Plugwash 20:28, 28 September 2006 (UTC)

yes, IBM are not "enforcing" it. but it still exists. and it still prevents the use of GIFs in a truly free software environment such as Gnu.DevAnubis 22:10, 28 September 2006 (UTC)

Honorable mention?

• Is it referring to YTMND as a side-effect of the GIF? --MichaelAhlers 18:55, 29 September 2006 (UTC)
  • Is which referring? But yes, YTMND is the new Compuserve. --Dwiki 20:33, 30 September 2006 (UTC)

Size of rotating globe image

The rotating globe image shown in the article is 468293 bytes. I think this is inconveniently large for people with low bandwidth connections.

Wikipedia:Image_use_policy#Size says "Inline animations should be used sparingly; a static image with a link to the animation is preferred unless the animation has a very small file size." Jibjibjib 01:16, 31 October 2006 (UTC)

Weasel words...this page is full of them. It should get checked out.

Editing GIF

How would I be able to edit a gif? Can I use Microsoft Paint? --66.218.23.154 02:48, 15 January 2007 (UTC)

Suppose so, but how can someone edit/create animated GIFs? JohnathanZX4 21:00, 20 January 2007 (UTC)

Yes Microsoft Paint can open, edit and save images in formats .BMP and .GIF. It can also open and save .JPG images but remember that .JPG compression usually introduces some distortion.

To create animated .GIFs you need GIMP or any of a variety of animated gif editors that Google can find. To understand the GIF file format, perhaps even to make your own editor, look at the specification at http://www.wotsit.org/download.asp?f=gif89m.Cuddlyable3 01:07, 14 February 2007 (UTC)

User:Motter

User:Motter (contribs) insists on adding links to to this article that lead to his website, at least according to his talk page, quoted below:

like 5 months ago somebody put a link to my free gif making site on the wiki gif page. I didn't put it up there but it has been removed by some person that thinks they are the almighty ruler of wikipedia. I don't really care how cool you are with wiki lingo or how often you check an article that doesn't interest you in the least the better the "community". What I do care about however is offering a totally free service to the users of wikipedia that are searching the internet to find a way to create gifs. leave the link alone Ub3|2N3|2d!

His reasons for including the link therefore appear to fall directly into Wikipedia:External_links#Links_normally_to_be_avoided. I and several other editors have remove the link and warned him that it is spam. His responses have included deleting other links from the article and consistently adding his link back claiming that it improves the article or stating that he was fixing it.

User:Motter has been invited to discuss his concerns on this talk page. GDallimore (Talk) 10:44, 27 February 2007 (UTC)

gifninja is a free .gif site that offers tools and over 50,000 free animated .gifs and rising. You just aren't going to convince me that the site isn't relevant.

As for the site being affiliated to me. I wasn't the person to list the site originally. When you came along and removed it cause you felt like it, I repaired your vandalism and intend to continue to do so.

—The preceding unsigned comment was added by Motter (talk • contribs) 00:31, 28 February 2007 (UTC).

I have removed the link to the "removed" site from the above comment since that defeats the point. I also does not consider that the number of gifs on a site makes it an appropriate link for the article for the reasons already mentioned above. I recommend you read through those guidelines carefully since, although wikipedia is an open encyclopedia, it is not an anarchy. GDallimore (Talk) 00:48, 28 February 2007 (UTC)

Ok.. fine, for the purpose of this article I don't care if it is hyper linked or not. But I put the url in plain text for others to see that site and see that it is relevant to the article. I also removed the word "offending" from your passage cause there is nothing offending about it.

Look, Wikipedia has guidlines because WP:NOT#Wikipedia_is_not_an_anarchy. When it comes to external links, these include the following:

• From Wikipedia:External_links#Links_normally_to_be_avoided

• Links mainly intended to promote a website
• Links to social networking sites

the main purpose of the site appears to be to create (extremely basic) animated gifs for MySpace

• Sites that are only indirectly related to the article's subject:

the site has tools for making gifs but has no useful information about gifs, it is therefore only indirectly related to an article about gifs

• Advertising and conflicts of interest

Motter is apparently the owner of the site. The fact that he didn't add the link originally is irrelevant.

The site also meets none of the requirements for Wikipedia:External_links#What_should_be_linked:

Finally, take a look at Wp:not#Wikipedia_is_not_a_mirror_or_a_repository_of_links.2C_images.2C_or_media_files and Wikipedia:WikiProject_Spam#Common_spammer_strawmen for why your protestations of non-spam are not found to be acceptable by me. GDallimore (Talk) 10:25, 28 February 2007 (UTC)

As a second opinion, I am afraid basically GDallimore is right about this. Your site is good, free and offers a useful service to people wanting to convert formats but it does not qualify as a reliable reference site giving more information on the article content. So I am afraid it shouldn't be listed here. I suggest you submit it to the open directory or somewhere which is a list of useful links: Wikipedia is not. --BozMo talk 10:41, 28 February 2007 (UTC)

User:Motter. Some valid concerns have been raised. There are substantial WP:COI and Advertising and conflicts of interest issues. Asside from the link being Links normally to be avoided, The link that continues to be added to this article is not appropriate as it is not a resource about the subject.--Hu12 10:43, 28 February 2007 (UTC)

GIF format may now be used freely

GIF format may now be used freely? Can we really jump into conclusion like this? I'm not so sure of this issue, it doesn't seem very clear for me. What about country not mention on the list? What about specific international patent trades ? --201.35.201.122 11:49, 24 May 2007 (UTC)

Firstly, it's true - the only patented part of GIF was the LZW compression method and the patents on that have expired. Just don't go using newer compression methods or you might get into trouble. Secondly it's said in the sources such as the "burn all gifs" site so it's not us coming to conclusions. The countries listed are the only countries where there were patents. I have no idea what you mean by "specific international patent trades".GDallimore (Talk) 11:57, 24 May 2007 (UTC)

⟨⟩

External Links

The animations in this article do not seem to work in Firefox: GIF Animation on the WWW - technical explanation of the GIF89a format and how it allows animation —Preceding unsigned comment added by Bitbut (talk • contribs)

They all move with firefox, (well iceweasel), v2.0.0.11, but this .gif animation of a nanotube, stays still. The same nanotube .gif moves in iceape. Linux box, FWIW. --AC (talk) 06:53, 23 January 2008 (UTC)

gallery

can we link to a gallery of all of wikis .gif images? do we have such a gallery?♠♦Д narchistPig♥♣ (talk) 00:14, 24 February 2008 (UTC)

Tools

How exactly can one create a animated GIF from scratch? And which tools?Anwar (talk) 20:35, 9 May 2008 (UTC)

• see below... 79.72.169.159 (talk) 20:48, 19 June 2008 (UTC)

Animated GIFs

I arrived at this page on a redirect(animated gif) trying to learn specifically about animated GIFs. After reading the article and doing research elsewhere i added an internal link, UnFREEz, as i thought it would be helpful, a few minutes later GDallimore reverted it. After further reading a 'connection' emerged... GDallimore appears to have proposed deletion of UnFREEz about a year ago, i presume the deletion didn't go ahead. Any seasoned editors got any suggestions ?? 79.72.169.159 (talk) 20:47, 19 June 2008 (UTC)

UnFREEz has been nominated for deletion. Even if not deleted, Wikipedia is not a "How To" guide so there is no need to have a link to that article from here. GDallimore (Talk) 22:34, 19 June 2008 (UTC)

UnFREEz was twice proposed for deletion by GDallimore, ten minutes prior to leaving the comment above and approximately one year ago. There is scant information about animated GIFs on this GIF article, maybe GDallimore (self confessed patent attorney) has a incentivized agenda. 79.72.128.85 (talk) 15:23, 20 June 2008 (UTC)

I suggest you remove your personal attacks. GDallimore (Talk) 15:47, 20 June 2008 (UTC)

User:79.72.149.81, your latest attempt to rationalize inclusion of a link to your favored site is unacceptable as content in the article. Respect external links guidelines, the fact that Wikipedia is not a link farm or public billboard, and the consensus of this article's curators by giving up on using using Wikipedia to promote this particular site/service/software you're so fond of. And when writing article content elsewhere, avoid weasel words and provide citatons from reliable sources so that everything you wrote is verifiable, otherwise it will be removed with speed roughly corresponding to how potentially contentious the content is. Also, create an account and log in with it. —mjb (talk) 18:41, 25 June 2008 (UTC)

Proposed move

I propose this article be moved to GIF (graphics format). The fully-expanded name is correct, but not widely used or familiar. Compare with people - we don't include their full names if they're better known by a shorter name. Dcoetzee 01:03, 18 October 2008 (UTC)

It used to be just GIF, but was changed some months ago - probably because you shouldn't normally use the acronym as the article title. Also, GIF redirects here so it's not as if people won't find what they're looking for. But you're right, people always say "GIF". I think it's a balanced issue. Suggest not making an arbitrary decision here, but raise the discussion on a few graphic format pages, Portable Network Graphics and JPEG say, and see if there's a topic wide consensus. GDallimore (Talk) 11:45, 18 October 2008 (UTC)

Naming conventions for image file formats

Please see the discussion at Talk:Image file formats#Naming_conventions_for_image_file_formats on naming conventions for articles on image file formats. Dcoetzee 00:47, 25 October 2008 (UTC)

Internet Explorer does not display fast GIFs at the right speed.

Yup, Microsoft's Internet Explorer does not display fast GIFs at the right speed. To prove it I made a 151 frame timer that counts to 3 seconds. I set each frame to be shown for 0.02 of a second. When I open the GIF in FireFox it animates at just about the right time, but when I open it in Internet Explorer it takes a whole 15 seconds to count up! This means that Internet Explorer changes each frame to be shown for 0.10 of a second. It might be worth mentioning somewhere in the article. Akadewboy (talk) 17:01, 10 October 2008 (UTC)

I also observe the difference, but I think this is squarely in the territory of original research (I think it has to do with the fact that IE is unwilling to skip animation frames, and each one takes a certain minimum time to render). It'd be nice if MS themselves had a KB for this, but they do have a reported bug about it on Microsoft Connect. Dcoetzee 18:19, 10 October 2008 (UTC)

IIRC firefox has the same issue at least it did last time I tried it. Plugwash (talk) 12:10, 18 October 2008 (UTC)

This is fairly recent so I'll reply. I'm not sure if the file being checked on was done so locally, but certainly any GIF is going to animate more slowly as its frames are still being downloaded. Not sure if that would cause the effect you're mentioning, though.

User 128.239.195.25 that is wrong. The browsers do not display an animated GIF while it is not yet downloaded. Please get an account and sign your posts. Cuddlyable3 (talk) 14:15, 2 December 2008 (UTC)

Dithered sunflower image

An example of a GIF image. The dithering process used to overcome the format's 256-color limitation makes the image appear coarse-grained. Note that this preview has 44 000 colors.

I have copied the dithered image here and propose removing it from the main article. Showing a reduced-size version of an (inconveniently) larger image creates confusion about cumulative effects of the dithering and subsequent resampling for scaling. Some information about the available palette and the choice of dither process is desirable if this is to demonstrate the change that dither produces. At pixel level a normal .gif image cannot have more than 256 colours. Arnero, how did you calculate 44 000 colours? Cuddlyable3 (talk) 19:27, 1 January 2009 (UTC)

"3D" and "fluid" animation

I just changed the captions for the animated images, and wanted to add a clarifying note here about why I made changes to one of them:

First, it said the animation was an example of "3D" animation using GIF. But GIF doesn't do 3D animation per se; it does animation of a series of still images, regardless of how those images were created. So saying that GIF can do 3D animation is the same as saying that any animation format can do 3D animation. A flip-book can do 3D animation if it's composed of a set of still images rendered by a 3D renderer. So I removed the word "3D" as misleading.

Second, the caption said the animation was an example of "fluid" animation. But in my browser, it displayed with a low frame rate, not at all fluid. So I removed that word as well. --Elysdir (talk) 19:15, 26 February 2009 (UTC)

I agree with both the above changes. We should look for a better animation example than BananaShoeShine.gif which has poor black level and is wrongly described as a stop-motion animation on its description page, Cuddlyable3 (talk) 21:27, 26 February 2009 (UTC)

Non-compressed .gif

There are 21 bytes in example, changed. —Preceding unsigned comment added by 77.37.142.221 (talk) 19:19, 26 April 2009 (UTC)

Netscape and animated GIFs

Being old enough to remember that Netscape played a big part in making animated GIFs popular, I was surprised to see no mention of Netscape in the article. So I added a paragraph about it. I hope I got it right.

I've used two refs I found via Google. Neither is very good. The only description I found of the layout of the Netscape Application Block was on a personal website. The only link I found for the fact that Netscape set things going was on a Russian site, which turned out to be an (illegal?) copy of a 1996 book. I really hope that someone with more knowledge or better Google skills can find better references.

Cheers, CWC 17:23, 28 August 2009 (UTC)

Why LZW for graphics?

LZW is based on constructing a dictionary, which makes sense for compressing text, but images?

Isn't any modern technique better? Like using filter + compressor.

Filter: Delta, RLE or quadtree

compressor: Huffman or arithmetic

Is GIF basically a thing of the past, historical interest, backwards compatibility? The palette would still makes sense for technical drawing and comics if it wasn't for antialising ... okay the palette is also a thing of the past. Can we state this in the introduction? Arnero (talk) 14:42, 31 December 2008 (UTC)

You may be right, but we shouldn't add anything without a source. And if a source is found, it shouldn't go in the introduction - it should go in the body of the article. Then, the introduction might be expanded to reflect that new part of the main article. GDallimore (Talk) 17:43, 31 December 2008 (UTC)

Arnero, documenting things of the past is what an encyclopedia does. We are not here to invent things. GIF's indexed palette can be a cause of banding on colour gradients but that is not the same as aliasing on line drawings. Cuddlyable3 (talk) 19:11, 1 January 2009 (UTC)

And GIF is hardly a thing of the past. It's still a very useful format for a variety of images, and it is still widely used on the web. Elphion (talk) 05:03, 6 November 2009 (UTC)

Text in GIF files

Years ago I remember GIF files that contained a number of images and also text. It had very primitive programming language like:

text "Hello world" picture 1, 10 fade text "Next one" picture 3, 30 blink text "finish" loop

I know this because you could view the program and change it using a hex editor. Consequently, it was easy to change the adventures of "Mandy" to whoever you wanted to impress.

I have not seen any documentation of this anywhere. Does anybody have any examples of this? I don't mean the adventures of Mandy, as I am sure that by todays standards it would be somewhat grainy. However an example of any GIF using the inbuilt text format would be nice. It must have been 89a as it supported multiple animated images in a single file. —Preceding unsigned comment added by Puzbie (talk • contribs) 16:27, 19 July 2009 (UTC)

The Plain Text Extension is described in the 89a spec (see link under External Links in the article). It's not widely used because there is little control over the font used to render the text (and the spec specifies monospacing, which generally looks pretty cheesy). I've added a blurb in the History section. Elphion (talk) 05:11, 6 November 2009 (UTC)

Not used much anymore?

Need section or comment on the decline in use of gifs over the last several years. 80.47.47.229 (talk) 10:27, 5 August 2010 (UTC)

Boy, that's not what I see. GIFs are still the lion's share of the images served by most of the sites I visit. -- Elphion (talk) 21:37, 5 August 2010 (UTC)

Link to original GIF sample image

I'm currently programming a GIF decoder, and I'm using both the wiki and the GIF specification as a guide.

The sample image, provided with the example file layout, is not what would be display when the GIF file is properly represented. Why isn't there a link to the original file? Wouldn't it be better if the sample image and the discussion actually matched? (more then a graphical representation)

An analogous graphical representations shouldn't be in gif format, and a link to the original should be provided, so there would be no confusion. —Preceding unsigned comment added by 203.214.122.182 (talk) 04:40, 7 November 2010 (UTC)

I agree it would be clearer to use the actual 3x5 image rather than the 32x52 enlarged representation, and to use {{thumb}} to blow it up to visible size. I've left a note for user:Cuddlyable3 to ask if s/he could upload it for us. -- Elphion (talk) 22:46, 11 November 2010 (UTC)

I created the listing. It defines the source file bytes under the heading "hexadecimal" (the omitted palette bytes at 011: to 309: are all "don't care" for this purpose). I have also uploaded the source file as "3x5 Sample image.GIF" which may be useful for testing a decoder. A problem with using this file in an article illustration is that it has no surrounding frame. That is why I made GifSample.gif which is used in the article. Cuddlyable3 (talk) 09:05, 12 November 2010 (UTC)

posterisation in globe invisible

On my computer the posterisation in the blue areas isn't visible, because they're too dark. I've checked the gamma of my monitor, and viewed some real world gamut test pictures, and I'm sure it's okay, the problem is with the image. If I cover the off-white areas around the image with my hands I can see that there's a blue area, but the bright Sahara sweeping by every few seconds makes it impossible to see if any posterisation is going on. (Additionally, there's no way for the reader to check if this posterisation is necessary, or an artefact of a bad palette choice, lack of dithering, or something else.) —Preceding unsigned comment added by 82.139.86.160 (talk) 23:51, 8 June 2010 (UTC)

I can't see it either. I think that is becauset a user optimised the original palette, see the File history [4]. Cuddlyable3 (talk) 09:13, 12 November 2010 (UTC)

File listing reversions

I undid the deletion by user:Cuddlyable3 of comments in the file listing. These tie the listing into the discussion of the file format earlier in the article. Also, the structure in his version is incorrect; the Global Color Table starts at offset 0x0D, not 0x0B, since the Header is 6 bytes long and the GIF89 Logical Screen Descriptor 7 bytes long. He objects to the word "sentinel", but its meaning (as reflected in Wiktionary, sense 2) is precisely germane here. -- Elphion (talk) 17:04, 3 March 2011 (UTC)

I have replaced the listing with its original version. It shows you are correct that the GCT starts at offset 0x0D. It is unnecessary to tie-in the listing by repeating details earlier stated in the section "File format". The Edit summary said: Reverted unnecessary additions to file listing. This is not a how-to coding guide. ASCII equivalents are irrelevant and "Sentinel" has wrong meaning. You are correct about the special meaning of "sentinel" in computer science but it was inserted unnecessarily where indents under the column heading "Meaning" already distinguish between codes that are block headers or block data, and with intent to introduce equivalent ASCII characters. The column headed text or value gives only the equivalents that are relevant, but ASCII is for communicating by people not machine-to-machine. Cuddlyable3 (talk) 18:50, 3 March 2011 (UTC)

Well, I certainly disagree with the notion that examples divorced from the context of the discussion somehow make a more effective presentation. This listing would be far more effective if it illustrated the points in the "File format" section. As for the sentinels, it is clear that the designers chose them not just as numerical codes, but for their human mnemonic potential: a file is seen as sequence of images separated by commas, punctuated with interjections marked by '!', and terminated by the semi-colon, a common statement terminator. It seems silly *not* to include these, at least in "Meaning" column, which after all is meant to communicate with humans.

Meanwhile, I have edited some of the comments to reduce the ambiguity or correct mistaken impressions. E.g., the "width pixels" is clearer as "canvas width in pixels", and the "default aspect ratio" is more properly the "default pixel aspect ratio", referring to the shape of the pixels, not to the shape of the canvas (since both are commonly called "the" aspect ratio of an image). Also, the GCE header should not include the length of the first sub-block. The length is part of the sub-block, not part of the block header, as indicated in the spec..

-- Elphion (talk) 19:13, 4 March 2011 (UTC)

It is wrong to present the GIF file structure as alternating between text characters and machine code because no one in their right mind types or decodes by hand a real-world GIF file. It is also unhelpful to cite the non-notable speculation that a designer at some point chose random ASCII punctuation codes for alleged mnemonic potential. That the GIF file terminator byte value happens to be the statement separator character value in programming languages is not notable and a distraction.

Codes 0x2C, 0x21, and 0x3B are only parts of block headers in the GIF structure with no other individual significance, any other byte values could have been chosen in their places, and they occur randomly again in typical image data. It would be silly to stuff the "Meaning" column with all the irrelevant significances a particular byte value can have in other contexts. The only bytes in a GIF file that have textual relevance are the first 6 that in effect tell anyone who mistakenly opens the file in a text editor "This is not a text file".

Elphion argues for including repetitions to make the article a more effective teaching presentation but that is not what we do here. Elphon's claim about what a GIF file "is seen as" is a primitive view not supported by the source. Elphon keeps adding the term "canvas" to the file listing, which is superfluous because "Screen" means the same thing as "canvas" in this context. Elphion latest edit includes damaging the list with an error at 30F:. This and other edits suggest that 1) Elphon is a student in the progress of learning about the GIF format who is inclined to doodle on the "Meaning" column of the list by expanding on the remarks there, and 2) there may be a language difficulty. The GIF article has occasionally attracted vandalism and although it is nice to know that someone reads it, Elphon should stop editing the code-level listing parts that have been thoroughly checked earlier. The GIF89a spec. states that the sub-block length value is fixed in the GCE header and therefore imparts no information, so it seems a quibbling formalism to regard it as outside the header. Cuddlyable3 (talk) 18:52, 12 March 2011 (UTC)

(outdent) I will not address Cuddlyable3's ad hominem remarks except to say that his speculation about my being a student or having a "language difficulty" are widely off the mark. I've known (and programmed) the GIF format for many years, and English all of my life.

I said nothing about a teaching exposition, but if what we are about here is not the effective presentation of information, then I don't understand the point of Wikipedia at all. I will continue to make edits that I believe make the presentation more effective. My "doodles" are not for my benefit but for other readers'.

Cuddlyable3 points out an error in my edit of the GCE header -- I forgot to remove the block size from the header line when transferring it to a separate line, similar to the handling of the image data sub-block. I've corrected that. I'm also not tied to the term "canvas" -- while it is succinct, suggestive, and brief, "logical screen" (but not "screen" by itself) will do as well, and I've made that change in the article too. The point is that "width pixels" and "height pixels" by themselves don't give enough information -- width of what and height of what are important additions.

The length of the sub-block belongs with the sub-block, not the header. While in this case the length is fixed in the spec, the spec is also clear that the structure of an extension block consists of a header followed by sub-blocks, and it is quite clear about the structure of a sub-block, which includes the length as the first byte.

I have not insisted on the interpretation of the sentinels being included in the article, since this is not mentioned unambiguously in the 89a spec. However, the 87a spec does identify the three sentinels by character value first, not by numerical value; and it refers to the comma as an image "separator" and the semi-colon as a "terminator". The odds against these being randomly chosen numerical values, as Cuddlyable3 suggests, are enormous.

-- Elphion (talk) 21:14, 12 March 2011 (UTC)

No, randomly chosen ASCII punctuation codes. They do not serve their respective textual functions. Cuddlyable3 (talk) 10:59, 19 March 2011 (UTC)

Again, I think the probability indicates otherwise: (a) why choose punctuation codes at all, if not for their suggestive connotation; (b) the particular punctuation chosen does happen to correspond with the semantics of the sentinels. -- Elphion (talk) 17:50, 20 May 2011 (UTC)

GIF is not a programming language. Terms like "suggestive connotation" have no meaning in machine code. Speculation about the designer's thinking before the standard was issued is not for the article. Cuddlyable3 (talk) 22:05, 20 May 2011 (UTC)

Of course it's not a programming language; but neither is it machine code. It's a file format, a convention for representing images. Such a convention can be endowed with a great deal of mnemonic structure for the convenience of humans: people inspecting the file, or coders dealing with code that interprets the file. The mnemonic chunk codes in PNG are a good example. There's far less of that in GIF, but without question the sentinels were chosen for their mnemonic value, especially given the original conception of GIF (each file a series of images, with the possibility of many such series being queued together in an input stream). However, as I indicated above, I am not advocating adding this to the article, so it's rather a moot point. -- Elphion (talk) 00:33, 21 May 2011 (UTC)

No Interlacing Information

There is no information about GIF interlacing on this page. The PNG page is very good reference to how PNG interlacing works, even including an animated GIF showing the process (ironically).83.216.149.7 (talk) 19:04, 9 December 2011 (UTC)

I added a short section on interlacing. -- Elphion (talk) 21:30, 9 December 2011 (UTC)

Big-endian

I modified the declaration where multi-byte data inside the GIF format were described to be little-endian. The GIF89a specification states: "Multi-byte numeric fields are ordered Least Significant Byte first", so they actually are big-endian. --Aldoaldoz (talk) 12:51, 23 March 2012 (UTC)

"ordered Least Significant Byte first" is the definition of little-endian; see Endianness -- Elphion (talk) 13:25, 23 March 2012 (UTC)

sorry --Aldoaldoz (talk) 14:19, 23 March 2012 (UTC)

no problem; we all make mistakes -- Elphion (talk) 17:42, 23 March 2012 (UTC)

Resurgent Popularity

I believe this article is due for a section on the popularity of the GIF format in the modern internet. Animated gifs are used now more than ever on social sites like tumblr, reddit, 4chan, and internet forums, but you wouldn't know it based on the article here. Reaction GIFs as a phenomenon should be covered.76.199.7.225 (talk) 08:41, 25 December 2012 (UTC)

To "resurge" in popularity necessarily implies the GIF went out of favour. I wasn't aware that it had. Despite the efforts of various anti-patent groups to stamp it out, and the assertion that patent protection would stifle it as a format, GIFs have always been an important and well-used format. Until such time as there is a section about falling usage of GIFs, there can't be a section about a resurgence in their popularity. GDallimore (Talk) 20:39, 27 December 2012 (UTC)

I agree with both of you. GIFs have never gone out of style, but animated GIF's in particular have become a popular decorative art form worthy of mention. -- Elphion (talk) 22:05, 27 December 2012 (UTC)

In 2012, the word "GIF" was officially recognised as a verb

Officially? Dictionaries don't make langugages; speakers do.80.103.84.224 (talk) 10:39, 19 March 2013 (UTC)

If you're objecting to the use of the word "officially", I'd agree. See if you can find a better word and improve the article. If you're objecting to the entire statement, I don't agree since dictionaries reflect usage, they don't make things up for their own amusement as you seem to be implying. GDallimore (Talk) 11:07, 19 March 2013 (UTC)

Page Protection

Maybe protection of this article is needed. It seems there are constant changes over just one issue - the pronunciation. While I accept that /ˈɡɪf/ is correct it must be acknowledged that /ˈdʒɪf/ is also used. Indeed I would say that the second pronunciation is much more common and pretty universal outside of experienced IT professionals. The second pronunciation also fits in with pronunciation rules in many Indo-European languages (whereby a G followed by an e or i is pronounced /dʒ/ - this is more often than not the case in English too, for example germ, Geoff, Gemini, genetics, gentle, general, geography, giant..., although there are so many words which contradict such a rule). I would also say that an inventor cannot control how a word is pronounced and used (patents and trademarks might control the latter though) It seems that it is best to include both pronunciations.--217.71.47.190 (talk) 19:52, 22 May 2013 (UTC)

I should add that edit warring may only be temporary and related to today's article on the BBC (http://www.bbc.co.uk/news/technology-22620473).--217.71.47.190 (talk) 19:58, 22 May 2013 (UTC)

Functioning URL: http://www.bbc.co.uk/news/technology-22620473
-- Elphion (talk) 20:08, 22 May 2013 (UTC)

If you think that will stop the arguments, just look at the comments there! -- Elphion (talk) 20:09, 22 May 2013 (UTC)

I agree, by the way, that both pronunciations should be given, because both are wide-spread. I question your characterization of the hard G as "pretty universal" -- in my experience just the opposite is true. I don't know whether this is a regional variation or an occupational one. I've seen no solid evidence either way. There is no "offical" pronunciation, of course, though there is an original one. From there, usage is pretty much up for grabs. Language does change, but as anyone that crosses the ocean knows, not in lock-step! -- Elphion (talk) 20:15, 22 May 2013 (UTC)

I support changing the pronunciation of other words too, Jirlfriend, Jifted, jills, jib, jit, jig, to jive, jizmo, jilly suit, Jimmick, Jiggle, Jigabyte, Jirdle, Jibson and other words found at Joogle datboi (Talk) 20:43, 22 May 2013 (UTC) — Preceding unsigned comment added by 201.174.39.102 (talk)

The warring is probably just due to the twitter explosion more than the BBC. It's a bit more than usual, but manageable and has thrown up a couple of useful sources so protection would seem to be damaging to the end goal of improving the article. GDallimore (Talk) 20:43, 22 May 2013 (UTC)

How is the inventor's declared, official pronunciation, as used in all internal and external communications by CompuServe and CompuServe employees, "not official"? RvLeshrac (talk) 19:32, 23 May 2013 (UTC)

What legal force does it have? What else do you mean by "official"? -- Elphion (talk) 19:44, 23 May 2013 (UTC)

I think it can be referred to as the "offical pronunciation supported by Compuserve" if there is a reliable source (eg a compuserve announcement) stating that that is their position, but I haven't seen such an unequivocal statement. However, even if there were, that still doesn't require any changes to the lead of the article or any suggestion that the hard G pronunciation is less worthy or more wrong in the eyes of the general public (rather than various special interest groups). The article says the creator intended and still wants it to be pronounced one way, but it isn't by lots of people and even dictionaries have recognised the alternative description. There is nothing incorrect, misleading or wrong about any of that and there is therefore no reason to remove or play down the "non-official" pronunciation. GDallimore (Talk) 20:15, 23 May 2013 (UTC)

"JPEG came later with the Mosaic browser."

I've removed this sentence. While it may be true that Mosaic was the first browser to support JPEGs, inline graphics were a concept invented by the Mosaic team anyway, they were not part of the original HTML specifications developed at CERN.—Austriacus (talk) 18:20, 22 May 2012 (UTC)

This is the subject I've come to check for talk discussions about. If XBM was ever a major online image format it must have died on its ass very quickly - even in TBL's own documentation about his in-house browser at CERN and its early third party cousins, he never mentions it; the inclusion of image support in the changelog is marked as "you can now include tiff, postscript and giff" (sic)... or any other format so long as your system has an installed codec for it (paraphrase). XBM is a terrible low-tech, insecure, very inefficient format even when compared to something like BMP, and after being online for the better part of 20 years this is literally the first time I've heard of it mentioned as an option for web graphics. Both GIF and TIFF do everything XBM can, and do it better, without freezing out any potential viewers.

The question is when JPG support came in ... surely given the above, if a viewer had a JPG codec in their system already, then you could quite happily include one on your webpage and the browser would pass it to the OS for decoding. I seem to remember this not being an initially all too common thing ... but the first browsers I used supported it intrinsically even though the operating system had no idea what the file was until you installed a dedicated image editor, or an advanced enough copy of MS Office/etc. And it might not have been a natural choice at first - until hi-colour and true-colour displays came along, there was pretty much no point to it, as you'd get a better result with GIF (and preferably one tuned for 16 colours rather than 256, at that), it just meant the browser would have to go through an additional complex decoding step (exceptionally slow on any CPU without a numeric coprocessor, unlike GIF's speedy integer-based decoding and TIFF's tendancy to be completely uncompressed) and then dither the image down to suit anyway. 16/24 bit colour and FPUs being built-in rather than specific add-ons didn't become a particular thing in everyday computers until the 90s were well underway, and couldn't be relied on until the second half of the decade. My school's internet-connected computers, around 96-97, were still running 256 colour displays at VGA or SVGA resolution (most but not all could do at least 16-bit, and many could do 24, but it was slow, memory hungry and often came with screen flicker), and the older ones were 486-SXes or even 386s which had much more trouble dealing with JPGs than the more up-to-date DX2s and Pentiums. It was typically reserved as something you used for dealing with the conflict between scanned photographic images you wanted to insert in documents, and the very limited disc space you were allocated between the network and whatever floppies you could fit in your pocket, rather than chucking pictures across the web. (All the same, I have a feeling one of the first websites I ever saw used them - very small and easily decoded ones, however)

Could well be that this format wasn't specifically supported at all until Mosaic came along then. I haven't been able to find anything that makes a definitive case either way, but between your representation and my slightly patchy memory and a bit of reasoning, it seems most likely. I'll hold off inserting it alongside the others though - but I'm still very tempted to do SOMETHING to the mention of XBM, because it's little more than an irrelevant curio (probably supported simply because it was a default Unix format, rather than anything expected to get serious use), and there's no mention of TIFF etc, which certainly WAS used (including in several of Berners-Lee's example HTML documents) and had excellent cross-platform compatibility (I don't think I've yet used a 16-bit or better computer that doesn't have some kind of ability to load and convert them). 193.63.174.211 (talk) 11:15, 11 October 2013 (UTC)

EDIT: I've since seen a comparison table, here on Wikipedia, that shows the image formats supported by various browsers, including a lot of early ones. CERN's own WorldWideWeb, which had quite a limited lifespan, officially being discontinued in 1994 at version 0.18, and is officially the FIRST web browser ever made? Supports JPG and GIF, apparently ... and nothing else. Not even XBM. Something doesn't quite taste right here, but as that's not a capability combination shared by ANY other browser on the list (a couple have less, all the others have at least one or two more, some have patchy support for one or the other), it might be worth giving the author of that list temporary benefit of the doubt. Several other browsers are listed as supporting XBM, and some as having had it then dropped it, but it's actually missing from some of the earliest ones like WWW itself. JPG certainly existed at the time, so it's possible it was an option. All the same, it says WWW doesn't support TIFF either... which is demonstrably false. Hmm. 193.63.174.211 (talk) 11:24, 11 October 2013 (UTC)

Animation + more than 256 colors possible?

It would be nice if the article answered that. --TiagoTiago (talk) 03:15, 23 May 2013 (UTC)

It does. -- Elphion (talk) 06:45, 23 May 2013 (UTC)

And has done for about 5 years already. 193.63.174.211 (talk) 12:19, 11 October 2013 (UTC)

WebP format

Should also include information about animated WebP as a possible replacement, although it's only supported by Chrome. http://blog.chromium.org/2013/11/chrome-32-beta-animated-webp-images-and.html --192.136.210.191 (talk) 02:56, 16 December 2013 (UTC)

Hardly a viable replacement yet, but added to the list of alternatives and I've rewritten that entire section. GDallimore (Talk) 13:01, 16 December 2013 (UTC)

Image Coding

Could an editor please expand the Image Coding section. It is intended to show how the 9-bit codes are mapped to 8-bit bytes, but it isn't clear that the codes/bytes are being packed right to left (a naive interpretation might assume left to right which makes it unclear what is actually happening). Maybe it could be explained a bit more clearly (e.g. using colour coding?) to match the quality of the rest of the article. — Preceding unsigned comment added by 88.215.37.80 (talk) 18:26, 14 January 2014 (UTC)

I've made an attempt. Does it help? -- Elphion (talk) 20:10, 14 January 2014 (UTC)

Use for sprites in games

How do you cite the fact that sprites in games are stored as GIF files? 12Me21 (talk) 22:11, 20 January 2015 (UTC)

First you find a reliable source that says that. Then you put information about the source (author, publisher, URL, anything that is appropriate for locating the resource) in the text between <ref> and </ref> to turn the information into a footnote. Don't worry too much about the format, that can be fixed up later. What's important is information to identify the source. -- Elphion (talk) 01:06, 21 January 2015 (UTC)

Unisys and LZW patent enforcement

The current wording makes it seem like the company was a passive innocent victim, but that's really not the case -- in fact, it changed its stated policies and enforcement strategies several times over the years, and during the last year or two before the U.S. patent expired, it seemed to be flailing around and trying to extract a little more blood out of the turnip by any possible method. The issue of retroactively closed/proprietary file formats has been a very sensitive one for on-line communities ever since the ARC wars of the late 1980s (before there even was a commercial consumer Internet). AnonMoos (talk) 15:45, 10 March 2015 (UTC)

The section looks reasonable to me, and it does mention that Unisys tried to change the rules later on. I don't get a whiff of the company being an innocent victim. Just about everyone agrees that the patent "opportunity" caught them completely flat footed, and that they didn't handle the resulting foofoorah very well (and the article says that). They certainly didn't scheme to entice CompuServe and thereby the entire WWW into their snares. But I don't fault them for trying to make some money from the patent: until we change how patents work in the computing environment, that's the way the industry works. -- Elphion (talk) 18:53, 10 March 2015 (UTC)

The wording "Nevertheless, Unisys was subjected to thousands of online attacks and abusive emails from users... Despite giving free licenses to hundreds of non-profit organizations, schools and governments, Unisys was completely unable to generate any good publicity and continued to be condemned..." conveys the impression that Unisys was a bunch of hapless well-meaning people buffeted by circumstances largely beyond their control and targeted by malicious Internet trolls -- but that was not actually the case. A few people may have gone overboard, but there was a much larger group of solidly determined and well-informed people who had reasonable grounds for opposing Unisys' positions... AnonMoos (talk) 10:20, 11 March 2015 (UTC)

If you're not happy with the wording, why don't you suggest an alternative? We ought to be able to craft something appropriate. But "hapless well-meaning people buffeted by circumstances largely beyond their control" is pretty much accurate (especially the "hapless" part). The "burn all GIFs" campaign was an incredible over-reaction and completely poisoned the waters. I agree there were plenty of people opposing Unisys's position (of whom I was one), but the fact remained that Unisys had a patent on a key piece of technology and was acting well within its legal rights. Compared with real patent trolls, they behaved quite mildly -- many companies would have gone after end users, which Unisys explicitly did not do. -- Elphion (talk) 18:24, 11 March 2015 (UTC)

First off, many well-informed and reasonable people think that software patents are pernicious -- and also that the less such patents have to do with control of specific hardware machinery, and the closer they approach towards abstract pure mathematical algorithms, the more pernicious they are. Second, Unisys had nothing to do with defining or popularizing the GIF format, which created an unfortunate impression that they were swooping in to reap the profits after others had done most of the work. Third, the issue of retroactively closed-and-proprietary file formats has been a very sensitive one for on-line communities before the commercial Internet even existed (as I mentioned before). For all these reasons, Unisys needed to tread very carefully to be perceived as a good corporate citizen. It's true that Unisys made some soothing noises and generous-sounding pronouncements at the beginning, but with every abrupt change of policy and/or enforcement strategy they alienated more and more people, until at the end (when it seemed like they were flailing around to quickly extract the maximum amount of money by every and any method in the remaining few months before the patent expired) they had almost no friends left. If I rewrite the passage, I would remove all references to unmotivated malicious trolling, because I don't think that unmotivated malicious trolling played a significant role in events. No doubt there were some very angry people, but those people were angry for much the same reasons that many well-informed and perfectly reasonable people found themselves opposing Unisys... AnonMoos (talk) 18:39, 14 March 2015 (UTC)

I agree with much of what you say; but we are not arguing about the perniciousness of software patents. My point is simply that until the patent model changes, companies who are used to making their money through patented technology have a clear interest in protecting their patents -- and using them to make money. Unisys did not come from the world of the Web and Free Software, or even free file formats; at the time they were largely a proprietary mainframe manufacturer with little interest in the Web -- like many old companies they would have seen it primarily as an advertising medium. I'm sure the clash of business paradigms caught them completely off guard, and when they tried (as they thought reasonably) to enforce the patent once its use was brought to their attention, they had no idea how much negative publicity it would generate. As I said above, Unisys didn't handle the situation well, but the explosive reaction on the other side rather precluded an amiable compromise.

So, fine, omit the "malicious trolling" (but I would note that many of the people who objected to Unisys on quite reasonable grounds did so in very unreasonable language); but at the same time, in the interests of NPOV, avoid portraying Unisys as a villain. I am particularly struck by your sentence "Unisys needed to tread very carefully to be perceived as a good corporate citizen" -- that's the POV in a nutshell. Unisys simply didn't understand the issues, or indeed the new computing environment they were playing out in. They saw instead a rare opportunity to use their technology to get in on the Web business ("extracting money", if you like). That's not my POV, but neither is it a villainous one.

-- Elphion (talk) 20:52, 14 March 2015 (UTC)

Let me add: I think this Slashdot post from 1999 is a reasonable summary. I'm not sure what you're referring to as "flailing around", but I can report that a project I was working on in the early 2000s (toward the end of the patent period) had occasion to approach Unisys for a GIF license. As a commercial for-profit product, the project fell squarely in territory Unisys was requiring licenses for. We had some trouble getting their attention, but they offered terms that were not unreasonable. In the end we figured out how to avoid re-compressing the image data, so we didn't need a license after all. But the whole process was one we were entirely familiar with: we wanted to use patented technology for a commercial purpose, and expected to have to license it. -- Elphion (talk) 00:43, 15 March 2015 (UTC)

The Slashdot thing is dated almost four years before the United States LZW patent expired, and so does not reflect the final phase. What it does reflect is plenty of people not being happy that a significant part of the whole "ecosystem" of their non-commercial software and websites is dependent on Unisys's beneficence for its continued existence, and not necessarily feeling too confident about how long such beneficence will last, given the changes and inconsistencies which had already occurred. I don't have any ill-will towards the employee mentioned, but some angry e-mails were almost inevitable given the nature of community concerns and Unisys's complicated and shifting positions -- and for every vulgar e-mailer there was also a well-informed person who was reasonably opposed to the way that Unisys was doing things. AnonMoos (talk) 08:40, 18 March 2015 (UTC)

Needs a discussion of tools to block the infernal things

Since animated gifs can be painful and/or seizure-inducing, the article should discuss tools to block them and should discuss why most browsers enable them. 71.191.163.95 (talk) 23:00, 17 April 2015 (UTC)

Needs more than just technical content

This article seems highly technical. I came here looking for an overview of the historical and cultural story of the animated GIF... from the animated road-worker "under construction" sign GIFs of the late 90s, to the clips-from-movies-as-a-form-of-emoji that we see today, as well as cinemagraphs.... I think something of that cultural story about the usage of GIFs should be added... Or at least linked to if it exists elsewhere? It's pretty embarrassing that knowyourmeme does a better job of telling this story than Wikipedia does. Alexbowyer (talk) 12:31, 17 June 2015 (UTC)

Feel free to add content. I'm not embarrassed that we haven't copied the entire Web into WP :-) -- Elphion (talk) 18:46, 18 June 2015 (UTC)

ZGATEXTI5, ZGANPIMGI5 extensions

I noticed that your example of a true colour image (SmallFullColourGIF.gif) had some extensions that I have been unable to decipher. These are labelled ZGATEXTI5 and ZGANPIMGI5 but I think there are others out there. Does anyone have more information on them? LaserBilly (talk) 09:43, 24 September 2015 (UTC)

The spec only allows 8 characters for the app extension identifier, so these are, strictly speaking, "ZGATEXTI" and "ZGANPIMG" extensions. My guess is that they are related to some "ZGA" program or format; they probably contain information the program used to create the subsequent image blocks, so that the program can reconstruct the generating data. Most viewers (e.g., the browsers) will simply ignore these extensions. The NETSCAPE extension is the only one I know of with any significant support, though nothing prevents your random program from adding its own (which again, will be ignored by most viewers). -- Elphion (talk) 17:14, 24 September 2015 (UTC)

The image description page refers to Zoner GIF Animator 5, which you can Google. I haven't found any description of the extension blocks though. -- Elphion (talk) 18:50, 24 September 2015 (UTC)

Needs a respell

For example, JPEG: JAY-peg. Is it pronounced " JEH-if " or " GEH-if " ? (I don't know how the respell template works.) —User 000 name 04:30, 18 October 2015 (UTC)

 Done -- Elphion (talk) 21:58, 18 October 2015 (UTC)

GIF "revival"

I've moved here for discussion the following 2012-11-23 addition to the article by 80.101.72.96 (talk · contribs · WHOIS):

In 2013 the .gif format had a widespread revival on the internet. The format actually became something of a standard in online media, often replacing the usual YouTube-videolinks in articles with GIF's of the same, but shortend, actionmoments. Cause for the revival seems to be the availability of GIF's through Tumblr and because of the widespread difference in browsers/platforms at the time (and videolinks redirected people on mobile devices away from the original articles).

The immediate problem is the speculation and lack of any source. I also think 'revival' is not the right choice of words; GIF is still widely used on the Net. -- Elphion (talk) 20:47, 23 November 2013 (UTC)

Elphion -- Non-animated GIFs have been on a gently declining curve over the last 15 years, but animated GIFs have been undergoing a kind of retro hipster ironic revival in the past few years -- they're all over various trendy entertainment news etc. websites... AnonMoos (talk) 15:38, 10 March 2015 (UTC)

Yes, I know -- but there are still tons of static GIFs out there. The main reason their use is declining is the advent of ready-made PNG files stuffed with large numbers of icons. -- Elphion (talk) 18:39, 10 March 2015 (UTC)

If the retro hipster ironic embrace of animated GIFs (not totally different from the retro hipster ironic embrace of old 8-bit video games) is a real significant phenomenon (which it is, as far as I can tell), then there should probably be some mention of it somewhere on the article... AnonMoos (talk) 10:25, 11 March 2015 (UTC)

There's nothing "retro hipster ironic" going on here. There simply is no other accepted format for what GIF does. It isn't a revival so much as just a lot of people tuning into the Internet for the first time in their lives because of the widespread adoption of cell phones. Frankly it's a travesty that a new standard for GIF hasn't been proposed (like GIFo15?) to address the many shortcomings it has. It would at least be good if browsers would all promise to implement the GIF standard correctly for files that use a hypothetical new version in the header ready for the publishing of the standard. Not only is there no other standard there is nothing to indicate that there will be at any point in the future. GIF has a lot of gas, especially because of it's popular adoption (such as naming it word of the year) but it would die instantaneously if there was a replacement for it, it's practically "undead" as is, dead for 20yrs, never has a corpse had so much mileage. --184.63.132.236 (talk) 21:21, 23 October 2015 (UTC)

GIF with > 256 colours

The following webpage shows a > 256 colour GIF - it seems that GIFs have a limit of 256 colours per block, but a single GIF image can have many blocks. The article does not seem to take this into account

http://phil.ipal.org/tc.html —Preceding unsigned comment added by 87.127.209.199 (talk) 13:35, 26 March 2008 (UTC)

Yes it does: Graphics Interchange Format#True color. --Zundark (talk) 13:59, 26 March 2008 (UTC)

"The dithering process used to overcome the format's 256-color limitation makes the image appear coarse-grained." —Preceding unsigned comment added by 87.194.237.176 (talk) 20:39, 30 March 2008 (UTC)

I see your point; saying in that caption that there's a "256-color limitation" is somewhat inaccurate. We could say "256-color limitation for single-image/unanimated streams" or some such. —mjb (talk) 01:40, 31 March 2008 (UTC)

http://phil.ipal.org/tc.html shows a 32697-color GIF without dithering. I am going to fix the lead paragraph. --Guy Macon (talk) 06:11, 13 May 2013 (UTC)

Since, in practice, the format is almost NEVER used to support more than 256 colours, I think it is even more misleading to state otherwise. I have used this source, which was already used in the body of the article to explain truecolour gifs, more appropriately to explain why nobody actually does this, even though it is technically feasible. GDallimore (Talk) 09:37, 13 May 2013 (UTC)

Agree with GDallimore: GIF was designed to permit different palettes in one image, not to provide full-color functionality. GIF was developed to target the common graphic cards of the time, which were mostly restricted to 256 colors. The point of multiple palettes was not full-color, but compression: it allowed most of the canvas to be described in a restricted palette (< 8 bits), while small areas could be described with more color definition. Almost no editors in common use now support more than one palette, and the only GIFs I have seen using >256 colors are proof-of-concept examples. The article's discussion of "full-color" GIFs is the right way to handle this. -- Elphion (talk) 13:19, 13 May 2013 (UTC)

I have no problem with GDallimore's changes. The article is now better than it was before my edit, and it is better than it was after my edit. Good job. --Guy Macon (talk) 14:20, 13 May 2013 (UTC)

I don't understand what's wrong with saying that it usually only supports up to 256 colours - as that's what's found in almost all common implementations... but that it does also allow for an abitrary number of colours displayed from within a 24-bit colour space, by breaking the whole image up into a number of discrete blocks with their own local 256-colour palettes - as that is actually the truth. And an encyclopaedia should be a repository of truth, not a load of generally believed but actually incorrect folk "knowledge". (And yes, the fact that GIF does indeed allow an effectively unlimited colour palette, so long as software, hardware, and filesize constraints don't interfere, is news to me as well, but having had it demonstrated before my very eyes, I'm not about to summarily dismiss it just because it conflicts with everything I had assumed for the last 20+ years) 193.63.174.211 (talk) 12:18, 11 October 2013 (UTC)

• It seems to me like web browsers may've conspired to hobble the GIF. It's clearly designed to do "powerpoint" like presentations, but all web browsers have reduced it to the lowest common denominator of being treated as a series of images to be displayed in sequence with mandatory time-gaps between frames that appear nowhere in the standard. Clearly if a sub-image block does not begin at 0,0 it's unlikely that it's a series of images to be played back to back, but a diagram of some kind instead (which could also be used to take advantage of more than one group of colors.) Perhaps the guy that says it's pronounced like "JIF" is right, and GIF is really this unholy abomination with no official standard that we're now stuck with, more popular than ever--184.63.132.236 (talk) 21:38, 23 October 2015 (UTC)

Uncompressed GIFs

user:BenRG corrects a long-standing error in the description of uncompressed GIFs [5] (good catch). He also adds the observation that if the code width were allowed to increase to the full 12 bits, the overhead would approach 50%. But isn't it the case that the "uncompressed algorithm" has always assumed fix-width codes? [The following argument that predicting increases in code width requires maintaining a table is incorrect; see my further remarks after "The Rule of 2^n − 2" below]  To predict where the width would actually increase would require something very close to maintaining the encoding dictionary, which would defeat the whole purpose of uncompressed GIFs. (added:) well, no, I suppose you could maintain the decoding dictionary instead, which is not covered by the patent. But: The point was never to mimic the code growth (or to reduce the encoder overhead required to keep track of it), but to prevent the decoder from increasing the width. Given that, the 50% datum is sort of irrelevant. Added: Are there references showing schemes that actually attempted to mimic adjustments in code-width? -- Elphion (talk) 17:32, 20 May 2011 (UTC)

What source is there for the claim "To avoid the patent on LZW compression, some encoders ignore the dynamic LZW table entirely and emit only static LZW codes ? There has been no patent restriction on LZW for many years.
Here is other discussion of non-compressed GIF. Cuddlyable3 (talk) 21:48, 20 May 2011 (UTC)

The present tense is misleading, since, as you point out, there is no longer any need to avoid the patented features. But certainly uncompressed GIF was originally developed to get around the patent -- just read the notes to any of the uncompressed GIF libraries, e.g., [6] (LibUnGif for Windows). -- Elphion (talk) 00:31, 21 May 2011 (UTC)

Can anyone provide an example of a non-compressed GIF image for the article? Ideally it should be small enough for the code to be viewable but just large enough to need repetition of the clear code to work. Cuddlyable3 (talk) 13:50, 21 May 2011 (UTC)

Here's the 3 x 5 sample image, encoded as an uncompressed bi-level image (color table with two entries, symbol width n=2). The code width is n+1 = 3, and the rule is to insert a CLEAR code after every 2^n − 2 = 2 pixels.

Code
The following discussion has been closed. Please do not modify it.
The pixel values (0 = black, 1 = white), arranged in rows and columns: 0 1 1 1 0 1 1 1 1 1 1 1 1 1 1 The 3-bit binary codes, including initial CLEAR, interpolated CLEARs, and terminal STOP: 100 initial CLEAR 000 pixel 1 001 pixel 2 100 CLEAR 001 pixel 3 001 pixel 4 100 CLEAR 000 pixel 5 001 pixel 6 100 CLEAR 001 pixel 7 001 pixel 8 100 CLEAR 001 pixel 9 001 pixel 10 100 CLEAR 001 pixel 11 001 pixel 12 100 CLEAR 001 pixel 13 001 pixel 14 100 CLEAR 001 pixel 15 101 STOP Packed into nine 8-bit bytes, LSB-first: Binary Hex 0100 0100 44 1001 1000 98 0001 0000 10 0110 0001 61 1100 0010 C2 1000 0100 84 0000 1001 09 0001 0011 13 1010 0110 A6 And finally, assembled into a complete GIF file: byte# hexadecimal text or (hex) value Meaning 00: 47 49 46 38 39 61 GIF89a Header Logical Screen Descriptor 06: 03 00 3 - logical screen width in pixels 08: 05 00 5 - logical screen height in pixels 0A: 80 - GCT follows for 2 colors with resolution 3 x 1 bits/primary 0B: 00 0 - background color #0 0C: 00 - default pixel aspect ratio R G B Global Color Table 0D: 00 00 00 0 0 0 - color #0 black 10: FF FF FF 255 255 255 - color #1 white 13: 2C Image Descriptor 14: 00 00 00 00 (0,0) - NW corner position of image in canvas 18: 03 00 05 00 (3,5) - image width and height in pixels 1C: 00 - no local color table 1D: 02 2 LZW minimum code size 1E: 09 9 9 bytes of encoded image data follow 1F: 44 98 10 61 C2 84 09 13 A6 28: 00 - end 29: 3B GIF file terminator A regular, compressed GIF file in this bicolor format would save 5 bytes of image data.

-- Elphion (talk) 19:59, 21 May 2011 (UTC)

I boxed your code for readability. Cuddlyable3 (talk) 11:11, 22 May 2011 (UTC)

Now that the patent doesn't give a motive for making non-compressed gif, a remaining motive is to have easy random read and write of pixels. The 128-color version looks useful because each code fits a byte without repacking, so a read-mask-write cycle is not needed to paint a pixel. Elphion, can you post an explanation for inserting CLEAR code after every 2^n − 2 codes? Cuddlyable3 (talk) 11:11, 22 May 2011 (UTC)

(outdent)

Yes, symbol width 7 (code width 8) hits byte boundaries very nicely, and the formula giving byte offset from row and column, taking extra CLEAR codes into account, is straight-forward. For images with few colors one can also use symbol width 3 (8 colors, code width 4), which packs the codes in nybbles, but not quite as conveniently since the low-order nybble is filled first. In general, using a shorter code saves bytes, but the more frequent CLEAR codes eat up some of the savings. Here's the encoded data for the 3 x 5 in 4- and 8-bit codes for comparison; both easily readable, but the 8-bit codes clearly more convenient for easy access:

4-bit codes: 08 11 01 81 11 11 11 18 11 09

8-bit codes: 80 00 01 01 01 00 01 01 01 01 01 01 01 01 01 01 81

The Rule of 2^n − 2:   If the symbol width is n, the codes of width n+1 fall naturally into two blocks: the lower block of 2^n codes for coding single symbols, and the upper block of 2^n codes that will be used by the decoder for sequences of length greater than one. Of that upper block, the first two codes are already taken, 2^n for CLEAR and 2^n + 1 for STOP. We must also prevent the decoder from using the last code in the upper block, 2^(n+1) − 1, because when the decoder fills that slot, he will increase the code width. Thus in the upper block there are 2^n − 3 codes available to the decoder that won't trigger an increase in code width. Because the decoder is always one step behind in maintaining the table, he will not generate a table entry upon receiving the first code from the encoder, but will generate one for each succeeding code. Thus the encoder can generate 1 + 2^n − 3, or 2^n − 2, codes without triggering an increase in code width.

(And on reviewing this argument, I see that my argument above that the encoder needs to maintain a table to predict where the code-width changes occur is wrong. Beyond the first code the decoder always makes a table entry until the table is filled or cleared, so the code-width increases are easy to calculate. But the uncompressed coders I know of all use fixed-width codes, because allowing the code width to increase only decreases the efficiency of the uncompressed encoding.)

-- Elphion (talk) 16:07, 22 May 2011 (UTC)

The code table is only filled as fast as you describe in the case of all pixels having the same color index, but of course that possibility must be allowed. Long pixel data must be broken into blocks which complicates addressing. I think the block size can be arbitrary up to 255 bytes, but I have not managed to demonstrate this in practice. Cuddlyable3 (talk) 18:46, 22 May 2011 (UTC)

No, for uncompressed GIFs, the table always fills that fast. Until the table fills up, the LZW algorithm tells the decoder to add a code every time the encoder emits a code (after the first, and except for STOP and CLEAR), just as a standard encoder is also adding a code every time it emits a code (except STOP and CLEAR). That's how the encoder and decoder will agree on the values of the codes. That the encoder in this case is ignoring the values of the codes above STOP doesn't change the algorithm for the decoder. The decoder will in this case likely end up with a lot of codes decoding to the same string, but again, that doesn't change the algorithm -- and most decoders aren't structured even to be able to detect that.

(Stated differently: as a function of the input symbols, the growth of the standard LZW codes is hard to predict except by keeping track of the table. But as a function of the codes emitted, the growth is trivial to predict, and in uncompressed GIF, symbols = emitted codes, except for the CLEAR codes which reset everything.)

Yes the image data must be broken into sub-blocks. The obvious rule would be to use some multiple of 1 + (2^n − 2) codes that works out to a byte boundary such that the number of bytes is under 256, corresponding to (possibly multiple) chunks of CLEAR + data. E.g. 1 + 126 + 1 + 126 = 254 bytes for 8-bit codes (one CLEAR code for every 126 data bytes), or some multiple of 7 bytes (like 252) for 4-bit codes (since two CLEAR + data chunks fit in seven bytes).

-- Elphion (talk) 19:23, 22 May 2011 (UTC)

Yes. I have corrected my post by striking. Your reasoning agrees with mine but can you produce a gif that works this way? For example a 32x32 pattern with 128-color table? Cuddlyable3 (talk) 07:17, 23 May 2011 (UTC)

(outdent)

Here's a 46 x 46 uncompressed GIF with 7-bit symbols (128 colors, 8-bit codes). I put each raster in its own sub-block, with a CLEAR code at the beginning of each raster. Each raster sub-block thus has 48 bytes: length (47=2F) + CLEAR (80) + 46 bytes for 46 pixels. (This scheme has more CLEAR codes than necessary -- one for every 46 codes rather than the max of 126 -- but it makes the addressing simpler.) The STOP code is in its own 2-byte sub-block at the end (01 + 81), followed by the terminating null sub-block (00). The global color table has 128 entries.

-- Elphion (talk) 01:48, 24 May 2011 (UTC)

I added a hex listing to your image description page. Cuddlyable3 (talk) 08:46, 24 May 2011 (UTC)

Ooh, very neat! Shall I upload a 2nd version of the image with a 24-byte comment extension to pad the start of image data to a 48-byte boundary? -- Elphion (talk) 19:13, 24 May 2011 (UTC)

How about 72 bytes instead? (I couldn't say anything meaningful in only 24 − 4 bytes.) -- Elphion (talk) 19:45, 24 May 2011 (UTC)

The article doesn't explain comment extensions. Let's put your Quilt image in the article. Cuddlyable3 (talk) 20:23, 24 May 2011 (UTC)

What I meant was: I can upload the padded version that would align the image data in a listing, so that the image isn't split in the listing. But that makes sense only if you would be willing to re-do the listing too. The point is not to illustrate the comment extension -- we don't even have to mention it, although it would be visible in the listing. Or we could mention comment extensions in the article too -- I could go either way. -- Elphion (talk) 20:38, 24 May 2011 (UTC)

Understood. I think the present simple version is preferable. The faint visibility of the image in the code is only a chance curiosity of no particular use. We should open a new discussion if you think the gif comment extension is still notable. It is in the gif standard but I have never known it used. Cuddlyable3 (talk) 09:02, 25 May 2011 (UTC)

Fine with me -- Elphion (talk) 12:36, 25 May 2011 (UTC)

Done. Cuddlyable3 (talk) 15:31, 26 May 2011 (UTC)

• Sorry, but this is way outside the limits of what is appropriate for an encyclopedia. Not even a mention of such a scheme ever being used is appropriate--184.63.132.236 (talk) 21:44, 23 October 2015 (UTC)

Sorry, don't agree at all. It's an interesting historical phenomenon, and still useful for producing GIFs without implementing LZW. -- Elphion (talk) 22:25, 23 October 2015 (UTC)

Well unless you can find a notable source for why this is historically interesting, it would be removed anyway. Really it's arcane, and not even important. If this was done to circumvent LZW patents put it in the patent section. Otherwise it's meaningless. If you don't agree there's nothing anyone could say to convince you otherwise. This is obvious. Which is why I've quit Wikipedia so many times, because what edits survive just come down to who cares more about things no one should care about in the first place. --184.63.132.236 (talk) 03:57, 24 October 2015 (UTC)

You can find several references on the web. One in print is John Miano, Compressed Image File Formats: JPEG, PNG, GIF, XBM, BMP, Addison-Wesley. I could also add {{cn}} to your judgments that it's arcane and unimportant. Some people would say the same thing about GIF in general, and point out in addition that one problem with it is that you have to compress the data, which is a pain. But Uncompressed GIF gets around that. In the end I suppose the only things we all find important are death and taxes. -- Elphion (talk) 04:11, 24 October 2015 (UTC)

I may be inclined to GUT the MIDDLE of this article SOON

Extended discussion of an LZW implementation at rosettacode
The following discussion has been closed. Please do not modify it.
I'm working on a GIF encoder right now, and to me the middle of this article (from "6 Example GIF file" to "8 Interlacing") looks highly misleading. It looks like a hacker that didn't realize the specification is public tried to reverse engineer some GIFs and wrote the entire project up in a journal. Specifically the bulk of it looks like it's just trying to describe what LZW compression looks like when looked at in a hex editor; which needless to say has nothing to do with GIF and probably doesn't belong on the LZW article either. BMP_file_format has very nice tables. The GIF specification in the external links is very short, and is overlong in the document itself, it could be compressed down to a very small section, with a brief mention of the data chunks being LZW encoded, and that should be all. I won't raise a hand to wipe the article until I have a working encoder, so I can be absolutely certain of this position. In the meantime please comment, and please volunteer to make tables for GIF. They would be much smaller than the ones on the BMP article, but I'm not going to wrestle with tables in the article, or volunteer to translate the specification. I'm not a Wikipedian, but if GIF can be a word of the year, then this article can at least not be a train wreck, even if that means taking the ax to it--184.63.132.236 (talk) 19:41, 19 October 2015 (UTC) ALSO, the entire notion of "uncompressed" GIF looks dubious, and unworthy of mention. As near as I can tell it is LZW compressed, just maximally poorly so. In which case it doesn't warrant a technical explanation, although it could be a short paragraph if it was found that such GIFs circumvented the LZW patent, however it seems unlikely that they would, because they are still technically LZW compressed.--184.63.132.236 (talk) 19:45, 19 October 2015 (UTC) I think it would be a good idea to discuss proposed changes here before proceeding with them. Much of this material is here in answer to specific requests. It is also technically accurate. -- Elphion (talk) 20:26, 19 October 2015 (UTC) I think this sprawling middle section needs to go, somehow. Still I'm running into trouble with this encoder. It's clear that the data is encoded in a way that isn't as simple as just saying it's "LZW", because that doesn't appear to be a standard compression scheme, so much as a compression philosophy. The code at http://rosettacode.org/wiki/LZW_compression#C in the external links looks like it was developed for GIF-LZW (although it only implements 8-bit "color"; not less) yet still it appears to be inadequate for GIF encoding; either because the code has been edited, or never tested in the first place. So I do not believe it's a reliable link, both because most of the code on that page, not simply generated from the C code, implements LZW in a way that bears little resemblance to GIF (which uses variable length packing, and special stopcodes) and so it belongs on the LZW article, but probably not on the GIF one. There really should be a separate page on that website for GIF-LZW; and I don't know if I make that code work, if it would even be worth correcting. That said, there should be mention of how GIF encoding is by no means simply a strict LZW filter of some kind, yet at the same time, it seems like the differences could fit in a single paragraph, or half of a paragraph, and the example here are not particularly helpful, and the style seems like it is from the perspective of an outsider, who is not versed well enough to simply read the spec and implement it, which seems completely inappropriate for an encyclopedia (the spec is far more clear than a hex editor. And a layman should have nothing to do with a hex editor.) --184.63.132.236 (talk) 23:07, 20 October 2015 (UTC) I got that encoder working, and left a note on that rosettacode.org page from the comment above describing the necessary changes to it. What I can offer is to check any tables and descriptions for correctness, and I can be very fastidious about editing, I just don't have it in me to layout an entire section from scratch. I think most parties will agree that this middle section is overgrown and due for culling. IMO the article would be better with it removed than nothing. Which is why I'm happy to help with a replacement section that is clear, concise, and encyclopedic. --184.63.132.236 (talk) 04:14, 21 October 2015 (UTC) Yes; as you've discovered, there are many different ways to implement LZW -- different applications use different versions, and we do already point that out at LZW. The link to rosettacode (if we include it at all), as you say, belongs at LZW, not GIF -- and that's where it is. (I don't know offhand where the link came from; as a general rule we don't link to implementation websites unless they're fairly authoritative.) The comment you added at rosettacode is quite right: the version there is not the one used by GIF (though in fairness it doesn't claim to be). But I'll push back on two aspects of that comment: (1) GIF implements 2 to 8 bit color, not 1 to 8 bit. (The symbol size in the Image Descriptor must be at least 2 -- although if you only use colors 0 and 1, the color table need only have two entries.) (2) GIF is by no means the only place LZW is used. LZW (and LZ in general) was developed primarily for text compression, and is still widely used for that -- especially in embedded devices where minimal overhead is important. It's also still the most common compression in TIFF files -- which again uses a different version. It's partly because GIF uses a specialized version of LZW that the GIF examples were provided here, since the examples at LZW are not specific to GIF. I agree that the current formatting is not optimal. I don't agree that the material doesn't belong here. The GIF spec does not suffice in this regard since it doesn't cover the specifics of LZW. Welch's original article is not bad, but (a) it doesn't address GIF in particular, (b) it doesn't discuss variable length codes (one of the reasons that "early change" was implemented by mistake), and (c) it's hard to get hold of. In fact, outside of WP I know of no completely error-free discussion on the web. So there is some value here, and I'm wary of throwing out too much. [added:] That code at rosettacode is pret-ty fun-ky. E.g., indexing or incrementing a (void*) pointer ... especially when you're stuffing (size_t)-sized objects there ... -- Elphion (talk) 05:21, 21 October 2015 (UTC) Yes, the encoding can only go to a 2bit minimum, but it's not like GIF can do 9bit color, so it can do 1 to 8bit color, the distinction is not important. The bulk of this article should not be about the technical specifications. A table for the fields, and a note for the data field should suffice. Personally I think it would be useful to provide an implementation of the LZW codec in an initially collapsed box, or probably better if there was a wikicommons for such a thing, but describing the algorithm in detail with words is just beyond what is acceptable in an encyclopedia. Something like a mention of the clear/stop codes, how the LZW codes begin as small as possible (2bits) and increase up to 12bits, stopping there (for what rationale I don't know), and stipulating that GIFs are Little Endian encoded should suffice. This can fit into a note in a table. There are loads of tables on BMP and I think they're probably all warranted. GIF should require really only one or two, plus the Netscape and Graphic Control tables in the animation part of the article. If there are more tables they should be collapsed as it's unlikely anyone cares. I do think a programmer should be able to implement GIF just by reading this article, but also it should be easy for them to do so, by making it straightforward. I do not believe there are any void* or size_t types in the C implementation. Which is the only one that looks like GIF-LZW, other than the translations of it. Oh I see, you mean the memory management stuff. That's pretty standard for C. --184.63.132.236 (talk) 21:22, 21 October 2015 (UTC) If you're dealing with a C that understands size_t (and that code uses size_t in several places), you're dealing with a C that returns void* from calloc(). Older C's might return char*, which would naturally increment the pointer by a single byte; so x[0] = some size_t and x[1] = some other size_t will likely land you in trouble. The point is that the code does not appear to have been run through a caller for even simple error checking. OK, I see what it's doing. -- Elphion (talk) 21:36, 21 October 2015 (UTC) I've taken a closer look at the code at rosettacode.com. It's not awful, but could use some spiffing up. Unlike many of the language examples there, the C code makes the mistake of trying to combine the compression and the packing; most of the programs produce (or consume) an array of integer codes, and leave the packing details to a separate pass. You get a much more flexible package that way, since the details of delivering the bits (like the variable width packing, MSB vs LSB, and GIF's sub-block mechanism) have nothing to do with the LZW compression. But a flexible package does need to support a maximum code value (since many implementations require that), and many of the programs there simply assume that the code values have no limit. Still, it's an interesting collection of programs. Remarks specifically about the C implementation there (I doubt this came from a GIF codec, since it differs in so many points from the requirements of GIF): It assumes MSB packing. (GIF uses LSB.) This could be fixed to be configurable. It assumes a fixed symbol width of 8, despite parameterizing the values for clear code, stop code, and first compound code. (GIF uses widths 2 through 8.) This could be made configurable, but there are a lot of hard-coded numerical values that would have to be parameterized. It assumes variable width coding up to 16 bits wide. (GIF always uses 12 bit max.) The maximum code width is not handled particularly well. Ideally, the encoder and decoder should agree beforehand on a maximum width (i.e., on a maximum code value). This encoder can be configured to use anything between 9 and 15 (inclusive), whereas this decoder always assumes the maximum width is 16. This is not a problem PROVIDED the encoder always issues a clear code when the table fills, as this code assumes -- but LZW (and GIF in particular) does not require this. A minor point: if the table fills, the encoder issues the clear code at the next wider width, which is wider than its configured maximum. Since the maximum is <= 15, this is still <= 16, so the decoder can handle it; but this is sloppy coding. A better implementation would offload these details to a separate packing/unpacking process. As a result of these packing glitches, this encoder would have to be configured to use a max code width of 11 to generate legal GIF encoding (assuming MSB vs LSB were fixed), whereas a typical GIF encoder would use 12. This decoder would thus not be able to handle all legal GIF-encoded LZW (even for 8-bit symbols, and even if MSB vs LSB were fixed). The encoder and decoder appear to use "early change": the code triggering a change in code width is issued after the change in width rather than before it. (GIF does not use early change.) This (with several of the other details) suggests to me that the code came from an implementation for PDF. The encoder's method of detecting whether a string is in the table is simple and time efficient (and avoids hashing, which may avoid the Unisys patent -- though IANAL, and this is now a moot point). It requires a lot of space that ordinarily won't get used, and how this would stack up against a hashing scenario is not clear. It's interesting to look at the C++ version, which does use hashing: the code is much cleaner and far more intelligible, but there's a lot of magic going on under the hood! -- Elphion (talk) 02:01, 23 October 2015 (UTC) I put most of this in the Talk page there. It's certainly possible if PDF is similar to GIF that it came from elsewhere. Are the clear codes not supposed to use the current bit width? The specification seems a little unclear about the reset after the max is exceeded, it says to add a clear code, but not whether to use the max width or max+1 width. Anyway, it works for 9-12 widths. Not 11... I am a little bit angry about how web browsers have treated GIF. And angry that it's the only format that exists for looping images (that will not be initially blocked with a Play button.) The compression is not so bad. But if no one can agree on an alternative, there is plenty of room for extensions, unrelated to compression; why not establish some?! The ability to have more than one image on the logical canvas is completely disregarded by almost all viewers. It's clearly meant to allow sections of the canvas to be setup independently, like for a "powerpoint" presentation, but viewers/browsers treat any image as a time delayed animation. I wonder what the originators think about this. The graphic control block was clearly never intended for frame-by-frame animations. I've been using it to try to take screenshots of a unique 3D graphical technique. Here[7][8][9] are some examples. It's normal for a the last one to flash when it loops. I will probably add graphic-control blocks to the intraframe sub-image blocks, which may make a difference. The graphic control adds transparency, so it isn't simply there to insert a delay. Still I read browsers do not honor a 0 delay. It's madness, it's like there was a conspiracy to break GIFs. I think unless new life is breathed into it with extensions it's probably dead, with nothing to take its place. On a regular display the images in the screenshots do not feature aliasing, so they do not required "anti-aliasing". It doesn't work well in the GIFs either because they are too slow, or the framerate is irregular. But even with an approximately 30FPS (vs. 50FPS) delay they are clunky, whereas the effect is generally serviceable with a normal 3D viewer at 30FPS. Although at 60FPS it's virtually indistinguishable from a still image. Fortunately 3D really looks better with an ordered dither, so in regular mode with effects turned on, depending on how uniform colored the scene is, screenshots generally fit into a single 256 color image, otherwise this would not be possible with tiling unless a viewer allows it. --184.63.132.236 (talk) 09:23, 23 October 2015 (UTC) @Elphion; I've posted that encoder rewrite here[10]. I made it ultra-compact for my own needs. I am done here. I would lay waste to these sections and add proper tables to describe the specification, but I estimate the odds that you'll undo any changes I make to be around 90%, so I have better things to do. Ciao. --184.63.132.236 (talk) 11:18, 27 October 2015 (UTC)

Lossless?

This article, and the article on Lossless compression, say that GIF compression is lossless. Wouldn't that only be the case if the image contains 256 colors or less? How would one reconstruct the original colors of an image containing up to 16 million colors if given a GIF image? It seems that saving a colorful image as a single GIF does NOT provide enough information in the compressed file to determine the original colors. It seems that at best, someone trying to reconstruct a colorful image using only a GIF of it could attempt to estimate gradients present in the image to figure out how close each pixel is to its color on the reduced color palette, or try to figure out the original image characteristics by trying to reverse the process by which the GIF compression chose the reduced palette for the image. MathEconMajor (talk) 18:36, 25 October 2016 (UTC)

When reading the article it appears to me the compression method is lossless - but that by within sub-blocks an image is converted into a 256 colours palette before compressing. So the loss is more in the preprocessing (going to 256 colours) than the actual compression. Under true colours it is explained how a GIF file could deal with more than 256 colour -that is by specifying blocks consisting of 256 pixels and than define the palette for each pixel individually. I have never seen this used in practice (and doing so would probably result in inflation instead of compression of the original image). I hope I understood correctly as I am no expert on this. Arnoutf (talk) 18:58, 25 October 2016 (UTC)

GIF compression is lossless since it operates only on areas with a max of 256 colors. If the image you're trying to store as a GIF has more than 256 colors, then you have to break it up into sub-images of max 256 colors before hitting it with GIF compression. (16x16 squares work, but other possibilities exist.) But if you do that, the decompressed image will automatically have the same data as the original. Added: (If the image has more than 256 colors, GIF is not the obvious choice anyway: other lossless formats can handle more than 256 colors more conveniently.) -- Elphion (talk) 21:11, 25 October 2016 (UTC)

Pronunciation

The article seems to be contradicting itself in the pronunciation section, I'm not sure which is right so I'm just flagging it so to speak 67.234.78.0 (talk) 10:02, 2 June 2012 (UTC)

I don't see any contradiction. Both pronunciations are used; the soft G version ("Jif") was the original version used by the development team in deliberate reference to the peanut butter brand. Both versions are listed in dictionaries. What's the problem? -- Elphion (talk) 23:17, 2 June 2012 (UTC)

It's just flat out wrong. It's JIF, EoF. Anyone using GIF is a luddite and a fool. — Preceding unsigned comment added by 166.205.55.44 (talk) 22:12, 4 February 2013 (UTC)

Anyone else catch/find funny the fact that this person basically said "if you pronounce it like it's spelled, then you're a luddite"? or am I the only one? he/she used "GIF" as the text representation (of the pronunciation indicated to be incorrect), thus implying that however the reader reads those three letters (which would probably HAVE to be with a hard "g", as it is juxtaposed with and preceded by "JIF", -which is far less ambiguous- in that comment) is in fact incorrect... Brettpeirce (talk) 17:22, 2 November 2016 (UTC)

Yes "GIF" is ambiguous, especially since many Germanic words keep the hard G, even though the usual rule is soft G before E, I, and Y. The language gives no clear verdict one way or the other. That's why the pronunciation guide uses "ghif" to indicate the pronunciation of hard G. It's not perfect, but there's no unambiguous alternative in this situation. -- Elphion (talk) 18:04, 2 November 2016 (UTC)

Both the American Heritage Dictionary and the Oxford English Dictionary rate fairly high as Reliable Sources, and both give both pronunciations. You're entitled to your opinion, of course, but it remains POV. -- Elphion (talk) 01:28, 5 February 2013 (UTC)

The creator, the individual who gave the invention a name, trumps all third-party sources. Otherwise, there would be no purpose for naming rights. We do not consider "Leego" a valid pronunciation either, even though it would be grammatically correct. RvLeshrac (talk) 12:25, 22 May 2013 (UTC)

The creator may be an authority on graphic file formats, but he is obviously not an authority on pronounciation. His opinion trumps nothing. El Mariachi (talk) 22:53, 5 November 2013 (UTC)

GIF has moved way out of the realm of brand names, like kleenex or aspirin. If common folk commonly use the G sound and dictionaries say it's alright, that's English for you. Like the chief editor at Oxford says to the BBC, same goes for "quark", which was intended as "quork". That's a reliable source (or two) saying the creator does not trump anyone. InedibleHulk (talk) 17:26, 22 May 2013 (UTC)

WP is not in the business of prescribing pronunciation. We can report that Wilhite deliberately chose the soft 'g' for the original pronunciation, we can report that there is wide-spread disagreement over the "correct" pronunciation, we can even report that the White House sets a standard for its staff (it does not have the authority to promulgate an "official" pronunciation for the rest of us). But we cannot try to adjudicate this tempest in a teapot -- WP:NPOV dictates clearly that we must acknowledge that both pronunciations are widely used, and that both are sanctioned by authoritative dictionaries. (The dictionaries are not erroneous, despite what Wilhite says; they are simply reporting usage.) The referenced blog entry claiming that "most" techies use the hard 'g' offers no more than anecdotal evidence ("everyone I know . . ."). This is the height of POV and should not be accepted here. -- Elphion (talk) 13:23, 22 May 2013 (UTC)

The only mistake would be to remove one pronunciation or promote one over the other. Both are used, both have their own history, this article mentons that without taking sides. GDallimore (Talk) 15:17, 22 May 2013 (UTC)

According to recent revisions, we can't report that the sole official pronunciation is the soft 'g' -- because that is apparently "not constructive." The 'hard-g 'is an unofficial pronunciation, and is thus trivia -- it is utterly irrelevant to the official pronunciation as desired and stated by the inventors. The "hard-g" pronunciation was certainly never used by anyone I encountered while CompuServe was still running, and is the equivalent of deciding that because some people mispronounce "Lego," we should accept all pronunciations as valid. RvLeshrac (talk) 19:22, 23 May 2013 (UTC)

It appears that you have a conflict of interests due to your history with compuserve and should therefore avoid editing this article. Please make sure that edits are made on the basis of reliable sources, which undisputedly support the idea that both pronunciations are in common usage whatever the desires of the creators, and not your own personal interests. Thank you. GDallimore (Talk) 20:00, 23 May 2013 (UTC)

My take on all this is that the original authors were just a little bit crazed after one too many nights on the Jolt Cola and maybe shouldn't be listened to so seriously, especially as the reasoning behind it is one of a really bad joke that arose out of a near-but-not-quite coincidence spotted by someone who didn't realise that puns work just as well if not better when they slightly alter a well worn phrase rather than copying it direct. "Graphic" is not pronounced as Jraffic. If the acronym was Giraffe Image Format, that would make sense at least. Also, although it's not anywhere as commonly used, there is an actual JIF format (it's part of the JPG standard, which was dreamt up at about the same time and totally independently). Just to be certain, it would probably be clearest to save the "soft G" sound for THAT... Besides, in language, what's considered correct is usually the majority view, and the only person I ever heard say "JIF" like that was taking the mickey.

PS, "teach the controversy!" ;) ... as basically everyone except the coders and a few hardline pedants say it as they see it (hard G), not having been told how to pronounce it or its history and thus using regular English rules (admit it - if no-one told you that Gin was soft-G, you'd say it the other way)... there needs to be the note that it's commonly "mis"pronounced despite the official proclamation, for the purposes of clearing up potential confusion if nothing else. Say in 50 years time someone uses a surviving copy of this to interpret a similarly old video about early C21 web culture and can't figure out why everyone's saying Guh-Iff on there when this page clearly says it's to be pronounced Je-Iff... 193.63.174.211 (talk) 12:01, 11 October 2013 (UTC)

I don't know what went on in the Compuserve development tank, but it's clear that they did pronounce the acronym with a soft G ("JIF"). I don't know how "most" people would pronounce "gin" upon first encountering it, but I would have used the standard rule (soft G before E and I) and said "jin", on analogy with gem. I don't know which pronunciation of GIF is more widespread, or how it breaks down across geographical or professional lines; in my experience "JIF" is the clear winner. Acronyms acquire their own pronunciation; their letters don't always reflect the pronunciation of the corresponding letters in the abbreviated phrase (consider the U in FUBAR). The point is that we have resources (dictionaries) who investigate how the world pronounces things, and in this case, both British and American dictionaries report that both pronunciations are used -- and that's what the article reports. The article is completely agnostic about which is "correct". (And "correctness" -- however defined -- is often not the majority usage: Received Pronunciation, e.g., is used by only a small proportion of the British population.) -- Elphion (talk) 15:53, 11 October 2013 (UTC)

I was a member of the Compuserve Graphics Forum at the time the GIF format was being developed. Despite Steve Wilhite's preference/advocacy, It was documented within the forum, and well-understood by developers at the time, that it was pronounced with a hard G, as in Graphics Interchange Format, not a soft g, as in Jraphics.

Grafman (talk) 20:30, 14 March 2016 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on GIF. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20070207110047/http://lpf.ai.mit.edu/Patents/Gif/unisys.html to http://lpf.ai.mit.edu/Patents/Gif/unisys.html

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

Y An editor has reviewed this edit and fixed any errors that were found.

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 14:27, 9 October 2017 (UTC)

Actual format?

There's no actual information in the article about how the format actually works. I mean it says it's 8bit and that there can be frames but I would like to know what a GIF file actually has in it byte by byte. The link oto the spec has the info but that's more detail than I need. Wikivek (talk) 19:03, 29 March 2008 (UTC)

" ... what a GIF file actually has in it byte by byte." Sounds like the spec to me. If we were to rehash the spec here, how can we be expected to predict how much detail you need? There's a link to the spec, and that's absolutely the right solution. Elphion (talk) 16:56, 11 November 2009 (UTC)

Programming question moved to User talk:Vmelkon -- Elphion (talk) 18:30, 10 February 2018 (UTC)

the meaning of "GIF" has broadened

i don't know where to add this (the disambig? lone sentence in the lead?) but in contemporary usage (2018) the term "gif" now refers to a short, looping video or animation, no matter what format this in. Twitter prominently displays a [GIF] box over these small looping videos, even though there are mostly mp4. to be clear, i don't care about the technical side (so perhaps this page, actually about the technical file, is wrong?) but the linguistic side. We use "GIF" nowadays to mean something that is NOT "Graphics Interchange Format", even though the usage derives from here. 2A02:8109:9A80:6F6C:3006:3246:A00A:BBD2 (talk) 23:08, 23 July 2018 (UTC)

Wikipedia is not a dictionary, and definitely not Urban Dictionary. —DIYeditor (talk) 01:47, 24 July 2018 (UTC)

Removing the "GIFs with sound" section

I see no point in a section whose purpose is simply to restate that GIFs do not have sound, so I removed it. Do let me know if anyone objects. HamartiaProsciuttoPharos (talk) 22:21, 16 February 2020 (UTC)

Proposed merge with Video alternative to GIF

Video alternative to GIF does not currently merit a whole separate article. Ethanpet113 (talk) 01:49, 13 January 2019 (UTC)

Support/Merge I was actually searched GIF, but I was really looking for the stub article Video alternative to GIF. ―Matthew J. Long -Talk-^☖ 04:54, 17 January 2019 (UTC)

Support I'm kinda split on this one. I agree that a stub doesn't really work for Video alternative to GIF, but not really sure how it would be included in the article. I originally was going to stay neutral, however, the more I think about it when writing this reply, the more I support this merger. GeekInParadise (talk) 17:53, 26 March 2019 (UTC)

User Since video is an alternative to all image-based animation formats like APNG, animated WebP and others, I actually think that it would be better to rename the article to Video alternative to animated images and link to it from GIF, APNG and wherever else needed. --Fernando Trebien (talk) 20:22, 24 June 2019 (UTC)

User For the reason that the article on Video alternative to GIF, in its current state, is short, I would suggest either merging the two articles and having the Video alternative to GIF page redirect to GIF; adding a very brief introduction on video alternatives to Graphics Interchange Format (under which, "see full article here" would link to the full page); or mentioning alternatives to the format in the See Also section. Among those three options, I would personally go with the introduction with the "see full article here" under the heading. ~Osvaldo Jørgensen Talk-Page 01:24, 12 February 2020 (UTC)

Support the original proposal as stated; no need for a stand-along stub given that GIF can accommodate it. Having a brief summary remain at Video alternative to GIF is inefficient, as it duplicaties the first sentence or two on the target page section. An appropriate section would be to create a new section within GIF#Animated GIF, which could then also incorporate the brief GIF#GIFs with sound single sentence. Klbrain (talk) 13:51, 12 February 2020 (UTC)

Comment Suggest deleting "GIF with Sound" section (which is misleading: there are no GIFs with sound), incorporating that material and Video alternative to GIF in a new subsection "Video alternatives" under "Alternatives to GIF". -- Elphion (talk) 18:05, 12 February 2020 (UTC)

  Y Merger complete. Klbrain (talk) 13:48, 10 April 2020 (UTC)

Dictionaries, years of the editions?

In: GIF#Pronunciation_of_GIF / second paragraph there are mentioned a lot of dictionaries.
I would appreciate, if:

1. at each dictionary there would be mentioned the year and
2. if the dictionaries would be sorted by year.
   

This way one could see, whether there has been a kind of developement and who might have been following whom.
Please ping me. Steue (talk) 09:00, 28 October 2020 (UTC)

@Steue — This would be overkill, bordering on WP:OR. The dictionary references serve to show that both pronunciations are current, and that's what matters. If you have a WP:RS tracing the evolution of the usage, that would be an appropriate addition. But it is not our job to dictate (or even to suggest) "correct" usage. -- Elphion (talk) 14:58, 28 October 2020 (UTC)

@Elphion, it seems that you misinterpreted my intention. I do not intend to dictate or suggest anything. My intention is to find out whether there was a developement of some kind or not, and to get this made visible easily. And in case there was, it may be interesting to someone else als well.

If you, personally, are satisfied with what there is in this article, that is your decision; and I do not intend to evaluate or invalidate this. But you have no right to force your limitation onto all the other readers and to barr more information.

Please ping me. Steue (talk) 02:19, 30 October 2020 (UTC)

No change in my response: a reliable source for this would be fair game. -- Elphion (talk) 03:31, 30 October 2020 (UTC)

Section "History" / first paragraph: wrong word?

@ Metaeducation
In: GIF#History / first paragraph, the second sentence read:
{I have bolded the questionable word in the second part of the following sentence.}
GIF became popular because it used LZW data compression, which was more efficient than the run-length encoding that formats such as those used by PCX and MacPaint, and fairly large images could therefore be downloaded in a reasonably short time, even with very slow modems.
I "stumbled" over this "that". Could it be, that it should have become "and"?
Because the sentence was much too long to be easily understood, anyway, I restructured and reworded the whole paragraph, in order to describe the things in chronologic sequence, without changing any information; at least this was my intention. But after having restructured it and compared it to the original I still wonder whether I have put all the information from the original correct, especially, because I still wonder about this "that.".
Please ping me. Steue (talk) 07:21, 28 October 2020 (UTC)

@Steue I agree that the "that" makes the sentence hard to read, so I simplified that sentence. Your chronological rewrite, however, obscures the important point: the earlier wording has the right elements in the right order. -- Elphion (talk) 14:53, 28 October 2020 (UTC)

@Elphion: Thank you for clarification. At least now the content is clear and understandable.

However, now the words are no longer links, as they were before.

I, personally, prefer to put facts as chronologic as possible and in short sentences, because this makes everything easier to grasp, especially for all the many readers for whom English is not their mothertongue.

Just to understand why you answered although I wrote to U:Metaeducation, and, of course, only if you would like to disclose this: Are you the author of this paragraph and are using a different username or is it, that you know the facts good enough to tell how the sentence has to be?

Please ping me. Steue (talk) 03:08, 30 October 2020 (UTC)

I responded because I watch this page and you pointed out a passage that needs clarification. -- Elphion (talk) 03:33, 30 October 2020 (UTC)