जीआईएफ

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

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

 

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

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

१९८९ में कंप्युसर्व ने ८९ए नामक एक उन्नत संस्करण जारी किया, इस संस्करण को जोड़ा गया:

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

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

कंप्युसर्व ने कई कंप्यूटरों के लिए डाउनलोड करने योग्य रूपांतरण सुविधाएं प्रदान करके जीआईएफ को अपनाने को प्रोत्साहित किया। उदाहरण के लिए, दिसंबर १९८७ तक, एक एप्पल आईआईजीएस उपयोगकर्ता अटारी एसटी या कमोडोर ६४ पर बनाए गए चित्रों को देख सकता था। जीआईएफ वेब साइटों पर आमतौर पर उपयोग किए जाने वाले पहले दो छवि प्रारूपों में से एक था, दूसरा ब्लैक एंड व्हाइट एक्सबीएम था।

सितंबर १९९५ में नेटस्केप नेविगेटर २.० ने एनिमेटेड जीआईएफ को लूप में जोड़ने की क्षमता को जोड़ा।

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

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

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

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

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

उच्चारण

 

जीआईएफ के पहले अक्षर का उच्चारण १९९० के दशक से विवादित रहा है। अंग्रेजी में सबसे आम उच्चारण जिफ और गिफ हैं। प्रारूप के रचनाकारों ने संक्षिप्त जीआईएफ को जिफ के रूप में किया, जिसमें विल्हाइट ने कहा कि उनका उच्चारण जानबूझकर अमेरिकी मूंगफली का मक्खन ब्रांड जिफ को प्रतिध्वनित करना है, और कंप्यूसर्व के कर्मचारी अक्सर चुटकी लेते हैं "चुनिंदा डेवलपर्स चुनते हैं। जीआईएफ", जिफ के टेलीविजन विज्ञापनों का एक धोखा है। हालांकि, शब्द को व्यापक रूप से गिफ और सर्वेक्षणों ने आम तौर पर दिखाया है कि यह गिफ का उच्चारण अधिक प्रचलित है।

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

