Talk:GIF

message: 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)
replies: text: 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)

text: 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)
thread_title:  Empty.gif 

message: 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)
thread_title:  Application block for animated GIFs 

message: 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)
replies: text: Sorry, you're quite right.  I've reverted my change. Dan Bloch (talk) 23:34, 27 July 2021 (UTC)
replies: text: Thanks.  -- Elphion (talk) 23:51, 27 July 2021 (UTC)
thread_title:  GIF Spec 

message: 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)
replies: text: Yes. -- Elphion (talk) 11:51, 30 May 2022 (UTC)
thread_title:  Followed or follow? 

message: Hi, I'd like to propose to change the respelling from "JIF" to "DJIF". This will avoid confusion with "dʒ" and "ʒ". M^{atr1x-}_{101} {userpage! | talk!} 22:12, 28 November 2022 (UTC)
replies: text: This will also avoid confusion with "" (y sound) in IPA M^{atr1x-}_{101} {userpage! | talk!} 16:28, 30 November 2022 (UTC)
replies: text: 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)
replies: text:  I think that WP:IGNORE applies and that "JIF" could be confused with " (with a "j" as in "hallelujah)"" or "". Besides, there's not much people can confuse "DJIF" with. M^{atr1x-}_{101} {userpage! | talk!} 17:38, 1 December 2022 (UTC)
replies: text: 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)
replies: text: @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^{atr1x-}_{101} {userpage! | talk!} 21:17, 1 December 2022 (UTC)
replies: text: 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)
thread_title:  Changing the respell 

message: 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)
thread_title:  GIFs with sound? 

message: > 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)
replies: text: What you need is a Reliable Source. -- Elphion (talk) 15:47, 5 October 2023 (UTC)
replies: text: 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)
thread_title:  Discuss that most people will call GIFs what actually is not a GIF?