Wie die Erkennung funktioniert
Wie die Erkennung funktioniert
Diese Seite führt durch das, was AsposeOcr.Recognize() intern tatsächlich macht, von der Eingabevalidierung bis zum finalen RecognitionResult. Der Aufruf von AsposeOcr.Recognize(OcrInput) startet eine feste, achtstufige Pipeline. Jeder nachfolgende Schritt basiert auf der eigenen Implementierung der Bibliothek — es gibt keine konfigurierbaren Stufen.
1. Eingabevalidierung
Bevor ein Modell geladen wird, validiert Recognize() das OcrInput: Es verwirft eine null-Eingabe (ArgumentNullException), ein nicht unterstütztes InputType (NotSupportedException) und jeden in der Warteschlange befindlichen Pfad, der nicht auf dem Datenträger existiert (FileNotFoundException). Es wird keine ONNX-Sitzung erstellt, bis jede Eingabe bestanden hat.
2. PDF-Rendern oder Raster-Laden
Für InputType.PDF, jede Seite wird zu einem 24-Bit-RGB-Bild bei 150 DPI using Aspose.PDF.FOSS. Für InputType.SingleImage, wird die Rasterdatei direkt geladen. Die Rendering-Auflösung von 150 DPI ist fest und nicht konfigurierbar.
3. Detektor-Vorverarbeitung
Das Bild wird in Graustufen umgewandelt unter Verwendung von Rec. 709 Luma-Gewichte, die die wahrgenommene Helligkeit genauer bewahren als ein einfacher Kanal-Durchschnitt. Wenn die längste Seite des Bildes 1000 Pixel überschreitet, wird es mit einem separablen Lanczos-8 filter (zwei eindimensionale Durchläufe), um die Vorverarbeitung des Detektormodells zur Trainingszeit anzupassen. Ein 32-Pixel-weißer Streifen wird aus demselben Grund an den unteren Rand des Bildes angehängt.
4. Regionserkennung
Das vorverarbeitete Bild wird durch das erste eingebettete ONNX-Modell geleitet, das Text-Wahrscheinlichkeitskarten und Zwischen-Visuelle-Features erzeugt. Ein zweites ONNX-Modell — das Verfeinerungsmodell — stärkt die Verbindungen zwischen benachbarten Zeichen, sodass eine komplette Textzeile als eine Region und nicht als mehrere Fragmente erkannt wird. Beide Modelle laufen auf der CPU mit Microsoft.ML.OnnxRuntime, das für 8 intra-operation worker-Threads konfiguriert ist.
5. Region-Nachverarbeitung
Die Text- und Link-Wahrscheinlichkeitskarten des Detektors werden schwellenwertbehandelt und anschließend mit einer vier-fach verbundenen, breitensuche-basierten Flood-Fill-Methode gruppiert. Jede resultierende Region wird dilatiert, mit einem Minimalflächen-Rechteck angepasst, zurück in die Koordinaten des Quellbildes skaliert und auf nicht verschachtelte, achsenausgerichtete Linienrechtecke reduziert. Diese Rechtecke sind das, was RecognitionResult.LinesResult.Line letztendlich zurückgibt.
6. Zeilenerkennung
Jedes erkannte Rechteck wird um zwei Pixel erweitert, aus dem Quellbild ausgeschnitten und – unter Beibehaltung seines Seitenverhältnisses – auf eine feste 1200×32 weiße Leinwand. Das Ergebnis wird in einen NHWC-Graustufen-Tensor konvertiert und an das Erkennungsmodell übergeben.
7. CTC-Dekodierung
Die Rohausgabe des Erkennungsmodells wird mit einem gierigen CTC (Verbindungsorientierte Zeitliche Klassifikation) Dekodierung: Wiederholte vorhergesagte Klassen werden zusammengefasst, die Leerklasse wird entfernt, und die verbleibenden Klassen werden über das im Modell eingebettete lateinische Alphabet abgebildet, um den erkannten Text der Zeile zu erzeugen.
8. Ergebniszusammenstellung
Erkannte Zeilen werden mit ihren Quellbild-Rechtecken gepaart, um jedes RecognitionResult.LinesResult zu erstellen. Alle nicht-leeren Zeilen werden mit plattformspezifischen Zeilenumbrüchen zusammengeführt, um RecognitionResult.RecognitionText zu erzeugen.
Sequenzielle vs. parallele Arbeit
Eingabedateien und, bei PDFs, einzelne Seiten werden verarbeitet sequentially — es gibt kein Input-Level-Multithreading API. Parallelität existiert nur innerhalb jedes ONNX-Inference-Aufrufs, wo Microsoft.ML.OnnxRuntime parallelisiert die Graphausführung über seine 8 konfigurierten intra-operation threads.
