गहन विश्लेषण

OCR की अंदरूनी कार्यप्रणाली: कंप्यूटर इमेज से टेक्स्ट पढ़ना कैसे सीखते हैं

koboshiCo-founder
·24 मिनट पढ़ें
OCR की अंदरूनी कार्यप्रणाली: कंप्यूटर इमेज से टेक्स्ट पढ़ना कैसे सीखते हैं
सारांश

कंप्यूटर के लिए, किसी दस्तावेज़ की फोटो केवल रंगीन पिक्सल की एक ग्रिड होती है। उन पिक्सल को खोजने योग्य और संपादन योग्य टेक्स्ट में बदलने के लिए इमेज प्रीप्रोसेसिंग, लेआउट विश्लेषण और अक्षर पहचान तक फैली एक पाइपलाइन की आवश्यकता होती है — हर चरण के पीछे दशकों का शोध है। यह गाइड Otsu की बाइनराइज़ेशन से लेकर Vision Transformers तक OCR की यात्रा कराती है।

किसी भी इमेज को hex editor में खोलें। सड़क के साइनबोर्ड की फोटो, एक रसीद, किसी PDF का स्क्रीनशॉट। ऑफ़सेट शून्य पर आपको फ़ॉर्मेट हैडर मिलता है। कुछ किलोबाइट आगे, आप पिक्सल डेटा तक पहुँचते हैं: RGB में तीन बाइट प्रति पिक्सल, संख्याओं की एक ग्रिड जहाँ (128, 52, 19) शायद ईंट की दीवार है और (240, 238, 220) शायद कागज़ है। उस ग्रिड में कहीं एक स्टॉप साइन है जिस पर "STOP" शब्द लाल बैकग्राउंड पर सफ़ेद Highway Gothic फ़ॉन्ट में लिखा है। एक इंसान चार अक्षर देखता है। कंप्यूटर लाल-समीप पिक्सल मानों का 47 x 19 का क्षेत्र देखता है जहाँ R चैनल 200 के आसपास है और G और B 40 से नीचे हैं। उस क्षेत्र को "STOP" स्ट्रिंग से मैप करना ही ऑप्टिकल कैरेक्टर रिकॉग्निशन (OCR) है, और यह 1929 में Gustav Tauschek द्वारा पहली रीडिंग मशीन के पेटेंट के बाद से एक खुली शोध समस्या रही है।

OCR भ्रामक रूप से कठिन है क्योंकि पढ़ना भ्रामक रूप से आसान है। एक छह साल का बच्चा दर्जनों फ़ॉन्ट में, अलग-अलग आकारों में, असमान रोशनी में, थोड़ा घुमाए गए, आंशिक रूप से ढके हुए और पेंसिल से लिखे गए 'A' अक्षर को पहचान सकता है। कंप्यूटर को एक पाइपलाइन चाहिए: इमेज साफ़ करें, टेक्स्ट क्षेत्र खोजें, अक्षरों या ग्लिफ़ अनुक्रमों को खंडित (segment) करें और प्रत्येक को वर्गीकृत (classify) करें। इनमें से हर चरण की अपनी विफलता की स्थिति है, और विफलताएँ जुड़ती जाती हैं।

OCR को क्या कठिन बनाता है

मूल समस्या वर्गीकरण (classification) नहीं है। पहले से खंडित 28 x 28 पिक्सल की अक्षर इमेज को 62 वर्गों (A–Z, a–z, 0–9) में वर्गीकृत करना एक ऐसा कार्य है जिसे 1990 के दशक का LeNet 99% सटीकता पर हल कर सकता है। कठिन हिस्सा वह सब कुछ है जो classifier से पहले आता है।

फ़ॉन्ट विविधता। अक्षर "g" के कम से कम चार सामान्य संरचनात्मक रूप हैं: एक-मंज़िला (हस्तलिखित), दो-मंज़िला (अधिकांश सेरिफ़ फ़ॉन्ट), Helvetica में लूप-टेल, और Futura में ओपन-टेल। Tahoma पर प्रशिक्षित मॉडल Univers को मापने योग्य दर पर ग़लत पढ़ेगा। वास्तविक दुनिया का OCR सैकड़ों टाइपफ़ेस और हस्तलेखन को कवर करता है, जिसकी कोई सुसंगत स्ट्रोक टोपोलॉजी ही नहीं है।

ज्यामितीय विकृति। दस्तावेज़ों की फोटो शायद ही कभी फ़्लैटबेड स्कैन होती हैं। रसीद की फ़ोन से ली गई फोटो में परिप्रेक्ष्य झुकाव (perspective skew), वक्रता और असमान पैमाना आ जाता है। किताब की जिल्द के पास का टेक्स्ट मुड़ जाता है। व्हाइटबोर्ड की फोटो में फ़ोटोग्राफ़र की छाया आ जाती है। 10-डिग्री का झुकाव मानक बेंचमार्क पर Tesseract की सटीकता को ~97% से घटाकर 85% से नीचे कर देता है। डीस्क्यूइंग एल्गोरिदम (Hough लाइन डिटेक्शन, Radon ट्रांसफ़ॉर्म, प्रोजेक्शन प्रोफ़ाइल विश्लेषण) उस नुकसान का कुछ हिस्सा वसूल करते हैं, लेकिन पूरा नहीं।

प्रकाश और शोर। असमान प्रकाश एक समान बैकग्राउंड को ग्रेडिएंट में बदल देता है, जो ग्लोबल थ्रेशोल्डिंग को तोड़ देता है। JPEG कम्प्रेशन आर्टिफ़ैक्ट नुकीले किनारों के आसपास रिंगिंग पैदा करते हैं। OCR की भाषा में, इसका मतलब अक्षर स्ट्रोक के आसपास रिंगिंग है। कम रोशनी वाले सेंसर का सॉल्ट-एंड-पेपर शोर सफ़ेद स्थान को गहरे पिक्सल से भर देता है जो विराम चिह्न जैसे लगते हैं। फोटोकॉपी की फोटोकॉपी पतले स्ट्रोक को आपस में मिला देती है, "rn" को "m" और "cl" को "d" में बदल देती है।

