![]() | 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. |
Archive 1 |
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.
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.
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)
A Unisys page doesn't mention this http://www.unisys.com/about__unisys/lzw/ but the page is not specifically addressing free software.
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...
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)
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)
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.
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 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)
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)
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
"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).
The article states:
I thought IE was the only one that had "issues". What are the others? -- Yath 22:24, 4 Apr 2005 (UTC)
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)
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)
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:
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)
Screeny >> http://img291.imageshack.us/img291/5835/picox6.jpg -- XIIICats 11:50, 3 August 2006 (UTC)
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)
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/?title=Image:Mustang-ani-t.gif&diff=prev&oldid=82392086
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 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)
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)
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)
make up your mind.
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)
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!
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)
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).
<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
"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)
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)
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)
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?
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.
How would I be able to edit a gif? Can I use Microsoft Paint? -- 66.218.23.154 02:48, 15 January 2007 (UTC)
User:Motter ( contribs) insists on adding links to to this article that lead to his website, at least according to his talk page, quoted below:
like 5 months ago somebody put a link to my free gif making site on the wiki gif page. I didn't put it up there but it has been removed by some person that thinks they are the almighty ruler of wikipedia. I don't really care how cool you are with wiki lingo or how often you check an article that doesn't interest you in the least the better the "community". What I do care about however is offering a totally free service to the users of wikipedia that are searching the internet to find a way to create gifs. leave the link alone Ub3|2N3|2d!
His reasons for including the link therefore appear to fall directly into Wikipedia:External_links#Links_normally_to_be_avoided. I and several other editors have remove the link and warned him that it is spam. His responses have included deleting other links from the article and consistently adding his link back claiming that it improves the article or stating that he was fixing it.
User:Motter has been invited to discuss his concerns on this talk page. GDallimore ( Talk) 10:44, 27 February 2007 (UTC)
gifninja is a free .gif site that offers tools and over 50,000 free animated .gifs and rising. You just aren't going to convince me that the site isn't relevant.
As for the site being affiliated to me. I wasn't the person to list the site originally. When you came along and removed it cause you felt like it, I repaired your vandalism and intend to continue to do so.
—The preceding unsigned comment was added by Motter ( talk • contribs) 00:31, 28 February 2007 (UTC).
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.
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)
⟨⟩
The animations in this article do not seem to work in Firefox: GIF Animation on the WWW - technical explanation of the GIF89a format and how it allows animation —Preceding unsigned comment added by Bitbut ( talk • contribs)
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)
How exactly can one create a animated GIF from scratch? And which tools? Anwar ( talk) 20:35, 9 May 2008 (UTC)
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)
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)
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)
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)
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 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)
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)
There are 21 bytes in example, changed. —Preceding unsigned comment added by 77.37.142.221 ( talk) 19:19, 26 April 2009 (UTC)
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)
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)
Years ago I remember GIF files that contained a number of images and also text. It had very primitive programming language like:
text "Hello world" picture 1, 10 fade text "Next one" picture 3, 30 blink text "finish" loop
I know this because you could view the program and change it using a hex editor. Consequently, it was easy to change the adventures of "Mandy" to whoever you wanted to impress.
I have not seen any documentation of this anywhere. Does anybody have any examples of this? I don't mean the adventures of Mandy, as I am sure that by todays standards it would be somewhat grainy. However an example of any GIF using the inbuilt text format would be nice. It must have been 89a as it supported multiple animated images in a single file. —Preceding unsigned comment added by Puzbie ( talk • contribs) 16:27, 19 July 2009 (UTC)
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)
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)
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 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)
'!'
, 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.(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)
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 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)
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)
Officially? Dictionaries don't make langugages; speakers do. 80.103.84.224 ( talk) 10:39, 19 March 2013 (UTC)
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'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)
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)
It would be nice if the article answered that. -- TiagoTiago ( talk) 03:15, 23 May 2013 (UTC)
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)
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)
How do you cite the fact that sprites in games are stored as GIF files? 12Me21 ( talk) 22:11, 20 January 2015 (UTC)
The current wording makes it seem like the company was a passive innocent victim, but that's really not the case -- in fact, it changed its stated policies and enforcement strategies several times over the years, and during the last year or two before the U.S. patent expired, it seemed to be flailing around and trying to extract a little more blood out of the turnip by any possible method. The issue of retroactively closed/proprietary file formats has been a very sensitive one for on-line communities ever since the ARC wars of the late 1980s (before there even was a commercial consumer Internet). AnonMoos ( talk) 15:45, 10 March 2015 (UTC)
Since animated gifs can be painful and/or seizure-inducing, the article should discuss tools to block them and should discuss why most browsers enable them. 71.191.163.95 ( talk) 23:00, 17 April 2015 (UTC)
This article seems highly technical. I came here looking for an overview of the historical and cultural story of the animated GIF... from the animated road-worker "under construction" sign GIFs of the late 90s, to the clips-from-movies-as-a-form-of-emoji that we see today, as well as cinemagraphs.... I think something of that cultural story about the usage of GIFs should be added... Or at least linked to if it exists elsewhere? It's pretty embarrassing that knowyourmeme does a better job of telling this story than Wikipedia does. Alexbowyer ( talk) 12:31, 17 June 2015 (UTC)
I noticed that your example of a true colour image (SmallFullColourGIF.gif) had some extensions that I have been unable to decipher. These are labelled ZGATEXTI5 and ZGANPIMGI5 but I think there are others out there. Does anyone have more information on them? LaserBilly ( talk) 09:43, 24 September 2015 (UTC)
For example, JPEG: JAY-peg. Is it pronounced " JEH-if " or " GEH-if " ? (I don't know how the respell template works.) —User 0 0 0 name 04:30, 18 October 2015 (UTC)
Done --
Elphion (
talk)
21:58, 18 October 2015 (UTC)
I've moved here for discussion the following 2012-11-23 addition to the article by 80.101.72.96 ( talk · contribs · WHOIS):
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)
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)
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)
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)
user:BenRG corrects a long-standing error in the description of uncompressed GIFs [5] (good catch). He also adds the observation that if the code width were allowed to increase to the full 12 bits, the overhead would approach 50%. But isn't it the case that the "uncompressed algorithm" has always assumed fix-width codes? [The following argument that predicting increases in code width requires maintaining a table is incorrect; see my further remarks after "The Rule of 2^n − 2" below] To predict where the width would actually increase would require something very close to maintaining the encoding dictionary, which would defeat the whole purpose of uncompressed GIFs. (added:) well, no, I suppose you could maintain the decoding dictionary instead, which is not covered by the patent. But: The point was never to mimic the code growth (or to reduce the encoder overhead required to keep track of it), but to prevent the decoder from increasing the width. Given that, the 50% datum is sort of irrelevant. Added: Are there references showing schemes that actually attempted to mimic adjustments in code-width? -- Elphion ( talk) 17:32, 20 May 2011 (UTC)
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)
Code |
---|
The following discussion has been closed. Please do not modify it. |
0 1 1 1 0 1 1 1 1 1 1 1 1 1 1
100 initial CLEAR 000 pixel 1 001 pixel 2 100 CLEAR 001 pixel 3 001 pixel 4 100 CLEAR 000 pixel 5 001 pixel 6 100 CLEAR 001 pixel 7 001 pixel 8 100 CLEAR 001 pixel 9 001 pixel 10 100 CLEAR 001 pixel 11 001 pixel 12 100 CLEAR 001 pixel 13 001 pixel 14 100 CLEAR 001 pixel 15 101 STOP
Binary Hex 0100 0100 44 1001 1000 98 0001 0000 10 0110 0001 61 1100 0010 C2 1000 0100 84 0000 1001 09 0001 0011 13 1010 0110 A6
byte# hexadecimal text or (hex) value Meaning 00: 47 49 46 38 39 61 GIF89a Header Logical Screen Descriptor 06: 03 00 3 - logical screen width in pixels 08: 05 00 5 - logical screen height in pixels 0A: 80 - GCT follows for 2 colors with resolution 3 x 1 bits/primary 0B: 00 0 - background color #0 0C: 00 - default pixel aspect ratio R G B Global Color Table 0D: 00 00 00 0 0 0 - color #0 black 10: FF FF FF 255 255 255 - color #1 white 13: 2C Image Descriptor 14: 00 00 00 00 (0,0) - NW corner position of image in canvas 18: 03 00 05 00 (3,5) - image width and height in pixels 1C: 00 - no local color table 1D: 02 2 LZW minimum code size 1E: 09 9 9 bytes of encoded image data follow 1F: 44 98 10 61 C2 84 09 13 A6 28: 00 - end 29: 3B GIF file terminator
|
(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)
(outdent)
Here's a 46 x 46 uncompressed GIF with 7-bit symbols (128 colors, 8-bit codes). I put each raster in its own sub-block, with a CLEAR code at the beginning of each raster. Each raster sub-block thus has 48 bytes: length (47=2F) + CLEAR (80) + 46 bytes for 46 pixels. (This scheme has more CLEAR codes than necessary -- one for every 46 codes rather than the max of 126 -- but it makes the addressing simpler.) The STOP code is in its own 2-byte sub-block at the end (01 + 81), followed by the terminating null sub-block (00). The global color table has 128 entries.
-- Elphion ( talk) 01:48, 24 May 2011 (UTC)
Sorry, don't agree at all. It's an interesting historical phenomenon, and still useful for producing GIFs without implementing LZW. -- Elphion ( talk) 22:25, 23 October 2015 (UTC)
Extended discussion of an LZW implementation at rosettacode |
---|
The following discussion has been closed. Please do not modify it. |
I'm working on a GIF encoder right now, and to me the middle of this article (from "6 Example GIF file" to "8 Interlacing") looks highly misleading. It looks like a hacker that didn't realize the specification is public tried to reverse engineer some GIFs and wrote the entire project up in a journal. Specifically the bulk of it looks like it's just trying to describe what LZW compression looks like when looked at in a hex editor; which needless to say has nothing to do with GIF and probably doesn't belong on the LZW article either. BMP_file_format has very nice tables. The GIF specification in the external links is very short, and is overlong in the document itself, it could be compressed down to a very small section, with a brief mention of the data chunks being LZW encoded, and that should be all. I won't raise a hand to wipe the article until I have a working encoder, so I can be absolutely certain of this position. In the meantime please comment, and please volunteer to make tables for GIF. They would be much smaller than the ones on the BMP article, but I'm not going to wrestle with tables in the article, or volunteer to translate the specification. I'm not a Wikipedian, but if GIF can be a word of the year, then this article can at least not be a train wreck, even if that means taking the ax to it-- 184.63.132.236 ( talk) 19:41, 19 October 2015 (UTC) ALSO, the entire notion of "uncompressed" GIF looks dubious, and unworthy of mention. As near as I can tell it is LZW compressed, just maximally poorly so. In which case it doesn't warrant a technical explanation, although it could be a short paragraph if it was found that such GIFs circumvented the LZW patent, however it seems unlikely that they would, because they are still technically LZW compressed.-- 184.63.132.236 ( talk) 19:45, 19 October 2015 (UTC)
Yes; as you've discovered, there are many different ways to implement LZW -- different applications use different versions, and we do already point that out at LZW. The link to rosettacode (if we include it at all), as you say, belongs at LZW, not GIF -- and that's where it is. (I don't know offhand where the link came from; as a general rule we don't link to implementation websites unless they're fairly authoritative.) The comment you added at rosettacode is quite right: the version there is not the one used by GIF (though in fairness it doesn't claim to be). But I'll push back on two aspects of that comment: (1) GIF implements 2 to 8 bit color, not 1 to 8 bit. (The symbol size in the Image Descriptor must be at least 2 -- although if you only use colors 0 and 1, the color table need only have two entries.) (2) GIF is by no means the only place LZW is used. LZW (and LZ in general) was developed primarily for text compression, and is still widely used for that -- especially in embedded devices where minimal overhead is important. It's also still the most common compression in TIFF files -- which again uses a different version. It's partly because GIF uses a specialized version of LZW that the GIF examples were provided here, since the examples at LZW are not specific to GIF. I agree that the current formatting is not optimal. I don't agree that the material doesn't belong here. The GIF spec does not suffice in this regard since it doesn't cover the specifics of LZW. Welch's original article is not bad, but (a) it doesn't address GIF in particular, (b) it doesn't discuss variable length codes (one of the reasons that "early change" was implemented by mistake), and (c) it's hard to get hold of. In fact, outside of WP I know of no completely error-free discussion on the web. So there is some value here, and I'm wary of throwing out too much. [added:] That code at rosettacode is pret-ty fun-ky. E.g., indexing or incrementing a (void*) pointer ... especially when you're stuffing (size_t)-sized objects there ... -- Elphion ( talk) 05:21, 21 October 2015 (UTC)
I've taken a closer look at the code at rosettacode.com. It's not awful, but could use some spiffing up. Unlike many of the language examples there, the C code makes the mistake of trying to combine the compression and the packing; most of the programs produce (or consume) an array of integer codes, and leave the packing details to a separate pass. You get a much more flexible package that way, since the details of delivering the bits (like the variable width packing, MSB vs LSB, and GIF's sub-block mechanism) have nothing to do with the LZW compression. But a flexible package does need to support a maximum code value (since many implementations require that), and many of the programs there simply assume that the code values have no limit. Still, it's an interesting collection of programs. Remarks specifically about the C implementation there (I doubt this came from a GIF codec, since it differs in so many points from the requirements of GIF):
-- Elphion ( talk) 02:01, 23 October 2015 (UTC)
-- 184.63.132.236 ( talk) 09:23, 23 October 2015 (UTC)
|
This article, and the article on Lossless compression, say that GIF compression is lossless. Wouldn't that only be the case if the image contains 256 colors or less? How would one reconstruct the original colors of an image containing up to 16 million colors if given a GIF image? It seems that saving a colorful image as a single GIF does NOT provide enough information in the compressed file to determine the original colors. It seems that at best, someone trying to reconstruct a colorful image using only a GIF of it could attempt to estimate gradients present in the image to figure out how close each pixel is to its color on the reduced color palette, or try to figure out the original image characteristics by trying to reverse the process by which the GIF compression chose the reduced palette for the image. MathEconMajor ( talk) 18:36, 25 October 2016 (UTC)
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)
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)
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)
Grafman ( talk) 20:30, 14 March 2016 (UTC)
Hello fellow Wikipedians,
I have just modified one external link on GIF. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
An editor has reviewed this edit and fixed any errors that were found.
Cheers.— InternetArchiveBot ( Report bug) 14:27, 9 October 2017 (UTC)
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)
Programming question moved to User talk:Vmelkon -- Elphion ( talk) 18:30, 10 February 2018 (UTC)
i don't know where to add this (the disambig? lone sentence in the lead?) but in contemporary usage (2018) the term "gif" now refers to a short, looping video or animation, no matter what format this in. Twitter prominently displays a [GIF] box over these small looping videos, even though there are mostly mp4. to be clear, i don't care about the technical side (so perhaps this page, actually about the technical file, is wrong?) but the linguistic side. We use "GIF" nowadays to mean something that is NOT "Graphics Interchange Format", even though the usage derives from here. 2A02:8109:9A80:6F6C:3006:3246:A00A:BBD2 ( talk) 23:08, 23 July 2018 (UTC)
I see no point in a section whose purpose is simply to restate that GIFs do not have sound, so I removed it. Do let me know if anyone objects. HamartiaProsciuttoPharos ( talk) 22:21, 16 February 2020 (UTC)
Video alternative to GIF does not currently merit a whole separate article. Ethanpet113 ( talk) 01:49, 13 January 2019 (UTC)
In:
GIF#Pronunciation_of_GIF / second paragraph there are mentioned a lot of dictionaries.
I would appreciate, if:
This way one could see, whether there has been a kind of developement and who might have been following whom.
Please ping me.
Steue (
talk)
09:00, 28 October 2020 (UTC)
@
Metaeducation
In:
GIF#History / first paragraph, the second sentence read:
{I have bolded the questionable word in the second part of the following sentence.}
GIF became popular because it used
LZW data compression, which was more efficient than the run-length encoding that formats such as those used by
PCX and
MacPaint, and fairly large images could therefore be downloaded in a reasonably short time, even with very slow
modems.
I "stumbled" over this "that". Could it be, that it should have become "and"?
Because the sentence was much too long to be easily understood, anyway, I restructured and reworded the whole paragraph, in order to describe the things in chronologic sequence, without changing any information; at least this was my intention. But after having restructured it and compared it to the original I still wonder whether I have put all the information from the original correct, especially, because I still wonder about this "that.".
Please ping me.
Steue (
talk)
07:21, 28 October 2020 (UTC)
![]() | 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. |
Archive 1 |
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.
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.
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)
A Unisys page doesn't mention this http://www.unisys.com/about__unisys/lzw/ but the page is not specifically addressing free software.
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...
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)
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)
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.
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 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)
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)
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
"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).
The article states:
I thought IE was the only one that had "issues". What are the others? -- Yath 22:24, 4 Apr 2005 (UTC)
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)
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)
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:
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)
Screeny >> http://img291.imageshack.us/img291/5835/picox6.jpg -- XIIICats 11:50, 3 August 2006 (UTC)
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)
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/?title=Image:Mustang-ani-t.gif&diff=prev&oldid=82392086
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 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)
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)
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)
make up your mind.
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)
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!
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)
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).
<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
"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)
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)
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)
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?
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.
How would I be able to edit a gif? Can I use Microsoft Paint? -- 66.218.23.154 02:48, 15 January 2007 (UTC)
User:Motter ( contribs) insists on adding links to to this article that lead to his website, at least according to his talk page, quoted below:
like 5 months ago somebody put a link to my free gif making site on the wiki gif page. I didn't put it up there but it has been removed by some person that thinks they are the almighty ruler of wikipedia. I don't really care how cool you are with wiki lingo or how often you check an article that doesn't interest you in the least the better the "community". What I do care about however is offering a totally free service to the users of wikipedia that are searching the internet to find a way to create gifs. leave the link alone Ub3|2N3|2d!
His reasons for including the link therefore appear to fall directly into Wikipedia:External_links#Links_normally_to_be_avoided. I and several other editors have remove the link and warned him that it is spam. His responses have included deleting other links from the article and consistently adding his link back claiming that it improves the article or stating that he was fixing it.
User:Motter has been invited to discuss his concerns on this talk page. GDallimore ( Talk) 10:44, 27 February 2007 (UTC)
gifninja is a free .gif site that offers tools and over 50,000 free animated .gifs and rising. You just aren't going to convince me that the site isn't relevant.
As for the site being affiliated to me. I wasn't the person to list the site originally. When you came along and removed it cause you felt like it, I repaired your vandalism and intend to continue to do so.
—The preceding unsigned comment was added by Motter ( talk • contribs) 00:31, 28 February 2007 (UTC).
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.
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)
⟨⟩
The animations in this article do not seem to work in Firefox: GIF Animation on the WWW - technical explanation of the GIF89a format and how it allows animation —Preceding unsigned comment added by Bitbut ( talk • contribs)
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)
How exactly can one create a animated GIF from scratch? And which tools? Anwar ( talk) 20:35, 9 May 2008 (UTC)
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)
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)
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)
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)
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 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)
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)
There are 21 bytes in example, changed. —Preceding unsigned comment added by 77.37.142.221 ( talk) 19:19, 26 April 2009 (UTC)
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)
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)
Years ago I remember GIF files that contained a number of images and also text. It had very primitive programming language like:
text "Hello world" picture 1, 10 fade text "Next one" picture 3, 30 blink text "finish" loop
I know this because you could view the program and change it using a hex editor. Consequently, it was easy to change the adventures of "Mandy" to whoever you wanted to impress.
I have not seen any documentation of this anywhere. Does anybody have any examples of this? I don't mean the adventures of Mandy, as I am sure that by todays standards it would be somewhat grainy. However an example of any GIF using the inbuilt text format would be nice. It must have been 89a as it supported multiple animated images in a single file. —Preceding unsigned comment added by Puzbie ( talk • contribs) 16:27, 19 July 2009 (UTC)
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)
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)
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 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)
'!'
, 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.(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)
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 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)
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)
Officially? Dictionaries don't make langugages; speakers do. 80.103.84.224 ( talk) 10:39, 19 March 2013 (UTC)
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'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)
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)
It would be nice if the article answered that. -- TiagoTiago ( talk) 03:15, 23 May 2013 (UTC)
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)
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)
How do you cite the fact that sprites in games are stored as GIF files? 12Me21 ( talk) 22:11, 20 January 2015 (UTC)
The current wording makes it seem like the company was a passive innocent victim, but that's really not the case -- in fact, it changed its stated policies and enforcement strategies several times over the years, and during the last year or two before the U.S. patent expired, it seemed to be flailing around and trying to extract a little more blood out of the turnip by any possible method. The issue of retroactively closed/proprietary file formats has been a very sensitive one for on-line communities ever since the ARC wars of the late 1980s (before there even was a commercial consumer Internet). AnonMoos ( talk) 15:45, 10 March 2015 (UTC)
Since animated gifs can be painful and/or seizure-inducing, the article should discuss tools to block them and should discuss why most browsers enable them. 71.191.163.95 ( talk) 23:00, 17 April 2015 (UTC)
This article seems highly technical. I came here looking for an overview of the historical and cultural story of the animated GIF... from the animated road-worker "under construction" sign GIFs of the late 90s, to the clips-from-movies-as-a-form-of-emoji that we see today, as well as cinemagraphs.... I think something of that cultural story about the usage of GIFs should be added... Or at least linked to if it exists elsewhere? It's pretty embarrassing that knowyourmeme does a better job of telling this story than Wikipedia does. Alexbowyer ( talk) 12:31, 17 June 2015 (UTC)
I noticed that your example of a true colour image (SmallFullColourGIF.gif) had some extensions that I have been unable to decipher. These are labelled ZGATEXTI5 and ZGANPIMGI5 but I think there are others out there. Does anyone have more information on them? LaserBilly ( talk) 09:43, 24 September 2015 (UTC)
For example, JPEG: JAY-peg. Is it pronounced " JEH-if " or " GEH-if " ? (I don't know how the respell template works.) —User 0 0 0 name 04:30, 18 October 2015 (UTC)
Done --
Elphion (
talk)
21:58, 18 October 2015 (UTC)
I've moved here for discussion the following 2012-11-23 addition to the article by 80.101.72.96 ( talk · contribs · WHOIS):
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)
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)
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)
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)
user:BenRG corrects a long-standing error in the description of uncompressed GIFs [5] (good catch). He also adds the observation that if the code width were allowed to increase to the full 12 bits, the overhead would approach 50%. But isn't it the case that the "uncompressed algorithm" has always assumed fix-width codes? [The following argument that predicting increases in code width requires maintaining a table is incorrect; see my further remarks after "The Rule of 2^n − 2" below] To predict where the width would actually increase would require something very close to maintaining the encoding dictionary, which would defeat the whole purpose of uncompressed GIFs. (added:) well, no, I suppose you could maintain the decoding dictionary instead, which is not covered by the patent. But: The point was never to mimic the code growth (or to reduce the encoder overhead required to keep track of it), but to prevent the decoder from increasing the width. Given that, the 50% datum is sort of irrelevant. Added: Are there references showing schemes that actually attempted to mimic adjustments in code-width? -- Elphion ( talk) 17:32, 20 May 2011 (UTC)
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)
Code |
---|
The following discussion has been closed. Please do not modify it. |
0 1 1 1 0 1 1 1 1 1 1 1 1 1 1
100 initial CLEAR 000 pixel 1 001 pixel 2 100 CLEAR 001 pixel 3 001 pixel 4 100 CLEAR 000 pixel 5 001 pixel 6 100 CLEAR 001 pixel 7 001 pixel 8 100 CLEAR 001 pixel 9 001 pixel 10 100 CLEAR 001 pixel 11 001 pixel 12 100 CLEAR 001 pixel 13 001 pixel 14 100 CLEAR 001 pixel 15 101 STOP
Binary Hex 0100 0100 44 1001 1000 98 0001 0000 10 0110 0001 61 1100 0010 C2 1000 0100 84 0000 1001 09 0001 0011 13 1010 0110 A6
byte# hexadecimal text or (hex) value Meaning 00: 47 49 46 38 39 61 GIF89a Header Logical Screen Descriptor 06: 03 00 3 - logical screen width in pixels 08: 05 00 5 - logical screen height in pixels 0A: 80 - GCT follows for 2 colors with resolution 3 x 1 bits/primary 0B: 00 0 - background color #0 0C: 00 - default pixel aspect ratio R G B Global Color Table 0D: 00 00 00 0 0 0 - color #0 black 10: FF FF FF 255 255 255 - color #1 white 13: 2C Image Descriptor 14: 00 00 00 00 (0,0) - NW corner position of image in canvas 18: 03 00 05 00 (3,5) - image width and height in pixels 1C: 00 - no local color table 1D: 02 2 LZW minimum code size 1E: 09 9 9 bytes of encoded image data follow 1F: 44 98 10 61 C2 84 09 13 A6 28: 00 - end 29: 3B GIF file terminator
|
(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)
(outdent)
Here's a 46 x 46 uncompressed GIF with 7-bit symbols (128 colors, 8-bit codes). I put each raster in its own sub-block, with a CLEAR code at the beginning of each raster. Each raster sub-block thus has 48 bytes: length (47=2F) + CLEAR (80) + 46 bytes for 46 pixels. (This scheme has more CLEAR codes than necessary -- one for every 46 codes rather than the max of 126 -- but it makes the addressing simpler.) The STOP code is in its own 2-byte sub-block at the end (01 + 81), followed by the terminating null sub-block (00). The global color table has 128 entries.
-- Elphion ( talk) 01:48, 24 May 2011 (UTC)
Sorry, don't agree at all. It's an interesting historical phenomenon, and still useful for producing GIFs without implementing LZW. -- Elphion ( talk) 22:25, 23 October 2015 (UTC)
Extended discussion of an LZW implementation at rosettacode |
---|
The following discussion has been closed. Please do not modify it. |
I'm working on a GIF encoder right now, and to me the middle of this article (from "6 Example GIF file" to "8 Interlacing") looks highly misleading. It looks like a hacker that didn't realize the specification is public tried to reverse engineer some GIFs and wrote the entire project up in a journal. Specifically the bulk of it looks like it's just trying to describe what LZW compression looks like when looked at in a hex editor; which needless to say has nothing to do with GIF and probably doesn't belong on the LZW article either. BMP_file_format has very nice tables. The GIF specification in the external links is very short, and is overlong in the document itself, it could be compressed down to a very small section, with a brief mention of the data chunks being LZW encoded, and that should be all. I won't raise a hand to wipe the article until I have a working encoder, so I can be absolutely certain of this position. In the meantime please comment, and please volunteer to make tables for GIF. They would be much smaller than the ones on the BMP article, but I'm not going to wrestle with tables in the article, or volunteer to translate the specification. I'm not a Wikipedian, but if GIF can be a word of the year, then this article can at least not be a train wreck, even if that means taking the ax to it-- 184.63.132.236 ( talk) 19:41, 19 October 2015 (UTC) ALSO, the entire notion of "uncompressed" GIF looks dubious, and unworthy of mention. As near as I can tell it is LZW compressed, just maximally poorly so. In which case it doesn't warrant a technical explanation, although it could be a short paragraph if it was found that such GIFs circumvented the LZW patent, however it seems unlikely that they would, because they are still technically LZW compressed.-- 184.63.132.236 ( talk) 19:45, 19 October 2015 (UTC)
Yes; as you've discovered, there are many different ways to implement LZW -- different applications use different versions, and we do already point that out at LZW. The link to rosettacode (if we include it at all), as you say, belongs at LZW, not GIF -- and that's where it is. (I don't know offhand where the link came from; as a general rule we don't link to implementation websites unless they're fairly authoritative.) The comment you added at rosettacode is quite right: the version there is not the one used by GIF (though in fairness it doesn't claim to be). But I'll push back on two aspects of that comment: (1) GIF implements 2 to 8 bit color, not 1 to 8 bit. (The symbol size in the Image Descriptor must be at least 2 -- although if you only use colors 0 and 1, the color table need only have two entries.) (2) GIF is by no means the only place LZW is used. LZW (and LZ in general) was developed primarily for text compression, and is still widely used for that -- especially in embedded devices where minimal overhead is important. It's also still the most common compression in TIFF files -- which again uses a different version. It's partly because GIF uses a specialized version of LZW that the GIF examples were provided here, since the examples at LZW are not specific to GIF. I agree that the current formatting is not optimal. I don't agree that the material doesn't belong here. The GIF spec does not suffice in this regard since it doesn't cover the specifics of LZW. Welch's original article is not bad, but (a) it doesn't address GIF in particular, (b) it doesn't discuss variable length codes (one of the reasons that "early change" was implemented by mistake), and (c) it's hard to get hold of. In fact, outside of WP I know of no completely error-free discussion on the web. So there is some value here, and I'm wary of throwing out too much. [added:] That code at rosettacode is pret-ty fun-ky. E.g., indexing or incrementing a (void*) pointer ... especially when you're stuffing (size_t)-sized objects there ... -- Elphion ( talk) 05:21, 21 October 2015 (UTC)
I've taken a closer look at the code at rosettacode.com. It's not awful, but could use some spiffing up. Unlike many of the language examples there, the C code makes the mistake of trying to combine the compression and the packing; most of the programs produce (or consume) an array of integer codes, and leave the packing details to a separate pass. You get a much more flexible package that way, since the details of delivering the bits (like the variable width packing, MSB vs LSB, and GIF's sub-block mechanism) have nothing to do with the LZW compression. But a flexible package does need to support a maximum code value (since many implementations require that), and many of the programs there simply assume that the code values have no limit. Still, it's an interesting collection of programs. Remarks specifically about the C implementation there (I doubt this came from a GIF codec, since it differs in so many points from the requirements of GIF):
-- Elphion ( talk) 02:01, 23 October 2015 (UTC)
-- 184.63.132.236 ( talk) 09:23, 23 October 2015 (UTC)
|
This article, and the article on Lossless compression, say that GIF compression is lossless. Wouldn't that only be the case if the image contains 256 colors or less? How would one reconstruct the original colors of an image containing up to 16 million colors if given a GIF image? It seems that saving a colorful image as a single GIF does NOT provide enough information in the compressed file to determine the original colors. It seems that at best, someone trying to reconstruct a colorful image using only a GIF of it could attempt to estimate gradients present in the image to figure out how close each pixel is to its color on the reduced color palette, or try to figure out the original image characteristics by trying to reverse the process by which the GIF compression chose the reduced palette for the image. MathEconMajor ( talk) 18:36, 25 October 2016 (UTC)
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)
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)
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)
Grafman ( talk) 20:30, 14 March 2016 (UTC)
Hello fellow Wikipedians,
I have just modified one external link on GIF. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
An editor has reviewed this edit and fixed any errors that were found.
Cheers.— InternetArchiveBot ( Report bug) 14:27, 9 October 2017 (UTC)
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)
Programming question moved to User talk:Vmelkon -- Elphion ( talk) 18:30, 10 February 2018 (UTC)
i don't know where to add this (the disambig? lone sentence in the lead?) but in contemporary usage (2018) the term "gif" now refers to a short, looping video or animation, no matter what format this in. Twitter prominently displays a [GIF] box over these small looping videos, even though there are mostly mp4. to be clear, i don't care about the technical side (so perhaps this page, actually about the technical file, is wrong?) but the linguistic side. We use "GIF" nowadays to mean something that is NOT "Graphics Interchange Format", even though the usage derives from here. 2A02:8109:9A80:6F6C:3006:3246:A00A:BBD2 ( talk) 23:08, 23 July 2018 (UTC)
I see no point in a section whose purpose is simply to restate that GIFs do not have sound, so I removed it. Do let me know if anyone objects. HamartiaProsciuttoPharos ( talk) 22:21, 16 February 2020 (UTC)
Video alternative to GIF does not currently merit a whole separate article. Ethanpet113 ( talk) 01:49, 13 January 2019 (UTC)
In:
GIF#Pronunciation_of_GIF / second paragraph there are mentioned a lot of dictionaries.
I would appreciate, if:
This way one could see, whether there has been a kind of developement and who might have been following whom.
Please ping me.
Steue (
talk)
09:00, 28 October 2020 (UTC)
@
Metaeducation
In:
GIF#History / first paragraph, the second sentence read:
{I have bolded the questionable word in the second part of the following sentence.}
GIF became popular because it used
LZW data compression, which was more efficient than the run-length encoding that formats such as those used by
PCX and
MacPaint, and fairly large images could therefore be downloaded in a reasonably short time, even with very slow
modems.
I "stumbled" over this "that". Could it be, that it should have become "and"?
Because the sentence was much too long to be easily understood, anyway, I restructured and reworded the whole paragraph, in order to describe the things in chronologic sequence, without changing any information; at least this was my intention. But after having restructured it and compared it to the original I still wonder whether I have put all the information from the original correct, especially, because I still wonder about this "that.".
Please ping me.
Steue (
talk)
07:21, 28 October 2020 (UTC)