Google ने मूल रूप से WebP को JPEG इमेज फ़ॉर्मैट की जगह इस्तेमाल करने के लिए, एक नुकसान पहुंचाने वाले इमेज फ़ॉर्मैट के तौर पर डेवलप किया था. यह ऐसा फ़ॉर्मैट था जो JPEG के तौर पर एन्कोड की गई तुलना में कम क्वालिटी वाली इमेज फ़ाइल से छोटी फ़ाइलें बना सकता था. बाद में, इस फ़ॉर्मैट में हुए अपडेट में नुकसानरहित कंप्रेशन, PNG जैसी ऐल्फ़ा चैनल ट्रांसपेरंसी, और GIF जैसे ऐनिमेशन के विकल्प को शामिल किया गया. इन सभी को JPEG स्टाइल के लॉसी कंप्रेशन के साथ इस्तेमाल किया जा सकता है. WebP एक अभरोसेमंद फ़ॉर्मैट है. इस फ़ॉर्मैट में कई तरह के काम किए जा सकते हैं.
WebP का नुकसान पहुंचाने वाला कंप्रेशन एल्गोरिदम, एक ऐसे तरीके पर आधारित होता है जिसका इस्तेमाल VP8 वीडियो कोडेक, वीडियो में मुख्य-फ़्रेम को कंप्रेस करने के लिए करता है. बड़े लेवल पर, यह JPEG एन्कोडिंग की तरह होता है: WebP, अलग-अलग पिक्सल के बजाय "ब्लॉक" के हिसाब से काम करता है. साथ ही, इसमें ल्यूमिनेंस और क्रोमिनेंस के बीच एक जैसा फ़र्क़ होता है. WebP के लुमा ब्लॉक 16x16 के होते हैं, जबकि क्रोमा ब्लॉक 8x8 के होते हैं. साथ ही, उन्हें "मैक्रोब्लॉक" 4x4 सब-ब्लॉक में बांटा जाता है.
जहां WebP काफ़ी हद तक JPEG से अलग होते हैं, उनकी दो सुविधाएं होती हैं: "ब्लॉक अनुमान" और "अडैप्टिव ब्लॉक क्वांटाइज़ेशन".
अनुमान को ब्लॉक करें
ब्लॉक अनुमान, ऐसी प्रोसेस है जिससे हर क्रोमिनेंस और ल्यूमिनेंस ब्लॉक के कॉन्टेंट का अनुमान, उनके आस-पास के ब्लॉक की वैल्यू के आधार पर लगाया जाता है. खास तौर पर, मौजूदा ब्लॉक के ऊपर और बाईं ओर के ब्लॉक की वैल्यू के आधार पर ऐसा किया जाता है. जैसा कि आप कल्पना कर सकते हैं, यह काम करने वाले एल्गोरिदम काफ़ी जटिल होते हैं, लेकिन इसे आसान भाषा में रखने के लिए कहें: "अगर मौजूदा ब्लॉक के ऊपर नीला है और मौजूदा ब्लॉक की बाईं ओर नीला है, तो मान लीजिए कि यह ब्लॉक नीला है."
सही मायनों में, कुछ डिग्री के लिए PNG और JPEG भी इसी तरह का अनुमान लगाते हैं. WebP की खासियत है कि यह आस-पास की ब्लॉक के डेटा को सैंपल करता है और फिर मौजूदा ब्लॉक को कई अलग-अलग "अनुमान वाले मोड" से पॉप्युलेट करने की कोशिश करता है. साथ ही, इमेज के छूटे हुए हिस्से को "ड्रॉ" करने की कोशिश करता है. इसके बाद, हर अनुमान मोड से मिलने वाले नतीजों की तुलना, असली इमेज के डेटा से की जाती है और सबसे नज़दीकी अनुमानित मैच को चुना जाता है.
यहां तक कि सबसे नज़दीकी अनुमानित मैच भी पूरी तरह से सही नहीं होंगे. इसलिए, उस ब्लॉक की अनुमानित और असल वैल्यू के बीच के अंतर को फ़ाइल में एन्कोड किया जाता है. इमेज को डिकोड करते समय, रेंडरिंग इंजन एक ही डेटा का इस्तेमाल करके, एक जैसा अनुमान लगाने वाला लॉजिक लागू करता है. इससे हर ब्लॉक के लिए एक जैसी अनुमानित वैल्यू मिलती हैं. इसके बाद, फ़ाइल में कोड में बदले गए अनुमान और उम्मीद के मुताबिक इमेज के बीच का अंतर, अनुमानों पर लागू किया जाता है. यह बिलकुल उसी तरह किया जाता है जिस तरह Git प्रतिबद्धता फ़ाइल की बिलकुल नई कॉपी के बजाय लोकल फ़ाइल पर लागू किए जाने वाले डिफ़रेंशियल पैच को दिखाती है.
उदाहरण के लिए: सही अनुमान दिखाने वाले एल्गोरिदम में शामिल जटिल गणित के बारे में ज़्यादा जानने के बजाय, हम WebP जैसी एन्कोडिंग की खोज करेंगे. इसमें सिंगल अनुमान मोड होगा. इसका इस्तेमाल, संख्याओं की ग्रिड को उसी तरह से रिले करने के लिए किया जाएगा जिस तरह हम लेगसी फ़ॉर्मैट में करते थे. हमारे एल्गोरिदम में सिर्फ़ एक अनुमान मोड होता है. इसे हम "अनुमान मोड एक" कहेंगे. हर ब्लॉक की वैल्यू, उसके ऊपर और उसके बाईं ओर मौजूद ब्लॉक की वैल्यू का कुल योग होती है. यह वैल्यू 1 से शुरू होती है.
अब, मान लें कि हम नीचे दिए गए असली इमेज डेटा से शुरुआत कर रहे हैं:
111151111
122456389
अपने अनुमानित मॉडल का इस्तेमाल करके, 2x9 ग्रिड का कॉन्टेंट तय करने पर हमें ये नतीजे मिलेंगे:
111111111
123456789
हमारा डेटा, हमारे बनाए हुए अनुमानित एल्गोरिदम के लिए सही है. यह अनुमानित डेटा, हमारे असली डेटा से काफ़ी मिलता-जुलता है. बिलकुल सही नहीं, बेशक—असल डेटा में कई ब्लॉक होते हैं, जो अनुमानित डेटा से अलग होते हैं. इसलिए, हम जो एन्कोडिंग भेजते हैं उसमें न सिर्फ़ इस्तेमाल के लिए अनुमान लगाने का तरीका शामिल होता है, बल्कि उन ब्लॉक का अंतर भी शामिल होता है जो उनकी अनुमानित वैल्यू से अलग होना चाहिए:
_ _ _ _ +4 _ _ _ _
_ _ -1 _ _ _ -4 _ _
जिस लेगसी फ़ॉर्मैट एन्कोडिंग के बारे में हमने बात की है उसी तरह की आसान भाषा इस्तेमाल करें:
सुझाव मोड एक का इस्तेमाल करके 2x9 ग्रिड. +4 से 1x5, -1 से 2x3, -4 से 2x7.
आखिरी नतीजा, कोड में बदली गई एक फ़ाइल है. इस फ़ाइल की परफ़ॉर्मेंस शानदार है.
अडैप्टिव ब्लॉक क्वानटाइज़ेशन
JPEG कंप्रेशन एक ब्लैंकेट ऑपरेशन है, जिसमें इमेज में मौजूद हर ब्लॉक पर एक ही तरह के वॉल्यूम का लेवल लागू किया जाता है. एक जैसी कंपोज़िशन वाली इमेज में, यह साफ़ तौर पर समझ में आता है, लेकिन असली दुनिया की तस्वीरें हमारे आस-पास की दुनिया से ज़्यादा एक जैसी नहीं हैं. इसका मतलब यह है कि हमारी JPEG कंप्रेशन सेटिंग, ज़्यादा फ़्रीक्वेंसी वाली जानकारी से नहीं, बल्कि इमेज के उन हिस्सों से तय की जाती हैं जहां JPEG कंप्रेस करने की सुविधा सबसे अच्छी होती है.
जैसा कि इस बढ़ा-चढ़ाकर दिखाया गया है, फ़ोरग्राउंड में रानी के पंख काफ़ी तेज़ दिखते हैं—हाई-रिज़ॉल्यूशन वाले ओरिजनल विंग की तुलना में थोड़ा खुरदरा दिखता है, लेकिन मूल के पंख के साथ तुलना करने के बिना यह साफ़ तौर पर नहीं दिखता. इसी तरह, मिल्कवीड का फूल और फ़ोरग्राउंड में पत्तियां—आप और मुझे हमारी प्रशिक्षित आंखों से कंप्रेशन से जुड़ी चीज़ें दिख सकती हैं. हालांकि, कंप्रेस करने की वजह से फ़ोरग्राउंड में हर चीज़ काफ़ी खराब दिख रही है. तस्वीर के सबसे ऊपर बाईं ओर दी गई कम फ़्रीक्वेंसी वाली जानकारी—पत्तियों की धुंधली हरी बैकग्राउंड—बेहद खराब लगती है. ऐसे दर्शक भी क्वालिटी की समस्या का तुरंत पता लगा लेते हैं जिन्होंने ट्रेनिंग नहीं ली है. बैकग्राउंड में हल्के-फुल्के ग्रेडिएंट को नुकीले, ठोस रंगों वाले ब्लॉक में बदल दिया जाता है.
इससे बचने के लिए WebP, संख्या बढ़ाने के तरीके को ज़रूरत के हिसाब से अपनाता है: एक इमेज को विज़ुअल तौर पर मिलते-जुलते चार सेगमेंट में बांटा जाता है. उन सेगमेंट के लिए, कंप्रेशन पैरामीटर अलग-अलग ट्यून किए जाते हैं. WebP के साथ एक जैसे बड़े कंप्रेसर का इस्तेमाल करके:
इन दोनों इमेज फ़ाइलों का साइज़ करीब-करीब एक ही है. जब हम राजा के पहलुओं को देखते हैं, तो क्वालिटी भी उतनी ही होती है. अगर आप बहुत करीब से देखते हैं, तो आपको आखिर में कुछ छोटे-मोटे अंतर दिख सकते हैं. WebP में, मिल्कवीड के फूल बस थोड़े तीखे होते हैं—फिर से, वे तब तक काफ़ी नहीं होते, जब तक कि आप दोनों को अगल-बगल में नहीं रखते और क्वालिटी में अंतर ढूंढने की कोशिश नहीं करते. बैकग्राउंड इन दोनों को मिलाकर, एक अलग कहानी है: इसमें JPEG की साफ़-साफ़ दिखने वाली आर्टफ़ैक्ट की झलक नहीं है. WebP फ़ॉर्मैट में हमें फ़ाइल का साइज़ एक जैसा ही होता है, लेकिन बेहतर क्वालिटी की इमेज देने के लिए, कुछ ऐसी छोटी-मोटी जानकारी दें या इसका पता लगाएं जिनका पता हमारे साइकोविज़ुअल सिस्टम को न लगा हो. ऐसा तब होता है, जब हम इन दोनों की आपस में तुलना नहीं करते.
WebP का इस्तेमाल करना
WebP के अंदरूनी हिस्से, JPEG एन्कोडिंग की तुलना में काफ़ी ज़्यादा जटिल हो सकते हैं. हालांकि, हमारे रोज़ाना के काम के हिसाब से, यह तरीका जितना आसान है, उतना ही आसान: WebP की एन्कोडिंग की सभी जटिलता को, एक "क्वालिटी" वैल्यू के आस-पास बनाया जाता है. इसे JPEG की तरह 0-100 से दिखाया जाता है. एक बार फिर, इसका यह मतलब नहीं है कि आपके चैनल पर सिर्फ़ एक "क्वालिटी" सेटिंग का इस्तेमाल सीमित किया जाता है. आपको WebP एन्कोडिंग की पूरी जानकारी तैयार करनी चाहिए, लेकिन यह समझने के लिए कि ये सेटिंग आम तौर पर नहीं दिखतीं. इससे फ़ाइल के साइज़ और क्वालिटी पर क्या असर पड़ता है.
Google, cwebp कमांड लाइन एन्कोडर उपलब्ध कराता है. इसकी मदद से, अलग-अलग फ़ाइलों या इमेज की पूरी डायरेक्ट्री का फ़ॉर्मैट बदला जा सकता है या कंप्रेस किया जा सकता है:
$ cwebp -q 80 butterfly.jpg -o butterfly.webp
Saving file 'butterfly.webp'
File: butterfly.jpg
Dimension: 1676 x 1418
Output: 208418 bytes Y-U-V-All-PSNR 41.00 43.99 44.95 41.87 dB
(0.70 bpp)
block count: intra4: 7644 (81.80%)
Intra16: 1701 (18.20%)
Skipped: 63 (0.67%)
bytes used: header: 249 (0.1%)
mode-partition: 36885 (17.7%)
Residuals bytes |segment 1|segment 2|segment 3|segment 4| total
macroblocks: | 8%| 22%| 26%| 44%| 9345
quantizer: | 27 | 25 | 21 | 13 |
filter level: | 8 | 6 | 19 | 16 |
और अगर आप कमांड लाइन की ओर झुक नहीं रहे हैं, तो Squoosh हमें WebP कोड भेजने की तरह ही काम करेगा. इससे हमें अलग-अलग एन्कोडिंग, सेटिंग, क्वालिटी लेवल, और JPEG एन्कोडिंग से फ़ाइल के साइज़ में अंतर के बीच, साथ-साथ तुलना करने का विकल्प मिलता है.