2026 में इतने ऐप अब भी WebP क्यों ठुकराते हैं
WebP एक दशक से ज़्यादा पुरानी होने पर भी, उपभोक्ता सॉफ़्टवेयर का एक असल हिस्सा अब भी इसे अपलोड या डिस्प्ले के लिए नहीं लेता। वजह तकनीकी क्षमता नहीं, क्योंकि कोडेक व्यापक रूप से उपलब्ध है, बल्कि प्रोडक्ट जड़ता और फ़ॉर्मैट मानकीकरण है। Instagram और बड़े Meta प्लैटफ़ॉर्म ने अपलोड के लिए JPEG पर मानक तय किया क्योंकि यह वैश्विक यूज़र बेस के लिए सबसे पोर्टेबल फ़ॉर्मैट है, और अपलोड वैलिडेशन बदलने का मतलब सैकड़ों डिवाइस सेटअप पर दोबारा टेस्ट करना है। Windows 10 पर Microsoft का फ़ोटो व्यूअर WebP संभालने के लिए अलग Store इंस्टॉल मांगता है। 2018 से पहले बने ज़्यादातर एंटरप्राइज़ कंटेंट मैनेजर अपलोड को एक तय MIME सूची से जाँचते हैं जो WebP से पुरानी है। प्रिंट प्रदाता, स्टॉक एजेंसियाँ और सरकारी पोर्टल अक्सर फ़ॉर्मैट आवश्यकताएँ क़ानूनी या ख़रीद विशिष्टताओं में बाँध देते हैं। ये असली बाधाएँ हैं जो एक कम्पैटिबल फ़ॉर्मैट मांगती हैं, और JPEG इनका सार्वभौमिक जवाब बना रहता है।
पारदर्शिता की समस्या: सफ़ेद क्यों, और इसे कैसे बदलें
JPEG का कम्प्रेशन लाल, हरे और नीले मानों से निकाले luma और chroma चैनलों पर काम करता है। अल्फा के लिए कोई चौथा चैनल नहीं होता। जब ब्राउज़र किसी ऐसी WebP से JPEG लिखता है जिसमें पारदर्शी पिक्सेल हैं, तो उसे हर पारदर्शी जगह को एक असली रंग देना पड़ता है। डिफ़ॉल्ट भराव सफ़ेद है, हेक्स FFFFFF, RGB 255 बाय 255 बाय 255। यह ब्राउज़र डिफ़ॉल्ट है, इस टूल की दिखाई कोई सेटिंग नहीं। अगर आपकी WebP का बैकग्राउंड पारदर्शी है और आपको JPG में कोई ख़ास रंग चाहिए, मान लीजिए किसी गहरे पेज पर लोगो के लिए गहरा स्लेटी, तो WebP को किसी ऐसे एडिटर में खोलिए जो लेयर सपोर्ट करता हो, इमेज के नीचे अपने मनचाहे रंग की एक बैकग्राउंड लेयर डालिए, स्टैक को फ़्लैटन कीजिए, और फिर उस फ़्लैट फ़ाइल को इस कन्वर्टर से चलाइए। नतीजा एक JPG होता है जो ठीक वहीं आपका चुना रंग रखता है जहाँ पहले पारदर्शिता थी।
क्वालिटी, PSNR, और visually negligible का मतलब
PSNR, यानी Peak Signal-to-Noise Ratio, यह मापने का मानक इंजीनियरिंग पैमाना है कि एक री-एनकोड की गई इमेज अपने स्रोत से कितनी दूर हटती है, डेसिबल में व्यक्त। ज़्यादा आँकड़ा मतलब करीबी मेल। हमारे एंड-टू-एंड टेस्ट में, यहाँ इस्तेमाल JPEG राइटर ने 1024 बाय 768 फ़ोटो पर डिफ़ॉल्ट क्वालिटी पर 43.66 dB PSNR दिया। संदर्भ के लिए, 36 dB वह मोटा सीमा है जिसके नीचे फ़र्क ज़्यादातर दर्शकों को साफ़ दिखने लगता है, जबकि 40 dB और ऊपर को आम तौर पर फ़ोटोग्राफ़िक सामग्री के लिए perceptually transparent कहा जाता है। 43.66 dB पर बदलाव, किसी भी व्यावहारिक वेब या प्रिंट मक़सद के लिए, स्रोत जैसा ही दिखता है। इस वर्ज़न में क्वालिटी तय है, कोई स्लाइडर नहीं। अगर किसी ख़ास वर्कफ़्लो के लिए सटीक क्वालिटी स्तर चाहिए, तो उस काम के लिए कोई ज़्यादा कॉन्फ़िगर करने योग्य टूल बेहतर बैठता है।
बदलाव के बाद फ़ाइल साइज़: WebP-से-JPG आम तौर पर बड़ी होती है
WebP फ़ोटोग्राफ़ को JPEG से ज़्यादा कुशलता से कम्प्रेस करती है। जब आप उल्टी दिशा में, WebP से JPG में बदलते हैं, तो आप एक कम कुशल फ़ॉर्मैट पर जाते हैं, इसलिए आउटपुट आम तौर पर इनपुट से बड़ा निकलता है। हमारी माप में, 1024 बाय 768 पर एक WebP फ़ोटोग्राफ़ ने JPEG बनाई, उस एक मामले में थोड़ी छोटी क्योंकि JPEG ने वह इमेज अच्छे से encode कर दी। पर बड़ी फ़ोटो पर बढ़ोतरी लगातार रहती है। एक तस्वीर जो WebP बनकर आती है, तुलनीय दृश्य क्वालिटी पर करीब JPEG बनकर जा सकती है। यह कोई बग या कन्वर्टर के बिगड़ने का संकेत नहीं है। यह एक ज़्यादा कुशल फ़ॉर्मैट से एक कम कुशल पर जाने की अपेक्षित क़ीमत है, और वह बढ़त बस सार्वभौमिक कम्पैटिबिलिटी की लागत है।
मेटाडेटा: EXIF, GPS, और क्या हटता है
WebP फ़ाइलें EXIF मेटाडेटा रख सकती हैं, जिसमें GPS निर्देशांक, कैमरा मॉडल, शटर स्पीड, अपर्चर और ओरिएंटेशन शामिल हैं। JPEG फ़ाइलें भी EXIF रख सकती हैं। पर यहाँ की कन्वर्ज़न प्रक्रिया आउटपुट से सारा मेटाडेटा हटा देती है। बनी JPEG में सिर्फ़ पिक्सेल डेटा रहता है, कोई EXIF नहीं, कोई IPTC कॉपीराइट फ़ील्ड नहीं, कोई XMP एडिट इतिहास नहीं, और Firefox व WebKit में कोई ICC प्रोफ़ाइल नहीं, जबकि Chrome और Edge ICC प्रोफ़ाइल रखते हैं। यह ब्राउज़र के ड्रॉइंग स्तर पर होता है और इसे ओवरराइड नहीं किया जा सकता। ज़्यादातर वेब प्रकाशन के लिए हटा मेटाडेटा बेहतर नतीजा है: यह कुछ किलोबाइट घटाता है, GPS निर्देशांक हटाता है जो बता सकते हैं कि फ़ोटो कहाँ ली गई, और कैमरा या एडिटिंग विवरण लीक होने से बचाता है। आर्काइव या क़ानूनी काम के लिए जहाँ मेटाडेटा बचना चाहिए, इस कन्वर्टर के बजाय किसी समर्पित EXIF-संरक्षक एडिटर का इस्तेमाल कीजिए।
WebP-से-JPG बदलाव में कितना समय लगता है?
Chromium, Firefox और WebKit पर हमारे एंड-टू-एंड टेस्ट में, 1024 बाय 768 फ़ोटोग्राफ़ के लिए JPEG encode चरण Chromium पर 16 मिलीसेकंड, Firefox पर 12 और WebKit पर 17 लगा। 3840 बाय 2160 की बड़ी फ़ोटो के लिए encode चरण ने Chromium पर करीब 1.5 सेकंड जोड़े। आप जो कुल समय असल में महसूस करते हैं उसमें ब्राउज़र का फ़ाइल डिस्क से पढ़ना, WebP डिकोड चरण और encode से पहले सतह का ड्रॉ भी जुड़ता है। 4 मेगापिक्सेल से कम फ़ोन फ़ोटो के लिए पूरा चक्कर एक सेकंड से नीचे रहता है। 8 मेगापिक्सेल से ऊपर बड़ी DSLR फ़ोटो के लिए डेस्कटॉप ब्राउज़र पर 2 से 5 सेकंड की उम्मीद कीजिए। मोबाइल डिवाइस अकेले encode के लिए डेस्कटॉप से करीब 3 से 5 गुना धीमे चलते हैं, जो मोबाइल CPU प्रदर्शन के अंतर से मेल खाता है।