JPEG का गुप्त जीवन: 1992 का प्रारूप कैसे इंटरनेट पर छा गया

किसी भी .jpg फ़ाइल को हेक्स एडिटर में खोलें। पहले दो बाइट्स:

FF D8

यह Start of Image (SOI) मार्कर है। हर JPEG फ़ाइल इसी से शुरू होती है। आपके डिवाइस का JPEG डिकोडर सबसे पहले इसी को ढूंढता है। अगले बाइट्स डिकोडर को बताते हैं कि यह JPEG का कौन सा फ़्लेवर है, कौन सा कलर स्पेस एक्सपेक्ट करना है और पिक्सल डेटा कहाँ शुरू होता है। यह प्रारूप वेब ब्राउज़र से भी पुराना है, फिर भी 2025 Web Almanac के अनुसार आधुनिक वेब पर सर्व की गई लगभग 57% छवियों को कैरी करता है।

वह स्टोरेज संकट जिसने JPEG को जन्म दिया

1986 में, एक raw 640 × 480 ग्रेस्केल इमेज 307 KB डिस्क स्पेस खाती थी। उसी रिज़ॉल्यूशन पर एक कलर इमेज को 921 KB चाहिए होता था। उस समय 20 MB हार्ड ड्राइव सैकड़ों डॉलर में आती थीं और 1.44 MB फ्लॉपी डिस्क स्टैंडर्ड एक्सचेंज मीडियम थी, तो एक अनकंप्रेस्ड फोटो पूरे डिस्क का दो-तिहाई हिस्सा भर सकती थी।

ज़रूरत साफ़ थी: कंटीन्यूअस-टोन इमेज के लिए एक स्टैंडर्ड कंप्रेशन फॉर्मैट, फोटोग्राफ़्स के लिए, लाइन आर्ट नहीं। कई ग्रुप इस समस्या पर काम कर रहे थे। 1986 में ISO/IEC और ITU-T द्वारा गठित Joint Photographic Experts Group ने बेहतरीन आइडियाज़ को एक ही ड्राफ्ट में मर्ज किया। छह साल रिफाइनमेंट के बाद, 1992 में इसे ISO/IEC 10918-1 के रूप में पब्लिश किया गया।

JPEG कभी भी एकमात्र इमेज फॉर्मैट बनने का इरादा नहीं रखता था। इसे एक ही काम के लिए डिज़ाइन किया गया था: फोटोग्राफ़्स को इतना छोटा बनाना कि स्टोर और ट्रांसमिट किया जा सके। यह उस काम को एक बहुत ही स्पेसिफिक ऑर्डर में जानकारी फेंककर करता है।

JPEG इतना अच्छा क्यों कंप्रेस करता है

JPEG कंप्रेशन एक पाइपलाइन है, कोई सिंगल एल्गोरिदम नहीं। हर स्टेज वह डेटा हटाता है जिसे आंखें सबसे कम मिस करती हैं।

1. कलर स्पेस कन्वर्जन (RGB → YCbCr)

आपकी स्क्रीन RGB दिखाती है। JPEG YCbCr स्टोर करता है। Y चैनल ल्यूमिनेंस (brightness) ले जाता है। Cb और Cr क्रोमिनेंस (blue-difference और red-difference) ले जाते हैं। यह इसलिए मायने रखता है क्योंकि मानव आंख में लगभग 2.5 मिलियन कोन सेल्स ब्राइटनेस के लिए ट्यून हैं और केवल 100,000 कलर के लिए। हम ल्यूमिनेंस डिटेल को कलर डिटेल से बेहतर देखते हैं।

2. क्रोमा सबसैंपलिंग (Chroma subsampling)

