Talk:GIF

The 'True color' section has several issues. I attempted to address some of them but the whole contribution was reverted by Elphion (talk · contribs). I'm not an (auto)confirmed user on the English wiki but if someone has a higher reputation whose edits are not reverted immediately feel free to cherry pick the valuable parts of my contribution attempt. The room for improvements I tried to cover:

• The title: True color conventionally means at least 24/32bpp color depth. The current illustration is high color at best with its 1859 colors. Btw. technically there is no different in the approach and the "although larger tiles may be used and similar colors merged resulting in some loss of color information" part already gives the hint that simple high color approach is preferable to avoid huge file sizes.
• Factually incorrect information: "Many rendering programs interpret tiles or layers as animation frames and display them in sequence as an endless animation^[1]" - not true, the mistakenly animated still images are played only once. The added reference is a repetition of an obsolete webarchive link that has nothing to do with looping.
• Poor sources: The current article doesn't provide concrete examples for decoders that handle high color GIF images property. Instead, tells the aforementioned vague (and incorrectly described) behavior of browsers. The provided references for common delays are therefore tagged as 'better source needed'. I added concrete examples for properly working decoders and applications (GDI+, Windows Paint, .NET/.NET Framework applications using Windows Forms technology).
• High color animation/still image distinction:
  • Technical distinction: I made it clear what makes a GIF animation or multi-layered image: "Multi-layer high color GIF images do not have the Netscape Application Extension Block^[2] that would describe the looping information for an animation, and the Graphic Control Extension blocks^[3] are either missing or all of them have zero delay. Some GIF decoders [...] handle them correctly as well; however, many other decoders, including some browsers treat zero delays as 100 millisecond ones even if the image is not an animation (it has no Netscape Application Extension Block)."
  • Thematic distinction: I admit I could've done it better. I split the section into separate animations/still images parts; however, I didn't really changed the animation part. But now the whole section thoroughly explains high color images whereas the title and the illustration is about animation, which might be confusing.
