लॉसी बनाम लॉसलेस: इमेज फॉर्मैट जानबूझकर क्यों भूलते हैं

एक ही 12 MP फोटो (4000 × 3000 पिक्सल) को दो बार सेव कीजिए। एक बार PNG के रूप में: 24 MB। एक बार JPEG क्वालिटी 90 पर: 3.4 MB। दोनों को स्क्रीन पर साथ-साथ रखिए, फ़र्क नहीं बता पाएंगे। 400% तक ज़ूम कीजिए, तब जाकर अंतर दिखता है: बालों और घास में हल्की सॉफ्टनिंग, सबसे शार्प एजेज़ के किनारे बारीक हेलोज़।

दो फ़ाइलें, एक इमेज, साइज़ में 7× का फ़ासला। दोनों फ़ाइलें बिल्कुल सही हैं। फ़र्क बस शर्तों का है। PNG की शर्त: हर बिट बचा रहेगा। JPEG की शर्त: वह सब बचा रहेगा जो आप नोटिस करेंगे। इमेज फॉर्मैट्स की लगभग हर बात इसी से निकलती है कि कोई फॉर्मैट इन दोनों शर्तों में से कौन सी मानता है।

संपीड़न दो खेमों में क्यों बंटा

1948 में Claude Shannon ने "A Mathematical Theory of Communication" पब्लिश किया और संपीड़न के सामने एक सख़्त निचली सीमा खींच दी। उनके सोर्स कोडिंग थियोरम के मुताबिक़ आप डेटा को उसकी एन्ट्रॉपी, यानी प्रति सिंबल औसत जानकारी, से नीचे लॉसलेस तरीके से नहीं दिखा सकते। पूरी तरह रैंडम इमेज कंप्रेस ही नहीं होती। एकदम सफ़ेद इमेज लगभग कुछ ही बाइट्स में सिमट जाती है। हर असली इमेज इसी पैमाने पर कहीं बैठती है, और कोई भी लॉसलेस एल्गोरिदम इस पैमाने को पार नहीं कर सकता।

लॉसी संपीड़न एक चोर-रास्ते की वजह से मौजूद है। एन्ट्रॉपी की सीमा उस डेटा पर लगती है जो आपके पास है, उस पर नहीं जो आप रखते हैं। पहले इमेज को ऐसी हल्की-सी अलग इमेज से बदल दीजिए जिसकी एन्ट्रॉपी कम हो, तो सीमा भी उसके साथ नीचे उतर जाती है। पूरा खेल बस इतना है: पहले डेटा बदलो, फिर पैक करो। इंजीनियरिंग का सवाल यह है कि किस हद तक का बदलाव चलेगा।

जवाब दो चीज़ों पर निर्भर करता है। पहली, कंटेंट। किसी सेटिंग्स पैनल का स्क्रीनशॉट ज़्यादातर फ़्लैट कलर और दोहराते शेप्स का होता है: कम एन्ट्रॉपी, अनुमान लगाना आसान। जंगल की फोटो पिक्सल लेवल पर फोटॉन शॉट नॉइज़ और सेंसर रीड नॉइज़ है: ज़्यादा एन्ट्रॉपी, अनुमान मुश्किल। दूसरी, उपभोक्ता। फ़ाइल पढ़ने वाले प्रोग्राम को सटीक बिट्स चाहिए। फ़ाइल देखने वाले इंसान की नज़र में ग़लती सहने की क्षमता पहले से होती है: रंग की बारीकियाँ पकड़ने में सीमित नज़र, बारीक हाई-फ़्रीक्वेंसी टेक्सचर के प्रति कम संवेदनशीलता, और ब्राइटनेस की ऐसी परसेप्शन जो निरपेक्ष वैल्यू नहीं, अनुपात देखती है (Weber का नियम, लगभग 1 से 2% ल्यूमिनेंस स्टेप्स)।

इसी वजह से फॉर्मैट बंट गए। कंटेंट का अनुमान लगाया जा सके और देखने वाला मशीन हो या पिक्सल खंगालने वाला इंसान, तो लॉसलेस चुनिए। कंटेंट शोर से भरा हो और देखने वाला हाथ की दूरी पर बैठा इंसान हो, तो आपके पास भूल जाने की गुंजाइश है।

