OCR für Monospace-Schrift

[Walter T. (nicolas)]

Guten Morgen,

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.

[Harald K. (kirnbichler)]

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:

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:

BUU AFFE REN

19] ClimatePartner

klimaneutral

Paner

Sparkasse                                                        Blatt    6
Kundenhinweis                                      Mitteilung    2: Je Teilııt
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 jährlich über die Einlagensicherung
zu informieren und Ihnen den "Informationsbogen für den Einleger” zur Ver-
fügung zu stellen. Dieser Bogen liegt für Sie in allen Geschäftsstellen
bereit und kann auch auf unserer Homepage eingesehen werden unter:

 Www.sparkasse-siegen.de/einlagensicherung

: Über diese gesetzliche Einlagensicherung hinaus bleibt die Instituts-

sicherung der Sparkassen-Finanzgruppe bestehen. Durch diese soll der Ent-

\ schä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.

Viel Erfolg!

*) https://github.com/tesseract-ocr/tesseract,
Installer für Windows 
https://digi.bib.uni-mannheim.de/tesseract/tesseract-ocr-w64-setup-5.3.3.20231005.exe

[Walter T. (nicolas)]

Danke für den Hinweis. Bis gerade ging ich davon aus, dass Tesseract ein 
SDK sei, und sich nicht einfach über die Kommandozeile aufrufen ließe.

Dann muss ich mal ausprobieren, ob sich das Wörterbuch komplett 
abschalten lässt.

[Kaj G. (Firma: RUB) (bloody)]

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.

[Harald K. (kirnbichler)]

Walter T. schrieb:
> Dann muss ich mal ausprobieren, ob sich das Wörterbuch komplett
> abschalten lässt.

Ja, aber warum sollte man das wollen?

[Stephan S. (uxdx)]

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

[Walter T. (nicolas)]

Harald K. schrieb:
> Ja, aber warum sollte man das wollen?

Weil es auf Kontoauszügen wohl fatal ist, wenn gemischte Zeichenketten 
zu Wörtern "korrigiert" werden.

Stephan S. schrieb:
> 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.

[Stephan S. (uxdx)]

Walter T. schrieb:
> 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.

[Harald K. (kirnbichler)]

Walter T. schrieb:
> Wenn Tesseract PDF nicht direkt unterstützt

Das tut es natürlich. Und Dein Beispielbild hat auch genügende 
Auflösung.

Es sollte vielleicht vor dem Scan beschnitten werden, denn der vertikale 
Text am linken Rand ist auch von der OCR erfasst worden (s.o.)

Walter T. schrieb:
> 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.

[Walter T. (nicolas)]

Dafür arbeite ich mich gerade durch die Doku.

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).

[Percy N. (vox_bovi)]

Harald K. schrieb:
> Walter T. schrieb:
>> 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).

[Christoph db1uq K. (christoph_kessler)]

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.

[Walter T. (nicolas)]

Tesseract scheint generell Probleme mit Texten zu haben, die nicht zu 
Wörterbüchern passen.

Simple monospace text not correctly interpretted #2820:
https://github.com/tesseract-ocr/tesseract/issues/2820

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:

    '-?-11.11111111.11g_
      Kontoauszug  13
      Blatt  6
    Mitteilung  2 / Teil 1
Konto-Nr.    
Sparkasse    
Kundenhinweis    
Information zur Einlagensicherung    
  
  Oruck 110 10899 2104-1001
  
7-
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
Ü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.

[Harald K. (kirnbichler)]

Percy N. schrieb:
> 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?

[Walter T. (nicolas)]

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.

[Christoph db1uq K. (christoph_kessler)]

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.

[Harald K. (kirnbichler)]

Walter T. schrieb:
> 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.

Hierbei hilft vielleicht das hier:

https://tesseract-ocr.github.io/tessdoc/Command-Line-Usage.html#hocr-output

https://kba.github.io/hocr-spec/1.2/

Da gibt es einen "confidence"-Wert (x_wconf), zwar nicht für einzelne 
Zeichen, aber für einzelne erkannte Wörter.

https://kba.github.io/hocr-spec/1.2/#x_wconf

[Oliver S. (oliverso)]

Ist zwar etwas OT, aber immer wieder schön:
https://youtu.be/7FeqF1-Z1g0?feature=shared

Oliver

[Franko S. (frank_s866)]

cat Blocktext.jpg |java -jar tika-app-2.9.1.jar
erkent:

INFO  [main] 16:03:57,018 org.apache.tika.parser.ocr.TesseractOCRParser 
Tesseract is installed and is being invoked. This can add greatly to 
processing time.  If you do not want tesseract to be applied to your 
files see: 
https://cwiki.apache.org/confluence/display/TIKA/TikaOCR#TikaOCR-disable-ocr
<?xml version="1.0" encoding="UTF-8"?><html 
xmlns="http://www.w3.org/1999/xhtml">;
<head>
<meta name="Resolution Units" content="inch"/>
<meta name="Number of Tables" content="2 Huffman tables"/>
<meta name="File Modified Date" content="Do. März 14 16:03:56 +01:00 
2024"/>
<meta name="Compression Type" content="Progressive, Huffman"/>
<meta name="Data Precision" content="8 bits"/>
<meta name="Number of Components" content="3"/>
<meta name="tiff:ImageLength" content="1233"/>
<meta name="Component 2" content="Cb component: Quantization table 1, 
Sampling factors 1 horiz/1 vert"/>
<meta name="Thumbnail Height Pixels" content="0"/>
<meta name="Component 1" content="Y component: Quantization table 0, 
Sampling factors 1 horiz/1 vert"/>
<meta name="Image Height" content="1233 pixels"/>
<meta name="Thumbnail Width Pixels" content="0"/>
<meta name="X Resolution" content="300 dots"/>
<meta name="Image Width" content="2456 pixels"/>
<meta name="File Size" content="386189 bytes"/>
<meta name="Content-Type-Parser-Override" content="image/ocr-jpeg"/>
<meta name="Component 3" content="Cr component: Quantization table 1, 
Sampling factors 1 horiz/1 vert"/>
<meta name="Version" content="1.1"/>
<meta name="X-TIKA:Parsed-By" 
content="org.apache.tika.parser.DefaultParser"/>
<meta name="X-TIKA:Parsed-By" 
content="org.apache.tika.parser.image.JpegParser"/>
<meta name="X-TIKA:Parsed-By" 
content="org.apache.tika.parser.ocr.TesseractOCRParser"/>
<meta name="File Name" content="apache-tika-15348064881531317815.tmp"/>
<meta name="tiff:BitsPerSample" content="8"/>
<meta name="tiff:ImageWidth" content="2456"/>
<meta name="Content-Type" content="image/jpeg"/>
<meta name="Y Resolution" content="300 dots"/>
<title/>
</head>
<body><div class="ocr">a0ov 277 44%

1] ClimatePartner

klimaneutral

Sparkasse Blatt 6
Kundenhinweis Mitteilung 2.07&gt; 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.
</div>

</body></html>

[Christoph db1uq K. (christoph_kessler)]

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."

[Oliver S. (oliverso)]

Franko S. schrieb:
> cat Blocktext.jpg |java -jar tika-app-2.9.1.jar
> erkent:

eher nicht so viel richtig.

Oliver

[Foobar (asdfasd)]

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.

[Percy N. (vox_bovi)]

Harald K. schrieb:
> 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.

[Christoph db1uq K. (christoph_kessler)]

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.

[Franko S. (frank_s866)]

tesseract Blocktext.jpg delme -l deu
Tesseract Open Source OCR Engine v4.1.1 with Leptonica
cat delme.txt

liefert:

BUU AFFE REN

„ ClimatePartner

klimaneutral

Sparkasse Blatt 6
Kundenhinweis Mitteilung 2: Je Teilıd
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 jährlich über die Einlagensicherung
= zu informieren und Ihnen den "Informationsbogen für den Einleger” zur Ver-
3 fügung zu stellen. Dieser Bogen liegt für Sie in allen Geschäftsstellen

& bereit und kann auch auf unserer Homepage eingesehen werden unter:

2 wWww.sparkasse-siegen.de/einlagensicherung

° Über diese gesetzliche Einlagensicherung hinaus bleibt die Instituts-
sicherung der Sparkassen-Finanzgruppe bestehen. Durch diese soll der Ent-
\ schä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.

[Franko S. (frank_s866)]

Vorher bearbeitet:
gecropped, per schwellwert nach schwarz/weiss gewandelt:
tesseract wie oben aufgerufen:

Konto-Nr, Kontoauszug 13
Sparkasse Blatt 6
Kundenhinweis Mitteilung 2 / Teilı1
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 jährlich über die Einlagensicherung
zu informieren und Ihnen den "Informationsbogen für den Einleger"” zur Ver-
fügung zu stellen. Dieser Bogen liegt für Sie in allen Geschäftsstellen
bereit und kann auch auf unserer Homepage eingesehen werden unter:
www.sparkasse-siegen.de/einlagensicherung

Über diese gesetzliche Einlagensicherung hinaus bleibt dıe Instituts-
sicherung der Sparkassen-Finanzgruppe bestehen. Durch diese sol] der Ent-
schädigungsfal] 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.

[Harald K. (kirnbichler)]

Franko S. schrieb:
> tesseract wie oben aufgerufen:

Wenn man dem Ding noch den Parameter "-c preserve_interword_spaces=1" 
mitgibt, bleibt auch die Formatierung mit Leerzeichen erhalten, wie oben 
schon gezeigt.

[Frank E. (Firma: Q3) (qualidat)]

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!

https://tesseract-ocr.github.io/tessdoc/tess4/TrainingTesseract-4.00.html#training-text-requirements

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.

[Jörg W. (dl8dtl) (Moderator)]

Walter T. schrieb:
> 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.

[Walter T. (nicolas)]

Harald K. schrieb:
> 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:

REM --psm 6 : Als Textblock betrachten
REM -l deu  : Ohne deutsche Trainingsdaten werden Umlaute nicht erkannt
REM Das Postfix ".txt" wird automatisch an die Zieldatei angehaengt

set TESSDATA_PREFIX=C:\Program Files\Tesseract-OCR\tessdata
"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.

Jörg W. schrieb:
> 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).

[Oliver S. (oliverso)]

Frank E. schrieb:
> 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.

Oliver

[Jens G. (jensig)]

Walter T. schrieb:
> 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 ...

[Walter T. (nicolas)]

Jens G. schrieb:
> 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...

[Harald K. (kirnbichler)]

Jens G. schrieb:
> Ich habe den Eindruck, die ganze OCR-Geschichte hat sich wohl nicht sehr
> vorwärts bewegt die letzten 20 Jahre, oder täuscht das?

Das täuscht. Du kannst ja mal versuchen, mit Deinem Finereader Fraktur 
zu lesen.

[Christoph db1uq K. (christoph_kessler)]

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.

[Frank E. (Firma: Q3) (qualidat)]

OCR ist ein mehrstufiger Prozess, auf den man nur bei Open 
Source-Software wirklich eine Chance auf Einfluss hat:

1. Zeilen isolieren (schwierig bei geringem Abstand oder schrägen 
Zeilen)
2. Zeichen isolieren (schwierig bei Ligaturen oder Unterschneidungen)
3. Zeichen erkennen (müssen angelernt werden)
4. Wortgrenzen erkennen
5. Zeichen zu Worten zusammenfassen, Abgleich/Korr. mit 
Wortstamm-Datenbank
6. Worte aneinander reihen, abgleich mit Grammatik-Engine, heute KI/LLM
7. 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 
...

[Christoph db1uq K. (christoph_kessler)]

Ich habe länger in Nr. 14 gewohnt, daher mein sehr lokales historisches 
Interesse.
Der Glasmaler steht in Wikipedia:
https://de.wikipedia.org/wiki/Johannes_Kriebitzsch
Und um die Ecke wurde mal ein Papst gefangengehalten, von 1416-1419:
https://de.wikipedia.org/wiki/Johannes_XXIII._(Gegenpapst)

[Harald K. (kirnbichler)]

Christoph db1uq K. schrieb:
> Und um die Ecke wurde mal ein Papst gefangengehalten, von 1416-1419:
> https://de.wikipedia.org/wiki/Johannes_XXIII._(Gegenpapst)

Es kann gar nicht genug Päpste geben.

[Christoph db1uq K. (christoph_kessler)]

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.

[Jens G. (jensig)]

Harald K. schrieb:
> Jens G. schrieb:
>> Ich habe den Eindruck, die ganze OCR-Geschichte hat sich wohl nicht sehr
>> vorwärts bewegt die letzten 20 Jahre, oder täuscht das?
>
> Das täuscht. Du kannst ja mal versuchen, mit Deinem Finereader Fraktur
> zu lesen.

Da hast Du zwar recht, ich meinte aber die Qualität der Erkennung bei 
bekannten Schriftarten, wie eben bei obigem Kontauszug.

[Walter T. (nicolas)]

Nachtrag:

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.

[Harald K. (kirnbichler)]

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. Kommandozeilengesteuert. Mag ich.

[Ob S. (Firma: 1984now) (observer)]

Harald K. schrieb:

> Opensource. Kommandozeilengesteuert. Mag ich.

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.

[Harald K. (kirnbichler)]

Ob S. schrieb:
> 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)?

[Torsten B. (butterbrotstern)]

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

C:\Programs\tess533>tesseract --help-oem
OCR Engine modes:
  0    Legacy engine only. %dafür braucht man ein spezielles .traineddata
  1    Neural nets LSTM engine only.
  2    Legacy + LSTM engines.
  3    Default, based on what is available.

C:\Programs\tess533>tesseract --help-psm
Page segmentation modes:
  0    Orientation and script detection (OSD) only.
  1    Automatic page segmentation with OSD.
  2    Automatic page segmentation, but no OSD, or OCR. (not implemented)
  3    Fully automatic page segmentation, but no OSD. (Default)
  4    Assume a single column of text of variable sizes.
  5    Assume a single uniform block of vertically aligned text.
  6    Assume a single uniform block of text.
  7    Treat the image as a single text line.
  8    Treat the image as a single word.
  9    Treat the image as a single word in a circle.
 10    Treat the image as a single character.
 11    Sparse text. Find as much text as possible in no particular order.
 12    Sparse text with OSD.    <---- interessant!!
 13    Raw line. Treat the image as a single text line,
       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 .

[Percy N. (vox_bovi)]

Walter T. schrieb:
> Insbesondere werden gerne die Ziffern '5' und '6' falsch gelesen.

Es soll Zeitgenossen geben, die dieses Problem getrost mit einem 
Wörterbuch erschlagen wollen ...

[Walter T. (nicolas)]

Torsten B. schrieb:
> 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.

[Ob S. (Firma: 1984now) (observer)]

Walter T. schrieb:
> Torsten B. schrieb:
>> 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.