JPEG XL और Pareto Front

 (cloudinary.com)
2 पॉइंट द्वारा GN⁺ 2024-03-02 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • पहले एक बार में बड़ी इमेज प्रोसेस करने वाली JPEG XL encoding में आने वाली bottleneck को libjxl 0.10 ने streaming encoding API के ज़रिए कम किया, जिससे lossless compression की memory usage और speed में बड़ा सुधार हुआ
  • 13500×6750 NASA night Earth image की lossless encoding, libjxl 0.9 के लगभग 8GB RAM·2 मिनट से अधिक से घटकर libjxl 0.10 में 0.7GB RAM, single-thread 30 सेकंड, और 8-thread 5 सेकंड रह गई
  • compression methods की तुलना सिर्फ file size से करना पर्याप्त नहीं है; encoding speed और compression density को साथ देखने वाला Pareto front, time budget के हिसाब से सबसे बेहतर settings तय करने का मानदंड बनता है
  • lossy compression में compression ratio, speed, और image quality को साथ देखना चाहिए, और SSIMULACRA2 60~90 रेंज में JPEG XL ने खासकर high-quality~visually lossless क्षेत्र में मजबूत नतीजे दिखाए
  • jpegli जैसे नए JPEG encoder बहुत तेज encoding वाले हिस्सों में अब भी प्रतिस्पर्धी हैं, लेकिन JPEG XL व्यापक speed range में lossless और lossy compression दोनों के लिए एक प्रमुख विकल्प बन चुका है

libjxl 0.10 में मुख्य बदलाव

  • libjxl 0.10 JPEG XL reference implementation का नया version है, और इसका सबसे बड़ा बदलाव streaming encoding API का पूरा implementation है
  • यह API बड़ी इमेज को एक बार में प्रोसेस करने के बजाय chunk units में encode करती है
    • पूरी इमेज को memory में लोड करने से होने वाला RAM burden कम होता है
    • encoding speed भी बेहतर होती है
    • खासकर बड़ी इमेज की lossless compression में इसका असर स्पष्ट है

lossless compression में memory और समय की कमी

  • libjxl 0.10 से पहले lossless JPEG XL encoding में बड़ी memory usage और लंबा processing time समस्या बन सकते थे
  • उदाहरण इमेज NASA की 13500×6750 night Earth image है
    • TIFF file 64MB है
    • compression से पहले size 273MB है
  • default effort setting e7 पर उसी इमेज को compress करने का परिणाम:
    • libjxl 0.9 ने लगभग 8GB RAM का उपयोग किया और 2 मिनट से अधिक लिया, जबकि result file 33.7MB थी
    • single-thread पर 2 मिनट 40 सेकंड, और 8-thread पर 2 मिनट 6 सेकंड लगे, यानी threads बढ़ाने का असर बहुत बड़ा नहीं था
    • measurement environment 12-core Apple M3 Pro CPU और 36GB RAM वाले नवंबर 2023 MacBook Pro का था
  • libjxl 0.10 में उसी इमेज की compression के लिए सिर्फ 0.7GB RAM चाहिए
    • single-thread 30 सेकंड
    • 8-thread 5 सेकंड
    • result file 33.2MB थी
  • effort value बढ़ाने पर compression ratio बेहतर होता है, लेकिन CPU time के मुकाबले improvement धीरे-धीरे कम होता जाता है
    • e1 से e2 पर जाते समय 0.1 सेकंड की जगह 1 सेकंड खर्च कर 22MB कम किए जा सके
    • e2 से e7 पर जाते समय 1 सेकंड की जगह 5 सेकंड खर्च कर अतिरिक्त 11MB कम हुए
    • e7 से e9 पर जाते समय 1MB और कम करने के लिए लगभग 2 मिनट इंतज़ार करना पड़ा

effort setting का व्यावहारिक संतुलन

  • compression settings मूल रूप से समय और file size के बीच का संतुलन हैं
  • image editing के दौरान local save करने वाले authoring workflow में बहुत मजबूत compression ज़रूरी नहीं होती, इसलिए low-effort encoding उचित हो सकती है
  • one-to-many delivery scenarios या long-term archiving में कुछ MB कम करने के लिए अधिक CPU time खर्च करना मूल्यवान हो सकता है

