GIF का विश्लेषण — फ़्रेम, देरी, पैलेट और फ़ाइल साइज़

Q: फ़्रेम की दोनों व्यू में क्या फ़र्क है?

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

प्राइवेसी का यह दावा कैसे जाँचा जा सकता है

आपके GIF के पास बाहर जाने का रास्ता ही नहीं है। Content-Security-Policy में वे सारे पते लिखे हैं जिनसे यह पेज बात कर सकता है, और उनमें से एक भी इस साइट का नहीं है। यहाँ ऐसा कोई ठिकाना है ही नहीं जहाँ आपकी फ़ाइल इकट्ठी की जा सके, और होता भी तो कोड में ऐसा कुछ नहीं है जो उसे वहाँ भेजे। पहले यहाँ connect-src 'none' लिखा था, जिसमें कोई अपवाद नहीं था। विज्ञापन की कीमत यही थी, और यह बता देना भी सौदे का हिस्सा है।

पढ़ने वाला हिस्सा इस रिपॉज़िटरी की चार फ़ाइलें हैं। फ़ाइल में क्या है, यह पता करने के लिए यहाँ ब्राउज़र का अपना GIF डिकोडर इस्तेमाल नहीं होता, क्योंकि वह डिकोडर यह नहीं बताता कि कोई बाइट कहाँ गया। इसलिए फ़ॉर्मैट हाथ से पढ़ा जाता है: src/gif.js ब्लॉक-दर-ब्लॉक चलता है, src/lzw.js पिक्सल खोलता है, src/frames.js उन्हें एक पर एक रखता है, और src/budget.js हिस्सों को वापस जोड़कर देखता है कि वे फ़ाइल के साइज़ के बराबर बैठते हैं या नहीं।

कमेंट और मेटाडेटा आपको दिखते हैं, और किसी को नहीं। किसी GIF में कमेंट ब्लॉक हो सकता है, किसी एडिट का ब्योरा देने वाला XMP पैकेट हो सकता है, या कलर प्रोफ़ाइल। यह पेज इन सबको छाप देता है। ये आपके सामने स्क्रीन पर आते हैं और वहीं तक रहते हैं। इस रिपॉज़िटरी में ऐसा कोई एनालिटिक्स इवेंट है ही नहीं जो इनमें से कुछ ले जाए, और होता भी तो यह पेज उसे भेज नहीं सकता।

Google क्या लोड करता है, और उसे क्या नहीं दिया जाता। विज्ञापन और माप वाली स्क्रिप्ट Google से आती हैं। इनमें से किसी को भी आपकी फ़ाइल के बारे में कुछ नहीं सौंपा जाता, न फ़ाइल, न थंबनेल, न नाम, न साइज़, न फ़्रेम की गिनती, न कोई कमेंट। GIF को पढ़ने, खोलने या बनाने वाली हर पंक्ति इसी ऑरिजिन से आती है और रिपॉज़िटरी में मौजूद है।

दान का बटन क्या लोड करता है, और उसे क्या नहीं दिया जाता। हेडर वाला “Buy me a coffee” बटन cdnjs.buymeacoffee.com की एक स्क्रिप्ट बनाती है और अक्षर Google Fonts से आते हैं। वह एक लिंक से ज़्यादा कुछ नहीं है। न वह आपकी विज़िट की खबर देता है, न उसे आपके या आपकी फ़ाइलों के बारे में कुछ मिलता है। जब तक आप क्लिक न करें कुछ नहीं होता, और क्लिक करने पर जो खुलेगा वह किसी और की साइट है।

यह ऑफ़लाइन भी चलता है। नेटवर्क काट दीजिए, इस पेज का हर हिस्सा काम करता रहेगा। सबसे आसान सबूत यही है। जो टूल आपका GIF एनालाइज़ करने के लिए कहीं भेजता, वह प्लग निकालते ही रुक जाता।

खुद जाँच लीजिए। ऊपर लिखी किसी भी बात को भरोसे पर मानने की ज़रूरत नहीं। यह पेज रिपॉज़िटरी के टेम्पलेट और कॉन्फ़िग से बनता है, एक ऐसी बिल्ड स्क्रिप्ट के ज़रिए जिसे आप पढ़ भी सकते हैं और खुद चला भी सकते हैं। उसका नतीजा dist ब्रांच पर कमिट रहता है, यानी जो सर्व हो रहा है और सोर्स से बिल्ड करने पर जो बनता है, दोनों का फ़र्क आप खुद देख सकते हैं:

github.com/A-Box-of-Tools/website

सबसे पहले पढ़ने लायक फ़ाइलें ये हैं — Content-Security-Policy के लिए config/site.toml, फ़ाइल में एक-एक ब्लॉक चलने वाले रीडर के लिए src/gif.js, खोलने वाले के लिए src/lzw.js, और बाइट का हिसाब रखने वाले के लिए src/budget.js। इनमें से किसी में भी ऐसी एक पंक्ति नहीं है जो नेटवर्क तक पहुँच सके।

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

एक GIF चुनिए

GIF यहाँ छोड़िए या क्लिक करके चुनिए — चलती हो या स्थिर, किसी भी साइज़ की

बाइट कहाँ गए

फ़ाइल का हर बाइट ठीक एक ही पंक्ति में है, और पंक्तियाँ मिलकर पूरी फ़ाइल बनती हैं। अगर न बनतीं, तो पट्टी चुपचाप खिंचकर फ़िट होने के बजाय आखिरी पंक्ति यह बता देती।

इस फ़ाइल के बाइट कहाँ गए
हिस्सा	बाइट	अनुपात
पूरी फ़ाइल	—	100%