लॉसी संपीड़न कैसे काम करता है

लॉसी कोडेक्स के बारे में अक्सर कहा जाता है कि वे "डेटा फेंक देते हैं"। सही तो है, लेकिन पूरी बात नहीं। वे चुन-चुनकर खास डेटा फेंकते हैं, और चुनाव मानव दृष्टि के एक मॉडल से होता है। पाइपलाइन यह है:

1. RGB को ल्यूमा-क्रोमा कलर स्पेस में बदलें (JPEG में YCbCr, बाकी जगह मिलते-जुलते बंटवारे)। आपकी आंख ब्राइटनेस की डिटेल कलर की डिटेल से कहीं बेहतर पकड़ती है, इसलिए क्रोमा चैनल्स को चौथाई रिज़ॉल्यूशन पर रखा जा सकता है (4:2:0 सबसैंपलिंग)। अकेला यह स्टेप raw डेटा को लगभग 50% काट देता है, और ज़्यादातर फोटो में दिखता भी नहीं।

2. हर ब्लॉक को फ़्रीक्वेंसी में बदलें। JPEG 8 × 8 ब्लॉक्स पर डिस्क्रीट कॉसाइन ट्रांसफॉर्म चलाता है। JPEG 2000 वेवलेट्स चलाता है। AV1 और HEVC बड़े, वैरिएबल साइज़ के ट्रांसफॉर्म चलाते हैं। नतीजे का पैटर्न हमेशा एक जैसा निकलता है: कुछ बड़े कोएफिशिएंट्स जो ब्रॉड शेप्स बताते हैं, और ढेर सारे छोटे कोएफिशिएंट्स जो बारीक टेक्सचर बताते हैं।

3. क्वांटाइज़ करें। हर कोएफिशिएंट को एक स्टेप साइज़ से डिवाइड करके पूर्णांक में राउंड करें। छोटे कोएफिशिएंट्स ज़ीरो बन जाते हैं। पूरी पाइपलाइन में लॉसी स्टेप बस यही एक है, और आपके एन्कोडर की क्वालिटी सेटिंग इन्हीं स्टेप साइज़ेज़ पर लगने वाला एक मल्टीप्लायर है। क्वालिटी 95 छोटे स्टेप्स रखती है और लगभग सब कुछ बचा लेती है। क्वालिटी 30 बड़े स्टेप्स रखती है और ज़्यादातर बारीक टेक्सचर को ज़ीरो कर देती है।

4. जो बचा, उसे एन्ट्रॉपी-कोड करें। Zig-zag स्कैन, run-length एन्कोडिंग, Huffman या arithmetic कोडिंग। यह स्टेज लॉसलेस है। यह बस पहले से क्वांटाइज़ किए हुए नंबरों को पैक करता है।

वह लिस्ट एक बार फिर पढ़िए। स्टेप 1, 2 और 4 तो बस रिवर्सिबल हिसाब-किताब है। स्टेप 3 वह जगह है जहाँ इमेज असल में बिगाड़ी जाती है, जानबूझकर, एक-एक राउंडिंग एरर से।

इस तबाही की अपनी पहचान है। क्वालिटी बहुत नीचे धकेल दीजिए और आपको मिलेगी ब्लॉकिंग (आसमान और दीवारों में दिखने लगते 8 × 8 ग्रिड एजेज़), रिंगिंग (टेक्स्ट और हाई-कंट्रास्ट एजेज़ के गिर्द हेलोज़) और बैंडिंग (स्मूथ ग्रेडिएंट का सीढ़ियों में टूट जाना)। लॉसी फ़ाइल को फिर से सेव कीजिए और पाइपलाइन पहले से क्षतिग्रस्त डेटा पर दोबारा चलती है, इसीलिए जनरेशन लॉस जुड़ती जाती है: JPEG का दसवां री-सेव पहले वाले का वॉटरकलर लगता है।

लॉसलेस संपीड़न कैसे काम करता है

लॉसलेस कोडेक्स ऐसी कोई छूट नहीं लेते। डिकोड हुई फ़ाइल को ओरिजिनल से बिट-बाय-बिट मिलना ही है, इसलिए वे बस मॉडल बना सकते हैं और पैक कर सकते हैं। स्टैंडर्ड रेसिपी के दो स्टेज हैं।