ज़्यादातर JPEG 4:2:0 सबसैंपलिंग का इस्तेमाल करते हैं। हर 4 ल्यूमिनेंस सैंपल के लिए, 1 Cb सैंपल और 1 Cr सैंपल होता है। इसका मतलब है कि क्रोमा चैनल्स को ल्यूमा चैनल के चौथाई रिज़ॉल्यूशन पर स्टोर किया जाता है। 4000 × 3000 इमेज के लिए, Y प्लेन फुल रिज़ॉल्यूशन में है। Cb और Cr प्लेन 2000 × 1500 के हैं। असली कंप्रेशन शुरू होने से पहले ही आपने raw डेटा को लगभग 50% काट दिया, और ज़्यादातर लोग इसे नोटिस नहीं करते।

3. डिस्क्रीट कॉसाइन ट्रांसफॉर्म (DCT)

इमेज को 8 × 8 पिक्सल ब्लॉक्स में बांटा जाता है। हर ब्लॉक को DCT से गुजारा जाता है, जो स्पेशियल डेटा (पिक्सल वैल्यूज़) को फ़्रीक्वेंसी डेटा (ब्लॉक में वैल्यूज़ कितनी तेज़ी से बदलती हैं) में बदलता है। नतीजा 8 × 8 का कोएफिशिएंट मैट्रिक्स है। ऊपर-बाएँ की वैल्यू DC कोएफिशिएंट है (ब्लॉक की एवरेज ब्राइटनेस)। बाकी 63 AC कोएफिशिएंट्स हैं जो बढ़ती हुई हाई-फ़्रीक्वेंसी डिटेल को दर्शाते हैं।

हाई-फ़्रीक्वेंसी कोएफिशिएंट्स फाइन टेक्सचर को एन्कोड करते हैं: बाल, घास, शोर। लो-फ़्रीक्वेंसी कोएफिशिएंट्स ब्रॉड शेप्स को एन्कोड करते हैं: आसमान, दीवारें, स्किन टोन्स।

4. क्वांटाइजेशन (Quantization)

यहाँ पर loss होती है। JPEG हर DCT ब्लॉक पर एक क्वांटाइजेशन टेबल लगाता है। यह टेबल एक दूसरी 8 × 8 डिवाइज़र मैट्रिक्स है। हर DCT कोएफिशिएंट को अपने मैचिंग क्वांटाइज़र से डिवाइड किया जाता है और निकटतम पूर्णांक में राउंड किया जाता है।

स्टैंडर्ड क्वांटाइजेशन टेबल हाई-फ़्रीक्वेंसी कोएफिशिएंट्स को सबसे ज़ोर से मारती है:

16  11  10  16  24  40  51  61
12  12  14  19  26  58  60  55
14  13  16  24  40  57  69  56
14  17  22  29  51  87  80  62
18  22  37  56  68 109 103  77
24  35  55  64  81 104 113  92
49  64  78  87 103 121 120 101
72  92  95  98 112 100 103  99

मान लीजिए, एक हाई-फ़्रीक्वेंसी कोएफिशिएंट 7 है, उसे 121 से डिवाइड करके 0 में राउंड किया जाता है। वह गया। अनरिवर्सिबल। डिकोडर उसे कभी नहीं देखता। यही lossy compression है: डेटा नष्ट होता है, सिर्फ़ re-encode नहीं होता।

क्वालिटी 90 पर, क्वांटाइज़र्स को एक छोटे स्केलिंग फैक्टर से डिवाइड किया जाता है। क्वालिटी 50 पर, स्केलिंग फैक्टर ज़्यादा होता है। ज़्यादा कोएफिशिएंट्स ज़ीरो हो जाते हैं। फ़ाइल छोटी हो जाती है। इमेज सॉफ्टर हो जाती है।

5. एन्ट्रॉपी कोडिंग (Entropy coding)

क्वांटाइजेशन के बाद, बचे हुए कोएफिशिएंट्स को zig-zag स्कैन किया जाता है, run-length encoded किया जाता है, और Huffman coding से कंप्रेस किया जाता है। यह स्टेज lossless है। यह पहले से नष्ट हुए डेटा को बस और कुशलता से पैक करता है।

