Character Recognition

Vor gut zwei Jahren hab ich ja hier schon mal etwas zur Schrifterkennung geschrieben, das Programm cellwriter vorgestellt und einige Links rausgehauen. Mindestens seit der Zeit (aber eigentlich schon etwas länger) beschäftige ich mich hin und wieder mit dem Thema und irgendwann ist mir sogar unter der Dusche ein kleines Kriterium eingefallen, das einigermaßen dazu geeignet ist, einzelne geschriebene Zeichen (Glyphen) einem vorher trainierten Sample (und damit einem Zeichen/Character) zuzuordnen.

Genauer geht es hierbei um eine On-line Recognition und wie bei cellwriter um einzelne Zeichen, also ohne Segmentierung. Ich darf schon behaupten in den letzten Jahren viel rumprobiert zu haben: Angefangen mit einem kleinen Zeichenfeld in php-gtk, das einzelne svg-Bildchen auswarf, zwischendurch (weil es mit der Handschrift nicht so klappte) einige Tests mit Zeichen aus einem ttf, umgewandelt in bmp und svg, hier mal eine Änderung, da mal eine neue (Verbesserungs-)Idee (wieder unter der Dusche), schließlich dann mit xournal als Zeichenfläche, dessen xoj-Dateien ich in svg übersetzte, irgendwann dann mal HMMs probiert und in die Ecke geworfen, über CRM114 gestoplert, ein paar Verteilungen mit R berechnet, über SVMs nachgedacht und schließlich (wieder) bei Bayes gelandet. Gebastel, Gefrickel, ganz schlimm!

Inzwischen habe ich mir mit ruby und gtk ein kleines Programm zusammengestrickt um mein Kriterium zu testen. Für die Bayes-Klassifikation benutze ich den classifier von Lucas Carlson, meine kleine (beta, beta, beta!) Oberfläche dient sowohl zum Erstellen und Speichern der Samples als auch zur Klassifikation der eingegebenen Zeichen. Und, was soll ich sagen? Gegen eine aufwendigere Analyse (wie z.B. in cellwriter) stinkt mein kleines, allein betrachtetes Kriterium natürlich ab, aber - die richtigen Samples vorausgesetzt - kann man so schon den ein oder anderen gekritzelten Buchstaben klassifizieren.

Es geht hier ja auch nicht um eine vollständige Handschriftenerkennung sondern nur darum, meine Idee zu testen - und gegenüber den sehr sehr ernüchternden Ergebnissen von anno dazumal macht das Ding heute schon einiges her. Wie man auf dem Bild (schlecht) erkennen kann (siehe im linken Fenster ganz unten in der Statuszeile bzw. im rechten Fenster das Zeichen, das in der Liste ganz oben steht), ordnet mein Programm der geschriebenen Glyphe immerhin das richtige Zeichen (a) zu - und das bei einem Sample-Bestand von 26 Kleinbuchstaben. Die Grenzen meines Analysekriteriums sind mir auch einigermaßen klar: Ein ä wird sich damit z.B. von einem a nicht unterscheiden lassen. Für eine ordentliche Handschriftenerkennung muß man schon noch ein paar andere Kriterien bemühen. Meine (inzwischen alte) Idee ist jedenfalls erstmal umgesetzt und für mich damit wieder ein kleiner Abschnitt in Sachen "Gebastel an Handschriftenerkennung" abgeschlossen.

Neues vom OCR Feeder

...es gibt Neuigkeiten vom schönen Programm OCRFeeder, das ich hier schon einmal ausprobiert hatte. Damals ging es insbesondere darum, wie man in OCRFeeder Tesseract als OCR-Engine benutzen kann und ich kam um ein bisschen Gebastel nicht drum rum.
Renard Voß hat mich nun netterweise in den Kommentaren des alten Artikels darauf aufmerksam gemacht, daß Joaquim Rocha noch an dem Programm arbeitet: Inzwischen gibt es ein git-Repository und neuere Versionen des Programms arbeiten nun auch ohne viel Aufwand mit Tesseract zusammen, worauf Rocha auch in seinem Blog hinweist - hatte ich bislang leider übersehen. Den Hilfswrapper von damals kann man nun also ruhig in die Tonne schieben - es genügt nun, für Tesseract eine funktionierende Konfigurationsdatei zu erstellen (geht auch per GUI).
Anbei ein Screenshot von OCRFeeder Studio mit dem OCR-Ergebnis von Tesseract.

Update: Inzwischen gibt es in den Repos auch eine deutsche Übersetzung. Außerdem lohnt es sich, hier auch die Kommentare zu lesen (Installation/OCR dt. Texte/Sonderzeichen).

OCR Feeder