उच्चारण पर असहमति के कारण इंटरनेट पर गर्मागर्म बहस छिड़ गई है। २०१३ के वेबबी पुरस्कार समारोह में लाइफटाइम अचीवमेंट पुरस्कार प्राप्त करने के अवसर पर, विल्हाइट ने सार्वजनिक रूप से हार्ड-जी उच्चारण को अस्वीकार कर दिया; उनके भाषण के कारण ट्विटर पर १७,००० से अधिक पोस्ट और दर्जनों समाचार लेख आए। व्हाइट हाउस और टीवी कार्यक्रम जेपर्डी! २०१३ में भी बहस में शामिल हुए। फरवरी २०२० में जेएम स्मकर कंपनी, जिफ ब्रांड के मालिक, ने एनिमेटेड इमेज आँकड़ाबेस और सर्च इंजन गिफी के साथ एक सीमित-संस्करण "जिफ बनाम जिफ" जारी करने के लिए भागीदारी की। जीआईएफ (#JआईFवीsGआईF के रूप में हैशटैग) पीनट बटर का जार जिसमें एक लेबल विनोदपूर्वक जिफ उच्चारण को विशेष रूप से मूंगफली के मक्खन को संदर्भित करने के लिए घोषित करता था, और जीआईएफ को विशेष रूप से गिफ उच्चारण के साथ उच्चारित किया जाता था।

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

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

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

इसके बाद फ़ाइल को खंडों में विभाजित किया जाता है। प्रत्येक को १-बाइट प्रहरी द्वारा पेश किया जाता है:

• एक छवि (०x२सी द्वारा प्रस्तुत, एक आस्की अल्पविराम

  ',' 

  )
• एक एक्सटेंशन ब्लॉक (०x२१ द्वारा प्रस्तुत, एक आस्की विस्मयादिबोधक बिंदु

  '!' 

  )
• ट्रेलर (मान ०x३बी का एक एकल बाइट, एक आस्की अर्धविराम

  ';' 

  ), जो फ़ाइल का अंतिम बाइट होना चाहिए।

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

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

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

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

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

जीआईएफ पैलेट-आधारित है: फ़ाइल में एक छवि (एक फ्रेम) में उपयोग किए गए रंगों में उनके आरजीबी मान पैलेट तालिका में परिभाषित होते हैं जो २५६ प्रविष्टियों तक हो सकते हैं, और छवि के लिए आँकड़ा उनके सूचकांक द्वारा रंगों को संदर्भित करता है ( ०–२५५) पैलेट टेबल में। पैलेट में रंग की परिभाषा लाखों रंगों (प्रत्येक प्राथमिक के लिए २ ^२४ शेड्स, ८ बिट) के रंग स्थान से खींची जा सकती है, लेकिन एक फ्रेम द्वारा उपयोग किए जा सकने वाले रंगों की अधिकतम संख्या २५६ है। जब जीआईएफ विकसित किया गया था तो यह सीमा उचित लग रही थी क्योंकि कुछ लोग एक साथ अधिक रंग प्रदर्शित करने के लिए हार्डवेयर का खर्च उठा सकते थे। साधारण ग्राफिक्स, रेखा चित्र, कार्टून और ग्रे-स्केल तस्वीरों में आमतौर पर २५६ से कम रंगों की आवश्यकता होती है।

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

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

ग्राफिकल वेब ब्राउज़र के शुरुआती दिनों में , ८-बिट बफ़र्स (केवल २५६ रंगों की अनुमति) वाले ग्राफिक्स कार्ड आम थे और वेबसेफ पैलेट का उपयोग करके जीआईएफ चित्र बनाना काफी सामान्य था।^{[किसके अनुसार?] ]} इसने अनुमानित प्रदर्शन सुनिश्चित किया, लेकिन रंगों की पसंद को गंभीर रूप से सीमित कर दिया। जब २४-बिट रंग आदर्श बन गया, तो पैलेट को अलग-अलग छवियों के लिए इष्टतम रंगों के साथ पॉप्युलेट किया जा सकता था।

छोटी छवियों के लिए एक छोटी रंग तालिका पर्याप्त हो सकती है, और रंग तालिका को छोटा रखने से फ़ाइल को तेज़ी से डाउनलोड किया जा सकता है। ८७ए और ८९ए दोनों विनिर्देश १ से ८ तक किसी भी n के लिए २ ⁿ रंगों के रंग तालिकाओं की अनुमति देते हैं। अधिकांश ग्राफिक्स एप्लिकेशन इनमें से किसी भी तालिका आकार के साथ जीआईएफ छवियों को पढ़ेंगे और प्रदर्शित करेंगे; लेकिन कुछ चित्र बनाते समय सभी आकारों का समर्थन नहीं करते हैं। २, १६ और २५६ रंगों की तालिकाएँ व्यापक रूप से समर्थित हैं।

असली रंग

हालांकि वास्तविक रंग छवियों के लिए जीआईएफ का उपयोग लगभग कभी नहीं किया जाता है, ऐसा करना संभव है। एक जीआईएफ छवि में कई छवि ब्लॉक शामिल हो सकते हैं, जिनमें से प्रत्येक का अपना २५६-रंग पैलेट हो सकता है, और एक पूर्ण छवि बनाने के लिए ब्लॉक को टाइल किया जा सकता है। वैकल्पिक रूप से, जीआईएफ८९ए विनिर्देश ने एक "पारदर्शी" रंग का विचार पेश किया, जहां प्रत्येक छवि ब्लॉक में २५५ दृश्यमान रंगों और एक पारदर्शी रंग का अपना पैलेट शामिल हो सकता है। ऊपर की परतों के पारदर्शी भागों के माध्यम से दिखाए जाने वाले प्रत्येक परत के दृश्य भाग के साथ छवि ब्लॉकों को परत करके एक पूर्ण छवि बनाई जा सकती है।

 

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

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