लेआउट जटिलता। दस्तावेज़ों में कॉलम, कैप्शन, तालिकाएँ, हैडर, फ़ुटनोट और साइडबार होते हैं। टेक्स्ट इमेज के चारों ओर बहता है। कुछ भाषाएँ दाएँ से बाएँ चलती हैं। अन्य एक ही पैराग्राफ़ में दिशाएँ मिलाती हैं। पढ़ने का क्रम पहचानना (कौन सा टेक्स्ट ब्लॉक किसके बाद आता है) पहचान से अलग एक लेआउट विश्लेषण समस्या है, और इसे ग़लत करने पर आउटपुट गड़बड़ा जाता है, भले ही हर अक्षर सही वर्गीकृत हुआ हो।

संदर्भगत अस्पष्टता। केवल पिक्सल पैटर्न को देखते हुए, "0" (अंक शून्य), "O" (बड़ा अक्षर O) और "o" (छोटा अक्षर o) कई sans-serif फ़ॉन्ट में एक जैसे होते हैं। "1", "l", "I" और "|" एक ऊर्ध्वाधर स्ट्रोक साझा करते हैं। रिज़ॉल्यूशन एक और आयाम जोड़ता है: 12 पिक्सल ऊँचाई पर, "e" और "c" तीन पिक्सल चौड़े एक क्षैतिज स्ट्रोक से भिन्न होते हैं। मानव पाठक संदर्भ से इन्हें हल करते हैं। मशीनों को वही निर्णय लेने के लिए भाषा मॉडल — सांख्यिकीय या सीखे हुए — की आवश्यकता होती है।

पारंपरिक OCR पाइपलाइन

डीप लर्निंग से पहले, OCR हाथ से डिज़ाइन किए गए चरणों का एक अनुक्रम था। हर चरण स्वतंत्र रूप से विकसित किया जाता था, अक्सर अलग-अलग शोध समूहों द्वारा, और एक विशिष्ट विकृति के लिए ट्यून किया जाता था। पाइपलाइन कुछ इस तरह दिखती थी:

कच्ची इमेज -> प्रीप्रोसेसिंग -> बाइनराइज़ेशन -> डीस्क्यू -> लेआउट विश्लेषण
  -> अक्षर विभाजन -> फ़ीचर निष्कर्षण -> वर्गीकरण
  -> पोस्ट-प्रोसेसिंग (भाषा मॉडल) -> टेक्स्ट आउटपुट

प्रीप्रोसेसिंग और बाइनराइज़ेशन

रंगीन इमेज को ग्रेस्केल में बदला जाता है। शोर में कमी थ्रेशोल्डिंग से पहले सिग्नल को चिकना करती है। मीडियन फ़िल्टर सॉल्ट-एंड-पेपर शोर को संभालता है। गॉसियन ब्लर सेंसर शोर को संभालता है। जब किनारों का संरक्षण महत्वपूर्ण हो तो बाइलैटरल फ़िल्टर का उपयोग होता है।

बाइनराइज़ेशन ग्रेस्केल इमेज को सफ़ेद बैकग्राउंड पर काले टेक्स्ट में बदलता है। मानक एल्गोरिदम Otsu की विधि (1979) है: यह उस थ्रेशोल्ड की विस्तृत खोज करता है जो अग्रभूमि (foreground) और पृष्ठभूमि (background) पिक्सल वितरणों के बीच अंतर-वर्ग विचरण (intra-class variance) को न्यूनतम करता है। Otsu एक बाइमॉडल हिस्टोग्राम मानता है (टेक्स्ट पिक्सल एक तीव्रता पर, बैकग्राउंड पिक्सल दूसरी पर), जो नियंत्रित प्रकाश में फ़्लैटबेड स्कैन के लिए काम करता है और छाया वाली फ़ोन फोटो के लिए विफल हो जाता है। स्थानीय अनुकूली विधियाँ (Sauvola, Niblack) पड़ोस के आँकड़ों के आधार पर प्रति पिक्सल अलग थ्रेशोल्ड की गणना करती हैं, जो किनारों के पास आर्टिफ़ैक्ट की कीमत पर असमान प्रकाश को संभालती हैं।

डीस्क्यू और लेआउट विश्लेषण

दस्तावेज़ का झुकाव रेखाएँ खोजकर पता लगाया जाता है: या तो किनारे के पिक्सल पर Hough ट्रांसफ़ॉर्म द्वारा, या प्रोजेक्शन प्रोफ़ाइल विश्लेषण द्वारा जहाँ दस्तावेज़ को कोणों की एक श्रेणी में घुमाया जाता है और सबसे तेज़ क्षैतिज प्रोजेक्शन शिखरों वाला कोण चुना जाता है। झुकाव कोण ज्ञात होने पर, एक affine ट्रांसफ़ॉर्म इमेज को वापस घुमाता है।

लेआउट विश्लेषण पृष्ठ को टेक्स्ट ब्लॉकों में विभाजित करता है। क्लासिक दृष्टिकोण connected-component analysis (CCA) चलाकर अग्रभूमि पिक्सल के गुच्छे खोजता है, उन्हें निकटता के आधार पर शब्दों में समूहित करता है, फिर शब्दों को पंक्तियों में और पंक्तियों को ब्लॉकों में। XY-cut एल्गोरिदम क्षैतिज और ऊर्ध्वाधर प्रोजेक्शन के साथ सफ़ेद स्थान के अंतराल खोजकर पृष्ठ को पुनरावर्ती रूप से विभाजित करता है, क्षेत्रों का एक वृक्ष बनाता है। आधुनिक कार्यान्वयन हाइब्रिड दृष्टिकोण का उपयोग करते हैं: प्रारंभिक गुच्छों के लिए CCA, फिर प्रत्येक गुच्छे को टेक्स्ट, इमेज, तालिका या विभाजक के रूप में वर्गीकृत करने के लिए एक सीखा हुआ मॉडल।

