JXL को GIF में बदलें

इसकी एक ही ठोस वजह है और वह बाहरी है: जहाँ तस्वीर जानी है वह जगह GIF लेती है और और कुछ नहीं। पुराना फ़ोरम सॉफ़्टवेयर, दशक भर पुराने भीतरी औज़ार, कुछ टिकटिंग सिस्टम, कुछ ईमेल-हस्ताक्षर संपादक और कई एम्बेडेड वेब इंटरफ़ेस इसी श्रेणी में आते हैं, और किसी कोडेक की दलील किसी अपलोड-वैलिडेटर के आगे काम नहीं आती।

अगर आपकी मंज़िल कुछ और ले सकती है, कुछ और लीजिए। WebP छोटी है, पूरा रंग और असली पारदर्शिता रखती है, और हर ब्राउज़र इसे पढ़ता है; PNG बिना नुक़सान वाला विकल्प है जहाँ सिस्टम पुराना है पर उतना पुराना नहीं। यह पेज उस मजबूर हालत के लिए है — यह मानना कि GIF किसी JXL के लिए वाजिब मंज़िल है, ग़लत होगा।

GIF एक इंडेक्स्ड तस्वीर रखती है: हर पिक्सेल ज़्यादा से ज़्यादा 256 प्रविष्टियों की पैलेट में एक नंबर की ओर इशारा करता है, और यह सीमा GIF89a विनिर्देश में है, किसी सेटिंग में नहीं। JPEG XL इसके ठीक उलट सिरे से आता है — हर चैनल में 32 बिट तक, चौड़ा रंग-दायरा, और डिज़ाइन में कहीं कोई पैलेट नहीं।

किसी फ़ोटो पर यह गिरावट तुरंत दिखती है। जो आसमान दो सौ नीलेपन से गुज़रता था, उसे बस दर्जन भर मिलते हैं, और छायाओं के बीच की रेखा ढाल की जगह पट्टी बन जाती है। सपाट सामग्री कहीं बेहतर बचती है — कोई डायग्राम, इंटरफ़ेस स्क्रीनशॉट या सादे पृष्ठभूमि वाला लोगो पहले से 256 से कम रंग रख सकता है और बिना किसी दिखने वाले नुक़सान के बदल जाता है।

GIF को CompuServe ने 1987 में प्रकाशित किया, और इसका मौजूदा संस्करण GIF89a 1989 का है। यह वेब, रंग-प्रबंधन और आज समझे जाने वाले अल्फ़ा चैनल से पहले का है। JPEG XL को 2021 में ISO/IEC 18181 के रूप में उसी समिति ने मानकीकृत किया जिसने असली JPEG विनिर्देश लिखा था।

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

यह वह हिस्सा है जो 256 रंगों वाले फ़ॉर्मेट से कोई नहीं अपेक्षा रखता। संपीड़न से पहले पैलेट-आधारित तस्वीर एक बाइट प्रति पिक्सेल होती है, तो बारह-मेगापिक्सेल फ़ोटो बारह लाख पैलेट-इंडेक्स बाइट होती है। फिर GIF LZW लगाती है, जो दोहराए हुए मान ढूँढता है — सपाट ग्राफ़िक में बहुत, फ़ोटोग्राफ़िक शोर में लगभग नहीं।

नतीजा यह है कि दो-तीन मेगाबाइट की JXL अक्सर उससे कई गुना बड़ी GIF बनकर निकलती है, और वह भी कहीं ज़्यादा ख़राब दिखते हुए। अगर फ़ाइल-आकार आपकी वजह का हिस्सा है, यहीं रुक जाइए — यह जोड़ी आकार और गुणवत्ता दोनों में ग़लत दिशा में जाती है। अपवाद सिर्फ़ सपाट-ग्राफ़िक वाला मामला है, जहाँ GIF सचमुच छोटी हो सकती है।

GIF की पारदर्शिता एक पैलेट प्रविष्टि को अदृश्य चिह्नित करने भर है, कटआउट किनारे को मुलायम दिखाने वाले आधे-पारदर्शी पिक्सेल के लिए कोई बीच का मान नहीं। यहाँ का एनकोडर एक क़दम आगे जाकर कोई प्रविष्टि चिह्नित ही नहीं करता — अल्फ़ा चैनल पैलेट चुने जाने से पहले ही ड्रॉप-ज़ोन के ऊपर सेट पृष्ठभूमि रंग से भर दिया जाता है।

तो नतीजा एक फ़ैसले पर टिकता है। रंग को उसी तस्वीर पर सेट कीजिए जहाँ यह बैठेगी और एंटी-अलायस्ड किनारा ठीक वैसे ही घुल जाएगा जैसे JXL में था; इसे सफ़ेद पर छोड़ें और किसी गहरे पेज पर कटआउट सफ़ेद डिब्बे में क़ैद दिखेगा। जहाँ पारदर्शिता ही तस्वीर की वजह है, WebP या PNG उसे रखने वाली मंज़िल है, GIF नहीं।

