This is the
talk page for discussing improvements to the
GIF article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
Archives:
1Auto-archiving period: 90 days
![]() |
![]() | This ![]() It is of interest to the following WikiProjects: | |||||||||||||||||||||||||||||||||
|
![]() | The contents of the Video alternative to GIF page were merged into GIF on 10 April 2020. For the contribution history and old versions of the redirected page, please see its history; for the discussion at that location, see its talk page. |
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.
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:
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)
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)
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)
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:
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
"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."
"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"
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?"
"I'm not sure why you say a full color GIF cannot have 'partial transparency'"
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)
Hi, I'd like to propose to change the respelling from "JIF" to "DJIF". This will avoid confusion with "dʒ" and "ʒ". { userpage! | talk!} 22:12, 28 November 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)
> 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)
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)
This is the
talk page for discussing improvements to the
GIF article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
Archives:
1Auto-archiving period: 90 days
![]() |
![]() | This ![]() It is of interest to the following WikiProjects: | |||||||||||||||||||||||||||||||||
|
![]() | The contents of the Video alternative to GIF page were merged into GIF on 10 April 2020. For the contribution history and old versions of the redirected page, please see its history; for the discussion at that location, see its talk page. |
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.
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:
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)
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)
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)
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:
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
"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."
"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"
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?"
"I'm not sure why you say a full color GIF cannot have 'partial transparency'"
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)
Hi, I'd like to propose to change the respelling from "JIF" to "DJIF". This will avoid confusion with "dʒ" and "ʒ". { userpage! | talk!} 22:12, 28 November 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)
> 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)
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)