...die wirklich simple Klickibunti-OS-Lösung für OCR fehlt ja leider immer noch. Heute bin ich aber über das Projekt OCR Feeder von Joaquim Rocha gestolpert, der in Python (als master-thesis) eine recht brauchbare GUI zusammengestöpselt hat. Die sehr beachtliche page segmentation steckt in dem Programm selbst drin (wenn ich den python-code richtig interpretiert habe), das OCR leistet eine externe Engine, also wahlweise ocrad, gocr oder - wär ja nicht ganz unnett - tesseract. OCRFeeder nimmt dann einfach deren output und kann dann daraus ein ODT erzeugen.
Man braucht also nur eine Engine, die ein Bild frisst und den erkannten Text dann nach stdout schreibt. Leider nimmt (das cli von) tesseract aber afaik nur TIFFs und besteht auch noch beharrlich darauf, sein Ergebnis in eine Textdatei zu schreiben.
Damit OCRFeeder trotzdem mit tesseract als Engine funktioniert, hab ich auf Basis des Scripts ocube^* mal einen kleinen Wrapper geschrieben, der nichts anderes macht als das Ursprungsbild mit imagemagick nach TIFF zu konvertieren, tesseract auf diesem Bild arbeiten zu lassen und dann die erzeugte Ausgabe nach stdout zu schreiben.
Wie man auf dem Bild sieht, klappt mit diesem Wrapper dann auch tessearact als Engine für OCRFeeder. Wie man aber leider auch sieht, erwartet OCRFeeder wohl normalen ascii-text, tesseract gibt aber natürlich utf-8 aus.
Ob an OCRFeeder noch weitergeschraubt wird (von wem auch immer) und dann die ein oder andere Verbesserung ansteht, bleibt abzuwarten.

(^* dürfte bald weg sein der Link, wenn geocities abgeklemmt wird)

OCRopus

...letzten Oktober hatte ich mich ja nochmal an einer line segmentation handschriftlicher Texte versucht und wollte mir hierzu auch noch OCRopus ansehen, wenn es dann fertig ist (bzw. ich es auf meinem Rechner zum laufen bekomme). Heute war es dann soweit: Nachdem sich OCRopus hier vorgestern noch nicht bauen ließ, wurde praktisch über Nacht der Bug gefixt und die derzeitige Revision 800 (http://ocropus.googlecode.com/svn/trunk/) funktioniert bestens mit Tesseract in der Revision 169 ( http://tesseract-ocr.googlecode.com/svn/trunk/). Nur kurz, wie man beides (z.B.) zieht und installiert, erst Tesseract:
svn co http://tesseract-ocr.googlecode.com/svn/trunk/ tesseract-ocr
Und in tesseract-ocr dann
./configure
make
make install
Prüfen, ob Tesseract funktioniert:
tesseract eurotext.tif test
test sollte nun den Text enthalten, den man in dem Bild eurotext.tif sieht. Nun noch OCRopus ziehen und bauen:
svn co http://ocropus.googlecode.com/svn/trunk/ ocropus
Und in ocropus dann
./configure
jam
Wenn alles ordentlich durchlief dann z.B. mit
ocrocmd/ocrocmd data/pages/alice_1.png
testen, ob die Zeichenerkennung auf dem Testbild (Alice im Wunderland) funktioniert.
Bestenfalls erhält man html mit der segmentation des Bildes und dem Text. Ich habe das Ganze mal so, wie es ist, auf ein Stück aus der Trierer HS30 losgelassen. Das Ergebnis sieht man auf dem Bild (die unterschiedlichen Farben haben keine Bedeutung). Mal sehen, was man noch alles mit dem netten Programm anfangen kann.

line segmentation mal wieder

...vor fast zwei Jahren habe ich mich ein wenig mit der Zeilensegmentierung handschriftlicher Texte beschäftigt - hauptsächlich spielte ich mit Filtern, also Pixel- und Kantenorientierten Verfahren rum. Irgendwann möchte ich mal Handschriften deren Transkription zeilenweise gegenüberstellen.
Neulich fiel mir die OCR-Software GOCR in die Hände, die ich natürlich gleich gegen ihren ursprünglichen Verwendungszweck auf eine Handschrift loslassen musste. Das Schöne an GOCR ist, daß man sich die Koordinaten der gefundenen Zeilen und Zeichen als XML ausgeben lassen kann. Den Ausschnitt (ein paar Zeilen) der Handschrift (als jpeg) schicken wir zuerst durch djpeg, um ihn in ein graustufiges pbm umzuwandeln, danach lassen wir gocr darauf los und lassen uns das Ergebnis als xml ausgeben:
djpeg -pnm -gray hs30.jpg | gocr -o hs30.xml -f XML -v 48 -m 256
Mit dem Parameter -v >=32 gibt uns GOCR das Ergebnis zudem noch als png aus. Für das XML kann man sich nun recht einfach ein XSL schreiben, um aus den Koordinaten der gefundenen Zeichen eine Imagemap zu erstellen. Die Links in der Imagemap sollten dann auf die entsprechende Zeile in der Transkription verweisen. So viel zur Idee...
Hier kann man sich das Resultat ansehen (oder hier als statisches html - mit xsltproc gebaut). Die Auszeichnungen von GOCR: Blaue Linien für die Zeilen, rote Rechtecke für die Zeichen. Die Koordinaten der Zeichen und die jeweilige Zeilennummer sind in den area-Tags im title-Attribut hinterlegt. Das XSL sieht so aus.
Gut, die Zeilensegmentierung ist alles andere als optimal - GOCR ist dafür nicht gedacht und funktioniert bei gedruckten Zeilen auch super. Vorgefilterte Bilder (Sobel-Filter etc.?) habe ich auf die Segmentierung von GOCR noch nicht losgelassen.
Gespannt sein darf man aber auch auf OCRopus des DFKI - ausprobiert habe ich es noch nicht, da ich keine Doku gefunden habe und es wohl (noch) kein fertiges Paket gibt.
Vielleicht kann ich ja über die nächsten kleinen Ergebnisse noch vor September 2009 berichten. :)