Pareto front के ज़रिए compression methods की तुलना

  • compression techniques की तुलना करते समय सिर्फ file size देखने से वास्तविक चयन के लिए ज़रूरी जानकारी छूट सकती है

  • तुलना के axis और chart की व्याख्या

    • मुख्य axis हैं compression density और encoding speed
    • किसी method के Pareto-optimal होने का मतलब है कि ऐसा कोई दूसरा method नहीं है जो समान या बेहतर compression density को कम समय में हासिल करे
    • ऐसे Pareto-optimal methods के समूह को Pareto front कहा जाता है
    • chart में vertical axis encoding speed है, और horizontal axis compressed image का average bits per pixel है
    • vertical axis megapixels per second में है, और wide speed range को दिखाने के लिए log scale का उपयोग किया गया है
    • compression से पहले 8-bit RGB, 24bpp होता है
    • ऊपर की ओर जाना तेज़ है, और बाईं ओर जाना बेहतर compression ratio दर्शाता है

lossless compression तुलना के परिणाम

  • पिछला libjxl भी सभी speed ranges में Pareto-optimal नतीजे देता था, और PNG·lossless AVIF·lossless WebP से छोटी files बनाता था
  • libjxl 0.10 ने पिछले version की तुलना में काफी अंतर से बेहतर परिणाम दिखाए
  • QOI chart में नहीं दिखाया गया, लेकिन उसने 154Mpx/s पर 17bpp दर्ज किया
    • libjxl की सबसे low-effort setting ने 427Mpx/s पर 11.5bpp तक compress किया
    • libjxl 2.7 गुना तेज़ था और result file 32.5% छोटी थी

non-photo images में lossless compression

  • photos में natural noise अधिक होने से lossless compression कठिन होती है, जबकि non-photo images में परिणाम अलग होते हैं
  • अलग-अलग art styles वाली 41 comic images पर किए गए test में average size 7.3 megapixels थी
  • ऐसी images लगभग 4bpp तक compress हुईं, जो photo images के लगभग 10bpp से बहुत बेहतर है
  • lossless AVIF इस image type में उपयोगी नहीं था
    • उसका compression ratio PNG से भी खराब था
    • वह QOI जैसी density तक पहुँचा, लेकिन बहुत धीमा था
  • lossless WebP ने इस तरह की images में बहुत अच्छा compression ratio दिखाया
  • QOI speed और simplicity को देखते हुए ठीक है, लेकिन Pareto-optimal से काफ़ी दूर है
    • low-effort JPEG XL encoding, QOI से 2 गुना तेज़ और 31% छोटी थी
  • libjxl 0.10 ने non-photo images में भी 0.9 के मुकाबले बड़ा सुधार दिखाया
    • WebP default effort: 4.30bpp, 2.3Mpx/s
    • libjxl 0.9 effort 5: 4.27bpp, 2.6Mpx/s
    • libjxl 0.10 effort 5: 4.25bpp, 12.2Mpx/s
    • libjxl 0.10 effort 7: 4.04bpp, 5.9Mpx/s

lossy compression में quality axis जुड़ती है

  • lossless compression में सिर्फ compressed size और speed देखना काफी है, लेकिन lossy compression में image quality भी जुड़ जाती है
  • lossy image codecs और encoders की performance quality point के अनुसार बदल सकती है
    • जो encoder high-quality encoding में अच्छा हो, ज़रूरी नहीं कि low-quality में भी अच्छा हो
    • उल्टा भी सही है
  • सिर्फ compression ratio और quality को देखने वाले bitrate-distortion plots से encoding effort और compression performance के बीच का संतुलन समझना कठिन हो जाता है
  • lossy compression का Pareto front देखने के लिए compression·speed·quality के 3D space को कई quality points पर काटकर देखना पड़ता है