दोनों फ़ॉर्मेट एनिमेशन रख सकते हैं, इसलिए यह GIF की नहीं, इस कन्वर्टर की सीमा है। यहाँ इस्तेमाल किया गया JXL डिकोडर एक ही तस्वीर लौटाता है, तो एनिमेटेड स्रोत एक-फ़्रेम वाली GIF बनता है और बाक़ी फ़्रेम इस पेज तक पहुँचने से पहले ही कोडेक द्वारा छोड़ दिए जाते हैं।

यह शुरू करने से पहले जान लेना ज़रूरी है, क्योंकि स्थिर GIF वह फ़ाइल है जिसे कोई नहीं चाहता। अगर क्रम ही मक़सद है, MP4 या WebM सही फ़ॉर्मेट भी है और कहीं छोटा भी — GIF के रूप में कई मेगाबाइट तक जाने वाला एनिमेशन वीडियो में आमतौर पर उसका दसवाँ हिस्सा भर होता है।

256 रंग तय करने का काम किसी को करना है, और उसे बुरी तरह करना ही वह धब्बेदार, पोस्टराइज़्ड GIF बनाता है जिसके लिए यह फ़ॉर्मेट याद रखा जाता है। कन्वर्टर तस्वीर से ही पैलेट बनाता है, हर चैनल को एक तयशुदा जाली में गोल करने के बजाय वाक़ई मौजूद रंगों को समूहबद्ध करता है — ImageMagick जैसे औज़ार भी यही तरीक़ा अपनाते हैं।

पैलेट को घटाए हुए रंग-स्थान में बनाया जाता है ताकि काम तेज़ रहे, जो नाज़ुक ढाल पर थोड़ी सटीकता की क़ीमत पर किसी बड़ी फ़ोटो पर कई सेकंड ख़र्च होने से बचाता है। 256 रंगों पर ख़त्म होने वाले फ़ॉर्मेट के लिए यह सौदा भारी पड़ता है — नतीजे में इस भीतरी सटीकता से कहीं ज़्यादा असर क्वांटाइज़ेशन के क़दम का होता है।

GIF में कोई गुणवत्ता पैरामीटर है ही नहीं, इसलिए यहाँ कोई गुणवत्ता सेटिंग दी भी नहीं गई है। WebP या AVIF की तरह ब्योरे के बदले कोई दर चुनने को नहीं — फ़ाइल उतनी ही बड़ी होती है जितनी पैलेट-इंडेक्स और LZW शब्दकोश बनाते हैं, और इनमें से किसी पर असर डालने वाला इकलौता लीवर पिक्सेल-गिनती है।

यही अधिकतम-चौड़ाई नियंत्रण को यहाँ इकलौता काम का विकल्प बनाता है। तस्वीर की चौड़ाई आधी करने से पिक्सेल-गिनती चौथाई होती है और GIF भी लगभग चौथाई रह जाती है, और जो सिस्टम सिर्फ़ GIF लेता है उसमें आम तौर पर आकार-सीमा भी जुड़ी होती है।

JPEG XL EXIF, XMP और ICC प्रोफ़ाइल रखता है। GIF के पास इनमें से किसी को रखने की जगह नहीं — कोई मानक मेटाडेटा ब्लॉक नहीं, कोई रंग-प्रबंधन नहीं, कोई कैप्चर जानकारी नहीं। कैमरा, लेंस, तारीख़, निर्देशांक और रंग-स्थान — सब इसी कन्वर्ज़न पर ख़त्म हो जाते हैं।

यह नुक़सान है या फ़ायदा, यह इस पर निर्भर करता है कि आप क्यों बदल रहे हैं। किसी सार्वजनिक फ़ोरम पर पोस्ट करने के लिए यह वही नतीजा है जो आप ख़ुद चाहते — हटाने को एक चीज़ कम। किसी रिकॉर्ड की तरह फ़ाइल करने के लिए इसका मतलब है कि GIF वह प्रति नहीं है जिसे रखा जाए — JPEG XL ही वह है।

डिकोड, पैलेट बनाना और GIF लिखना — तीनों आपके ब्राउज़र में चलते हैं, तो कुछ भी अपलोड नहीं होता और किसी फ़ाइल के लिए इंतज़ार नहीं करना पड़ता। मुफ़्त स्तर पर 100 MB तक की फ़ाइलें स्वीकार होती हैं, और JPEG XL फ़ाइलों का पूरा फ़ोल्डर एक ही बार में बदलकर ZIP बनकर लौटता है।

JPEG XL रखिए। यह इस साइट का सबसे नुक़सानदेह कन्वर्ज़न है — रंग, पारदर्शिता, एनिमेशन और अक्सर आकार, सब ग़लत दिशा में जाते हैं — और GIF से वापस मूल जितना पाने का कोई रास्ता नहीं। अगर कभी वह पाबंद सिस्टम कोई आधुनिक फ़ॉर्मेट स्वीकार करने लगे, आपके पास मूल फ़ाइल से दोबारा बदलने का विकल्प बना रहेगा।