जीआईएफ

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

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

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

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

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

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

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

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

सितंबर 1995 में नेटस्केप नेविगेटर 2.0 ने एनिमेटेड जीआईएफ को लूप करने की क्षमता को जोड़ा है।

जबकि जीआईएफ को कम्पूसर्वे द्वारा विकसित किया गया था, इसने 1985 में यूनिसिस द्वारा पेटेंट किए गए लेम्पेल-ज़िव-वेल्च (एलजेडडब्ल्यू) दोषरहित डेटा कम्प्रेशन एल्गोरिदम का उपयोग किया। 1994 में यूनिसिस और कम्पूसर्वे के बीच लाइसेंसिंग समझौते पर विवाद ने पोर्टेबल नेटवर्क ग्राफ़िक्स (पीएनजी) के विकास को प्रेरित किया। मानक 2004 में, जीआईएफ के लिए प्रयुक्त मालिकाना कम्प्रेशन से संबंधित सभी पेटेंट समाप्त हो गए।

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

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

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

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

उच्चारण
जीआईएफ के पहले अक्षर का उच्चारण 1990 के दशक से विवादित रहा है। अंग्रेजी में सबसे आम उच्चारण हैं (जिन के रूप में वायस्ड पोस्टएल्वियोलर एफ्रिकेट के साथ) और  (उपहार के रूप में वॉइस्ड वेलर प्लोसिव के साथ), अक्षर G द्वारा दर्शाए गए स्वनिम में भिन्नता है। प्रारूप के रचनाकारों ने परिवर्णी शब्द जीआईएफ का उच्चारण किया वॉइस्ड पोस्टएल्वियोलर एफ़्रीकेट के साथ, विल्हाइट ने कहा कि वह उच्चारण के लिए अमेरिकी  मूंगफली का मक्खन  ब्रांड जेआईएफ (मूंगफली का मक्खन) को जानबूझकर प्रतिध्वनित करने का इरादा रखता है, और कम्पूसर्वे के कर्मचारी प्रायः जिफ़ के टेलीविजन विज्ञापनों का एक स्पूफ चुनिंदा डेवलपर्स जीआईएफ चुनते हैं। हालाँकि, इस शब्द का व्यापक रूप से उच्चारण किया जाता है, वॉयस वेलर स्टॉप के साथ, और चुनावों ने सामान्यतः दिखाया है कि यह कठिन जी उच्चारण अधिक प्रचलित है। Dictionary.com दोनों उच्चारणों को उद्धृत करता है, संकेत करता है प्राथमिक उच्चारण के रूप में, जबकि कैम्ब्रिज डिक्शनरी ऑफ अमेरिकन इंग्लिश केवल हार्ड-जी उच्चारण प्रदान करता है। मेरियम-वेबस्टर का कॉलेजिएट डिक्शनरी और ऑक्सफोर्ड डिक्शनरी दोनों उच्चारणों का हवाला देते हैं, लेकिन हार्ड G को पहले रखें:. द न्यू ऑक्सफोर्ड अमेरिकन डिक्शनरी ने ही दिया इसके दूसरे संस्करण में लेकिन इसे अपडेट किया  तीसरे संस्करण में है।

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

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

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

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

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

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

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

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

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

फ़ाइल प्रारूप का पूरा विवरण जीआईएफ विनिर्देशन में सम्मिलित है।

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

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

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

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

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

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

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

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

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

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

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

साधारण कम्प्रेशन स्पष्ट है: प्रारंभ में 15 बाइट्स द्वारा परिभाषित पिक्सेल रंग नियंत्रण कोड सहित 12 कोड बाइट्स द्वारा सटीक रूप से दर्शाए जाते हैं।

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

Table          9-bit