अक्षर विभाजन (Character Segmentation)

मशीन-मुद्रित टेक्स्ट के लिए, विभाजन का अर्थ शब्द इमेज को अलग-अलग अक्षरों में काटना है। ऊर्ध्वाधर प्रोजेक्शन प्रोफ़ाइल (प्रति कॉलम अग्रभूमि पिक्सल गिनती का हिस्टोग्राम) अक्षर केंद्रों पर शिखर और अक्षर सीमाओं पर घाटियाँ उत्पन्न करता है। यह तब तक काम करता है जब तक दो अक्षर स्पर्श न करें, या एक अक्षर में असंबद्ध भाग न हों ("i", "j", ":", "%"). अति-विभाजन (बहुत आक्रामक रूप से काटना) और फिर classifier के आत्मविश्वास के आधार पर विलय एक समाधान है। दूसरा समाधान विभाजन को पूरी तरह छोड़कर पूरे शब्दों को पहचानना है, जो आधुनिक अनुक्रम-आधारित विधियाँ करती हैं।

फ़ीचर निष्कर्षण और वर्गीकरण

एक बार जब आपके पास अक्षर इमेज है, तो आपको classifier के लिए इसे संख्यात्मक रूप से वर्णित करना होगा। डीप-लर्निंग-पूर्व फ़ीचर में शामिल थे:

  • कच्चे पिक्सल मान एक समतल वेक्टर के रूप में (सरल, अनुवाद और पैमाने के प्रति नाज़ुक)
  • Zoning: अक्षर बाउंडिंग बॉक्स को N x N ग्रिड में विभाजित करें, प्रति सेल अग्रभूमि पिक्सल गिनें, गिनती को फ़ीचर के रूप में उपयोग करें
  • ग्रेडिएंट-आधारित फ़ीचर (HOG): oriented gradients का हिस्टोग्राम किनारे की दिशाओं को पकड़ता है, छोटे अनुवादों के प्रति मज़बूत
  • Scale-invariant feature transform (SIFT): स्केल, घुमाव और प्रकाश के प्रति अपरिवर्तनीय कीपॉइंट का पता लगाता और वर्णित करता है

classifier आमतौर पर RBF कर्नेल वाली support vector machine (SVM) होती थी, जो प्रति फ़ॉन्ट हजारों लेबल वाली अक्षर इमेज पर प्रशिक्षित होती थी। एक अच्छी तरह से ट्यून की गई SVM + HOG पाइपलाइन साफ़ मुद्रित टेक्स्ट पर ~98% प्रति-अक्षर सटीकता प्राप्त कर सकती थी। शोरग्रस्त, झुके हुए या हस्तलिखित इनपुट पर वही पाइपलाइन 70-80% तक गिर जाती थी।

Tesseract: HP Labs से LSTM तक

Tesseract संदर्भ ओपन-सोर्स OCR इंजन है। यह 1980 के दशक में HP Labs Bristol में एक PhD परियोजना के रूप में शुरू हुआ, 2005 में ओपन-सोर्स किया गया और 2006 से Google द्वारा अनुरक्षित है। इसकी वास्तुकला स्पष्ट रूप से दो युगों में विभाजित है।

संस्करण 3: क्लासिक पाइपलाइन

Tesseract 3 ने कुछ नवाचारों के साथ पारंपरिक पाइपलाइन लागू की। इसका लेआउट विश्लेषण एक tab-stop डिटेक्शन एल्गोरिदम का उपयोग करता था जो शब्द बाउंडिंग बॉक्स को संरेखित करके कॉलम सीमाएँ खोजता था — 1990 के दशक में HP जिस प्रकार के दस्तावेज़ स्कैन करता था, उसके लिए ट्यून की गई एक व्यावहारिक ह्यूरिस्टिक। अक्षर विभाजन chopper/associator तर्क का उपयोग करता था: chopper शब्द इमेज को उम्मीदवार कट्स में अति-विभाजित करता था, और associator classifier के आत्मविश्वास और एक शब्दकोश का उपयोग करके तय करता था कि कौन से कट्स को मिलाना है।

classifier दो-पास प्रणाली था। पहला पास (स्टैटिक classifier) खंडित गुच्छों को प्रोटोटाइप (क्लस्टर किए गए प्रशिक्षण नमूने) से nearest-neighbor खोज का उपयोग करके मिलाता था। दूसरा पास (अनुकूली classifier) दस्तावेज़ पर ही फ़ाइन-ट्यून करता था, उस इमेज में प्रयुक्त विशिष्ट फ़ॉन्ट सीखता था। अनुकूली classifier को प्रभावी होने के लिए लगभग एक पृष्ठ टेक्स्ट की आवश्यकता होती थी, यही कारण है कि Tesseract 3 सड़क चिह्नों और कैप्शन जैसी एकल-शब्द इमेज पर खराब प्रदर्शन करता था।

Tesseract 3 .traineddata फ़ाइलें वितरित करता था: प्रोटोटाइप क्लस्टर, अक्षर सेट परिभाषाएँ, शब्द-आवृत्ति शब्दकोश और भ्रमित करने वाले अक्षर जोड़ों को मैप करने वाली unichar अस्पष्टता तालिका वाले संग्रह। एक नई भाषा को प्रशिक्षित करने के लिए Tesseract को ग्राउंड-ट्रुथ ट्रांसक्रिप्शन के साथ जोड़ीदार टेक्स्ट इमेज खिलानी पड़ती थी, हर अक्षर को बॉक्स करना पड़ता था और प्रशिक्षण उपकरण चलाने पड़ते थे। प्रति भाषा कई घंटों की प्रक्रिया।