माइक्रोसॉफ्ट पेंट एक छोटी श्वेत-श्याम छवि को निम्न जीआईएफ फ़ाइल के रूप में सहेजता है (सचित्र बढ़े हुए)। पेंट जीआईएफ का इष्टतम उपयोग नहीं करता है; अनावश्यक रूप से बड़ी रंग तालिका (प्रयुक्त २ के बजाय पूर्ण २५६ रंगों को संग्रहीत करना) और प्रतीक चौड़ाई के कारण, यह जीआईएफ फ़ाइल १५-पिक्सेल छवि का एक कुशल प्रतिनिधित्व नहीं है। हालांकि ग्राफिक कंट्रोल एक्सटेंशन ब्लॉक कलर इंडेक्स १६ (हेक्साडेसिमल १०) को पारदर्शी घोषित करता है, लेकिन उस इंडेक्स का इस्तेमाल इमेज में नहीं किया जाता है। छवि आँकड़ा में प्रदर्शित होने वाले एकमात्र रंग सूचकांक दशमलव ४० और २५५ हैं, जिन्हें वैश्विक रंग तालिका क्रमशः काले और सफेद रंग में मैप करती है।

सैम्पल तस्वीर (बड़ी की गई), असल कद ३ पिक्सेल चौड़ा और ५ ऊँचा

ध्यान दें कि निम्न तालिकाओं में हेक्स संख्याएं छोटे-एंडियन बाइट क्रम में हैं, जैसा कि प्रारूप विनिर्देश निर्धारित करता है।

छवि कोडिंग

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

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

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

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

तालिका ९-बिट            स्ट्रिंग - > कोड कोड क्रिया              #० | ०००एच ९-बिट कोड की रूट टेबल को इनिशियलाइज़ करें           पैलेट | :            रंग | :             #२५५ | ०एफएफएच              क्लियर | १००एच              अंत | १०१एच                | १००एच साफ़ पिक्सेल लोकल | रंग पैलेट स्ट्रिंग | काला # ४० २८ | ०२८एच पहला पिक्सेल हमेशा आउटपुट के लिए सफेद #२५५ एफएफ | तालिका में पाया गया स्ट्रिंग          २८ एफएफ | १०२एच हमेशा तालिका में पहली स्ट्रिंग जोड़ें         एफएफ | स्थानीय स्ट्रिंग प्रारंभ करें सफेद #२५५ एफएफ एफएफ | तालिका में स्ट्रिंग नहीं मिली                | ०एफएफएच - पिछले स्ट्रिंग के लिए आउटपुट कोड          एफएफ एफएफ | १०३एच - तालिका में नवीनतम स्ट्रिंग जोड़ें         एफएफ | - स्थानीय स्ट्रिंग प्रारंभ करें सफेद #२५५ एफएफ एफएफ | तालिका में पाया गया स्ट्रिंग ब्लैक # ४० एफएफ एफएफ २८ | तालिका में स्ट्रिंग नहीं मिली                | १०३एच - पिछले स्ट्रिंग के लिए आउटपुट कोड          एफएफ एफएफ २८ | १०४एच - तालिका में नवीनतम स्ट्रिंग जोड़ें         २८ | - स्थानीय स्ट्रिंग प्रारंभ करें सफेद #२५५ २८ एफएफ | तालिका में पाया गया स्ट्रिंग सफेद #२५५ २८ एफएफ एफएफ | तालिका में स्ट्रिंग नहीं मिली                | १०२एच - पिछले स्ट्रिंग के लिए आउटपुट कोड          २८ एफएफ एफएफ | १०५एच - तालिका में नवीनतम स्ट्रिंग जोड़ें         एफएफ | - स्थानीय स्ट्रिंग प्रारंभ करें सफेद #२५५ एफएफ एफएफ | तालिका में पाया गया स्ट्रिंग सफेद #२५५ एफएफ एफएफ एफएफ | तालिका में स्ट्रिंग नहीं मिली                | १०३एच - पिछले स्ट्रिंग के लिए आउटपुट कोड          एफएफ एफएफ एफएफ | १०६एच - तालिका में नवीनतम स्ट्रिंग जोड़ें         एफएफ | - स्थानीय स्ट्रिंग प्रारंभ करें सफेद #२५५ एफएफ एफएफ | तालिका में पाया गया स्ट्रिंग सफेद #२५५ एफएफ एफएफ एफएफ | तालिका में पाया गया स्ट्रिंग सफेद #२५५ एफएफ एफएफ एफएफ एफएफ | तालिका में स्ट्रिंग नहीं मिली                | १०६एच - पिछले स्ट्रिंग के लिए आउटपुट कोड          एफएफ एफएफ एफएफ एफएफ | १०७एच - तालिका में नवीनतम स्ट्रिंग जोड़ें         एफएफ | - स्थानीय स्ट्रिंग प्रारंभ करें सफेद #२५५ एफएफ एफएफ | तालिका में पाया गया स्ट्रिंग सफेद #२५५ एफएफ एफएफ एफएफ | तालिका में पाया गया स्ट्रिंग सफेद #२५५ एफएफ एफएफ एफएफ एफएफ | तालिका में पाया गया स्ट्रिंग                           कोई और पिक्सेल नहीं                      १०७एच - अंतिम स्ट्रिंग के लिए आउटपुट कोड                      १०१एच अंत 

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

