JXL फ़ाइल क्या होती है?

JXL एक बाइनरी फ़ॉर्मेट है, जो सिर्फ़ उसी प्रोग्राम के लिए मायने रखता है जो इसे जानता हो। यह पिक्सेल की एक जाली सहेजता है, इसलिए अपने ही रिज़ॉल्यूशन से आगे बढ़ाने पर यह धुँधला पड़ जाता है। इसका इस्तेमाल सहेजना और फ़ोटोग्राफ़ी के लिए होता है।

एक्सटेंशन .jxl है और पूरा नाम JPEG XL। दोनों उतना नहीं बताते जितना यह कि फ़ाइल अंदर क्या-क्या रख सकती है — और इस पन्ने का बाक़ी हिस्सा इसी के बारे में है।

इसे Joint Photographic Experts Group ने 2021 में जारी किया था। विनिर्देश ISO/IEC 18181 है।

उम्र एक व्यावहारिक वजह से काम की है: फ़ॉर्मेट जितना पुराना, उतने ज़्यादा प्रोग्रामों को उसे सीखने का वक़्त मिला है।

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

यह एक ही काम को एक ही तरह के लोगों के लिए अच्छी तरह करने को मौजूद है। उस काम के बाहर इसे यूँ ही चुन लेना ठीक नहीं, और उस काम के अंदर आमतौर पर इससे बेहतर कुछ है ही नहीं।

JXL फ़ाइल अपना अंदरूनी हिस्सा हूबहू सहेजती है। दोबारा सहेजने से कुछ नहीं बदलता, इसलिए इसे जितनी बार चाहें खोलिए, बदलिए और फिर से सहेजिए — नुक़सान जमा नहीं होता। यही बात इसे सौंपने का नहीं, काम करने का फ़ॉर्मेट बनाती है।

JXL फ़ाइल अपने साथ एक अल्फ़ा चैनल रखती है, इसलिए लोगो के किनारे पीछे जो कुछ भी हो उसके ऊपर नरम बने रहते हैं — वह सफ़ेद डिब्बे में बंद होकर नहीं पहुँचता।

JXL फ़ाइल ठहरी हुई एक तस्वीर के बजाय पूरा एनिमेशन सहेज सकती है। बदलने से पहले यह जान लेना ज़रूरी है: जो लक्ष्य सिर्फ़ एक फ़्रेम रखता है, वह पहला रख लेता है और बाक़ी गिरा देता है — अमूमन बिना बताए।

हर चैनल पर 32 बिट तक। यह RGB, ग्रेस्केल और चौड़े दायरे का रंग में काम कर सकता है।

हर चैनल पर आठ से ज़्यादा बिट ही वह चीज़ है जो संपादन के दौरान ढलान को सीढ़ियों में टूटने से रोकती है — काम वाली फ़ाइल में इसकी अहमियत है, बनी हुई फ़ाइल में शायद ही कभी।

GIMP और ImageMagick इसे पढ़ते हैं, और इसी तरह के ज़्यादातर दूसरे प्रोग्राम भी।

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

इसे कुछ ही ब्राउज़र पढ़ पाते हैं।

जहाँ सहारा एक-सा नहीं है, वहाँ साथ में दूसरा फ़ॉर्मेट परोस देना आम जवाब है: ब्राउज़र वही उठा लेता है जो वह समझता है, और कोई बाहर नहीं छूटता।

JXL फ़ाइल EXIF डेटा, XMP डेटा और ICC प्रोफ़ाइल रख सकती है।

इसमें से कुछ भी बदलाव के बाद बचेगा या नहीं, यह पूरी तरह लक्ष्य फ़ॉर्मेट पर टिका है, और ईमानदार जवाब अमूमन «कुछ हिस्सा» ही है।

JXL सौंपने के लिए बना है, इसके अंदर काम करने के लिए नहीं। इसे बदलना मुमकिन है और शायद ही कभी सुखद; समझदारी का रास्ता मूल फ़ाइल से होकर और एक नए निर्यात से होकर जाता है।

बार-बार आने वाली शिकायतें: अपने इलाक़े के बाहर सहारा बिखरा हुआ है।

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

यह क्षमता किसी और के पास नहीं। JPEG XL मौजूदा JPEG को ले सकता है, उसे क़रीब 20 प्रतिशत छोटा दोबारा एनकोड कर सकता है, और बाद में मूल फ़ाइल बाइट-दर-बाइट वापस बना सकता है — बस दिखने में एक जैसी तस्वीर नहीं, वही फ़ाइल, वही checksum के साथ।

इससे सवाल बदल जाता है। तस्वीर लाइब्रेरी को WebP या AVIF में बदलने का मतलब है प्रतिबद्धता: JPEG दूसरे लॉसी पास से गुज़रती हैं, और मूल या तो साथ रखी जाती हैं या चली जाती हैं। JXL में दोबारा-कंप्रेस करना उलटा जा सकने वाला है, तो बीस साल पुराना आर्काइव बिना कुछ दाँव पर लगाए पाँचवाँ हिस्सा छोटा हो सकता है।

JPEG XL में AVIF को टक्कर देता lossy मोड है और PNG को टक्कर देता lossless मोड है, और WebP के दो मोड के उलट ये एक ही डिज़ाइन साझा करते हैं। Lossless JXL आम तौर पर PNG से 30 से 40 प्रतिशत छोटा होता है।

यह progressive decoding भी संभालता है — आंशिक रूप से डाउनलोड फ़ाइल पूरी तस्वीर के कम-रेज़ोल्यूशन संस्करण के तौर पर दिखती है। AVIF ऐसा कुछ सिर्फ़ layered एनकोड से पाता है जो लगभग कोई एनकोडर नहीं बनाता।

