Jump to content

Talk:GIF: Difference between revisions

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Content deleted Content added
Hans Bauer (talk | contribs)
Use byte with lowest bit set
Hans Bauer (talk | contribs)
Replace 0xff by 0x01
Line 148: Line 148:
* 0 is the colormap entry for the only pixel in Empty.gif.
* 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.
* 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 0xff) then reading 3 bits from the LZW sequence --> 5
* 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.
* 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.
I have tested several GIF files and Empty.gif is the only GIF where the LZW decoder needs to read beyond the sequence.

Revision as of 11:34, 19 March 2021

Template:Vital article

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.


Actual format?

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)[reply]

" ... what a GIF file actually has in it byte by byte." Sounds like the spec to me. If we were to rehash the spec here, how can we be expected to predict how much detail you need? There's a link to the spec, and that's absolutely the right solution. Elphion (talk) 16:56, 11 November 2009 (UTC)[reply]

Programming question moved to User talk:Vmelkon -- Elphion (talk) 18:30, 10 February 2018 (UTC)[reply]

Pronunciation

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)[reply]

I don't see any contradiction. Both pronunciations are used; the soft G version ("Jif") was the original version used by the development team in deliberate reference to the peanut butter brand. Both versions are listed in dictionaries. What's the problem? -- Elphion (talk) 23:17, 2 June 2012 (UTC)[reply]

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)[reply]

Anyone else catch/find funny the fact that this person basically said "if you pronounce it like it's spelled, then you're a luddite"? or am I the only one? he/she used "GIF" as the text representation (of the pronunciation indicated to be incorrect), thus implying that however the reader reads those three letters (which would probably HAVE to be with a hard "g", as it is juxtaposed with and preceded by "JIF", -which is far less ambiguous- in that comment) is in fact incorrect... Brettpeirce (talk) 17:22, 2 November 2016 (UTC)[reply]
Yes "GIF" is ambiguous, especially since many Germanic words keep the hard G, even though the usual rule is soft G before E, I, and Y. The language gives no clear verdict one way or the other. That's why the pronunciation guide uses "ghif" to indicate the pronunciation of hard G. It's not perfect, but there's no unambiguous alternative in this situation. -- Elphion (talk) 18:04, 2 November 2016 (UTC)[reply]
Both the American Heritage Dictionary and the Oxford English Dictionary rate fairly high as Reliable Sources, and both give both pronunciations. You're entitled to your opinion, of course, but it remains POV. -- Elphion (talk) 01:28, 5 February 2013 (UTC)[reply]
The creator, the individual who gave the invention a name, trumps all third-party sources. Otherwise, there would be no purpose for naming rights. We do not consider "Leego" a valid pronunciation either, even though it would be grammatically correct. RvLeshrac (talk) 12:25, 22 May 2013 (UTC)[reply]
The creator may be an authority on graphic file formats, but he is obviously not an authority on pronounciation. His opinion trumps nothing. El Mariachi (talk) 22:53, 5 November 2013 (UTC)[reply]
GIF has moved way out of the realm of brand names, like kleenex or aspirin. If common folk commonly use the G sound and dictionaries say it's alright, that's English for you. Like the chief editor at Oxford says to the BBC, same goes for "quark", which was intended as "quork". That's a reliable source (or two) saying the creator does not trump anyone. InedibleHulk (talk) 17:26, 22 May 2013 (UTC)[reply]
WP is not in the business of prescribing pronunciation. We can report that Wilhite deliberately chose the soft 'g' for the original pronunciation, we can report that there is wide-spread disagreement over the "correct" pronunciation, we can even report that the White House sets a standard for its staff (it does not have the authority to promulgate an "official" pronunciation for the rest of us). But we cannot try to adjudicate this tempest in a teapot -- WP:NPOV dictates clearly that we must acknowledge that both pronunciations are widely used, and that both are sanctioned by authoritative dictionaries. (The dictionaries are not erroneous, despite what Wilhite says; they are simply reporting usage.) The referenced blog entry claiming that "most" techies use the hard 'g' offers no more than anecdotal evidence ("everyone I know . . ."). This is the height of POV and should not be accepted here. -- Elphion (talk) 13:23, 22 May 2013 (UTC)[reply]
The only mistake would be to remove one pronunciation or promote one over the other. Both are used, both have their own history, this article mentons that without taking sides. GDallimore (Talk) 15:17, 22 May 2013 (UTC)[reply]

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)[reply]