उदाहरण के लिए, 12 MP अनकंप्रेस्ड RGB इमेज 36 MB होती है। इसे JPEG क्वालिटी 90 में 4:2:0 सबसैंपलिंग के साथ सेव करें और यह ~3.5 MB हो जाती है। यह 10:1 रिडक्शन है, और magnification के बिना विज़िबल क्वालिटी लॉस नहीं होता।

यह असल में कितना lossy है?

नुकसान बराबर नहीं बंटा है।

क्वालिटी गिरने पर आम तौर पर ब्लॉकिंग, रिंगिंग और कलर ब्लीडिंग जैसे आर्टिफैक्ट्स दिखते हैं। ब्लॉकिंग में स्मूथ ग्रेडिएंट्स जैसे आसमान में 8 × 8 ग्रिड एज नज़र आते हैं। रिंगिंग हाई-कंट्रास्ट एजेज़ के आसपास ऑसिलेटिंग हेलोज़ बनाता है, जैसे टेक्स्ट के बगल बैकग्राउंड में। कलर ब्लीडिंग तब होती है जब क्रोमा सबसैंपलिंग रंग को शार्प बाउंड्रीज़ के पार फैला देती है।

असली खतरा जनरेशन लॉस (generation loss) है। JPEG खोलें, एडिट करें, फिर से JPEG में सेव करें। हर सेव पूरा पाइपलाइन दोबारा चलाता है: RGB → YCbCr → सबसैंपल → DCT → क्वांटाइज़। राउंडिंग एरर्स बढ़ते हैं। 10 जनरेशन के बाद, इमेज ऐसी लगती है जैसे वॉटरकलर में बनी हो। 50 के बाद, वह पहचान में नहीं आती।

ग्रीन शिफ्ट और अन्य री-कंप्रेशन क्विर्क्स

JPEG को बार-बार फिर से सेव करें और आपको कलर टेम्परेचर में ड्रिफ्ट नोटिस हो सकती है। कुछ इमेज में हल्की हरी झलक आ जाती है, तो कुछ मैजेंटा की ओर जाती हैं। वजह क्रोमा चैनल्स में दबी है।

JPEG Cb और Cr को कम रिज़ॉल्यूशन पर स्टोर करता है और उन्हें आक्रामक रूप से क्वांटाइज़ करता है। हर सेव दोनों चैनल्स में राउंडिंग एरर लाती है। RGB में वापस कन्वर्जन यह मैट्रिक्स इस्तेमाल करता है:

R = Y + 1.402 × (Cr - 128)
G = Y - 0.344136 × (Cb - 128) - 0.714136 × (Cr - 128)
B = Y + 1.772 × (Cb - 128)

ध्यान दें कि ग्रीन Cb और Cr दोनों से कैलकुलेट होता है। जब दोहराया हुआ क्वांटाइजेशन Cb को ऊपर और Cr को नीचे धकेलता है, भले ही सिर्फ़ एक क्वांटाइजेशन स्टेप से, G चैनल ड्रिफ्ट कर जाता है। Cb में पॉज़िटिव बायस ग्रीन को नीचे धकेलता है। Cr में नेगेटिव बायस ग्रीन को ऊपर धकेलता है। इंटरैक्शन सममित (symmetric) नहीं है क्योंकि -0.344136 और -0.714136 कोएफिशिएंट्स की मैग्नीट्यूड अलग-अलग है। नतीजा यह है कि कुछ इमेज रीजन में धीरे-धीरे हरा बढ़ता है, खासकर जहाँ ओरिजिनल क्रोमा वैल्यूज़ पहले से ही क्वांटाइजेशन बाउंड्रीज़ के पास थीं।

यह हर बार नहीं होता। यह एन्कोडर की क्वांटाइजेशन टेबल्स, सबसैंपलिंग मोड और इमेज कंटेंट पर निर्भर करता है। लेकिन इसे दोहराया जा सकता है, और यही एक कारण है कि प्रोफेशनल वर्कफ्लोज़ JPEG को दोबारा सेव करने से बचते हैं।

