WebP तकनीक के फायदे और नुकसान का विश्लेषण (2021)
(eng.aurelienpierre.com)- WordPress और प्रमुख ब्राउज़रों में WebP सपोर्ट आने से फोटो लाइब्रेरी को माइग्रेट करना आसान हो गया, लेकिन वास्तविक तस्वीरों में फ़ाइल साइज़ में कमी की तुलना में posterization और ringing जैसी क्षति अधिक स्पष्ट दिखती है
- Google और कई WordPress plugins बताते हैं कि WebP, JPEG से छोटा होता है और
lossy 80पर्याप्त है, लेकिन मौजूदा JPEG को फिर से WebP में बदलने पर lossy compression की क्षति जमा हो सकती है - स्टूडियो पोर्ट्रेट और film scan जैसी उन इमेजों में जहाँ smooth gradation महत्वपूर्ण है, WebP 95~96 भी JPEG 85+noise के बराबर या उससे भारी परिणाम देता है
- औसत SSIM और औसत फ़ाइल साइज़ की तुलना फ़ोटोग्राफ़रों के लिए ज़रूरी worst-case handling की गारंटी नहीं देती, और जिन वेबसाइटों पर हर इमेज के लिए quality tuning मुश्किल है वहाँ स्थिरता अधिक महत्वपूर्ण है
- यदि किसी साइट पर इमेज क्वालिटी महत्वपूर्ण है, तो JPEG 85~90 बनाए रखना, dithering या सूक्ष्म noise जोड़ना, मौजूदा JPEG का WebP re-encoding टालना, और CDN·responsive images·lazy loading का उपयोग करना अधिक व्यावहारिक है
WebP अपनाने की उम्मीदें और वास्तविक समस्याएँ
- WordPress ने
image/webpMIME type upload स्वीकार करना शुरू किया और सितंबर 2020 के बाद प्रमुख ब्राउज़र WebP दिखाने लगे, जिससे फोटो लाइब्रेरी को WebP में माइग्रेट करना आसान हो गया - WebP आकर्षक विकल्प लगता है क्योंकि तुलना में इसे समान गुणवत्ता पर JPEG से 15% छोटा बताया जाता है और Google 25~34% तक छोटा होने का दावा करता है
- WordPress में ऐसे कई plugins हैं जो मौजूदा media library को WebP में बदलते हैं, और उनमें से काफ़ी plugins बाहरी सर्वर पर conversion करने वाले SaaS तरीके से काम करते हैं
- कुछ plugins और तकनीकी दस्तावेज़ बताते हैं कि WebP quality
lossy 80से ऊपर ज़्यादातर तस्वीरों के लिए अनावश्यक है, लेकिन logo वाले उदाहरण वास्तविक फोटो वर्क की समस्याओं का पर्याप्त प्रतिनिधित्व नहीं करते
मौजूदा JPEG को WebP में दोबारा compress करने पर होने वाली क्षति
- WordPress media को
lossy 80quality पर bulk convert करने के बाद बैकग्राउंड में posterized rings दिखाई देने लगे - समस्या वाली इमेज Ilford Delta 400 film को Mamiya RB 67 से शूट किए गए 6×7cm medium format scan की थी, और मूल स्रोत 16-bit scan से शुरू हुआ था
- Delta 400 का silver grain प्राकृतिक dithering की तरह काम करता है, जिससे smooth क्षेत्रों में posterization रुकती है, लेकिन WebP conversion के बाद gradation सीढ़ियों की तरह टूट गई
- मूल JPEG quality 85 भी पूरी तरह साफ़ नहीं थी, लेकिन WebP conversion की तुलना में बेहतर थी; इसका बड़ा कारण पहले से lossy-compressed JPEG पर WebP lossy compression की एक और परत चढ़ना था
- Google Page Speed Insights और कई plugins इस तरह के re-encoding workflow को सुझाते हैं या आसान बनाते हैं, लेकिन वास्तविक quality loss के लिहाज़ से यह सुरक्षित नहीं है
वास्तविक तस्वीरों पर तुलना प्रयोग
- RAW तस्वीरों को darktable से सीधे encode करके केवल एक बार compress करने की स्थिति में भी WebP की कमज़ोरी दिखाई दी
- टेस्ट इमेज वास्तविक studio headshot थी, जिसमें soft lighting और background gradation बहुत महत्वपूर्ण थे
- JPEG और WebP दोनों को quality 90 पर सेव करके और 8-bit Floyd-Steinberg dithering लागू करने पर:
- JPEG 85 और WebP 90 दोनों को असफल माना गया
- WebP में posterized rings का contrast अधिक था, इसलिए वह और खराब दिखा
- WebP 90, सुझाए गए
lossy 80से 10 points अधिक quality पर होने के बावजूद समस्या बनी रही - JPEG 90 ठीक-ठाक दिखा, लेकिन फ़ाइल साइज़ बड़ा था
- WebP को lossless में सेव करने पर quality साफ़ हो गई, लेकिन फ़ाइल साइज़ संतोषजनक नहीं था; JPEG 90 लगभग उसके एक-तिहाई साइज़ पर अंतर करना कठिन था, और JPEG 95 आधे से थोड़ा अधिक साइज़ पर लगभग वैसा ही दिखा
- Floyd-Steinberg dithering की जगह -48 dB PSNR का random noise जोड़ने वाले टेस्ट में भी WebP अभी भी posterization के प्रति अधिक संवेदनशील रहा
- JPEG 85+noise जितना smooth दिखने के लिए WebP quality 95~96 के बीच चाहिए थी
- इस स्थिति में WebP, JPEG 85+noise से 39% अधिक भारी था, और JPEG 90+Floyd-Steinberg dithering से भी 30% अधिक भारी था
- WebP परिणामों में अब भी हल्की ringing बनी रही
औसत metrics और फोटो quality के बीच का अंतर
- WebP की श्रेष्ठता का मूल्यांकन image datasets के औसत SSIM और औसत bit size पर बहुत अधिक निर्भर करता है
- औसत मान उस output stability की गारंटी नहीं देते जिसकी एक फ़ोटोग्राफ़र को web portfolio में ज़रूरत होती है
- फोटो portfolio वह क्षेत्र नहीं है जहाँ compression backend मनमाने ढंग से fail कर सकता हो
- हर इमेज के लिए WebP quality को बारीकी से adjust करना समय लेने वाला काम है, और WordPress में ऐसा workflow भी कठिन माना जाता है
- SSIM औसत, variance और covariance पर आधारित image similarity metric है, इसलिए यह वास्तविक perceptual metric को पर्याप्त रूप से नहीं दर्शाता और इस पर विवाद भी है
- compression damage में केवल संख्यात्मक विचलन का आकार ही नहीं, बल्कि artifacts का स्वभाव भी महत्वपूर्ण होता है
- random noise कुछ हद तक स्वीकार्य हो सकता है
- pattern वाले blotches या सीढ़ीनुमा gradients तस्वीर को अधिक बुरी तरह बिगाड़ते हैं
वे दृश्य जहाँ WebP खास तौर पर कमज़ोर पड़ता है
- फोटो कार्य में सबसे कठिन दृश्य अक्सर तीखे detail नहीं बल्कि smooth gradation वाले होते हैं
- जब किसी दीवार पर लगभग point light source जैसी रोशनी पड़कर प्राकृतिक background बनाती है, तब background में पर्याप्त texture होना चाहिए, लेकिन वह subject से ध्यान नहीं खींचना चाहिए
- WebP compression के उदाहरण अक्सर sharp, deep depth-of-field और high-frequency detail वाले दृश्यों को दिखाते हैं, लेकिन ऐसे दृश्यों में posterization की संभावना कम होती है, इसलिए वे algorithm की कमज़ोरी को अच्छी तरह नहीं दिखाते
- sharpness की कमी हमेशा फोटो को बर्बाद नहीं करती, लेकिन smooth vignetting का सीढ़ियों की तरह टूट जाना स्वीकार करना कठिन क्षति है
फ़ॉर्मेट डिज़ाइन और रंग से जुड़ी समस्याएँ
- WebP, RGB या RGBalpha फ़ॉर्मेट है, इसलिए black-and-white इमेज को single-channel grayscale इमेज के रूप में सेव नहीं किया जा सकता
- टेस्ट में दिखी posterization magenta और green rings के कारण और खराब लगी, जिसे chroma subsampling से होने वाले color shift के रूप में समझा गया
- यदि शुद्ध black-and-white format को single channel में सेव किया जा सके, तो अतिरिक्त chroma shift पैदा न हो
- AVIF ने इस हिस्से को हल किया है, लेकिन इसे तकनीकी रूप से व्यापक और व्यावहारिक होने में कम से कम 10 साल लगने की संभावना मानी गई है
इमेज quality बचाने के उपाय
- जिन वेबसाइटों पर इमेज महत्वपूर्ण हैं, खासकर visual artists के portfolio में, वहाँ JPEG quality 90 या कम से कम 85 बनाए रखना बेहतर माना गया है
- smooth gradation को बचाने के लिए इमेज में हमेशा dithering या बहुत हल्का noise जोड़ने की सलाह दी गई है
- मौजूदा JPEG को WebP में बदलने से बचना बेहतर है, और अपवाद केवल तब होना चाहिए जब ऊपर के उदाहरण जैसी क्षति स्वीकार्य हो
- loading speed और perceived responsiveness बढ़ाने के लिए format conversion से अधिक सुरक्षित तरीका CDN, responsive image sizes, और image lazy loading का उपयोग करना है
- बाहरी सर्वर पर conversion करने वाला SaaS तरीका लागत बढ़ाता है, वास्तविक quality factors को सार्वजनिक नहीं करता, और security plugins से मज़बूत किए गए WordPress environment में HTTP connection errors भी पैदा कर सकता है
- सर्वर पर सीधे ImageMagick या GraphicsMagick चलाने का तरीका बेहतर है, और PHP interface के बजाय सीधे server program का उपयोग करने वाली approach की सिफ़ारिश की गई है
- यदि तकनीकी डेवलपर्स और image algorithm designers केवल औसत metrics के आधार पर format choice थोपते हैं, तो इससे वास्तविक कलाकारों का समय और लागत दोनों बर्बाद हो सकते हैं
1 टिप्पणियां
Hacker News की राय
WebP में भी वही समस्या दिखी, इसलिए ज़्यादातर JPG/PNG पर वापस लौट गए; फ़ोटो के लिए jpg और UI-टाइप images के लिए png इस्तेमाल करते हैं
असली समस्या शायद यह है कि बहुत से लोग फर्क महसूस नहीं कर पाते, और इसकी वजह लगता है कि पिछले 10 सालों में desktop monitors innovation से दूर एक blind spot में अटके रहे हैं। यहाँ आधे लोग शायद 2012 के आसपास आए 1920x1080 LCD पर example images देख रहे होंगे, और यह भी समस्या का हिस्सा है
अजीब बात है कि फोन जैसे छोटे screens और 4K TV जैसे बड़े screens में viewing distance के हिसाब से pixel density शानदार हो गई है, लेकिन 20~40-inch panels 2000s के मध्य के स्तर पर अटके हुए हैं
साथ ही, लेखक ने अगर bright background वाली example photo इस्तेमाल की होती या article background को black कर दिया होता, तो बेहतर होता। सफेद background पर black image में आंखों को adapt करना मुश्किल होता है, इसलिए समस्या देखना कठिन है; dark background पर रखने से फर्क कहीं ज़्यादा आसानी से दिखता है
इसलिए display quality को मुख्य समस्या मानना मुश्किल है। यह driver या post-processing filter की समस्या हो सकती है, या बस हर किसी की नज़र ऐसी चीज़ें देखने वाली नहीं होती
अगर image processing में रुचि हो, तो अनुभव से ऐसी details दिखने लगती हैं। लेखक निश्चित रूप से मुझसे अधिक अनुभवी है, और ऐसी details देखना शायद उसके काम का हिस्सा भी हो सकता है। खराब monitor पर भी वह समस्या पहचान सकता है और यह भी बता सकता है कि वह monitor किस तरह खराब है
example अच्छा नहीं है। अगर कुछ दिखाना है, तो screenshot को zoom करके artifacts दिखाने चाहिए
PNG को WebP में बदलते समय “lossless WebP” का lossless क्या वास्तव में lossless नहीं है?
संदर्भ के लिए, PNG को lossless WebP में convert करने के बाद वापस PNG में decode करें, और उस PNG को फिर WebP में convert करें, तो बिल्कुल वही lossless WebP file मिलती है। चाहे PNG से सीधे lossless encoding करें, या PNG optimizer से “crush” किए गए उसी PNG से encode करें, वही WebP बनता है
अच्छा है कि कुछ लोग सच में best results की चिंता करते हैं, लेकिन ज़्यादातर लोग शायद इसे न तो notice करेंगे और न ही इसकी परवाह करेंगे
पहली दो तस्वीरों को अलग-अलग tabs में खोलकर जल्दी-जल्दी switch करके देखा, लेकिन कोई फर्क बिल्कुल नहीं दिखा। दो अलग-अलग monitors, Chrome और Firefox में आजमाया, और आखिरी पुरुष वाली तस्वीरों में भी वही था
Edit: आखिरी तुलना में WebP दो बार था और link गलत था। jpg यहां है, फिर भी फर्क नहीं दिखता
https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20...
Edit: सच देखने के लिए असल में click करके full-size image देखनी पड़ती है। लेख में embedded images में, यहां तक कि जिन्हें lossless बताया गया था, उनमें भी compression artifacts काफी ज्यादा थे
इसलिए https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20... वाली full-size lossless WebP ठीक लगती है, लेकिन उसी image का embedded version https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20... भयानक दिखता है
Edit 2: नीचे की तीनों में फर्क काफी साफ है
https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20... lossy-noise.jpg (216 kB JPEG)
https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20... (150 kB WebP)
https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20... (301 kB WebP)
दोनों WebP examples में, यहां तक कि 301 kB version में भी, posterization साफ दिखाई देती है
सोच रहा हूं कि कहीं इस्तेमाल किए गए WebP encoder या settings में कोई समस्या तो नहीं है
Edit 3: monitor gamma और color profile gradients में posterization की visibility को प्रभावित कर सकते हैं
https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20...
https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20...
हालांकि अगर आपको photography में दिलचस्पी नहीं है, तो शायद आप इसे देखने की उतनी परवाह न करें
ऐसे फर्क छोटे नहीं होते। जो लोग फर्क नहीं देख पाते या जिन्हें बहुत ध्यान से देखने पर ही दिखता है, उन्हें समझना चाहिए कि बहुत लोगों को वह फर्क तुरंत दिख जाता है
दूसरी image में मैंने jpeg 90 [1] और webp 90 [2] versions खोले, और दोनों की तुलना करने पर गर्दन के दाईं ओर साफ banding issue है। पूरी image के चारों ओर घूमती हुई गहरी पट्टी भी थोड़ी कम दिखती है, लेकिन अगर पता हो कि कहां देखना है तो अब भी दिखती है
jpeg 90 की तुलना webp lossless, jpeg 100, jpeg 95 में से किसी एक से करें तो गर्दन के दाईं ओर jpeg 90 की बहुत हल्की banding भी दिखती है। हालांकि zoom किए बिना उसे पहचानना बहुत मुश्किल है
[1] https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20...
[2] https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20...
मेरे हिसाब से WebP की सबसे खराब और आसानी से पहचानी जा सकने वाली कमी मजबूरन 4:2:0 chroma subsampling है। चमकीले रंगों वाली कई images में रंग और brightness का नुकसान बिना किसी professional नज़र के भी साफ दिखता है
तुलना [1] में ऊपर दाईं ओर का balloon अपना चमकदार लाल रंग खो चुका है, और तुलना [2] में बीच की चमकीली नीली neon art ने brightness खो दी है
[1] https://storage.googleapis.com/demos.webmproject.org/webp/cm...
[2] https://storage.googleapis.com/demos.webmproject.org/webp/cm...
मुझे हैरानी है कि यह command jpg > webp conversion में हल्का नीला रंग क्यों बना देती है, जबकि बाकी रंग ठीक-ठाक निकलते हैं
cwebp -pass 10 -m 6 -nostrong -sharp_yuv -quiet -q 60 -sharpness 2 $1 -oयह लेख WebP में मुझे सबसे बड़ी लगने वाली समस्या को address नहीं करता। browser के बाहर इस format की असुविधा छोटे size reduction से बड़ी है
बेहतर formats मौजूद हैं। HEIF, AVIF, H.266 से आ सकने वाले video codec से प्रेरित formats भी हैं और JPEG XL भी है; WebP बिना पर्याप्त फायदे वाला compromise लगता है
बहुत लोग लगभग best-case WEBP image में banding दिखती है या नहीं, इस पर बहस करते हैं, लेकिन असल दुनिया की WEBP images आम तौर पर भयानक दिखती हैं। मैंने हाल में ही इसे गंभीरता से notice करना शुरू किया है
बेशक अब generative upscaling process से image को “साफ” किया जा सकता है, लेकिन किसी के 45KB बचाने की वजह से इतनी बिजली खर्च करना काफी ironic है
यह मुझे उन दिनों की याद भी दिलाता है जब GIF को JPEG में convert किया जाता था। करीब 25 साल पहले बहुत सारे साफ-सुथरे GIF screenshots थे जिनके लिए 256 colors काफी थे, लेकिन JPEG ने उन्हें खराब कर दिया
Google developers से WEBP इस्तेमाल करने को कहता है, लेकिन जिन्हें कोई देखना नहीं चाहता उन video ads को petabytes में serve करने में उसे कोई दिक्कत नहीं
अगर बात यह है कि “non-expert आँखों को ठीक लग सकता है, लेकिन photographers को नहीं”, तो मुझे लगता है कि WebP क्यों खराब है यह “non-experts” को दिखाने और लेख व tone को justify करने के लिए बेहतर examples होने चाहिए
शायद Android पर देखने की वजह से हो, लेकिन सभी photos की quality एक जैसी लग रही है
और अगर “expert eyes” के लिए photos बनानी हैं, तो ऐसी technology इस्तेमाल न करें जो expert eyes के लिए सही न हो? या ऐसे फैसले दूसरों पर न छोड़ें?
इस thread में लेखक के बारे में बकवास करते हुए और confidently कहते हुए कि कोई फर्क नहीं है, ऐसे comments देखकर वह frustration जायज लगती है। पहली images में फर्क न देख पाना ठीक है, लेकिन इसलिए confidently यह मत कहिए कि आप लेखक से ज्यादा जानते हैं, या image codecs design मत कीजिए
full screen में देखे बिना भी दिख गया। grimace कर रहे आदमी को देखें, और shoulder के पास shirt के edge पर नज़र डालें
खराब image quality वाली photo में shoulder के आसपास ऐसा light bleeding होता है जैसे backlight हो
अच्छी quality वाली photo में gradient smooth है। shoulder के आसपास backlight जैसा light bleeding नहीं है, बस smooth gradient background जैसा दिखता है
साफ कहूँ तो मैं photographer नहीं, DevOps engineer हूँ। मैंने पेशेवर तौर पर JavaScript भी आखिरी बार कम-से-कम 11 साल पहले इस्तेमाल किया था
यह काफी आसानी से दिखता है
[1] https://news.ycombinator.com/item?id=38653224
इस blog post का पूरा basic idea formats के बीच comparison के तौर पर basic validation पास करने की कोशिश नहीं, बल्कि शिकायत और clicks बढ़ाने जैसा लगता है
थोड़ा background बताऊँ तो Aurelien Pierre को Darktable का प्रमुख contributor माना जाता है। Darktable एक open source RAW developing/catalog tool है, यानी open source Adobe Lightroom जैसा
वे सही तरीके को लेकर मजबूत राय रखने के लिए जाने जाते हैं, और कभी-कभी इतने कड़े कि उन्होंने Darktable को fork करके अपना project Ansel भी बना लिया। पहले HN discussion भी हुई थी https://news.ycombinator.com/item?id=38390914
अगर archive image quality की चिंता है, तो जब तक uncompressed original से करना संभव न हो, पुरानी images को नए format में फिर से compress नहीं किया जाएगा। lossy compressed source से re-encode करने पर quality खराब होती है। storage सस्ता है और लगातार और सस्ता होता जा रहा है
असली मायने वाली बात यह है कि नई photos को नए format में compress करते समय safe settings चुनें
इस संदर्भ में Google ने Chrome से JPEG XL support हटाकर और उसे restore करने से भी इनकार करके, WebP जैसे मौजूदा formats की तुलना में “incremental benefit” पर्याप्त नहीं है—यह दावा करते हुए JPEG XL को रोक रखा है
-q100पर दिखने वाली banding आती है और JPEG-q90पर भी visually transparent रहता हैलगता है लेखक ने गलत जगह focus किया। format differences पर ध्यान दिया, जबकि असल में compression method पर ध्यान देना चाहिए था। image processing programs में वही number, जैसे “80”, set करने पर भी compression result अलग होता है
सच में meaningful comparison करना हो तो smooth gradient background वाली black-and-white studio portrait photo ही नहीं, बल्कि complex background वाली full-color images जैसी अलग-अलग images भी test करनी चाहिए। imagemagik, graphicsMagick, sharp, photoshop और तरह-तरह की cloud services जैसे कई programs भी साथ में देखने चाहिए
एक और समस्या use case है। अगर कोई professional photographer full-size, highest-quality photos upload करना चाहता है, तो creative/editing result पूरी तरह preserve रहे इसके लिए शायद compress न करना ही बेहतर हो। लेकिन वह use case किसी website द्वारा reasonable size और reasonable quality वाली images दिखाने वाले average use case जैसा नहीं है
कई स्थितियों में बहुत छोटी image के लिए stronger compression स्वीकार करना worthwhile होता है, और कई images में compression उतना noticeable नहीं होगा जितना full-resolution professional studio photo में, जिसमें बड़ा gradient background हो
व्यक्तिगत रूप से मुझे कोई meaningful difference नहीं दिखता, इसलिए मेरी आंखें निश्चित रूप से “non-expert eyes” लगती हैं
लेखक की शिकायत image background में बने artifacts को लेकर है
perception लोगों में इतना अलग हो सकता है, यह हैरानी की बात है
WebP के gradients अक्सर video stills जैसे दिखते हैं। chroma subsampling इस्तेमाल की जा सकने वाली luminance approximations की density घटाता है, और जितना ज्यादा लागू होता है, gradients उतने खराब होते जाते हैं
high contrast और high-frequency detail पर बड़ा असर नहीं पड़ता, लेकिन gradients बुरी तरह खराब हो सकते हैं
chroma का मतलब color होता है, और color subsampling वह तरीका है जिसका उपयोग इसलिए होता है कि ज्यादा महत्वपूर्ण luminance channel से information न निकाली जाए