It appears that you have a conflict of interests due to your history with compuserve and should therefore avoid editing this article. Please make sure that edits are made on the basis of reliable sources, which undisputedly support the idea that both pronunciations are in common usage whatever the desires of the creators, and not your own personal interests. Thank you. GDallimore (Talk) 20:00, 23 May 2013 (UTC)[reply]
My take on all this is that the original authors were just a little bit crazed after one too many nights on the Jolt Cola and maybe shouldn't be listened to so seriously, especially as the reasoning behind it is one of a really bad joke that arose out of a near-but-not-quite coincidence spotted by someone who didn't realise that puns work just as well if not better when they slightly alter a well worn phrase rather than copying it direct. "Graphic" is not pronounced as Jraffic. If the acronym was Giraffe Image Format, that would make sense at least. Also, although it's not anywhere as commonly used, there is an actual JIF format (it's part of the JPG standard, which was dreamt up at about the same time and totally independently). Just to be certain, it would probably be clearest to save the "soft G" sound for THAT... Besides, in language, what's considered correct is usually the majority view, and the only person I ever heard say "JIF" like that was taking the mickey.
PS, "teach the controversy!" ;) ... as basically everyone except the coders and a few hardline pedants say it as they see it (hard G), not having been told how to pronounce it or its history and thus using regular English rules (admit it - if no-one told you that Gin was soft-G, you'd say it the other way)... there needs to be the note that it's commonly "mis"pronounced despite the official proclamation, for the purposes of clearing up potential confusion if nothing else. Say in 50 years time someone uses a surviving copy of this to interpret a similarly old video about early C21 web culture and can't figure out why everyone's saying Guh-Iff on there when this page clearly says it's to be pronounced Je-Iff... 193.63.174.211 (talk) 12:01, 11 October 2013 (UTC)[reply]
I don't know what went on in the Compuserve development tank, but it's clear that they did pronounce the acronym with a soft G ("JIF"). I don't know how "most" people would pronounce "gin" upon first encountering it, but I would have used the standard rule (soft G before E and I) and said "jin", on analogy with gem. I don't know which pronunciation of GIF is more widespread, or how it breaks down across geographical or professional lines; in my experience "JIF" is the clear winner. Acronyms acquire their own pronunciation; their letters don't always reflect the pronunciation of the corresponding letters in the abbreviated phrase (consider the U in FUBAR). The point is that we have resources (dictionaries) who investigate how the world pronounces things, and in this case, both British and American dictionaries report that both pronunciations are used -- and that's what the article reports. The article is completely agnostic about which is "correct". (And "correctness" -- however defined -- is often not the majority usage: Received Pronunciation, e.g., is used by only a small proportion of the British population.) -- Elphion (talk) 15:53, 11 October 2013 (UTC)[reply]
I was a member of the Compuserve Graphics Forum at the time the GIF format was being developed. Despite Steve Wilhite's preference/advocacy, It was documented within the forum, and well-understood by developers at the time, that it was pronounced with a hard G, as in Graphics Interchange Format, not a soft g, as in Jraphics.

Grafman (talk) 20:30, 14 March 2016 (UTC)[reply]

Lossless?

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)[reply]

When reading the article it appears to me the compression method is lossless - but that by within sub-blocks an image is converted into a 256 colours palette before compressing. So the loss is more in the preprocessing (going to 256 colours) than the actual compression. Under true colours it is explained how a GIF file could deal with more than 256 colour -that is by specifying blocks consisting of 256 pixels and than define the palette for each pixel individually. I have never seen this used in practice (and doing so would probably result in inflation instead of compression of the original image). I hope I understood correctly as I am no expert on this. Arnoutf (talk) 18:58, 25 October 2016 (UTC)[reply]
GIF compression is lossless since it operates only on areas with a max of 256 colors. If the image you're trying to store as a GIF has more than 256 colors, then you have to break it up into sub-images of max 256 colors before hitting it with GIF compression. (16x16 squares work, but other possibilities exist.) But if you do that, the decompressed image will automatically have the same data as the original. Added: (If the image has more than 256 colors, GIF is not the obvious choice anyway: other lossless formats can handle more than 256 colors more conveniently.) -- Elphion (talk) 21:11, 25 October 2016 (UTC)[reply]

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.

checkY An editor has reviewed this edit and fixed any errors that were found.

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 14:27, 9 October 2017 (UTC)[reply]

the meaning of "GIF" has broadened

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)[reply]

Wikipedia is not a dictionary, and definitely not Urban Dictionary. —DIYeditor (talk) 01:47, 24 July 2018 (UTC)[reply]

Proposed merge with Video alternative to GIF