लेम्पेल-ज़िव-वेल्च एल्गोरिथ्म को प्रत्येक पिक्सेल के लिए तालिका की खोज की आवश्यकता होती है। ४०९६ पतों के माध्यम से एक रैखिक खोज कोडिंग को धीमा कर देगी। व्यवहार में कोड को संख्यात्मक मान के क्रम में संग्रहीत किया जा सकता है; यह प्रत्येक खोज को केवल १२ परिमाण तुलनाओं के साथ एक एसएआर (कुछ उत्तरोत्तर असन्नीकरण एडीसी में प्रयुक्त के रूप में क्रमिक सन्निकटन रजिस्टर) द्वारा करने की अनुमति देता है। इस दक्षता के लिए कोड और वास्तविक मेमोरी पतों के बीच कनवर्ट करने के लिए एक अतिरिक्त तालिका की आवश्यकता होती है; अतिरिक्त तालिका रखरखाव की आवश्यकता केवल तभी होती है जब एक नया कोड संग्रहीत किया जाता है जो पिक्सेल दर से बहुत कम होता है।

छवि डिकोडिंग

डिकोडिंग संग्रहीत बाइट्स को ९-बिट कोड पर वापस मैप करके शुरू होती है। जैसा कि नीचे दिखाया गया है, पिक्सेल रंगों को पुनर्प्राप्त करने के लिए इन्हें डीकोड किया गया है। एन्कोडर में उपयोग की गई तालिका के समान एक तालिका इस नियम द्वारा तार जोड़कर बनाई गई है:

खिसक जाना ९-बिट - ---> स्थानीय टेबल पिक्सेल कोड कोड कोड - > स्ट्रिंग पैलेट रंग क्रिया १००एच ०००एच | #० ९-बिट कोड की रूट टेबल को इनिशियलाइज़ करें           : | पैलेट           : | रंग की           ०एफएफएच | #२५५           १०० घंटे | स्पष्ट           १०१ह | समाप्त ०२८एच | #४० BLACK डीकोड १ पिक्सेल ०एफएफएच ०२८एच | आवक कोड तालिका में पाया गया              | #२५५ WHITE - तालिका से आउटपुट स्ट्रिंग           १०२एच | २८ एफएफ - तालिका में जोड़ें १०३एच ०एफएफएच | आने वाला कोड तालिका में नहीं मिला           १०३ह | एफएफ एफएफ - तालिका में जोड़ें              | - तालिका से आउटपुट स्ट्रिंग              | #२५५ WHITE              | #२५५ WHITE १०२एच १०३एच | आवक कोड तालिका में पाया गया              | - तालिका से आउटपुट स्ट्रिंग              | #४० BLACK              | #२५५ WHITE           १०४एच | एफएफ एफएफ २८ - तालिका में जोड़ें १०३ह १०२ह | आवक कोड तालिका में पाया गया              | - तालिका से आउटपुट स्ट्रिंग              | #२५५ WHITE              | #२५५ WHITE           १०५एच | २८ एफएफ एफएफ - तालिका में जोड़ें १०६ह १०३ह | आने वाला कोड तालिका में नहीं मिला           १०६एच | एफएफ एफएफ एफएफ - तालिका में जोड़ें              | - तालिका से आउटपुट स्ट्रिंग              | #२५५ WHITE              | #२५५ WHITE              | #२५५ WHITE १०७ह १०६ह | आने वाला कोड तालिका में नहीं मिला           १०७ह | एफएफ एफएफ एफएफ एफएफ - तालिका में जोड़ें              | - तालिका से आउटपुट स्ट्रिंग              | #२५५ WHITE              | #२५५ WHITE              | #२५५ WHITE              | #२५५ WHITE १०१ह | समाप्त 

