OCR-SW, howto und best practice

pit234a

Well-Known Member
hier habe ich es ja schon angedeutet, dass ich dieses Thema am liebsten noch weiter beleuchten möchte.
Wie macht ihr das?
Was kann ich von euch lernen?
Welche Tips habt ihr so in Petto?

Ausgangslage: ich brauchte einen neuen Scanner, habe um Rat gefragt und diesen erhalten, den neuen Scanner gekauft und so eingesetzt, wie den alten Scanner auch und ich wäre damit glücklich und zufrieden gewesen und meiner Tage Licht hätte sich so dem Ende genähert, ohne dass ich jemals erfahren hätte, dass ja da noch mehr geht!

Wäre nicht @Andy_m4 gewesen, der mir weitere Erleuchtung zu Teil werden ließ.
Du kannst auch Schrifterkennung drauf machen (um die Dokumente so durchsuchbar zu kriegen).
Eine gern genommene Lösung ist graphics/tesseract. bzw. eine integriertes Programm (mit GUI) wie graphics/gscan2pdf.
Wenns noch ein bisschen mehr sein soll, kann man zu OpenPaper.work (FreeBSD Pkg: py311-openpaperwork-*) greifen.

Schon bei tesseract erkenne ich, dass diese Art der Texterkennung und der Erzeugung resultierender Dateien in txt, aber vor Allem als PDF ungleich besser ist, als alles, was ich bisher genutzt habe, nämlich: graphics/gocr und graphics/ocrad.
Das graphics/tesseract ist einfach meilenweit besser und erzeugt grandios gute und durchsuchbare PDF-Dateien, selbst aus meinen sehr alten und unzulänglichen Scans!

Dabei könnte ich nun alle möglichen veralteten Scans einfach einem Script vorwerfen, dass diese mit tessaract behandelt.
Bevor ich aber diesen verwegenen Weg gehe, frage ich lieber mal nach.

@Andy_m4 hat ja noch andere Möglichkeiten genannt und ich kann kaum glauben, dass die mich dann noch mehr begeistern können?

Bevor ich unsägliche Stunden mit Tests zubringe, deshalb lieber mal nachgefragt:
Wie macht ihr das?
Welche Programme nutzt ihr?
Nutzt ihr das zusätzlich zum Scann-Programm oder kann man das dann auch integrieren?
Oder doch lieber ein Script laufen lassen?
 
Skript. :)

Was die Software angeht gehe ich mal davon aus, dass heutzutage genug Trainingsdaten fuer neuronale Netze zur Verfuegung stehen. Das sollte der schrifterkennung zu gute kommen!

Wenn du einen Scanner mit dokumenten einzug hast geht das bestimmt auch sehr komfortabel.
 
graphics/gscan2pdf
zweiter Tag.

Vielleicht viel zu wenig Zeit habe ich bisher in gscan2pdf investiert.
Es ist eine GUI.
OK.
Aus dieser GUI kann man Dokumente scannen und sogleich eine Übersetzung nach OCR starten. Man kann auch bereits eingescannte Dokumente als Bild-Datei hier öffnen und dann ebenfalls den OCR starten.
In unterschiedlichen Tabs werden die unterschiedlichen Ebenen angezeigt und können dort sogar editiert werden, also zumindest scheint es so, und es werden Tabs für den Text und für Anmerkungen geöffnet, wobei ich nicht sicher bin, was genau das eigentlich meint. Auf die Schnelle konnte ich da nichts editieren, aber das war auch jetzt nicht Sinn meines Versuches. Die Anmerkungen-Tabs waren bislang immer leer.
Die Texterkennung eines Dokumentes muss man starten und erhält dann die Auswahl, entweder per tessaract oder per gocr (siehe oben) zu wandeln. tessaract bietet dann auch die Auswahl einer Sprache, wo German recht gut in der Gesamtauswahl versteckt ist. Aber dann funktioniert es mal wieder gnadenlos viel besser, als das von mir bisher genutzte gocr.

