रिग्रेसिव (Regressive) JPEG

 (maurycyz.com)
1 पॉइंट द्वारा GN⁺ 21 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Progressive JPEG की मल्टी-स्कैन संरचना को बदलकर, डाउनलोड आगे बढ़ने पर इमेज क्वालिटी बेहतर होने के बजाय पहले से दिख रही इमेज को लगातार किसी दूसरी इमेज में बदला जा सकता है
  • हर scan color channel, DCT frequency range और precision तय करता है, और समान resolution वाले JPEG से कुछ markers हटाकर उन्हें जोड़ने पर मौजूदा rendering data को overwrite किया जा सकता है
  • Decoder compression bomb जैसी समस्याओं से बचने के लिए process किए जाने वाले scans की संख्या सीमित करते हैं; Chrome लगभग 90 frames तक render करता है और Firefox आदि उससे अधिक process करते हैं
  • अगर हर frame में केवल एक DC-only scan इस्तेमाल किया जाए, तो frames की संख्या बढ़ाते हुए ghosting से बचा जा सकता है, लेकिन DCT block की प्रकृति के कारण परिणामी resolution मूल का 1/16 रह जाता है
  • एक ही JPEG में video की तरह कई frames रखे जा सकते हैं, लेकिन timing information न होने से playback speed network delay पर निर्भर रहती है; यह व्यावहारिक video की तुलना में partial rendering का उपयोग करने वाले HTML और single-page app experiments के लिए अधिक उपयुक्त है

Progressive JPEG इमेज कैसे दिखाता है

  • JPEG पहले low-frequency components store करता है, ताकि file का केवल कुछ हिस्सा डाउनलोड होने पर भी कटी हुई इमेज की जगह low-resolution preview दिखाया जा सके
  • Compressed data कई scans में बंटा होता है और हर scan से पहले header होता है
    • FF DA scan start marker है
    • इसके बाद length field, शामिल channels की संख्या और ID, तथा Huffman table index आते हैं
    • start/end DCT bins और precision तय करने के बाद Huffman-encoded DCT coefficients store किए जाते हैं
  • पहले scan में तीनों color channels के सबसे कम DC frequency bin शामिल होते हैं

YCbCr और चरणबद्ध quality improvement

  • JPEG के तीन color channels आम RGB के बजाय YCbCr का उपयोग करते हैं
    • Y luminance है, इसलिए high quality चाहिए
    • Cb, Cr chroma components हैं, इसलिए quality कम करने पर visual impact ज्यादा नहीं होता
    • बहुत मोटे तौर पर कहें तो Y = G, Cb = B - G, Cr = R - G है
  • example JPEG scan 0 से 9 तक data को चरणबद्ध रूप से भरता है
    • scan 0: Y Cb Cr, DCT bin 0–0 को half precision में store कर बहुत low-resolution preview देता है
    • scan 1: Y, bins 1–5 को 1/4 precision में जोड़कर luminance details मजबूत करता है
    • scan 2·3: Cb, Cr के bins 1–63 को half precision में जोड़ते हैं
    • scan 4: Y के bins 6–63 को 1/4 precision में भरकर scan 1 से छोड़ी गई range पूरी करता है
    • scan 5: Y के bins 1–63 को half precision में सुधारता है
    • scan 6–9: हर channel में अंतिम bit जोड़कर full quality बनाते हैं
  • Chroma data luminance से पहले पूरा हो जाता है, लेकिन chroma half resolution, यानी 1/4 pixel count में store होता है, इसलिए Cr + Cb की कुल capacity भी luminance की केवल आधी होती है

डाउनलोड के दौरान इमेज बदलना

  • क्योंकि हर scan लागू होने वाली frequency range स्पष्ट करता है, बाद के scans से पहले से rendered image data को overwrite करने वाला JPEG बनाया जा सकता है
  • समान resolution वाली कई images को जोड़ते हुए अगले markers को filter out करने के तरीके से इसे implement किया जाता है
    • image start (start-of-image)
    • frame start (start-of-frame)
    • image end (end-of-image)
  • Hex editor से भी बनाया जा सकता है, लेकिन वास्तविक generation के लिए एक सरल C program इस्तेमाल किया जाता है
  • file को slow network पर भेजने पर, download आगे बढ़ने के दौरान कई images बारी-बारी से switch होती हैं

Decoder की scan limit

  • अधिकांश JPEG decoders एक निश्चित संख्या के scans process करने के बाद रुक जाते हैं
  • माना जाता है कि यह compression bomb जैसी समस्याओं से बचने की limit है, और simple concatenation method से 9 frames से अधिक implement करना मुश्किल है
  • लंबा animation बनाने के लिए हर frame के लिए आवश्यक scans की संख्या न्यूनतम करनी होगी

Baseline JPEG इस्तेमाल न कर पाने का कारण

  • केवल एक scan इस्तेमाल करने वाले Baseline JPEG से शुरू करने का तरीका काम नहीं करता
  • Progressive mode में एक ही scan में DC data यानी bin 0 और AC data यानी bin 1 या उससे ऊपर को साथ नहीं रखा जा सकता
  • Baseline mode में यह restriction नहीं है, लेकिन Baseline decoder पहले scan के बाद processing रोक देता है
  • AC data को DC data के बाद आना होता है, इसलिए सबसे छोटा progressive JPEG frame केवल DC-only scan से बना होता है