लेम्पेल-ज़िव-वेल्च कोड लंबाई

उदाहरण में २५६ रंगों से छोटे पैलेट के लिए छोटी कोड लंबाई का उपयोग किया जा सकता है। यदि पैलेट केवल ६४ रंग है (इसलिए रंग अनुक्रमणिका ६ बिट चौड़े हैं), प्रतीक ० से ६३ तक हो सकते हैं, और प्रतीक की चौड़ाई ६ बिट्स ली जा सकती है, जिसमें कोड ७ बिट्स से शुरू होते हैं। वास्तव में प्रतीक की चौड़ाई को पैलेट के आकार से मेल खाने की आवश्यकता नहीं है: जब तक डिकोड किए गए मान हमेशा पैलेट में रंगों की संख्या से कम होते हैं, प्रतीक २ से ८ तक की कोई भी चौड़ाई हो सकते हैं, और पैलेट का आकार २ की किसी भी शक्ति का हो सकता है। २ से २५६ तक। उदाहरण के लिए, यदि पैलेट के केवल पहले चार रंगों (मान ० से ३) का उपयोग किया जाता है, तो प्रतीकों को ३ बिट्स से शुरू होने वाले कोड के साथ २ बिट चौड़ा लिया जा सकता है।

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

कोड तालिका में प्रारंभ में ऐसे कोड होते हैं जो प्रक्रिया के दौरान जोड़े गए स्ट्रिंग्स के लिए दो विशेष कोड सीlआर और अंत और कोड को समायोजित करने के लिए प्रतीक आकार से एक बिट लंबे होते हैं। जब तालिका भर जाती है तो कोड की लंबाई बढ़ जाती है ताकि अधिक स्ट्रिंग्स के लिए स्थान दिया जा सके, अधिकतम कोड ४०९५ = एफएफएफ (हेक्स) तक। जैसा कि डिकोडर अपनी तालिका बनाता है, यह कोड की लंबाई में इन वृद्धि को ट्रैक करता है और यह आने वाले बाइट्स को तदनुसार अनपैक करने में सक्षम होता है।

असम्पीडित जीआईएफ

एक ४६×४६ बिना कम्प्रेस किया हुआ ७ बिट का जीआईएफ (१२८ रंग, ८ बिट कोड)।

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

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