Chrome ने JPEG XL को एक फ़्लैग के पीछे लागू किया और फिर 2023 में हटा दिया, कहते हुए इकोसिस्टम की दिलचस्पी इसे बनाए रखने के लायक़ नहीं थी। यह फ़ैसला फ़ोटोग्राफ़र, ब्राउज़र इंजीनियर और इमेज-कंप्रेशन समुदाय में बहस का विषय रहा।

फिर Apple ने 2023 में Safari 17 में सहारा जोड़ा, और यह macOS व iOS दोनों पर काम करता है। तो आज की स्थिति सच में बँटी है: Safari हाँ, Firefox फ़्लैग के पीछे, Chrome नहीं। असामान्य रूप से मज़बूत तकनीकी मामला और असामान्य रूप से ख़राब क़िस्मत वाला फ़ॉर्मेट।

macOS और iOS पर Safari, जो तस्वीर ट्रैफ़िक का बड़ा हिस्सा है। Adobe के ऐप्लिकेशन, जिन्होंने सहारा जोड़ा। इमेज टूल और लाइब्रेरी का बढ़ता सेट। कुछ कैमरा निर्माता इसे कैप्चर विकल्प के तौर पर दे चुके हैं।

व्यावहारिक नतीजा यह है कि JXL अभी डिलीवरी फ़ॉर्मेट की बजाय भंडारण और आर्काइव फ़ॉर्मेट के तौर पर समझ में आता है। अपनी डिस्क पर लाइब्रेरी कंप्रेस करना आपके नियंत्रण का फ़ैसला है; सार्वजनिक वेबपेज पर JXL डालने का मतलब है बड़ा हिस्सा कुछ नहीं देख पाएगा।

JPEG XL 2022 में दो सबमिशन से मानकीकृत हुआ: Google का PIK और Cloudinary का FUIF, जो ख़ुद FLIF से निकला। नतीजा दोनों के विचार लिए हुए है, यही वजह है यह तस्वीर और synthetic इमेज दोनों को अच्छे से संभालता है, किसी एक के लिए ट्यून किए बिना।

यह वंशावली एक व्यावहारिक वजह से मायने रखती है: JPEG recompression फ़ीचर जान-बूझकर डिज़ाइन से आया, किसी हादसे से नहीं। समिति ने मौजूदा JPEG संग्रह को माइग्रेट करने लायक़ बनाने का लक्ष्य रखा।

हर चैनल में बत्तीस बिट तक, चौड़े रंग-दायरे और HDR। lossy और lossless दोनों मोड में असली अल्फ़ा चैनल। एनिमेशन। और फ़ॉर्मेट अन्य फ़ॉर्मेट से कहीं बड़ी तस्वीरें रखता है — आयाम की सीमाएँ व्यावहारिक की बजाय सैद्धांतिक हैं।

यह AVIF से काफ़ी तेज़ भी एनकोड करता है, जो AVIF की मुख्य कमज़ोरी है। इस पैमाने पर JXL दो आधुनिक फ़ॉर्मेट में ज़्यादा व्यावहारिक है, जो वेब पर इसकी हालत को कम की बजाय ज़्यादा निराशाजनक बनाता है।

अगर आप मौजूदा JPEG दोबारा-कंप्रेस कर रहे हैं, lossless JPEG recompression मोड इस्तेमाल कीजिए, जो उलटा जा सकता है और कुछ ख़र्च नहीं करता। अगर इसकी बजाय आप उस JPEG को JXL के सादे lossy मोड से एनकोड करते हैं, आप पहले से कंप्रेस्ड तस्वीर को दूसरे लॉसी पास से गुज़ार रहे हैं और नुक़सान बढ़ता जाता है।

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

JPG में तब जब फ़ाइल किसी ऐसे व्यक्ति तक पहुँचनी है जिसका ब्राउज़र या सॉफ़्टवेयर JXL नहीं दिखाएगा, जो आज ज़्यादातर लोगों का मतलब है। उसी दिखने वाली क्वालिटी पर बड़ी फ़ाइल की उम्मीद रखिए। PNG में तब जब तस्वीर में पारदर्शिता है या यह स्क्रीनशॉट या डायग्राम है।

Bit depth देखने लायक़ नुक़सान है। हर चैनल में आठ से ज़्यादा बिट रखने वाली JXL को JPG या PNG में बदलने पर ग्रेडिएंट में कम स्तर बचते हैं। JXL रखिए — इसकी हालत देखते हुए, यह बहुत मुमकिन है यही आर्काइव प्रति है और बदली फ़ाइल वह है जो आप भेजते हैं।

अपने स्टोरेज पर निजी आर्काइव के लिए, अकेला JPEG recompression मज़बूत दलील है: पाँचवाँ हिस्सा छोटा, पूरी तरह उलटा जा सकने वाला, कुछ भी जोखिम में नहीं। यह एक दुर्लभ पेशकश है और यह इस पर निर्भर नहीं करता कि ब्राउज़र किसी बात पर सहमत हों।

प्रकाशित होने वाली किसी भी चीज़ के लिए, अभी नहीं। Chrome के बिना फ़ॉर्मेट को मुख्य तस्वीर के तौर पर परोसा नहीं जा सकता, और बहुसंख्यक के लिए fallback बनाए रखना ज़्यादातर फ़ायदा हटा देता है। यह बदल सकता है — Safari का सहारा ख़ुद इस चलन का उलटफेर था — पर आज का फ़ैसला इस बात पर टिकना चाहिए कि यह अभी कहाँ काम करता है।