पहला स्टेज: डिकोरिलेशन (decorrelation)। PNG कंप्रेस करने से पहले हर स्कैनलाइन को फ़िल्टर करता है। हर पंक्ति के लिए एन्कोडर पाँच प्रिडिक्टर्स (None, Sub, Up, Average, Paeth) में से एक चुनता है और असली पिक्सल और अनुमान के बीच का अंतर स्टोर करता है। एकदम सफ़ेद पंक्ति एक सफ़ेद पिक्सल और उसके पीछे हज़ारों ज़ीरो बन जाती है। स्मूथ ग्रेडिएंट छोटे, धीरे-धीरे बदलते रेसिड्यूअल बन जाता है। दोनों हालात में नंबर छोटे होकर ज़ीरो के आसपास जमा हो जाते हैं, और अगले स्टेज को ठीक यही चाहिए।

दूसरा स्टेज: एन्ट्रॉपी कोडिंग। PNG DEFLATE इस्तेमाल करता है, वही एल्गोरिदम जो gzip और zip के पीछे है, 1970s के दो आइडियाज़ से बना। LZ77 दोहराई गई बाइट सीक्वेंसेज़ खोजता है और हर दोहराव को पिछले 32 KB डेटा की ओर इशारा करते एक (distance, length) पॉइंटर से बदल देता है। फिर Huffman कोडिंग बार-बार आने वाली वैल्यूज़ को छोटे बिट कोड देती है और कम आने वाली वैल्यूज़ को लंबे। कोई स्टेप कुछ नहीं खोता। पैक किए गए स्ट्रीम से ओरिजिनल बाइट्स हमेशा पूरे-के-पूरे वापस मिल जाते हैं।

यही वजह है कि PNG स्क्रीनशॉट पर शानदार है और फोटो पर बेकार। इंटरफ़ेस ग्राफ़िक्स में दोहराव भरा होता है: एक जैसी पंक्तियाँ, दोहराए आइकन्स, फ़्लैट कलर के लंबे रन। LZ77 को हर जगह मैच मिलते हैं, और फ़िल्टर बचे-खुचे को ज़ीरो के क़रीब रेसिड्यूअल बना देते हैं। फोटोग्राफ़ कुछ भी दोहराती नहीं। शॉट नॉइज़ हर पिक्सल को पड़ोसियों से थोड़ा अलग बना देता है, तो प्रिडिक्टर्स चूक जाते हैं, रेसिड्यूअल बड़े और रैंडम रहते हैं, और LZ77 के पास इशारा करने को कुछ नहीं बचता। 12 MP फोटो पर PNG raw पिक्सल्स के मुकाबले आम तौर पर 1.3:1 से 1.6:1 ही निचोड़ पाता है। JPEG नज़र में एक जैसी क्वालिटी पर 10:1 निकाल लेता है।

उन बड़ी फ़ाइलों के बदले मिलती है एक पक्की गारंटी: PNG डिकोड कीजिए, पिक्सल्स का हैश लीजिए, और हैश हर बार सोर्स से मिलेगा। जिन स्क्रीनशॉट को OCR से गुज़रना है, जिन स्कैन को फिर से एडिट किया जाएगा, मेडिकल और साइंटिफ़िक इमेजेज़ जो किसी पेपर या कोर्टरूम तक पहुँच सकती हैं, उनके लिए यह गारंटी ही पूरी बात है।

JPEG ने 1992 में लॉसी पर दांव क्यों लगाया

Joint Photographic Experts Group ने 1986 में काम शुरू किया, और उस दौर की पाबंदियाँ हर डिज़ाइन फ़ैसले की वजह बता देती हैं। 20 MB हार्ड ड्राइव सैकड़ों डॉलर की आती थी। 1.44 MB फ्लॉपी फ़ाइलें ले जाने का स्टैंडर्ड ज़रिया थी। मॉडेम 14.4 kbps पर चलते थे, वो भी किस्मत अच्छी हो तो, यानी एक अनकंप्रेस्ड 921 KB VGA फोटो डाउनलोड करने में करीब नौ मिनट। 10:1 लॉसी वर्जन एक मिनट से भी कम में पहुँच जाता है। 2:1 लॉसलेस वर्जन को भी चार मिनट से ज़्यादा लगते।