यदि प्रतीक चौड़ाई n है, तो चौड़ाई n+1 के कोड स्वाभाविक रूप से दो ब्लॉकों में आते हैं: एकल प्रतीकों को कोड करने के लिए 2ⁿ कोड का निचला ब्लॉक, और 2ⁿ कोड का ऊपरी ब्लॉक जिसका उपयोग डिकोडर द्वारा अनुक्रमों के लिए किया जाएगा एक से अधिक लंबाई। उस ऊपरी ब्लॉक में से, पहले दो कोड पहले ही लिए जा चुके हैं: 2ⁿ क्लियर के लिए और 2ⁿ + 1 स्टॉप के लिए। डिकोडर को ऊपरी ब्लॉक, 2ⁿ⁺¹ − 1 में अंतिम कोड का उपयोग करने से भी रोका जाना चाहिए, क्योंकि जब डिकोडर उस स्लॉट को भरता है, तो यह कोड की चौड़ाई बढ़ा देगा। इस प्रकार ऊपरी ब्लॉक में डिकोडर के लिए 2ⁿ − 3 कोड उपलब्ध हैं जो कोड की चौड़ाई में वृद्धि को ट्रिगर नहीं करेंगे। चूंकि डिकोडर तालिका को बनाए रखने में हमेशा एक कदम पीछे रहता है, यह एन्कोडर से पहला कोड प्राप्त करने पर तालिका प्रविष्टि उत्पन्न नहीं करता है, लेकिन प्रत्येक बाद के कोड के लिए एक उत्पन्न करेगा। इस प्रकार एन्कोडर कोड की चौड़ाई में वृद्धि को ट्रिगर किए बिना 2ⁿ − 2 कोड उत्पन्न कर सकता है। इसलिए, एन्कोडर को कोडिंग डिक्शनरी को डिकोडर को रीसेट करने के लिए 2ⁿ − 2 कोड या उससे कम के अंतराल पर अतिरिक्त क्लियर कोड का उत्सर्जन करना चाहिए। जीआईएफ मानक ऐसे अतिरिक्त क्लियर कोड को किसी भी समय छवि आँकड़ा में सम्मिलित करने की अनुमति देता है। समग्र आँकड़ा स्ट्रीम को उप-ब्लॉकों में विभाजित किया जाता है, जिनमें से प्रत्येक में १ से २५५ बाइट्स होते हैं।

उपरोक्त ३×५ छवि के नमूने के लिए, निम्नलिखित ९-बिट कोड "स्पष्ट" (१००) का प्रतिनिधित्व करते हैं, जिसके बाद स्कैन क्रम में छवि पिक्सेल और "स्टॉप" (१०१) होते हैं।

१०० ०२८ ०एफएफ ०एफएफ ०एफएफ ०२८ ०एफएफ ०एफएफ ०एफएफ ०एफएफ ०एफएफ ०एफएफ ०एफएफ ०एफएफ ०एफएफ ०एफएफ १०१ 

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

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

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

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

एक इंटरलेस्ड छवि को ऊपर से नीचे तक ८ पिक्सेल ऊंची स्ट्रिप्स में विभाजित किया जाता है, और छवि की पंक्तियों को निम्न क्रम में प्रस्तुत किया जाता है:

• पास १: प्रत्येक पट्टी से पंक्ति ० (सबसे ऊपर की रेखा)।
• दर्रा २: प्रत्येक पट्टी से पंक्ति ४।
• पास ३: प्रत्येक पट्टी से पंक्ति २ और ६।
• पास ४: प्रत्येक पट्टी से पंक्तियाँ १, ३, ५, और ७।

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

 

 

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

डिफ़ॉल्ट रूप से, एक एनीमेशन केवल एक बार फ्रेम के अनुक्रम को प्रदर्शित करता है, अंतिम फ्रेम प्रदर्शित होने पर रुक जाता है। एनीमेशन को लूप में सक्षम करने के लिए, नेटस्केप ने १९९० के दशक में नेटस्केप एप्लिकेशन ब्लॉक (एनएबी) को लागू करने के लिए एप्लिकेशन एक्सटेंशन ब्लॉक (विक्रेताओं को जीआईएफ फ़ाइल में एप्लिकेशन-विशिष्ट जानकारी जोड़ने की अनुमति देने के लिए) का उपयोग किया। एनीमेशन फ़्रेम के अनुक्रम से ठीक पहले रखा गया यह ब्लॉक, फ़्रेम के अनुक्रम को चलाने की संख्या को निर्दिष्ट करता है (१ से ६५५३५ बार) या इसे लगातार दोहराना चाहिए (शून्य हमेशा के लिए लूप को इंगित करता है)। इन दोहराए जाने वाले एनिमेशन के लिए समर्थन पहले नेटस्केप नेविगेटर संस्करण २.० में दिखाई दिया, और फिर अन्य ब्राउज़रों में फैल गया। अधिकांश ब्राउज़र अब Nएबी को पहचानते हैं और उसका समर्थन करते हैं, हालांकि यह जीआईएफ८९ए विनिर्देश का कड़ाई से हिस्सा नहीं है।

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