Video alternative to GIF does not currently merit a whole separate article. Ethanpet113 (talk) 01:49, 13 January 2019 (UTC)[reply]

Support/Merge I was actually searched GIF, but I was really looking for the stub article Video alternative to GIF. ―Matthew J. Long -Talk- 04:54, 17 January 2019 (UTC)[reply]
Support I'm kinda split on this one. I agree that a stub doesn't really work for Video alternative to GIF, but not really sure how it would be included in the article. I originally was going to stay neutral, however, the more I think about it when writing this reply, the more I support this merger. GeekInParadise (talk) 17:53, 26 March 2019 (UTC)[reply]
User Since video is an alternative to all image-based animation formats like APNG, animated WebP and others, I actually think that it would be better to rename the article to Video alternative to animated images and link to it from GIF, APNG and wherever else needed. --Fernando Trebien (talk) 20:22, 24 June 2019 (UTC)[reply]
User For the reason that the article on Video alternative to GIF, in its current state, is short, I would suggest either merging the two articles and having the Video alternative to GIF page redirect to GIF; adding a very brief introduction on video alternatives to Graphics Interchange Format (under which, "see full article here" would link to the full page); or mentioning alternatives to the format in the See Also section. Among those three options, I would personally go with the introduction with the "see full article here" under the heading. ~Osvaldo Jørgensen Talk-Page 01:24, 12 February 2020 (UTC)[reply]
Support the original proposal as stated; no need for a stand-along stub given that GIF can accommodate it. Having a brief summary remain at Video alternative to GIF is inefficient, as it duplicaties the first sentence or two on the target page section. An appropriate section would be to create a new section within GIF#Animated GIF, which could then also incorporate the brief GIF#GIFs with sound single sentence. Klbrain (talk) 13:51, 12 February 2020 (UTC)[reply]
Comment Suggest deleting "GIF with Sound" section (which is misleading: there are no GIFs with sound), incorporating that material and Video alternative to GIF in a new subsection "Video alternatives" under "Alternatives to GIF". -- Elphion (talk) 18:05, 12 February 2020 (UTC)[reply]
  checkY Merger complete. Klbrain (talk) 13:48, 10 April 2020 (UTC)[reply]

Removing the "GIFs with sound" section

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)[reply]

Section "History" / first paragraph: wrong word?

@ 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)[reply]

@Steue I agree that the "that" makes the sentence hard to read, so I simplified that sentence. Your chronological rewrite, however, obscures the important point: the earlier wording has the right elements in the right order. -- Elphion (talk) 14:53, 28 October 2020 (UTC)[reply]
@Elphion: Thank you for clarification. At least now the content is clear and understandable.
However, now the words are no longer links, as they were before.
I, personally, prefer to put facts as chronologic as possible and in short sentences, because this makes everything easier to grasp, especially for all the many readers for whom English is not their mothertongue.
Just to understand why you answered although I wrote to U:Metaeducation, and, of course, only if you would like to disclose this: Are you the author of this paragraph and are using a different username or is it, that you know the facts good enough to tell how the sentence has to be?
Please ping me. Steue (talk) 03:08, 30 October 2020 (UTC)[reply]
I responded because I watch this page and you pointed out a passage that needs clarification. -- Elphion (talk) 03:33, 30 October 2020 (UTC)[reply]

Dictionaries, years of the editions?

In: GIF#Pronunciation_of_GIF / second paragraph there are mentioned a lot of dictionaries.
I would appreciate, if:

  1. at each dictionary there would be mentioned the year and
  2. if the dictionaries would be sorted by year.

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)[reply]

@Steue — This would be overkill, bordering on WP:OR. The dictionary references serve to show that both pronunciations are current, and that's what matters. If you have a WP:RS tracing the evolution of the usage, that would be an appropriate addition. But it is not our job to dictate (or even to suggest) "correct" usage. -- Elphion (talk) 14:58, 28 October 2020 (UTC)[reply]
@Elphion, it seems that you misinterpreted my intention. I do not intend to dictate or suggest anything. My intention is to find out whether there was a developement of some kind or not, and to get this made visible easily. And in case there was, it may be interesting to someone else als well.
If you, personally, are satisfied with what there is in this article, that is your decision; and I do not intend to evaluate or invalidate this. But you have no right to force your limitation onto all the other readers and to barr more information.
Please ping me. Steue (talk) 02:19, 30 October 2020 (UTC)[reply]
No change in my response: a reliable source for this would be fair game. -- Elphion (talk) 03:31, 30 October 2020 (UTC)[reply]

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 (talkcontribs) 10:35, 19 March 2021 (UTC)[reply]