Codec तुलनाओं पर गंभीरता से विचार

 (cloudinary.com)
10 पॉइंट द्वारा lifthrasiir 2022-12-15 | 2 टिप्पणियां | WhatsApp पर शेयर करें

Chrome के JPEG XL प्रयोग को बंद करने की खबर (https://hi.news.hada.io/topic?id=7709) के बाद issue tracker इस सवाल से भर गया था कि इसे क्यों हटाया जा रहा है। इसके जवाब में AVIF पक्ष ने अपने द्वारा तुलना किए गए benchmark डेटा को प्रकाशित कर बचाव किया था (https://storage.googleapis.com/avif-comparison/index.html)। यह लेख उसी सामग्री का विश्लेषण और JPEG XL पक्ष की प्रतिक्रिया है.

सिर्फ JPEG XL के समर्थन/विरोध से अलग, यह image format की तुलना करते समय ध्यान देने योग्य महत्वपूर्ण बिंदुओं को रेखांकित करता है, इसलिए पढ़ने लायक है। मुख्य बिंदु संक्षेप में:

  • AVIF पक्ष की decoding speed Chrome और libjxl के पुराने versions पर आधारित थी, इसलिए वह बढ़ा-चढ़ाकर दिखाई गई है। हाल के versions के आधार पर JPEG XL (default settings) ~= 12-bit AVIF < JPEG XL (fast decoding settings) ~= 8-bit AVIF < JPEG से recompress किया गया JPEG XL, और हर inequality के बीच अंतर केवल लगभग 10% है.

  • कुल decoding speed से अधिक महत्वपूर्ण यह है कि उपयोग करने योग्य image किस समय पर दिखाई देती है, और JPEG XL progressive decoding को support करता है, इसलिए यहाँ उसे बड़ा फायदा मिलता है। (यह web पर Largest Contentful Paint जैसी बातों के उसी संदर्भ में है.)

  • Encoding performance और encoded image की quality की अलग-अलग तुलना की गई है, लेकिन libjxl में encoding performance और encoding quality को पूरी तरह स्वतंत्र रूप से नियंत्रित किया जा सकता है, जबकि AVIF सहित अधिकांश अन्य encoders में यह संभव नहीं है, इसलिए उनकी ऐसी तुलना नहीं की जा सकती.

  • Encoding के समय प्रस्तुत target quality range बहुत चौड़ी थी और probability distribution को ध्यान में नहीं रखा गया। "On the fly" कहा गया सबसे कम quality स्तर इतना खराब है कि कोई भी उसे किसी भी उद्देश्य के लिए उपयोग नहीं कर सकता। साथ ही AVIF औसतन low-quality images में मजबूत दिखता है, लेकिन file size थोड़ा सा बढ़ते ही कई मामलों में JPEG XL काफी आगे निकल जाता है; इसे अनुचित तरीके से average करने से JPEG XL की ताकत कमजोर पड़ती दिखी.

  • Test में उपयोग किया गया dataset उपयुक्त नहीं है। Lossless compression में magazine images को scan करके बने Kodak set का उपयोग किया गया, और lossy compression में Noto Emoji set शामिल है, जिसे आमतौर पर vector graphics या lossless compression के साथ उपयोग किया जाता है; दोनों ही lossless और lossy compression के सामान्य use cases नहीं हैं.

  • अगर image compression performance पर चर्चा वर्तमान के लिए है, तो image format द्वारा supported features भविष्य के लिए हैं। यदि किसी image format को browser में शामिल करने के बाद हटाया नहीं जा सकता, तो उसका मूल्यांकन करते समय features पर और भी अधिक ज़ोर दिया जाना चाहिए.

संबंधित पढ़ाई

2 टिप्पणियां

 
lifthrasiir 2022-12-15

ऑफिस जाने से पहले जल्दी-जल्दी लिखने की वजह से कुछ छोटी-मोटी गलतियाँ हैं (...). सख्ती से कहें तो, "on the fly" सबसे कम quality नहीं बल्कि सबसे ज़्यादा speed है (हालाँकि JPEG XL को छोड़कर ज़्यादातर encoders में इसका quality के साथ उलटा संबंध होता है). साथ ही, Kodak dataset के बारे में मैंने न जाने क्या सोचकर इसे magazine लिखा था, लेकिन वास्तव में यह film से scan किया गया है.