OCR स्कैन की गई PDF को कैसे पढ़ता है, और यह टूल Markdown क्यों लौटाता है

स्कैन की गई PDF पेजों को रास्टर इमेज के रूप में रखती है: टेक्स्ट की तस्वीरें, चुनने-योग्य अक्षर नहीं। OCR (ऑप्टिकल कैरेक्टर रिकग्निशन) पिक्सेल देखकर अंदाज़ा लगाता है कि कौन-से आकार अक्षर हैं, और असली टेक्स्ट निकालता है। PDF123 पर यह मुफ़्त ब्राउज़र टूल और POST /api/v1/misc/ocr-pdf के रूप में चलता है; प्रतिक्रिया Markdown होती है, दोबारा लिखी PDF नहीं।

स्कैन अब भी तस्वीर ही है

OCR बिटमैप को साफ़, शार्प या बदलता नहीं। जो साफ़ स्कैन OCR गलत पढ़ता है, वह देखने में साफ़ ही लगता रहता है। कभी इमेज गुणवत्ता अड़चन नहीं थी; अड़चन पहचान थी: एक ही बैच के स्कैन पर पहचान इंजन बदल दें तो सटीकता में बड़ा फ़र्क़ आ सकता है, जबकि पिक्सेल जस के तस रहते हैं।

पारंपरिक PDF OCR इमेज के नीचे संरेखित अदृश्य टेक्स्ट परत लिखता है ताकि चयन और खोज सही शब्दों पर पड़ें। यही आरेख दिखाता है, और कई डेस्कटॉप टूल आज भी ऐसे चलते हैं।

यह एंडपॉइंट असल में क्या लौटाता है

OCR मार्ग /api/v1/misc/ocr-pdf को कॉल करता है, जो एक स्वतंत्र Rust क्रेट pdf-inspector (इसके ocr फ़ीचर के साथ बनाया गया) पर चलता है। यह पूरी PDF किसी पहचान मॉडल को नहीं सौंपता। pdf-inspector पहले हर पेज को वर्गीकृत करता है: या तो उसमें पहले से निकाला-जा-सकने-योग्य नेटिव टेक्स्ट है, या वह सिर्फ़ इमेज है। नेटिव टेक्स्ट वाले पेज वह टेक्स्ट जैसा है वैसा ही रखते हैं और कभी पहचान मॉडल को नहीं छूते; सिर्फ़ इमेज वाले पेज इसके बजाय पहचान पाइपलाइन से गुज़रते हैं—PDFium (वही ओपन-सोर्स रेंडरर जिसे Chrome आंतरिक रूप से इस्तेमाल करता है) पेज को रास्टराइज़ करता है, और ONNX Runtime PP-OCRv6 Small मॉडल चलाकर उसे पढ़ता है। दोनों तरह के पेज क्रम में जोड़कर एक ही Markdown दस्तावेज़ में सिल दिए जाते हैं, इसीलिए प्रतिक्रिया text/markdown होती है और डाउनलोड .md पर ख़त्म होता है।

यह अनुबंध इस पुनर्लेखन के लिए नया है। इस प्रोजेक्ट का पुराना Java/Spring Boot बैकएंड OCRmyPDF को कॉल करता था—वही पारंपरिक "इमेज प्लस छिपी टेक्स्ट परत" तरीका—और PDF लौटाता था। Rust पुनर्लेखन ने उस पूरे रास्ते को pdf-inspector की चुनिंदा OCR से बदल दिया, और साथ ही आउटपुट PDF से Markdown में बदल गया। पुराना Java बैकएंड तब से रिपॉज़िटरी से पूरी तरह हटाया जा चुका है; यह कोई टॉगल नहीं है जिसे आप वापस चालू कर सकें।

खोजने-योग्य PDF (इमेज और टेक्स्ट परत) चाहिए तो यह गलत नतीजा है। एजेंट या पाइपलाइन जो टेक्स्ट पढ़ सके, वह चाहिए तो Markdown ही मक़सद है।

Auto बनाम Force OCR

फ़ॉर्म में ocrType फ़ील्ड है:

• Normal (force-ocr के अलावा कुछ भी) Auto पर मैप होता है: जहाँ टेक्स्ट पहले से है वहाँ उसे इस्तेमाल करें, और सिर्फ़ इमेज वाले पेजों पर OCR चलाएँ। साफ़ जन्मजात डिजिटल PDF पर Auto OCR रनटाइम लोड नहीं करता।
• Force OCR (ocrType=force-ocr) हर पेज पर पहचान दोबारा चलाता है, उन पर भी जिनमें टेक्स्ट परत है। इमेज-मात्र पेजों पर यह समय लेता है, अतिरिक्त शुद्धता नहीं; बदले में टूटी या अधूरी परत को अनदेखा करने वाला पास मिलता है।

पोर्टल का डिफ़ॉल्ट Force OCR है। भाषा का कोई नियंत्रण नहीं: पुराने Java मार्ग से बचे tessdata कोड अनदेखे जाते हैं।

Auto/Force का बँटवारा रिक्वेस्ट के भीतर ही होता है, और न पोर्टल और न ही API का क्षमता-जाँच (capability probe) इसे पहले से जाँचता है। GET /api/v1/settings/get-endpoints-status हमेशा ocr-pdf को "enabled" बताता है, बिना यह असल में जाँचे कि PDFium, ONNX Runtime, या PP-OCRv6 मॉडल इंस्टॉल हैं या नहीं। असली जाँच तभी होती है जब कोई रिक्वेस्ट पहचान को ट्रिगर करे: अगर इनमें से कुछ भी गायब हो, तो एंडपॉइंट 503 लौटाता है, न कि कोई घटिया Markdown जो चुपचाप सिर्फ़ नेटिव टेक्स्ट पर गिर जाए। PP-OCRv6 Small मॉडल का आकार लगभग 31 MB है; जब तक इसे डिप्लॉय के समय लोकल कैश में पहले से न भरा गया हो, यह तब नेटवर्क से डाउनलोड होता है जब किसी पेज को सचमुच पहचान की ज़रूरत पड़ती है। बिना पहले से भरे मॉडल वाली ऑफ़लाइन मशीन अपने पहले Force अनुरोध पर धीमी चलने के बजाय वहीं फ़ेल होने की सबसे ज़्यादा संभावना रखती है।

पहचान संभाव्य है

इंजन पिक्सेल पैटर्न को अक्षरों और शब्दों के मॉडल से मिलाते हैं। वे साफ़, उच्च-कंट्रास्ट, मानक फ़ॉन्ट वाली छपाई पर अच्छा करते हैं, और इन पर कमज़ोर:

• कम रिज़ॉल्यूशन या कम कंट्रास्ट वाले स्कैन (फ़ैक्स-गुणवत्ता बनाम 300 DPI मूल)
• हस्तलेख, सजावटी फ़ॉन्ट, असामान्य लेआउट (बहु-स्तंभ तालिकाएँ, घुमाया टेक्स्ट, घनी फ़ॉर्म)
• तिरछे पेज जो ग्लिफ़ आकार इतना विकृत कर दें कि मिलान भ्रमित हो जाए

धुँधला फ़ैक्स साफ़ स्कैन जैसा OCR नहीं होगा, चाहे Auto हो या Force। यह ख़ुद मॉडल की सीमा है, कोई पैरामीटर इसे ठीक नहीं कर सकता।

OCR जो नहीं करता

OCR टेक्स्ट देता है। यह अनुच्छेद, शीर्षक, तालिकाएँ या पुनः-प्रवाहित होने वाला Word दस्तावेज़ नहीं बनाता। संपादन-योग्य लेआउट पहचान की त्रुटि के ऊपर खड़ी रूपांतरण समस्या है, स्कैन पढ़ने का वही काम नहीं।

PDF का OCR करें बिना खाते के सर्वर-पक्ष चलता है। डाउनलोड Markdown है। मौजूदा टेक्स्ट परत गलत लगे तो Force OCR इस्तेमाल करें ताकि Auto उस पर भरोसा न करे; यह जाँचने के लिए कि किसी मशीन पर सचमुच PDFium और मॉडल इंस्टॉल है या नहीं, असली रिक्वेस्ट चलाना क्षमता-जाँच पढ़ने से बेहतर है, क्योंकि वह जाँच सिर्फ़ यह पुष्टि करती है कि एंडपॉइंट मौजूद है, यह नहीं कि उसका रनटाइम तैयार है। चाबियों और OpenAPI के लिए Developers देखें।