{name} पढ़ी जा रही है… {name} GIF नहीं है: {why}। यह टूल खुद GIF प्रारूप पढ़ता है, इसलिए दूसरी फ़ाइलों के बारे में इसके पास कहने को कुछ नहीं है। {name} पढ़ी नहीं जा सकी: {why} फ़ाइल {available} बाइट पर खत्म हो जाती है, और {at} पर {wanted} बाइट और चाहिए थे यह फ़ाइल «GIF» से नहीं, {what} से शुरू होती है एक JPEG एक PNG एक RIFF फ़ाइल — कोई WebP या WAV एक PDF एक ज़िप फ़ाइल {bytes} बाइट कोड आकार {size} है, जबकि प्रारूप 2 से 8 तक की छूट देता है {n} फ़्रेम {n} फ़्रेम {n} रंग {n} रंग {n} प्रविष्टि {n} प्रविष्टियाँ प्रति-फ़्रेम {n} तालिका प्रति-फ़्रेम {n} तालिकाएँ {n} बार {n} बार {n} बाइट {minutes} मि {seconds} से {n}से {time} ({fps} fps) {n} फ़्रेम 0.02से से कम माँगते हैं, और हर ब्राउज़र उन्हें उसकी जगह 0.10से रोके रखता है। एक बार — कोई लूप ब्लॉक नहीं हमेशा {n} बार समस्या जान लेना ठीक है टिप्पणी {frames}। इनमें से {drawn} यहाँ बनाए गए हैं; बाकी इतने बड़े हैं कि सबको एक साथ स्मृति में नहीं रखा जा सकता, इसलिए उनके बारे में सिर्फ़ हेडर से बताया गया है। {frames}, इनमें से कोई भी पूरे कैनवस को नहीं ढकता। {frames}, सभी पूरे कैनवस को ढकते हैं। {frames}, इनमें से {n} पूरे कैनवस को ढकते हैं। बाकी {frames} दिखाइए फ़्रेम {n} अपने आप में क्या रखता है फ़्रेम {n} के बाद का कैनवस फ़्रेम {n} नहीं बनाया गया देरी {delay} → 0.10से आयत ⁦{left}, {top}⁩ पर ⁦{width} × {height}⁩ पैलेट {n} अपने खुद के वैश्विक वाला बिलकुल कोई नहीं पारदर्शी सूचकांक {n} नहीं आकार {size} — {share} इंटरलेस्ड हाँ संपीड़न {ratio}× गड़बड़ डेटा वक्त से पहले खत्म हो जाता है इस फ़ाइल की तालिकाएँ मिलकर {declared} घोषित करती हैं, पिक्सेल उनमें से {referenced} का ज़िक्र करते हैं, और उनमें से {different} एक-दूसरे से अलग हैं। {entries}, {size}, {frames} में साझा। फीकी प्रविष्टियाँ वे हैं जिनका ज़िक्र कोई पिक्सेल कभी नहीं करता। {tables} (कुल {size}) फ़्रेम {n} — {colours} {n} में से पहली 24 दिखाई गई हैं। बाकी डाउनलोड होने वाली रिपोर्ट में हैं। एक टिप्पणी। कोई व्यूअर इसे नहीं दिखाता, और फ़ाइल की हर प्रति इसे साथ ढोती है। लूप ब्लॉक, जो हमेशा चलाने को कहता है। यह GIF विशिष्टि का हिस्सा नहीं है: नेटस्केप ने इसे 1995 में गढ़ा और फिर भी सबने इसे लागू कर लिया। लूप ब्लॉक, जो {times} चलाने को कहता है। एक XMP पैकेट: वह XML जो कोई इमेज एडिटर यह दर्ज करने को लिखता है कि उसने क्या किया। इसे कुछ भी नहीं बनाता। एक ICC रंग प्रोफ़ाइल, जो बताती है कि पैलेट की संख्याएँ रंग के तौर पर क्या हैं। GIF में से इसे शायद ही कुछ पढ़ता हो। एक प्लेन-टेक्स्ट ब्लॉक, जो व्यूअर से तस्वीर के ऊपर टेक्स्ट बनाने को कहता है। यह 1989 की विशिष्टि में था और इसे कभी किसी ने लागू नहीं किया। एक एप्लिकेशन ब्लॉक। व्यूअर जिन्हें नहीं पहचानते उन्हें छोड़ देते हैं। चलती है लिखे अनुसार {time} असल में चलती है {time} - 0.02से से कम के {n} फ़्रेम हर ब्राउज़र 0.10से कर देता है दर {fps} फ़्रेम प्रति सेकंड लूप कोई लूप ब्लॉक नहीं - एक बार चलती है वैश्विक पैलेट {n} रंग कोई नहीं बनाए गए रंग पृष्ठभूमि सूचकांक कॉपी हो गया। यह सादा टेक्स्ट है, और सिर्फ़ आपके क्लिपबोर्ड तक गया है। इस ब्राउज़र ने पेज को क्लिपबोर्ड में लिखने नहीं दिया। इसके बजाय «डाउनलोड करें» का इस्तेमाल कीजिए। हेडर और स्क्रीन विवरण हस्ताक्षर, कैनवास का आकार और झंडे। तेरह बाइट, जो अब तक बने हर GIF में हैं। वैश्विक रंग तालिका तीन-तीन बाइट के {colours} रंग, जिन्हें हर वह फ़्रेम साझा करता है जो अपनी तालिका साथ नहीं लाता। इस फ़ाइल में यह है ही नहीं: हर फ़्रेम अपनी पैलेट खुद ढोता है। फ़्रेम-दर-फ़्रेम रंग तालिकाएँ ऐसे फ़्रेम की अपनी पैलेट जिसे दूसरे रंग चाहिए थे। हर बार, हर रंग के तीन बाइट। फ़्रेम के समय-ब्लॉक हर फ़्रेम के आठ बाइट: कितनी देर रुकेगा, समेटने का तरीका, और कौन-सा रंग पारदर्शी है। फ़्रेम विवरण हर फ़्रेम के ग्यारह बाइट: आयत कहाँ बैठा है, कितना बड़ा है, और कंप्रेसर किस कोड आकार से शुरू करता है। दबाए हुए पिक्सल तस्वीर खुद, LZW से दबाई हुई। ठीक-ठाक GIF में यही करीब-करीब पूरी फ़ाइल होती है। ब्लॉक की चौखट हर 255 बाइट डेटा पर एक लंबाई-बाइट, और हर लड़ी को खत्म करने के लिए एक शून्य। इससे बचा नहीं जा सकता, और यह देखने लायक है। टिप्पणियाँ और मेटाडेटा लूप ब्लॉक, टिप्पणियाँ, रंग प्रोफ़ाइल, और कोई भी XMP जो किसी संपादक ने पीछे छोड़ दिया हो। समापन एक बाइट, जो कहता है कि फ़ाइल खत्म। अंत के बाद के बाइट समापन के आगे पड़ा डेटा। कोई डिकोडर इसे पढ़ता नहीं, और यह बस बोझ है। हिसाब में न आया उन ब्लॉकों के भीतर के बाइट जहाँ यह रीडर रुक गया। बीच ब्लॉक में खत्म होने वाली फ़ाइल कुछ ऐसे बाइट छोड़ जाती है। दो बार गिना गया ब्लॉक एक-दूसरे पर चढ़े हुए हैं, यानी यह फ़ाइल खुद ही तय नहीं कर पा रही कि वे शुरू कहाँ होते हैं। तय नहीं जहाँ है वहीं रहने दो पृष्ठभूमि पर लौटा दो नीचे जो था वह लौटा दो आरक्षित ({n}) समेटना GIF विश्लेषण — {name} abox.tools/gif-analyzer/ ने इसे पूरी तरह ब्राउज़र के भीतर पढ़ा। फ़ाइल कहीं अपलोड नहीं हुई। फ़ाइल संस्करण कैनवास ⁦{width} x {height}⁩ पिक्सल आकार {rounded} ({exact}) फ़्रेम बाइट कहाँ गए कुल जो नज़र में आता है फ़्रेम फ़ाइल में साथ चलता पाठ वैश्विक पैलेट अपने {colours} साझा पूरा कैनवास क्रम कहाँ आकार ठहराव समेटना पैलेट बाइट फ़ाइल अंत-बाइट के बिना ही खत्म हो जाती है, यानी अधूरी है — कोई डाउनलोड जो जल्दी रुक गया, या कटी हुई फ़ाइल। बाइट {at} का मान 0x{marker} है, और इस प्रारूप का कोई भी ब्लॉक ऐसे शुरू नहीं होता। उसके बाद का सब कुछ छोड़ दिया गया। {first} और {second} पर लगातार दो ग्राफ़िक कंट्रोल ब्लॉक हैं। पहला किसी तस्वीर का ब्योरा नहीं देता और कुछ नहीं करता। {at} से शुरू होने वाले ब्लॉक के बीचोंबीच फ़ाइल खत्म हो जाती है। {detail}। शब्दकोश में कुछ आने से पहले ही कोड {code} आ गया। दर्शक जितना बना सकेगा बनाएगा और आयत का बाकी हिस्सा खाली छोड़ देगा। कोड {code} शब्दकोश की {code} प्रविष्टि की ओर इशारा करता है, जबकि प्रविष्टियाँ केवल {entries} हैं। दर्शक जितना बना सकेगा बनाएगा और आयत का बाकी हिस्सा खाली छोड़ देगा। इस फ़ाइल में कोई फ़्रेम नहीं है। शीर्ष पढ़ा गया, पर उसके बाद कोई इमेज ब्लॉक नहीं आया। यह जो भी हो, कोई दर्शक इससे कुछ नहीं बनाएगा। फ़ाइल साफ़-सुथरे ढंग से खत्म नहीं होती। फ़ाइल के अंत के बाद {bytes} पड़े हैं। हर डिकोडर अंत-बाइट पर रुक जाता है, इसलिए ये न कभी पढ़े जाते हैं न कभी बनाए जाते हैं। आम तौर पर यह पहली फ़ाइल के पीछे जुड़ी दूसरी फ़ाइल होती है, या कोई प्रोग्राम जो अपने आगे तक लिख गया। फ़ाइल को अंत-बाइट पर काट देने से कुछ नहीं जाता। एक फ़्रेम 0.02 सेकंड से कम ठहरने को कहता है, और कोई ब्राउज़र ऐसा नहीं करेगा। {count} फ़्रेम 0.02 सेकंड से कम ठहरने को कहते हैं, और कोई ब्राउज़र ऐसा नहीं करेगा। नेटस्केप के बाद का हर ब्राउज़र सेकंड के सौवें हिस्से से दो से कम की देरी को दस तक ऊपर कर देता है — यह नियम 1996 में उस ज़माने के घूमते ग्लोबों के लिए लिखा गया था और कभी हटाया नहीं गया। इसलिए यह ऐनिमेशन कहता है कि वह {nominal} चलता है और असल में {real} चलता है, करीब {factor} गुना धीमा। 0.01 की जगह 0.02 लिखने पर उसे वही रफ़्तार मिल जाती है जो वह माँग रहा है। हर फ़्रेम की देरी शून्य है। फ़ाइल समय बताती ही नहीं, इसलिए यह किस रफ़्तार से चलेगा पूरी तरह दर्शक पर है — आम तौर पर दस फ़्रेम प्रति सेकंड, पर इसकी कोई गारंटी नहीं। दो ब्राउज़र इसे दो अलग रफ़्तारों पर चला सकते हैं और दोनों सही होंगे। फ़्रेमों का समय एक-सा नहीं है: {shortest} से {longest} तक, {delays} अलग-अलग देरियाँ। आखिरी फ़्रेम को देर तक रोकना जान-बूझकर होता है और आम है। बीच में बिखरी देरियाँ आम तौर पर किसी कन्वर्टर की निशानी हैं जिसने वीडियो से फ़्रेम गिरा दिए और खाई भरने के लिए पड़ोसियों को खींच दिया। लूप ब्लॉक नहीं है, इसलिए यह एक बार चलकर रुक जाता है। लूप करना GIF की विशिष्टि का हिस्सा नहीं है। यह वह ब्लॉक है जो नेटस्केप ने 1995 में गढ़ा और सबने फिर भी लागू किया; जिस फ़ाइल में यह न हो उसे हर ब्राउज़र ठीक एक बार दिखाता है। अगर इसे दोहराना ही था, तो लिखने वाले ने ब्लॉक छोड़ दिया। यह एक बार चलकर रुक जाता है। यह {count} बार चलकर रुक जाता है। लूप ब्लॉक सामान्य शून्य के बजाय एक गिनती बताता है — शून्य का अर्थ है हमेशा। कुछ पुराने दर्शक गिनती अनदेखी कर के फिर भी लगातार दोहराते हैं। हर फ़्रेम पूरा कैनवास दोबारा बनाता है। GIF किसी फ़्रेम को केवल उस आयत के रूप में रख सकता है जो पिछले के बाद बदला — इसीलिए लगभग स्थिर खिड़की की स्क्रीन रिकॉर्डिंग छोटी हो सकती है। यहाँ कोई ऐसा नहीं करता: हर फ़्रेम पूरा कैनवास है, ⁦{width}×{height}⁩। आपस में असंबद्ध तस्वीरों से बने फ़्रेमों के लिए यह सही है, और फ़िल्माई या रिकॉर्ड की गई किसी भी चीज़ के लिए — जहाँ तस्वीर का ज़्यादातर हिस्सा हिलता ही नहीं — यह यूँ ही गँवाई गई जगह है। {total} में से एक फ़्रेम पूरा कैनवास दोबारा बनाता है; बाकी सिर्फ़ बदला हुआ हिस्सा रखते हैं। {total} में से {count} फ़्रेम पूरा कैनवास दोबारा बनाते हैं; बाकी सिर्फ़ बदला हुआ हिस्सा रखते हैं। सुधरी हुई GIF ऐसी ही दिखती है। पूरे कैनवास वाले आम तौर पर पहला फ़्रेम होते हैं और वे जगहें जहाँ तस्वीर पूरी की पूरी बदल गई। कोई फ़्रेम पूरा कैनवास दोबारा नहीं बनाता। पहले के बाद हर फ़्रेम सिर्फ़ वही आयत रखता है जो बदला — यही इस प्रारूप का सही इस्तेमाल है, और यही वजह है कि यह फ़ाइल इतनी छोटी है। एक फ़्रेम कैनवास से बाहर निकल जाता है। {count} फ़्रेम कैनवास से बाहर निकल जाते हैं। कैनवास ⁦{width}×{height}⁩ है और एक फ़्रेम ऐसा आयत माँगता है जो किनारे से बाहर चला जाता है। बाहर निकले हिस्से का क्या किया जाए, इस पर डिकोडर एकमत नहीं: कोई काट देता है, कोई फ़ाइल ही लेने से मना कर देता है। कैनवास ⁦{width}×{height}⁩ है और कुछ फ़्रेम ऐसा आयत माँगते हैं जो किनारे से बाहर चला जाता है। बाहर निकले हिस्से का क्या किया जाए, इस पर डिकोडर एकमत नहीं: कोई काट देता है, कोई फ़ाइल ही लेने से मना कर देता है। एक फ़्रेम अपनी ही रंग-तालिका लिए चलता है, जिसकी कीमत {bytes} है — फ़ाइल का {share}। {count} फ़्रेम अपनी-अपनी रंग-तालिका लिए चलते हैं, जिनकी कीमत {bytes} है — फ़ाइल का {share}। अपनी पैलेट होने से फ़्रेम वे रंग इस्तेमाल कर पाता है जो साझा तालिका में नहीं हैं, और जब भी वह लिखी जाती है हर प्रविष्टि पर तीन बाइट लगते हैं। जहाँ फ़्रेम एक ही दृश्य के हों, सबके लिए एक तालिका छोटी भी पड़ती है और देखने में ठहरी हुई भी: फ़्रेम-दर-फ़्रेम उछलती पैलेट ही तो GIF की टिमटिमाहट है। कोई वैश्विक रंग-तालिका नहीं है। इसमें कुछ गलत नहीं — यहाँ हर फ़्रेम अपनी लेकर आता है — पर इसका अर्थ है कि पहला फ़्रेम आने से पहले दर्शक के पास कैनवास रँगने को कुछ नहीं होता। रंग-तालिकाओं की {entries} प्रविष्टियाँ कभी इस्तेमाल ही नहीं होतीं, और वह {bytes} बनता है। इस फ़ाइल की तालिकाएँ {declared} रंग घोषित करती हैं और पिक्सेल उनमें से {referenced} की ओर इशारा करते हैं। रंग-तालिका की लंबाई, उसमें जो भी हो, हमेशा दो की घात होती है, इसलिए नौ रंग इस्तेमाल करने वाले फ़्रेम को भी सोलह मिलते हैं; थोड़ी गोलाई अपरिहार्य है। इससे कहीं ज़्यादा का अर्थ है कि पैलेट उस तस्वीर के लिए बनी थीं जो आखिर में फ़्रेम में आई ही नहीं। पूरा ऐनिमेशन एक ही रंग से बनता है। पूरा ऐनिमेशन {count} रंगों से बनता है। यह सपाट चित्रकारी है, और GIF इसी के लिए बना था। ऐसी फ़ाइल अच्छी दबती है और डिदरिंग बुरी तरह झेलती है, इसलिए अगर यह चित्तीदार दिखे तो बंद करने वाली चीज़ डिदरिंग ही है। कोई तस्वीर, या उससे बनी कोई चीज़। GIF एक फ़्रेम को ज़्यादा से ज़्यादा 256 रंग देता है, इसलिए जिसमें भी कोई ढाल है वह अनुमान से बनाया जा रहा है — और डिदरिंग तथा फ़ाइल को भारी करने वाला शोर वहीं से आते हैं। इस फ़ाइल में {bytes} का एक टिप्पणी ब्लॉक है। टिप्पणियाँ कोई दर्शक नहीं दिखाता, फिर भी फ़ाइल की हर नकल उन्हें ढोती है। आम तौर पर यह उसी का नाम होता है जिसने फ़ाइल लिखी, और कभी-कभी कुछ ऐसा जिसे लेखक ने प्रकाशित करना नहीं चुना होता। एक XMP मेटाडेटा पैकेट {bytes} घेरता है — फ़ाइल का {share}। XMP वह XML ब्लॉक है जिसे कोई इमेज एडिटर यह दर्ज करने के लिए लिखता है कि उसने क्या किया, और उसमें संपादन का इतिहास, सॉफ़्टवेयर और कभी-कभी लेखक तक हो सकते हैं। कोई दर्शक उसमें से कुछ नहीं बनाता। उसे हटाने में तस्वीर का कुछ नहीं जाता। एक ICC रंग प्रोफ़ाइल {bytes} घेरती है। प्रोफ़ाइल बताती है कि पैलेट के अंक रंगों के तौर पर क्या माने रखते हैं। GIF के भीतर से इसे पढ़ने वाला लगभग कुछ नहीं है, इसलिए यह अमूमन बेकार का बोझ है — पर जो दर्शक इसे पढ़ते हैं, उनमें हटाने पर रंग खिसक सकते हैं। इस फ़ाइल में एक सादा-पाठ एक्सटेंशन है। यह ब्लॉक दर्शक से कहता है कि तस्वीर के ऊपर खानों की जाली में पाठ बनाए। यह 1989 की विशिष्टि में था, इसे कभी किसी ने लागू नहीं किया, और हर डिकोडर इसे छोड़ देता है। इसमें जो भी लिखा हो, दिखेगा नहीं। “{name}” नाम का एक ऐप्लिकेशन ब्लॉक है, {bytes} का। ऐप्लिकेशन ब्लॉक वह रास्ता हैं जिससे विशिष्टि के बाहर की हर चीज़ GIF में घुसती है। दर्शक जिन्हें नहीं पहचानते उन्हें छोड़ देते हैं, इसलिए जब तक कोई खास चीज़ इसे न पढ़ रही हो, यह सिर्फ़ बोझ है। एक फ़्रेम इंटरलेस करके रखा गया है। {count} फ़्रेम इंटरलेस करके रखे गए हैं। पंक्तियाँ चार बारी में रखी जाती हैं ताकि धीमी लाइन से आती तस्वीर जल्दी ही अपना मोटा-मोटा रूप दिखा दे। 1993 में इसका मतलब था, यह पंक्तियों को क्रम से रखने के मुकाबले थोड़ा खराब दबती है, और आज किसी दर्शक को इससे फ़ायदा नहीं। यह फ़ाइल कहती है कि वह GIF89a नहीं, GIF{version} है। GIF87a पहले आया और उसमें न समय के ब्लॉक हैं, न पारदर्शिता, न लूप ब्लॉक। इनमें से कुछ भी लिए हुए फ़ाइल का खुद को 87a कहना आम है — डिकोडर जाँचते ही नहीं — पर यह इस बात का संकेत है कि शीर्ष लिखा नहीं, नकल किया गया था। पृष्ठभूमि का रंग सूचकांक {index} है, जबकि वैश्विक तालिका में केवल {entries} प्रविष्टियाँ हैं। कुछ टूटेगा नहीं — दर्शक उसकी जगह पारदर्शी ले लेते हैं — पर इसका अर्थ है कि यह खाना कभी भरा ही नहीं गया, या उस पैलेट के हिसाब से भरा गया जो अब फ़ाइल में है ही नहीं। पिक्सेल का पहलू अनुपात {ratio} पर सेट है। यह उन पर्दों के लिए बना खाना है जिनके पिक्सेल वर्गाकार नहीं थे। आज का हर दर्शक इसे अनदेखा कर के फ़्रेम को उसके सहेजे आकार में बनाता है, इसलिए इस पर टिकी फ़ाइल बनाने वाले को खिंची हुई और बाकी सबको सामान्य दिखेगी। कंप्रेसर ने अपना शब्दकोश {count} बार रीसेट किया। LZW चलते-चलते शब्दकोश बनाता है और उसमें 4,096 प्रविष्टियाँ आती हैं; भर जाने पर एनकोडर फिर से शुरू कर देता है। प्रति फ़्रेम एक बार सामान्य है — फ़्रेम की शुरुआत ही ऐसे होती है। इससे ज़्यादा का अर्थ है कि तस्वीर इतनी विविध थी कि बीच रास्ते ही शब्दकोश चुक गया, और यही कोई तस्वीर या भारी डिदरिंग करती है — इसीलिए वैसी फ़ाइलें बड़ी होती हैं। एक फ़्रेम अपने ठीक पहले वाले जैसा ही है। {count} फ़्रेम अपने ठीक पहले वाले जैसे ही हैं। वे अपना पूरा दबा हुआ आकार लेते हैं और पर्दे पर कुछ नहीं बदलते। उनकी देरी को पिछले फ़्रेम में जोड़ देने पर दिखने में बिलकुल वही रहेगा और आकार कम हो जाएगा। एक फ़्रेम पूरा डिकोड नहीं होता। {count} फ़्रेम पूरे डिकोड नहीं होते। फ़्रेम भरने से पहले ही दबा हुआ डेटा खत्म हो जाता है। दर्शक जितना बना सकेगा बनाएगा और आयत का बाकी हिस्सा खाली छोड़ देगा। आपका GIF कहीं नहीं गया। {total} फ़ाइलें लोड हुईं। {platform} किसी चीज़ ने {hosts} से संपर्क किया, और यह टूल ऐसा कभी नहीं करता। {platform} विज्ञापन, माप और दान वाले बटन के लिए साइट की अपनी स्क्रिप्ट {hosts} होस्ट से आईं। उनमें से किसी को कोई फ़ाइल नहीं मिली। विज्ञापन, माप और दान वाले बटन के लिए साइट की अपनी स्क्रिप्ट {hosts} होस्ट से आईं। उनमें से किसी को कोई फ़ाइल नहीं मिली।

