जीआईएफ

ग्राफिक्स इंटरचेंज फॉर्मेट(अंग्रेज़ी:जीआईएफ; जिसे गिफ़ या जिफ़ कहा जा सकता है) एक बिटमैप छवि प्रारूप है जिसे ऑनलाइन सेवा प्रदाता १५ जून १९८७ को कंप्युसर्व की एक टीम द्वारा अमेरिकी कंप्यूटर वैज्ञानिक स्टीव विल्हाइट के नेतृत्व में विकसित किया गया था और जारी किया गया था। अनुप्रयोगों और ऑपरेटिंग सिस्टम के बीच व्यापक समर्थन और पोर्टेबिलिटी के कारण यहवर्ल्ड वाइड वेबपर व्यापक उपयोग में है।
प्रारूप प्रत्येक छवि के लिए प्रति पिक्सेल ८ बिट तक का समर्थन करता है, जिससे एकल छवि को २४-बिटआरजीबी रंग स्थानसे चुने गए २५६ विभिन्न रंगों के अपने स्वयं के पैलेट को संदर्भित करने की अनुमति मिलती है। यहएनिमेशनका भी समर्थन करता है और प्रत्येक फ्रेम के लिए २५६ रंगों तक के एक अलग पैलेट की अनुमति देता है। ये पैलेट सीमाएं रंगीन तस्वीरों और रंग ग्रेडिएंट वाली अन्य छवियों को पुन: प्रस्तुत करने के लिए जीआईएफ को कम उपयुक्त बनाती हैं, लेकिन रंग के ठोस क्षेत्रों वाले ग्राफिक्स या लोगो जैसी सरल छवियों के लिए अच्छी तरह से अनुकूल हैं।
दृश्य गुणवत्ता को कम किए बिना फ़ाइल के आकार को कम करने के लिएलेम्पेल-ज़िव-वेल्चदोषरहित आँकड़ा संपीड़न तकनीक का उपयोग करके जीआईएफ छवियों को संपीड़ित किया जाता है।
कंप्युसर्व ने अपने फ़ाइल डाउनलोडिंग क्षेत्रों के लिए एक रंगीन छवि प्रारूप प्रदान करने के लिए १५ जून १९८७ को जीआईएफ की शुरुआत की। इसने उनके पहले के रन-लेंथ एन्कोडिंग प्रारूप को बदल दिया, जो केवल ब्लैक एंड व्हाइट था। जीआईएफ लोकप्रिय हो गया क्योंकि इसमेंलेम्पेल-ज़िव-वेल्चआँकड़ा संपीड़नका उपयोग किया गया था। चूंकि यह पीसीएक्स और मैकपेंट द्वारा उपयोग की जाने वाली रन-लेंथ एन्कोडिंग की तुलना में अधिक कुशल था, धीमीमोडेमके साथ भी काफी बड़ी छवियों को उचित रूप से जल्दी से डाउनलोड किया जा सकता था।
जीआईएफ के मूल संस्करण को ८७ए कहा जाता था।  यह संस्करण पहले से ही एक स्ट्रीम में एकाधिक छवियों का समर्थन करता है।
१९८९ में कंप्युसर्व ने ८९ए नामक एक उन्नत संस्करण जारी किया,  इस संस्करण को जोड़ा गया:
फ़ाइल के पहले छहबाइट("मैजिक नंबर" या हस्ताक्षर) को देखकर दो संस्करणों को अलग किया जा सकता है, जिसेआस्कीके रूप में व्याख्या करने पर क्रमशः "जीआईएफ८७ए" या "जीआईएफ८९ए" पढ़ा जाता है।
कंप्युसर्व ने कई कंप्यूटरों के लिए डाउनलोड करने योग्य रूपांतरण सुविधाएं प्रदान करके जीआईएफ को अपनाने को प्रोत्साहित किया। उदाहरण के लिए, दिसंबर १९८७ तक, एक एप्पल आईआईजीएस उपयोगकर्ता अटारी एसटी या कमोडोर ६४ पर बनाए गए चित्रों को देख सकता था।जीआईएफ वेब साइटों पर आमतौर पर उपयोग किए जाने वाले पहले दो छवि प्रारूपों में से एक था, दूसरा ब्लैक एंड व्हाइट एक्सबीएम था।
सितंबर १९९५ में नेटस्केप नेविगेटर २.० ने एनिमेटेड जीआईएफ को लूप में जोड़ने की क्षमता को जोड़ा।
जबकि जीआईएफ को कंप्युसर्व द्वारा विकसित किया गया था, इसने १९८५ मेंयूनिसिसद्वारा पेटेंट कराए गएलेम्पेल-ज़िव-वेल्चदोषरहित आँकड़ा कम्प्रेशन एल्गोरिथम का उपयोग किया। १९९४ मेंयूनिसिसऔर कंप्युसर्व के बीच लाइसेंस समझौते पर विवाद ने पोर्टेबल नेटवर्क ग्राफिक्स (पीएनजी) मानक के विकास को गति दी। २००४ में जीआईएफ के लिए उपयोग किए जाने वाले मालिकाना संपीड़न से संबंधित सभी पेटेंट समाप्त हो गए।
एक फ़ाइल में एकाधिक छवियों को संग्रहीत करने की सुविधा नियंत्रण आँकड़ा के साथ सरल एनिमेशन बनाने के लिए वेब पर व्यापक रूप से उपयोग की जाती है।
वैकल्पिक इंटरलेसिंग सुविधा, जो छवि स्कैन लाइनों को इस तरह से स्टोर करती है कि आंशिक रूप से डाउनलोड की गई छवि भी कुछ हद तक पहचानने योग्य थी, ने भी जीआईएफ की लोकप्रियता में मदद की,क्योंकि उपयोगकर्ता डाउनलोड को रोक सकता था यदि यह आवश्यक नहीं था।
मई २०१५ मेंफेसबुकने जीआईएफ के लिए समर्थन जोड़ा।जनवरी २०१८ में इंस्टाग्राम ने स्टोरी मोड में जीआईएफ स्टिकर्स भी जोड़े।
एकसंज्ञाके रूप मेंजीआईएफशब्द कई शब्दकोशों के नए संस्करणों में पाया जाता है। २०१२ मेंऑक्सफोर्ड यूनिवर्सिटी प्रेसके अमेरिकी विंग नेजीआईएफको एकक्रियाके रूप में भी मान्यता दी, जिसका अर्थ है "एक जीआईएफ फ़ाइल बनाना", जैसा कि "जीआईएफिंगग्रीष्मकालीन ओलंपिकसे दृश्यों को साझा करने का एक आदर्श माध्यम था"। प्रेस के कोशकारों ने इसे वर्ष का अपना शब्द माना, यह कहते हुए कि जीआईएफ "अनुसंधान और पत्रकारिता सहित गंभीर अनुप्रयोगों के साथ एक उपकरण" के रूप में विकसित हुआ है।
जीआईएफके पहले अक्षर का उच्चारण १९९० के दशक से विवादित रहा है। अंग्रेजी में सबसे आम उच्चारण जिफ और गिफ हैं। प्रारूप के रचनाकारों ने संक्षिप्तजीआईएफको जिफ के रूप में किया, जिसमें विल्हाइट ने कहा कि उनका उच्चारण जानबूझकर अमेरिकी मूंगफली का मक्खन ब्रांड जिफ को प्रतिध्वनित करना है, और कंप्यूसर्व के कर्मचारी अक्सर चुटकी लेते हैं "चुनिंदा डेवलपर्स चुनते हैं। जीआईएफ", जिफ के टेलीविजन विज्ञापनों का एक धोखा है।हालांकि, शब्द को व्यापक रूप से गिफऔर सर्वेक्षणों ने आम तौर पर दिखाया है कि यह गिफ का उच्चारण अधिक प्रचलित है।
डिक्शनेरी.कॉमप्राथमिक उच्चारण के रूप में जिफ को इंगित करते हुए दोनों उच्चारणों का हवाला देता है, जबकिकैम्ब्रिज डिक्शनरी ऑफ अमेरिकन इंग्लिशकेवलगिफउच्चारण प्रदान करता है।मरियम-वेबस्टर्स कॉलेजिएट डिक्शनरीऔर ऑक्सफोर्ड डिक्शनरी दोनों उच्चारणों का हवाला देते हैं, लेकिन पहले गिफ को रखें।न्यू ऑक्सफ़ोर्ड अमेरिकन डिक्शनरीने अपने दूसरे संस्करणमें केवल जिफ दिया लेकिन अपने तीसरे संस्करण में इसेजिफ, गिफमें अपडेट किया।
उच्चारण पर असहमति के कारण इंटरनेट पर गर्मागर्म बहस छिड़ गई है। २०१३ के वेबबी पुरस्कार समारोह में लाइफटाइम अचीवमेंट पुरस्कार प्राप्त करने के अवसर पर, विल्हाइट ने सार्वजनिक रूप से हार्ड-जीउच्चारण को अस्वीकार कर दिया;उनके भाषण के कारणट्विटरपर १७,००० से अधिक पोस्ट और दर्जनों समाचार लेख आए।व्हाइट हाउसऔर टीवी कार्यक्रमजेपर्डी!२०१३ में भी बहस में शामिल हुए।फरवरी २०२० में जेएम स्मकर कंपनी, जिफ ब्रांड के मालिक, ने एनिमेटेड इमेज आँकड़ाबेस और सर्च इंजन गिफी के साथ एक सीमित-संस्करण "जिफ बनाम जिफ" जारी करने के लिए भागीदारी की। जीआईएफ (#JआईFवीsGआईFके रूप में हैशटैग) पीनट बटर का जार जिसमें एक लेबल विनोदपूर्वकजिफउच्चारण को विशेष रूप से मूंगफली के मक्खन को संदर्भित करने के लिए घोषित करता था, औरजीआईएफको विशेष रूप से गिफ उच्चारण के साथ उच्चारित किया जाता था।
जीआईएफ सीमित संख्या में रंगों के साथ तेज धार वाली रेखा कला के लिए उपयुक्त हैं, जैसे कि लोगो। यह प्रारूप के दोषरहित संपीड़न का लाभ उठाता है, जो अच्छी तरह से परिभाषित किनारों के साथ समान रंग के समतल क्षेत्रों का पक्षधर है।उनका उपयोग गेम के लिए लो-कलर स्प्राइट आँकड़ा को स्टोर करने के लिए भी किया जा सकता है।जीआईएफ का उपयोग छोटे एनिमेशन और कम-रिज़ॉल्यूशन वीडियो क्लिप के लिए किया जा सकता है, या ऑनलाइन मैसेजिंग में प्रतिक्रियाओं के रूप में शब्दों का उपयोग करने के बजाय भावनाओं और भावनाओं को व्यक्त करने के लिए उपयोग किया जा सकता है। वे सोशल मीडिया प्लेटफॉर्म जैसे टम्बलर,फेसबुक और ट्विटर पर लोकप्रिय हैं।
संकल्पनात्मक रूप से, एक जीआईएफ फ़ाइल शून्य या अधिक "छवियों" के साथ आबादी वाले एक निश्चित आकार के ग्राफिकल क्षेत्र ("तार्किक स्क्रीन") का वर्णन करती है। कई जीआईएफ फ़ाइलों में एक ही छवि होती है जो संपूर्ण तार्किक स्क्रीन को भर देती है। अन्य तार्किक स्क्रीन को अलग उप-छवियों में विभाजित करते हैं। छवियां एनिमेटेड जीआईएफ फ़ाइल में एनीमेशन फ्रेम के रूप में भी कार्य कर सकती हैं, लेकिन फिर से इन्हें संपूर्ण लॉजिकल स्क्रीन भरने की आवश्यकता नहीं है।
जीआईएफ फाइलें एक निश्चित लंबाई वाले हेडर ("जीआईएफ८७ए" या "जीआईएफ८९ए") से शुरू होती हैं, जो संस्करण देती हैं, इसके बाद एक निश्चित लंबाई वाला लॉजिकल स्क्रीन डिस्क्रिप्टर होता है जो पिक्सेल आयाम और लॉजिकल स्क्रीन की अन्य विशेषताओं को देता है। स्क्रीन डिस्क्रिप्टर सर्व रंग टेबल की उपस्थिति और आकार को भी निर्दिष्ट कर सकता है, जो मौजूद होने पर अगला होता है।
इसके बाद फ़ाइल को खंडों में विभाजित किया जाता है। प्रत्येक को १-बाइट प्रहरी द्वारा पेश किया जाता है:
एक छवि एक निश्चित-लंबाई वाले इमेज डिस्क्रिप्टर से शुरू होती है, जो एक स्थानीय रंग तालिका की उपस्थिति और आकार को निर्दिष्ट कर सकती है (जो मौजूद होने पर अगले का अनुसरण करती है)। छवि आँकड़ा इस प्रकार है: एक बाइट अनएन्कोडेड प्रतीकों की थोड़ी चौड़ाई देता है (जो कम से कम २ बिट चौड़ा होना चाहिए, यहां तक कि द्वि-रंग छवियों के लिए भी), इसके बाद एलजेडडब्ल्यू-एन्कोडेड आँकड़ा वाले उप-ब्लॉकों की एक लिंक्ड सूची है।
एक्सटेंशन ब्लॉक (ब्लॉक जो ८७ए स्पेक में पहले से परिभाषित एक तंत्र के माध्यम से ८७ए परिभाषा को "विस्तारित" करते हैं) में सेंटीनेल, एक्सटेंशन के प्रकार को निर्दिष्ट करने वाला एक अतिरिक्त बाइट, और एक्सटेंशन आँकड़ा के साथ उप-ब्लॉक की एक लिंक्ड सूची शामिल है। एक छवि को संशोधित करने वाले एक्सटेंशन ब्लॉक (जैसे ग्राफिक कंट्रोल एक्सटेंशन जो वैकल्पिक एनीमेशन विलंब समय और वैकल्पिक पारदर्शी पृष्ठभूमि रंग निर्दिष्ट करता है) को उनके द्वारा संदर्भित छवि वाले सेगमेंट से तुरंत पहले होना चाहिए।
छवि आँकड़ा और एक्सटेंशन ब्लॉक द्वारा उपयोग की जाने वाली लिंक्ड सूचियों में उप-ब्लॉक की श्रृंखला होती है, प्रत्येक उप-ब्लॉक एक बाइट से शुरू होता है जो उप-ब्लॉक (१ से २५५) में बाद के आँकड़ा बाइट्स की संख्या देता है। उप-ब्लॉक की श्रृंखला को एक खाली उप-ब्लॉक (० बाइट) द्वारा समाप्त किया जाता है।
यह संरचना फ़ाइल को पार्स करने की अनुमति देती है, भले ही सभी भागों को समझा न जाए। ८७ए चिह्नित जीआईएफ में एक्सटेंशन ब्लॉक हो सकते हैं; आशय यह है कि एक डिकोडर फ़ाइल को उन एक्सटेंशन में शामिल सुविधाओं के बिना पढ़ और प्रदर्शित कर सकता है जिन्हें वह नहीं समझता है।
फ़ाइल प्रारूप का पूरा विवरण जीआईएफ विनिर्देश में शामिल है।
जीआईएफ पैलेट-आधारित है: फ़ाइल में एक छवि (एक फ्रेम) में उपयोग किए गए रंगों में उनकेआरजीबीमान पैलेट तालिका में परिभाषित होते हैं जो २५६ प्रविष्टियों तक हो सकते हैं, और छवि के लिए आँकड़ा उनके सूचकांक द्वारा रंगों को संदर्भित करता है ( ०–२५५) पैलेट टेबल में। पैलेट में रंग की परिभाषा लाखों रंगों (प्रत्येक प्राथमिक के लिए २शेड्स, ८ बिट) के रंग स्थान से खींची जा सकती है, लेकिन एक फ्रेम द्वारा उपयोग किए जा सकने वाले रंगों की अधिकतम संख्या २५६ है। जब जीआईएफ विकसित किया गया था तो यह सीमा उचित लग रही थी क्योंकि कुछ लोग एक साथ अधिक रंग प्रदर्शित करने के लिए हार्डवेयर का खर्च उठा सकते थे। साधारण ग्राफिक्स, रेखा चित्र, कार्टून और ग्रे-स्केल तस्वीरों में आमतौर पर २५६ से कम रंगों की आवश्यकता होती है।
प्रत्येक फ्रेम एक इंडेक्स को "पारदर्शी पृष्ठभूमि रंग" के रूप में नामित कर सकता है: इस इंडेक्स को सौंपा गया कोई भी पिक्सेल पृष्ठभूमि से उसी स्थिति में पिक्सेल के रंग को लेता है, जिसे एनीमेशन के पिछले फ्रेम द्वारा निर्धारित किया जा सकता है।
कई तकनीकों, जिन्हें सामूहिक रूप से डीथरिंग कहा जाता है, को रंगों की एक विस्तृत श्रृंखला को एक छोटे रंग पैलेट के साथ दो या दो से अधिक रंगों के पिक्सेल का उपयोग करके रंगों के बीच में अनुमानित करने के लिए विकसित किया गया है। ये तकनीकें गहरे रंग के रिज़ॉल्यूशन को अनुमानित करने के लिए स्थानिक रिज़ॉल्यूशन का त्याग करती हैं। जीआईएफ विनिर्देश का हिस्सा नहीं होने पर, डीथरिंग का उपयोग छवियों में बाद में जीआईएफ छवियों के रूप में एन्कोड किया जा सकता है। यह अक्सर जीआईएफ छवियों के लिए एक आदर्श समाधान नहीं है, क्योंकि स्थानिक संकल्प का नुकसान आम तौर पर स्क्रीन पर एक छवि को अस्पष्ट दिखता है, और क्योंकि जीआईएफ के मुख्य उद्देश्य के खिलाफ काम करते हुए, डिथरिंग पैटर्न अक्सर छवि आँकड़ा की संपीड़ितता में हस्तक्षेप करते हैं।
ग्राफिकल वेब ब्राउज़र के शुरुआती दिनों में , ८-बिट बफ़र्स (केवल २५६ रंगों की अनुमति) वाले ग्राफिक्स कार्ड आम थे औरवेबसेफ पैलेटका उपयोग करके जीआईएफ चित्र बनाना काफी सामान्य था।इसने अनुमानित प्रदर्शन सुनिश्चित किया, लेकिन रंगों की पसंद को गंभीर रूप से सीमित कर दिया। जब २४-बिट रंग आदर्श बन गया, तो पैलेट को अलग-अलग छवियों के लिए इष्टतम रंगों के साथ पॉप्युलेट किया जा सकता था।
छोटी छवियों के लिए एक छोटी रंग तालिका पर्याप्त हो सकती है, और रंग तालिका को छोटा रखने से फ़ाइल को तेज़ी से डाउनलोड किया जा सकता है। ८७ए और ८९ए दोनों विनिर्देश १ से ८ तक किसी भीnके लिए २रंगों के रंग तालिकाओं की अनुमति देते हैं। अधिकांश ग्राफिक्स एप्लिकेशन इनमें से किसी भी तालिका आकार के साथ जीआईएफ छवियों को पढ़ेंगे और प्रदर्शित करेंगे; लेकिन कुछ चित्रबनातेसमय सभी आकारों का समर्थन नहीं करते हैं। २, १६ और २५६ रंगों की तालिकाएँ व्यापक रूप से समर्थित हैं।
हालांकि वास्तविक रंग छवियों के लिए जीआईएफ का उपयोग लगभग कभी नहीं किया जाता है, ऐसा करना संभव है।एक जीआईएफ छवि में कई छवि ब्लॉक शामिल हो सकते हैं, जिनमें से प्रत्येक का अपना २५६-रंग पैलेट हो सकता है, और एक पूर्ण छवि बनाने के लिए ब्लॉक को टाइल किया जा सकता है। वैकल्पिक रूप से, जीआईएफ८९ए विनिर्देश ने एक "पारदर्शी" रंग का विचार पेश किया, जहां प्रत्येक छवि ब्लॉक में २५५ दृश्यमान रंगों और एक पारदर्शी रंग का अपना पैलेट शामिल हो सकता है। ऊपर की परतों के पारदर्शी भागों के माध्यम से दिखाए जाने वाले प्रत्येक परत के दृश्य भाग के साथ छवि ब्लॉकों को परत करके एक पूर्ण छवि बनाई जा सकती है।
एक पूर्ण-रंगीन छवि को जीआईएफ के रूप में प्रस्तुत करने के लिए, मूल छवि को ऐसे छोटे क्षेत्रों में विभाजित किया जाना चाहिए जिनमें २५५ या २५६ से अधिक विभिन्न रंग न हों। इन क्षेत्रों में से प्रत्येक को फिर अपने स्थानीय पैलेट के साथ एक अलग छवि ब्लॉक के रूप में संग्रहीत किया जाता है और जब छवि ब्लॉक एक साथ प्रदर्शित होते हैं (या तो टाइलिंग या आंशिक रूप से पारदर्शी छवि ब्लॉकों को लेयर करके), पूर्ण, पूर्ण-रंगीन छवि दिखाई देती है। उदाहरण के लिए, एक छवि को १६ गुणा १६ पिक्सेल (कुल २५६ पिक्सेल) की टाइलों में तोड़ना सुनिश्चित करता है कि किसी भी टाइल में २५६ रंगों की स्थानीय पैलेट सीमा से अधिक नहीं है, हालांकि बड़ी टाइलों का उपयोग किया जा सकता है और समान रंगों का विलय हो जाता है जिसके परिणामस्वरूप रंग का कुछ नुकसान होता है जानकारी।
चूंकि प्रत्येक छवि ब्लॉक की अपनी स्थानीय रंग तालिका हो सकती है, इसलिए कई छवि ब्लॉक वाली जीआईएफ फ़ाइल बहुत बड़ी हो सकती है, जो पूर्ण-रंग वाले जीआईएफ की उपयोगिता को सीमित करती है।इसके अतिरिक्त, सभी जीआईएफ रेंडरिंग प्रोग्राम टाइल वाली या स्तरित छवियों को सही ढंग से हैंडल नहीं करते हैं। कई रेंडरिंग प्रोग्राम टाइलों या परतों को एनीमेशन फ्रेम के रूप में व्याख्या करते हैं और उन्हें एनीमेशन के रूप में अनुक्रम में प्रदर्शित करते हैंअधिकांश वेब ब्राउज़र स्वचालित रूप से फ्रेम को ०.१ सेकंड या उससे अधिक के विलंब समय के साथ प्रदर्शित करते हैं।
ध्यान दें कि निम्न तालिकाओं में हेक्स संख्याएं छोटे-एंडियन बाइट क्रम में हैं, जैसा कि प्रारूप विनिर्देश निर्धारित करता है।
छवि पिक्सेल आँकड़ा, ऊपर बाईं ओर से क्षैतिज रूप से स्कैन किया जाता है,लेम्पेल-ज़िव-वेल्च एन्कोडिंगद्वारा कोड में परिवर्तित किया जाता है जिसे फ़ाइल में संग्रहीत करने के लिए बाइट्स में मैप किया जाता है। पिक्सेल कोड आमतौर पर बाइट्स के ८-बिट आकार से मेल नहीं खाते हैं, इसलिए कोड को "लिटिल-एंडियन" स्कीम द्वारा बाइट्स में पैक किया जाता है: पहले कोड का कम से कम महत्वपूर्ण बिट कम से कम महत्वपूर्ण बिट में संग्रहीत होता है। पहले बाइट, कोड के उच्च क्रम बिट्स को बाइट के उच्च क्रम बिट्स में आवश्यकतानुसार अगले बाइट के निम्न क्रम बिट्स में फैलाना। प्रत्येक बाद के कोड को कम से कम महत्वपूर्ण बिट से शुरू करके संग्रहीत किया जाता है जो पहले से उपयोग नहीं किया गया है।
यह बाइट स्ट्रीम फ़ाइल में "उप-ब्लॉक" की एक श्रृंखला के रूप में संग्रहीत है। प्रत्येक उप-ब्लॉक की अधिकतम लंबाई २५५ बाइट्स होती है और उप-ब्लॉक में आँकड़ा बाइट्स की संख्या को इंगित करने वाले बाइट के साथ उपसर्ग होता है। उप-ब्लॉक की श्रृंखला को एक खाली उप-ब्लॉक (एक एकल ० बाइट, ० आँकड़ा बाइट्स वाले उप-ब्लॉक को इंगित करता है) द्वारा समाप्त किया जाता है।
ऊपर की नमूना छवि के लिए ९-बिट कोड और बाइट्स के बीच प्रतिवर्ती मानचित्रण नीचे दिखाया गया है।
एक मामूली संपीड़न स्पष्ट है: शुरू में १५ बाइट्स द्वारा परिभाषित पिक्सेल रंग नियंत्रण कोड सहित १२ कोड बाइट्स द्वारा दर्शाए जाते हैं। ९-बिट कोड उत्पन्न करने वाली एन्कोडिंग प्रक्रिया नीचे दिखाई गई है। एक स्थानीय स्ट्रिंग पैलेट से पिक्सेल रंग संख्या जमा करती है, जब तक कोई आउटपुट क्रिया नहीं होती है, जब तक कि स्थानीय स्ट्रिंग को कोड तालिका में पाया जा सकता है। तालिका से पहले आने वाले पहले दो पिक्सेल का विशेष उपचार होता है, जो स्ट्रिंग्स के अतिरिक्त द्वारा अपने प्रारंभिक आकार से बढ़ता है। प्रत्येक आउटपुट कोड के बाद, स्थानीय स्ट्रिंग को नवीनतम पिक्सेल रंग में प्रारंभ किया जाता है (जिसे आउटपुट कोड में शामिल नहीं किया जा सकता है)।
स्पष्टता के लिए तालिका को ऊपर दिखाया गया है कि बढ़ती लंबाई के तारों का निर्माण किया जा रहा है। वह योजना कार्य कर सकती है लेकिन तालिका अप्रत्याशित मात्रा में स्मृति का उपभोग करती है। मेमोरी को व्यवहार में सहेजा जा सकता है, यह ध्यान में रखते हुए कि संग्रहीत की जाने वाली प्रत्येक नई स्ट्रिंग में एक वर्ण द्वारा संवर्धित पहले से संग्रहीत स्ट्रिंग होती है। प्रत्येक पते पर केवल दो शब्दों को संग्रहीत करना किफायती है: एक मौजूदा पता और एक वर्ण।
लेम्पेल-ज़िव-वेल्च एल्गोरिथ्म को प्रत्येक पिक्सेल के लिए तालिका की खोज की आवश्यकता होती है। ४०९६ पतों के माध्यम से एक रैखिक खोज कोडिंग को धीमा कर देगी। व्यवहार में कोड को संख्यात्मक मान के क्रम में संग्रहीत किया जा सकता है; यह प्रत्येक खोज को केवल १२ परिमाण तुलनाओं के साथ एक एसएआर (कुछउत्तरोत्तर असन्नीकरण एडीसीमें प्रयुक्त के रूप में क्रमिक सन्निकटन रजिस्टर) द्वारा करने की अनुमति देता है। इस दक्षता के लिए कोड और वास्तविक मेमोरी पतों के बीच कनवर्ट करने के लिए एक अतिरिक्त तालिका की आवश्यकता होती है; अतिरिक्त तालिका रखरखाव की आवश्यकता केवल तभी होती है जब एक नया कोड संग्रहीत किया जाता है जो पिक्सेल दर से बहुत कम होता है।
डिकोडिंग संग्रहीत बाइट्स को ९-बिट कोड पर वापस मैप करके शुरू होती है। जैसा कि नीचे दिखाया गया है, पिक्सेल रंगों को पुनर्प्राप्त करने के लिए इन्हें डीकोड किया गया है। एन्कोडर में उपयोग की गई तालिका के समान एक तालिका इस नियम द्वारा तार जोड़कर बनाई गई है:
उदाहरण में २५६ रंगों से छोटे पैलेट के लिए छोटी कोड लंबाई का उपयोग किया जा सकता है। यदि पैलेट केवल ६४ रंग है (इसलिए रंग अनुक्रमणिका ६ बिट चौड़े हैं), प्रतीक ० से ६३ तक हो सकते हैं, और प्रतीक की चौड़ाई ६ बिट्स ली जा सकती है, जिसमें कोड ७ बिट्स से शुरू होते हैं। वास्तव में प्रतीक की चौड़ाई को पैलेट के आकार से मेल खाने की आवश्यकता नहीं है: जब तक डिकोड किए गए मान हमेशा पैलेट में रंगों की संख्या से कम होते हैं, प्रतीक २ से ८ तक की कोई भी चौड़ाई हो सकते हैं, और पैलेट का आकार २ की किसी भी शक्ति का हो सकता है। २ से २५६ तक। उदाहरण के लिए, यदि पैलेट के केवल पहले चार रंगों (मान ० से ३) का उपयोग किया जाता है, तो प्रतीकों को ३ बिट्स से शुरू होने वाले कोड के साथ २ बिट चौड़ा लिया जा सकता है।
इसके विपरीत, प्रतीक की चौड़ाई ८ पर सेट की जा सकती है, भले ही केवल मान ० और १ का उपयोग किया गया हो; इन आँकड़ा के लिए केवल दो-रंग तालिका की आवश्यकता होगी। हालांकि इस तरह से फ़ाइल को एन्कोड करने का कोई मतलब नहीं होगा, कुछ ऐसा ही आमतौर पर द्वि-रंग छवियों के लिए होता है: न्यूनतम प्रतीक चौड़ाई २ है, भले ही केवल मान ० और १ का उपयोग किया गया हो।
कोड तालिका में प्रारंभ में ऐसे कोड होते हैं जो प्रक्रिया के दौरान जोड़े गए स्ट्रिंग्स के लिए दो विशेष कोडसीlआरऔरअंतऔर कोड को समायोजित करने के लिए प्रतीक आकार से एक बिट लंबे होते हैं। जब तालिका भर जाती है तो कोड की लंबाई बढ़ जाती है ताकि अधिक स्ट्रिंग्स के लिए स्थान दिया जा सके, अधिकतम कोड ४०९५ = एफएफएफ (हेक्स) तक। जैसा कि डिकोडर अपनी तालिका बनाता है, यह कोड की लंबाई में इन वृद्धि को ट्रैक करता है और यह आने वाले बाइट्स को तदनुसार अनपैक करने में सक्षम होता है।
जीआईएफ एन्कोडिंग प्रक्रिया को लेम्पेल-ज़िव-वेल्च संपीड़न के बिना एक फ़ाइल बनाने के लिए संशोधित किया जा सकता है जो अभी भी जीआईएफ छवि के रूप में देखने योग्य है। इस तकनीक को मूल रूप से पेटेंट उल्लंघन से बचने के तरीके के रूप में पेश किया गया था। ग्राफिक्स प्रोग्रामर के लिए असम्पीडित जीआईएफ एक उपयोगी मध्यवर्ती प्रारूप भी हो सकता है क्योंकि अलग-अलग पिक्सल पढ़ने या पेंटिंग के लिए सुलभ हैं। एक असम्पीडित जीआईएफ फ़ाइल को केवल एक छवि संपादक के माध्यम से पारित करके एक साधारण जीआईएफ फ़ाइल में परिवर्तित किया जा सकता है।
संशोधित एन्कोडिंग विधि लेम्पेल-ज़िव-वेल्च तालिका के निर्माण की उपेक्षा करती है और केवल रूट पैलेट कोड और क्लियर और स्टॉप के लिए कोड उत्सर्जित करती है। यह एक सरल एन्कोडिंग (कोड मानों और पैलेट कोड के बीच १-से-१ पत्राचार) उत्पन्न करता है, लेकिन सभी संपीड़न को त्याग देता है: छवि में प्रत्येक पिक्सेल एक आउटपुट कोड उत्पन्न करता है जो उसके रंग सूचकांक को दर्शाता है। एक असम्पीडित जीआईएफ को संसाधित करते समय, एक मानक जीआईएफ डिकोडर को इसकी डिक्शनरी टेबल पर स्ट्रिंग्स लिखने से नहीं रोका जाएगा, लेकिन कोड की चौड़ाई कभी नहीं बढ़नी चाहिए क्योंकि यह बिट्स की एक अलग पैकिंग को बाइट्स में ट्रिगर करता है।
यदि प्रतीक चौड़ाई n है, तो चौड़ाईn+1के कोड स्वाभाविक रूप से दो ब्लॉकों में आते हैं: एकल प्रतीकों को कोड करने के लिए2कोड का निचला ब्लॉक, और2कोड का ऊपरी ब्लॉक जिसका उपयोग डिकोडर द्वारा अनुक्रमों के लिए किया जाएगा एक से अधिक लंबाई। उस ऊपरी ब्लॉक में से, पहले दो कोड पहले ही लिए जा चुके हैं:2क्लियर के लिए और2+ 1स्टॉप के लिए। डिकोडर को ऊपरी ब्लॉक,2− 1में अंतिम कोड का उपयोग करने से भी रोका जाना चाहिए, क्योंकि जब डिकोडर उस स्लॉट को भरता है, तो यह कोड की चौड़ाई बढ़ा देगा। इस प्रकार ऊपरी ब्लॉक में डिकोडर के लिए2− 3कोड उपलब्ध हैं जो कोड की चौड़ाई में वृद्धि को ट्रिगर नहीं करेंगे। चूंकि डिकोडर तालिका को बनाए रखने में हमेशा एक कदम पीछे रहता है, यह एन्कोडर से पहला कोड प्राप्त करने पर तालिका प्रविष्टि उत्पन्न नहीं करता है, लेकिन प्रत्येक बाद के कोड के लिए एक उत्पन्न करेगा। इस प्रकार एन्कोडर कोड की चौड़ाई में वृद्धि को ट्रिगर किए बिना2− 2कोड उत्पन्न कर सकता है। इसलिए, एन्कोडर को कोडिंग डिक्शनरी को डिकोडर को रीसेट करने के लिए2− 2कोड या उससे कम के अंतराल पर अतिरिक्त क्लियर कोड का उत्सर्जन करना चाहिए। जीआईएफ मानक ऐसे अतिरिक्त क्लियर कोड को किसी भी समय छवि आँकड़ा में सम्मिलित करने की अनुमति देता है। समग्र आँकड़ा स्ट्रीम को उप-ब्लॉकों में विभाजित किया जाता है, जिनमें से प्रत्येक में १ से २५५ बाइट्स होते हैं।
उपरोक्त ३×५ छवि के नमूने के लिए, निम्नलिखित ९-बिट कोड "स्पष्ट" (१००) का प्रतिनिधित्व करते हैं, जिसके बाद स्कैन क्रम में छवि पिक्सेल और "स्टॉप" (१०१) होते हैं।
उपरोक्त कोड बाइट्स में मैप किए जाने के बाद, असम्पीडित फ़ाइल संपीड़ित फ़ाइल से इस प्रकार भिन्न होती है:
ठोस रंग की एक बड़ी छवि का तुच्छ उदाहरण जीआईएफ फ़ाइलों में उपयोग किए जाने वाले चर-लंबाई वाले लेम्पेल-ज़िव-वेल्च संपीड़न को प्रदर्शित करता है।
दिखाए गए कोड मान बाइट्स में पैक किए जाते हैं जिन्हें बाद में २५५ बाइट्स तक के ब्लॉक में पैक किया जाता है। छवि आँकड़ा का एक ब्लॉक एक बाइट से शुरू होता है जो अनुसरण करने के लिए बाइट्स की संख्या की घोषणा करता है। किसी छवि के लिए आँकड़ा का अंतिम ब्लॉक शून्य ब्लॉक-लंबाई बाइट द्वारा चिह्नित किया जाता है।
जीआईएफ विशिष्टता प्रत्येक छवि को जीआईएफ फ़ाइल की तार्किक स्क्रीन के भीतर यह निर्दिष्ट करने की अनुमति देती है कि यह इंटरलेस्ड है; यानी, इसके आँकड़ा ब्लॉक में रेखापुंज रेखाओं का क्रम अनुक्रमिक नहीं है। यह उस छवि के आंशिक प्रदर्शन की अनुमति देता है जिसे पूर्ण छवि पेंट करने से पहले पहचाना जा सकता है।
एक इंटरलेस्ड छवि को ऊपर से नीचे तक ८ पिक्सेल ऊंची स्ट्रिप्स में विभाजित किया जाता है, और छवि की पंक्तियों को निम्न क्रम में प्रस्तुत किया जाता है:
प्रत्येक पंक्ति के भीतर पिक्सेल इंटरलेस्ड नहीं होते हैं, लेकिन बाएं से दाएं क्रमिक रूप से प्रस्तुत किए जाते हैं। गैर-अंतःस्थापित छवियों के साथ, एक पंक्ति के आँकड़ा और अगले के लिए आँकड़ा के बीच कोई विराम नहीं है। यह संकेतक कि एक छवि इंटरलेस्ड है, संबंधित इमेज डिस्क्रिप्टर ब्लॉक में थोड़ा सा सेट है।
हालाँकि जीआईएफ को एक एनीमेशन माध्यम के रूप में डिज़ाइन नहीं किया गया था, लेकिन एक फ़ाइल में कई छवियों को संग्रहीत करने की इसकी क्षमता स्वाभाविक रूप से एक एनीमेशन अनुक्रम केफ्रेमको संग्रहीत करने के लिए प्रारूप का उपयोग करने का सुझाव देती है। एनिमेशनप्रदर्शितकरने की सुविधा के लिए, जीआईएफ८९ए स्पेक ने ग्राफिक कंट्रोल एक्सटेंशन (जीसीई) को जोड़ा, जो फ़ाइल में छवियों (फ्रेम) को समय की देरी के साथ चित्रित करने की अनुमति देता है, जिससे एकवीडियो क्लिपबनता है। एनीमेशन जीआईएफ में प्रत्येक फ्रेम को अपने स्वयं के जीसीई द्वारा पेश किया जाता है जो फ्रेम तैयार होने के बाद प्रतीक्षा करने के लिए समय की देरी को निर्दिष्ट करता है। फ़ाइल की शुरुआत में वैश्विक जानकारी डिफ़ॉल्ट रूप से सभी फ़्रेमों पर लागू होती है। आँकड़ा स्ट्रीम-ओरिएंटेड है, इसलिए प्रत्येक जीसीई की शुरुआत की फ़ाइल ऑफ़सेट पिछले आँकड़ा की लंबाई पर निर्भर करती है। प्रत्येक फ्रेम के भीतर लेम्पेल-ज़िव-वेल्च-कोडित छवि आँकड़ा को २५५ बाइट्स तक के उप-ब्लॉकों में व्यवस्थित किया जाता है; प्रत्येक उप-ब्लॉक का आकार बाइट द्वारा घोषित किया जाता है जो इससे पहले होता है।
डिफ़ॉल्ट रूप से, एक एनीमेशन केवल एक बार फ्रेम के अनुक्रम को प्रदर्शित करता है, अंतिम फ्रेम प्रदर्शित होने पर रुक जाता है। एनीमेशन को लूप में सक्षम करने के लिए,नेटस्केपने १९९० के दशक में नेटस्केप एप्लिकेशन ब्लॉक (एनएबी) को लागू करने के लिए एप्लिकेशन एक्सटेंशन ब्लॉक (विक्रेताओं को जीआईएफ फ़ाइल में एप्लिकेशन-विशिष्ट जानकारी जोड़ने की अनुमति देने के लिए) का उपयोग किया।एनीमेशन फ़्रेम के अनुक्रम से ठीक पहले रखा गया यह ब्लॉक, फ़्रेम के अनुक्रम को चलाने की संख्या को निर्दिष्ट करता है (१ से ६५५३५ बार) या इसे लगातार दोहराना चाहिए (शून्य हमेशा के लिए लूप को इंगित करता है)। इन दोहराए जाने वाले एनिमेशन के लिए समर्थन पहलेनेटस्केप नेविगेटरसंस्करण २.० में दिखाई दिया, और फिर अन्य ब्राउज़रों में फैल गया।अधिकांश ब्राउज़र अब Nएबी को पहचानते हैं और उसका समर्थन करते हैं, हालांकि यह जीआईएफ८९ए विनिर्देश का कड़ाई से हिस्सा नहीं है।
निम्न उदाहरण एनीमेशन फ़ाइल की संरचना को दिखाता हैरोटेटिंग अर्थ (बड़ा)। जीआईएफदिखाया गया है (थंबनेल के रूप में) लेख के इन्फोबॉक्स में।
प्रत्येक फ्रेम के लिए एनीमेशन विलंब जीसीई में एक सेकंड के सौवें हिस्से में निर्दिष्ट किया गया है। आँकड़ा की कुछ अर्थव्यवस्था संभव है जहां एक फ्रेम को केवल डिस्प्ले के पिक्सल के एक हिस्से को फिर से लिखने की आवश्यकता होती है, क्योंकि इमेज डिस्क्रिप्टर पूरी छवि के बजाय एक छोटे आयत को फिर से स्कैन करने के लिए परिभाषित कर सकता है। ब्राउज़र या अन्य डिस्प्ले जो एनिमेटेड जीआईएफ का समर्थन नहीं करते हैं, आमतौर पर केवल पहला फ्रेम दिखाते हैं।
एनिमेटेड जीआईएफ फ़ाइलों का आकार और रंग गुणवत्ता उन्हें बनाने के लिए उपयोग किए गए एप्लिकेशन के आधार पर महत्वपूर्ण रूप से भिन्न हो सकती है। फ़ाइल आकार को कम करने की रणनीतियों में सभी फ़्रेमों के लिए एक सामान्य वैश्विक रंग तालिका का उपयोग करना शामिल है (प्रत्येक फ़्रेम के लिए एक पूर्ण स्थानीय रंग तालिका के बजाय) और क्रमिक फ़्रेमों में कवर किए गए पिक्सेल की संख्या को कम करना (ताकि केवल पिक्सेल जो एक फ्रेम से एक फ्रेम में बदलते हैं) अगला बाद वाले फ्रेम में शामिल हैं)। अधिक उन्नत तकनीकों में मौजूदा लेम्पेल-ज़िव-वेल्च डिक्शनरी से बेहतर मिलान करने के लिए रंग अनुक्रमों को संशोधित करना शामिल है, जो हानिपूर्ण संपीड़न का एक रूप है। बस स्वतंत्र फ्रेम छवियों की एक श्रृंखला को एक समग्र एनीमेशन में पैक करने से बड़े फ़ाइल आकार प्राप्त होते हैं। मौजूदा जीआईएफ को देखते हुए फ़ाइल आकार को कम करने के लिए उपकरण उपलब्ध हैं।
मेटाडेटा को जीआईएफ फाइलों में एक टिप्पणी ब्लॉक, एक सादा पाठ ब्लॉक, या एक एप्लिकेशन-विशिष्ट एप्लिकेशन एक्सटेंशन ब्लॉक के रूप में संग्रहीत किया जा सकता है। कई ग्राफिक्स संपादक छवि को उत्पन्न करने के लिए उपयोग किए गए आँकड़ा को शामिल करने के लिए अनौपचारिक एप्लिकेशन एक्सटेंशन ब्लॉक का उपयोग करते हैं, ताकि इसे आगे के संपादन के लिए पुनर्प्राप्त किया जा सके।
इन सभी विधियों में तकनीकी रूप से मेटाआँकड़ा को उप-ब्लॉकों में विभाजित करने की आवश्यकता होती है ताकि एप्लिकेशन मेटाआँकड़ा ब्लॉक को इसकी आंतरिक संरचना को जाने बिना नेविगेट कर सकें।
एक्सटेंसिबल मेटाआँकड़ा प्लेटफ़ॉर्म मेटाआँकड़ा मानक ने जीआईएफ फाइलों में एक्सएमपी आँकड़ा को शामिल करने के लिए एक अनौपचारिक लेकिन अब व्यापक "एक्सएमपी आँकड़ा" एप्लिकेशन एक्सटेंशन ब्लॉक पेश किया।चूंकि एक्सएमपी आँकड़ा एनयूएल वर्णों के बिना यूटीएफ-८ का उपयोग करके एन्कोड किया गया है, इसलिए आँकड़ा में कोई ० बाइट्स नहीं हैं। आँकड़ा को औपचारिक उप-ब्लॉकों में तोड़ने के बजाय, एक्सटेंशन ब्लॉक एक "मैजिक ट्रेलर" के साथ समाप्त होता है जो आँकड़ा को उप-ब्लॉक के रूप में मानने वाले किसी भी एप्लिकेशन को अंतिम ० बाइट में रूट करता है जो उप-ब्लॉक श्रृंखला को समाप्त करता है।
१९७७ और १९७८ में जैकब ज़िव और अब्राहम लेम्पेल ने दोषरहित आँकड़ा-संपीड़न एल्गोरिदम के एक नए वर्ग पर एक जोड़ी पत्र प्रकाशित किए, जिसे अब सामूहिक रूप से एलज़ेड७७ और एलज़ेड७८ कहा जाता है। १९८३ में टेरी वेल्च ने एलज़ेड७८ का एक तेज़ संस्करण विकसित किया जिसेलेम्पेल-ज़िव-वेल्चनाम दिया गया।
वेल्च ने जून १९८३ में लेम्पेल-ज़िव-वेल्च पद्धति के लिए एक पेटेंट आवेदन दायर किया। परिणामी पेटेंट, यूS४५५८३०२, को दिसंबर १९८५ में प्रदान किया गया, स्पेरी कॉरपोरेशन को सौंपा गया, जो बाद में १९८६ में बरोज़ कॉर्पोरेशन में विलय हो गया औरयूनिसिसका गठन किया।यूनाइटेड किंगडम, फ्रांस, जर्मनी, इटली, जापान और कनाडा में और पेटेंट प्राप्त किए गए।
उपरोक्त पेटेंटों के अलावा, वेल्च के १९८३ के पेटेंट में कई अन्य पेटेंटों के उद्धरण भी शामिल हैं जिन्होंने इसे प्रभावित किया, जिनमें शामिल हैं:
जून १९८४ में वेल्च का एक लेख आई ट्रिपल ई पत्रिका में प्रकाशित हुआ था जिसमें पहली बार सार्वजनिक रूप से लेम्पेल-ज़िव-वेल्च तकनीक का वर्णन किया गया था।लेम्पेल-ज़िव-वेल्च एक लोकप्रिय आँकड़ा संपीड़न तकनीक बन गई और, जब पेटेंट दिया गया, तो यूनिसिस ने सौ से अधिक कंपनियों के साथ लाइसेंसिंग समझौते किए।
लेम्पेल-ज़िव-वेल्च की लोकप्रियता ने कंप्युसर्व को उनके जीआईएफ के संस्करण के लिए संपीड़न तकनीक के रूप में चुनने के लिए प्रेरित किया, जिसे १९८७ में विकसित किया गया था। उस समय, कंप्युसर्व को पेटेंट के बारे में जानकारी नहीं थी।यूनिसिस को पता चला कि जीआईएफ के संस्करण ने एलजेडडब्ल्यू संपीड़न तकनीक का इस्तेमाल किया और जनवरी १९९३ में कंप्यूसर्व के साथ लाइसेंसिंग वार्ता में प्रवेश किया। बाद के समझौते की घोषणा २४ दिसंबर १९९४ को की गई।यूनिसिस ने कहा कि उन्हें उम्मीद है कि एलजेडडब्ल्यू पेटेंट का उपयोग करने वाली सभी प्रमुख वाणिज्यिक ऑनलाइन सूचना सेवा कंपनियां यूनिसिस से उचित दर पर प्रौद्योगिकी का लाइसेंस लेंगी, लेकिन उन्हें गैर-व्यावसायिक, गैर-लाभ जीआईएफ-आधारित एप्लिकेशन, जिनमें ऑनलाइन सेवाओं पर उपयोग के लिए शामिल हैं।
इस घोषणा के बाद, कंप्युसर्व और यूनिसिस की व्यापक निंदा हुई, और कई सॉफ़्टवेयर डेवलपर्स ने जीआईएफ का उपयोग बंद करने की धमकी दी। पीएनजी प्रारूप (नीचे देखें) को १९९५ में एक इच्छित प्रतिस्थापन के रूप में विकसित किया गया था।हालांकि, पीएनजी प्रारूप के लिए वेब ब्राउज़र और अन्य सॉफ्टवेयर के निर्माताओं से समर्थन प्राप्त करना मुश्किल साबित हुआ और जीआईएफ को बदलना संभव नहीं था, हालांकि पीएनजी की लोकप्रियता में धीरे-धीरे वृद्धि हुई है।इसलिए, एलजेडडब्ल्यू संपीड़न के बिना जीआईएफ विविधताएं विकसित की गईं। उदाहरण के लिए,एरिक एस. रेमंडके जिफलिब पर आधारित लिबुंगिफ पुस्तकालय, जीआईएफ के निर्माण की अनुमति देता है जो आँकड़ा प्रारूप का पालन करता है लेकिन संपीड़न सुविधाओं से बचा जाता है, इस प्रकार यूनिसिस एलजेडडब्ल्यू पेटेंट के उपयोग से बचा जाता है।२००१ के एकडॉ. डोब केलेख ने एलजेडडब्ल्यू-संगत एन्कोडिंग को उसके पेटेंट का उल्लंघन किए बिना प्राप्त करने का एक तरीका बताया।
अगस्त १९९९ में यूनिसिस ने अपने लाइसेंसिंग अभ्यास का विवरण बदल दिया, कुछ गैर-वाणिज्यिक और निजी वेबसाइटों के मालिकों के लिए $५००० या $७५०० के एकमुश्त लाइसेंस शुल्क के भुगतान पर लाइसेंस प्राप्त करने के विकल्प की घोषणा की।वेबसाइट मालिकों या अन्य जीआईएफ उपयोगकर्ताओं के लिए ऐसे लाइसेंस की आवश्यकता नहीं थी, जिन्होंने जीआईएफ उत्पन्न करने के लिए लाइसेंस प्राप्त सॉफ़्टवेयर का उपयोग किया था। फिर भी, यूनिसिस को हजारों ऑनलाइन हमलों और उपयोगकर्ताओं के अपमानजनक ईमेल के अधीन किया गया था, यह मानते हुए कि उनसे $ ५००० का शुल्क लिया जाएगा या उनकी वेबसाइटों पर जीआईएफ का उपयोग करने के लिए मुकदमा चलाया जाएगा। सैकड़ों गैर-लाभकारी संगठनों, स्कूलों और सरकारों को मुफ्त लाइसेंस देने के बावजूद, यूनिसिस कोई अच्छा प्रचार उत्पन्न करने में पूरी तरह से असमर्थ था और लीग फॉर प्रोग्रामिंग फ्रीडम जैसे व्यक्तियों और संगठनों द्वारा निंदा करना जारी रखा, जिन्होंने १९९९ में "बर्न ऑल जीआईएफ" अभियान शुरू किया था।
यूनाइटेड स्टेट्स लेम्पेल-ज़िव-वेल्च पेटेंट २० जून २००३ को समाप्त हो गया।यूनाइटेड किंगडम, फ्रांस, जर्मनी और इटली में समकक्ष पेटेंट १८ जून २००४ को समाप्त हो गए, जापानी पेटेंट २० जून २००४ को समाप्त हो गए, और कनाडाई पेटेंट ७ जुलाई २००४ को समाप्त हो गए।नतीजतन, जबकि यूनिसिस के पास एलजेडडब्ल्यू तकनीक में सुधार से संबंधित पेटेंट और पेटेंट आवेदन हैं,स्वयं एलजेडडब्ल्यू (और परिणामस्वरूप जीआईएफ) जुलाई २००४ से उपयोग करने के लिए स्वतंत्र हैं।
पोर्टेबल नेटवर्क ग्राफिक्स (पीएनजी) को जीआईएफ के प्रतिस्थापन के रूप में डिजाइन किया गया था ताकि एलजेडडब्ल्यू संपीड़न तकनीक पर यूनिसिस के पेटेंट के उल्लंघन से बचा जा सके।पीएनजी जीआईएफ की तुलना में बेहतर संपीड़न और अधिक सुविधाएँ प्रदान करता है,एनीमेशन एकमात्र महत्वपूर्ण अपवाद है। पीएनजी जीआईएफ की तुलना में उन उदाहरणों में अधिक उपयुक्त है जहां सच्चे-रंग इमेजिंग और अल्फा पारदर्शिता की आवश्यकता होती है।
हालांकि पीएनजी प्रारूप के लिए समर्थन धीरे-धीरे आया, नएवेब ब्राउज़रपीएनजी का समर्थन करते हैं।इंटरनेट एक्सप्लोररके पुराने संस्करण पीएनजी की सभी सुविधाओं का समर्थन नहीं करते हैं। संस्करण ६ और इससे पहले के संस्करण Mआईसीआरosoएफटी-विशिष्ट एचटीएमएल एक्सटेंशन का उपयोग किए बिना अल्फा चैनल पारदर्शिता का समर्थन नहीं करते हैं।पीएनजी छवियों का गामा सुधार संस्करण ८ से पहले समर्थित नहीं था, और पुराने संस्करणों में इन छवियों के प्रदर्शन में गलत रंग हो सकता है।
समान ८-बिट (या कम) छवि आँकड़ा के लिए, पीएनजी एन्कोडिंग में उपयोग की जाने वाली अधिक कुशल संपीड़न तकनीकों के कारण, पीएनजी फाइलें आम तौर पर समकक्ष जीआईएफ से छोटी होती हैं।जीआईएफ के लिए पूर्ण समर्थन मुख्य रूप से जटिल कैनवास संरचना द्वारा जटिल है, हालांकि यह कॉम्पैक्ट एनीमेशन सुविधाओं को सक्षम बनाता है।
वीडियो कई मुद्दों को हल करते हैं जो जीआईएफ वेब पर सामान्य उपयोग के माध्यम से प्रस्तुत करते हैं। उनमें अत्यधिक छोटे फ़ाइल आकार, ८-बिट रंग प्रतिबंध को पार करने की क्षमता, और बेहतर फ्रेम-हैंडलिंग और कोडेक के माध्यम से संपीड़न शामिल हैं।वेब ब्राउज़रमें जीआईएफ प्रारूप के लिए लगभग सार्वभौमिक समर्थन औरएचटीएमएलमानक में वीडियो के लिए आधिकारिक समर्थन की कमी के कारण जीआईएफ को वेब पर लघु वीडियो जैसी फाइलों को प्रदर्शित करने के उद्देश्य से प्रमुखता मिली।
अप्रैल २०१४ में४चैनने साइलेंटवेबएमवीडियो के लिए समर्थन जोड़ा, जो आकार में ३ एमबी और लंबाई में २ मिनट से कम है,और अक्टूबर २०१४ मेंइमिजरने साइट पर अपलोड की गई किसी भी जीआईएफ फाइलों को वीडियो में परिवर्तित करना और वीडियो देना शुरू कर दिया। एचटीएमएल प्लेयर को.जीआईएफवीएक्सटेंशन वाली वास्तविक फ़ाइल के रूप में लिंक करें।
साँचा:Graphics file formats