Brauche ich das?
Vermutlich gar nicht oder doch eher selten.
Wenn ich ein Dokument, wie bei mir üblich, als PNG gescannt habe, kann ich es mittels gscan2pdf-GUI öffnen und dann daraus den enthaltenen Text mittels tessaract OCR-Erkenntnissen einem neu zu erstellenden PDF zuführen.
Eh nun?
Das kann ich ja auch mittels eines Einzeilers auf der Shell, wenn ich tessaract direkt aufrufe und ein entsprechendes PDF aus meinem PNG erzeugen lasse.
Vielleicht vergesse ich ja die Syntax auf der Shell? Dann kann ich mich immerhin bequem der GUI bedienen.

Lassen wir das mal so stehen. Die gewonnen Erkenntnisse mögen sich im Laufe der Zeit ja noch ändern, aber am Tag zwei meiner Versuche würde ich meinen, dass ich gscan2pdf und seine GUI vermutlich eher nicht brauche und kaum nutzen werde.
 
Das kann ich ja auch mittels eines Einzeilers auf der Shell, wenn ich tessaract direkt aufrufe und ein entsprechendes PDF aus meinem PNG erzeugen lasse.
Vielleicht vergesse ich ja die Syntax auf der Shell? Dann kann ich mich immerhin bequem der GUI bedienen.
Vielleicht unberechtigter Einwand, da ich tesseract nur im Zusammenhang mit Untertiteln kenne, aber eine GUI finde ich da sehr praktisch für die Nachkorrektur bei falsch erkannten Buchstaben/Zeichen. Tesseract hat ja keine 100% Trefferquote, schlimm ist es z.B. bei 1,i,I,|,/,¡ sowie jeweils die Kursivvarianten.
In meiner Vorstellung bekäme ich dann ein .pdf wo ich mir nicht sicher bin, wieviel Prozent Gulaschtext enthalten ist.
 
aber eine GUI finde ich da sehr praktisch für die Nachkorrektur bei falsch erkannten Buchstaben/Zeichen. Tesseract hat ja keine 100% Trefferquote,
dito, aber:

ich habe es mit dieser GUI (gscan2pdf) nicht hin bekommen, irgendwas zu editieren.
Außerdem zeigte sie ein extrem lahmes Verhalten, dergestalt, dass ich manchmal gar nicht wusste, ob sie überhaupt noch wach ist, um dann plötzlich doch eine Reaktion auf eine lang zurückliegende Mausaktion zu zeigen und mich damit nun wieder vollkommen zu überraschen.
Die Ergebnisse waren dann letztlich auch schlechter, als die einfache Kommandozeile mit tessaract.
Aber, das ist schwierig ohne Beispiele zu beschreiben und die etwa ein Dutzend Beispiele, mit denen ich es probiert habe, sind allesamt Dokumente der Art, dass ich die nicht hier zeigen möchte. Ich versuche mal, es zu beschreiben.
Die GUI zerlegte das Dokument offenbar in viele Textbereiche und zeigte diese dann auch in einem extra-TAB an, der so ausgesehen hat, als könne man da etwas editieren. Es gelang mir nicht, wie schon gesagt. Als PDF abgespeichert und dann benutzt, um daraus zu kopieren oder Stellen zu markieren (also weiter bearbeiten der PDFs), lagen die unterlegten Textfelder weiter vom darüber liegenden Bild auseinander, als bei den mittels einfachster Syntax auf der Kommandozeile hergestellten PDFs. Bei letzterem besteht beinahe 100% Übereinstimmung, ein markiertes Wort (das dann zur Suche benutzt werden kann oder als Text kopiert wird), ist genau gleich dem angezeigten Bereich. Bei PDFs, die von der GUI erzeugt wurden, traf dieser Bereich nur zu etwa 95% zu, man erfasste also etwa das Wort komplett, obwohl optisch noch die letzten Buchstaben zur Markierung fehlten oder, umgekehrt, erfasste man dann unerwünscht Zeichen des nächsten Wortes, weil eben die Deckung nicht ganz 100% war.
Sodann hatte mir das Paket schon einige andere Anwendungen wegen diversen (Versions-) Konflikten gekippt, was ich eh nur bereit war, zu dem anvisierten Test zu akzeptieren. Es brauchte entweder hier weitere Eingriffe oder, was bei mir nun der Fall ist, der Deinstallation dieser SW im Zuge der Re-installation anderer SW, die ich mir eher wünschte.