DC-only frame की संरचना और resolution

  • DCT 16×16 blocks के स्तर पर process होता है, इसलिए केवल DC data शामिल होने पर भी यह single-color नहीं, बल्कि मूल की 1/16 resolution वाली image बना सकता है
  • न्यूनतम frame केवल एक scan इस्तेमाल करता है, जो Y Cb Cr तीनों channels के DCT bins 0–0 को full precision में store करता है
  • इस configuration में Chrome processing रोकने से पहले लगभग 90 frames render करता है
    • Firefox जैसे दूसरे browsers अधिक scans process करते हैं
    • 90 scans से बनी image लगभग सभी browsers में काम करती है

Ghosting के बिना frame transition

  • simple concatenation method में ghosting इसलिए होती है क्योंकि AC scans को मौजूदा data को refine करने के लिए design किया गया है
  • सामान्य progressive JPEG में file size बहुत बढ़ाए बिना कई precision steps रखे जा सकते हैं, लेकिन images को replace करने के तरीके के लिए यह उपयुक्त नहीं है
  • वास्तविक progressive improvement के बिना केवल DC-only scans इस्तेमाल करने पर पिछले AC data की refinement नहीं होती, इसलिए ghosting से बचा जा सकता है
  • DC-only frame standard-compliant JPEG image है, इसलिए special encoder की जरूरत नहीं होती
    • scan specification में 0,1,2:0-0,0,0; की तरह तीनों channels के केवल DC bins specify किए जाते हैं

single JPEG video की सीमाएं

  • DC-only frames को जोड़ने पर एक JPEG file में पूरा video रखा जा सकता है
  • JPEG scans में frame timing जोड़ने का कोई तरीका नहीं है, इसलिए playback speed पूरी तरह network delay पर निर्भर रहती है
  • गैर-पारंपरिक Rickroll या prank के अलावा इसका कोई practical use case नहीं है

partial rendering को बढ़ाने वाले experiments

  • partial rendering का उपयोग करके JPEG frame replacement के अलावा भी experiments किए जा सकते हैं
  • <dialog> tagだけ इस्तेमाल किए गए pure HTML video से Bad Apple video implement किया गया
  • data को file में hardcode किए बिना, CSS या JavaScript के बिना interactive single-page application भी implement किया गया
  • image generation के लिए merge.c C code इस्तेमाल किया गया

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

