WebP डेस्कटॉप ऐप में सार्वभौमिक रूप से सपोर्ट क्यों नहीं है
WebP को Google ने 2010 में जारी किया, पर डेस्कटॉप सॉफ्टवेयर ने इसे ब्राउज़र सपोर्ट से बहुत पीछे रहकर अपनाया. ब्राउज़र ने WebP जल्दी अपनाया क्योंकि वे अपने रेंडरिंग इंजन खुद नियंत्रित करते हैं और Google ने Chrome के WebP सपोर्ट को एक प्रतिस्पर्धी बढ़त के रूप में सक्रिय रूप से बेहतर किया. डेस्कटॉप ऐप किसी नए इमेज फॉर्मेट को अपनाने में ज्यादा समय लेते हैं क्योंकि हर ऐप अपना खुद का इमेज डिकोडिंग ढांचा रखता है, और नया फॉर्मेट सपोर्ट करने के लिए कई किनारे के मामलों की लंबी कतार के विरुद्ध परीक्षण करना पड़ता है. Adobe Photoshop, जिसे ज्यादातर पेशेवर फोटोग्राफर और डिज़ाइनर इस्तेमाल करते हैं, ने 2022 के अंत में वर्शन 23.2 तक मूल WebP सपोर्ट नहीं दिया. Microsoft Office ऐप 2026 तक भी प्लेटफॉर्म-दर-प्लेटफॉर्म WebP को असमान तरीके से संभालते हैं. प्रिंट RIP सॉफ्टवेयर और ज्यादातर पुराने आर्काइविंग टूल ने WebP को कभी नहीं अपनाया. व्यावहारिक नतीजा यह है कि जो फाइल ब्राउज़र में बिल्कुल सही दिखती है, उसे वही सॉफ्टवेयर पूरी तरह मना कर सकता है जिसकी उपयोगकर्ता को ज़रूरत है, और PNG में बदलना भरोसेमंद उपाय है.
WebP, PNG पर अपनी कम्प्रेशन बढ़त कैसे हासिल करती है
PNG, DEFLATE कम्प्रेशन इस्तेमाल करती है, जो 1996 का एक सामान्य-उद्देश्य लॉसलेस एल्गोरिथ्म है. यह कम्प्रेशन से पहले स्कैनलाइन पर कुछ उलटे जा सकने वाले फिल्टर लगाती है और नतीजे को एक zlib स्ट्रीम में कोड करती है. यह असरदार है पर मशीन लर्निंग और वीडियो कोडिंग शोध के बेहतर तरीके निकलने से पहले बना था. WebP लॉसी मोड VP8 वीडियो कम्प्रेशन से लिया गया एक ब्लॉक-आधारित ट्रांसफॉर्म इस्तेमाल करता है, 16x16 मैक्रोब्लॉक इकाइयों पर इंट्रा-फ्रेम प्रिडिक्शन और डिस्क्रीट कोसाइन ट्रांसफॉर्म लगाता है. WebP लॉसलेस मोड स्थानिक प्रिडिक्शन, कलर ट्रांसफॉर्मेशन और एक LZ77 कोडिंग चरण इस्तेमाल करता है जो आम इमेज सामग्री के लिए DEFLATE से संरचनात्मक रूप से ज्यादा कुशल है. Google के प्रकाशित बेंचमार्क दिखाते हैं कि मानक परीक्षण इमेज के एक संग्रह पर लॉसलेस WebP, PNG से करीब 26 प्रतिशत छोटी होती है, और अल्फा वाली लॉसी WebP तुलनीय विज़ुअल क्वालिटी पर PNG से करीब तीन गुना छोटी. PNG-से-WebP दिशा इन बचतों का लाभ उठाती है, WebP-से-PNG दिशा उन्हें पलट देती है, इसीलिए आउटपुट बड़ा होता है.
मापे गए फाइल आकार वृद्धि के उदाहरण
ये Chrome 148, Linux डेस्कटॉप पर मापे गए, जहां डिकोड हुई WebP इनपुट पर ब्राउज़र का PNG लिखने वाला पथ लगाया गया. quality 80 पर सहेजा गया 400x300 पिक्सेल का एक छोटा वेक्टर-शैली ग्राफिक, डिकोड होकर PNG बनने में करीब 15 से 25 मिलीसेकंड लेता है और आमतौर पर 20 से 30 प्रतिशत बढ़ता है. 1024x768 की एक फोटोग्राफिक WebP, करीब छोटे आकार, 100 मिलीसेकंड से कम में डिकोड होकर PNG बनती है और आमतौर पर 3 से 5 गुना बढ़ती है. 3840x2160 की एक बड़ी फोटोग्राफिक WebP, करीब बड़े आकार, करीब 1.2 सेकंड में PNG बनती है और दृश्य की जटिलता के अनुसार 5 से 10 गुना बढ़ती है. व्यावहारिक ऊपरी सीमा करीब बड़ी WebP फोटो का कई गुना बड़ा की PNG बन जाना है. ये आंकड़े दोनों फॉर्मेट के बीच कम्प्रेशन कुशलता का अंतर दर्शाते हैं और पिक्सेल संख्या के साथ रैखिक रूप से बढ़ते हैं.
राउंड ट्रिप में अल्फा ट्रांसपेरेंसी
WebP और PNG में 8-बिट अल्फा चैनल एक ही वैल्यू रेंज इस्तेमाल करता है, जहां 0 पूरी तरह ट्रांसपेरेंट और 255 पूरी तरह ठोस होता है. जब ब्राउज़र अल्फा वाली WebP को डिकोड करता है, तो वह RGBA वैल्यू वाला एक पिक्सेल बफर बनाता है जहां A घटक मूल अल्फा डेटा दर्शाता है. जब उस बफर को PNG के रूप में दोबारा save किया जाता है, तो PNG, A वैल्यू को सीधे अपने अल्फा चैनल में लिख देती है. कोई कम्पोज़िटिंग चरण नहीं होता, कोई बैकग्राउंड रंग नहीं लगता, और कोई प्री-मल्टिप्लिकेशन साइड इफेक्ट पिक्सेल वैल्यू नहीं बदलता. नतीजा अल्फा चैनल का एक लॉसलेस स्थानांतरण होता है, जहां PNG में हर पिक्सेल की अपारदर्शिता वैल्यू वही होती है जो WebP में सहेजी थी. किनारों पर बारीक एंटी-एलियसिंग वाली इमेज के लिए, हर मध्यवर्ती अल्फा वैल्यू, जैसे टेक्स्ट के किनारे पर 40 प्रतिशत अपारदर्शिता वाला पिक्सेल, राउंड ट्रिप में सही-सलामत बची रहती है. यही निष्ठा PNG को JPG पर सही चुनाव बनाती है जब ठिकाने का ऐप इमेज को कई बैकग्राउंड पर दिखाता हो.
EXIF और मेटाडेटा का व्यवहार
दोबारा save करने की प्रक्रिया PNG आउटपुट से EXIF, IPTC और XMP मेटाडेटा हटा देती है. WebP फाइलें अपने मेटाडेटा चंक में EXIF डेटा रख सकती हैं, और जब ब्राउज़र इमेज को डिकोड करके दोबारा save करता है तो वह डेटा खो जाता है. ICC कलर प्रोफाइल एक अलग रास्ता अपनाती हैं, जहां Chrome और Safari, WebP डिकोड करने के बाद PNG आउटपुट में sRGB ICC प्रोफाइल टैग बनाए रखते हैं, और Firefox ICC प्रोफाइल समेत सारा मेटाडेटा हटा देता है. व्यावहारिक नतीजा सभी ब्राउज़र में sRGB-सुरक्षित आउटपुट है, पर सोर्स WebP में जड़ी कोई वाइड-गैमट प्रोफाइल Firefox में नहीं बचती. ICC-टैग वाले राउंड ट्रिप पर निर्भर पेशेवर फोटोग्राफिक वर्कफ्लो के लिए कोई मेटाडेटा-संवेदी कन्वर्ज़न टूल इस्तेमाल करें. सामान्य वेब इमेज के लिए मेटाडेटा हटना आमतौर पर स्वीकार्य है और आउटपुट फाइल आकार थोड़ा घटाने का छोटा फायदा देता है.
व्यवहार में प्राइवेसी की जांच
यह दावा कि कोई फाइल डेटा ब्राउज़र से बाहर नहीं जाता, बिना किसी खास टूल के जांचा जा सकता है. अपना ब्राउज़र खोलें, webp-to-png पेज पर जाएं, फिर F12 या राइट-क्लिक मेन्यू से ब्राउज़र डेवलपर टूल खोलें. Network टैब पर जाएं, मौजूदा अनुरोध साफ करें, और कोई WebP फाइल डालकर एक कन्वर्जन चलाएं. अनुरोध सूची को Fetch, XHR या All से फिल्टर करें. सूची में कन्वर्जन के दौरान इमेज डेटा वाला कोई बाहरी अनुरोध नहीं दिखता. मौजूद एकमात्र नेटवर्क अनुरोध शुरुआती पेज लोड संसाधन और मानक एनालिटिक्स पिंग हैं, जो सिर्फ पेज व्यू और Core Web Vitals प्रदर्शन डेटा दर्ज करते हैं, किसी इमेज सामग्री के बिना. हर बड़ा रिमोट WebP से PNG कन्वर्टर हर कन्वर्जन पर कम से कम एक अपलोड POST और एक डाउनलोड GET बनाता है, दोनों सर्वर पर दर्ज होते हैं. डिवाइस-पर वाली बनावट का मतलब है कि वे लॉग प्रविष्टियां मौजूद ही नहीं होतीं, और यही संवेदनशील सामग्री वाली फाइलें बदलने वाले उपयोगकर्ताओं के लिए सार्थक फर्क है.