aber hast du dir in dem Kontext mal paperless-ngx angeschaut?
https://www.bsdforen.de/goto/post?id=341647 sagte @Andy_m4 :
Wenns noch ein bisschen mehr sein soll, kann man zu OpenPaper.work (FreeBSD Pkg: py311-openpaperwork-*)
Beides: NEIN, noch nicht.
Die Idee ist bei mir ja ohnehin neu, dass man so etwas überhaupt machen kann, also Dokumente scannen und dann so gut mittels passender SW nach enthaltenen Texten zu durchsuchen, dass man auch tatsächlich gute Ergebnisse einfängt.
Bisher hielt ich ehrlich gesagt nicht allzu-viel von OCR-SW.

Die folgende Aussage würde thematisch vielleicht besser zum vorigen Abschnitt passen also als Antwort zu https://www.bsdforen.de/threads/ocr-sw-howto-und-best-practice.37330/post-341672.

tessaract hat mich vollkommen überrascht, was die Qualität der Ergebnisse angeht. Bei "sauberen Dokumenten" gibt es quasi keine Fehler in meinen bisherigen Versuchen. Es gibt allerdings viele "unsaubere Dokumente" und wenn man dann auch noch die Kopie einer Kopie einscannt, macht auch tessaract Fehler bei der OCR-Erkennung. Unsauber ist zB ein Stempel mit Text, der dann auch noch schräg auf ein Dokument gedrückt wurde und andere Inhalte großzügig überlagert oder auch die oft vorhanden Felder, wo man etwa ein Datum eintragen muss, dessen einzelne Komponenten aber durch "Zellen" getrennt sind. Das sieht etwa so aus
Code:
"|__|__|____|"
und das soll nun sinnvoll gefüllt werden mit |dd|mm|yyyy|, was bestimmt einen Sinn macht, aber nun von der OCR-Maschine nur sehr schwierig aufzulösen ist, weil eben semantisch gar nicht sinnvoll. Kein Mensch verwendet doch | als Trenner für das Datum und wenn dann auch noch die Vorlage ein wenig schräg und undeutlich ist, erkennt tessaract hier sehr schnell statt | einen / oder ein 1 oder l oder dann in Kombination mit folgenden Pixeln auch noch viel interessantere Dinge.
Ich glaube nicht, dass irgendeine GUI hier Abhilfe schaffen und etwas besser machen kann, aber das ist nicht mehr, als mein derzeitiger Stand.

Und auf diesem Stand bin ich gerade ein wenig eingefroren.
py311-openpaperwork habe ich installiert, gebe aber zu, dass mir das nicht weiter hilft, weil ich nicht mal weiß, wie ich das starten kann.
Bei meiner Recherche dazu stieß ich dann auch auf paperless-ngx, habe aber noch nicht mal daran gedacht, das nun schon zu installieren / probieren, wo ich so wenig Ahnung habe, dass ich eine einfache Python-GUI-Anwendung nicht zu starten weiß.

Ich weiß jetzt nicht, ob das übers Ziel hinausschießt
das weiß ich natürlich auch nicht!
probieren möchte ich schon gerne, bin aber womöglich doch zu unbedarft, siehe gerade eben.
Doch, das stimmt nun eben schon, wenn ich ein "sauberes" PNG einfach mittels
Code:
tessaract "von/hier" "zu/hier" -l deu pdf
behandle, werden meine Erwartungen bereits zu mehr als 100% erfüllt. Bei meinen bisherigen Versuchen funktionierte das sehr zufrieden stellend!
Was will man mehr?
 
Zurück
Oben