कमेटी के अपने टेस्ट्स बता चुके थे कि लॉसलेस से आगे कुछ नहीं निकलेगा। फोटोग्राफ़िक कंटेंट, जो घोषित लक्ष्य था ("कंटीन्यूअस-टोन इमेजेज़"), में रिडंडेंसी बस होती ही नहीं इतनी। इस गणित के सामने कमेटी ने बची हुई एकमात्र ढील के इर्द-गिर्द डिज़ाइन किया: दर्शक।

कम जानी गई बात यह है कि 1992 में पब्लिश हुआ स्टैंडर्ड (ISO/IEC 10918-1) एक लॉसलेस मोड भी रखता है। यह DCT को पूरी तरह छोड़ देता है, हर पिक्सल का अनुमान ज़्यादा से ज़्यादा तीन पड़ोसियों से लगाता है, सात तय प्रिडिक्टर्स में से एक से, और रेसिड्यूअल्स को एन्ट्रॉपी-कोड करता है: कॉन्सेप्ट में वही ट्रिक जो PNG तीन साल बाद इस्तेमाल करेगा। लगभग किसी ने इसे इम्प्लीमेंट नहीं किया। डिकोडर्स ने नज़रअंदाज़ किया, एन्कोडर्स ने नज़रअंदाज़ किया, और जब मेडिकल इमेजिंग को असल में लॉसलेस JPEG की ज़रूरत पड़ी, तो उसके लिए एक अलग स्टैंडर्ड बनाया गया (JPEG-LS, ISO/IEC 14495, 1999)।

कमेटी को पेटेंट्स से भी बचकर निकलना था। JPEG का arithmetic कोडिंग विकल्प IBM के Q-coder पेटेंट्स में उलझा हुआ था, इसलिए रॉयल्टी-फ्री बेसलाइन Huffman कोडिंग पर ठहरी, और ज़्यादातर इम्प्लीमेंटेशन्स ने arithmetic पाथ को छुआ ही नहीं। पेटेंट की चिंता का कोडेक डिज़ाइन को आकार देना 1992 में नई बात नहीं थी। आगे यह और भी बदतर होने वाला था।

असल में JPEG एक साइकोविज़ुअल दांव था: कंप्रेशन का आख़िरी 5× गणित नहीं, जीवविज्ञान है।

PNG ने 1995 में लॉसलेस पर दांव क्यों लगाया

PNG कोई इंजीनियरिंग प्रोजेक्ट नहीं था। यह एक क़ानूनी इमरजेंसी थी।

दिसंबर 1994 में Unisys ने ऐलान किया कि GIF इस्तेमाल करने वाले सॉफ़्टवेयर से लाइसेंस फ़ीस ली जाएगी, क्योंकि GIF का कंप्रेशन LZW एल्गोरिदम पर टिका था, जिसे 1985 का एक पेटेंट ढकता था जो Unisys को विरासत में मिला था। GIF का निर्माता CompuServe ने सौदा कर लिया और ख़र्च डेवलपर्स पर डाल दिया। Usenet की ग्राफ़िक्स कम्युनिटीज़ भड़क गईं: GIF सात साल से मुफ़्त था, और शुरुआती वेब भर की इमेजेज़ और टूल्स एक झटके में पेटेंट के घेरे में आ गए थे।

कुछ ही हफ़्तों में, जनवरी 1995 की शुरुआत में, Thomas Boutell ने विकल्प का पहला ड्राफ्ट पोस्ट किया। वॉलंटियर्स ने मेलिंग लिस्ट्स पर कुछ ही महीनों में डिज़ाइन गढ़ दिया। PNG 1.0 अक्टूबर 1996 में W3C रिकमेंडेशन के रूप में आया, फिर मार्च 1997 में RFC 2083 के रूप में।

दो ज़रूरतें कभी बहस में ही नहीं आईं। हर एल्गोरिदम पेटेंट से साफ़ होना चाहिए था, जिसका मतलब था DEFLATE (Phil Katz के PKZIP वाला LZ77 और Huffman का मिश्रण, जिसे Jean-loup Gailly और Mark Adler ने zlib में इम्प्लीमेंट किया)। और फॉर्मैट को लॉसलेस होना ही था, बात ख़त्म। कम्युनिटी GIF की जगह ले रही थी; इमेज बिगाड़ने वाला कोई बदल पैदा होते ही मर जाता, और पेटेंट ऑडिट ने वैसे भी उन परसेप्चुअल ट्रिक्स के लिए कोई जगह नहीं छोड़ी थी जिन पर JPEG चलता था।

