Chromium ने JpegXL को मर्ज किया

 (chromium-review.googlesource.com)
2 पॉइंट द्वारा GN⁺ 2026-01-14 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Chromium कोडबेस में JpegXL डिकोडर को इंटीग्रेट किया गया है, जिससे ब्राउज़र JXL फ़ॉर्मैट इमेज को प्रोसेस कर सकेगा
  • यह बदलाव Gerrit code review पेज पर “Wire up JXL decoder” शीर्षक से देखा जा सकता है
  • यह मर्ज JpegXL फ़ॉर्मैट सपोर्ट के लिए एक अहम कदम है, जिसमें डिकोडर को जोड़ने का काम शामिल है
  • code review Chromium के src रिपॉज़िटरी के बदलाव (7184969) के रूप में दर्ज है
  • वेब ब्राउज़र में अगली पीढ़ी के image format सपोर्ट के विस्तार के लिहाज़ से यह महत्वपूर्ण है

Chromium में JpegXL डिकोडर का इंटीग्रेशन

  • Gerrit code review एंट्री “Wire up JXL decoder (7184969)” Chromium प्रोजेक्ट में JpegXL डिकोडर को जोड़ने वाला बदलाव है
    • यह बदलाव Chromium की src रिपॉज़िटरी के भीतर किया गया है
    • code review प्लेटफ़ॉर्म के रूप में chromium-review.googlesource.com का उपयोग किया जाता है
  • शीर्षक के अनुसार, यह JXL (JpegXL) डिकोडर को ब्राउज़र के भीतर wire up करने का काम है
  • पेज पर अतिरिक्त विवरण या code की बारीकियां दिखाई नहीं देतीं, केवल बदलाव का शीर्षक ही देखा जा सकता है

तकनीकी संदर्भ

  • JpegXL एक अगली पीढ़ी का image compression format है, जिसका लक्ष्य मौजूदा JPEG की तुलना में बेहतर efficiency है (मूल पाठ में इसका सीधा उल्लेख नहीं है, केवल तकनीकी नाम मौजूद है)
  • Chromium में डिकोडर मर्ज होने से, JXL इमेज प्रोसेसिंग क्षमता को code स्तर पर सक्षम करने की बुनियाद तैयार होती है
  • यह बदलाव ब्राउज़र इंजन की media decoding system के विस्तार से जुड़ी तकनीकी प्रगति है

दस्तावेज़ की स्थिति

  • यह पेज Gerrit code review के cached snapshot के रूप में दिखाया गया है
  • इसमें “shadow DOM is hidden” जैसी चेतावनी पंक्ति शामिल है, लेकिन असल code सामग्री दिखाई नहीं देती
  • इसलिए इस दस्तावेज़ से पुष्टि की जा सकने वाली जानकारी केवल बदलाव का शीर्षक और review identifier (7184969) तक सीमित है

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