# GIF एनालाइज़र — GIF के अंदर असल में क्या है फ़्रेम, देरी, पैलेट, और हर बाइट कहाँ गया। > GIF को अपने ब्राउज़र में खोलकर देखिए: हर फ़्रेम की देरी और डिस्पोज़ल, कलर टेबल, लूप की गिनती, और फ़ाइल का साइज़ कहाँ गया इसका बाइट-दर-बाइट ब्योरा। कुछ अपलोड नहीं होता। यह पेज एक इंटरैक्टिव टूल है जो पूरी तरह आपके ब्राउज़र में चलता है, https://abox.tools/hi/gif-analyzer/ पर — आप इसे जो भी देते हैं, वह कहीं अपलोड नहीं होता। आगे वह सब कुछ है जो यह पेज इस टूल के बारे में शब्दों में कहता है; इसे इस्तेमाल करने के लिए यह पता खोलें। ## यह टूल GIF **कभी अपलोड नहीं करता**। यहाँ कोई सर्वर है ही नहीं। फ़ाइल को खोलना और खोलकर देखना, दोनों आपका अपना ब्राउज़र करता है। ब्लॉक की बनावट, LZW खोलना और इस पेज पर बना हर फ़्रेम, सब इसी डिवाइस पर होता है। मान लीजिए यहाँ कुछ भेजना भी चाहता, तो इस पेज के दूसरी तरफ़ ऐसा कोई सर्वर ही नहीं है जिसे फ़ाइल भेजी जा सके। - ✗ कोई अपलोड नहीं - ✗ कोई खाता नहीं - ✓ ऑफ़लाइन चलता है - ✓ ओपन सोर्स - ✓ फ़ाइलें आपके डिवाइस पर ही रहती हैं ## GIF का विश्लेषण कैसे करें 1. **एक GIF चुनिए।** उसे चुनने वाले खाने में खींचकर छोड़ दीजिए या खुद ढूँढ़ लीजिए। ब्राउज़र उसे सीधे आपकी डिस्क से पढ़ता है, और इस बीच कुछ भी कहीं नहीं जाता। 2. **पहले सारांश पढ़िए।** कैनवस का आकार, फ़्रेम की गिनती, एनिमेशन खुद को कितना लंबा बताता है, और असल में कितना चलता है। ये आखिरी दो लोगों की उम्मीद से कहीं ज़्यादा बार अलग निकलते हैं, और वजह अगले हिस्से में है। 3. **जो चीज़ें उभरकर आती हैं, उन्हें देखिए।** वहाँ की हर पंक्ति आपकी फ़ाइल से नापी गई है: ऐसी देरी जिसे कोई ब्राउज़र नहीं मानेगा, गायब लूप ब्लॉक, ऐसी कलर टेबल जिनका कोई हवाला नहीं देता, कुछ फ़्रेम से भी बड़ा मेटाडेटा। इनमें से कुछ भी इस बारे में अंदाज़ा नहीं है कि आप क्या बनाना चाहते थे। 4. **देखिए कि बाइट कहाँ गए।** फ़ाइल का हर बाइट ठीक एक ही पंक्ति में है, और पंक्तियाँ मिलकर पूरी फ़ाइल बनती हैं। अगर ज़्यादातर हिस्सा “कंप्रेस्ड पिक्सल” में नहीं है, तो बाकी तालिका बता देती है कि वह कहाँ है। 5. **फ़्रेम एक-एक करके देखिए।** हर फ़्रेम अपनी देरी, अपना आयत, अपना डिस्पोज़ल तरीका और अपना साइज़ दिखाता है। “हर फ़्रेम के बाद का कैनवस” और “हर फ़्रेम जो सहेजता है सिर्फ़ वही” के बीच बदलकर देखिए। फ़ाइल ऑप्टिमाइज़ है या नहीं, यह दूसरे से पता चलता है, क्योंकि अच्छी बनी GIF छोटे-छोटे आयत सहेजती है और खराब बनी हर बार पूरी तस्वीर। 6. **ज़रूरत हो तो रिपोर्ट ले जाइए।** पूरा विश्लेषण सादे टेक्स्ट में, किसी संदेश में चिपकाने या फ़ाइल के साथ रख लेने के लिए। यह पेज के भीतर, उसी से बनता है जो पहले से आपकी स्क्रीन पर है। ## विस्तार से [GIF के भीतर असल में क्या है](https://abox.tools/hi/guides/whats-inside-a-gif/): फ़्रेम, देरी, निपटाने के तरीके और रंगों की तालिकाएँ समझाई गईं, ब्राउज़र सबसे तेज़ देरी क्यों नहीं मानते, और किसी GIF का आकार असल में कहाँ चला गया यह कैसे पता करें। ## बॉक्स में और भी टूल - [तस्वीरों से वीडियो](https://abox.tools/hi/images-to-video/): तस्वीरों के एक फ़ोल्डर को वीडियो बना दीजिए। - [वीडियो कटर](https://abox.tools/hi/trim-video/): चलते-चलते उन हिस्सों पर निशान लगाइए जो रखने लायक हैं। उन्हें एक ही वीडियो के रूप में वापस पाइए। - [वीडियो क्रॉपर](https://abox.tools/hi/crop-video/): क्लिप में से उतना ही रखिए जितना काम का है। - [वीडियो रिवर्सर](https://abox.tools/hi/reverse-video/): आखिरी फ़्रेम सबसे पहले, आवाज़ समेत। ## सवाल ### क्या मेरा GIF कहीं अपलोड होता है? नहीं। फ़ाइल को आपका अपना ब्राउज़र आपके अपने हार्डवेयर पर पढ़ता, खोलता और बनाता है। इस टूल का कोई सर्वर वाला हिस्सा है ही नहीं, और पेज की `Content-Security-Policy` में वे सारे पते लिखे हैं जिनसे यह बात कर सकता है, जिनमें से एक भी इस साइट का नहीं है। नेटवर्क काट दीजिए, यह फिर भी GIF एनालाइज़ करता रहेगा। ### मेरी GIF देरी में लिखे से धीमी क्यों चलती है? क्योंकि हर ब्राउज़र सेकंड के दो सौवें हिस्से से कम देरी मानने से इनकार कर देता है और उसकी जगह फ़्रेम को दसवें हिस्से तक रोके रखता है। यह नियम 1996 में Netscape में लिखा गया था, उस ज़माने के घूमते ग्लोब और “निर्माणाधीन” बोर्ड के लिए, और तब से हर ब्राउज़र में उतारा गया है; हटाया कभी किसी ने नहीं। \ \ तो जिस GIF के सारे फ़्रेम 0.01 सेकंड कहते हैं, वह 100 फ़्रेम प्रति सेकंड पर नहीं चलती। वह 10 पर चलती है, यानी बनाने वाले सॉफ़्टवेयर की मंशा से पाँच से दस गुना धीमी। यह पेज दोनों आँकड़े दिखाता है, फ़ाइल क्या कहती है और वह असल में क्या करेगी, और जिन फ़्रेम पर असर पड़ता है उन्हें निशान लगा देता है। सुधार वहीं होगा जहाँ फ़ाइल बनी थी: 0.01 की जगह 0.02 लिखिए। ### “डिस्पोज़ल” का क्या मतलब है? किसी फ़्रेम का समय खत्म होने पर स्क्रीन पर क्या छोड़ना है। एनिमेशन ठीक दिखेगा या धब्बे छोड़ेगा, यह इसी फ़ील्ड से तय होता है। \ \ **जहाँ है वहीं रहने दीजिए** का मतलब है कि अगला फ़्रेम इसी के ऊपर पुत जाएगा, और जब फ़्रेम अपारदर्शी हों और एक-दूसरे को ढँकते हों तो यही चाहिए। **बैकग्राउंड तक साफ़ कर दीजिए** पहले फ़्रेम का आयत पोंछ देता है, और ट्रांसपेरेंसी को यही चाहिए, वरना अगले फ़्रेम के आर-पार दिखने वाले हिस्सों में पिछला फ़्रेम झलकता है। **नीचे जो था वह लौटा दीजिए** वही वापस रख देता है जो इस फ़्रेम के बनने से पहले वहाँ था, और स्थिर बैकग्राउंड पर चलती छोटी चीज़ इसी तरह सहेजी जाती है। और **बताया ही नहीं गया** का मतलब है कि फ़ाइल ने कुछ कहा ही नहीं, और हर व्यूअर उसे “जहाँ है वहीं रहने दीजिए” मान लेता है। ### मेरी GIF इतनी बड़ी क्यों है? “बाइट कहाँ गए” वाली तालिका यह आम तौर पर नहीं, आपकी उसी फ़ाइल के लिए बताती है, और मुमकिन जवाब गिनती के ही हैं। \ \ अगर लगभग सब कुछ **कंप्रेस्ड पिक्सल** में है, तो फ़ाइल में बस तस्वीर ही बहुत है: GIF हर फ़्रेम को पूरे पिक्सल के रूप में सहेजती है, न मोशन कंपनसेशन, न क्वालिटी का कोई घुंडी वाला नियंत्रण। इसलिए साइज़ मोटे तौर पर क्षेत्रफल गुणा फ़्रेम की गिनती है। कम फ़्रेम, छोटा आकार या कम रंग, बस यही तीन लीवर हैं। \ \ अगर बड़ा हिस्सा **कलर टेबल** में है, तो फ़ाइल हर फ़्रेम के लिए अलग पैलेट लिख रही है, 768 बाइट प्रति पैलेट। अगर बड़ा हिस्सा **मेटाडेटा** में है, तो किसी एडिटर ने XMP पैकेट छोड़ दिया है, और उसे तस्वीर छुए बिना हटाया जा सकता है। और अगर सारे फ़्रेम पूरा कैनवस ढँकते हैं, तो एनकोडर ने कभी निकाला ही नहीं कि असल में कौन-सा हिस्सा बदला। जो चीज़ फ़िल्माई या रिकॉर्ड की गई हो, उसमें यही फ़ाइल का बड़ा हिस्सा होता है। ### फ़्रेम की दोनों व्यू में क्या फ़र्क है? **हर फ़्रेम के बाद का कैनवस** वह है जो कोई व्यूअर उस पल दिखाता है, यानी यह फ़्रेम पिछले फ़्रेम की छोड़ी हुई चीज़ों के ऊपर। **हर फ़्रेम जो सहेजता है सिर्फ़ वही** वह आयत है जो फ़ाइल उस फ़्रेम के लिए सचमुच रखती है, अकेला, नीचे कुछ भी बिछाए बिना। \ \ दिलचस्प दूसरा वाला है। GIF किसी फ़्रेम में तस्वीर का सिर्फ़ बदला हुआ हिस्सा सहेज सकती है, और इसीलिए लगभग स्थिर विंडो की स्क्रीन रिकॉर्डिंग छोटी रह सकती है। अगर आपकी फ़ाइल का हर फ़्रेम पूरा कैनवस है, तो यह काम किसी ने किया ही नहीं, और एनिमेशन देखकर यह पता नहीं चलता, सिर्फ़ सहेजी हुई चीज़ देखकर चलता है। ### यह कह रहा है कि मेरी फ़ाइल में कमेंट या XMP है। वह क्या है? ऐसा टेक्स्ट जो तस्वीर के साथ चलता है और जिसे कोई व्यूअर नहीं दिखाता। कमेंट ब्लॉक आम तौर पर उसी सॉफ़्टवेयर का नाम होता है जिसने फ़ाइल लिखी। XMP पैकेट वह XML है जो कोई इमेज एडिटर यह दर्ज करने के लिए लिखता है कि उसने क्या किया, और उसमें एडिट का इतिहास, सॉफ़्टवेयर का वर्शन और कभी-कभी लेखक का नाम तक हो सकता है। \ \ यह पेज दोनों को पूरा छाप देता है, क्योंकि मेटाडेटा के बारे में दिलचस्प सवाल यह है कि उसमें लिखा क्या है, न कि यह कि वह मौजूद है। यह आपको दिखता है और किसी को नहीं: इस रिपॉज़िटरी में कुछ भी इसमें से किसी को कुछ नहीं पढ़ाता। ### क्या यह खराब GIF भी खोल लेता है? कोशिश करता है, और बता देता है कि कहाँ जाकर उसने हाथ खड़े किए। जो फ़ाइल किसी ब्लॉक के बीच खत्म हो जाए, जहाँ ब्लॉक का निशान होना चाहिए वहाँ कोई और बाइट हो, या जिसमें ऐसा फ़्रेम हो जिसका कंप्रेस्ड डेटा जल्दी चुक जाए, उसमें भी उस बिंदु तक जो कुछ पढ़ा जा सका, सब दिखता है, और सबसे ऊपर लिखा होता है कि दिक्कत क्या थी। एनालाइज़र की सबसे ज़्यादा ज़रूरत यहीं पड़ती है, इसलिए एक खराब बाइट के चक्कर में पूरी फ़ाइल फेंक देना गलत बर्ताव होता। ### क्या यह मेरी फ़ाइल बदलता है? नहीं। यह टूल सिर्फ़ पढ़ता है। न कोई आउटपुट फ़ाइल है, न दोबारा एनकोडिंग, न यहाँ कोई ऐसा बटन जो GIF लिखता हो। डाउनलोड करने को सिर्फ़ विश्लेषण की सादे टेक्स्ट वाली कॉपी है। आपका असली फ़ाइल आपकी डिस्क पर ज्यों की त्यों है, और टैब बंद करने पर क्या होगा, उसका ईमानदार जवाब भी यही है। ### क्या यह मुफ़्त है, और क्या इसके लिए खाता बनाना पड़ेगा? यह मुफ़्त है, और यहाँ न कोई खाता है, न साइन-इन, न ट्रायल। फ़ाइल के साइज़ पर भी आपके अपने डिवाइस की मेमोरी के अलावा कोई सीमा नहीं है। साइट पर विज्ञापन हैं और खर्च वही उठाते हैं, लेकिन विज्ञापनों को आपकी फ़ाइल के बारे में कुछ नहीं दिया जाता। ### क्या यह ऑफ़लाइन चलता है? हाँ। पेज एक बार लोड कर लीजिए, फिर इंटरनेट काट दीजिए, यह चलता रहेगा। कुछ अपलोड नहीं हो रहा, यह साबित करने का सबसे आसान तरीका भी यही है। जो टूल आपका GIF एनालाइज़ करने के लिए कहीं भेजता, वह प्लग निकालते ही रुक जाता। ## प्राइवेसी का यह दावा कैसे जाँचा जा सकता है - **आपके GIF के पास बाहर जाने का रास्ता ही नहीं है।** Content-Security-Policy में वे सारे पते लिखे हैं जिनसे यह पेज बात कर सकता है, और उनमें से एक भी इस साइट का नहीं है। यहाँ ऐसा कोई ठिकाना है ही नहीं जहाँ आपकी फ़ाइल इकट्ठी की जा सके, और होता भी तो कोड में ऐसा कुछ नहीं है जो उसे वहाँ भेजे। पहले यहाँ `connect-src 'none'` लिखा था, जिसमें कोई अपवाद नहीं था। विज्ञापन की कीमत यही थी, और यह बता देना भी सौदे का हिस्सा है। - **पढ़ने वाला हिस्सा इस रिपॉज़िटरी की चार फ़ाइलें हैं।** फ़ाइल में क्या है, यह पता करने के लिए यहाँ ब्राउज़र का अपना GIF डिकोडर इस्तेमाल नहीं होता, क्योंकि वह डिकोडर यह नहीं बताता कि कोई बाइट कहाँ गया। इसलिए फ़ॉर्मैट हाथ से पढ़ा जाता है: `src/gif.js` ब्लॉक-दर-ब्लॉक चलता है, `src/lzw.js` पिक्सल खोलता है, `src/frames.js` उन्हें एक पर एक रखता है, और `src/budget.js` हिस्सों को वापस जोड़कर देखता है कि वे फ़ाइल के साइज़ के बराबर बैठते हैं या नहीं। - **कमेंट और मेटाडेटा आपको दिखते हैं, और किसी को नहीं।** किसी GIF में कमेंट ब्लॉक हो सकता है, किसी एडिट का ब्योरा देने वाला XMP पैकेट हो सकता है, या कलर प्रोफ़ाइल। यह पेज इन सबको छाप देता है। ये आपके सामने स्क्रीन पर आते हैं और वहीं तक रहते हैं। इस रिपॉज़िटरी में ऐसा कोई एनालिटिक्स इवेंट है ही नहीं जो इनमें से कुछ ले जाए, और होता भी तो यह पेज उसे भेज नहीं सकता। - **Google क्या लोड करता है, और उसे क्या नहीं दिया जाता।** विज्ञापन और माप वाली स्क्रिप्ट Google से आती हैं। इनमें से किसी को भी आपकी फ़ाइल के बारे में कुछ नहीं सौंपा जाता, न फ़ाइल, न थंबनेल, न नाम, न साइज़, न फ़्रेम की गिनती, न कोई कमेंट। GIF को पढ़ने, खोलने या बनाने वाली हर पंक्ति इसी ऑरिजिन से आती है और रिपॉज़िटरी में मौजूद है। - **दान का बटन क्या लोड करता है, और उसे क्या नहीं दिया जाता।** हेडर वाला “Buy me a coffee” बटन cdnjs.buymeacoffee.com की एक स्क्रिप्ट बनाती है और अक्षर Google Fonts से आते हैं। वह एक लिंक से ज़्यादा कुछ नहीं है। न वह आपकी विज़िट की खबर देता है, न उसे आपके या आपकी फ़ाइलों के बारे में कुछ मिलता है। जब तक आप क्लिक न करें कुछ नहीं होता, और क्लिक करने पर जो खुलेगा वह किसी और की साइट है। - **यह ऑफ़लाइन भी चलता है।** नेटवर्क काट दीजिए, इस पेज का हर हिस्सा काम करता रहेगा। सबसे आसान सबूत यही है। जो टूल आपका GIF एनालाइज़ करने के लिए कहीं भेजता, वह प्लग निकालते ही रुक जाता। **खुद जाँच लीजिए।** ऊपर लिखी किसी भी बात को भरोसे पर मानने की ज़रूरत नहीं। यह पेज रिपॉज़िटरी के टेम्पलेट और कॉन्फ़िग से बनता है, एक ऐसी बिल्ड स्क्रिप्ट के ज़रिए जिसे आप पढ़ भी सकते हैं और खुद चला भी सकते हैं। उसका नतीजा `dist` ब्रांच पर कमिट रहता है, यानी जो सर्व हो रहा है और सोर्स से बिल्ड करने पर जो बनता है, दोनों का फ़र्क आप खुद देख सकते हैं: https://github.com/A-Box-of-Tools/website सबसे पहले पढ़ने लायक फ़ाइलें ये हैं — Content-Security-Policy के लिए `config/site.toml`, फ़ाइल में एक-एक ब्लॉक चलने वाले रीडर के लिए `src/gif.js`, खोलने वाले के लिए `src/lzw.js`, और बाइट का हिसाब रखने वाले के लिए `src/budget.js`। इनमें से किसी में भी ऐसी एक पंक्ति नहीं है जो नेटवर्क तक पहुँच सके।

