क्या Google ने JPEG XL सपोर्ट को फिर से ज़िंदा किया?

 (tonisagrista.com)
5 पॉइंट द्वारा GN⁺ 2025-12-03 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • Chromium इंजन द्वारा JPEG XL के सपोर्ट को पुनर्स्थापित किए जाने के बाद, एक समय हटाए गए इमेज फॉर्मेट पर फिर से ध्यान केंद्रित हो रहा है
  • 2022 में Google ने JPEG XL को “इकोसिस्टम में रुचि की कमी” का कारण बताकर हटाया था, लेकिन समुदाय और प्रमुख कंपनियों का लगातार दबाव जारी रहा
  • Meta, Intel, Adobe, Cloudinary, Krita जैसी कई संस्थाओं ने फॉर्मेट को बनाए रखने की ज़रूरत का सार्वजनिक रूप से समर्थन किया
  • हाल ही में PDF Association ने HDR कंटेंट के लिए बेस फॉर्मेट के रूप में JPEG XL अपनाने की मंशा व्यक्त की, जिससे यह रुझान मजबूत हुआ
  • Chrome की पुनः-एंट्री (reintroduction) को JPEG XL के व्यापक standardization संभावनाओं को बढ़ाने वाले एक turning point के रूप में देखा जा रहा है

JPEG XL की वापसी की पृष्ठभूमि

  • 2022 में Chromium टीम ने JPEG XL को “इकोसिस्टम में पर्याप्त रुचि की कमी” और “मौजूदा फॉर्मैट की तुलना में लाभ की कमी” के कारण कोड और फ्लैग हटाए
    • उस समय समुदाय की तरफ से Meta, Intel, Cloudinary, Adobe, ffmpeg, libvips, Krita जैसी प्रमुख संस्थाओं का समर्थन सामने आया
    • इसके बाद ब्लॉग, वीडियो और SNS के ज़रिए हटाने के निर्णय की अनुचितता पर लगातार प्रतिक्रियाएँ दिखीं
  • 2025 के अंत में Chromium टीम ने Obsolete स्थिति में पड़े JPEG XL मुद्दे को Assigned में बदलते हुए औपचारिक रूप से पुनर्स्थापन प्रक्रिया शुरू की
    • Blink डेवलपर्स ग्रुप में Rick Byers ने “high-performance और memory-safe JPEG XL decoder” को स्वागतयोग्य बताते हुए टिप्पणी की
    • यह निर्णय Safari सपोर्ट, Firefox के रुख में बदलाव, और PDF Association की अपनाने की पहल जैसे सकारात्मक संकेतों पर आधारित था

Firefox और Rust-आधारित डिकोडर विकास

  • Firefox टीम को JPEG XL के C++ आधारित libjxl डिकोडर में सुरक्षा जोखिम का भय था, इसलिए “memory-safe” Rust वर्ज़न की जरूरत पर जोर दिया गया
    • इसी कारण Google Research ने Rust इम्प्लिमेंटेशन jxl-rs का विकास शुरू किया
    • यह प्रोजेक्ट JPEG XL के ब्राउज़र के अंदर सुरक्षित एकीकरण की संभावना बढ़ाने वाला रहा

PDF Association की अपनाने की पहल

  • PDF Association के CTO Peter Wyatt ने PDF स्पेक में JPEG XL को PDF स्पेसिफिकेशन के लिए HDR इमेज का डिफ़ॉल्ट फॉर्मेट बनाने की इच्छा व्यक्त की
    • इससे डॉक्यूमेंट और पब्लिशिंग सेक्टर में JPEG XL के standardize होने की संभावना मजबूत हो सकती है