1 टिप्पणियां

 
GN⁺ 2026-01-14
Hacker News की टिप्पणियाँ

  • मैंने Cloudinary ब्लॉग पोस्ट देखी; यह webp, jpegxl, avif, jpeg आदि की तुलना करने वाली एक पुरानी लेकिन शानदार पोस्ट है
    चार्ट बहुत अच्छे से व्यवस्थित हैं, और AVIF बहुत धीमा है

    • यहाँ JPEG को सबसे कम quality पर सेट करने पर भी वह काफ़ी बेहतर दिख रहा था
      संबंधित सेक्शन लिंक
    • मुझे समझ नहीं आ रहा कि यह साइट ठीक-ठीक क्या करना चाहती है
      स्क्रीनशॉट देखें
    • जैसा कि उद्धृत वाक्य में कहा गया है, अगर JPEG XL ने अभी lossy/lossless दोनों में सबसे बेहतर codec की स्थिति मज़बूत कर ली है, तो यह JPEG और PNG को एक साथ replace कर सकने वाली बड़ी प्रगति है
    • लेकिन इस टेस्ट में hardware-accelerated encoder/decoder का उपयोग नहीं किया गया

  • jxl-rs लाइब्रेरी JPEG XL का Rust implementation है
    यह अपेक्षाकृत नया प्रोजेक्ट है, लेकिन Rust की वजह से security stability के मामले में कुछ भरोसा होता है
    Chromium की पिछली चर्चा के समय यह लाइब्रेरी मौजूद नहीं थी

    • मुझे याद है Google ने JPEG XL को ‘रुचि की कमी’ की वजह से ठुकराया था। शायद यह security issue की वजह से नहीं था
    • मैं “Rust security concerns कम कर देता है” वाली बात से सहमत नहीं हूँ। memory safety अपने आप में security नहीं है
      Rust overconfidence ला सकता है, और ऐसे मामले बन सकते हैं जहाँ threat modeling को छोड़ दिया जाए
      उल्टा, एक सावधान C programmer ज़्यादा सुरक्षित हो सकता है
    • मैंने सच में देखा कि इसमें unsafe code कितना है
      search result link

  • हाल ही में मैंने WebP और AVIF की तुलना की; WebP लगभग तुरंत encode हो जाता है, जबकि AVIF को 1MP image पर 20 सेकंड से ज़्यादा लगते हैं
    JXL का support अभी कम है इसलिए इसे व्यवहार में इस्तेमाल नहीं कर सकता, लेकिन WebP जैसी speed और उससे बेहतर quality की उम्मीद है

    • कहा गया कि rav1e का update कई सालों से रुका हुआ है, इसलिए aom या svt-av1 जैसे encoder इस्तेमाल करना बेहतर है
    • AVIF में CPU usage parameters को adjust करना पड़ता है। default setting बहुत ऊँचा CPU level इस्तेमाल करती है, इसलिए यह धीमा है
      मेरे environment में 2MP AVIF लगभग 100ms में बन जाता है

  • यह अफ़सोस की बात है कि JPEG XL की public spec तक खुली पहुँच नहीं है

    • मुझे लगता है private standards बनाए रखना शर्मनाक है
    • समस्या यह है कि ISO, IEC जैसी संस्थाओं के बहुत से दस्तावेज़ paywall के पीछे हैं

  • हमें एक और नया image format मिल गया है, लेकिन चिंता है कि क्या यह फिर उसी स्थिति में फँस जाएगा जहाँ conversion के बिना इसका इस्तेमाल नहीं हो पाएगा

    • फिर भी Microsoft ने भी JPEG XL add-on जारी किया है, और अब जब Google पीछे हट गया है, तो मुझे लगता है कि यह वास्तविक मौका है
      Microsoft Store लिंक
    • वास्तव में बहुत से apps इसे पहले से support करते हैं — Affinity, Photoshop, Microsoft Photos, Gimp, और iOS 17+/macOS 12+ में system-wide support भी है
      Chromium तो बल्कि देर से आया है
    • बेशक, किसी भी नए format को अपनाने में हमेशा लगभग 10 साल लगते हैं

  • विकि में JPEG XL की feature list पढ़ते समय मैंने multi-channel images और multi-page documents जैसी दिलचस्प चीज़ें देखीं
    इसमें अच्छी बातें हैं, लेकिन यह धीरे-धीरे TIFF जितना जटिल होता लग रहा है

  • JPEG और JPEG-XL के बीच अभी भी बहुत सी समानताएँ हैं
    अगर नया implementation मौजूदा JPEG support को भी integrate कर दे, तो क्या code size कम किया जा सकता है, यह सोचने वाली बात है

    • वास्तव में उस feature के लिए JPEG-XL Rust repository में issue खुला हुआ है
      issue #513 लिंक

  • निजी तौर पर, मैं WEBP जैसे नए format की बजाय मौजूदा JPEG का इस्तेमाल जारी रखना चाहूँगा
    ज़्यादातर programs इसे support करते हैं, और आम उपयोगकर्ताओं के लिए JPEG + PNG काफ़ी है
    साधारण animation के लिए GIF, और जटिल चीज़ों के लिए video इस्तेमाल किया जा सकता है

    • “JPEG XL” नाम के बावजूद केवल JPEG का extension नहीं है
      यह PNG से छोटे size में lossless encoding कर सकता है, और मौजूदा JPEG को 20% और compress करते हुए reversible transcoding भी support करता है
      HDR, wide gamut, progressive loading जैसी कई सुविधाएँ हैं, इसलिए web delivery के लिए भी यह आदर्श है
      jpegxl.info देखें
    • WebP को अब de facto standard format माना जा सकता है
      Safari 14 के बाद सभी प्रमुख browsers इसे support करते हैं, और Windows 10·macOS Big Sur के बाद यह default रूप से शामिल है
      support status, software list देखें
    • GIF अब अप्रभावी है। इसे video से replace करना 5~10 गुना अधिक कुशल है
      संबंधित लेख

  • मैं लंबे समय से JPEG XL, WebP, AVIF की बहस सुनता आया हूँ, लेकिन इसे अच्छी तरह नहीं जानता था
    benchmarks देखने पर लगता है कि JpegXL compression speed और size दोनों में WebP से बेहतर है, तो फिर Chromium इसे अपनाने में हिचकिचा क्यों रहा था, यह जानने की जिज्ञासा है

    • WebP और AVIF, VP8/AV1 के साथ code share करते हैं इसलिए browser integration आसान है, जबकि JPEG-XL अलग codebase है, इसलिए implementation का बोझ ज़्यादा है
      साथ ही libjxl में 100,000 से अधिक lines का C++ code है, इसलिए security vulnerabilities का जोखिम था
      Rust implementation के mature होने के साथ लगता है कि Chrome अब इसे फिर से review कर रहा है
    • JPEG XL progressive decoding support करता है
      demo video
    • Google का दावा था कि “अगर ऐसे कई मिलते-जुलते formats हों, तो केवल security risk बढ़ता है,” और AVIF अकेला काफ़ी है
    • AVIF low bpp (low quality) में अच्छा है लेकिन lossless में कमज़ोर, जबकि JXL high quality और lossless में मज़बूत है
    • पहले JPEGXL C++ लाइब्रेरी maintenance बंद जैसी स्थिति में थी, लेकिन Rust version आने के बाद browser adoption संभव हुआ

  • मुझे जिज्ञासा थी कि क्या JPEG XL animation support करता है

    • support तो करता है, लेकिन frame-to-frame compression नहीं होने की वजह से यह अप्रभावी है और सामान्य video से बड़ा हो जाता है
    • Chrome platform status page के अनुसार animation, HDR, और progressive decoding सभी support हैं
      विस्तृत लिंक
    • मैंने सच में Canary browser में टेस्ट किया और animation ठीक से काम कर रहा था
    • किसी ने मज़ाक में कहा कि WebP असल में “image के रूप में video format” है, जबकि JPEG XL “video के रूप में image format” है, इसलिए एक विडंबनापूर्ण symmetric structure बन जाती है 😄