quality measurement और aggregation method

  • image quality व्यक्तिपरक होती है और लोगों के बीच अलग हो सकती है
  • सबसे अच्छा measurement तरीका वह experiment है जिसमें दर्जनों लोग कड़े test protocol के तहत images की तुलना या scoring करें
  • ऐसे experiments समय और लागत दोनों में भारी होते हैं, इसलिए हर encoder setting को test करना कठिन है और objective metrics का उपयोग किया जाता है
  • public metrics में अच्छे metrics के रूप में SSIMULACRA2, Butteraugli, DSSIM का उल्लेख किया जाता है
    • ये human visual system को model करने की कोशिश करते हैं और subjective evaluation से अच्छा correlation दिखाते हैं
    • PSNR या SSIM जैसे पुराने और सरल metrics, human quality judgment से अच्छी तरह मेल नहीं खाते
  • अगर evaluation उसी metric से की जाए जिसे encoder अंदर optimize करता है, तो परिणाम उस encoder के पक्ष में झुक सकते हैं
    • high-effort libjxl, Butteraugli optimize करता है
    • libavif, PSNR या SSIM optimize कर सकता है
    • SSIMULACRA2 को सुरक्षित metric माना गया क्योंकि tested encoders में से कोई इसे internal optimization के लिए इस्तेमाल नहीं करता
  • test में encoder settings इस तरह चुनी गईं कि पूरी image set पर लागू होने पर average SSIMULACRA2 score किसी खास मान के करीब रहे
  • average score ordering, WebP और AVIF के पक्ष में जाने वाला तरीका है
    • पिछले research में AVIF और WebP, JPEG·HEIC की तुलना में कम consistent थे, जबकि JPEG XL सबसे consistent encoder था
    • वास्तविक उपयोग में आप worst score या वास्तविक worst visual quality को match करना चाह सकते हैं

वास्तविक उपयोग के करीब quality range

  • lossy compression में 50:1 या 200:1 जैसी high compression ratios भी संभव हैं, लेकिन compression artifacts पैदा होते हैं
  • वास्तविक उपयोग में सबसे प्रासंगिक range SSIMULACRA2 60~90 है
  • quality points की विशेषताएँ:
    • SSIMULACRA2 90: visually lossless quality, और AVIF व JPEG XL जैसे modern codecs इसे लगभग 8:1 compression ratio, यानी 3bpp पर हासिल कर सकते हैं
    • SSIMULACRA2 80: high quality, लगभग 16:1 compression ratio, यानी 1.5bpp
    • SSIMULACRA2 70: medium-high quality, लगभग 30:1 compression ratio, यानी 0.8bpp
    • SSIMULACRA2 60: medium quality, लगभग 40:1 compression ratio, यानी 0.6bpp
  • SSIMULACRA2 60 से नीचे की quality bandwidth और कम कर सकती है, लेकिन image को खराब करने का जोखिम रहता है
  • 2024 के web में medium~high quality range सबसे प्रासंगिक है
    • HTTP Archive के अनुसार web पर AVIF का median 1bpp है, जो medium-high quality के बराबर है
    • JPEG का median 2.1bpp है, जो high quality के बराबर है
  • camera जैसे non-web use cases में high-quality~visually lossless range अधिक प्रासंगिक है

lossy compression Pareto front के परिणाम

  • lossy compression tests फरवरी 2024 के अंत तक हर encoder के latest version पर किए गए
  • encoding speed को Apple M3 Pro आधारित नवंबर 2023 MacBook Pro पर 8-thread के साथ मापा गया
  • AVIF में tiled और untiled दोनों settings का test किया गया
    • tiled settings multithreading का बेहतर उपयोग करती हैं, इसलिए तेज़ हैं
    • लेकिन इसके बदले compression density में नुकसान होता है

