जीआईएफ

ग्राफिक्स इंटरचेंज फॉर्मेट (जीआईएफ;  या  , #Pronomy) एक  रेखापुंज ग्राफिक्स  छवि फ़ाइल स्वरूप है जिसे अमेरिकी कंप्यूटर वैज्ञानिक  स्टीव विल्हाइट  के नेतृत्व में ऑनलाइन सेवा प्रदाता  CompuServe  की एक टीम द्वारा विकसित किया गया था और 15 जून 1987 को जारी किया गया था। अनुप्रयोगों और ऑपरेटिंग सिस्टम के बीच व्यापक समर्थन और पोर्टेबिलिटी के कारण यह  वर्ल्ड वाइड वेब  पर व्यापक उपयोग में है।

प्रारूप प्रत्येक छवि के लिए 8-बिट रंग  तक का समर्थन करता है, जिससे एक छवि को  24-बिट रंग -बिट  आरजीबी रंग मॉडल  से चुने गए 256 अलग-अलग रंगों के अपने स्वयं के  पैलेट (कंप्यूटिंग)  को संदर्भित करने की अनुमति मिलती है। यह  एनीमेशन  का भी समर्थन करता है और प्रत्येक फ्रेम के लिए 256 रंगों के एक अलग पैलेट की अनुमति देता है। ये पैलेट सीमाएं रंगीन तस्वीरों और अन्य  छवि ढाल  को पुन: पेश करने के लिए जीआईएफ को कम उपयुक्त बनाती हैं, लेकिन रंग के ठोस क्षेत्रों वाले ग्राफिक्स या लोगो जैसी सरल छवियों के लिए उपयुक्त हैं।

दृश्य गुणवत्ता को खराब किए बिना फ़ाइल आकार को कम करने के लिए GIF छवियों को Lempel-Ziv-Welch (LZW) दोषरहित डेटा संपीड़न  तकनीक का उपयोग करके संपीड़ित किया जाता है।

इतिहास
CompuServe ने 15 जून 1987 को अपने फ़ाइल डाउनलोडिंग क्षेत्रों के लिए एक रंगीन छवि प्रारूप प्रदान करने के लिए GIF पेश किया। इसने उनके पहले के रन-लेंथ एन्कोडिंग  प्रारूप को बदल दिया, जो केवल काले और सफेद रंग का था। जीआईएफ लोकप्रिय हो गया क्योंकि इसमें लेम्पेल-ज़िव-वेल्च डेटा संपीड़न का इस्तेमाल किया गया था। चूंकि यह  पीसीएक्स  और  मैकपेंट  द्वारा उपयोग की जाने वाली रन-लेंथ एन्कोडिंग की तुलना में अधिक कुशल था, धीमी  मोडम  के साथ भी काफी बड़ी छवियों को यथोचित तेज़ी से डाउनलोड किया जा सकता था।

GIF के मूल संस्करण को 87a कहा जाता था। यह संस्करण पहले से ही एक स्ट्रीम में कई छवियों का समर्थन करता है।

1989 में, CompuServe ने 89a नामक एक उन्नत संस्करण जारी किया, यह संस्करण जोड़ा गया:
 * एनीमेशन देरी के लिए समर्थन
 * पारदर्शी पृष्ठभूमि रंग
 * एप्लिकेशन-विशिष्ट मेटाडेटा का संग्रहण
 * टेक्स्ट लेबल को टेक्स्ट के रूप में अनुमति देना (उन्हें ग्राफिकल डेटा में एम्बेड नहीं करना)। चूंकि प्रदर्शन फोंट पर थोड़ा नियंत्रण होता है, हालांकि, इस सुविधा का उपयोग शायद ही कभी किया जाता है।

फ़ाइल के पहले छह बाइट ्स ( जादू संख्या (प्रोग्रामिंग)  या हस्ताक्षर) को देखकर दो संस्करणों को अलग किया जा सकता है, जिसे  ASCII  के रूप में व्याख्या किए जाने पर क्रमशः GIF87a या GIF89a पढ़ा जाता है।

CompuServe ने कई कंप्यूटरों के लिए डाउनलोड करने योग्य रूपांतरण सुविधाएं प्रदान करके GIF को अपनाने के लिए प्रोत्साहित किया। उदाहरण के लिए, दिसंबर 1987 तक, एक Apple IIGS  उपयोगकर्ता अटारी ST या  कमोडोर 64  पर बनाए गए चित्रों को देख सकता था। जीआईएफ उन पहले दो छवि प्रारूपों में से एक था जो आमतौर पर वेब साइटों पर उपयोग किए जाते थे, दूसरा ब्लैक-एंड-व्हाइट  एक्सबीएम  था। सितंबर 1995 में नेटस्केप (वेब ​​​​ब्राउज़र)#रिलीज़ इतिहास 2.0 में #एनिमेटेड GIF जोड़ा गया।

जबकि GIF को CompuServe द्वारा विकसित किया गया था, इसने 1985 में Unisys  द्वारा पेटेंट किए गए Lempel-Ziv-Welch (LZW) दोषरहित डेटा संपीड़न एल्गोरिदम का उपयोग किया। 1994 में Unisys और CompuServe के बीच लाइसेंसिंग समझौते पर विवाद ने  पोर्टेबल नेटवर्क ग्राफ़िक्स  (PNG) के विकास को प्रेरित किया। मानक। 2004 में, GIF के लिए उपयोग किए जाने वाले मालिकाना संपीड़न से संबंधित सभी पेटेंट समाप्त हो गए।

नियंत्रण डेटा के साथ एक फ़ाइल में एकाधिक छवियों को संग्रहीत करने की सुविधा का उपयोग वेब पर बड़े पैमाने पर सरल कंप्यूटर एनीमेशन  बनाने के लिए किया जाता है।

वैकल्पिक इंटरलेसिंग (बिटमैप्स)  सुविधा, जो छवि स्कैन लाइनों को इस तरह से क्रम से संग्रहीत करती है कि आंशिक रूप से डाउनलोड की गई छवि भी कुछ पहचानने योग्य थी, ने भी GIF की लोकप्रियता में मदद की, एक उपयोगकर्ता के रूप में डाउनलोड को रद्द कर सकता है यदि यह वह नहीं था जो आवश्यक था।

मई 2015 में फेसबुक  ने GIF के लिए समर्थन जोड़ा।  जनवरी 2018 में इंस्टाग्राम ने स्टोरी मोड में GIF स्टिकर भी जोड़े।

शब्दावली
संज्ञा के रूप में, GIF शब्द कई शब्दकोशों के नए संस्करणों में पाया जाता है। 2012 में,  ऑक्सफोर्ड यूनिवरसिटि प्रेस  के अमेरिकी विंग ने GIF को एक  क्रिया  के रूप में भी मान्यता दी, जिसका अर्थ GIF फ़ाइल बनाना है, क्योंकि GIFing  ग्रीष्मकालीन ओलंपिक  से दृश्यों को साझा करने का एक आदर्श माध्यम था। प्रेस के कोशकारों ने इसे वर्ष का अपना शब्द बताया, यह कहते हुए कि जीआईएफ अनुसंधान और पत्रकारिता सहित गंभीर अनुप्रयोगों के साथ एक उपकरण के रूप में विकसित हुआ है।

उच्चारण
जीआईएफ के पहले अक्षर का उच्चारण 1990 के दशक से विवादित रहा है। अंग्रेजी में सबसे आम उच्चारण हैं (जिन के रूप में वायस्ड पोस्टएल्वियोलर एफ्रिकेट के साथ) और  (उपहार के रूप में वॉइस्ड वेलर प्लोसिव के साथ), पत्र जी द्वारा दर्शाए गए  स्वनिम  में भिन्न। प्रारूप के रचनाकारों ने परिवर्णी शब्द जीआईएफ का उच्चारण किया वॉइस्ड पोस्टएल्वियोलर एफ़्रीकेट के साथ, विल्हाइट ने कहा कि वह उच्चारण के लिए अमेरिकी  मूंगफली का मक्खन  ब्रांड Jif (मूंगफली का मक्खन) को जानबूझकर प्रतिध्वनित करने का इरादा रखता है, और CompuServe के कर्मचारी अक्सर जिफ़ के टेलीविजन विज्ञापनों का एक स्पूफ चुनिंदा डेवलपर्स GIF चुनते हैं। हालाँकि, इस शब्द का व्यापक रूप से उच्चारण किया जाता है, वॉयस वेलर स्टॉप के साथ, और चुनावों ने आम तौर पर दिखाया है कि यह कठिन जी उच्चारण अधिक प्रचलित है। डिक्शनरी.कॉम दोनों उच्चारणों को उद्धृत करता है, संकेत करता है प्राथमिक उच्चारण के रूप में, जबकि कैम्ब्रिज डिक्शनरी ऑफ अमेरिकन इंग्लिश केवल हार्ड-जी उच्चारण प्रदान करता है। मेरियम-वेबस्टर का कॉलेजिएट डिक्शनरी और ऑक्सफोर्ड डिक्शनरी दोनों उच्चारणों का हवाला देते हैं, लेकिन कठिन जी को पहले रखें:. द न्यू ऑक्सफोर्ड अमेरिकन डिक्शनरी  ने ही दिया  इसके दूसरे संस्करण में लेकिन इसे अपडेट किया  तीसरे संस्करण में। उच्चारण पर असहमति के कारण इंटरनेट पर गरमागरम बहस छिड़ गई है। 2013 वेबी अवार्ड्स  समारोह में लाइफटाइम अचीवमेंट अवार्ड प्राप्त करने के अवसर पर, विल्हाइट ने सार्वजनिक रूप से हार्ड-जी उच्चारण को अस्वीकार कर दिया; उनके भाषण के कारण  ट्विटर  पर 17,000 से अधिक पोस्ट और दर्जनों समाचार लेख बने।  सफेद घर  और टीवी कार्यक्रम जॉपार्डी! 2013 में भी बहस में शामिल हुए। फरवरी 2020 में, Jif ब्रांड के मालिक, J.M. Smucker कंपनी ने एनिमेटेड इमेज डेटाबेस और सर्च इंजन Giphy  के साथ पार्टनरशिप करके एक सीमित-संस्करण Jif बनाम GIF (#JIFvsGIF के रूप में  हैशटैग  किया गया) पीनट बटर का जार जारी किया, जिसमें एक लेबल था सॉफ्ट-जी उच्चारण को विशेष रूप से पीनट बटर को संदर्भित करने के लिए, और जीआईएफ को हार्ड-जी उच्चारण के साथ विशेष रूप से उच्चारित करने के लिए विनोदी रूप से घोषित करना।

उपयोग
जीआईएफ लोगो जैसे रंगों की सीमित संख्या के साथ तीक्ष्ण धार वाली रेखा कला के लिए उपयुक्त हैं। यह प्रारूप के दोषरहित संपीड़न का लाभ उठाता है, जो अच्छी तरह से परिभाषित किनारों के साथ समान रंग के समतल क्षेत्रों का समर्थन करता है। उनका उपयोग गेम्स के लिए लो-कलर स्प्राइट (कंप्यूटर ग्राफिक्स)  डेटा को स्टोर करने के लिए भी किया जा सकता है। जीआईएफ का उपयोग छोटे एनिमेशन और कम-रिज़ॉल्यूशन वीडियो क्लिप के लिए किया जा सकता है, या शब्दों का उपयोग करने के बजाय भावनाओं और भावनाओं को व्यक्त करने के लिए उपयोग किए जाने वाले ऑनलाइन मैसेजिंग में प्रतिक्रियाओं के रूप में किया जा सकता है। वे Tumblr जैसे सोशल मीडिया प्लेटफॉर्म पर लोकप्रिय हैं, फेसबुक और ट्विटर।

फ़ाइल प्रारूप
संकल्पनात्मक रूप से, एक जीआईएफ फ़ाइल एक निश्चित आकार के ग्राफिकल क्षेत्र (तार्किक स्क्रीन) का वर्णन करती है जो शून्य या अधिक छवियों से भरा हुआ है। कई जीआईएफ फाइलों में एक ही छवि होती है जो पूरी तार्किक स्क्रीन भरती है। अन्य तार्किक स्क्रीन को अलग-अलग उप-छवियों में विभाजित करते हैं। छवियां एनिमेटेड जीआईएफ फ़ाइल में एनीमेशन फ्रेम के रूप में भी काम कर सकती हैं, लेकिन फिर से इन्हें पूरी लॉजिकल स्क्रीन भरने की जरूरत नहीं है।

जीआईएफ फाइलें एक निश्चित-लंबाई वाले हेडर (जीआईएफ87ए या जीआईएफ89ए) से शुरू होती हैं, जो संस्करण देती हैं, इसके बाद एक निश्चित-लंबाई लॉजिकल स्क्रीन डिस्क्रिप्टर पिक्सेल आयाम और लॉजिकल स्क्रीन की अन्य विशेषताएं देती हैं। स्क्रीन डिस्क्रिप्टर ग्लोबल कलर टेबल (जीसीटी) की उपस्थिति और आकार को भी निर्दिष्ट कर सकता है, जो मौजूद होने पर आगे आता है।

इसके बाद, फ़ाइल को खंडों में विभाजित किया जाता है, प्रत्येक को 1-बाइट प्रहरी द्वारा प्रस्तुत किया जाता है:
 * एक छवि (0x2C द्वारा प्रस्तुत, एक ASCII अल्पविराम ',')
 * एक एक्सटेंशन ब्लॉक (0x21 द्वारा पेश किया गया, एक ASCII विस्मयादिबोधक बिंदु '!')
 * ट्रेलर (मूल्य 0x3B का एक सिंगल बाइट, एक ASCII अर्धविराम ';'), जो फ़ाइल का अंतिम बाइट होना चाहिए।

एक छवि एक निश्चित-लंबाई छवि डिस्क्रिप्टर से शुरू होती है, जो स्थानीय रंग तालिका की उपस्थिति और आकार निर्दिष्ट कर सकती है (जो मौजूद होने पर आगे आती है)। छवि डेटा इस प्रकार है: एक बाइट अनएन्कोडेड प्रतीकों की बिट चौड़ाई (जो कि कम से कम 2 बिट चौड़ा होना चाहिए, द्वि-रंग छवियों के लिए भी होना चाहिए), इसके बाद उप-ब्लॉकों की एक लिंक की गई सूची जिसमें LZW-एन्कोडेड डेटा शामिल है।

एक्सटेंशन ब्लॉक (ब्लॉक जो 87a परिभाषा को पहले से ही 87a कल्पना में परिभाषित तंत्र के माध्यम से विस्तारित करते हैं) में प्रहरी, एक्सटेंशन के प्रकार को निर्दिष्ट करने वाला एक अतिरिक्त बाइट और एक्सटेंशन डेटा के साथ उप-ब्लॉकों की एक लिंक्ड सूची शामिल है। एक्सटेंशन ब्लॉक जो एक छवि को संशोधित करते हैं (जैसे ग्राफिक कंट्रोल एक्सटेंशन जो वैकल्पिक एनीमेशन विलंब समय और वैकल्पिक पारदर्शी पृष्ठभूमि रंग निर्दिष्ट करता है) को तुरंत उस छवि के साथ सेगमेंट से पहले होना चाहिए जिसका वे संदर्भ देते हैं।

छवि डेटा और एक्सटेंशन ब्लॉक द्वारा उपयोग की जाने वाली लिंक्ड सूचियों में उप-ब्लॉकों की श्रृंखला शामिल होती है, प्रत्येक उप-ब्लॉक एक बाइट से शुरू होता है जो उप-ब्लॉक (1 से 255) में बाद के डेटा बाइट्स की संख्या देता है। उप-ब्लॉकों की श्रृंखला एक खाली उप-ब्लॉक (एक 0 बाइट) द्वारा समाप्त होती है।

यह संरचना फ़ाइल को पार्स करने की अनुमति देती है, भले ही सभी भाग समझ में न आए हों। 87a चिह्नित GIF में एक्सटेंशन ब्लॉक हो सकते हैं; आशय यह है कि एक डिकोडर फ़ाइल को एक्सटेंशन में शामिल सुविधाओं के बिना पढ़ और प्रदर्शित कर सकता है जिसे वह समझ नहीं पाता है।

फ़ाइल प्रारूप का पूरा विवरण GIF विनिर्देशन में शामिल है।

पैलेट्स
जीआईएफ पैलेट-आधारित है: फ़ाइल में एक छवि (एक फ्रेम) में उपयोग किए जाने वाले रंगों में उनके आरजीबी  मान एक पैलेट (कंप्यूटिंग) में परिभाषित होते हैं जो 256 प्रविष्टियों तक रख सकते हैं, और छवि के लिए डेटा उनके द्वारा रंगों को संदर्भित करता है पैलेट तालिका में सूचकांक (0-255)। पैलेट में रंग परिभाषाएँ लाखों रंगों के रंग स्थान से खींची जा सकती हैं (224 शेड्स, प्रत्येक प्राथमिक के लिए 8 बिट्स), लेकिन एक फ्रेम द्वारा उपयोग किए जा सकने वाले रंगों की अधिकतम संख्या 256 है। GIF विकसित होने पर यह सीमा उचित लगती थी क्योंकि कुछ लोग एक साथ अधिक रंगों को प्रदर्शित करने के लिए हार्डवेयर का खर्च उठा सकते थे। सरल ग्राफिक्स, रेखा चित्र, कार्टून और ग्रे-स्केल फ़ोटोग्राफ़ को आमतौर पर 256 से कम रंगों की आवश्यकता होती है।

प्रत्येक फ़्रेम एक इंडेक्स को एक पारदर्शी पृष्ठभूमि रंग के रूप में निर्दिष्ट कर सकता है: इस इंडेक्स को असाइन किया गया कोई भी पिक्सेल पृष्ठभूमि से उसी स्थिति में पिक्सेल का रंग लेता है, जो एनीमेशन के पिछले फ्रेम द्वारा निर्धारित किया जा सकता है।

कई तकनीकों, जिन्हें सामूहिक रूप से डाइथरिंग कहा जाता है, को दो या दो से अधिक रंगों के पिक्सेल का उपयोग करके रंगों के बीच में अनुमानित करने के लिए एक छोटे रंग पैलेट के साथ रंगों की एक विस्तृत श्रृंखला का अनुमान लगाने के लिए विकसित किया गया है। ये तकनीकें लगभग गहरे रंग के रिज़ॉल्यूशन के लिए स्थानिक रिज़ॉल्यूशन का त्याग करती हैं। जबकि जीआईएफ विनिर्देश का हिस्सा नहीं है, बाद में जीआईएफ छवियों के रूप में एन्कोड किए गए चित्रों में डिथरिंग का उपयोग किया जा सकता है। यह अक्सर जीआईएफ छवियों के लिए एक आदर्श समाधान नहीं है, क्योंकि स्थानिक रिज़ॉल्यूशन का नुकसान आम तौर पर स्क्रीन पर एक छवि अस्पष्ट दिखता है, और क्योंकि जीआईएफ के मुख्य उद्देश्य के खिलाफ काम करते हुए डिथरिंग पैटर्न अक्सर छवि डेटा की संपीड़ितता में हस्तक्षेप करते हैं।

ग्राफिकल वेब ब्राउज़र के शुरुआती दिनों में, 8-बिट बफ़र्स (केवल 256 रंगों की अनुमति) वाले ग्राफ़िक्स कार्ड सामान्य थे और वेब-सुरक्षित रंगों का उपयोग करके GIF छवियां बनाना काफी सामान्य था। इसने पूर्वानुमेय प्रदर्शन सुनिश्चित किया, लेकिन रंगों की पसंद को गंभीर रूप से सीमित कर दिया। जब 24-बिट रंग आदर्श बन गया, तो इसके बजाय पैलेट को अलग-अलग छवियों के लिए इष्टतम रंगों से भरा जा सकता था।

छोटी छवियों के लिए एक छोटी रंग तालिका पर्याप्त हो सकती है, और रंग तालिका को छोटा रखने से फ़ाइल को तेज़ी से डाउनलोड किया जा सकता है। 87a और 89a दोनों विनिर्देश 2 की रंग तालिका की अनुमति देते हैं1 से 8 तक किसी भी n के लिए n रंग। अधिकांश ग्राफ़िक्स एप्लिकेशन इनमें से किसी भी तालिका आकार के साथ GIF छवियों को पढ़ेंगे और प्रदर्शित करेंगे; लेकिन कुछ चित्र बनाते समय सभी आकारों का समर्थन नहीं करते हैं। 2, 16 और 256 रंगों की तालिकाएँ व्यापक रूप से समर्थित हैं।

असली रंग
हालांकि जीआईएफ का इस्तेमाल कलर डेप्थ#ट्रू कलर (24-बिट) इमेज के लिए लगभग कभी नहीं किया जाता है, ऐसा करना संभव है। एक जीआईएफ छवि में कई छवि ब्लॉक शामिल हो सकते हैं, जिनमें से प्रत्येक का अपना 256-रंग पैलेट हो सकता है, और पूर्ण छवि बनाने के लिए ब्लॉक को टाइल किया जा सकता है। वैकल्पिक रूप से, GIF89a विनिर्देश ने एक पारदर्शी रंग का विचार पेश किया जहां प्रत्येक छवि ब्लॉक में 255 दृश्यमान रंगों के साथ-साथ एक पारदर्शी रंग का अपना पैलेट शामिल हो सकता है। ऊपर की परतों के पारदर्शी भागों के माध्यम से दिखाई देने वाली प्रत्येक परत के दृश्य भाग के साथ छवि ब्लॉकों को लेयर करके एक पूर्ण छवि बनाई जा सकती है। GIF के रूप में पूर्ण-रंग वाली छवि प्रस्तुत करने के लिए, मूल छवि को छोटे क्षेत्रों में विभाजित किया जाना चाहिए जिसमें 255 या 256 से अधिक विभिन्न रंग न हों। इन क्षेत्रों में से प्रत्येक को तब अपने स्वयं के स्थानीय पैलेट के साथ एक अलग छवि ब्लॉक के रूप में संग्रहीत किया जाता है और जब छवि ब्लॉक एक साथ प्रदर्शित होते हैं (या तो टाइलिंग द्वारा या आंशिक रूप से पारदर्शी छवि ब्लॉकों को परत करके), पूर्ण, पूर्ण-रंग वाली छवि दिखाई देती है। उदाहरण के लिए, किसी छवि को 16 गुणा 16 पिक्सेल (कुल 256 पिक्सेल) की टाइलों में तोड़ना सुनिश्चित करता है कि किसी भी टाइल में 256 रंगों की स्थानीय पैलेट सीमा से अधिक नहीं है, हालाँकि बड़ी टाइलों का उपयोग किया जा सकता है और समान रंगों का विलय हो जाता है जिसके परिणामस्वरूप रंग में कुछ कमी आती है जानकारी।

चूँकि प्रत्येक छवि ब्लॉक की अपनी स्थानीय रंग तालिका हो सकती है, एक GIF फ़ाइल जिसमें कई छवि ब्लॉक होते हैं, बहुत बड़ी हो सकती है, जो पूर्ण-रंग वाले GIF की उपयोगिता को सीमित करती है। इसके अतिरिक्त, सभी जीआईएफ रेंडरिंग प्रोग्राम टाइल वाली या स्तरित छवियों को सही ढंग से संभाल नहीं पाते हैं। कई रेंडरिंग प्रोग्राम टाइल्स या लेयर्स को एनीमेशन फ्रेम के रूप में समझते हैं और उन्हें एनीमेशन के रूप में अनुक्रम में प्रदर्शित करते हैं अधिकांश वेब ब्राउज़र स्वचालित रूप से 0.1 सेकंड या उससे अधिक के विलंब समय के साथ फ़्रेम प्रदर्शित करते हैं।

उदाहरण जीआईएफ फ़ाइल
ध्यान दें कि निम्नलिखित तालिकाओं में हेक्स संख्याएं endianness  | लिटिल-एंडियन बाइट क्रम में हैं, जैसा कि प्रारूप विनिर्देश निर्धारित करता है।

छवि कोडिंग
छवि पिक्सेल डेटा, ऊपर बाईं ओर से क्षैतिज रूप से स्कैन किया जाता है, लेम्पेल-ज़िव-वेल्च द्वारा उन कोडों में परिवर्तित किया जाता है जिन्हें फ़ाइल में संग्रहीत करने के लिए बाइट्स में मैप किया जाता है। पिक्सेल कोड आमतौर पर बाइट्स के 8-बिट आकार से मेल नहीं खाते हैं, इसलिए कोड को लिट्ल-एंडियन योजना द्वारा बाइट्स में पैक किया जाता है: पहले कोड का कम से कम महत्वपूर्ण बिट पहले बाइट के कम से कम महत्वपूर्ण बिट में संग्रहीत होता है।, कोड के उच्च क्रम बिट्स को बाइट के उच्च क्रम बिट्स में, आवश्यकतानुसार अगले बाइट के निम्न क्रम बिट्स में फैलाना। प्रत्येक बाद के कोड को पहले से उपयोग नहीं किए गए कम से कम महत्वपूर्ण बिट से शुरू किया जाता है।

यह बाइट स्ट्रीम फ़ाइल में उप-ब्लॉकों की एक श्रृंखला के रूप में संग्रहीत है। प्रत्येक उप-ब्लॉक की अधिकतम लंबाई 255 बाइट्स होती है और एक बाइट के साथ उपसर्ग होता है जो उप-ब्लॉक में डेटा बाइट्स की संख्या को दर्शाता है। उप-ब्लॉकों की श्रृंखला एक खाली उप-ब्लॉक (एक एकल 0 बाइट, 0 डेटा बाइट्स वाले उप-ब्लॉक को इंगित करता है) द्वारा समाप्त की जाती है।

9-बिट कोड और बाइट्स के बीच प्रतिवर्ती मानचित्रण के ऊपर नमूना छवि के लिए नीचे दिखाया गया है।

एक मामूली संपीड़न स्पष्ट है: प्रारंभ में 15 बाइट्स द्वारा परिभाषित पिक्सेल रंग नियंत्रण कोड सहित 12 कोड बाइट्स द्वारा सटीक रूप से दर्शाए जाते हैं। 9-बिट कोड बनाने वाली एन्कोडिंग प्रक्रिया नीचे दिखाई गई है। एक स्थानीय स्ट्रिंग पैलेट से पिक्सेल रंग संख्याएं जमा करती है, जब तक कि स्थानीय स्ट्रिंग को कोड तालिका में पाया जा सकता है, तब तक कोई आउटपुट क्रिया नहीं होती है। पहले दो पिक्सेल का विशेष उपचार होता है जो तार के जोड़ से तालिका के प्रारंभिक आकार से बढ़ने से पहले आते हैं। प्रत्येक आउटपुट कोड के बाद, स्थानीय स्ट्रिंग को नवीनतम पिक्सेल रंग में प्रारंभ किया जाता है (जो आउटपुट कोड में शामिल नहीं किया जा सकता)।

तालिका 9-बिट स्ट्रिंग --> कोड कोड एक्शन #0 | 000h 9-बिट कोड की रूट तालिका प्रारंभ करें पैलेट | : रंग | : #255 | 0FFh सीएलआर | 100 ह अंत | 101h | 100h साफ़ करें पिक्सेल स्थानीय | कलर पैलेट स्ट्रिंग | काला #40 28 | 028h पहला पिक्सेल हमेशा आउटपुट के लिए सफ़ेद #255 FF | तालिका में स्ट्रिंग मिली 28 एफएफ | 102h हमेशा तालिका में पहली स्ट्रिंग जोड़ें एफएफ | स्थानीय स्ट्रिंग प्रारंभ करें सफेद #255 एफएफ एफएफ | तालिका में स्ट्रिंग नहीं मिला | 0FFh - पिछले स्ट्रिंग के लिए आउटपुट कोड एफएफ एफएफ | 103h - तालिका में नवीनतम स्ट्रिंग जोड़ें एफएफ | - स्थानीय स्ट्रिंग प्रारंभ करें सफेद #255 एफएफ एफएफ | तालिका में स्ट्रिंग मिली काला #40 एफएफ एफएफ 28 | तालिका में स्ट्रिंग नहीं मिला | 103h - पिछले स्ट्रिंग के लिए आउटपुट कोड एफएफ एफएफ 28 | 104h - तालिका में नवीनतम स्ट्रिंग जोड़ें 28 | - स्थानीय स्ट्रिंग प्रारंभ करें सफ़ेद #255 28 FF | तालिका में स्ट्रिंग मिली सफ़ेद #255 28 FF FF | तालिका में स्ट्रिंग नहीं मिला | 102h - पिछले स्ट्रिंग के लिए आउटपुट कोड 28 एफएफ एफएफ | 105h - तालिका में नवीनतम स्ट्रिंग जोड़ें एफएफ | - स्थानीय स्ट्रिंग प्रारंभ करें सफेद #255 एफएफ एफएफ | तालिका में स्ट्रिंग मिली सफेद #255 एफएफ एफएफ एफएफ | तालिका में स्ट्रिंग नहीं मिला | 103h - पिछले स्ट्रिंग के लिए आउटपुट कोड एफएफ एफएफ एफएफ | 106h - तालिका में नवीनतम स्ट्रिंग जोड़ें एफएफ | - स्थानीय स्ट्रिंग प्रारंभ करें सफेद #255 एफएफ एफएफ | तालिका में स्ट्रिंग मिली सफेद #255 एफएफ एफएफ एफएफ | तालिका में स्ट्रिंग मिली सफेद #255 एफएफ एफएफ एफएफ एफएफ | तालिका में स्ट्रिंग नहीं मिला | 106h - पिछले स्ट्रिंग के लिए आउटपुट कोड एफएफ एफएफ एफएफ एफएफ | 107h - तालिका में नवीनतम स्ट्रिंग जोड़ें एफएफ | - स्थानीय स्ट्रिंग प्रारंभ करें सफेद #255 एफएफ एफएफ | तालिका में स्ट्रिंग मिली सफेद #255 एफएफ एफएफ एफएफ | तालिका में स्ट्रिंग मिली सफेद #255 एफएफ एफएफ एफएफ एफएफ | तालिका में स्ट्रिंग मिली और पिक्सेल नहीं 107h - अंतिम स्ट्रिंग के लिए आउटपुट कोड 101h अंत

स्पष्टता के लिए तालिका को ऊपर निर्मित के रूप में दिखाया गया हैबढ़ती लंबाई के तार का टी। वह योजना कार्य कर सकती है लेकिन तालिका अप्रत्याशित मात्रा में स्मृति का उपभोग करती है। मेमोरी को व्यवहार में सहेजा जा सकता है, यह ध्यान में रखते हुए कि संग्रहीत की जाने वाली प्रत्येक नई स्ट्रिंग में एक वर्ण द्वारा संवर्धित पहले से संग्रहीत स्ट्रिंग होती है। प्रत्येक पते पर केवल दो शब्दों को संग्रहित करना किफायती है: एक मौजूदा पता और एक वर्ण।

LZW एल्गोरिथ्म को प्रत्येक पिक्सेल के लिए तालिका की खोज की आवश्यकता होती है। 4096 पतों के माध्यम से एक रैखिक खोज कोडिंग को धीमा कर देगी। व्यवहार में कोड को संख्यात्मक मान के क्रम में संग्रहीत किया जा सकता है; यह प्रत्येक खोज को SAR (क्रमिक सन्निकटन रजिस्टर, जैसा कि कुछ क्रमिक सन्निकटन ADC में उपयोग किया जाता है) द्वारा किया जा सकता है, केवल 12 परिमाण तुलनाओं के साथ। इस दक्षता के लिए कोड और वास्तविक मेमोरी पतों के बीच रूपांतरण के लिए एक अतिरिक्त तालिका की आवश्यकता होती है; अतिरिक्त टेबल अपकीपिंग की आवश्यकता तभी होती है जब एक नया कोड संग्रहीत किया जाता है जो पिक्सेल दर से बहुत कम होता है।

छवि डिकोडिंग
डिकोडिंग संग्रहीत बाइट्स को 9-बिट कोड पर मैप करके शुरू होता है। नीचे दिखाए गए पिक्सेल रंगों को पुनर्प्राप्त करने के लिए इन्हें डीकोड किया गया है। एन्कोडर में उपयोग की जाने वाली तालिका के समान एक तालिका इस नियम द्वारा तार जोड़कर बनाई गई है: खिसक जाना 9-बिट > लोकल टेबल पिक्सेल कोड कोड कोड --> स्ट्रिंग पैलेट कलर एक्शन 100 ह 000 ह | #0 9-बिट कोड के रूट टेबल को इनिशियलाइज़ करें : | पैलेट : | रंग की 0FFh | #255 100 ह | सीएलआर 101h | अंत 028h | #40  BLACK पहला पिक्सेल डीकोड करें 0FFh 028h | तालिका में आने वाला कोड मिला | #255 WHITE - टेबल से आउटपुट स्ट्रिंग 102h | 28 एफएफ - तालिका में जोड़ें 103h 0FFh | इनकमिंग कोड टेबल में नहीं मिला 103एच | एफएफ एफएफ - तालिका में जोड़ें | - टेबल से आउटपुट स्ट्रिंग | #255 WHITE 102h 103h | तालिका में आने वाला कोड मिला | - टेबल से आउटपुट स्ट्रिंग | #40  BLACK 104h | एफएफ एफएफ 28 - तालिका में जोड़ें 103h 102h | तालिका में आने वाला कोड मिला | - टेबल से आउटपुट स्ट्रिंग | #255 WHITE 105h | 28 एफएफ एफएफ - तालिका में जोड़ें 106h 103h | इनकमिंग कोड टेबल में नहीं मिला 106h | एफएफ एफएफ एफएफ - तालिका में जोड़ें | - टेबल से आउटपुट स्ट्रिंग | #255 WHITE 107h 106h | इनकमिंग कोड टेबल में नहीं मिला 107h | एफएफ एफएफ एफएफ एफएफ - तालिका में जोड़ें | - टेबल से आउटपुट स्ट्रिंग | #255 WHITE 101h | अंत
 * #255 WHITE
 * #255 WHITE
 * #255 WHITE
 * #255 WHITE
 * #255 WHITE
 * #255 WHITE
 * #255 WHITE
 * #255 WHITE

LZW कोड की लंबाई
उदाहरण में 256 रंगों से छोटे पैलेट के लिए छोटी कोड लंबाई का उपयोग किया जा सकता है। यदि पैलेट केवल 64 रंग का है (इसलिए रंग सूचकांक 6 बिट चौड़ा है), प्रतीक 0 से 63 तक हो सकते हैं, और प्रतीक की चौड़ाई 6 बिट हो सकती है, कोड 7 बिट से शुरू होते हैं। वास्तव में, प्रतीक की चौड़ाई को पैलेट के आकार से मेल नहीं खाना चाहिए: जब तक डिकोड किए गए मान हमेशा पैलेट में रंगों की संख्या से कम होते हैं, तब तक प्रतीक 2 से 8 तक कोई भी चौड़ाई हो सकते हैं, और पैलेट का आकार 2 की कोई भी शक्ति हो सकती है। 2 से 256 तक। उदाहरण के लिए, यदि पैलेट के केवल पहले चार रंगों (मान 0 से 3) का उपयोग किया जाता है, तो प्रतीकों को 3 बिट से शुरू होने वाले कोड के साथ 2 बिट चौड़ा लिया जा सकता है।

इसके विपरीत, प्रतीक चौड़ाई 8 पर सेट की जा सकती है, भले ही मान 0 और 1 का उपयोग किया गया हो; इन आंकड़ों के लिए केवल दो रंगों वाली तालिका की आवश्यकता होगी। हालाँकि फ़ाइल को इस तरह से एन्कोड करने का कोई मतलब नहीं होगा, आमतौर पर द्वि-रंग छवियों के लिए कुछ ऐसा ही होता है: न्यूनतम प्रतीक चौड़ाई 2 है, भले ही केवल मान 0 और 1 का उपयोग किया गया हो।

कोड तालिका में शुरू में ऐसे कोड होते हैं जो दो विशेष कोड clr और अंत को समायोजित करने के लिए प्रतीक आकार से एक बिट लंबे होते हैं और प्रक्रिया के दौरान जोड़े गए स्ट्रिंग्स के लिए कोड होते हैं। जब टेबल भर जाती है तो अधिक स्ट्रिंग्स के लिए जगह देने के लिए कोड की लंबाई बढ़ जाती है, अधिकतम कोड 4095 = FFF(hex) तक। जैसा कि डिकोडर अपनी तालिका बनाता है, यह कोड की लंबाई में इन वृद्धि को ट्रैक करता है और यह आने वाले बाइट्स को तदनुसार अनपैक करने में सक्षम होता है।

असम्पीडित जीआईएफ
GIF एन्कोडिंग प्रक्रिया को LZW संपीड़न के बिना एक फ़ाइल बनाने के लिए संशोधित किया जा सकता है जो अभी भी GIF छवि के रूप में देखा जा सकता है। इस तकनीक को मूल रूप से पेटेंट उल्लंघन से बचने के तरीके के रूप में पेश किया गया था। असम्पीडित जीआईएफ ग्राफिक्स प्रोग्रामर के लिए एक उपयोगी मध्यवर्ती प्रारूप भी हो सकता है क्योंकि अलग-अलग पिक्सेल पढ़ने या पेंटिंग के लिए सुलभ होते हैं। एक असम्पीडित जीआईएफ फ़ाइल को एक साधारण जीआईएफ फ़ाइल में एक छवि संपादक के माध्यम से पारित करके परिवर्तित किया जा सकता है।

संशोधित एन्कोडिंग विधि LZW तालिका के निर्माण पर ध्यान नहीं देती है और केवल रूट पैलेट कोड और CLEAR और STOP के लिए कोड का उत्सर्जन करती है। यह एक सरल एन्कोडिंग (कोड मान और पैलेट कोड के बीच 1-से-1 पत्राचार) उत्पन्न करता है, लेकिन सभी संपीड़न का त्याग करता है: छवि में प्रत्येक पिक्सेल एक आउटपुट कोड उत्पन्न करता है जो उसके रंग सूचकांक को दर्शाता है। एक असम्पीडित जीआईएफ को संसाधित करते समय, एक मानक जीआईएफ डिकोडर को अपनी शब्दकोश तालिका में तार लिखने से नहीं रोका जाएगा, लेकिन कोड की चौड़ाई कभी भी नहीं बढ़नी चाहिए क्योंकि यह बिट्स की एक अलग पैकिंग को बाइट्स में ट्रिगर करता है।

यदि प्रतीक चौड़ाई है $n$, चौड़ाई के कोड $n+1$ स्वाभाविक रूप से दो ब्लॉकों में गिर जाते हैं: का निचला ब्लॉक $2n$ एकल प्रतीकों को कोड करने के लिए कोड, और ऊपरी ब्लॉक $2n$ कोड जिनका उपयोग डिकोडर द्वारा एक से अधिक लंबाई के अनुक्रमों के लिए किया जाएगा। उस ऊपरी ब्लॉक के पहले दो कोड पहले ही ले लिए गए हैं: $2n$ स्पष्ट और के लिए $2n + 1$ स्टॉप के लिए। डिकोडर को ऊपरी ब्लॉक में अंतिम कोड का उपयोग करने से भी रोका जाना चाहिए, $2^{n+1} − 1$, क्योंकि जब डिकोडर उस स्लॉट को भरता है, तो यह कोड की चौड़ाई बढ़ा देगा। इस प्रकार ऊपरी ब्लॉक में हैं $2n − 3$ डिकोडर के लिए उपलब्ध कोड जो कोड चौड़ाई में वृद्धि को ट्रिगर नहीं करेंगे। क्योंकि डिकोडर तालिका को बनाए रखने में हमेशा एक कदम पीछे होता है, यह एनकोडर से पहला कोड प्राप्त करने पर तालिका प्रविष्टि उत्पन्न नहीं करता है, लेकिन प्रत्येक बाद के कोड के लिए एक उत्पन्न करेगा। इस प्रकार एनकोडर उत्पन्न कर सकता है $2n − 2$ कोड चौड़ाई में वृद्धि को ट्रिगर किए बिना कोड। इसलिए, एनकोडर को अंतराल पर अतिरिक्त CLEAR कोड का उत्सर्जन करना चाहिए $2n − 2$ डिकोडर को कोडिंग डिक्शनरी को रीसेट करने के लिए कोड या उससे कम। GIF मानक किसी भी समय छवि डेटा में ऐसे अतिरिक्त CLEAR कोड डालने की अनुमति देता है। कंपोजिट डेटा स्ट्रीम को उप-ब्लॉकों में विभाजित किया गया है, जिनमें से प्रत्येक में 1 से 255 बाइट्स होते हैं।

उपरोक्त नमूना 3×5 छवि के लिए, निम्नलिखित 9-बिट कोड स्पष्ट (100) का प्रतिनिधित्व करते हैं, जिसके बाद छवि पिक्सेल स्कैन क्रम और स्टॉप (101) में होते हैं।

100 028 0FF 0FF 0FF 028 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 101

उपरोक्त कोड बाइट्स में मैप किए जाने के बाद, असम्पीडित फ़ाइल संपीड़ित फ़ाइल से भिन्न होती है:

संपीड़न उदाहरण
ठोस रंग की एक बड़ी छवि का तुच्छ उदाहरण GIF फ़ाइलों में उपयोग की जाने वाली चर-लंबाई LZW संपीड़न को प्रदर्शित करता है। दिखाए गए कोड मान बाइट्स में पैक किए जाते हैं जिन्हें बाद में 255 बाइट्स तक के ब्लॉक में पैक किया जाता है। छवि डेटा का एक ब्लॉक एक बाइट से शुरू होता है जो बाइट्स की संख्या का पालन करने की घोषणा करता है। एक छवि के लिए डेटा का अंतिम ब्लॉक शून्य ब्लॉक-लम्बाई बाइट द्वारा चिह्नित किया गया है।

इंटरलेसिंग
जीआईएफ विशिष्टता प्रत्येक छवि को जीआईएफ फ़ाइल की तार्किक स्क्रीन के भीतर यह निर्दिष्ट करने की अनुमति देती है कि यह इंटरलेस्ड है; यानी, इसके डेटा ब्लॉक में रेखापुंज रेखाओं का क्रम अनुक्रमिक नहीं है। यह छवि के आंशिक प्रदर्शन की अनुमति देता है जिसे पूरी छवि पेंट करने से पहले पहचाना जा सकता है।

एक इंटरलेस्ड छवि को ऊपर से नीचे तक 8 पिक्सेल ऊँची पट्टियों में विभाजित किया जाता है, और छवि की पंक्तियों को निम्नलिखित क्रम में प्रस्तुत किया जाता है:
 * पास 1: प्रत्येक स्ट्रिप से लाइन 0 (सबसे ऊपर वाली लाइन)।
 * पास 2: प्रत्येक पट्टी से पंक्ति 4।
 * पास 3: प्रत्येक स्ट्रिप से लाइन 2 और 6।
 * पास 4: प्रत्येक पट्टी से पंक्तियाँ 1, 3, 5 और 7।

प्रत्येक पंक्ति के भीतर पिक्सेल इंटरलेस्ड नहीं होते हैं, लेकिन बाएं से दाएं लगातार प्रस्तुत किए जाते हैं। गैर-इंटरलेस्ड छवियों की तरह, एक पंक्ति के डेटा और अगली पंक्ति के डेटा के बीच कोई विराम नहीं होता है। इंडिकेटर कि एक इमेज इंटरलेस्ड है, संबंधित इमेज डिस्क्रिप्टर ब्लॉक में थोड़ा सा सेट है।

एनिमेटेड जीआईएफ
हालांकि जीआईएफ को एनीमेशन माध्यम के रूप में डिजाइन नहीं किया गया था, एक एनीमेशन अनुक्रम के फिल्म फ्रेम  को स्टोर करने के लिए प्रारूप का उपयोग करके स्वाभाविक रूप से एक फाइल में कई छवियों को स्टोर करने की इसकी क्षमता का सुझाव दिया गया था। एनिमेशन प्रदर्शित करने की सुविधा के लिए, GIF89a युक्ति ने ग्राफिक कंट्रोल एक्सटेंशन (GCE) जोड़ा, जो फ़ाइल में छवियों (फ्रेम्स) को समय की देरी के साथ चित्रित करने की अनुमति देता है, एक  वीडियो क्लिप  बनाता है। एनीमेशन जीआईएफ में प्रत्येक फ्रेम अपने स्वयं के जीसीई द्वारा पेश किया जाता है जो फ्रेम तैयार होने के बाद प्रतीक्षा करने में देरी को निर्दिष्ट करता है। फ़ाइल की शुरुआत में वैश्विक जानकारी डिफ़ॉल्ट रूप से सभी फ़्रेमों पर लागू होती है। डेटा स्ट्रीम-ओरिएंटेड है, इसलिए प्रत्येक GCE के प्रारंभ की फ़ाइल ऑफ़सेट पूर्ववर्ती डेटा की लंबाई पर निर्भर करती है। प्रत्येक फ़्रेम के भीतर LZW-कोडित छवि डेटा को 255 बाइट्स तक के उप-ब्लॉकों में व्यवस्थित किया जाता है; प्रत्येक उप-ब्लॉक का आकार उसके पहले आने वाली बाइट द्वारा घोषित किया जाता है।

डिफ़ॉल्ट रूप से, एक एनीमेशन केवल एक बार फ्रेम के अनुक्रम को प्रदर्शित करता है, अंतिम फ्रेम प्रदर्शित होने पर रुक जाता है। एनीमेशन को लूप में सक्षम करने के लिए, नेटस्केप  ने 1990 के दशक में नेटस्केप एप्लिकेशन ब्लॉक (एनएबी) को लागू करने के लिए एप्लिकेशन एक्सटेंशन ब्लॉक (विक्रेताओं को जीआईएफ फ़ाइल में एप्लिकेशन-विशिष्ट जानकारी जोड़ने की अनुमति देने के उद्देश्य से) का उपयोग किया। एनीमेशन फ्रेम के अनुक्रम से ठीक पहले रखा गया यह ब्लॉक, निर्दिष्ट करता है कि फ्रेम के अनुक्रम को कितनी बार खेला जाना चाहिए (1 से 65535 बार) या इसे लगातार दोहराना चाहिए (शून्य लूप को हमेशा के लिए इंगित करता है)। इन दोहराए जाने वाले एनिमेशन के लिए समर्थन पहले  नेटस्केप नेविगेटर  संस्करण 2.0 में दिखाई दिया, और फिर अन्य ब्राउज़रों में फैल गया। अधिकांश ब्राउज़र अब NAB को पहचानते हैं और उसका समर्थन करते हैं, हालांकि यह GIF89a विनिर्देश का कड़ाई से हिस्सा नहीं है।

The following example shows the structure of the animation file ''[[:File:Rotating earth (large).gif|Rotating earth (large).gifलेख के इन्फोबॉक्स में दिखाया गया (थंबनेल के रूप में)।

जीसीई में सेकंड के सौवें हिस्से में प्रत्येक फ्रेम के लिए एनीमेशन विलंब निर्दिष्ट किया गया है। डेटा की कुछ किफायत संभव है जहां एक फ्रेम को डिस्प्ले के पिक्सेल के केवल एक हिस्से को फिर से लिखने की आवश्यकता होती है, क्योंकि इमेज डिस्क्रिप्टर पूरी छवि के बजाय एक छोटे आयत को फिर से स्कैन करने के लिए परिभाषित कर सकता है। ब्राउज़र या अन्य डिस्प्ले जो एनिमेटेड जीआईएफ का समर्थन नहीं करते हैं, आमतौर पर केवल पहला फ्रेम दिखाते हैं।

एनिमेटेड जीआईएफ फाइलों का आकार और रंग गुणवत्ता उन्हें बनाने के लिए उपयोग किए जाने वाले एप्लिकेशन के आधार पर महत्वपूर्ण रूप से भिन्न हो सकती है। फ़ाइल आकार को कम करने की रणनीतियों में सभी फ़्रेमों के लिए एक सामान्य वैश्विक रंग तालिका का उपयोग करना शामिल है (प्रत्येक फ़्रेम के लिए एक पूर्ण स्थानीय रंग तालिका के बजाय) और क्रमिक फ़्रेमों में कवर किए गए पिक्सेल की संख्या को कम करना (ताकि केवल पिक्सेल जो एक फ्रेम से दूसरे फ्रेम में बदलते हैं) अगले को बाद वाले फ्रेम में शामिल किया गया है)। अधिक उन्नत तकनीकों में मौजूदा LZW डिक्शनरी से बेहतर मिलान करने के लिए रंग अनुक्रमों को संशोधित करना शामिल है, हानिपूर्ण संपीड़न  का एक रूप। केवल स्वतंत्र फ्रेम छवियों की एक श्रृंखला को एक समग्र एनीमेशन में पैक करने से बड़े फ़ाइल आकार प्राप्त होते हैं। मौजूदा जीआईएफ दिए गए फ़ाइल आकार को कम करने के लिए उपकरण उपलब्ध हैं।

मेटाडाटा
मेटाडेटा को जीआईएफ फाइलों में एक टिप्पणी ब्लॉक, एक सादा पाठ ब्लॉक या एक एप्लिकेशन-विशिष्ट एप्लिकेशन एक्सटेंशन ब्लॉक के रूप में संग्रहीत किया जा सकता है। कई ग्राफिक्स संपादक छवि उत्पन्न करने के लिए उपयोग किए गए डेटा को शामिल करने के लिए अनौपचारिक एप्लिकेशन एक्सटेंशन ब्लॉक का उपयोग करते हैं, ताकि इसे आगे के संपादन के लिए पुनर्प्राप्त किया जा सके।

इन सभी विधियों में तकनीकी रूप से मेटाडेटा को उप-ब्लॉकों में तोड़ने की आवश्यकता होती है ताकि एप्लिकेशन मेटाडेटा ब्लॉक को उसकी आंतरिक संरचना को जाने बिना नेविगेट कर सकें।

एक्स्टेंसिबल मेटाडेटा प्लेटफ़ॉर्म (XMP) मेटाडेटा मानक ने GIF फ़ाइलों में XMP डेटा को शामिल करने के लिए एक अनौपचारिक लेकिन अब व्यापक XMP डेटा एप्लिकेशन एक्सटेंशन ब्लॉक पेश किया। चूंकि XMP डेटा NUL वर्णों के बिना  UTF-8  का उपयोग करके एन्कोड किया गया है, इसलिए डेटा में 0 बाइट्स नहीं हैं। डेटा को औपचारिक उप-ब्लॉकों में तोड़ने के बजाय, एक्सटेंशन ब्लॉक एक मैजिक ट्रेलर के साथ समाप्त हो जाता है जो डेटा को सब-ब्लॉक के रूप में मानने वाले किसी भी एप्लिकेशन को अंतिम 0 बाइट में रूट करता है जो उप-ब्लॉक श्रृंखला को समाप्त करता है।

यूनिसिस और LZW पेटेंट प्रवर्तन
1977 और 1978 में, जैकब ज़िव  और  अब्राहम लेम्पेल  ने दोषरहित डेटा-संपीड़न एल्गोरिदम की एक नई श्रेणी पर कुछ पेपर प्रकाशित किए, जिन्हें अब सामूहिक रूप से  LZ77 और LZ78  के रूप में संदर्भित किया जाता है। 1983 में,  टेरी वेल्च  ने LZ78 का एक तेज़ संस्करण विकसित किया जिसे लेम्पेल-ज़िव-वेल्च (LZW) नाम दिया गया था। वेल्च ने जून 1983 में LZW विधि के लिए एक पेटेंट आवेदन दायर किया। परिणामी पेटेंट, US4558302, दिसंबर 1985 में प्रदान किया गया, स्पेरी कॉर्पोरेशन  को सौंपा गया था, जो बाद में 1986 में  बरोज़ कॉर्पोरेशन  के साथ विलय हो गया और यूनिसिस का गठन किया। आगे पेटेंट यूनाइटेड किंगडम, फ्रांस, जर्मनी, इटली, जापान और कनाडा में प्राप्त किए गए थे।

उपरोक्त पेटेंटों के अलावा, वेल्च के 1983 के पेटेंट में कई अन्य पेटेंटों के उद्धरण भी शामिल हैं जिन्होंने इसे प्रभावित किया, जिनमें शामिल हैं: जून 1984 में, वेल्च का एक लेख IEEE  पत्रिका में प्रकाशित हुआ था, जिसमें पहली बार LZW तकनीक का सार्वजनिक रूप से वर्णन किया गया था। LZW एक लोकप्रिय डेटा कम्प्रेशन तकनीक बन गई और, जब पेटेंट प्रदान किया गया, तो यूनिसिस ने सौ से अधिक कंपनियों के साथ लाइसेंसिंग समझौते किए। LZW की लोकप्रियता ने CompuServe को 1987 में विकसित GIF के अपने संस्करण के लिए संपीड़न तकनीक के रूप में इसे चुनने के लिए प्रेरित किया। उस समय, CompuServe को पेटेंट के बारे में पता नहीं था। यूनिसिस को पता चला कि GIF के संस्करण ने LZW संपीड़न तकनीक का उपयोग किया और जनवरी 1993 में CompuServe के साथ लाइसेंसिंग वार्ता में प्रवेश किया। बाद के समझौते की घोषणा 24 दिसंबर 1994 को की गई। यूनिसिस ने कहा कि वे उम्मीद करते हैं कि सभी प्रमुख व्यावसायिक ऑन-लाइन सूचना सेवा कंपनियां उचित दर पर यूनिसिस से प्रौद्योगिकी का लाइसेंस लेने के लिए LZW पेटेंट को नियोजित करती हैं, लेकिन उन्हें गैर-वाणिज्यिक, गैर-वाणिज्यिक, गैर- लाभ GIF-आधारित अनुप्रयोग, जिसमें ऑन-लाइन सेवाओं पर उपयोग के लिए शामिल हैं।
 * 1980 के दो जापानी पेटेंट NEC  के जून कानात्सु से,
 * (1974) जॉन एस होर्निंग से,
 * (1977) क्लाउस ई. होल्ट्ज़ से, और
 * 1981 में कार्ल एकहार्ट हेंज का जर्मन पेटेंट।

इस घोषणा के बाद, CompuServe और Unisys की व्यापक निंदा हुई और कई सॉफ्टवेयर डेवलपर्स ने GIF का उपयोग बंद करने की धमकी दी। पोर्टेबल नेटवर्क ग्राफिक्स (नीचे देखें) को 1995 में एक इच्छित प्रतिस्थापन के रूप में विकसित किया गया था।  हालांकि, पीएनजी प्रारूप के लिए वेब ब्राउज़र और अन्य सॉफ्टवेयर के निर्माताओं से समर्थन प्राप्त करना मुश्किल साबित हुआ और जीआईएफ को बदलना संभव नहीं था, हालांकि पीएनजी की लोकप्रियता धीरे-धीरे बढ़ी है। इसलिए, LZW संपीड़न के बिना GIF विविधताएं विकसित की गईं। उदाहरण के लिए, एरिक एस. रेमंड के giflib पर आधारित लिबंगिफ लाइब्रेरी, जीआईएफ के निर्माण की अनुमति देता है जो डेटा प्रारूप का पालन करता है लेकिन संपीड़न सुविधाओं से बचा जाता है, इस प्रकार यूनिसिस LZW पेटेंट के उपयोग से बचा जाता है। 2001 डॉ. डॉब्स जर्नल|डॉ. डॉब के लेख ने इसके पेटेंट का उल्लंघन किए बिना LZW- संगत एन्कोडिंग प्राप्त करने का एक तरीका बताया। अगस्त 1999 में, यूनिसिस ने कुछ गैर-वाणिज्यिक और निजी वेबसाइटों के मालिकों के लिए $5000 या $7500 के एक बार के लाइसेंस शुल्क के भुगतान पर लाइसेंस प्राप्त करने के विकल्प की घोषणा करते हुए अपने लाइसेंसिंग अभ्यास के विवरण को बदल दिया। ऐसे लाइसेंस की आवश्यकता वेबसाइट के मालिकों या अन्य जीआईएफ उपयोगकर्ताओं के लिए नहीं थी, जिन्होंने जीआईएफ बनाने के लिए लाइसेंस प्राप्त सॉफ़्टवेयर का उपयोग किया था। फिर भी, यूनिसिस को हजारों ऑनलाइन हमलों और उपयोगकर्ताओं से अपमानजनक ईमेल का सामना करना पड़ा, यह मानते हुए कि उनकी वेबसाइटों पर जीआईएफ का उपयोग करने के लिए उनसे $ 5000 का शुल्क लिया जाएगा या उन पर मुकदमा चलाया जाएगा। सैकड़ों गैर-लाभकारी संगठनों, स्कूलों और सरकारों को मुफ्त लाइसेंस देने के बावजूद, यूनिसिस कोई भी अच्छा प्रचार करने में पूरी तरह से असमर्थ था और प्रोग्रामिंग स्वतंत्रता के लिए लीग  जैसे व्यक्तियों और संगठनों द्वारा निंदा की जाती रही, जिन्होंने 1999 में बर्न ऑल जीआईएफ अभियान शुरू किया था।. संयुक्त राज्य LZW पेटेंट 20 जून 2003 को समाप्त हो गया। यूनाइटेड किंगडम, फ्रांस, जर्मनी और इटली में समकक्ष पेटेंट 18 जून 2004 को समाप्त हो गए, जापानी पेटेंट 20 जून 2004 को समाप्त हो गए और कनाडाई पेटेंट 7 जुलाई 2004 को समाप्त हो गए। नतीजतन, जबकि यूनिसिस के पास LZW तकनीक में सुधार से संबंधित पेटेंट और पेटेंट आवेदन हैं, जुलाई 2004 से LZW खुद (और फलस्वरूप GIF) उपयोग करने के लिए स्वतंत्र है।

पीएनजी
LZW संपीड़न तकनीक पर यूनिसिस के पेटेंट के उल्लंघन से बचने के लिए पोर्टेबल नेटवर्क ग्राफिक्स (PNG) को GIF के प्रतिस्थापन के रूप में डिज़ाइन किया गया था। PNG GIF की तुलना में बेहतर संपीड़न और अधिक सुविधाएँ प्रदान करता है, एनिमेशन एकमात्र महत्वपूर्ण अपवाद है। PNG ऐसे उदाहरणों में GIF से अधिक उपयुक्त है जहां ट्रू-कलर इमेजिंग और अल्फा पारदर्शिता  की आवश्यकता होती है।

हालाँकि PNG प्रारूप के लिए समर्थन धीरे-धीरे आया, नए वेब ब्राउज़र  PNG का समर्थन करते हैं।  Internet Explorer  के पुराने संस्करण PNG की सभी विशेषताओं का समर्थन नहीं करते हैं। संस्करण 6 और पहले के संस्करण Microsoft-विशिष्ट HTML एक्सटेंशन का उपयोग किए बिना  अल्फा चैनल  पारदर्शिता का समर्थन नहीं करते हैं। रेफरी> पीएनजी छवियों का  गामा सुधार  सुधार संस्करण 8 से पहले समर्थित नहीं था, और पिछले संस्करणों में इन छवियों के प्रदर्शन में गलत रंग हो सकता है। जीआईएफ के लिए पूर्ण समर्थन मुख्य रूप से इसकी अनुमति देने वाली जटिल कैनवास संरचना द्वारा जटिल है, हालांकि यह कॉम्पैक्ट एनीमेशन सुविधाओं को सक्षम बनाता है।

एनिमेशन प्रारूप
वीडियो वेब पर सामान्य उपयोग के माध्यम से GIF द्वारा पेश की जाने वाली कई समस्याओं का समाधान करते हैं। इनमें अत्यधिक छोटे फ़ाइल आकार, 8-बिट रंग प्रतिबंध को पार करने की क्षमता, और वीडियो कोडेक  के माध्यम से बेहतर फ्रेम-हैंडलिंग और संपीड़न शामिल हैं। वेब ब्राउज़र में GIF प्रारूप के लिए वस्तुतः सार्वभौमिक समर्थन और  HTML  मानक में वीडियो के लिए आधिकारिक समर्थन की कमी के कारण GIF को वेब पर लघु वीडियो जैसी फ़ाइलों को प्रदर्शित करने के उद्देश्य से प्रमुखता मिली।


 * एकाधिक छवि नेटवर्क ग्राफिक्स (मल्टीपल-इमेज नेटवर्क ग्राफ़िक्स) को मूल रूप से एनिमेशन के लिए PNG-आधारित समाधान के रूप में विकसित किया गया था। एमएनजी 2001 में संस्करण 1.0 तक पहुंच गया, लेकिन कुछ अनुप्रयोग इसका समर्थन करते हैं।


 * एनिमेटेड पोर्टेबल नेटवर्क ग्राफिक्स (एनिमेटेड पोर्टेबल नेटवर्क ग्राफिक्स)  mozilla  द्वारा 2006 में प्रस्तावित किया गया था। APNG MNG प्रारूप के विकल्प के रूप में PNG प्रारूप का एक विस्तार है। APNG 2019 तक अधिकांश ब्राउज़रों द्वारा समर्थित है। एपीएनजी डीकोडर्स में पीछे की ओर संगतता बनाए रखते हुए पीएनजी फाइलों को एनिमेट करने की क्षमता प्रदान करता है जो एनीमेशन खंड (एमएनजी के विपरीत) को समझ नहीं सकता है। पुराने डिकोडर केवल एनीमेशन के पहले फ्रेम को प्रस्तुत करेंगे।


 * पीएनजी समूह ने 20 अप्रैल 2007 को आधिकारिक तौर पर एपीएनजी को एक आधिकारिक विस्तार के रूप में खारिज कर दिया।
 * कई अलग-अलग दृष्टिकोणों का उपयोग करते हुए पीएनजी पर आधारित एक सरल एनिमेटेड ग्राफिक्स प्रारूप के लिए बाद के कई प्रस्ताव आए हैं। फिर भी, APNG अभी भी Mozilla द्वारा विकसित किया जा रहा है और Mozilla Firefox#Version 3.0|Firefox 3.0 में समर्थित है जबकि एमएनजी समर्थन हटा दिया गया था।  एपीएनजी वर्तमान में क्रोम (संस्करण 59.0 के बाद से), ओपेरा, फ़ायरफ़ॉक्स और एज सहित सभी प्रमुख वेब ब्राउज़रों द्वारा समर्थित है।


 * एंबेडेड एडोब फ्लैश  ऑब्जेक्ट्स और
 * एमपीईजी फाइलों का उपयोग कुछ वेबसाइटों पर सरल वीडियो प्रदर्शित करने के लिए किया गया था, लेकिन एक अतिरिक्त ब्राउज़र प्लगइन के उपयोग की आवश्यकता थी।


 * वेबम और
 * वेबपी विकास में हैं और कुछ वेब ब्राउज़रों द्वारा समर्थित हैं।
 * वेब एनीमेशन के अन्य विकल्पों में AJAX  का उपयोग करके अलग-अलग फ़्रेमों की सेवा करना शामिल है, या
 * जावास्क्रिप्ट या  सिंक्रनाइज़ मल्टीमीडिया एकीकरण भाषा  (सिंक्रोनाइज़्ड मल्टीमीडिया इंटीग्रेशन लैंग्वेज) का उपयोग करके  स्केलेबल वेक्टर ग्राफिक्स  (स्केलेबल वेक्टर ग्राफिक्स) इमेज को एनिमेट करना।
 * HTML5 वीडियो के व्यापक समर्थन की शुरुआत के साथ अधिकांश वेब ब्राउज़रों में टैग, कुछ वेबसाइटें JavaScript फ़ंक्शंस द्वारा उत्पन्न वीडियो टैग के लूप किए गए संस्करण का उपयोग करती हैं। यह एक जीआईएफ का रूप देता है, लेकिन संपीड़ित वीडियो के आकार और गति के फायदे के साथ।


 * उल्लेखनीय उदाहरण Gfycat  और  Imgur  और उनके GIFV मेटाफ़ॉर्मेट हैं, जो वास्तव में एक लूप्ड  MP4  या WebM संपीड़ित वीडियो चलाने वाला एक वीडियो टैग है।


 * उच्च दक्षता छवि फ़ाइल प्रारूप (उच्च दक्षता छवि फ़ाइल प्रारूप) एक छवि फ़ाइल प्रारूप है, जिसे 2015 में अंतिम रूप दिया गया है, जो HEVC  वीडियो प्रारूप के आधार पर असतत कोसाइन ट्रांसफ़ॉर्म (DCT) हानिपूर्ण संपीड़न एल्गोरिदम का उपयोग करता है, और JPEG छवि प्रारूप से संबंधित है।  जेपीईजी  के विपरीत, एचईआईएफ एनीमेशन का समर्थन करता है। : जीआईएफ प्रारूप की तुलना में, जिसमें डीसीटी संपीड़न की कमी है, एचईआईएफ उल्लेखनीय रूप से अधिक कुशल संपीड़न की अनुमति देता है। HEIF अधिक जानकारी संग्रहीत करता है और समान GIF के आकार के एक छोटे से अंश पर उच्च-गुणवत्ता वाली एनिमेटेड छवियां बनाता है।
 * VP9 केवल 4:2:0  क्रोमा सबसैम्पलिंग  के साथ  अल्फा रचना  का समर्थन करता है  YUV A420 पिक्सेल प्रारूप में, जो जीआईएफ के लिए अनुपयुक्त हो सकता है जो ठीक रंग विवरण के साथ  रेखांकन   वेक्टर ग्राफिक्स  के साथ पारदर्शिता को जोड़ती है।


 * AV1 कोडेक का उपयोग वीडियो या अनुक्रमित छवि के रूप में भी किया जा सकता है।

उपयोग
अप्रैल 2014 में, 4chan  ने मूक वेबएम वीडियो के लिए समर्थन जोड़ा जो 3 एमबी से कम आकार और 2 मिनट की लंबाई में हैं,  और अक्टूबर 2014 में, इम्गुर ने साइट पर अपलोड की गई किसी भी जीआईएफ फाइल को वीडियो में परिवर्तित करना शुरू कर दिया और एचटीएमएल प्लेयर को एक वास्तविक फ़ाइल के रूप में लिंक देना शुरू कर दिया   विस्तार। जनवरी 2016 में, टेलीग्राम (सॉफ्टवेयर)  ने सभी जीआईएफ को एमपीईजी -4 वीडियो में फिर से एन्कोड करना शुरू कर दिया, जिसमें समान छवि गुणवत्ता के लिए 95% कम डिस्क स्थान की आवश्यकता होती है।

यह भी देखें

 * एवीआईएफ
 * सिनेमाग्राफ, जीआईएफ में अक्सर आंशिक रूप से एनिमेटेड तस्वीर
 * वेब बीकन, सामग्री पहुंच की जांच करने के लिए उपयोग की जाने वाली तकनीक
 * ग्राफिक्स फ़ाइल स्वरूपों की तुलना
 * जीआईएफ कला, जीआईएफ से जुड़ी डिजिटल कला  का एक रूप
 * GIFBuilder, प्रारंभिक एनिमेटेड GIF  निर्माण कार्यक्रम
 * plotutil (छद्म-GIF का समर्थन करता है, जो LZW के बजाय रन-लेंथ एन्कोडिंग का उपयोग करता है)
 * माइक्रोसॉफ्ट जीआईएफ एनिमेटर, सरल एनिमेटेड जीआईएफ बनाने के लिए ऐतिहासिक कार्यक्रम
 * सॉफ्टवेयर पेटेंट

बाहरी कड़ियाँ

 * The GIFLIB project
 * spec-gif89a.txt GIF 89a specification on w3.org
 * GIF 89a specification reformatted into HTML
 * LZW and GIF explained
 * Animated GIFs: a six-minute documentary produced by Off Book (web series)
 * GifCities (The GeoCities Animated GIF Search Engine)