ich habe alte Dokumente im Blocktext, bei denen ich eine Texterkennung (OCR) durchführen will.
(Kontext: Es handelt sich um alte Kontoauszüge, aus denen letztendlich eine Excel-Tabelle entstehen soll. Als Zwischenschritt brauche ich aber erst einmal den Inhalt des Papiers in einer Textdatei.)
Mein erster naiver Gedanke war, dass das eigentlich extrem gut gehen müsste, weil die Schriftart wohl mal vor etwa einem halben Jahrhundert dafür entwickelt wurde, OCR-tauglich zu sein. (Das versaut mir auch die Google-Suche: Die Schrift heißt wohl "OCR-B" und taucht immer bei den Suchbegriffen "OCR" und "Monospaced" auf.)
Allerdings ware die bisherigen Versuche extrem ernüchternd. Die meisten PDF-OCR-Programme, die ich getestet habe, versuchen daraus Proportionalschrift zu machen, und das Block-Layout ist damit dahin. Die Erkennungsrate ist auch nicht berauschend.
(Getestet mit: Adobe Acrobat 9, PDFXChange Editor 10, PaperPort 14. Am besten, nämlich bislang fehlerfrei, schneidet in der Erkennung noch das Windows-Snipping-Tool ab, aber das kann die Textdaten auch nicht als einfachen Textstring mit Leerzeichen exportieren und erfordert viel Handarbeit.)
Kennt ihr eine OCR-Software, der man "Contraints" auferlegen kann, damit Blocktext sich letztendlich auch als Blocktext exportieren lässt? Als Nebeneffekt sollte die Erkennungsrate davon ja auch profitieren.
Probier's mit tesseract*. Ist OpenSource, wird über Kommandozeile aufgerufen (Bilddatei als Quelle, Text in beliebigem Format als Ziel), und kann eben auch reine Textdateien erzeugen. Somit gibt es keine Proportionalschrift etc., sondern einfach nur Text, was Deinem Ziel deutlich näher kommen dürfte.
Tesseract kann auch PDF mit "searchable text" erzeugen (und ist damit auch für viele andere Anwendungen interessant), aber das ist ja offensichtlich nicht Dein Problem.
Beispielaufruf:
1
tesseract scan.jpg textdatei -l deu -c preserve_interword_spaces=1
Das erzeugt aus einer Bilddatei namens "scan.jpg" eine Datei namens "textdatei.txt".
Der Parameter "-l deu" ist für deutsche Texte
und der Parameter "-c preserve_interword_spaces=1" sorgt dafür, daß die Formatierung mit Leerzeichen halbwegs erhalten bleibt.
Dein Bild ergibt folgenden Text:
1
BUU AFFE REN
2
3
19] ClimatePartner
4
5
klimaneutral
6
7
Paner
8
9
Sparkasse Blatt 6
10
Kundenhinweis Mitteilung 2: Je Teilııt
11
Information zur Einlagensicherung
12
13
Auf der Grundlage einer EU-Richtlinie ist am 3. Juli 2015 in Deutschland
14
das Einlagensicherungsgesetz in Kraft getreten. Aufgrund gesetzlicher Vor-
15
gaben sind wir verpflichtet, Sie einmal jährlich über die Einlagensicherung
16
zu informieren und Ihnen den "Informationsbogen für den Einleger” zur Ver-
17
fügung zu stellen. Dieser Bogen liegt für Sie in allen Geschäftsstellen
18
bereit und kann auch auf unserer Homepage eingesehen werden unter:
19
20
Www.sparkasse-siegen.de/einlagensicherung
21
22
: Über diese gesetzliche Einlagensicherung hinaus bleibt die Instituts-
23
24
sicherung der Sparkassen-Finanzgruppe bestehen. Durch diese soll der Ent-
25
26
\ schädigungsfall vermieden und die Geschäftsbeziehung zum Kunden dauerhaft
27
28
fortgeführt werden. Für Sie als Kundin/Kunde ändert sich somit nichts.
29
Für Fragen stehen Ihnen unsere Mitarbeiter gerne zur Verfügung.
Du kannst das Ergebnis von tesseract verbessern:
je größer die Zeichen sind, desto besser ist die erkennung.
beim scann gleich rein zoomen?
Das rumspielen mit dem Kontrast/farbumkehr kann ebenfalls sehr helfen.
Ich verwende auch tesseract für OCR. Noch 2 Tips: wenn Du etwas einscannst, dann nimm für das Bild am besten PNG als Format oder JPG ohne Kompression und stell die Auflösung auf mindestens 600 dpi
PNG als Format und [...] die Auflösung auf mindestens 600 dpi
Muss ich mal ausprobieren. Die Scans liegen erst einmal als PDF vor, um automatisch begradigt zu werden. Wenn Tesseract PDF nicht direkt unterstützt, wird natürlich PNG das Zwischenformat.
Bei meinen bisherigen Versuchen war 300 dpi für Farbscans der "Sweet spot" mit den wenigsten Fehlern, aber die Programme, die ich vorher ausprobiert habe, nutzen auch andere OCR-Engines. Ich habe aber extra schon Scans verschiedener Auflösungen als Testdaten vorbereitet.
Muss ich mal ausprobieren. Die Scans liegen erst einmal als PDF vor, um
automatisch begradigt zu werden. Wenn Tesseract PDF nicht direkt
unterstützt, wird natürlich PNG das Zwischenformat.
Tesseract kann kein PDF einlesen, also vorher konvertieren, unter Linux nehme ich pdftoppm aus den poppler-utils aber dafür gibt es ja x Möglichkeiten.
Weil es auf Kontoauszügen wohl fatal ist, wenn gemischte Zeichenketten
zu Wörtern "korrigiert" werden.
Dazu würde ich einfach mal eine Handvoll Deiner Kontoauszüge da durchjagen und mir die Resultate ansehen, bevor Du anfängst, Dinge zu optimieren, die möglicherweise gar nicht optimiert werden müssen.
Auf den ersten Blick sieht es so aus, als könne ein SW-Scan sogar besser als ein Farbscan sein, weil der Scannertreiber einen etwas besseren Algorithmus als "single treshold" nutzt.
Auch sieht es auf den ersten Blick so aus, dass man Tesseract keine weiteren "Contraints" mitgeben kann. Das Wissen, dass es sich um einen Textblock mit 76 x 22 Zeichen handelt, nützt mir also an dieser Stelle noch nichts (Erst später bei der Fehlerkontrolle).
Weil es auf Kontoauszügen wohl fatal ist, wenn gemischte Zeichenketten
zu Wörtern "korrigiert" werden.
Dazu würde ich einfach mal eine Handvoll Deiner Kontoauszüge da
durchjagen und mir die Resultate ansehen, bevor Du anfängst, Dinge zu
optimieren, die möglicherweise gar nicht optimiert werden müssen.
Nei der OCR-Erfassung von Kontoauszügen halte ich Wörterbücher für problematisch; man möchte im Output das haben, was das Programm im Scan an Zeichen meint sicher erkannt zu haben, nicht das, was das Programm als möglicherweise gemeint ansieht. Richtig fatal dürfte der Spaß bei Beträgen werden, wenn bei der Interpretation unbekannte Beträge durch bereits gelernte ersetzt werden.
OCR-B kommt einer zuverlässigen Einzelzeichenerkennung entgegen; sie ist darauf optimiert. So werden zB sonst häufige Verwechslungen im Bereich 1, i, l, I vermieden (Ich begreife nicht, warum Behörden darauf bestehen, nur noch in Arial zu kommunizieren; man sollte Fraktur zurückschreiben).
gimagereader ist eine GUI für tesseract, gibt es für Linux und Windows
https://github.com/manisandro/gImageReader
Sehr überzeugend ist die Erkennung ja nicht gelungen, die Auflösung sollte besser sein.
Ich suche deswegen gerade mehr in einer anderen Richtung. Ich habe mir gerade mal eine Testversion von OmniPage heruntergeladen, und das sieht extrem vielversprechend aus:
1
'-?-11.11111111.11g_
2
Kontoauszug 13
3
Blatt 6
4
Mitteilung 2 / Teil 1
5
Konto-Nr.
6
Sparkasse
7
Kundenhinweis
8
Information zur Einlagensicherung
9
10
Oruck 110 10899 2104-1001
11
12
7-
13
Auf der Grundlage einer EU-Richtlinie ist am 3. Juli 2015 in Deutschland das Einlagensicherungsgesetz in Kraft getreten. Aufgrund gesetzlicher Vorgaben sind wir verpflichtet, Sie einmal jährlich über die Einlagensicherung zu informieren und Ihnen den "Informationsbogen für den Einleger" zur Verfügung zu stellen. Dieser Bogen liegt für Sie in allen Geschäftsstellen bereit und kann auch auf unserer Hornepage eingesehen werden unter: www.sparkasse-siegen.de/einlagensicherung
14
Über diese gesetzliche Einlagensicherung hinaus bleibt d'e Institutssicherung der Sparkassen-Finanzgruppe bestehen. Durch diese soll der Entschädigungsfall vermieden und die Geschäftsbeziehung zum Kunden dauerhaft fortgeführt werden. Für Sie als Kundin/Kunde ändert sich somit nichts. Für Fragen stehen Ihnen unsere Mitarbeiter gerne zur Verfügung.
Das helle "i" wird nicht korrekt erkannt und "Hornepage" ist auch falsch, ansonsten ist das sehr gut. Die Zeilenumbrüche und die Einrückungen fehlen (noch?), aber ich bin gerade auch erst am Anfang.
Bei "echten" Kontoauszügen sind insbesondere alle Zahlen korrekt.
Was der PDF-Export daraus macht, finde ich auch recht beeindruckend. Nicht perfekt, aber beeindruckend (siehe PDF im Anhang).
Die OCR-Engine ist Abbby Finereader, genau wie bei PDFXChange Pro, das ich auch schon getestet habe. Aber hier scheint sie besser parametrierbar zu sein.
Ich werde aber später definitiv noch beide Systeme mit 600-DPI-SW-Scans testen.
Nei der OCR-Erfassung von Kontoauszügen halte ich Wörterbücher für
problematisch; man möchte im Output das haben, was das Programm im Scan
an Zeichen meint sicher erkannt zu haben, nicht das, was das Programm
als möglicherweise gemeint ansieht.
Gewiss. Aber statt vorgefertigte Meinungen und Vermutungen über die Funktion eines Programmes zu haben, kann man auch dessen Funktion /prüfen/.
Zumindest früher sah man Wissen als dem Glauben überlegen an; ist jetzt das Ende der Aufklärung erreicht?
Naja, bei Tesseract steht genau in der Doku über die Funktionsweise, dass Wahrscheinlichkeiten gebildet werden, welche Wörter von der Pixelwolke dargestellt werden sollten, und das wahrscheinlichste Wort ausgegeben wird. Hat den Vorteil, dass es sich nicht so leicht von Ligaturen aus dem Takt bringen lässt.
Gerade bei diesen Daten wäre es aber sinnvoller, wenn "einfach" für jede der 1672 möglichen Zeichenpositionen an fester Stelle das wahrscheinlichste Zeichen ausgegeben wird und eine Fehlermarkierung, falls das Zeichen nicht unter einer bestimmten Fehlerschranke sicher ist.
gimagereader/tesseract hat auch eine Erkennung von Frakturschrift, was man für Kaufsoftware nur teuer als Zusatzpaket bekommt. Ich habe damit mal ein paar Seiten aus einem Adressbuch von 1919 gescannt. Durch die Tabellenspalten und die damaligen sehr individuellen Gewohnheiten des Schriftsetzers war das etwas schwierig, viel manuelle Nacharbeit nötig.
Das Haus meines Urgroßvaters steht drin und die Wohnung des Kapellmeisters Furtwängler, laut Wikipedia ein Großonkel der Tatortkommissarin. Am Erdgeschoss (das einzige was die Bomben übrigliessen, Nähe Hauptbahnhof) hängt heute eine Bronzetafel, dass der dort von 1915 bis 1919 wohnte. Laut Adressbuch im 4 OG.
P.S. hat nichts mit dem Thema zu tun, gerade wiedergefunden:
https://www.rnf.de/cmms-embed/20213
ein Lehrfilm der Royal Airforce mit Aufnahmen des nächtlichen Luftangriffs Sept.1943 aus Sicht der Piloten.
Gerade bei diesen Daten wäre es aber sinnvoller, wenn "einfach" für jede
der 1672 möglichen Zeichenpositionen an fester Stelle das
wahrscheinlichste Zeichen ausgegeben wird und eine Fehlermarkierung,
falls das Zeichen nicht unter einer bestimmten Fehlerschranke sicher
ist.
Sparkasse Blatt 6
Kundenhinweis Mitteilung 2.07> Ter 4
Information zur Einlagensicherung
Auf der Grundlage einer EU-Richtlinie ist am 3. Juli 2015 in Deutschland
das Einlagensicherungsgesetz in Kraft getreten. Aufgrund gesetzlicher Vor-
_ gaben sind wir verpflichtet, Sie einmal jahrlich Uber die Einlagensicherung
= zu informieren und Ihnen den “Informationsbogen flr den Einleger”™ zur Ver-
flugung zu stellen. Dieser Bogen liegt fiir Sie in allen Geschaftsstellen
® bereit und kann auch auf unserer Homepage eingesehen werden unter:
o WWW.Sparkasse-siegen.de/einlagensicherung
° Uber diese gesetzliche Einlagensicherung hinaus bleibt die Instituts-
sicherung der Sparkassen-Finanzgruppe bestehen. Durch diese soll der Ent-
| schadigungsfall vermieden und die Geschaftsbeziehung zum Kunden dauerhaft
fortgefihrt werden. Fur Sie als Kundin/Kunde andert sich somit nichts.
Fir Fragen stehen Ihnen unsere Mitarbeiter gerne zur VerfUgung.
Umlaute Fehlanzeige? Welche Sprache war eingestellt?
Olivers große Kopiererverschwörung habe ich noch nicht angeschaut:
"Im August 2013 kam heraus, dass so gut wie alle Xerox-Scankopierer beim Scannen Zahlen und Buchstaben einfach so durch andere ersetzen."
Nur ein Hinweis an die, die das geschwärzte Beispielbild als Test benutzen: ihr solltet vorher die geschwärzten Bereiche durch die normale Hintergrundfarbe oder ein mittleres Grau ersetzen. Dieses 100% Black behindert das globale Preprocessing (Histogram Normalization etc) und kann zu verminderter Erkennungsrate führen.
Gewiss. Aber statt vorgefertigte Meinungen und Vermutungen über die
Funktion eines Programmes zu haben, kann man auch dessen Funktion
prüfen.
Könnte man. Dann hätte man für den numerus clausus der getesteten Eingaben eine Auskunftcüber die Zuverlässigkeit. Und darf man hoffen, dass die Kontextinterpretation, was ein Wörterbuch immer ist, für die unendlich vielen andwren Eingaben hinreichend zuverlässig arbeitet. Hinreichend in diesem Anwendungsfalk: null Fehler. Never ever.
Zumindest früher sah man Wissen als dem Glauben überlegen an; ist jetzt
das Ende der Aufklärung erreicht?
Es scheint mittlerweile Zeitgenossen zu geben, die glauben, sie könnten einem Wörterbuch vertrauen und damit sogar die Erkennung verbessern, ohne es wissen zu können. Für andere liegt auf der Hand, dass eine kontextabhängige Interpretation von Randoms, und um nichts anderes handelt es sich bei Ziffern, allenfalls geeignet ist, Fehler zu vertuschen, statt sie zu korrigieren.
Jetzt 1:03:39 später, der Videovortrag vom CCC 2013 aus Olivers Link ist anschauenswert, wer die Zeit dafür übrig hat.
Eine Verschwörungstheorie zu Obamas Geburtsurkunde wurde damit auch entkräftet.
Wenn man dem Ding noch den Parameter "-c preserve_interword_spaces=1" mitgibt, bleibt auch die Formatierung mit Leerzeichen erhalten, wie oben schon gezeigt.
Im gesamten Thread taucht das Wort "Training" nicht auf, deshalb hier mein Hinweis: Es gibt wohl die Möglichkeit, Tesseract speziell auf Schriftart(en) zu trainieren, es soll auch Tools dafür geben!
Vielleicht wäre es besser, wenn Tesseract nicht 4000 Schriften kennt, sondern nur eine oder zwei?
Übrigens: Der Tesseract-Code stammt aus einem ursprünglich kommerziellen Projekt von HP. Als dieses eingestampft wurde, tat es den Entwicklern leid, die darin steckende Arbeit einfach wegzuwerfen und so fand es seinen Weg in die frei Wildbahn. Wie lange da nun schon freie Entwickler daran herumwerkeln, ist mir nicht bekannt. Vielleicht war das nicht in jedem Falle von Vorteil?
Ich würde auch mal die Demoversionen kommerzieller Software testen, z.B. "Readiris". Damit haben wir in der Firma mehrere tausen Ordner mit papiernen Mietverträgen für eine Wohnungsverwaltung digitalisiert. Die waren sehr zufrieden.
Gerade bei diesen Daten wäre es aber sinnvoller, wenn "einfach" für jede
der 1672 möglichen Zeichenpositionen an fester Stelle das
wahrscheinlichste Zeichen ausgegeben wird und eine Fehlermarkierung,
falls das Zeichen nicht unter einer bestimmten Fehlerschranke sicher
ist.
Vor Jahren, als TANs noch auf Papier gedruckt angeflogen kamen, habe ich die immer eingescannt und OCRt. Das war ein ziemlich simples Tool, man musste es mit dem tatsächlichen Font anlernen – aber das könnte für deinen Fall ja durchaus die sinnvollere Wahl sein.
Natürlich musste man hinterher nochmal drüber schauen, ob alles wirklich passt, aber alles zusammen ging das viel schneller, als wenn ich alle TANs abgeschrieben hätte.
Habe gerade mal geschaut, welche Überreste ich davon noch finden konnte, es dürfte sich um Clara OCR gehandelt haben.
Wenn man dem Ding noch den Parameter "-c preserve_interword_spaces=1"
mitgibt, bleibt auch die Formatierung mit Leerzeichen erhalten, wie oben
schon gezeigt.
Für Kontoauszüge scheint noch "--psm 6" essentiell zu sein, ansonsten wird bei einzelnen Seiten ein mehrspaltiges Layout angenommen.
Meine Kommandozeile sieht also momentan so aus:
1
REM --psm 6 : Als Textblock betrachten
2
REM -l deu : Ohne deutsche Trainingsdaten werden Umlaute nicht erkannt
3
REM Das Postfix ".txt" wird automatisch an die Zieldatei angehaengt
4
5
set TESSDATA_PREFIX=C:\Program Files\Tesseract-OCR\tessdata
6
"C:\Program Files\Tesseract-OCR\tesseract.exe" ./Kontoauszug_2023-13_fuer_ocr_Seite_1.png Kontoauszug_2023-13_Tesseract_Seite_1 -c preserve_interword_spaces=1 -l deu --psm 6
Dann habe ich die Scans noch auf 600 dpi SW umgestellt. Das spart gegenüber dem 300-DPI-Farb-Scan viel Zeit und die Erkennungsrate ist sogar besser.
Die Scans werden im Scan-Programm (Paperport) begradigt und beschnitten.
Ich bin vom Ergebnis erst einmal begeistert. Die Fehlerquote scheint ähnlich gering zu sein wie bei Omnipage, aber dadurch, dass sich Tesseract gut scripten lässt, spart das natürlich viel Klickarbeit.
Das war ein ziemlich simples Tool, man
musste es mit dem tatsächlichen Font anlernen – aber das könnte für
deinen Fall ja durchaus die sinnvollere Wahl sein.
Intuitiv würde ich auch sagen, dass ein "klassisches" Zeichenbasiertes OCR hier extrem gut funktionieren kann.
Erst einmal teste ich das jetzt mit Tesseract (niedrig hängende Früchte) und Omnipage (begrenzter Testzeitraum).
Im gesamten Thread taucht das Wort "Training" nicht auf, deshalb
hier
mein Hinweis: Es gibt wohl die Möglichkeit, Tesseract speziell auf
Schriftart(en) zu trainieren, es soll auch Tools dafür geben!
Es gibt sogar fertige ocrb-Trainingsdateien. Die Qualität ist allerdings unbekannt.
Ich suche deswegen gerade mehr in einer anderen Richtung. Ich habe mir
gerade mal eine Testversion von OmniPage heruntergeladen, und das sieht
extrem vielversprechend aus:
...
Das helle "i" wird nicht korrekt erkannt und "Hornepage" ist auch
falsch, ansonsten ist das sehr gut. Die Zeilenumbrüche und die
Einrückungen fehlen (noch?), aber ich bin gerade auch erst am Anfang.
Bei "echten" Kontoauszügen sind insbesondere alle Zahlen korrekt.
Was der PDF-Export daraus macht, finde ich auch recht beeindruckend.
Nicht perfekt, aber beeindruckend (siehe PDF im Anhang).
Die OCR-Engine ist Abbby Finereader, genau wie bei PDFXChange Pro, das
ich auch schon getestet habe. Aber hier scheint sie besser
parametrierbar zu sein.
Ich werde aber später definitiv noch beide Systeme mit 600-DPI-SW-Scans
testen.
Da habe ich doch gleich mal eine alte VM mit Win ME ;-) reaktiviert, dort meinen uralt-Abbyy Finereader Pro 5.0 installiert, das schon damals (vor 20 Jahren oder so) recht gute Ergebnisse bei bunten Zeitschriften brachte, und Dein jpeg ohne weitere Vorverarbeitung durchgejagt. Das Ergebnis ist sogar besser als bei Dir - aus "Mitteilung" wurde "Mittellung" (das i war ein bißchen schwach), das wars an Fehlern. Dann habe ich dem noch gesagt, das sei Schreibmaschinenschrift - Ergebnis nun 100% richtig.
Gut, bei der senkrechten Schrift links musste ich dem sagen, daß es da auch was in senkrechter Form zu erkennen gibt, dann wurde zumindest "ClimatePartner klimaneutral" erkannt (die kleine Drucknummer war zu klein).
Ich habe den Eindruck, die ganze OCR-Geschichte hat sich wohl nicht sehr vorwärts bewegt die letzten 20 Jahre, oder täuscht das? Ich hatte eigentlich gedacht, daß die heutigen Tools so einen guten Scan inzw. mit links machen können ...
Ich habe den Eindruck, die ganze OCR-Geschichte hat sich wohl nicht sehr
vorwärts bewegt die letzten 20 Jahre, oder täuscht das?
Ich vermute das Gegenteil. Nur ist modernes OCR eben auch auf moderne Schriften mit Ligaturen ausgelegt.
Das moderne Abbyy Finereader finde ich vom Lizenzmodell unattraktiv, da es nur Abos gibt. Sowohl PDFXChange Editor als auch Omnipage nutzen die Finereader-Engine und sind als Kaufprogramme erhältlich, allerdings lässt sich das OCR anscheinend bei beiden nicht nochmal separat konfigurieren.
Die 5.0 scheint es allerdings für einen schmalen Taler noch gebraucht zu geben. Oder ich finde jemanden, der die C'Ts von 2004 noch nicht weggeworfen hat...
Hier meine Fraktur-Testseite, Adressbuch 1919, in Haus-Nr.13 wohnte der Herr Kapellmeister im 4.OG
Der Versuch mit gimagereader auf Fraktur-Deutsch ist nicht überzeugend:
: 13 E Wan, Friedr., Kfnı
Bender, 1. Staatdanım., 2
Ruppert, Aug., Ww 3
Surtwängler, Wilhelni
Kapellmeijter 4
14 E Riiebikih. Sohannea.
Die Glasmalerei in Nr. 14 hat Kirchenfenster hergestellt, die heute noch in der Pfalz bis Mainz existieren. "h1" dürfte Hinterhof bedeuten, da stehen heute nur noch Garagen.
OCR ist ein mehrstufiger Prozess, auf den man nur bei Open Source-Software wirklich eine Chance auf Einfluss hat:
Zeilen isolieren (schwierig bei geringem Abstand oder schrägen Zeilen)
Zeichen isolieren (schwierig bei Ligaturen oder Unterschneidungen)
Zeichen erkennen (müssen angelernt werden)
Wortgrenzen erkennen
Zeichen zu Worten zusammenfassen, Abgleich/Korr. mit Wortstamm-Datenbank
Worte aneinander reihen, abgleich mit Grammatik-Engine, heute KI/LLM
Wahrscheinlichkeit für sinnvolle Sätze bestimmen, ggf. korrigieren
Das Meiste davon greift bei rein "technischen" Daten bzw. Dokumenten (z.B. Kontoauszüge), jenseits von Prosa, ins Leere, zumindest ab Punkt 5 ff. Dann werden die Ergebnisse eher "verschlimmbessert".
Für Kontoauszüge sollte man nach der reinen Zeichenerkennung aufhören ...
Damals war Mannheim nur ein Dorf von vielen. Die Stadtgründung war erst 1607. Der Kurfürst kam 1607 zur Grundsteinlegung am Vortag zu Pferd aus Heidelberg und übernachtete in einer kleinen Festung. Dabei wurde wohl schon mal kräftig vorgefeiert. Die Zeremonie begann recht spät am Folgetag und der Kurfürst fiel fast vom Pferd, da muss der Restalkohol noch gewirkt haben.
Ich betrachte das Problem als gelöst. Tesseract liefert insbesondere bei schwachen Ausdrucken mit Streifen eine ziemlich hohe Fehlerrate. Insbesondere werden gerne die Ziffern '5' und '6' falsch gelesen.
Insgesamt liefert aber das Ganze ist immer noch eine brauchbare Unterstützung und sparte gegenüber dem reinen Abtippen oder der Klickerei in Omnipage viel Zeit, so dass ich mein Ziel erreicht habe.
Ich hatte das ganze noch in ein kleines Script gepackt, das in den shell:sendto Order kam.
Danke für die hilfreichen Beiträge.
Ihr könnt also gerne den Thread anderweitig weiterverwenden, um über den Buchbinder Wanniger in der Rennershofstraße und seinen Gegenpapst diskutieren.
Na, freut mich, wenigstens ein kleines Bisschen zur Lösung beigetragen haben zu können. Tesseract war mir zwar vor längerer Zeit schonmal irgendwie über den Weg gelaufen, praktisch genutzt habe ich es aber erst vor ein paar Monaten, und da war ich davon recht angetan (sonst hätte ich es Dir gegenüber ja auch nicht erwähnt).
Opensource mag ich auch. Komandozeilengesteuert auch, aber nur als Möglichkeit.
Bei so einer Sache wie OCR mit prinzipiell sehr komplexer Parametrierung wäre es aber immer sinnvoll, wenn der Kram sich auch interaktiv mit einem brauchbaren GUI parametrieren lässt. Natürlich inclusive der Möglichkeit, die gefundene optimale Parametrierung für den Anwendungsfall dann so abzuspeichern, dass sie sich später "en block" zur Verwendung per CLI-Aufruf wiederverwenden läßt.
So sind richtig gute Programme gestrickt...
Ausschließliche Bedienmöglichkeit per CLI hingegen ist die Hölle. Das mag ich nicht. Das geht mir auf den Sack. Das ist unzumutbarer Steinzeitdreck.
Ausschließliche Bedienmöglichkeit per CLI hingegen ist die Hölle. Das
mag ich nicht. Das geht mir auf den Sack. Das ist unzumutbarer
Steinzeitdreck.
Aha. Niemand hindert Dich daran, ein Gui-Tool für Tesseract zusammenzuklimpern; allerdings, wenn Dich das Lesen der Dokumentation so grundlegend überfordert, dann scheinst Du nicht der geeignete Kandidat dafür zu sein.
Welches Problem würde eine GUI hier lösen? Daß man per Checkbox die zu setzenden Kommandozeilenparameter setzen kann (und nicht in der Dokumentation nachlesen muss, welche es gibt)?
Wie oben bereits geschrieben, gibt es mindestens eine GUI für Tesseract.
Die neueren Ghostscript-Versionen kann man auch mit Tess verknüpfen.
So kann man einfach durchsuchbare und kopierbare PDF erzeugen aus welchen, die das nicht vorsehen.
Leider werden diese manchmal größer.
Tess hat eine Unmenge (>600) an Variablen, mit denen man Details einstellen kann:
C:\Programs\tess533>tesseract --print-parameters
CLI-Parameter sind z.B. --oem und --psm
1
C:\Programs\tess533>tesseract --help-oem
2
OCR Engine modes:
3
0 Legacy engine only. %dafür braucht man ein spezielles .traineddata
4
1 Neural nets LSTM engine only.
5
2 Legacy + LSTM engines.
6
3 Default, based on what is available.
7
8
C:\Programs\tess533>tesseract --help-psm
9
Page segmentation modes:
10
0 Orientation and script detection (OSD) only.
11
1 Automatic page segmentation with OSD.
12
2 Automatic page segmentation, but no OSD, or OCR. (not implemented)
13
3 Fully automatic page segmentation, but no OSD. (Default)
14
4 Assume a single column of text of variable sizes.
15
5 Assume a single uniform block of vertically aligned text.
16
6 Assume a single uniform block of text.
17
7 Treat the image as a single text line.
18
8 Treat the image as a single word.
19
9 Treat the image as a single word in a circle.
20
10 Treat the image as a single character.
21
11 Sparse text. Find as much text as possible in no particular order.
22
12 Sparse text with OSD. <---- interessant!!
23
13 Raw line. Treat the image as a single text line,
24
bypassing hacks that are Tesseract-specific.
Anbei ein seltenes PDF, Tektronix hatte in den 1970ern versucht, in (C)NC einzusteigen. Das PDF habe ich mit
gswin32c.exe -sDEVICE=pdfocr8 -r600 -dDownScaleFactor=2 -oTek_numocr.pdf Tek_numerical_control_introduction.pdf
erzeugt.
Die .txt ist etwas bearbeitet, weil die Ränder als Buchstaben interpretiert wurden. Der Text wurde sehr gut erkannt; nur häufig , statt .
Tess hat eine Unmenge (>600) an Variablen, mit denen man Details
einstellen kann:
Vielleicht habe ich die Doku falsch gelesen, aber für mich sah das so aus, dass der Großteil der Parameter Überreste aus "legacy"-Versionen sind und von der aktuellen Version getrost ignoriert werden.
Tess hat eine Unmenge (>600) an Variablen, mit denen man Details
einstellen kann:
Vielleicht habe ich die Doku falsch gelesen, aber für mich sah das so
aus, dass der Großteil der Parameter Überreste aus "legacy"-Versionen
sind und von der aktuellen Version getrost ignoriert werden.
Ja, so ist das mit OSS. Die verfügbare Doku taugt wenig bis garnix. Praktisch immer völlig veraltet.
Und selbst, wenn sie ausnahmsweise mal aktuell ist: Nur für jemanden, der direkt im Thema steht, irgendwie lesbar und nutzbringend. Und der Mensch sollte nicht nur bezüglich des Themas der Anwendung im Stoff stehen, sondern darüber hinaus die Formalien der Dokumentation von CLI-Parametern beherschen. Sonst wird das immer noch nix.
Reines CLI-Interface ist prähistorische Vollscheiße.
Mit eine brauchbaren GUI kann der User halt rumpröbeln, um zum gewünschten Effekt zu kommen. Er braucht sich nicht mit diesen endlos öden Details zu belasten, wie die Scheiße funktioniert und wie die Paramter CLI-mäßig jeweils zu formulieren wären. Das GUI hat zumindest letzteres zu wissen. Wer könnte das besser in eine GUI einbauen, als der Schöpfer der eigentlichen Anwendung? Der kennt natürlich die Funktionsweise seiner Software immer am Besten von allen.
Blocktext.jpg
(390 KB)