string --> code     code    Action #0 | 000h              Initialize root table of 9-bit codes palette |  : colors |  : #255 | 0FFh clr | 100h end | 101h |           100h     Clear Pixel         Local         | color Palette string        | BLACK #40     28            |            028h     1st pixel always to output WHITE #255    FF            |                     String found in table 28 FF     | 102h                Always add 1st string to table FF           |                     Initialize local string WHITE #255    FF FF         |                     String not found in table |           0FFh     - output code for previous string FF FF     | 103h                - add latest string to table FF           |                     - initialize local string WHITE #255    FF FF         |                     String found in table BLACK #40     FF FF 28      |                     String not found in table |           103h     - output code for previous string FF FF 28  | 104h                - add latest string to table 28           |                     - initialize local string WHITE #255    28 FF         |                     String found in table WHITE #255    28 FF FF      |                     String not found in table |           102h     - output code for previous string 28 FF FF  | 105h                - add latest string to table FF           |                     - initialize local string WHITE #255    FF FF         |                     String found in table WHITE #255    FF FF FF      |                     String not found in table |           103h     - output code for previous string FF FF FF  | 106h                - add latest string to table FF           |                     - initialize local string WHITE #255    FF FF         |                     String found in table WHITE #255    FF FF FF      |                     String found in table WHITE #255    FF FF FF FF   |                     String not found in table |           106h     - output code for previous string FF FF FF FF| 107h               - add latest string to table FF           |                     - initialize local string WHITE #255    FF FF         |                     String found in table WHITE #255    FF FF FF      |                     String found in table WHITE #255    FF FF FF FF   |                     String found in table No more pixels 107h    - output code for last string 101h    End स्पष्टता के लिए तालिका को ऊपर दी गई लंबाई के बढ़ते तारों के रूप में दिखाया गया है। वह योजना काम कर सकती है लेकिन तालिका अप्रत्याशित मात्रा में मेमोरी का उपभोग करती है। मेमोरी को व्यवहार में सहेजा जा सकता है, यह ध्यान में रखते हुए कि संग्रहीत की जाने वाली प्रत्येक नई स्ट्रिंग में एक वर्ण द्वारा संवर्धित पहले से संग्रहीत स्ट्रिंग होती है। प्रत्येक पते पर केवल दो शब्दों को संग्रहित करना किफायती है: एक उपस्थिता एड्रेस और करैक्टर।

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

छवि डिकोडिंग
डिकोडिंग संग्रहीत बाइट्स को 9-बिट कोड पर मैप करके आरंभ होता है। नीचे दिखाए गए पिक्सेल रंगों को पुनर्प्राप्त करने के लिए इन्हें डीकोड किया गया है। एन्कोडर में उपयोग की जाने वाली तालिका के समान एक तालिका इस नियम द्वारा तार जोड़कर बनाई गई है: shift 9-bit > Local     Table                 Pixel code       code   code --> string   Palette color  Action 100h              000h  | #0                       Initialize root table of 9-bit codes :   | palette :   | colors 0FFh | #255 100h | clr 101h | end 028h                    |             #40   BLACK  Decode 1st pixel 0FFh       028h         |                           Incoming code found in table |            #255  WHITE   - output string from table 102h | 28 FF                     - add to table 103h       0FFh         |                           Incoming code not found in table 103h | FF FF                     - add to table |                          - output string from table |            #255  WHITE |            #255  WHITE 102h       103h         |                           Incoming code found in table |                          - output string from table |            #40   BLACK |            #255  WHITE 104h | FF FF 28                  - add to table 103h       102h         |                           Incoming code found in table |                          - output string from table |            #255  WHITE |            #255  WHITE 105h | 28 FF FF                  - add to table 106h       103h         |                           Incoming code not found in table 106h | FF FF FF                  - add to table |                          - output string from table |            #255  WHITE |            #255  WHITE |            #255  WHITE 107h       106h         |                           Incoming code not found in table 107h | FF FF FF FF               - add to table |                          - output string from table |            #255  WHITE |            #255  WHITE |            #255  WHITE |            #255  WHITE 101h                    |                           End

एलजेडडब्ल्यू कोड की लंबाई
उदाहरण में 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) तक। जैसा कि डिकोडर अपनी तालिका बनाता है, यह कोड की लंबाई में इन वृद्धि को ट्रैक करता है और यह आने वाले बाइट्स को तदनुसार अनपैक करने में सक्षम होता है।

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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


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


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


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


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


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


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


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


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

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

यह भी देखें

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

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

 * The जीआईएफLIB project
 * spec-जीआईएफ89a.txt जीआईएफ 89a specification on w3.org
 * जीआईएफ 89a specification reformatted into HTML
 * एलजेडडब्ल्यू and जीआईएफ explained
 * Animated जीआईएफs: a six-minute documentary produced by Off Book (web series)
 * जीआईएफCities (The GeoCities Animated जीआईएफ Search Engine)