विस्तार से

GIF के भीतर असल में क्या है फ़्रेम, देरी, निपटाने के तरीके और रंगों की तालिकाएँ समझाई गईं, ब्राउज़र सबसे तेज़ देरी क्यों नहीं मानते, और किसी GIF का आकार असल में कहाँ चला गया यह कैसे पता करें।

सवाल

क्या मेरा GIF कहीं अपलोड होता है?

नहीं। फ़ाइल को आपका अपना ब्राउज़र आपके अपने हार्डवेयर पर पढ़ता, खोलता और बनाता है। इस टूल का कोई सर्वर वाला हिस्सा है ही नहीं, और पेज की Content-Security-Policy में वे सारे पते लिखे हैं जिनसे यह बात कर सकता है, जिनमें से एक भी इस साइट का नहीं है। नेटवर्क काट दीजिए, यह फिर भी GIF एनालाइज़ करता रहेगा।

मेरी GIF देरी में लिखे से धीमी क्यों चलती है?

क्योंकि हर ब्राउज़र सेकंड के दो सौवें हिस्से से कम देरी मानने से इनकार कर देता है और उसकी जगह फ़्रेम को दसवें हिस्से तक रोके रखता है। यह नियम 1996 में Netscape में लिखा गया था, उस ज़माने के घूमते ग्लोब और “निर्माणाधीन” बोर्ड के लिए, और तब से हर ब्राउज़र में उतारा गया है; हटाया कभी किसी ने नहीं।

