Πώς το OCR διαβάζει ένα σαρωμένο PDF, και γιατί αυτό το εργαλείο επιστρέφει Markdown

Ένα σαρωμένο PDF αποθηκεύει τις σελίδες ως εικόνες ράστερ: φωτογραφίες κειμένου, όχι επιλέξιμους χαρακτήρες. Η οπτική αναγνώριση χαρακτήρων (OCR) εξετάζει αυτά τα εικονοστοιχεία, μαντεύει ποια σχήματα είναι γράμματα και παράγει πραγματικό κείμενο. Στο PDF123 εκτελείται και ως δωρεάν εργαλείο στον φυλλομετρητή και ως POST /api/v1/misc/ocr-pdf· η απάντηση είναι Markdown, όχι ξαναγραμμένο PDF.

Η σάρωση παραμένει εικόνα

Το OCR δεν καθαρίζει, δεν οξύνει και δεν αντικαθιστά την ψηφιδωτή εικόνα. Μια ευκρινής σάρωση που το OCR διαβάζει λάθος εξακολουθεί να δείχνει ευκρινής. Η εικόνα δεν υπήρξε ποτέ το σημείο συμφόρησης της ποιότητας· η αναγνώριση ήταν: αλλάξτε τη μηχανή αναγνώρισης πάνω στην ίδια παρτίδα σαρώσεων και η ακρίβεια μπορεί να αλλάξει δραστικά, χωρίς να έχουν αγγιχτεί καθόλου τα ίδια τα εικονοστοιχεία.

Το κλασικό OCR σε PDF γράφει ένα δεύτερο, αόρατο στρώμα κειμένου ευθυγραμμισμένο κάτω από την εικόνα, ώστε η επιλογή και η αναζήτηση να πέφτουν στις σωστές λέξεις. Αυτό δείχνει το διάγραμμα και έτσι λειτουργούν ακόμη πολλά προγράμματα για υπολογιστή.

Τι επιστρέφει στην πραγματικότητα αυτό το σημείο API

Η διαδρομή OCR καλεί το /api/v1/misc/ocr-pdf, το οποίο τρέχει πάνω σε ένα αυτόνομο Rust crate, το pdf-inspector (χτισμένο με το χαρακτηριστικό του ocr). Δεν δίνει ολόκληρο το PDF σε ένα μοντέλο αναγνώρισης. Το pdf-inspector ταξινομεί πρώτα κάθε σελίδα είτε ως ήδη διαθέτουσα εξαγώγιμο εγγενές κείμενο είτε ως αμιγώς εικόνα. Οι σελίδες με εγγενές κείμενο κρατούν αυτό το κείμενο ως έχει και δεν αγγίζουν ποτέ το μοντέλο αναγνώρισης· οι σελίδες που είναι μόνο εικόνα περνούν αντ' αυτού από τον αγωγό αναγνώρισης — το PDFium (ο ίδιος ανοιχτού κώδικα renderer που χρησιμοποιεί εσωτερικά το Chrome) ραστεροποιεί τη σελίδα, και το ONNX Runtime τρέχει το μοντέλο PP-OCRv6 Small για να τη διαβάσει. Και οι δύο τύποι σελίδων ράβονται με τη σειρά τους σε ένα ενιαίο έγγραφο Markdown, γι' αυτό η απάντηση είναι text/markdown και το ληφθέν αρχείο καταλήγει σε .md.

Αυτό το συμβόλαιο είναι καινούριο σε αυτή την επανεγγραφή. Το backend Java/Spring Boot που χρησιμοποιούσε παλιότερα το έργο καλούσε το OCRmyPDF, την κλασική προσέγγιση «εικόνα συν κρυφό στρώμα κειμένου», και επέστρεφε PDF. Η επανεγγραφή σε Rust αντικατέστησε αυτή τη διαδρομή εξ ολοκλήρου με την επιλεκτική OCR του pdf-inspector, και η έξοδος μετακινήθηκε μαζί της από PDF σε Markdown. Το παλιό backend σε Java έχει έκτοτε αφαιρεθεί εντελώς από το αποθετήριο· δεν είναι ένας διακόπτης που μπορείτε να γυρίσετε πίσω.

Αν χρειάζεστε αναζητήσιμο PDF (εικόνα με στρώμα κειμένου), αυτό το endpoint δεν μπορεί να σας το δώσει. Σας δίνει κείμενο που ένας πράκτορας ή ένας αγωγός δεδομένων μπορεί να καταναλώσει απευθείας.

Auto ή Force OCR

Η φόρμα έχει το πεδίο ocrType:

• Normal (οτιδήποτε εκτός από force-ocr) αντιστοιχεί σε Auto: χρησιμοποιεί το υπάρχον κείμενο όπου το αρχείο το έχει και εκτελεί OCR μόνο στις σελίδες που είναι εικόνες. Σε ένα καθαρό ψηφιακά γεννημένο PDF, το Auto δεν φορτώνει το περιβάλλον εκτέλεσης του OCR.
• Force OCR (ocrType=force-ocr) επαναλαμβάνει την αναγνώριση σε κάθε σελίδα, ακόμη και σε όσες έχουν ήδη στρώμα κειμένου. Στις σελίδες που είναι πραγματικά εικόνες πληρώνετε χρόνο, όχι επιπλέον ακρίβεια· κερδίζετε όμως ένα πέρασμα που αγνοεί ένα σπασμένο ή ελλιπές υπάρχον στρώμα.

Η προεπιλογή της πύλης είναι Force OCR. Δεν υπάρχει ρύθμιση γλώσσας: οι υπολειμματικοί κωδικοί tessdata από την παλιά διαδρομή Java αγνοούνται.

Ο διαχωρισμός Auto/Force γίνεται μέσα στο ίδιο το αίτημα, και ούτε η πύλη ούτε ο έλεγχος δυνατοτήτων του API το ελέγχουν εκ των προτέρων. Το GET /api/v1/settings/get-endpoints-status αναφέρει πάντα το ocr-pdf ως ενεργοποιημένο, χωρίς να επαληθεύει στην πραγματικότητα ότι είναι εγκατεστημένα το PDFium, το ONNX Runtime ή το μοντέλο PP-OCRv6. Ο πραγματικός έλεγχος γίνεται μόνο τη στιγμή που ένα αίτημα ενεργοποιεί την αναγνώριση: αν λείπει κάτι από αυτά, το endpoint επιστρέφει 503, όχι ένα υποβαθμισμένο Markdown που υποχωρεί σιωπηλά μόνο στο εγγενές κείμενο. Το ίδιο το μοντέλο PP-OCRv6 Small ζυγίζει περίπου 31 MB· εκτός αν έχει προφορτωθεί στην τοπική κρυφή μνήμη κατά την ανάπτυξη, κατεβαίνει μέσω δικτύου την πρώτη φορά που μια σελίδα χρειάζεται πραγματικά αναγνώριση. Ένα offline μηχάνημα χωρίς προφορτωμένο μοντέλο πιθανότατα θα αποτύχει ακριβώς εκεί, στο πρώτο του αίτημα Force, αντί απλώς να τρέξει πιο αργά.

Η αναγνώριση είναι πιθανοτική

Οι μηχανές αντιστοιχίζουν μοτίβα εικονοστοιχείων με μοντέλα γραμμάτων και λέξεων. Τα καταφέρνουν καλά σε καθαρή, υψηλής αντίθεσης εκτύπωση τυποποιημένης γραμματοσειράς και χειρότερα σε:

• Σαρώσεις χαμηλής ανάλυσης ή χαμηλής αντίθεσης (ποιότητα φαξ αντί για πρωτότυπο στα 300 DPI)
• Χειρόγραφα, διακοσμητικές γραμματοσειρές, ασυνήθιστες διατάξεις (πίνακες με πολλές στήλες, περιστραμμένο κείμενο, πυκνές φόρμες)
• Σελίδες με κλίση, που παραμορφώνουν τα σχήματα των χαρακτήρων αρκετά ώστε να μπερδέψουν την αντιστοίχιση

Ένα θολό φαξ δεν θα αναγνωριστεί σαν καθαρή σάρωση, ανεξάρτητα από την επιλογή Auto ή Force. Αυτό είναι όριο του ίδιου του μοντέλου, όχι κάτι που μπορεί να διορθώσει μια παράμετρος.

Τι δεν κάνει το OCR

Το OCR σας δίνει κείμενο. Δεν ξαναχτίζει παραγράφους, επικεφαλίδες, πίνακες ή ένα αναδιατάξιμο έγγραφο Word. Η επεξεργάσιμη διάταξη είναι πρόβλημα μετατροπής πάνω από το σφάλμα αναγνώρισης, δηλαδή διαφορετική δουλειά από την ανάγνωση μιας σάρωσης.

Το OCR σε PDF εκτελείται στον διακομιστή χωρίς λογαριασμό. Η λήψη είναι Markdown. Αν ένα υπάρχον στρώμα κειμένου φαίνεται λάθος, χρησιμοποιήστε το Force OCR ώστε το Auto να μην το εμπιστεύεται· και για να ελέγξετε αν ένα συγκεκριμένο μηχάνημα έχει πράγματι εγκατεστημένα το PDFium και το μοντέλο, το να στείλετε ένα πραγματικό αίτημα είναι πιο αξιόπιστο από το να διαβάσετε τον έλεγχο δυνατοτήτων, αφού αυτός απλώς επιβεβαιώνει ότι υπάρχει το endpoint, όχι ότι το περιβάλλον εκτέλεσής του είναι έτοιμο. Για κλειδιά αυτοματοποίησης και OpenAPI, δείτε τους Προγραμματιστές.