• Obsolete references: The currently used obsolete webarchive reference contains an actual example for a high color GIF still image (titled as true color but it's actually a 15bpp example of 32K colors). Without removing the dead link, I included an additional reference to a live project that has illustrations for high color animations and images.
• Still image illustration: As I'm not a confirmed contributor on the English wiki I could not upload an image example. In the end I added a commented out section with all the needed information along with the suggested description that triggered an 'Incorrectly formatted external link or image' tag (because I included the external image link in the comment)

I'm a bit disappointed that none of the changes met the local standards. I know it wasn't perfect (maybe even grammatically) but it definitely was an improvement compared to the current vague and somewhat misleading version. I hope this clarification (which took almost as much time as the original contribution) will be a good enough starting point for the higher respected contributors to improve the article. Feel free to remove this section once the corrections are done.

--TafferBoy (talk) 11:38, 6 December 2021 (UTC)

Response: First, and most important: although I reverted your edit, that does not mean there is nothing of value there. That's why I suggested discussion on the talk page, so we could discuss a better way to present the material.

• Title: True color is accurate. It means the ability to address any color in the 16M color space -- not that an image must contain all of those colors. The image in the article is 210 x 210 pixels = 44,100 pixels, so it certainly is not going to be able to display 16M colors -- and indeed, any example we provide here in thumbnail size will have a limited number of colors unless it is a very long animation -- which would not be appropriate, since we try to keep download time reasonable. Similarly, a JPG or PNG image is not going to include all the colors unless it is pretty big (4k pixels squared), yet these are still "true color" formats.

• Endless looping: You are quite correct that the display is not endless without a NAB extension block. I've removed the word "endless". The incorrect display is still often displayed as an animation, even if displayed only once. (The GCE block is described explicitly as enabling animation as it includes provision for time delays between frames. NAB adds only the ability to run through the animation more than once.)

• Poor/obsolete sources: The current source does not say that no platform displays these incorrectly, just that many browsers do. It's fine to add examples of platforms that display the images correctly; but then you have the task of choosing which ones to mention (and which ones not to mention) and finding references stating that they do display the images correctly. It is still true that many browsers show true color GIFs as animations (including even Chrome) rather than pre-assembling the image in memory before display -- though I haven't seen a good survey more recent than the archived article.

• Still image illustration: The current image attempts to show the difference in quality between a 256-color image and a higher color space, though unless you look closely it is hard to notice the difference. The image is not ideal: it attempts to alternate between 256 and full color (which is why it is animated). I think a better approach would be to present a side by side comparison of still images, 256 vs full color. (As you suggest, the animation draws attention away from the color issue.) I have not searched Commons for a good full color candidate. I would rather avoid using Lena: a frequent example in CG papers, yes, but a Playboy companion nonetheless -- we don't have to perpetuate the exploitation of women here. And in any event, an image that large won't display well in thumbnail size.

-- Elphion (talk) 13:52, 6 December 2021 (UTC)

Added: A good case can be made that the sequential display of the layers is not incorrect. The description of GCE does not require images to be pre-assembled, just that without explicit time delay, the delay should be 0. But any large image will take time to download; it is still common to see spatially large images displayed progressively as the bits are downloaded. GIF and PNG, e.g., both give some control over how that progressive display is assembled (via interleaving). Similarly, an image with large color-depth may take time to download, and the sequential display of GIF frames is in some sense a way of managing that too. What is a mistake (as seen in older browsers) is inserting a non-0 delay between frames when no time delay is specified. -- Elphion (talk) 14:12, 6 December 2021 (UTC)

And more: This section is about True Color in GIF, not about animation. We give details of the animation machinery in the section on animation. There's no good reason I can see for repeating that information in the True Color section. -- Elphion (talk) 14:51, 6 December 2021 (UTC)

"The GCE block is described explicitly as enabling animation as it includes provision for time delays between frames. NAB adds only the ability to run through the animation more than once."

Actually GCE is needed also when the image has overlapping layers such as in the high color Lena example because it specifies the transparent color index for local palette blocks. Still, GDI+, Windows Paint and the mentioned examples treat it correctly as a single frame image. The existence of NAB is what changes the interpretations of full 0 delays: if NAB presents, then even these applications treat the image as an animation where 0 values are translated to 100ms delays (or, if the app does not support animations, such as Windows Paint, then only the first frame will be displayed).

"The image is not ideal [...] I think a better approach would be to present a side by side comparison [...] I would rather avoid using Lena"

The linked project has also a 256x256 icon example. Fairly small (45K), 4363 colors. The same folder contains also the PNG version that can be used for comparison. As it has transparent background, it can illustrate an important difference: the high color GIF image cannot have partial transparency. And if you would like to add a regular 8bpp GIF as well, the linked tool on the project site allows you to create it with whatever ditherers. Feel free to generate the best looking samples as I could not upload them anyway. — Preceding unsigned comment added by TafferBoy (talk • contribs) 16:57, 6 December 2021 (UTC)

Of course GCE is required if the image uses transparency (but the article has already said that). My point is simply that GCE (not NAB) is where the delay (if any) is specified. Most programs I've seen include a minimum delay when displaying the image even if the delays are set to 0 (or other small value), regardless of whether NAB is present. I don't know why; it might simply be the overhead of setting up a new frame, or the thread might simply be yielding momentarily to avoid freezing up the system when displaying a large image with an unknown number of frames.

The behavior you describe in GDI+ (inserting default delays if NAB is present but not otherwise) is very interesting. I haven't observed that behavior elsewhere. On the other hand, I do frequently see programs (like Windows Image/Photo Viewer and any number of image editing programs) that will display only the first frame (and will save only one frame per image file).

On balance, I think what needs changing is (a) finding a nice pair of still images to illustrate the difference, and (b) rewriting the last paragraph of the section to avoid the notion of "incorrect" display, simply saying that different platforms handle such images differently -- from displaying only the first frame, to inserting minimum default delays between the frames.

Do you own the rights to the images you linked to on GitHub? If so, we could use the image with the color gradient and a 256-color variant to illustrate the difference. (I see the "License" paragraph on the GitHub page, but to import the image to Wikepedia or Commons I think it would have to be released with one of the standard licenses, rather than "KGy SOFT License 1.0". See wp:Image use policy.) The Warning sign image is another possibility, but I'm not sure why you say a full color GIF cannot have "partial transparency": if all layers mark a pixel transparent, it should be transparent. Another possibility is simply splitting the current example into two separate images: one with 256 colors, the other with 1859 -- the difference will be much easier to see without the animation.

-- Elphion (talk) 20:38, 6 December 2021 (UTC)

"Do you own the rights to the images you linked to on GitHub?"

The 'de facto' test images can be reused but Lena is problematic for other reasons, I'm unsure about the Windows icons but since there is a Wiki category for them I think it's okay, too; and as for the Granger rainbow, it can be simply generated, source is included. Btw. the license says that all non-SW like materials should be treated as the ones fall under CC BY 4.0.

"I'm not sure why you say a full color GIF cannot have 'partial transparency'"

I mean the GIF format does not support partial alpha so pixels can be either completely transparent not at all. The original icon has a nice partially transparent shadow, whereas it's not supported by the GIF image (GCE can designate one palette entry to represent the transparent color; otherwise, palette entries have only RGB values). Therefore the icon is a good example because it clearly demonstrates this feature.

TafferBoy (talk) 20:57, 7 December 2021 (UTC)

In GIF #Unisys and LZW patent enforcement /
third to last para (starting: "Following this announcement ...") /
second to last sentence
says:

(I capitalized the words and letters concerned, for convenience.)

For instance the libungif library, based on Eric S. Raymond's giflib, allows creation of GIFs that FOLLOWED the data format but AVOIDED the compression features, thus avoiding use of the Unisys LZW patent.

Shouldn't this "followED" be "follow" and "avoidED" be "avoid"?

Ping welcome, Steue (talk) 11:22, 30 May 2022 (UTC)

Yes. -- Elphion (talk) 11:51, 30 May 2022 (UTC)

Hi, I'd like to propose to change the respelling from "JIF" to "DJIF". This will avoid confusion with "dʒ" and "ʒ". ${\displaystyle M_{101}^{atr1x-}}$ {_user^page! | _t^a_l^k!} 22:12, 28 November 2022 (UTC)

This will also avoid confusion with "/j/" (y sound) in IPA ${\displaystyle M_{101}^{atr1x-}}$ {_user^page! | _t^a_l^k!} 16:28, 30 November 2022 (UTC)

Respell uses common English letter-values according to a well-defined WP scheme. The current respellings follow the guidelines. -- Elphion (talk) 21:27, 30 November 2022 (UTC)

@Elphion: I think that WP:IGNORE applies and that "JIF" could be confused with "/jɪf/ (with a "j" as in "hallelujah)"" or "/ʒɪf/". Besides, there's not much people can confuse "DJIF" with. ${\displaystyle M_{101}^{atr1x-}}$ {_user^page! | _t^a_l^k!} 17:38, 1 December 2022 (UTC)