JPEG XL के मुख्य तकनीकी फीचर

  • पुराने JPEG की lossless re-compression सपोर्ट के कारण, गुणवत्ता घटाए बिना लगभग 30% क्षमता (space) कम की जा सकती है
  • वाइड कलर गमट और HDR सपोर्ट, अधिकतम 32-bit channels और 4,099 channels हैंडल करने की क्षमता
  • अधिकतम इमेज साइज 1,073,741,823×1,073,741,824 का समर्थन होने से अल्ट्रा-हाई-साइज़ इमेज संभव हैं
  • progressive decoding का सपोर्ट मिलने से वेब ट्रांसफर efficiency बेहतर होती है
  • animation, alpha transparency, depth map फीचर इसमें मौजूद हैं
  • generation loss के प्रति मजबूत architecture से repeated encoding के बाद quality degradation न्यूनतम रहता है

निष्कर्ष

  • JPEG XL next-gen इमेज फॉर्मेट की जरूरतें पूरी करता है और Chrome इंजन की वापसी को इसके व्यापक अपनाने का महत्वपूर्ण turning point माना जा सकता है
  • समुदाय के लंबे समय से जारी दबाव के बाद हुई पुनर्स्थापना के चलते यह वेब इमेज इकोसिस्टम का नया मानक उम्मीदवार बनकर उभर रहा है
  • लेखक Chromium के पुनर्मूल्यांकन का स्वागत करते हुए भी कहते हैं कि यह फैसला बहुत देर से आया।

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

