OCR zur Texterkennung

[michamilz]

Zur Extraktion des Inhalts von PDF Dokumenten wird pdftotext genutzt. Das funktioniert bei den meisten Dokumenten ausgezeichnet. Im Schweriner BIS finden sich aber auch PDFs mit gescannten Inhalten. Diese können durch pdftotext nicht extrahiert werden. Eventuell kann eine freie OCR Software für diese Fälle genutzt werden.

[marians]

@michamilz Du hast absolut Recht! Auch im Kölner RIS gibt es gescannte Dokumente, deren Inhalte bislang vor der Suche versteckt bleiben.

Ich habe vor einigen Wochen ein paar Stunden auf die Suche nach einer Open-Source-Lösung verwendet. Leider habe ich dabei nichts gefunden, was ohne größeren Aufwand einsetzbar wäre. Wie es scheint, muss man eine OCR-Software erst mal trainieren, und zwar in zweierlei Hinsicht: Zum einen auf die verwendeten Schriftarten und außerdem auf die verwendete Sprache.

Eine fertig konfigurierte OCR-Lösung für deutsche Sprache, die auf die häufigsten Schriften trainiert ist (ich vermute mal Times New Roman und Arial decken zusammen mehr als 90% ab) wäre von ihrem Nutzen her so universell, dass sie meines Erachtens nicht als Teil eines SessionNet-Scrapers entwickelt werden sollte, sondern wenn als eigenständige Software.

Bevor wir uns darauf stürzen, sollten wir aber erst mal die Suche nach bestehenden Lösungen ausweiten.

[michamilz]

Vollkommen richtig.

Ich bin über tesseract gestolpert. http://code.google.com/p/tesseract-ocr In den Downloads http://code.google.com/p/tesseract-ocr/downloads/list gibt es eine Datei mit Trainingsdaten für die deutsche Sprache.

[marians]

Interessant! tesseract werd ich mir mal ansehen.

Ich hab die Frage mal in die Runde geschickt.

https://twitter.com/#!/offeneskoeln/status/170151375009882115
https://plus.google.com/u/0/112316445308833330556/posts/JU3D4nuLrfS

Aber wie ich sehe, hast Du ( @michamilz ) das schon bemerkt ;-)

Wir benötigen übrigens sorgfältig transskribierte Testdokumente, um die Qualität der Softwares beurteilen zu können. Finden wir freiwillige, die sowas machen wollen? Es gibt doch immer ein paar nicht-Coder, die gerne helfen würden, oder?

[marians]

Hier sind ein paar Testdokumente aus dem Kölner Bestand:

http://offeneskoeln.de/attachments/3/1/jpg292013.jpg
http://offeneskoeln.de/attachments/2/2/jpg292022.jpg
http://offeneskoeln.de/attachments/8/2/jpg292028.jpg
http://offeneskoeln.de/attachments/2/4/pdf345442.pdf
http://offeneskoeln.de/attachments/4/4/pdf345444.pdf
http://offeneskoeln.de/attachments/7/5/pdf345457.pdf
http://offeneskoeln.de/attachments/0/9/jpg344790.jpg
http://offeneskoeln.de/attachments/7/1/pdf344617.pdf
http://offeneskoeln.de/attachments/2/8/pdf119482.pdf
http://offeneskoeln.de/attachments/6/2/pdf130726.pdf
http://offeneskoeln.de/attachments/7/2/pdf130727.pdf

Erledigt:
http://offeneskoeln.de/attachments/0/6/pdf345460.pdf
http://offeneskoeln.de/attachments/8/9/pdf121798.pdf
http://offeneskoeln.de/attachments/1/1/jpg292011.jpg
http://offeneskoeln.de/attachments/4/2/pdf344624.pdf
http://offeneskoeln.de/attachments/4/4/pdf129244.pdf
http://offeneskoeln.de/attachments/4/7/pdf345174.pdf
http://offeneskoeln.de/attachments/8/5/pdf345458.pdf

[michamilz]

Ich steure mal diese Testdokumente bei:

[026_StV_2012_Anfrage_Fraktion_Unabhaengige_Buerger_(Lernatlas_2.pdf](http://lab.seitenmanufaktur.info/projekte/bis-scraper/ocr-test/026_StV_2012_Anfrage_Fraktion_Unabhaengige_Buerger_(Lernatlas_2.pdf)
026_StV_2012_Antwort_der_Oberbuergermeisterin_zur_Anfrage_Frakt.pdf

Ich frage bei uns in der Liste mal nach Freiwilligen.

[marians]

Fantastisch!

[marians]

Ich habe es nach mehreren erfolglosen Versuchen geschafft, tesseract zu kompilieren und zu testen (SVN-Version unter Ubuntu 11).

Hier sind die Ergebnisse der ersten 5 Dateien: https://gist.github.com/1846939

Die Dateinamen beziehen sich auf obige Testdokumente, die nun auch im Repository unter ocr-test liegen (https://github.com/marians/cologne-ris-scraper/tree/master/ocr-test/orig).

Nach Augenschein: Es kommt schon mal was raus. Aber es gibt auch viele Fehler.

Ich würde das gerne anhand von exakt abgetippten Referenzdateien beziffern. Dann kann man auch testen, welche Einstellungen sich besser eignen und welche weniger gut.

[marians]

Es gibt nun ein Script im repository namens ocr-test/differenz.py, mit dem kann die Abweichung zwischen der Referenz-Datei und der von tesseract bzw. einer anderen OCR-Software ausgegebenen Datei berechnet werden. Kleiner ist besser.

Bisher haben wir zwei Referenz-Dateien. Mit tesseract komme ich auf die folgenden Ergebnisse:

344624.txt: 452 von 1655 Zeichen (27.3%)
292011.txt: 224 von 1108 Zeichen (20.2%)

Das script ruft man so auf: differenz.py <Pfad_A> <Pfad_B>. Die Reihenfolge der Parameter spielt keine Rolle. Als Bezugslänge wird die längere der beiden Dateien verwendet.

[marcel12bell]

Gerade entdeckt: wenn man die Dateien vorher mit imagemagic (convert -density 300 -depth 4) bearbeitet, kommt man auf 8-9%...

[marians]

Das ist interessant! Denn die Urspungsdokumente haben eine deutlich niedrigere Auflösung.

344624: 114 dpi
292011: 150 dpi

[marcel12bell]

Da wird wohl bei der Konvertierung ein wenig imagemagic-Puder auf die Datei getan... ;-)
Bei 344624 sind es auch nur 18.5%
Bei 292011 sind es nur 23% (schlechter als dein Ergebnis)
Ich habe mit 121798 gearbeitet und wahrscheinlich ist die Einstellung nur dafür optimal. Aber man sieht was möglich ist...

[marians]

Ich habe neue Referenz-Dokumente hinzugefügt.

Eines der Dokumente (382656) hat einen mehrspaltigen Teil und einen mehrseitigen Tabellenteil. Für die OCR-Software als auch für den menschlichen Abschreiber stellt sich hier die Frage, in welcher Reihenfolge man die Texthäppchen erfasst. Bei solchen Dokumenten halte ich es für möglich, dass trotz einer genauen Erfassung von einzelnen Wörtern eine starke Abweichung zwischen Referenz und OCR-Ergebnis erreicht wird.

Wenn wir für die Suche vor allem an Einzelbegriffen interessiert sind, könnten wir einen weiteren Weg der Differenz-Messung wählen: Wir zerschneiden zuerst Referenz und OCR-Ergebnis in Einzelwörter, entfernen Satzzeichen, sortieren die Wortliste und vergleichen dann.

Außerdem tendiere ich dazu, die JPEG-Dateien, die von PDFs extrahiert wurden, aus dem ocr-test Order im Repository zu entfernen. Die Erzeugung solcher JPEGs ist schließlich ein wesentlicher Bestandteil des OCR-Processes und hat, wie wir gesehen haben, größeren Einfluss auf das Ergebnis. @marc12bell - bist Du einverstanden?

[marians]

Ich habe differenz.py geändert. Die Texte werden nun vor dem Vergleich in Kleinbuchstaben umgewandelt und Interpunktion und Leerzeichen werden weitgehend entfernt. Damit soll das Ergebnis eher das wiederspiegeln, was wir mit der Erkennung erreichen wollen.

Die ausgegebenen Prozent-Werte sollten jetzt bei gleichem Input niedriger sein als zuvor.

Der Ansatz, wie oben beschrieben die Einzelwörter als sortierte Liste zu vergleichen, hat nichts gebracht. Die Differenz war dabei in allen Fällen größer als beim bisherigen Vergleich. Warum auch immer.

[marians]

Hier zum Vergleich ein paar Werte von Acrobat Pro, mit den Default-Einstellungen (umrechnen auf 300 dpi):

129244: Differenz 175 von 1181 Zeichen (14.8%)
121798: Differenz 254 von 1941 Zeichen (13.1%)
344624: Differenz 231 von 1591 Zeichen (14.5%)
345174: Differenz 256 von 917 Zeichen (27.9%)
345458: Differenz 248 von 1471 Zeichen (16.9%)
345460: Differenz 194 von 1437 Zeichen (13.5%)
359812: Differenz 23 von 1775 Zeichen (1.3%)
368517: Differenz 138 von 1670 Zeichen (8.3%)
382656: Differenz 2708 von 10552 Zeichen (25.7%)

Das sind im Mittel 15,1 Prozent bei einer Standardabweichung von 8,08 Prozentpunkten.

Wenn wir das mit automatisierten Mitteln erreichen, können wir sehr zufrieden sein, denke ich.

[marcel12bell]

@marians ok & denke ich auch...