Talk:GIF

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)

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)

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)

PIG

This article should include the additions currently, i.e. after the rejection of APNG, under discussion to embed PNG in GIF, called PNG-in-GIF (PIG) and RGBA-in-GIF, whether they are accepted in the end or not.

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)

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)

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)

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)

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)

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)

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)

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)

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)

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 [1]. Cuddlyable3 (talk) 09:13, 12 November 2010 (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)

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)

Uncompressed GIFs

user:BenRG corrects a long-standing error in the description of uncompressed GIFs [2] (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., [3] (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)

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)

"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)

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)

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, May 22, 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)

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)

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)

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)

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)

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)

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)

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)

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

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[4][5][6] 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)