I certainly don't agree. The conventions for Respell are quite clear. It is not IPA (nor meant to be), and native speakers of English (who are the intended audience) will not be confused. The article already provides IPA for non-native speakers. -- Elphion (talk) 20:03, 1 December 2022 (UTC)

@Elphion I don't understand the problem with making it "DJIF". It will help, at least a few confused people and it won't really confuse anyone! Besides, the page you cited Help:Pronunciation respelling key doesn't look like a strict convention that must always be followed. I'm saying "GIF" is an exception due to its unique nature as a word. ${\displaystyle M_{101}^{atr1x-}}$ {_user^page! | _t^a_l^k!} 21:17, 1 December 2022 (UTC)

Again, I disagree. The average English speaker will understand "JIF" at once, wouldn't have a clue how to pronounce "DJIF", since "DJ" almost never occurs in English, especially in initial position. Respell is designed to use standard English spelling conventions, and "JIF" conforms to those exactly. -- Elphion (talk) 00:00, 2 December 2022 (UTC)

Apparently you can now have GIFs with sound. They appear to have better than 8-bit colour as well.

I haven't found any official specs anywhere yet though. Cb27p (talk) 15:32, 9 July 2023 (UTC)

cool I'll look. 💢no gifs allowed😫 164.152.179.169 (talk) 21:53, 18 April 2025 (UTC)

> In January 2016, Telegram started re-encoding all GIFs to MPEG-4 videos that "require up to 95% less disk space for the same image quality."[76]

https://techcrunch.com/2014/06/19/gasp-twitter-gifs-arent-actually-gifs/

I think many many websites describe small videos as GIFs, even when internally they use something else. I suspect this is worth adding to the page? — Preceding unsigned comment added by 79.116.36.51 (talk) 15:42, 5 October 2023 (UTC)

What you need is a Reliable Source. -- Elphion (talk) 15:47, 5 October 2023 (UTC)

I'm going to try to edit the page to include a reference to this article from The Atlantic, which seems to be a pretty good article regarding GIF's decline both as a file format and as a general communication medium ("reaction GIFs"), and also covers how most sites actually host MP4s instead. --TheSophera (talk) 23:00, 20 October 2023 (UTC)

GIF#Example GIF file -- where is it? The "sample image" at the top of the section links to File:GifSample.gif, which isn't it (this is an enlarged GIF which is 32x52 and has a border). Where is the actual 3x5 gif that's referred to in the section? Is it on Commons? It can't be reconstructed from the information given because it truncates and skips over portions. jp×g🗯️ 04:03, 18 November 2023 (UTC)

