Talk:GIF

PIG

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

Empty.gif

The LZW sequence of Empty.gif consists just of one byte 0x44. The minimum code size for this LZW sequence is 2. Decoding that works only if the decoder adds another byte with the lowest bit set (e.g.: [0x44, 0x01]). The decoder now works as follows:

• Read the first 3 Bits from the LZW sequence --> 4
• 4 is the clear code. So the LZW state is reset.
• Read the next 3 Bits form the LZW sequence --> 0
• 0 is the colormap entry for the only pixel in Empty.gif.
• Read the next 3 Bits from the LZW sequence --> This would need the next byte from the sequence, but that does not exist.
• If the next byte would have a value with the lowest bit set (such as 0x01) then reading 3 bits from the LZW sequence --> 5
• 5 is the end code, so the LZW decoding is finished.

I have tested several GIF files and Empty.gif is the only GIF where the LZW decoder needs to read beyond the sequence. In all other GIFs I tested the LZW sequence ends with an end code and there is no need to go beyond the end of the LZW sequence. So either Empty.gif is not a correct encoded GIF or there is something missing in the explanation. In Wikipedia is also Blank.gif, which is encoded as

47494638 39610100 01008000 00ffffff 00000021 f9040000  GIF89a.............!....
0000002c 00000000 01000100 00020244 01003b             ...,...........D..;

Empty.gif is encoded as

47494638 39610100 01008000 00000000 ffffff21 f9040100  GIF89a.............!....
0000002c 00000000 01000100 00020144 003b               ...,...........D.;

You can see that Blank.gif uses an LZW sequence of [0x44, 0x01] which contains also an end code. -- Hans Bauer (talk • contribs) 10:35, 19 March 2021 (UTC)

You are correct: Empty.gif is not coded correctly and should have a 2-byte sub-block to include the full 3 bits for the stop code, exactly as Blank.gif does. Many decoders will ignore a screw-up like this if the stream contains enough data to fill out the pixels for the area described in the image descriptor. Some will even assume pixel values of 0 to the end of the image if the stream ends prematurely. I've removed the code readout for Empty.gif: it's not only incorrect, it contributes nothing to the discussion. -- Elphion (talk) 20:04, 19 March 2021 (UTC)

PS: The stop code is somewhat superfluous for GIF files (as opposed to, say, LZW-encoded text streams), since the decoder knows in advance how many pixel codes there should be. As I indicated above, many (probably most) decoders won't blink too hard if the stop code is missing (as it effectively is in Empty.gif, which simply stops after the last data byte). But both the 87a and 89a specs say that the stop code "must be the last code output by the encoder." -- Elphion (talk) 20:47, 19 March 2021 (UTC)

Application block for animated GIFs

A recent edit by user FaKen2021 claims that the application extension block added by Netscape to signal a repeating animation has an additional field for the length of the application name field. The 89a spec is quite explicit about the format of the application block, and it contains no such length field. It is possible for an application to fudge this, but a complying parser would not read it that way. Animated GIFs I have examined do not include such a field. -- Elphion (talk) 01:32, 20 April 2021 (UTC)

Apologies -- I misunderstood the edit because the description of the fields differed materially from the spec's definition. I have reinstated the edit and changed the annotations to conform to the spec. Thanks for catching the error in the original description. -- Elphion (talk) 02:00, 20 April 2021 (UTC)

GIF Spec

Danbloch (talk · contribs) removed the link to https://www.w3.org/Graphics/GIF/spec-gif89a.txt, claiming that it is not the GIF spec. This is the document that has been circulating for decades as the GIF spec, and it is so labeled at W3C. The link should be restored. -- Elphion (talk) 22:16, 27 July 2021 (UTC)

@Elphion: Sorry, you're quite right. I've reverted my change. Dan Bloch (talk) 23:34, 27 July 2021 (UTC)

Thanks. -- Elphion (talk) 23:51, 27 July 2021 (UTC)

Improving the 'True color' section

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" - 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 that would describe the looping information for an animation, and the Graphic Control Extension blocks 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)

References

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)

Followed or follow?

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)

Changing the respell

Hi, I'd like to propose to change the respelling from "JIF" to "DJIF". This will avoid confusion with "dʒ" and "ʒ". $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 $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. $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. $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)

GIFs with sound?

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)

Discuss that most people will call GIFs what actually is not a GIF?

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

The "example gif"

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)