संस्करण 4/5: LSTM ने पाइपलाइन को बदला

Tesseract 4 (2018) ने पूरे पहचान पथ को एकल LSTM न्यूरल नेटवर्क से बदल दिया। LSTM टेक्स्ट लाइन इमेज के ऊर्ध्वाधर स्लाइस के अनुक्रम पर काम करता है, हर स्लाइस एक पिक्सल चौड़ी और पूरी टेक्स्ट-लाइन ऊँचाई की। हर स्लाइस बाइडायरेक्शनल LSTM लेयर्स के स्टैक में डाली जाती है। आउटपुट अक्षर संभावनाओं का अनुक्रम है जिसमें Connectionist Temporal Classification (CTC) लॉस है जो परिवर्तनीय-लंबाई आउटपुट अनुक्रम को ग्राउंड-ट्रुथ टेक्स्ट से संरेखित करता है, बिना पूर्व-खंडित अक्षर स्थितियों की आवश्यकता के।

LSTM मॉडल chopper/associator तंत्र के बिना परिवर्तनीय-चौड़ाई वाले अक्षरों, स्पर्श करने वाले अक्षरों और फ़ॉन्ट विविधता को संभालता है। यह अभी भी टेक्स्ट लाइनें खोजने के लिए Tesseract के पुराने लेआउट विश्लेषण पर निर्भर करता है, लेकिन लाइन पहचान एंड-टू-एंड न्यूरल है। ICDAR 2017 बेंचमार्क पर, Tesseract 4 ने मुद्रित अंग्रेज़ी पर 4.4% अक्षर त्रुटि दर (CER) हासिल की, जबकि Tesseract 3 के लिए यह 7.2% थी। प्रशिक्षण प्रक्रिया पुराने बॉक्सिंग टूल से हटकर टेक्स्ट लाइनों को ट्रांसक्रिप्शन के साथ जोड़ने पर आ गई। अभी भी पर्यवेक्षित, लेकिन प्रति अक्षर के बजाय प्रति पंक्ति एक लेबल के साथ।

.traineddata फ़ॉर्मेट को LSTM मॉडल भार (कई मेगाबाइट) को पुराने डेटा (शब्दकोश, unichar तालिकाएँ) के साथ एकल फ़ाइल में रखने के लिए विस्तारित किया गया। स्क्रैच से एक तेज़ LSTM मॉडल को प्रशिक्षित करने में लगभग 100 अक्षर वर्गों वाली लैटिन-लिपि भाषा के लिए आधुनिक GPU पर लगभग 24 घंटे लगते हैं; बड़े अक्षर सेट के कारण CJK भाषाओं में अधिक समय लगता है।

सटीकता की विशेषताएँ

Tesseract 5 ने बड़े प्रशिक्षण कॉर्पस और बेहतर डिफ़ॉल्ट पैरामीटर के साथ संस्करण 4 पर सुधार किया, लेकिन वास्तुकला अपरिवर्तित है। सटीकता इनपुट पर बहुत निर्भर है:

इनपुट स्थितिTesseract 4 CERTesseract 5 CER
साफ़ 300 DPI स्कैन, अंग्रेज़ी, एकल कॉलम2.1%1.8%
150 DPI मोबाइल फोटो, अंग्रेज़ी5.8%4.9%
मिश्रित फ़ॉन्ट के साथ साफ़ स्कैन7.3%6.1%
ऐतिहासिक दस्तावेज़ (अनियमित टाइप)18.4%16.2%
हस्तलेखन (IAM डेटासेट)28.7%26.3%

LSTM मॉडल संस्करण 3 की अधिकांश फ़ॉन्ट-संवेदनशीलता समस्याओं को हटा देता है, लेकिन इंजन अभी भी कम रिज़ॉल्यूशन (200 DPI से नीचे, LSTM का पिक्सल-स्लाइस इनपुट स्ट्रोक विवरण खो देता है), हस्तलिखित टेक्स्ट (मॉडल मुद्रित फ़ॉन्ट पर प्रशिक्षित था; हस्तलेखन की स्ट्रोक सांख्यिकी मौलिक रूप से भिन्न है), और जटिल लेआउट (लेआउट विश्लेषण अभी भी पुराना कोड पथ है, न्यूरल नहीं) पर खराब प्रदर्शन करता है।

आधुनिक डीप लर्निंग दृष्टिकोण

अकादमिक रूप से, OCR ने 2019 के आसपास CTC + LSTM प्रतिमान को पार कर लिया। तीन वास्तुकलाएँ अब साहित्य पर हावी हैं।

CRNN + CTC

Convolutional Recurrent Neural Network (CRNN), जो 2015 में Shi et al. द्वारा प्रकाशित हुई, CNN फ़ीचर एक्सट्रैक्टर को RNN अनुक्रम मॉडल और CTC डिकोडिंग के साथ जोड़ती है। CNN इमेज से स्थानिक फ़ीचर निकालता है, अनिवार्य रूप से वह सीखता है जो Tesseract में LSTM को हाथ से दिया जाता था (ऊर्ध्वाधर स्लाइस प्रतिनिधित्व)। RNN निकाले गए फ़ीचर में अनुक्रम निर्भरताओं को मॉडल करता है। CTC संरेखण को संभालता है। CRNN-CTC मानक बेसलाइन बन गई: एंड-टू-एंड प्रशिक्षण योग्य, अच्छा सामान्यीकरण, तेज़ अनुमान (GPU पर ~20 ms प्रति पंक्ति)।

अटेंशन-आधारित एन्कोडर-डिकोडर