तो जिस GIF के सारे फ़्रेम 0.01 सेकंड कहते हैं, वह 100 फ़्रेम प्रति सेकंड पर नहीं चलती। वह 10 पर चलती है, यानी बनाने वाले सॉफ़्टवेयर की मंशा से पाँच से दस गुना धीमी। यह पेज दोनों आँकड़े दिखाता है, फ़ाइल क्या कहती है और वह असल में क्या करेगी, और जिन फ़्रेम पर असर पड़ता है उन्हें निशान लगा देता है। सुधार वहीं होगा जहाँ फ़ाइल बनी थी: 0.01 की जगह 0.02 लिखिए।

“डिस्पोज़ल” का क्या मतलब है?

किसी फ़्रेम का समय खत्म होने पर स्क्रीन पर क्या छोड़ना है। एनिमेशन ठीक दिखेगा या धब्बे छोड़ेगा, यह इसी फ़ील्ड से तय होता है।

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

मेरी GIF इतनी बड़ी क्यों है?

“बाइट कहाँ गए” वाली तालिका यह आम तौर पर नहीं, आपकी उसी फ़ाइल के लिए बताती है, और मुमकिन जवाब गिनती के ही हैं।

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

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

फ़्रेम की दोनों व्यू में क्या फ़र्क है?

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

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

