Talk:Graphics Interchange Format/Archive 1

From Wikipedia, the free encyclopedia

Archived 27 February 2007

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Contents 1 transparency 2 article structure - pronunciation 3 patent issues 4 How to say Gif 5 Image? 6 BMP? 7 Browser support 8 GIF can have more than 256 colors 9 Image 10 truecolor vs truecolour 11 indexed color 12 speed 13 This article didn't answer my question in a way that I could understand 14 color or colour? 15 Perceptive, Adaptive, and Selective 16 Feb 2006 has passed, and IE7 is coming 17 Possible plagiarism on another site? 18 Only Animation Format? 19 True colour renders fine in MSIE & Firefox 20 2 images removed 21 GIF is a 24-bit RGB bitmap image format ???? It's not I think. 22 IBM Patent 23 Honorable mention? 24 Size of rotating globe image 25 Editing GIF

transparency

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

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

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

article structure - pronunciation

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

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

patent issues

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

How to say Gif

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Image?

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

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

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

BMP?

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

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

Browser support

The article states:

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

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

GIF can have more than 256 colors

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

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

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

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

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

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

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

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

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

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

as i see it thier are two possibilities

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Image

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

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

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

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

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

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

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

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

truecolor vs truecolour

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

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

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

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

indexed color

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

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

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

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

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

speed

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

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

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

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

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

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

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

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

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

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

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

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

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

Jrbrunger 08:50, 26 February 2006 (UTC)

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

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

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

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

color or colour?

make up your mind.

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

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

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

Perceptive, Adaptive, and Selective

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

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

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

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

Feb 2006 has passed, and IE7 is coming

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

Possible plagiarism on another site?

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

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

Only Animation Format?

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

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

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

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

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

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

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

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

True colour renders fine in MSIE & Firefox

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

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

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

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

2 images removed

Removed the following -

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

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

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

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

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

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

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

IBM Patent

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

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

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

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

Honorable mention?

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

Size of rotating globe image

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

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

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

Editing GIF

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

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

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

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