Hoe OCR een gescande PDF leest, en waarom deze tool Markdown teruggeeft

Een gescande PDF bewaart pagina's als rasterafbeeldingen: foto's van tekst, geen selecteerbare tekens. OCR (optical character recognition) bekijkt die pixels, raadt welke vormen tekens zijn en levert echte tekst op. Op PDF123 draait dat als gratis browsertool en als POST /api/v1/misc/ocr-pdf; het antwoord is Markdown, geen herschreven PDF.

De scan blijft een afbeelding

OCR maakt de bitmap niet schoon, scherper of anders. Een scherpe scan die OCR verkeerd leest, ziet er nog steeds scherp uit. De afbeelding was nooit het knelpunt; de herkenning was dat. Verwissel de herkenningsengine op dezelfde reeks scans en de nauwkeurigheid kan flink verschuiven, terwijl de pixels zelf ongewijzigd blijven.

Klassieke PDF-OCR schrijft een tweede, onzichtbare tekstlaag die onder de afbeelding is uitgelijnd, zodat selecteren en zoeken op de juiste woorden uitkomen. Dat laat het diagram zien, en zo werken veel desktopprogramma's nog.

Wat dit endpoint werkelijk teruggeeft

De OCR-route roept /api/v1/misc/ocr-pdf aan, dat draait op een op zichzelf staande Rust-crate, pdf-inspector (gebouwd met de ocr-functie ervan). Het geeft niet de hele PDF door aan een herkenningsmodel. pdf-inspector classificeert elke pagina eerst als pagina met al extraheerbare native tekst, of als alleen-afbeelding. Pagina's met native tekst behouden die tekst ongewijzigd en raken het herkenningsmodel nooit; alleen-afbeeldingpagina's doorlopen in plaats daarvan de herkenningspijplijn: PDFium (dezelfde opensource-renderer die Chrome intern gebruikt) rasterizeert de pagina, en ONNX Runtime draait het model PP-OCRv6 Small om hem te lezen. Beide soorten pagina's worden vervolgens in volgorde aan elkaar genaaid tot één Markdown-document, en daarom is het antwoord text/markdown en eindigt de download op .md.

Dat contract is nieuw met deze herschrijving. De Java/Spring Boot-backend die dit project vroeger draaide, riep OCRmyPDF aan, de klassieke aanpak van "afbeelding plus verborgen tekstlaag", en gaf een PDF terug. De herschrijving in Rust heeft dat pad volledig vervangen door de selectieve OCR van pdf-inspector, en de uitvoer verschoof daarmee van PDF naar Markdown. De oude Java-backend is inmiddels helemaal uit de repository verwijderd; het is geen schakelaar die u kunt terugzetten.

Hebt u een doorzoekbare PDF nodig (afbeelding plus tekstlaag), dan is dit de verkeerde uitvoer. Hebt u tekst nodig die een agent of pipeline kan lezen, dan is Markdown juist het doel.

Auto versus Force OCR

Het formulier heeft een veld ocrType:

• Normal (alles behalve force-ocr) komt neer op Auto: gebruik bestaande tekst waar het bestand die al heeft en draai OCR op pagina's die alleen afbeeldingen bevatten. Op een schone, digitaal ontstane PDF laadt Auto de OCR-runtime niet.
• Force OCR (ocrType=force-ocr) draait de herkenning op elke pagina opnieuw, ook op pagina's die al een tekstlaag hebben. Op pagina's die echt alleen afbeeldingen bevatten, betaalt u met tijd en niet met extra nauwkeurigheid; u krijgt een doorloop die een kapotte of onvolledige bestaande laag negeert.

De standaardwaarde in de portal is Force OCR. Er is geen taalinstelling: overgebleven tessdata-codes van het oude Java-pad worden genegeerd.

De keuze tussen Auto en Force valt binnen de aanvraag zelf, en noch de portal noch de capability-probe van de API controleert dat vooraf. GET /api/v1/settings/get-endpoints-status meldt ocr-pdf altijd als ingeschakeld, zonder daadwerkelijk te verifiëren of PDFium, ONNX Runtime of het PP-OCRv6-model geïnstalleerd zijn. De echte controle gebeurt pas op het moment dat een aanvraag herkenning in gang zet: ontbreekt een van die onderdelen, dan geeft het endpoint 503 terug, in plaats van stilletjes terug te vallen op een verzwakte Markdown met alleen native tekst. Het PP-OCRv6 Small-model zelf is ongeveer 31 MB groot; tenzij het bij de deploy al in de lokale cache is voorgeladen, wordt het over het netwerk gedownload zodra een pagina voor het eerst echt herkenning nodig heeft. Een machine die offline is en geen voorgeladen model heeft, zal hoogstwaarschijnlijk precies daar stuklopen bij de eerste Force-aanvraag, in plaats van gewoon trager te draaien.

Herkenning is probabilistisch

Herkenningsengines vergelijken pixelpatronen met modellen van letters en woorden. Ze presteren goed op schoon, contrastrijk drukwerk in standaardfonts, en slechter op:

• scans met lage resolutie of weinig contrast (faxkwaliteit tegenover een origineel van 300 DPI)
• handschrift, decoratieve fonts en ongewone indelingen (tabellen met meerdere kolommen, geroteerde tekst, dichte formulieren)
• scheve pagina's die glyphvormen net genoeg vervormen om de vergelijking in de war te brengen

Een wazige fax levert niet dezelfde OCR als een schone scan, ongeacht Auto of Force. Dat is een beperking van het model zelf, niet iets wat een parameter kan verhelpen.

Wat OCR niet doet

OCR geeft u tekst. Het bouwt geen alinea's, koppen, tabellen of een Word-document met doorlopende tekst opnieuw op. Bewerkbare opmaak is een conversieprobleem bovenop de herkenningsfout, niet dezelfde taak als een scan lezen.

OCR a PDF draait server-side zonder account. De download is Markdown. Ziet een bestaande tekstlaag er verkeerd uit, gebruik dan Force OCR, zodat Auto die laag niet vertrouwt; om te controleren of een bepaalde machine PDFium en het model daadwerkelijk geïnstalleerd heeft, is een echte aanvraag uitvoeren betrouwbaarder dan de capability-probe aflezen, want die bevestigt alleen dat het endpoint bestaat, niet dat de runtime ervan klaar is. Voor automatiseringssleutels en OpenAPI, zie Developers.