अगर JPEG इतना flawed है, तो हर जगह इसे क्यों इस्तेमाल करते हैं?

JPEG पॉपुलर नहीं है क्योंकि यह परफ़ेक्ट है। यह पॉपुलर है क्योंकि यह काफी अच्छा है और लगभग हर जगह चलता है।

बेसलाइन JPEG पेटेंट, जो कभी Forgent Networks के पास थे, 2006 में एक्सपायर हो गए, इसलिए यह रॉयल्टी-फ्री है। हर कैमरा, फोन, प्रिंटर और ब्राउज़र में पहले से JPEG डिकोडर है, इसलिए रेंडर करना बहुत सस्ता पड़ता है। सोशल मीडिया, न्यूज़ साइट्स और ईमेल अटैचमेंट के लिए क्वालिटी 75 JPEG फोन स्क्रीन पर सोर्स से अलग नहीं लगता। सबसे बड़ी बात यह है कि CMS, CDN, इमेज लाइब्रेरीज़ और पुराने आर्काइव्स JPEG के इर्द-गिर्द बने हैं, और इन्हें बदलने के लिए एक बेहतर फॉर्मैट के साथ-साथ पेटाबाइट्स मौजूदा एसेट्स को माइग्रेट करने का एक मज़बूत कारण भी चाहिए।

वे फॉर्मैट जिन्हें जीतना चाहिए था

कई फॉर्मैट्स ने JPEG को हटाने की कोशिश की। कोई पूरी तरह सफल नहीं हुआ।

PNG ने lossless प्रॉब्लम हल किया लेकिन फोटो के लिए JPEG से 5–10 गुना बड़ी फ़ाइलें देता है। यह स्क्रीनशॉट, UI एसेट्स और ग्राफ़िक्स पर राज करता है।

WebP (Google, 2010) साइज़ में JPEG से बेहतर है और ट्रांसपैरेंसी और एनिमेशन जोड़ता है। यह अब हर मेजर ब्राउज़र में आता है। 2025 Web Almanac WebP को LCP इमेज का 11% बताता है, 2024 के 7% से बढ़कर। यह आज का सेफ़ अपग्रेड पाथ है।

HEIC (Apple, 2017) ISOBMFF कंटेनर के अंदर HEVC कंप्रेशन इस्तेमाल करता है। यह JPEG से ~40–50% छोटा है और एक फ़ाइल में कई इमेज रख सकता है। यह Apple इकोसिस्टम पर हावी है और HEVC पेटेंट पूल्स की वजह से बाकी हर जगह रुका हुआ है।

AVIF (AOM, 2019) AV1 वीडियो से निकला है। यह किसी भी वाइडली सपोर्टेड फॉर्मैट में सबसे अच्छे कंप्रेशन रेशियो देता है। इक्विवेलेंट क्वालिटी पर यह WebP से लगभग 30% छोटा है। नुकसान डिकोड स्पीड है। मोबाइल डिवाइस पर AVIF इमेज JPEG से 2–3 गुना ज़्यादा समय लेती हैं रेंडर होने में, बैटरी खाती हैं और Largest Contentful Paint में देरी करती हैं।

JPEG XL (ISO/IEC 18181, 2021) तकनीकी रूप से सबसे ऊपर है। यह JPEG से 50–60% छोटा कंप्रेस करता है। तेज़ डिकोड करता है। प्रोग्रेसिव डिकोडिंग सपोर्ट करता है: ~1% फ़ाइल डाउनलोड करने के बाद ही यूज़ेबल इमेज दिखती है। सबसे ज़रूरी, यह मौजूदा JPEGs को lossless रीकंप्रेस कर सकता है ~20% साइज़ बचत के साथ, ओरिजिनल की bit-for-bit रिकवरी। कोई दूसरा फॉर्मैट यह नहीं कर सकता।

अभी हम कहाँ हैं