अटेंशन-आधारित मॉडल ने मशीन अनुवाद से seq2seq प्रतिमान को अनुकूलित किया। एक CNN या विज़न एन्कोडर इमेज का फ़ीचर मैप बनाता है। एक RNN डिकोडर एक बार में एक अक्षर आउटपुट टेक्स्ट उत्पन्न करता है, हर कदम पर फ़ीचर मैप के प्रासंगिक स्थानिक क्षेत्रों पर ध्यान (attend) देता है। अटेंशन तंत्र CTC की मोनोटोनिक बाधा को हटाता है: जब भाषा मॉडल दोहराए गए पैटर्न की अपेक्षा करता है तो डिकोडर इमेज के पहले के हिस्सों पर वापस जा सकता है, हालाँकि यह लचीलापन अपठनीय इनपुट के लिए हैलुसिनेशन (hallucination) जोखिम भी पेश करता है। अटेंशन-आधारित डिकोडर साफ़ मुद्रित अंग्रेज़ी पर ~1.5-3% CER प्राप्त करते हैं, लंबे अनुक्रमों और अनियमित लेआउट पर केवल-CTC मॉडल से बेहतर प्रदर्शन करते हैं।

Vision Transformers (TrOCR, Donut)

TrOCR (Microsoft, 2021) ने Transformer वास्तुकला को OCR पर लागू किया। इमेज को पैच में विभाजित किया जाता है, ViT (Vision Transformer) एन्कोडर द्वारा एन्कोड किया जाता है, और टेक्स्ट को एक Transformer टेक्स्ट डिकोडर द्वारा autoregressive रूप से डिकोड किया जाता है। यह एक मानक मल्टीमॉडल मॉडल की वास्तुकला है, जो विशेष रूप से OCR के लिए प्रशिक्षित है। TrOCR बिना किसी CNN प्रीप्रोसेसिंग, स्पष्ट भाषा मॉडल या अक्षर-स्तरीय विभाजन के मुद्रित टेक्स्ट पर अत्याधुनिक परिणाम प्राप्त करता है (साफ़ स्कैन पर 1% से कम CER)।

Donut (NAVER, 2022) ने इस दृष्टिकोण को दस्तावेज़ समझ तक विस्तारित किया: इनपुट एक पूर्ण दस्तावेज़ इमेज है, और आउटपुट दृश्य फ़ीचर से सीधे निकाला गया संरचित JSON है, जो OCR -> NLP पाइपलाइन को पूरी तरह छोड़ देता है। यह OCR और दस्तावेज़ पार्सिंग के बीच की रेखा को इस तरह धुंधला करता है जो वास्तविक अनुप्रयोगों के लिए मायने रखता है: इनवॉइस का कुल, पासपोर्ट नंबर या शोध पत्र से तालिका निकालना OCR + regex + ह्यूरिस्टिक के बजाय एकल मॉडल कॉल बन जाता है।

प्रदर्शन तुलना (मुद्रित अंग्रेज़ी, साफ़ 300 DPI)

विधिCERअनुमान गति (पंक्तियाँ/सेकंड)आवश्यक प्रशिक्षण डेटा
Tesseract 3 (क्लासिक)7.2%~2 (CPU)~100K अक्षर इमेज
Tesseract 5 (LSTM)1.8%~15 (CPU)~500K टेक्स्ट पंक्तियाँ
CRNN + CTC2.5%~120 (GPU)~2M टेक्स्ट पंक्तियाँ
Attention seq2seq1.8%~60 (GPU)~2M टेक्स्ट पंक्तियाँ
TrOCR (ViT + decoder)0.8%~20 (GPU)~10M टेक्स्ट पंक्तियाँ
Donut (ViT + decoder)1.2%~15 (GPU)~12M दस्तावेज़ इमेज

Tesseract और सर्वश्रेष्ठ Transformer मॉडलों के बीच का अंतर बेंचमार्क पर वास्तविक है। व्यवहार में, अंतर कम हो जाता है क्योंकि अधिकांश तैनात प्रणालियाँ Tesseract को साफ़, अच्छी रोशनी वाला, 300 DPI इनपुट देती हैं, और उस इनपुट पर, 1.8% CER का मतलब हर 55 अक्षरों में एक ग़लत अक्षर है। खोज अनुक्रमण के लिए स्वीकार्य, कानूनी दस्तावेज़ ट्रांसक्रिप्ट के लिए कम।

गैर-अंग्रेज़ी OCR: यह अधिक कठिन क्यों है

अंग्रेज़ी OCR एक हल की गई समस्या है। 26 बड़े अक्षरों, 26 छोटे अक्षरों, 10 अंकों और कुछ विराम चिह्नों का अक्षर सेट लगभग 70 वर्ग देता है। एक बहु-वर्ग वर्गीकरण समस्या जो 1990 के दशक के LeNet की क्षमता में आराम से है। दुनिया की बाकी लेखन प्रणालियाँ कम क्षमाशील हैं।

CJK: अक्षर सेट विस्फोट

चीनी, जापानी और कोरियाई (CJK) अकेले अक्षर सेट के आकार के कारण सबसे कठिन OCR चुनौती प्रस्तुत करते हैं। सरलीकृत चीनी लगभग 3,500 सामान्य अक्षर और सामान्य टेक्स्ट में 6,000+ का उपयोग करता है। पारंपरिक चीनी एक और हज़ार भिन्न रूप जोड़ता है। जापानी एक ही वाक्य में दो शब्दांश लिपियों (हीरागाना, काताकाना: 46 अक्षर प्रत्येक) को ~2,000 सामान्य कांजी और लैटिन अक्षरांकों के साथ मिलाता है। कोरियाई हंगुल ध्वन्यात्मक रूप से नियमित है (24 मूल अक्षर जो शब्दांश खंडों में संयोजित होते हैं), लेकिन दृष्टिगत रूप से सघन: एक खंड में लगभग दो लैटिन अक्षरों के बराबर स्थान में छह व्यक्तिगत जामो घटक तक समा सकते हैं।