000..... ...001.. ......0. .......0 

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

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

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

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

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

१९७७ और १९७८ में जैकब ज़िव और अब्राहम लेम्पेल ने दोषरहित आँकड़ा-संपीड़न एल्गोरिदम के एक नए वर्ग पर एक जोड़ी पत्र प्रकाशित किए, जिसे अब सामूहिक रूप से एलज़ेड७७ और एलज़ेड७८ कहा जाता है। १९८३ में टेरी वेल्च ने एलज़ेड७८ का एक तेज़ संस्करण विकसित किया जिसे लेम्पेल-ज़िव-वेल्च नाम दिया गया।

वेल्च ने जून १९८३ में लेम्पेल-ज़िव-वेल्च पद्धति के लिए एक पेटेंट आवेदन दायर किया। परिणामी पेटेंट, यूS४५५८३०२, को दिसंबर १९८५ में प्रदान किया गया, स्पेरी कॉरपोरेशन को सौंपा गया, जो बाद में १९८६ में बरोज़ कॉर्पोरेशन में विलय हो गया और यूनिसिस का गठन किया। यूनाइटेड किंगडम, फ्रांस, जर्मनी, इटली, जापान और कनाडा में और पेटेंट प्राप्त किए गए।

उपरोक्त पेटेंटों के अलावा, वेल्च के १९८३ के पेटेंट में कई अन्य पेटेंटों के उद्धरण भी शामिल हैं जिन्होंने इसे प्रभावित किया, जिनमें शामिल हैं:

• एनईसी के जून कनात्सु से दो १९८० जापानी पेटेंट,
• जॉन एस होर्निंग से यूएस पेटेंट ४,०२१,७८२ (१९७४),
• क्लाउस ई. होल्ट्ज़ से यूएस पेटेंट ४,३६६,५५१ (१९७७), और
• कार्ल एकहार्ट हेंज से १९८१ का जर्मन पेटेंट।

जून १९८४ में वेल्च का एक लेख आई ट्रिपल ई पत्रिका में प्रकाशित हुआ था जिसमें पहली बार सार्वजनिक रूप से लेम्पेल-ज़िव-वेल्च तकनीक का वर्णन किया गया था। लेम्पेल-ज़िव-वेल्च एक लोकप्रिय आँकड़ा संपीड़न तकनीक बन गई और, जब पेटेंट दिया गया, तो यूनिसिस ने सौ से अधिक कंपनियों के साथ लाइसेंसिंग समझौते किए।

लेम्पेल-ज़िव-वेल्च की लोकप्रियता ने कंप्युसर्व को उनके जीआईएफ के संस्करण के लिए संपीड़न तकनीक के रूप में चुनने के लिए प्रेरित किया, जिसे १९८७ में विकसित किया गया था। उस समय, कंप्युसर्व को पेटेंट के बारे में जानकारी नहीं थी। यूनिसिस को पता चला कि जीआईएफ के संस्करण ने एलजेडडब्ल्यू संपीड़न तकनीक का इस्तेमाल किया और जनवरी १९९३ में कंप्यूसर्व के साथ लाइसेंसिंग वार्ता में प्रवेश किया। बाद के समझौते की घोषणा २४ दिसंबर १९९४ को की गई। यूनिसिस ने कहा कि उन्हें उम्मीद है कि एलजेडडब्ल्यू पेटेंट का उपयोग करने वाली सभी प्रमुख वाणिज्यिक ऑनलाइन सूचना सेवा कंपनियां यूनिसिस से उचित दर पर प्रौद्योगिकी का लाइसेंस लेंगी, लेकिन उन्हें गैर-व्यावसायिक, गैर-लाभ जीआईएफ-आधारित एप्लिकेशन, जिनमें ऑनलाइन सेवाओं पर उपयोग के लिए शामिल हैं।

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

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

