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

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

इसलिए नतीजे को अनुमान समझिए, नतीजा नहीं। भरोसा करने से पहले इसे मूल तस्वीर से मिलाकर पढ़ लेना ही सबसे उपयोगी आदत है।

यहाँ हर दूसरा इमेज रास्ता तस्वीर को पहले पिक्सेल में खोलता है। यह रास्ता ऐसा नहीं करता — फ़ाइल वैसी ही पहचानने वाले इंजन तक जाती है, क्योंकि उसका अपना अलग लोडर है। उस इंजन में BMP, JPEG, PNG, PBM, WebP और सामान्य GIF के डिकोडर बने हुए हैं — JPEG XL इनमें नहीं है।

इसलिए JXL सीधे यहाँ डालने पर कुछ वापस नहीं आता, और यह किसी ब्राउज़र का सवाल नहीं है — इंजन का अपना WebAssembly कोर ही JPEG XL पढ़ना नहीं जानता।

JPEG XL से PNG बनाने वाला रास्ता अपना अलग WebAssembly डिकोडर साथ लाता है, ब्राउज़र से कुछ नहीं माँगता — इसलिए वह हमेशा एक जैसा काम करता है। पहले उसी से PNG बना लीजिए, फिर उस PNG से टेक्स्ट निकालिए।

PNG यहाँ बीच की फ़ाइल है — यह लॉसलेस है, इसलिए पहचान को चाहिए हर रेखा उसी में बची रहती है, जबकि JPEG अक्षरों की शक्ल को दोबारा संकुचित कर सकता था। टेक्स्ट मिल जाने के बाद यह बीच वाली PNG मिटाई जा सकती है।

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

भाषा बदलने के लिए बदलाव दोबारा चलाना पड़ता है, इसलिए बदलने से पहले ही सही भाषा चुन लेना बेहतर है।

हर अक्षर के पीछे जितने ज़्यादा पिक्सेल हों, पहचान उतनी ही सही आती है। 300 डीपीआई पर बना कोई स्कैन आम तौर पर काफ़ी होता है; दूर से खींची गई तस्वीर या किसी चैट ऐप से गुज़रकर छोटी हुई तस्वीर अक्सर काफ़ी नहीं होती।

बाद में तस्वीर को बड़ा करने से यह ठीक नहीं होता — बड़ा करना नई जानकारी नहीं जोड़ता, अक्षरों की धार को और धुँधला ही करता है। सही जवाब ऊँचे रिज़ॉल्यूशन पर दोबारा स्कैन करना है, फ़ाइल को बाद में बड़ा करना नहीं।

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

ख़ाली पंक्तियाँ और लाइन-ब्रेक ठीक वैसे ही रखे जाते हैं जैसे पहचाने गए — उन्हें साफ़ करना किसी कविता या पते के ढाँचे को बिगाड़ सकता था, इसलिए इंजन ने जो देखा वही मिलता है।

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

इसलिए जो कुछ आगे इस्तेमाल होना है, उसे पढ़कर मिलाना ज़रूरी है — किसी अनुच्छेद पर सरसरी नज़र ग़लती पकड़ लेती है, पर किसी खाता संख्या को अक्षर-दर-अक्षर जाँचना ही असली सुरक्षा है।

पहचानने वाला इंजन, उसका WebAssembly कोर और चारों भाषा-मॉडल — सब इसी साइट के अपने पते से परोसे जाते हैं, किसी सार्वजनिक CDN से नहीं। लाइब्रेरी का तयशुदा तरीक़ा तीनों को किसी और सर्वर से माँगना था, और उसे यहाँ जान-बूझकर बदला गया है।

इसका मतलब है कि किसी दस्तावेज़ को पढ़ने की बात भी किसी बाहरी नेटवर्क को पता नहीं चलती, भले ही तस्वीर वैसे भी कहीं न जाए।

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

एक पन्ना सेकंडों में तैयार होता है। फ़ोल्डर बदलते समय हर फ़ाइल इतना ही समय लेती है, एक के बाद एक, कोई समांतर प्रोसेसिंग नहीं।

इंजन, उसका कोर और मॉडल — तीनों इसी टैब में चलते हैं, तस्वीर कभी अपलोड नहीं होती। PNG बनाने वाला पहला क़दम भी ठीक इसी तरह चलता है।

जो कुछ इस रास्ते पढ़ा जाता है वह अक्सर सैलरी स्लिप, चिट्ठी या अनुबंध होता है — यहाँ मिटाने को कुछ नहीं है, क्योंकि कभी कहीं भेजा ही नहीं गया।