medium quality: SSIMULACRA2 60

  • एक ही format के अंदर भी encoder और effort settings के अनुसार परिणामों में बड़ा अंतर था
  • ऐतिहासिक रूप से व्यापक रूप से उपयोग किया जाने वाला JPEG encoder libjpeg-turbo default settings पर chart में सबसे तेज़ था, लेकिन compression density कम थी
  • WebP की compression density, libjpeg-turbo से बेहतर थी
  • mozjpeg, libjpeg-turbo से धीमा था लेकिन बेहतर compression देता था, और इस image set व quality point पर WebP से अधिक Pareto-efficient था
  • Google की JPEG XL team द्वारा बनाया गया jpegli, mozjpeg से तेज़ था और उसका compression ratio भी बेहतर था
    • यह guetzli और libjxl से मिले lessons पर आधारित है
    • यह WebP और high-speed AVIF से बेहतर compress करते हुए भी traditional JPEG files बनाता है
  • AVIF और HEIC, JPEG·WebP से बेहतर compression density पा सकते थे, लेकिन encoding धीमी थी
  • JPEG XL ने समान compression density तक पहुँचते हुए बहुत तेज़ encoding दी
  • इस quality point पर Pareto front, उचित speed ranges में JPEG XL और कई JPEG encoders से, और धीमे हिस्से में AVIF से बना था

medium-high और high-quality परिणाम

  • SSIMULACRA2 70 की medium-high quality पर कुल परिणाम medium quality जैसे ही थे
  • web के लिए सबसे उच्च प्रासंगिक quality point के रूप में average SSIMULACRA2 85 का उपयोग किया गया, ताकि अधिकांश images 80 या उससे अधिक प्राप्त करें
  • इस high-quality point पर अंतर और स्पष्ट हो गया
    • mozjpeg अब WebP को नहीं हरा पाया
    • jpegli ने अब भी WebP को हराया
    • Pareto front का बड़ा हिस्सा JPEG XL ने लिया
    • बहुत तेज़ encoding में traditional JPEG अब भी अच्छा रहा
  • इस quality point पर AVIF, Pareto front में नहीं था
    • सबसे धीमी setting पर उसने 0.5Mpx/s से कम speed में दूसरे सबसे तेज़ libjxl setting जितनी compression density हासिल की
    • वही libjxl setting 52Mpx/s पर थी, यानी 100 गुना से अधिक तेज़

decoding speed

  • अब तक की तुलना compression density और encoding speed पर केंद्रित थी
  • modern computers में decoding speed बड़ी समस्या नहीं है, लेकिन measurements की भी तुलना की गई
  • sequential JPEG, decoding speed में सबसे मजबूत है
  • mozjpeg और default jpegli द्वारा बनाई गई progressive JPEG धीमी हैं, लेकिन उचित size वाली images को बहुत तेज़ load करने लायक पर्याप्त रूप से तेज़ हैं
  • JPEG XL, sequential JPEG और progressive JPEG के बीच स्थित है
  • AVIF की decoding speed encoding method के अनुसार बदलती है
    • तेज़ लेकिन थोड़ी खराब multi-tile encoding इस्तेमाल करने पर decoding भी तेज़ होती है
    • default single-tile encoding धीमी होती है
  • measured सबसे धीमी decoding speed भी encoding speed की तुलना में पर्याप्त तेज़ थी

visually lossless और बड़ी images

  • visually lossless quality chart में WebP शामिल नहीं था
    • वह lossy mode में इस quality point तक पहुँच ही नहीं सका
    • क्योंकि WebP में 4:2:0 chroma subsampling अनिवार्य है
  • mozjpeg भी इस quality point के लिए design नहीं किया गया था, इसलिए वह libjpeg-turbo से compression और speed दोनों में खराब रहा
  • default speed setting पर libavif, libjpeg-turbo से 20% छोटा था, लेकिन encoding में एक अतिरिक्त digit जितना अधिक समय लगा
  • उसी quality point पर libjxl, libavif से 20% छोटा और 2.5 गुना तेज़ था
  • visually lossless quality का Pareto front अधिकतर JPEG XL ने लिया, जबकि सबसे तेज़ speed range में JPEG भी शामिल रहा
  • लगभग 1 megapixel web-size images पर हुए test के विपरीत, बड़ी images के test में परिणाम काफी अलग थे
    • high-quality point पर WebP, mozjpeg, और AVIF, libjpeg-turbo से खराब थे
    • HEIC ने libjpeg-turbo की तुलना में महत्वपूर्ण बचत दी
    • jpegli ने भी बेहतर speed पर महत्वपूर्ण बचत दी
    • JPEG XL ने images को 1.3bpp से कम तक compress किया, जबकि AVIF·libjpeg-turbo·WebP को 2bpp से अधिक चाहिए था