यूनाइटेड स्टेट्स लेम्पेल-ज़िव-वेल्च पेटेंट २० जून २००३ को समाप्त हो गया। यूनाइटेड किंगडम, फ्रांस, जर्मनी और इटली में समकक्ष पेटेंट १८ जून २००४ को समाप्त हो गए, जापानी पेटेंट २० जून २००४ को समाप्त हो गए, और कनाडाई पेटेंट ७ जुलाई २००४ को समाप्त हो गए। नतीजतन, जबकि यूनिसिस के पास एलजेडडब्ल्यू तकनीक में सुधार से संबंधित पेटेंट और पेटेंट आवेदन हैं, स्वयं एलजेडडब्ल्यू (और परिणामस्वरूप जीआईएफ) जुलाई २००४ से उपयोग करने के लिए स्वतंत्र हैं।

पीएनजी

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

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

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

एनिमेशन प्रारूप

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

• एमएनजी ("मल्टीपल-इमेज नेटवर्क ग्राफिक्स") मूल रूप से एनिमेशन के लिए पीएनजी-आधारित समाधान के रूप में विकसित किया गया था। २००१ में एमएनजी संस्करण १.० पर पहुंच गया, लेकिन कुछ एप्लिकेशन इसका समर्थन करते हैं।

• एपीएनजी ("एनिमेटेड पोर्टेबल नेटवर्क ग्राफिक्स") को मोज़िला द्वारा २००६ में प्रस्तावित किया गया था। एपीएनजी एमएनजी प्रारूप के विकल्प के रूप में पीएनजी प्रारूप का विस्तार है। एपीएनजी २०१९ तक अधिकांश ब्राउज़रों द्वारा समर्थित है। एपीएनजी पीएनजी फाइलों को चेतन करने की क्षमता प्रदान करता है, जबकि डिकोडर में पश्चगामी संगतता बनाए रखता है जो एनीमेशन खंड (एमएनजी के विपरीत) को नहीं समझ सकता है। पुराने डिकोडर केवल एनिमेशन के पहले फ्रेम को रेंडर करेंगे।

पीएनजी समूह ने २० अप्रैल २००७ को आधिकारिक रूप से एपीएनजी को आधिकारिक विस्तार के रूप में खारिज कर दिया।

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

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

• वेबएम और
• वेबपी विकास में है और कुछ वेब ब्राउज़र द्वारा समर्थित हैं।

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

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

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

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

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

• वीपी९ केवल वाईयूवी ए४२० पिक्सेल प्रारूप में ४:२:० क्रोमा सबसैंपलिंग के साथ अल्फा कंपोजिटिंग का समर्थन करता है, जो कि जीआईएफ के लिए अनुपयुक्त हो सकता है जो महीन रंग विवरण के साथ रास्टराइज्ड वेक्टर ग्राफिक्स के साथ पारदर्शिता को जोड़ती है।

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

अप्रैल २०१४ में ४चैन ने साइलेंट वेबएम वीडियो के लिए समर्थन जोड़ा, जो आकार में ३ एमबी और लंबाई में २ मिनट से कम है, और अक्टूबर २०१४ में इमिजर ने साइट पर अपलोड की गई किसी भी जीआईएफ फाइलों को वीडियो में परिवर्तित करना और वीडियो देना शुरू कर दिया। एचटीएमएल प्लेयर को .जीआईएफवी एक्सटेंशन वाली वास्तविक फ़ाइल के रूप में लिंक करें।

• सॉफ्टवेयर पेटेंट

• GIFLIB परियोजना
• w3.org पर कल्पना-gif89a.txt GIF 89a विशिष्टता
• GIF 89a विनिर्देशन को HTML में सुधारा गया
• LZW और GIF समझाया
• एनिमेटेड जीआईएफ : ऑफ बुक (वेब सीरीज) द्वारा निर्मित एक छह मिनट का वृत्तचित्र
• GifCities (द जियोसिटीज एनिमेटेड GIF सर्च इंजन)

साँचा:Graphics file formats