कंटेंट भी उतना ही मायने रखता था। PNG उसी चीज़ के लिए बना था जो GIF असल में ढोता था: लोगो, डायग्राम, लाइन आर्ट, आइकन्स, स्क्रीनशॉट। शार्प एजेज़ और फ़्लैट कलर, ठीक वही कंटेंट जहाँ JPEG के रिंगिंग आर्टिफैक्ट सबसे ज़्यादा दिखते हैं। फोटो के पीछे जाने का मतलब होता DCT को फिर से इजाद करना और पहले से जड़ जमा चुके, रॉयल्टी-फ्री JPEG से भिड़ना। PNG ने वही लड़ाई चुनी जो वह जीत सकता था, और उसे पूरी तरह जीत लिया। GIF पेटेंट 2003 में एक्सपायर हुआ (US के बाहर 2004 में), लेकिन तब तक PNG उसकी कुर्सी ले चुका था।

फिर भी बाज़ार में लॉसी क्यों जीता

PNG को उसका निश मिल गया। JPEG के हिस्से पूरी दुनिया आई।

वजह वॉल्यूम है। वेब की इमेजेज़ भारी बहुमत में फोटोग्राफ़ हैं, और फोटोग्राफ़ के लिए लॉसी कोई समझौता नहीं, सही औज़ार है। 2025 Web Almanac के मुताबिक़ तीन दशक बीत जाने के बाद भी JPEG सर्व की जाने वाली सभी इमेजेज़ का लगभग 57% है। सोशल फ़ीड, न्यूज़ फोटोग्राफ़ी, प्रोडक्ट शॉट्स, रियल एस्टेट लिस्टिंग: सब कंटीन्यूअस-टोन कंटेंट, जहाँ क्वालिटी-75 लॉसी एन्कोड उन स्क्रीनों पर सोर्स से अलग नहीं लगता जिनका लोग असल में इस्तेमाल करते हैं।

इकॉनॉमिक्स भी उसी दिशा में धकेलती है। स्टोरेज और बैंडविड्थ प्रति बाइट बिल होते हैं, और 10:1 बनाम 2:1 कोई मार्जिन नहीं, स्वीकार्य क्वालिटी पर डिलीवरी लागत में 5× का फ़र्क है। पेज स्पीड फ़ाइल साइज़ के पीछे चलती है, और फ़ाइल साइज़ कंप्रेशन के पीछे। हर कैमरा और फोन लॉसी डिफ़ॉल्ट (JPEG या HEIC) के साथ आता है। हर CMS लॉसी थंबनेल बनाता है। सोशल प्लेटफ़ॉर्म हर अपलोड को री-एन्कोड करते हैं, कुछ साइज़ के लिए, कुछ मेटाडेटा और उसमें छिपी किसी भी खतरनाक चीज़ को उछालने के लिए। कोई फोटोग्राफ़र बेदाग TIFF अपलोड कर सकता है; टाइमलाइन जो सर्व करती है, वह क्वालिटी-85 JPEG है।

लॉसलेस हारा नहीं, बस उन जगहों पर पीछे हट गया जहाँ उसकी गारंटी मायने रखती है: स्क्रीनशॉट और UI एसेट्स, जहाँ आर्टिफैक्ट तुरंत दिखते हैं और कंटेंट वैसे भी अच्छा कंप्रेस होता है; एडिट पाइपलाइन में मास्टर्स, जहाँ हर लॉसी जनरेशन जुड़ती जाती है; मेडिकल, लीगल और साइंटिफ़िक इमेजिंग, जहाँ "लगभग सही" सबूत नहीं बनता। इन निशों में PNG और TIFF को कोई चुनौती नहीं। बस ट्रैफ़िक वहाँ नहीं है।

फॉर्मैट्स आख़िर कहाँ पहुँचे

