Talk:Graphics Interchange Format

From Wikipedia, the free encyclopedia
Jump to: navigation, search
          This article is of interest to the following WikiProjects:
WikiProject Internet (Rated B-class, High-importance)
WikiProject icon This article is within the scope of WikiProject Internet, a collaborative effort to improve the coverage of the internet on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
B-Class article B  This article has been rated as B-Class on the project's quality scale.
 High  This article has been rated as High-importance on the project's importance scale.
 
WikiProject Computing (Rated B-class, High-importance)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
B-Class article B  This article has been rated as B-Class on the project's quality scale.
 High  This article has been rated as High-importance on the project's importance scale.
 
WikiProject Animation / Computer (Rated B-class, High-importance)
WikiProject icon This article is within the scope of WikiProject Animation, a collaborative effort to build an encyclopedic guide to animation on Wikipedia. If you would like to participate, you can edit the article attached to this page, help out with the open tasks, or contribute to the discussion.
B-Class article B  This article has been rated as B-Class on the project's quality scale.
Checklist icon
 High  This article has been rated as High-importance on the project's importance scale.
 
Taskforce icon
This article is supported by the Computer animation work group (marked as Top-importance).
 

User:Motter[edit]

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 (talkcontribs) 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:
  • 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[edit]

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 (talkcontribs)

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[edit]

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[edit]

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[edit]

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?[edit]

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[edit]

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

Animated GIFs[edit]

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.[edit]

Image:Timer_By_Two_Hundredths.gif

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[edit]

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[edit]

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?[edit]

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[edit]

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[edit]

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[edit]

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[edit]

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 (talkcontribs) 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[edit]

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[edit]

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?[edit]

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[edit]

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[edit]

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[edit]

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.
-- 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.

Quilt design as 46x46 uncompressed GIF.gif

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

No Interlacing Information[edit]

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[edit]

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."[edit]

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[edit]

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[edit]

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[edit]

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[edit]

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)

Page Protection[edit]

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?[edit]

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"[edit]

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)

WebP format[edit]

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[edit]

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)