OCR zur Texterkennung - Githubissues

michamilz commented 12 years ago

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 commented 12 years ago

@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 commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

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

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 commented 12 years ago

Ich steure mal diese Testdokumente bei:

[026_StV_2012_Anfrage_Fraktion_UnabhaengigeBuerger(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 commented 12 years ago

Fantastisch!

marians commented 12 years ago

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 commented 12 years ago

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 commented 11 years ago

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

marians commented 11 years ago

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

344624: 114 dpi 292011: 150 dpi

marcel12bell commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

@marians ok & denke ich auch...

marians commented 11 years ago

Habe differenz.py noch mal erweitert. Man kann nun wahlweise zwei Dateinamen wie bisher als Argumente übergeben, oder neu, zwei Ordnernamen. Beispiel:

python differenz.py acrobat referenz

Damit werden alle Dateien in den beiden Verzeichnissen namens 'acrobat' und 'referenz', deren Namen identisch sind, mit einander verglichen.

Die Ausgabe sieht dann so aus:

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

Die Standardabweichung im Kommentar weiter oben war aus Excel. Ich würde der hier eher vertrauen.

marians commented 11 years ago

Das könnte für die Normalisierung von schlechten Scans gut zu gebrauchen sein:

http://scikit-image.org/docs/dev/auto_examples/plot_threshold_adaptive.html#example-plot-threshold-adaptive-py

akuckartz commented 9 years ago

Die Umwandlung von eingescannten Dokumenten in Text-Dokumente ist potentiell auch für Kommunen selbst interessant - insbesondere aufgrund der sonst praktisch kaum möglichen Recherche-Möglichkeiten.

marians / cologne-ris-scraper

OCR zur Texterkennung #7