दो रुझान साफ़ दिखते हैं। नए कोडेक्स अब कोई पक्ष नहीं चुनते: WebP, HEIC, AVIF और JPEG XL सब एक ही स्पेसिफ़िकेशन में लॉसी और लॉसलेस मोड लेकर आते हैं, और JPEG 2000 यह 2000 में ही कर रहा था। लॉसी बनाम लॉसलेस का सवाल "कौन सा फॉर्मैट" से बदलकर "कौन सा मोड" हो गया है। और बॉर्डरलाइन केस आते ही रहते हैं। JPEG XL किसी मौजूदा JPEG को लॉसलेस तरीके से उसके साइज़ के लगभग 80% तक रीकंप्रेस कर सकता है, और यह ट्रिक इसलिए मुमकिन है क्योंकि दोनों खेमों ने तीस साल एक-दूसरे का गणित सीखा है।

प्रैक्टिस में कैसे चुनें

डिसिज़न ट्री छोटा है:

• फोटो पब्लिश कर रहे हैं? लॉसी। कंपैटिबिलिटी मायने रखे तो JPEG, साइज़ मायने रखे तो WebP या AVIF।
• स्क्रीनशॉट, लोगो या टेक्स्ट और फ़्लैट कलर वाली कोई भी चीज़ सेव कर रहे हैं? लॉसलेस। PNG।
• एडिट कर रहे हैं? मास्टर को लॉसलेस रखें, लॉसी कॉपी एक्सपोर्ट करें, और लॉसी फ़ाइल को उसी फॉर्मैट में दोबारा कभी सेव न करें। हर जनरेशन नुकसान बढ़ाती है।
• कन्वर्ट कर रहे हैं? आउटपुट को इनपुट से नहीं, काम से मिलाइए। फोटो गैलरी में जाने वाला PNG स्क्रीनशॉट JPEG या WebP बनना चाहिए। डिज़ाइन फ़ाइल में जाने वाला JPEG PNG बनना चाहिए, इसलिए नहीं कि क्वालिटी बढ़ेगी (नहीं बढ़ सकती), बल्कि इसलिए कि आगे घटना बंद हो जाता है।

iPhone फोटो में लोग अक्सर इसी आख़िरी पॉइंट पर अटकते हैं। HEIC पहले से लॉसी HEVC कंप्रेशन है। HEIC को PNG में बदलने से कुछ वापस नहीं आता; यह मौजूदा हालत को फ़्रीज़ कर देता है और आगे का नुकसान रोक देता है, और अगर आप एडिट करने वाले हैं तो यह भी काम की बात है। शेयर करने के लिए सीधे JPEG में बदलना ही सही रास्ता है। हमारे HEIC से JPG, HEIC से PNG और HEIC से WebP कन्वर्टर्स कन्वर्ज़न आपके ब्राउज़र में लोकली चलाते हैं, इसलिए फ़ाइल आपके डिवाइस से बाहर नहीं जाती।

यही लॉजिक बाकी पूरी मैट्रिक्स को भी कवर करता है। JPEG को लॉसलेस एडिटिंग वर्कफ़्लो में लाना: JPG से PNG। वेब के लिए PNG स्क्रीनशॉट छोटा करना: PNG से JPG, या PNG से WebP जब छोटी फ़ाइलें चाहिए और ट्रांसपैरेंसी भी सलामत रखनी हो। उल्टी दिशा में, WebP से PNG और WebP से JPG पुराने सॉफ़्टवेयर के साथ कंपैटिबिलिटी वापस दिलाते हैं। अगर आप अनकंप्रेस्ड BMP स्कैन में फँसे हैं, तो BMP से JPG, BMP से PNG और BMP से WebP एक ही स्टेप में वही लॉसी-लॉसलेस चॉइस देते हैं। डॉक्यूमेंट रेंडर करना भी उसी चौराहे पर आता है: किसी PDF पेज को इमेज के रूप में एक्सपोर्ट करने का मतलब है यह चुनना कि फोटोग्राफ़िक पेजों के लिए PDF से JPG, और टेक्स्ट को क्रिस्प रखना हो तो PDF से PNG।

तीस साल बाद, जो फॉर्मैट बचे हैं, वे वही हैं जिन्हें ठीक-ठीक मालूम था कि उनके यूज़र्स क्या भूल सकते हैं और क्या नहीं।