आँकड़ों और विज्ञापन के लिए कुकीज़
हम आँकड़ों और विज्ञापन के लिए कुकीज़ इस्तेमाल करते हैं, दोनों Google को जाती हैं। मना करने से आपको दिखने वाली किसी चीज़ में कोई फ़र्क़ नहीं पड़ता।निजता पेज पढ़ें
यहाँ आप TIFF को JXL में बदलते हैं, मुफ़्त और बिना खाते के: फ़ाइल ऊपर छोड़िए और कुछ ही सेकंड में नतीजा डाउनलोड के लिए तैयार मिलेगा। कन्वर्ज़न आपके अपने ब्राउज़र के भीतर होता है, इसलिए फ़ाइल कभी अपलोड नहीं होती। यह Windows, macOS और Linux पर वैसे ही चलता है जैसे iPhone और Android पर, और कनेक्शन काट देने पर भी चलता रहता है।
एक बार में 100 फ़ाइलें। फ़ॉर्मेट अलग-अलग हों तो भी चलेगा।
ये एक के बाद एक बदलती हैं और साथ में एक ZIP बनकर उतरती हैं।
TIFF से JXL
TIFF 601 KB → JXL 7 KB 85.0× छोटी
TIFF 601 KB → JXL 5 KB 122.7× छोटी
TIFF 601 KB → JXL 13 KB 46.4× छोटी
यह जोड़ी खोजी जाने की वजह अच्छी है — JPEG XL सचमुच पुरालेख के लिए मज़बूत उम्मीदवार है, 32 बिट प्रति चैनल तक सँभालती और सच्चा lossless मोड रखती है। कई राष्ट्रीय पुस्तकालयों ने इसे इसी वजह से गंभीरता से देखा।
इसमें से कुछ भी इस converter से नहीं पहुँचता, क्योंकि बीच की पाइपलाइन 8-बिट RGB है और एनकोडर एक क्वालिटी अंक से चलता है। जो मिलता है वह छोटी, अच्छी दिखने वाली, नुक़सान वाली प्रति है — मास्टर नहीं। TIFF को रखिए, इसे उसी तरह देखिए जैसे उसी स्कैन की JPG को देखते हैं।
यहाँ का एनकोडर लॉसलेस झंडा कभी सेट नहीं करता। इस साइट के अपने एनकोडर पर 256 गुणा 256 के टेस्ट पर मापा गया: डिफ़ॉल्ट 82 पर, ग्रेडिएंट के 262,144 में से 73,647 नमूने बदल गए, सबसे बुरा 21 दर्जों तक। 100 पर सिर्फ़ 334 नमूने बदले, कोई एक दर्जे से ज़्यादा नहीं।
यह near-lossless है, lossless नहीं। व्यावहारिक रूप से: देखने भर के लिए 82 पर छोड़िए, अगर JXL बाद में फिर एनकोड होगी तो 100 पर सेट कीजिए, और किसी सूची-रिकॉर्ड में इसे lossless मत लिखिए।
बहुत सी TIFF 16-बिट होती हैं — यही स्कैन करके TIFF बनाने का मुख्य मक़सद है। यहाँ का रीडर 16-बिट फ़ाइल सही पढ़ता है और फिर हर नमूने का ऊपरी बाइट रखकर 8 बिट आगे भेजता है। मापा गया: 30,000 का संचित मान 117 बनकर आता है।
तैयार तस्वीर पर कोई फ़र्क़ नहीं दिखता, क्योंकि स्क्रीन आठ बिट ही दिखाती है। संपादन मास्टर पर पूरा फ़र्क़ यही है — गहरे curve बदलाव से टिकने वाला 16-बिट ग्रेडिएंट यहीं गँवाया जाता है।
प्रिंट वर्कफ़्लो से आई TIFF अक्सर CMYK होती है, ICC प्रोफ़ाइल के साथ। यहाँ का रीडर CMYK को embedded प्रोफ़ाइल के बजाय एक तय फ़ॉर्मूले से स्क्रीन रंग में बदलता है — नतीजा वही तस्वीर है, थोड़े ग़लत रंगों में।
प्रोफ़ाइल ख़ुद भी साथ नहीं जाती — हर तस्वीर-बदलाव raw पिक्सेल में डिकोड होकर फिर एनकोड होता है, इसलिए ICC, EXIF, XMP सब गिर जाते हैं। प्रिंट सामग्री के लिए यह असली नुक़सान है।
TIFF एक फ़ाइल में एक से ज़्यादा तस्वीर रखती है, और दस्तावेज़ स्कैनर इसका लगातार इस्तेमाल करते हैं। यहाँ लिखी जाने वाली JPEG XL एक ही रखती है। रीडर पहला पन्ना लेता है और रुक जाता है, बिना कोई त्रुटि दिखाए।
यह वह इकलौता तरीक़ा है जिसमें यह बदलाव किसी पूरे संग्रह पर चुपचाप ग़लत जा सकता है, इसलिए बैच से पहले जाँच लीजिए। अगर पन्ने साथ रहने चाहिए, तो TIFF को PDF में बदलने वाला पेज सबको एक फ़ाइल में रखता है।
बहुत छोटी, क्योंकि शुरुआती बिंदु बिना दबा है। इस साइट के अपने 480 गुणा 320 के नमूने हर हाल में 615,400 बाइट TIFF हैं; डिफ़ॉल्ट क्वालिटी पर JXL में फ़ोटोग्राफ़ के लिए 7,240 बाइट, फ़्लैट ग्राफ़िक के लिए 5,016।
यह फ़ोटोग्राफ़िक अंक उस नमूना सेट के हर फ़ॉर्मेट से छोटा है, WebP के 14,700 और AVIF के 17,599 से नीचे। सिर्फ़ बाइट-प्रति-क्वालिटी का सवाल हो तो JPEG XL यहाँ जीतता है।
यहीं JPEG XL हारता है। ब्राउज़र समर्थन आंशिक है, पूरा नहीं, इसलिए .jxl किसी वेब पेज पर डालने या बिना जाँचे किसी को भेजने लायक़ फ़ाइल नहीं। GIMP और ImageMagick इसे सँभालते हैं; Photoshop को plugin चाहिए।
यह ईमानदार इस्तेमाल दो हालात तक सीमित करता है — कोई बंद वर्कफ़्लो जिसका औज़ार यही नाम लेता है, या कोई प्रयोग जहाँ असली फ़ाइल कहीं और सुरक्षित है।
अगर मक़सद exact रहते हुए छोटी पुरालेख प्रति है, तो TIFF को PNG में बदलना ज़्यादा ईमानदार है — PNG आठ बिट के भीतर lossless है, हर सॉफ़्टवेयर इसे पढ़ता है। अगर मक़सद प्रकाशन है, तो WebP या AVIF हर ब्राउज़र में काम करते हैं।
और अगर मक़सद सचमुच पुरालेख मास्टर है, तो सही जवाब वही है जो किसी को पसंद नहीं: जो TIFF पहले से है वही मास्टर है, और उसे रखा जाना चाहिए।
utif2 TIFF डिकोड करता है और WebAssembly में संकलित libjxl JXL लिखता है, दोनों ज़रूरत पड़ने पर ही उतरते हैं। फ़ाइल के बारे में कुछ भी नेटवर्क पार नहीं करता — मुफ़्त सीमा फ़ाइल पर 100 मेगाबाइट है।
बैच भी उसी तरह चलते हैं: फ़ोल्डर छोड़िए, हर फ़ाइल की अपनी प्रगति-पंक्ति, नतीजे ZIP बनकर वापस आते हैं। JPEG XL का एनकोडिंग AVIF जितना धीमा नहीं, पर तुरंत भी नहीं।
| TIFF | JXL | |
|---|---|---|
| पूरा नाम | Tagged Image File Format | JPEG XL |
| फ़ाइल एक्सटेंशन | .tif, .tiff | .jxl |
| मीडिया टाइप | image/tiff | image/jxl |
| कंप्रेशन | बिना नुक़सान — कुछ छोड़ा नहीं जाता | सेटिंग के हिसाब से दोनों में से कोई भी |
| पहली बार प्रकाशित | 1986 | 2021 |
| प्रकाशक | Adobe | Joint Photographic Experts Group |
| विनिर्देश | TIFF 6.0 | ISO/IEC 18181 |
| लाइसेंस | प्रकाशित, मानकीकृत नहीं | खुला मानक |
| आज की स्थिति | मौजूदा | सीमित उपयोग |
| बिट डेप्थ | 32 | 32 |
| रंग जो यह दर्ज कर सकता है | RGB, CMYK, ग्रेस्केल, Lab | RGB, ग्रेस्केल, वाइड गैमट |
| ब्राउज़र में खुलता है | कुछ ब्राउज़र | कुछ ब्राउज़र |
| इसकी जगह विचारणीय | PNG, PDF, DNG | AVIF, WebP, PNG |
JXL में कैप्शन, क्रेडिट और कीवर्ड वाले IPTC फ़ील्ड और GPS निर्देशांक के लिए जगह नहीं है, इसलिए वह TIFF फ़ाइल से आगे नहीं जाता। असली फ़ाइल फेंकने से पहले यह देख लेना काम आता है — और अगर फेंकना ही मक़सद था, तो यह जान लेना काम आता है।
TIFF में CMYK हो सकता है; JXL RGB में काम करता है। जो फ़ाइल प्रेस के लिए तैयार खड़ी थी वह स्क्रीन के रंग में चली जाती है, और छपाई की धारा में रंग-पृथक्करण दोबारा बनाना पड़ेगा।
पारदर्शिता बनी रहती है। TIFF और JXL — दोनों अल्फ़ा चैनल सँभालते हैं: काटा हुआ हिस्सा कटा ही रहता है और उसके पीछे कुछ भरा नहीं जाता।
JXL एनिमेशन ढो सकता है; TIFF फ़ाइल एक ही फ़्रेम है। बाहर ऐसी फ़ाइल आती है जिसमें एक तस्वीर है, और वह ऐसे फ़ॉर्मेट में है जो इससे ज़्यादा सँभाल सकता था।
ImageMagick TIFF और JXL — दोनों पढ़ लेता है, इसलिए आप नतीजे को असली फ़ाइल के बग़ल में रखकर देख सकते हैं, बिना दूसरा प्रोग्राम खोले।
TIFF Adobe का फ़ॉर्मेट है, जो 1986 में आया। यह हर चैनल पर 32 बिट में दर्ज करता है।
JXL Joint Photographic Experts Group का है और 2021 से चला आ रहा है, और ISO/IEC 18181 में तय किया गया है। GIMP और ImageMagick इस फ़ॉर्मेट को पढ़ लेते है।
TIFF 1986 में आया और JXL 2021 में। किसी को सौंपने के लिए आम तौर पर पुराना वाला ज़्यादा सुरक्षित रहता है; नया वाला वही काम कम बाइट में कर देता है।
नहीं। यह कन्वर्ज़न पूरी तरह आपके ब्राउज़र में होता है, इसलिए फ़ाइल आपके डिवाइस से बाहर नहीं जाती। आप ख़ुद जाँच सकते हैं: डेवलपर टूल्स का नेटवर्क टैब खोलिए और कुछ बदल कर देखिए। आपको पेज ख़ुद दिखेगा और आँकड़ों तथा विज्ञापन के वे अनुरोध दिखेंगे जिनसे इस सेवा का ख़र्च निकलता है — और एक भी ऐसा अनुरोध नहीं जो आपकी फ़ाइल साथ ले जा रहा हो। इस जोड़ी के पीछे jSquash है, तस्वीरों के संदर्भ कोडेक के WebAssembly संस्करण; आपका ब्राउज़र इसे एक बार उतारता है और फिर सहेज कर रखता है।
हाँ। न खाता, न वॉटरमार्क, और न कोई रोज़ का कोटा जो ख़त्म हो: यह आपकी अपनी मशीन पर चलता है, इसलिए आप जितनी बार चाहें लौट सकते हैं। ब्राउज़र 100 MB तक की फ़ाइलें सँभालता है, एक बार में 100। jSquash आपकी अपनी मशीन पर उतरता है और वहीं चलता है — इसीलिए उस पर कोई गिनती नहीं है।
JXL कंप्रेस करता है, इसलिए कुछ डेटा जाता है। तयशुदा सेटिंग पर यह पकड़ में नहीं आता; पक्का करना हो तो गुणवत्ता बढ़ा दीजिए। सिर्फ़ पहला पन्ना बदला जाता है: कई पन्नों वाली TIFF का बाक़ी हिस्सा साथ नहीं जाता।
JXL में कैप्शन, क्रेडिट और कीवर्ड वाले IPTC फ़ील्ड और GPS निर्देशांक के लिए जगह नहीं है, इसलिए वह TIFF फ़ाइल से आगे नहीं जाता। असली फ़ाइल फेंकने से पहले यह देख लेना काम आता है — और अगर फेंकना ही मक़सद था, तो यह जान लेना काम आता है।
TIFF में CMYK हो सकता है; JXL RGB में काम करता है। जो फ़ाइल प्रेस के लिए तैयार खड़ी थी वह स्क्रीन के रंग में चली जाती है, और छपाई की धारा में रंग-पृथक्करण दोबारा बनाना पड़ेगा।
पारदर्शिता बनी रहती है। TIFF और JXL — दोनों अल्फ़ा चैनल सँभालते हैं: काटा हुआ हिस्सा कटा ही रहता है और उसके पीछे कुछ भरा नहीं जाता।
इस पेज पर TIFF और JXL के बारे में जो कहा गया है, वह जाँचा जा सकता है, और ये रहे वे दस्तावेज़ जो उसे तय करते हैं।