1 टिप्पणियां

 
GN⁺ 21 시간 전
Hacker News की राय

  • Adam7 इंटरलेस PNG के साथ बहुत मिलता-जुलता काम किया था: https://www.da.vidbuchanan.co.uk/adamation/image.png
    प्लेबैक आखिरकार नेटवर्क latency पर निर्भर करता है, लेकिन मैंने सर्वर को इस तरह सेट किया था कि वह हर फ्रेम को तय अंतराल पर अलग-अलग भेजे। फ्रेम छोटे हैं, इसलिए अगर नेटवर्क असामान्य रूप से धीमा न हो तो सर्वर ही तय करता है कि प्लेबैक कब होगा

    • अगर आप HTTP सर्वर को नियंत्रित कर सकते हैं, तो response header में Refresh सेट करके क्लाइंट से समय-समय पर नया animation frame मंगवा सकते हैं[1]। 2013 के IOCCC entry में भी इसी तकनीक से PNG में render की गई घड़ी लगातार अपडेट होती रहती है[2]
      [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/...
      [2] https://www.ioccc.org/2013/mills/index.html
      अगली पंक्ति में Refresh header उल्टा encode किया गया है: https://github.com/ioccc-src/winner/blob/619f554bbdb19e5003a...
    • infinite GIF के साथ live video stream करने जैसा मिलता-जुलता काम भी किया था: https://github.com/jbochi/gifstreaming#live-video-streaming-...
    • जब लोग PNG को animation बनाने के लिए जुगाड़ कर रहे हैं, APNG बगल से जैसे चिल्ला रहा हो, “मैं भी मौजूद हूँ!”
    • 20 साल पहले की नौकरी में map application में real-time air quality layer जोड़ने के लिए मैंने animated GIF के साथ यही काम किया था। इमेजें Java2D से render की थीं, और point cloud की जगह gradient blobs बनाने के लिए JOGL version भी बना रहा था, लेकिन server admin ने OpenGL driver install करने की अनुमति नहीं दी, इसलिए उसे पूरा नहीं कर पाया

  • यह cursed technique है, लेकिन यहीं पर फिट बैठती है

    • बड़े tech companies शायद सोच रही होंगी कि इसे browser fingerprinting में कैसे इस्तेमाल किया जाए

  • सोच रहा हूँ कि क्या इस तकनीक से डेटा को सामने छिपाने वाली steganography संभव है। ज़्यादातर automated image analysis programs शायद सिर्फ आखिरी image को जांचें, इसलिए छात्र इसका इस्तेमाल स्कूल के content filter को bypass करने में कर सकते हैं

    • इसे AI disruption technique की तरह इस्तेमाल किया जा सकता है: इंसानों के लिए message पहले frame में, और AI के लिए message आखिरी frame में। यानी एक-दूसरे को बिल्ली की तस्वीरें भेजकर Skynet को हराना
    • यह सामान्य steganography से बेहतर तरीका नहीं लगता

  • शायद इसे उसी network पर parallel में load होने वाली चीज़ों के progress bar की तरह इस्तेमाल किया जा सकता है, ताकि user अंदाज़ा लगा सके कि कितनी latency बाकी है

    • याद पड़ता है कि 4chan जैसी जगहों पर इसका दुरुपयोग घिनौनी या अवैध images छिपाने में हुआ था, इसलिए इस तरह का व्यवहार पूरी तरह block कर दिया गया

  • अगर web server चलते-चलते “JPEG” बनाकर उसे समय-अंतराल वाले टुकड़ों में client को भेजे, तो प्लेबैक timing को कुछ हद तक नियंत्रित किया जा सकता है। अगर source webcam हो, तो एक अंतहीन “JPEG” भी संभव है

    • कुछ webcams पहले से ही multipart/x-mixed-replace नाम की MIME तकनीक से यह करती हैं। इसमें server क्लाइंट को बताता है कि अभी भेजे गए data को नए data से replace कर दो, और यह JavaScript के बिना सिर्फ सामान्य HTTP और JPEG से काम करता है
    • कई IP cameras पहले से https://en.wikipedia.org/wiki/Motion_JPEG के जरिए यही करती हैं
    • GIF से भी यह किया जा सकता है। मैंने एक बार ऐसा मज़ाकिया CGI बनाया था जो GIF को frame-by-frame भेजता था और image map से clicks संभालता था, ताकि JavaScript के बिना remote desktop जैसा इस्तेमाल हो सके। JPEG शायद बेहतर होता, इसलिए इसे फिर आज़माना चाहिए

  • Service Worker से slow connection का नाटक करके प्लेबैक speed नियंत्रित की जा सकती है

  • अलग-अलग environments में इसका अलग व्यवहार अजीब है। desktop Firefox में यह सही चलता है, लेकिन iOS mobile पर “JPEG के अंदर पूरा वीडियो” लगभग एकरंगी भूरे→नारंगी→लाल 3 फ्रेम और धुंधली बिल्ली की बस रूपरेखा जैसा दिखता है
    रंग हर फ्रेम में बदलते हैं, इसलिए पता चलता है कि यह काम कर रहा है, लेकिन इसे वीडियो कहना मुश्किल है। desktop पर यह सच में वीडियो जैसा चलता है, जो चौंकाने वाला था, और लगता है कि यह iOS image decoder की कोई अजीब boundary condition छू रहा है

  • हाल ही में OpenGL और jpeg-turbo के साथ images को तेज़ी से दिखाने पर काम किया, और JPEG का progressive mode चालू करने पर decoding काफ़ी धीमी हो गई। progressive JPEG अच्छा होता है वाली पुरानी सलाह अब शायद वैध नहीं रही
    दशकों से images को चरणबद्ध तरीके से साफ़ होते हुए लगभग देखा ही नहीं, इसलिए इसकी व्यावहारिक value भी कम लगती है

    • हो सकता है आपने page load होते ही image को थोड़ा धुंधला और फिर अगले चरण में साफ़ होते देखा हो। पहले की तरह शुरुआती चरण पहचान से बाहर नहीं होता, लेकिन कुल file size के लगभग 30% में low-resolution preview लगभग मुफ्त मिल जाना अभी भी उपयोगी है
    • encoder के रूप में cjpegli इस्तेमाल करता हूँ, और default progressive तथा full 4:4:4 के साथ compression सबसे अच्छा मिलता है, इसलिए यह सिर्फ एक अतिरिक्त feature नहीं है
    • progressive में save की गई JPEG photos आमतौर पर लगभग 5% छोटी होती हैं, और JPEG को progressive format में lossless convert करना भी संभव है। JPEG XL में lossless convert करने पर और जगह बच सकती है
    • progressive decoding का मकसद decoding को तेज़ करना नहीं, बल्कि खासकर धीमे mobile connections पर बड़ी images को जल्दी दिखाना है
      उदाहरण: https://youtube.com/watch?v=UphN1_7nP8U

  • पहले तो मैंने यह सोचा कि पहली image के “गलत” coefficients से high-frequency coefficients को मुश्किल तरीके से निकाला जाए, लेकिन दो images को बस जोड़ देने वाला तरीका काफ़ी चतुर है। एक image के low-frequency components के बाद दूसरी image के high-frequency components जोड़ देने भर से यह हैरान करने वाली हद तक अच्छा काम करता है

  • सोच रहा हूँ कि क्या camera से भी low-frequency components सीधे लिए जा सकते हैं। MRI का तरीका भी याद आता है, जहाँ k-space में low frequency पहले ली जाती है