Hoe herkenning werkt
Hoe herkenning werkt
Deze pagina loopt door wat AsposeOcr.Recognize() intern eigenlijk doet, van invoervalidatie tot de uiteindelijke RecognitionResult. Het aanroepen van AsposeOcr.Recognize(OcrInput) voert een vaste, acht-stappen pijplijn uit. Elke onderstaande stap is gebaseerd op de eigen implementatie van de bibliotheek — er zijn geen configureerbare fasen.
1. Invoervalidatie
Voordat een model wordt geladen, valideert Recognize() de OcrInput: het wijst een null invoer (ArgumentNullException) af, een niet-ondersteunde InputType (NotSupportedException), en elk in de wachtrij geplaatste pad dat niet op de schijf bestaat (FileNotFoundException). Er wordt geen ONNX-sessie aangemaakt totdat elke invoer slaagt.
2. PDF-renderen of rasterladen
Voor InputType.PDF, elke pagina wordt gerenderd tot een 24-bit RGB-afbeelding op 150 DPI using Aspose.PDF.FOSS. Voor InputType.SingleImage, wordt het rasterbestand direct geladen. De renderresolutie van 150 DPI is vast en niet configureerbaar.
3. Detectorvoorverwerking
De afbeelding wordt geconverteerd naar grijstinten met behulp van Rec. 709 luma-gewichten, die de waargenomen helderheid nauwkeuriger behouden dan een eenvoudige kanaalgemiddelde. Als de langste zijde van de afbeelding groter is dan 1000 pixels, wordt deze verkleind met een scheidbare Lanczos-8 filter (twee eendimensionale passes) om overeen te komen met de preprocessing tijdens de training van het detectormodel. Een witte strook van 32 pixels wordt aan de onderkant van de afbeelding toegevoegd om dezelfde reden.
4. Regiondetectie
De voorbewerkte afbeelding wordt doorgegeven aan het eerste ingebedde ONNX-model, dat tekst-probabiliteitskaarten en tussenliggende visuele kenmerken produceert. Een tweede ONNX-model — het verfijningsmodel — versterkt de verbindingen tussen aangrenzende tekens zodat een volledige tekstregel wordt gedetecteerd als één regio in plaats van meerdere fragmenten. Beide modellen draaien op de CPU met Microsoft.ML.OnnxRuntime geconfigureerd voor 8 intra-operatie worker-threads.
5. Regio-postverwerking
De tekst- en link-probabiliteitskaarten van de detector worden gethreshhold, vervolgens gegroepeerd met een vier-verbonden breadth-first flood fill. Elke resulterende regio wordt gedilateerd, passend gemaakt met een minimale-oppervlakte rechthoek, teruggeschaald naar de coördinaten van de bronafbeelding, en gereduceerd tot niet-geneste, as-geregelde lijndriehoeken. Deze rechthoeken zijn wat RecognitionResult.LinesResult.Line uiteindelijk retourneert.
6. Lijnerkenning
Elk gedetecteerd rechthoek wordt met twee pixels gepadded, uit de bronafbeelding gecropt, en resized — waarbij de beeldverhouding behouden blijft — naar een vaste 1200×32 witte canvas. Het resultaat wordt omgezet naar een NHWC grijstint tensor en doorgegeven aan het herkenningsmodel.
7. CTC-decodering
De ruwe output van het herkenningsmodel wordt gedecodeerd met greedy CTC (Connectionistische Tijdelijke Classificatie) decodering: herhaalde voorspelde klassen worden samengevoegd, de lege klasse wordt verwijderd, en de resterende klassen worden via het ingebedde Latijnse alfabet van het model gemapt om de herkende tekst van de regel te produceren.
8. Resultaatassemblage
Herkende regels worden gekoppeld aan hun bron-afbeeldingsrechthoeken om elke RecognitionResult.LinesResult te bouwen. Alle niet-lege regels worden samengevoegd met platform-regeleinden om RecognitionResult.RecognitionText te produceren.
Sequentieel vs. Parallel Werk
Invoerbestanden en, voor PDF’s, individuele pagina’s worden verwerkt sequentially — er is geen input-level multithreading API. Parallelisme bestaat alleen binnen elke ONNX-inferentieaanroep, waar Microsoft.ML.OnnxRuntime paralleliseert de graph-uitvoering over zijn 8 geconfigureerde intra-operatie threads.