Spelunking... nothing on Commons, nothing in the uploader's log... we get, I guess... whatever this is. jp×g🗯️ 04:13, 18 November 2023 (UTC)

I doubt that Cuddlyable3 ever uploaded the file. (It's so small there's hardly any point.) I agree that it's a little difficult to reconstruct the file, but it's not impossible. The only data missing are the contents of the Global Color Table (which can be retrieved from the image of the palette) and the indexes of the colors being used for Black and White. (Both colors appear more than once in the color table.) The indexes chosen happen to be Black = 0x28 and White = 0xFF. (The other contents of the color table don't really matter, since those are the only indexes used.) The codes generated by the algorithm and packed into the data bytes are:

100 (clear) | 28 (B) | FF (W) | 103 (WW) | 102 (BW) | 103 (WW) | 106 (WWW) | 107 (WWWW) | 101 (stop)

Any choice of index for B and W will generate the same sequence, except 28 and FF will be replaced by whatever indexes you choose for B and W. (We should mention that for this example Black=28 and White=FF.)

@JPxG: -- Elphion (talk) 19:18, 18 January 2024 (UTC)

And actually, the two indexes (decimal 40 and 255) are already mentioned in the text ahead of the table. -- Elphion (talk) 19:34, 18 January 2024 (UTC)

Well, I looked a bit further. It turns out that there are several versions of the palette image, each with slightly different colors than the others. All have Black in slot 28 hex and White in FF hex, but none has precisely #800000 in slot 01, which is what is shown in the table. All are similar to the usual MS Paint 256-color palette (which does have #80000 in slot 01) -- and the article claims the original came from MS Paint. So the original palette was likely the Paint palette. As I wrote above, it doesn't really matter what the other colors are, so a reasonable facsimile of the original 3x5 image can be reconstructed simply by creating a GIF in MS Paint and using the color table from that image as the color table in the 3x5 image. The rest of the data in the 3x5 image is shown in the table. -- Elphion (talk) 09:05, 19 January 2024 (UTC)

The article fails accessibility.

Wikipedia:Manual of Style/Accessibility#Animations says: "To be accessible, an animation (GIF – Graphics Interchange Format) should either: Not exceed a duration of five seconds (which results in making it a purely decorative element)[12] or Be equipped with control functions (stop, pause, play)[13]"

Non-compliance in this particular article sets a poor example. Humpster (talk) 23:32, 24 December 2024 (UTC)

So fix it. -- Elphion (talk) 19:41, 30 December 2024 (UTC)

Fixed. Humpster (talk) 22:56, 30 December 2024 (UTC)

Not an acceptable solution. The MOS suggestion makes perfect sense for animations designed to be eye-catching or distracting. This is not such an animation. However, if the animation truly bothers you, your MOS link has a link to a procedure to convert GIF to OGG. -- Elphion (talk) 00:18, 31 December 2024 (UTC)

Hearing no response, I'm removing the tag. -- Elphion (talk)

The redirect Blinky (image) has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at Wikipedia:Redirects for discussion/Log/2025 August 5 § Blinky (image) until a consensus is reached. 1234qwer1234qwer4 00:27, 5 August 2025 (UTC)

If using lossless compression after dumping nearly all color information is lossless - then half a liter plastic bottle is an appropriate "lossless" medium for up to 100 liters of liquid... you just dump the other 99.5 liters on the ground.

Also, if the argument is that it uses lossless compression, ergo it is lossless - you can "losslessly" squeeze that bottle to be slightly smaller, even when full.

That still doesn't make it an appropriate "lossless" medium for 100 liters of liquid - you have to LOSE 99.5% of it to squeeze ANY of it in.

And NO - "Well, you wouldn't want to use such a small bottle for that much liquid anyway" is NOT A VALID ARGUMENT.

We're talking capability, not quantity. Lossless means that there is no loss of data when image is saved using a certain file format. Did anyone here even try to save something as a GIF, using actual graphics software, like Photoshop or something?

FFS, it's like saying there is no color loss when saving an image as grayscale. Same 256-color palette as GIF! 109.175.105.56 (talk) 03:02, 10 October 2025 (UTC)

The compression is lossless. This is why GIF is frequently used for images with few colors, like logos and icons, which in lossy compression schemes typically acquire color artifacts. Nobody is arguing that conversion to 256 colors is ideal for full-color images. (GIF cannot be applied directly to such images anyway.) You are confusing image compression with image manipulation. -- Elphion (talk) 15:05, 10 October 2025 (UTC)