libjxl 0.10 की अंतिम स्थिति

  • libjxl 0.10 ने lossless और lossy दोनों compression में memory usage को एक-अंकीय स्तर तक घटा दिया
  • speed भी बेहतर हुई, खासकर multithreaded lossless encoding की default effort setting में speed एक-अंकीय स्तर तक बढ़ी
  • JPEG XL, lossless और lossy दोनों compression में, खासकर high-quality~visually lossless quality range में, एक मजबूत image codec के रूप में उभरता है
  • wide speed-setting range में JPEG XL, Pareto-optimal के करीब एक प्रमुख विकल्प बना हुआ है
  • traditional JPEG भी नए encoders की वजह से अब भी आकर्षक है
    • jpegli ने mozjpeg की तुलना में speed और compression दोनों में बड़ा सुधार दिखाया
    • जब बहुत ही तेज़ encoding चाहिए हो, तब traditional JPEG अब भी सबसे अच्छा विकल्प हो सकता है

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

2 टिप्पणियां

 
dofuuz 2024-03-08

लगता है jpegli encoder, mozjpeg के बाद, फिर से jpg की उम्र बढ़ा रहा है...
विडंबना यह है कि इसे JXL पक्ष ने बनाया है, लेकिन शायद यही JXL के प्रसार में रुकावट भी बन जाए...
 