JPEG XL का बचपन मुश्किल रहा। Google ने 2021 में Chrome में एक्सपीरिमेंटल सपोर्ट जोड़ा, फिर 31 अक्टूबर 2022 को हटा दिया ("हैलोवीन डिसिजन")। कहा गया कारण: मौजूदा फॉर्मैट्स पर इनेफिशिएंट इंक्रीमेंटल बेनेफ़िट। प्रतिक्रिया तुरंत आई। Chromium issue प्रोजेक्ट के इतिहास में दूसरा सबसे ज़्यादा स्टार्ड बन गया। Google पर AVIF की रक्षा करने का आरोप लगा, जो Alliance for Open Media से जुड़ा फॉर्मैट है जिसे Google ने सह-स्थापित किया था।

2025 के अंत में, Chromium ने रुख बदला। एक नया Rust डिकोडर (jxl-rs) Chrome Canary में आया। Chrome 145, फरवरी 2026 में रिलीज़ हुआ, ने JPEG XL सपोर्ट एक फ्लैग के पीछे शिप किया। Safari 2023 से सपोर्ट करता है। Firefox Nightly वही Rust डिकोडर इंटिग्रेट कर रहा है। JPEG XL अभी डिफ़ॉल्ट पर एनेबल्ड नहीं है, लेकिन यह कोडबेस में वापस है।

AVIF, इस बीच, 2026 का प्रैग्मैटिक चॉइस है। ब्राउज़र सपोर्ट वाइड है। एन्कोडर्स बेहतर हो रहे हैं। Cloudinary और Cloudflare दोनों Accept हेडर निगोसिएशन के ज़रिए AVIF ऑटोमैटिकली सर्व करते हैं। AVIF या WebP सर्व करने वाली मीडियन पेज 81% गुड LCP रेट्स दिखाती है, JPEG-ओनली पेज के 64% के मुकाबले, CoreDash डेटा के अनुसार।

आगे क्या करें

JPEG 33 साल का समझौता है। यह कलर रिज़ॉल्यूशन, हाई-फ़्रीक्वेंसी टेक्सचर और न्यूमेरिकल प्रिसिजन फेंकता है, बदले में वे फ़ाइल साइज़ जिन्होंने 1990s में डिजिटल फोटोग्राफ़ी को जीवित रखा। आर्टिफैक्ट्स अच्छी तरह समझे जाते हैं। जनरेशन लॉस रियल है। ग्रीन ड्रिफ्ट होता है।

फिर भी JPEG इसी कारण टिका है जिस कारण QWERTY टिका है: स्विचिंग कॉस्ट रुकने की पीड़ा से ज़्यादा है।

इसका मतलब यह नहीं कि JPEG के साथ कुछ न करें। ओरिजिनल्स को PNG, TIFF या क्वालिटी 95+ JPEG के रूप में आर्काइव करें, और कभी क्वालिटी 75 वेब एक्सपोर्ट से री-एडिट न करें। एक CDN या इमेज सर्विस का इस्तेमाल करें जो ब्राउज़र के Accept हेडर के आधार पर AVIF, WebP या JPEG XL निगोसिएट करे; एक मास्टर स्टोर करें और एज को डिमांड पर कन्वर्ट करने दें। JPEGs को बैच में री-एनकोड न करें, क्योंकि हर जनरेशन डेटा नष्ट करती है। अगर छोटी फ़ाइलें चाहिए, मास्टर से री-एनकोड करें, किसी दूसरे JPEG से नहीं।

JPEG अचानक गायब नहीं होगा। यह GIF की तरह फीका पड़ेगा: हर जगह सपोर्टेड, हर व्यूअर में खुलता, लेकिन लगातार उन फॉर्मैट्स से पछाड़ा जा रहा है जो कम बाइट्स और कम आर्टिफैक्ट्स में वही काम करते हैं। AVIF और JPEG XL अब उस मुकाम पर हैं जहाँ वे केवल प्रयोगशाला के आंकड़े नहीं, बल्कि असल ब्राउज़र और CDN में दिख रहे हैं।