यह कह रहा है कि मेरी फ़ाइल में कमेंट या XMP है। वह क्या है?

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

यह पेज दोनों को पूरा छाप देता है, क्योंकि मेटाडेटा के बारे में दिलचस्प सवाल यह है कि उसमें लिखा क्या है, न कि यह कि वह मौजूद है। यह आपको दिखता है और किसी को नहीं: इस रिपॉज़िटरी में कुछ भी इसमें से किसी को कुछ नहीं पढ़ाता।

क्या यह खराब GIF भी खोल लेता है?

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

क्या यह मेरी फ़ाइल बदलता है?

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

क्या यह मुफ़्त है, और क्या इसके लिए खाता बनाना पड़ेगा?

यह मुफ़्त है, और यहाँ न कोई खाता है, न साइन-इन, न ट्रायल। फ़ाइल के साइज़ पर भी आपके अपने डिवाइस की मेमोरी के अलावा कोई सीमा नहीं है। साइट पर विज्ञापन हैं और खर्च वही उठाते हैं, लेकिन विज्ञापनों को आपकी फ़ाइल के बारे में कुछ नहीं दिया जाता।

क्या यह ऑफ़लाइन चलता है?

हाँ। पेज एक बार लोड कर लीजिए, फिर इंटरनेट काट दीजिए, यह चलता रहेगा। कुछ अपलोड नहीं हो रहा, यह साबित करने का सबसे आसान तरीका भी यही है। जो टूल आपका GIF एनालाइज़ करने के लिए कहीं भेजता, वह प्लग निकालते ही रुक जाता।

GIF एनालाइज़र — GIF के अंदर असल में क्या है

प्राइवेसी का यह दावा कैसे जाँचा जा सकता है

एक GIF चुनिए

जो उभरकर आता है

बाइट कहाँ गए

रंग

ग्लोबल टेबल

और क्या-क्या पड़ा है

GIF का विश्लेषण कैसे करें

विस्तार से

सवाल

प्राइवेसी का यह दावा कैसे जाँचा जा सकता है

एक GIF चुनिए

—

जो उभरकर आता है

बाइट कहाँ गए

फ़्रेम दर फ़्रेम

रंग

ग्लोबल टेबल

और क्या-क्या पड़ा है

GIF का विश्लेषण कैसे करें

विस्तार से

बॉक्स में और भी टूल

सवाल