CJK OCR प्रणाली पहचान को 70-तरफ़ा वर्गीकरण के रूप में नहीं मान सकती। यह जापानी के लिए 4,000-तरफ़ा, सरलीकृत चीनी के लिए 6,000-तरफ़ा और पारंपरिक चीनी के लिए न्यूनतम 10,000-तरफ़ा वर्गीकरण है। अकेले softmax आउटपुट लेयर में पूरे लैटिन-लिपि OCR मॉडल से अधिक पैरामीटर हैं। प्रशिक्षण डेटा की आवश्यकता अक्षर सेट के साथ बढ़ती है: स्वीकार्य सटीकता के लिए प्रति वर्ग ~100 लेबल वाले नमूने, इसलिए चीनी प्रशिक्षण सेट 600,000 टेक्स्ट-लाइन इमेज से शुरू होते हैं।

Tesseract CJK traineddata फ़ाइलें प्रदान करता है (chi_sim, chi_tra, jpn, kor), लेकिन वे लैटिन मॉडलों से काफ़ी बड़ी हैं। chi_sim.traineddata ~50 MB है जबकि eng.traineddata ~15 MB है, और पहचान धीमी है क्योंकि आउटपुट स्पेस बड़ा है। साफ़ मुद्रित CJK टेक्स्ट पर सटीकता Tesseract 5 के लिए 2-5% CER पर चलती है, समान परिस्थितियों में अंग्रेज़ी की त्रुटि दर से लगभग 2-3 गुना।

अरबी और दाएँ-से-बाएँ लिपियाँ

अरबी अक्षर सेट (28 अक्षर जिनके प्रासंगिक रूप शब्द में स्थिति के अनुसार बदलते हैं) के अलावा दो समस्याएँ जोड़ता है। पहला, यह दाएँ से बाएँ लिखी जाती है, इसलिए OCR इंजन को टेक्स्ट दिशा का पता लगाना और आउटपुट क्रम उलटना होगा। दूसरा, अरबी घसीट (cursive) है। शब्द के भीतर अक्षर बेसलाइन स्ट्रोक के माध्यम से जुड़ते हैं, जिससे विभाजन लैटिन और सिरिलिक लिपियों के अधिकतर असंबद्ध अक्षर रूपों की तुलना में स्वाभाविक रूप से कठिन हो जाता है। अरबी शब्द इमेज एक सतत गुच्छा है; अक्षर-आधारित विभाजन प्रभावी रूप से असंभव है, यही कारण है कि LSTM/CTC दृष्टिकोण (जो अक्षर विभाजन के बिना शब्द इमेज पर काम करता है) अंग्रेज़ी OCR की तुलना में अरबी OCR के लिए बड़ी सफलता था।

हिब्रू, उर्दू, फ़ारसी और पश्तो इन चुनौतियों का कोई न कोई संयोजन साझा करते हैं। Tesseract अरबी traineddata प्रदान करता है, लेकिन साफ़ मुद्रित टेक्स्ट पर सटीकता लगभग 5-8% CER है, समान परिस्थितियों में अंग्रेज़ी से लगभग 4 गुना खराब।

भारतीय लिपियाँ: संयुक्ताक्षर (conjunct) समस्या

देवनागरी (हिंदी, मराठी, नेपाली) और अन्य ब्राह्मी लिपियाँ एक विशिष्ट चुनौती प्रस्तुत करती हैं: लेखन इकाई अक्षर नहीं बल्कि संयुक्ताक्षर (conjunct) है, एक व्यंजन, एक स्वर संशोधक और कभी-कभी एक अतिरिक्त व्यंजन का दृष्टिगत रूप से जुड़ा समूह। यूनिकोड देवनागरी ब्लॉक में 128 कोड बिंदु हैं, लेकिन संभावित संयुक्ताक्षरों की संख्या 1,000 से अधिक है। "शिरोरेखा" (शब्द में अक्षरों को जोड़ने वाली क्षैतिज शीर्ष रेखा) विभाजन को कठिन बनाती है क्योंकि यह रेखा आसन्न अक्षरों को एक दृश्य इकाई में मिला देती है।

Tesseract का हिंदी traineddata (hin) सामान्य संयुक्ताक्षरों को कवर करता है लेकिन मुद्रित टेक्स्ट पर सटीकता अंग्रेज़ी से 3-4 गुना पीछे है। तमिल, तेलुगु, बंगाली और अन्य भारतीय लिपियाँ कम समर्थित हैं, कुछ में आधिकारिक traineddata फ़ाइलें पूरी तरह अनुपस्थित हैं। मूल कारण प्रशिक्षण डेटा की मात्रा है: हिंदी के लिए उच्च-गुणवत्ता वाली एनोटेटेड टेक्स्ट-लाइन इमेज लाखों में मौजूद हैं, जबकि कन्नड़ के लिए उपलब्ध डेटासेट दसियों हज़ार में हैं।

ऊर्ध्वाधर टेक्स्ट और मिश्रित-दिशा लेआउट

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

छोटी भाषाएँ और प्रशिक्षण डेटा

10 मिलियन से कम वक्ताओं वाली भाषाओं के लिए, उच्च-गुणवत्ता वाला OCR प्रशिक्षण डेटा शायद ही कभी मौजूद होता है। यूनिकोड कंसोर्टियम ने 150 से अधिक लिपियों को एन्कोड किया है, लेकिन Tesseract लगभग 120 भाषाओं के लिए traineddata वितरित करता है, जिनमें से कई साफ़ बैकग्राउंड पर मानक फ़ॉन्ट के साथ रेंडर किए गए सिंथेटिक टेक्स्ट से उत्पन्न होते हैं। सिंथेटिक डेटा सामान्य फ़ॉन्ट में मुद्रित टेक्स्ट के लिए काम करता है और उन भाषाओं के वास्तविक दस्तावेज़ों में पाए जाने वाले फ़ॉन्ट, कागज़ और मुद्रण गुणवत्ता के लिए विफल रहता है। 300 DPI पर सिंथेटिक Arial पर प्रशिक्षित मॉडल 1970 के दशक के टाइपराइटर से लिखे अम्हारिक दस्तावेज़ को नहीं पढ़ेगा।