2 टिप्पणियां

 
GN⁺ 2025-12-03
Hacker News की राय

  • JPEG XL की कम चर्चित शानदार खूबियों में से एक यह है कि यह JPEG से lossless transcoding करते हुए लगभग 20% storage space बचाने वाला मोड देता है
    यह original entropy bitstream को जस का तस रखता है, इसलिए पूरी तरह reversible है
    GCP इसे DICOM Store API में लागू कर रहा है, इसलिए JXL की space savings का फायदा लेते हुए भी इसे real time में JPEG में बदलकर serve किया जा सकता है
    हमारी कंपनी GCP DICOM Store में दर्जनों PB डेटा स्टोर करती है, इसलिए उम्मीद है कि इस फीचर से सालाना फीस में बड़ी बचत हो सकती है
    ब्राउज़र में native support की भी उम्मीद है, और सुना है कि Chrome टीम आखिरकार इसे सपोर्ट करेगी

    • average JPEG encoder या mozjpeg की तुलना में फर्क क्या है, यह जानना चाहता हूँ
    • पहले GCP DICOM Store को टेस्ट करने का समय नहीं मिला था, इसलिए यह व्यवहार में कैसा है, यह जानना चाहता हूँ
      यह पूरा PACS है, WADO implementation है, या सिर्फ एक custom API, यह जानना चाहता हूँ
    • अगर यह reversible है, तो बस JPEG XL में स्टोर करके serve करते समय फिर से convert क्यों न किया जाए?
      पूछ रहा हूँ कि क्या processing time बहुत ज़्यादा लगता है
    • अगर original DICOM को वैसे भी स्टोर करना है, तो transcoding का मतलब क्या है, इस पर संदेह है
      लगता है storage cost का ज़्यादातर हिस्सा DICOM का ही होगा
    • आखिरकार GCP के बड़े ग्राहकों को इस फीचर से बड़ा फायदा मिलेगा, इसलिए लगता है कि Chrome में JXL को आगे बढ़ाने की वजह internal customers भी हो सकते हैं

  • JPEG XL का मुकाबला AVIF से नहीं है
    AVIF पहले ही de facto standard बन चुका है, लगभग सभी ब्राउज़र इसे सपोर्ट करते हैं, और Apple के default image format के रूप में भी इस्तेमाल हो रहा है
    JXL को अभी ब्राउज़र सपोर्ट कम मिला है, लेकिन archival, professional photography, medical use जैसे niche बाज़ारों में यह जगह बना रहा है
    लगभग 10 साल बाद लोग इसे बस “JPEG” कहने लगें, इतना आम भी हो सकता है
    AVIF एक open, royalty-free standard है, और JPEG/WebP की तुलना में इसकी compression efficiency कहीं बेहतर है, JXL के भी लगभग बराबर
    JXL का maximum image size बड़ा है, लेकिन adoption के मामले में AVIF काफी आगे है
    AV2 आने पर quality gap लगभग खत्म हो जाएगा, और दोनों formats आगे बढ़ते हुए करीब समान quality level बनाए रखेंगे, ऐसा लगता है

    • AVIF का JPEG या WebP से ज़्यादा efficient होना तो तय है, लेकिन JXL से इसकी सीधी टक्कर नहीं है
      practical quality settings में JXL ज़्यादा compression ratio और तेज़ encoding·decoding speed दिखाता है
      साथ ही यह progressive decoding भी सपोर्ट करता है
      AV2 आने पर शायद बराबरी कर ले, लेकिन अभी मुझे लगता है JXL काफी आगे है
    • Chrome टीम ने JXL support बंद करने की एक वजह यह भी बताई थी कि AVIF पहले से ही काफी अच्छा था
      लगता है यह पुनर्विचार उसी फैसले से जुड़ा हुआ है
    • “Apple का default image format AVIF है” यह बात गलत लगती है
      iPhone तो HEIF इस्तेमाल करता है
    • मैंने libjxl सीधे इस्तेमाल किया है, और यह memory usage के मामले में भारी और unstable लगा
      high-resolution images encode करने के लिए कभी-कभी terabyte स्तर की RAM चाहिए होती थी
      codebase देखकर हैरानी हुई, काफी बिखरा हुआ लगा, और कई options ठीक से काम नहीं कर रहे थे
      jxl-rs के साथ फिर से कोशिश करना सकारात्मक है, लेकिन वही developers इसमें शामिल हैं, इसलिए सावधानी से देख रहा हूँ

  • संभावना है कि Chromium JPEG XL फीचर के लिए jxl-rs crate इस्तेमाल करे
    शायद यह पर्याप्त रूप से stable होने तक इंतज़ार करके फिर integrate करना चाहता है
    संबंधित issue यहाँ देखा जा सकता है

    • Mozilla का रुख भी कुछ ऐसा ही था, लेकिन Google ने कुछ समय तक hostile attitude दिखाया था
      users के विरोध के बावजूद issue बंद कर दिया गया था, और हाल ही में फिर खोला गया
      शायद यह PR problem या internal असंतोष की वजह से भी हो सकता है
    • jxl-rs में डेढ़ साल से ज़्यादा समय तक कोई commit नहीं आया था
      अब चीज़ों का ठीक चलना शायद अच्छे भाग्य का नतीजा भी हो सकता है

  • मैंने JPEG XL की reference implementation (C++) देखी थी, और 2 साल पहले तक code quality अच्छी नहीं थी
    देखकर लगा था कि इसमें security issues पैदा हो सकते हैं

    • इसलिए Mozilla और Google दोनों memory-safe implementation की शर्त पर JXL support पर विचार कर रहे हैं
      Rust version विकसित किया जा रहा है, और Google की योजना Chromium के सभी decoders को धीरे-धीरे Rust में बदलने की है
    • सच कहें तो आज के समय (2025) में C++ में लिखा गया बड़ा image-processing code अपने आप में security risk है
      यह सिर्फ JPEG XL की समस्या नहीं है

  • JPEG XL का maximum resolution 1,073,741,823 × 1,073,741,824 है, इसलिए यह सैकड़ों petabytes तक के ultra-high-resolution images को represent कर सकता है
    व्यवहार में compression के बाद भी इसका आकार दर्जनों से सैकड़ों PB हो सकता है

    • 600DPI के हिसाब से देखें तो एक भुजा मैराथन दूरी के बराबर होगी
      अगर इतनी विशाल image को बहुत कम bytes में define किया जा सके, तो यह DOS attack vector भी बन सकता है
      इसे A4 sheets में बदलकर समझाने की कोशिश में Gemini calculator ने units गड़बड़ा दिए और बेकार नतीजा दे दिया
    • इतनी विशाल images को संभालने का एकमात्र practical तरीका tiling और pyramid structure है
    • शायद यह पूरी पृथ्वी की लगभग 4cm resolution वाली image जितना बड़ा होगा
    • उस resolution पर selfie ली जाए तो वह super-resolution microscope स्तर की होगी
    • AVIF के विपरीत JPEG XL efficient progressive decoding सपोर्ट करता है, इसलिए डाउनलोड के दौरान भी जल्दी low-quality preview देखा जा सकता है

  • पिछले HN चर्चाओं का संग्रह
    Chromium Team Re-Opens JPEG XL Feature Ticket
    FSF Slams Google over Dropping JPEG-XL in Chrome
    Google set to deprecate JPEG XL support in Chrome 110
    Chromium jpegxl issue closed as won't fix

  • मैं कई सालों से .avif इस्तेमाल कर रहा हूँ
    यह perfect नहीं है, लेकिन .jpg या .png से काफी बेहतर लगता है
    .webp या jpeg-xl पर भी विचार किया था, लेकिन अंत में .avif से संतुष्ट हूँ
    हालांकि Google का web standards पर लगभग एकतरफा नियंत्रण होना पसंद नहीं है
    किसी commercial company का digital ecosystem को नियंत्रित करना अच्छा नहीं है

    • “.jpg से .avif बेहतर है” वाले वाक्य में .avif दो बार दोहराया गया है, इसलिए थोड़ा भ्रम होता है
    • अगर high-quality JPEG को छोटा बनाना हो, तो jpegli आज़माने की सलाह दूँगा
      jpegli GitHub
      AVIF की visually lossless setting सही चुनी जाए तो वह jpegli से छोटा हो सकता है, लेकिन औसतन jpegli ज़्यादा efficient है
    • वैसे अंग्रेज़ी में “since some years” की जगह “for several years” अधिक natural लगता है
    • JPEG XL को कई बार दोबारा save करने पर भी quality loss कम होता है, इसलिए यह web environment के लिए फायदेमंद है
      संबंधित वीडियो: YouTube लिंक

  • JXL को हटाने का फैसला “पूरे Google” ने नहीं बल्कि Chrome टीम ने किया था
    JXL को Google Zurich lab के Jyrki Alakuijala ने डिज़ाइन किया था, और वे Chrome टीम में नहीं बल्कि Google Research में थे
    Chrome टीम में Mountain View केंद्रित बंद संस्कृति होने की बात कही गई

    • Jyrki Brotli, WebP lossless, WOFF2, jpegli जैसे कामों के भी शानदार engineer हैं
      JpegXL हटाए जाने के बाद उनका jpegli बनाना भी एक तरह की प्रतिक्रिया थी
    • इस स्थिति को शायद Conway’s Law से समझाया जा सकता है

  • लगता है JXL में C++ आधारित multithreaded dependencies ज़्यादा होने से security attack surface बढ़ सकता था, इसलिए यह देर से आगे बढ़ा
    Mozilla और Google दोनों इससे बचने के लिए Rust implementation को प्राथमिकता देते हैं
    standard अपने आप में निश्चित रूप से पुराने formats से बेहतर है

    • 10 करोड़ lines वाला दावा बहुत बढ़ा-चढ़ाकर कहा गया लगता है
    • वास्तव में यह लगभग 30,000 lines है, और single-threaded version करीब 10,000 lines का है
      binary size भी AVIF से काफी छोटा है, और specification भी बहुत अधिक concise है
    • चूँकि Google ने JXL development में हिस्सा लिया था, इसलिए memory-safe decoder जल्दी न बनाना उसकी अपनी ज़िम्मेदारी भी है
    • क्या शायद 100,000 lines कहना था? उनमें से काफ़ी हिस्सा test code होगा
    • असल libjxl लगभग 112,000 lines का है, इसलिए 10 करोड़ lines वाला दावा 3 orders of magnitude से गलत है

  • कहा जा रहा है कि iPhone 17 Pro की RAW files JPEG XL में compress की जाएँगी