GN⁺ 2024-03-02
Hacker News की रायें

  • lossless WebP कितना अच्छा है, इस पर भी ध्यान देना चाहिए
    यह बात अक्सर इस चर्चा में दब जाती है कि WebP में MozJPEG encoding की तुलना में साफ़ फायदा नहीं है या वह उससे भी खराब है, लेकिन lossless WebP performance और speed के मामले में सचमुच शानदार है
    PNG या OptiPNG से काफी बेहतर है, online support भी अब पर्याप्त हो चुका है, और बेहद खराब lossless AVIF से तो जाहिर तौर पर बहुत आगे है

    • lossless WebP सचमुच अच्छा है, लेकिन यह केवल 8-bit support करता है, इसलिए future-proofing कमजोर है
      SDR images के लिए ठीक है, लेकिन HDR के लिए यह उतनी ही बुनियादी सीमा बन जाती है जितनी GIF का 256 colors तक सीमित होना
    • lossless WebP में समस्या यह है कि यह केवल (A)RGB support करता है, और grayscale को single-color support से भी खराब workaround तरीके से encode करता है
      अगर पूरी comics को compress करना हो तो PNG अब भी सही है, और इस मामले में लगभग छोड़े जा चुके optipng की बजाय oxipng इस्तेमाल करना बेहतर है
      एक और छूटी हुई बात यह है कि lossless JPEG2000 photographic content में आश्चर्यजनक रूप से अच्छा और तेज़ हो सकता है
    • WebP में lossless WebP spec पर आधारित एक near-lossless encoding mode भी है, जिसका लगभग प्रचार नहीं हुआ
      ज़्यादातर use cases में इसे वास्तविक lossless से बेहतर माना जा सकता है, और अक्सर बिना दिखाई देने वाले नुकसान के size को आधा कर देता है
    • नए image formats AVIF और HEIC के lossless versions का पुराने PNG की तुलना में इतना खराब perform करना काफी चौंकाने वाला है
    • lossless AVIF में भी अतिरिक्त बचत की गुंजाइश दिखती है: https://www.reddit.com/r/AV1/comments/1b3lh08/comment/kstmbr...

  • बहुत low quality settings पर JPEG में दिखने वाले artifacts की वजह से पास से देखने पर वह cubist painting जैसा बिखरा हुआ लगे, फिर भी यह हैरानी की बात है कि वह image की overall quality को बेहतर बचाने वाली sharp detail approximation बनाए रखता है
    व्यावहारिक रूप से यह image को किसी abstract art style में बदल देता है, जबकि JXL और AVIF बस धुंधले हो जाते हैं

    • ऐसा इसलिए है क्योंकि JPEG को प्रति pixel 0.5 bit दिया गया है, जबकि JPEG XL और AVIF को क्रमशः लगभग 0.22 और 0.2 bit ही मिले हैं
      ये images समान compression ratio वाली नहीं हैं, बल्कि समान distortion level मिलाने की कोशिश कर रही हैं, और bits per pixel image के बगल में दिखाया गया है
      वास्तविक internet पर quality 65 का उपयोग दुर्लभ है और केवल सबसे low-quality sites पर होता है; quality 75 आम low quality है, और quality 85 औसत के करीब है
      जब compression चाहिए होता है, तो quality 94 yuv444 या उससे अधिक इस्तेमाल करता हूँ
    • अगर आप इस image की बात कर रहे हैं: https://res.cloudinary.com/jon/qp-low.png
      bitrate left column में है, और low-quality JPG, JXL/AVIF की medium-low quality यानी 0.4bpp के बराबर size का है, इसलिए नीचे-बाएँ वाली तस्वीर की तुलना ऊपर-मध्य और दाएँ वाली तस्वीरों से करनी चाहिए
    • JPEG अब भी प्रति pixel लगभग दोगुने bits इस्तेमाल करता है, इसलिए resulting file size काफी बड़ा है
      गलत comparison के बहकावे में नहीं आना चाहिए; JXL और AVIF को भी file size दोगुना दे दें तो वे काफी बेहतर दिखेंगे
    • क्योंकि JPEG bitrate ज़्यादा है, इस test में इसका मतलब ज़्यादा यह है कि SSIMULACRA2 गलत metric है
      SSIMULACRA2 block artifacts को कड़ी penalty देता है, लेकिन blur की उतनी परवाह नहीं करता लगता है, और मैं सहमत हूँ कि समान SSIMULACRA2 score पर JPEG version बेहतर दिखता है
    • इस लेख से मेरा निष्कर्ष भी यही था कि JPEG eyelashes जैसी edge sharpness को सचमुच बहुत अच्छी तरह बनाए रखता है, जबकि JXL और AVIF image की सारी details को smooth करके मसल देते हैं

  • समझ नहीं आता कि यह लेख encoding speed पर इतना focus क्यों करता है, जबकि web connection environment में usage का 99% माने जाने वाले decoding को बस सरसरी तौर पर देखता है
    यह बस इतना कहकर आगे बढ़ जाता है कि “decoding speed आधुनिक computers पर बड़ा मुद्दा नहीं है, लेकिन numbers को जल्दी देखना दिलचस्प है”

    • अगर 100MB per second से ऊपर है, तो internet के लिए पर्याप्त माना जा सकता है
      उस point से bottleneck decoding नहीं रह जाता
      आधुनिक compression algorithms में से अधिकांश asymmetric हैं, इसलिए compression पर बहुत अधिक time खर्च करने से decompression performance पर बड़ा असर नहीं पड़ता; basic performance हासिल होने के बाद यह कम महत्वपूर्ण हो जाता है
    • उत्सुकता है कि AVIF/AV1 या HEIC/H264 जैसे video formats से निकले image formats को hardware video decoder से decode करना practical है या नहीं
      अगर संभव है, तो मौजूदा hardware पर पूरी तरह software decoding की जरूरत वाले JPEG XL की तुलना में इन्हें प्राथमिकता देने का यह मजबूत कारण हो सकता है
      H264 decoding हर जगह है, और AV1 decoding भी लगातार standard feature बनती जा रही है
    • कुछ use cases में company encoding cost देती है, और client decoding करता है
      client अगर page की कुछ images को इंसान को महसूस न हो इतनी तेजी से decode कर सके तो काफी है; इसके उलट encoding में कुछ प्रतिशत का भी improvement वास्तविक cost बचा सकता है
    • real-time encoding काफी common है, इसलिए encoding speed महत्वपूर्ण है
    • क्योंकि यही Cloudinary का use case है
      वे सचमुच image encoding पर लाखों dollars खर्च करते हैं

  • lossless benchmark में QOI को देखकर हँसी आई
    यह आम public software में default रूप से supported नहीं है, और बेहतरीन होने के बजाय बस ठीक-ठाक होने का लक्ष्य रखने वाला, व्यावहारिक रूप से अप्रासंगिक format है; फिर भी non-photo encoding chart में इसका एक स्थान लेना दिलचस्प है

    • GameMaker Studio काफी जल्दी QOI की धारा में शामिल हो गया, और 2 साल पहले PNG textures को QOI में बदलकर और उसके ऊपर BZ2 compression जोड़कर औसतन 20% size reduction हासिल किया
      इसलिए GameMaker Studio और पिछले करीब 2 साल में बने games सचमुच internally QOI इस्तेमाल करते हैं
      consumer जानबूझकर इसका उपयोग नहीं करता, लेकिन इसे पूरी तरह irrelevant कहना भी मुश्किल है
    • फिर भी यह Pareto frontier तक नहीं पहुँचा
      पीछे मुड़कर देखें तो यह स्वाभाविक है, क्योंकि QOI decoding मूलतः sequential है, इसलिए इसे आसानी से parallelize नहीं किया जा सकता

  • मुझे जिज्ञासा है कि JXL की उत्कृष्टता खुद फ़ॉर्मैट की वजह से है या encoder की वजह से
    सिर्फ -d 1.0 से high-quality और छोटी images बनाने की इसकी क्षमता अजीब हद तक अच्छी है, जबकि दूसरे codecs में समान नतीजे पाने के लिए image type के हिसाब से quality settings अलग-अलग देनी पड़ती थीं

    • बहुत अच्छा point है
      इस development speed के साथ libjxl image encoders की दुनिया का x264 बन जाए तो हैरानी नहीं होगी
      इसके उलट libvpx हमेशा एक साधारण encoder रहा है, और मुझे लगता है कि यही vp8/vp9 formats के निराशाजनक प्रदर्शन—सिर्फ speed नहीं, बल्कि overall performance—की वजह हो सकता है
      इसका असर अनिवार्य रूप से lossy WebP performance पर भी पड़ा, और Dark Shikari ने x264 और vp8 की still image performance की तुलना भी की थी [0]
      [0] https://web.archive.org/web/20150419071902/http://x264dev.mu...
    • Pik को शुरुआत में quality option के बिना distance 1.0 पर संभव best हासिल करने के लिए design किया गया था
      visual lossless पर काफी focus बनाए रखा गया, और हम ऐसे format features नहीं डालना चाहते थे जो high quality settings में मदद न करें और सिर्फ complexity बढ़ाएँ
      modeling features के अलावा context modeling और entropy coding efficiency high quality पर बहुत महत्वपूर्ण हैं
      मुझे लगता है AVIF की entropy coding high-quality या lossless photos के लिए ठीक से suited नहीं है
    • इसी -d 1.0 interface वाला JPEG encoder cjpegli भी बनाया गया था

  • यह भी उल्लेखनीय है कि JPEG XL के काम से Highway नाम की एक बेहतरीन नई parallelization library भी निकली
    यह library सिर्फ JPEG XL में ही नहीं, बल्कि Google के नए Gemma AI models में भी इस्तेमाल हो रही है

    • अगर Highway में रुचि है, तो [0] देख सकते हैं
      [1] में भी इसे cover किया गया है, और शुरुआत ऐसी है: “आज हम open source code साझा कर रहे हैं जो number arrays को C++ std::sort से करीब 10 गुना तेज़ sort करता है, और सभी modern CPU architectures पर portability बनाए रखते हुए भी सबसे नए architecture-specific algorithms से तेज़ है। नीचे हम चर्चा करते हैं कि हमने यह कैसे हासिल किया।”
      [0] https://github.com/google/highway
      [1] https://opensource.googleblog.com/2022/06/Vectorized%20and%2..., संबंधित paper है https://arxiv.org/pdf/2205.05982.pdf
    • और VIPS भी है
      C++ में portable SIMD पाने का यह सबसे अच्छा तरीका लगता है

  • JPEG XL खुद अपने दम पर कितना चमकता है, इससे अलग, सिर्फ यह कर पाना ही निश्चित रूप से शानदार है
    a.jpg 615504 bytes का है और SHA-1 716744d950ecf9e5757c565041143775a810e10f है
    cjxl a.jpg a.jxl चलाने पर यह 615504-byte JPEG को पढ़कर container सहित 537339 bytes में compress करता है
    लेकिन djxl a.jxl b.jpg चलाने पर यह 537339-byte compressed data पढ़कर JPEG में reconstruct करता है, और b.jpg भी 615504 bytes का है और SHA-1 पूरी तरह समान है
    यह देखते हुए कि दुनिया में ऐसे अरबों JPEG files हैं जिन्हें लोग preserve करना चाहते हैं, existing JPEG को lossy format में recompress करने से quality घट जाती है
    लेकिन JPEG XL 15~30% बचत करते हुए भी, चाहें तो original JPG को bit-by-bit 100% identical वापस ला सकता है
    सच में कमाल है
    दुर्भाग्य से मैं Debian stable 12 Bookworm इस्तेमाल कर रहा हूँ, जिसमें ImageMagick 6.9 है, और मुझे पता है कि Emacs शायद images दिखाने के लिए ImageMagick इस्तेमाल करता है
    JPEG XL support ImageMagick 7 में ही जोड़ा गया था, और मैंने अभी आगे ज्यादा नहीं खोदा है

    • उस requirement को JPEG XL में शामिल कराने में मैंने योगदान दिया था
      मुझे लगता है यह lossy re-encoding के बिना digital heritage को पूरी तरह preserve करने में मदद करेगा
    • JPEG का screenshot लेकर उसे WhatsApp पर वापस भेजने वाले users के लिए यह feature बेहद कीमती होगा :P

  • यह बहुत प्रभावशाली है कि libjxl के नए version ने lossy और lossless compression दोनों में memory usage को एक order of magnitude तक घटाया, और speed भी सुधारी
    खास तौर पर यह बात अच्छी लगी कि multi-threaded lossless encoding की default effort setting अब एक order of magnitude तेज़ हो गई है, और लेख भी अच्छी तरह लिखा गया था

  • मुझे जिज्ञासा है कि क्या कोई website है जो JPEG XL format के हर चरण को विस्तार से समझाती हो
    traditional JPEG के विपरीत, संबंधित steps को स्पष्ट रूप से guide करने वाला document ढूँढना मुश्किल रहा, और अफसोस है क्योंकि इस format में बहुत सारे रोचक innovations इकट्ठे हैं, यह साफ है
    अलग-अलग components भी अपने आप में उपयोगी लगते हैं

  • लेख में AV1, और इसलिए AVIF encode करने वाला rav1e छूट गया है
    rav1e reference implementation aom से काफी तेज़ है, और ऐसे cases रहे हैं जहाँ aom 1 मिनट इंतज़ार करने पर भी image conversion पूरा नहीं कर पाया, जबकि rav1e को 10 seconds भी नहीं लगे

    • मुझे जिज्ञासा है कि क्या rav1e का Pareto curve libaom के Pareto curve से आगे है
      यह भी जानना चाहता हूँ कि तेज़ rav1e high encoding speed पर jpegli से बेहतर दिखता है या नहीं
    • rav1e और libaom दोनों में speed settings हैं
      समान speed पर मैंने दोनों के बीच compression performance में बड़ा अंतर नहीं देखा