Tesseract.js के साथ ब्राउज़र-साइड OCR

WebAssembly के आने तक ब्राउज़र में OCR चलाना अव्यावहारिक था। Tesseract.js Emscripten के माध्यम से Tesseract 5 (LSTM) को WebAssembly में संकलित करता है, C++ इंजन को JavaScript API में लपेटता है जो प्रति पहचान कार्य एक Web Worker चलाता है। इंजन, भाषा डेटा और worker स्टैटिक एसेट से लोड होते हैं। इमेज डेटा के लिए कोई सर्वर राउंड-ट्रिप नहीं।

API सतह सीधी है: एक या अधिक भाषा कोड के साथ एक worker बनाएँ, उसे एक इमेज दें, प्रति-अक्षर आत्मविश्वास स्कोर के साथ पहचाना गया टेक्स्ट वापस पाएँ। उपलब्ध CPU कोर द्वारा सीमित, कई worker समानांतर में चल सकते हैं। आमतौर पर उपभोक्ता लैपटॉप पर चार समानांतर पहचान कार्य, हाल के फ़ोन पर छह से आठ।

प्रदर्शन तीन कारकों से सीमित है। पहला, WebAssembly मूल गति के लगभग 50-70% पर चलता है; मूल Tesseract में 100 ms लेने वाली टेक्स्ट लाइन ब्राउज़र में लगभग 160 ms लेती है। दूसरा, traineddata फ़ाइलें नेटवर्क पर लोड होती हैं। eng.traineddata ~15 MB है, chi_sim.traineddata ~50 MB है, और पहचान शुरू होने से पहले दोनों को पूरी तरह डाउनलोड होना चाहिए। तीसरा, इमेज डिकोडिंग (JPEG/PNG/WebP/HEIC से कच्चा पिक्सल डेटा) ब्राउज़र के अंतर्निहित डिकोडर का उपयोग करता है, जो तेज़ हैं लेकिन फ़ॉर्मेट और डिवाइस के अनुसार भिन्न होते हैं।

गोपनीयता का लाभ संरचनात्मक है। क्लाइंट-साइड OCR का अर्थ है कि इमेज कभी डिवाइस नहीं छोड़ती। पासपोर्ट की फोटो, बैंक स्टेटमेंट, मेडिकल रिकॉर्ड। पिक्सल ब्राउज़र में डिकोड होते हैं, Textract समकक्ष Web Worker में चलता है, और परिणाम टेक्स्ट की एक स्ट्रिंग है जिसे उपयोगकर्ता कॉपी या सेव कर सकता है। कोई डेटा सेंटर इमेज को प्रोसेस नहीं करता। यह कोई सुविधा नहीं है; यह सर्वर की अनुपस्थिति है, जो स्पष्ट रूप से न देखने का वादा करने वाली गोपनीयता नीति से भिन्न है।

हमारा Image to Text टूल ठीक इसी स्टैक पर चलता है: LSTM पहचान के साथ Tesseract.js, समानांतर प्रोसेसिंग के लिए Web Workers, और 12 भाषाओं (अंग्रेज़ी, स्पेनिश, फ़्रेंच, जर्मन, पुर्तगाली, इतालवी, सरलीकृत और पारंपरिक चीनी, जापानी, कोरियाई, हिंदी और रूसी) के लिए traineddata। फोटो डालें, भाषाएँ चुनें, टेक्स्ट पाएँ। यह टूल JPEG, PNG, WebP, BMP और GIF इनपुट पढ़ता है, रिज़ॉल्यूशन-अवेयर प्री-स्केलिंग लागू करता है (सबसे लंबी साइड पर 3,000 पिक्सल से ऊपर की इमेज को पहचान विलंबता उचित रखने के लिए छोटा किया जाता है), और प्रति इमेज सादा टेक्स्ट आउटपुट करता है जिसमें प्रति-अक्षर आत्मविश्वास उपलब्ध होता है।

इमेज फ़ॉर्मेट का चुनाव व्यवहार में OCR गुणवत्ता को प्रभावित करता है। iPhones से HEIC फोटो, OCR से पहले JPEG में बदले जाने पर, टेक्स्ट किनारों के आसपास कम्प्रेशन आर्टिफ़ैक्ट प्राप्त कर लेते हैं जो पहचान सटीकता को कम करते हैं। HEIC को पहले PNG में बदलना (लॉसलेस, कोई क्वांटाइज़ेशन आर्टिफ़ैक्ट नहीं) उन तेज़ किनारों को संरक्षित करता है जिन पर LSTM निर्भर करता है। हमारे HEIC to JPG और HEIC to PNG कन्वर्टर इस प्रीप्रोसेसिंग चरण को सीधे ब्राउज़र में संभालते हैं। इसी तरह, कम रोशनी में ली गई फोटो थ्रेशोल्डिंग से पहले पूर्ण टोनल रेंज को संरक्षित करने वाले फ़ॉर्मेट में बदलने से लाभान्वित होती हैं: JPG to PNG दूसरी पीढ़ी के JPEG आर्टिफ़ैक्ट से बचता है जो JPEG स्रोत को पुनः एन्कोड करने पर जमा होते हैं।

ब्राउज़र OCR स्टैक थ्रूपुट पर GPU-त्वरित सर्वर-साइड मॉडलों के साथ प्रतिस्पर्धी नहीं है। 32 CPU कोर पर मूल C++ के साथ Tesseract चलाने वाला सर्वर हमेशा ब्राउज़र टैब से तेज़ रहेगा। यह गोपनीयता, शून्य बुनियादी ढाँचे और शून्य प्रति-अनुरोध लागत पर जीतता है। कुछ पृष्ठों, एक रसीद या कुछ साइनबोर्ड को स्कैन करने के लिए, 200 ms और 50 ms के बीच विलंबता का अंतर अदृश्य है।

OCR कहाँ जा रहा है

OCR ने 2022 के आसपास एक स्वतंत्र शोध क्षेत्र होना बंद कर दिया और व्यापक document AI और मल्टीमॉडल मॉडल स्पेस में विलय हो गया। तीन बदलाव चल रहे हैं।

मल्टीमॉडल LLM ज़ीरो-शॉट OCR के रूप में। GPT-4V, Claude और Gemini स्पष्ट OCR प्रशिक्षण के बिना इमेज से टेक्स्ट पढ़ सकते हैं। किसी दस्तावेज़ की फोटो दें और टेक्स्ट माँगें, और मॉडल उसे लौटा देता है। इसलिए नहीं कि इसमें समर्पित OCR हेड है, बल्कि इसलिए कि टेक्स्ट पहचान अरबों इमेज-टेक्स्ट जोड़ों पर प्रशिक्षण से उभरती है। गुणवत्ता असमान है। साफ़ मुद्रित अंग्रेज़ी पर, GPT-4V ~1% CER प्राप्त करता है, फ़ाइन-ट्यून किए गए TrOCR के तुलनीय। चीनी रसीदों की कम-रिज़ॉल्यूशन फोटो पर, यह Tesseract से बेहतर प्रदर्शन कर सकता है क्योंकि मॉडल संदर्भ का लाभ उठाता है (यह जानता है कि रसीद कैसी दिखती है और किन संख्याओं की अपेक्षा करनी है) बजाय केवल पिक्सल-स्तरीय साक्ष्य पर निर्भर रहने के। हस्तलेखन पर, यह फ़ाइन-ट्यून किए गए पहचानकर्ता से खराब है क्योंकि प्रशिक्षण वितरण में पर्याप्त हस्तलिखित इमेज शामिल नहीं थीं।

समझौता लागत और विलंबता है। OCR के लिए GPT-4V की API कॉल की लागत टोकन गिनती के आधार पर 1-3 सेंट प्रति पृष्ठ है और 1-3 सेकंड लेती है। Tesseract 100-500 ms में स्थानीय रूप से चलता है और प्रति पृष्ठ कुछ भी खर्च नहीं करता। 200-पृष्ठ के दस्तावेज़ को स्कैन करने के लिए, अंतर $2-6 और कई मिनट का वास्तविक समय बनाम शून्य और एक मिनट से कम है। एक बार के उपयोग (एक रसीद, एक व्हाइटबोर्ड फोटो) के लिए, मल्टीमॉडल मॉडल सरल और अक्सर अधिक सटीक है।

ऑन-डिवाइस अनुमान। सर्वर OCR के पीछे के मॉडल छोटे हो रहे हैं। ONNX Runtime Web क्वांटाइज़्ड CRNN और छोटे ViT मॉडल को WebGPU पर 50-100 ms प्रति टेक्स्ट लाइन पर ब्राउज़र में चलाता है। Apple का Vision फ़्रेमवर्क iOS और macOS के लिए ऑन-डिवाइस एक कॉम्पैक्ट OCR मॉडल शिप करता है, जो बिना नेटवर्क कॉल के VNRecognizeTextRequest के माध्यम से सुलभ है। "सर्वर GPU मॉडल" और "ब्राउज़र मॉडल" के बीच का अंतर कम हो रहा है क्योंकि दोनों एक ही वास्तुकला की सर्वोत्तम स्थिति पर अभिसरित हो रहे हैं: एक छोटा ViT एन्कोडर (~20-50M पैरामीटर) जिसमें हल्का डिकोडर है, INT8 या FP16 पर क्वांटाइज़्ड।

दस्तावेज़ समझ, केवल ट्रांसक्रिप्शन नहीं। OCR का आउटपुट एक स्ट्रिंग है। अधिकांश वास्तविक-दुनिया के कार्यों में उस स्ट्रिंग से संरचित जानकारी निकालना शामिल है: इनवॉइस नंबर, तिथियाँ, कुल राशि, नाम, पते। पारंपरिक दृष्टिकोण OCR को regex, named entity recognition और स्कीमा मैपिंग के साथ श्रृंखलाबद्ध करता है। हर चरण अपनी विफलता स्थितियों वाला एक अलग मॉडल है। एंड-टू-एंड दस्तावेज़ समझ मॉडल (Donut, LayoutLMv3, Pix2Struct) OCR को छोड़ते हैं और दस्तावेज़ इमेज को सीधे संरचित आउटपुट में मैप करते हैं। रसीदों पर फ़ाइन-ट्यून किया गया Donut मॉडल टेक्स्ट ट्रांसक्रिप्ट नहीं बनाता और फिर उसे पार्स नहीं करता। यह पिक्सल इनपुट से सीधे {"total": "42.50", "date": "2026-07-27", "vendor": "..."} उत्पन्न करता है। OCR चरण, वह भाग जिसके बारे में यह लेख है, एक अदृश्य कार्यान्वयन विवरण बन जाता है।

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

OCR दुनिया की अधिकांश भाषाओं और अधिकांश वास्तविक-दुनिया की इमेजिंग स्थितियों के लिए हल की गई समस्या नहीं है। यह साफ़, 300 DPI, अंग्रेज़ी, एकल-कॉलम, मशीन-मुद्रित टेक्स्ट के लिए हल की गई समस्या है — समस्या स्पेस का सबसे संकीर्ण और सबसे अच्छी तरह से वित्तपोषित हिस्सा। बाकी अभी भी खुला है।

और ब्लॉग पोस्ट्स पढ़ें