OCR Frakturerkennung

    Es gibt irgendwo ein Video von einem Vortrag des Entwicklers von Tesseract, wo er seine Algorithmen erklärt. War für mich sehr aufschlussreich, weil mir da klar wurde, warum Tesseract bestimmte Schwächen und Fehlerhäufigkeiten hat. Meine Nachbearbeitung und automatische Korrektur beruht darauf, diesen Schwächen durch ein einfaches OCR mit orthogonalen, schnell adaptiven Methoden zu begegnen. Tesseract kann nur das (Fonts, Zeichen), worauf es trainiert wurde. Das ist ein gravierender Nachteil dieser Art von KI. Ein Mensch kann adaptieren und lernt während des Lesens schwierige Fonts wie Gutenbergs Textura, oder auch Schwabacher und es geht von Seite zu Seite immer schneller und besser.

    Zitat von Siegmarer

    Ich habe Mac, gibts das/den „Tesseract„ auch dafür?

    Ja, ich entwickle auch auf einem Mac, derzeit MacOS 10.14.6 Mojave.

    Der einfachste Weg ist über Homebrew. Zuerst Homebrew installieren und dann mit Homebrew (Befehl brew auf der Kommandozeile) Tesseract. Dabei werden auch alle Abhängigkeiten installiert. Manchmal muss man für Sprachmodelle nachbessern.

    Weiss jetzt nicht, ob man Xcode und die Xcode command line tools for Homebrew installieren muss. Die brauche ich sowieso, um C/C++ zu kompilieren.

    Vermutlich gibt es einige GUI-Versionen für Linux oder Windows auch für Mac. Ich verwende es lieber von der Konsole bzw. selbst entwickelte Perl-Skripts, die mir das Rundherum auch gleich erledigen: Zerlegen und Umwandeln der PDFs, Anlage der Verzeichnisse, systematische Benennung bzw. Nummerierung der Dateien, Nachkorrektur und Qualitätsstatistiken. Erfahrungsgemäss schränken die GUI-Versionen ein und es ist auch nicht klar, was sie genau machen. GUI ist eher was für einzelne oder wenige Seiten.

    Die Masterarbeit von Paul Vorbach scheint auch mir interessant; vielleicht habe ich mal Zeit diese genauer zu lesen. Verstehen möchte ich vor allem das Trainieren und eben ob Trainingsdateien gemeinsam "zusammengeführt" und dann genutzt werden können.


    Ich habe eine für alle editierbare GSheet-Tabelle erstellt und den ersteren Teil der Liste von romulus eingefügt. Meines Erachtens sind nur aktuellere Tools die Tesseract ab v4 unterstützen interessant. Ich habe deshalb die Liste nach dem Datum (last v.date) sortiert. Die aktuellsten vier Tools sind CLI (Command Line Interface, Kommondozeileneingabe). Die aktuellste unterstützte Tesseract Version konnte ich nicht immer herausfinden.

    docs.google.com/spreadsheets/.../edit?usp=sharing

    Zitat von ChrisR

    den ersteren Teil der Liste von romulus eingefügt.


    Mach' Dich bitte aufmerksam darauf, dass allerlei E i n s c h a l t u n g e n etwa Antiqua oder Tabellenartiges w e s e n t l i c h das Endergebnis beeinflußen. Deshalb habe ich dies in die Musterreihe auch mit einfügen müssen. Es kommt ja sowieso auf die Experimente an, früh oder spät. So, dass alle Erwartungen anders sein können.

    Einmal editiert, zuletzt von romulus ()

    Die Masterarbeit ist prinzipiell interessant, ist aber von den Werten her veraltet. Tesseract 5-alpha hat wesentlich bessere Werte.

    Zwischenzeitlich (nach Version 4) wurde der Autor von Ocropus ins Entwicklungsteam aufgenommen und auf neuronale Netze umgestellt.


    Die Trainingsdaten für deutsche historische Druckwerke aus den EU-finanzierten Projekten sind frei erhältlich: https://github.com/tesseract-ocr/tesstrain/wiki/GT4HistOCR. Dort gibt es auch Verweise auf fertig trainierte Modelle der UB-Mannheim zum Download. So ein Trainingslauf dauert 20 CPU-TAGE! Die Trainingsdaten sind auch nicht grad handlich (660.000 Dateien). Ebenso gibt es die der ONB https://github.com/tesseract-o…n/wiki/AustrianNewspapers.

    Zitat von wollmers

    So ein Trainingslauf dauert 20 CPU-TAGE!

    Ein Beweis für eine irreführende Entscheidung.

    Es sind nur ca. 700 Frakturschriften dem Namen nach bekannt.

    Einer Privatperson liegen m.E. 1 bis 10 Bücher im Durchschnitt zum Umsetzen vor.

    Millionen von Büchern setzt man d i e n s t l i c h und gegen Entgelt an den Bibliotheken um.

    Globale Aufgaben sind nicht für Privatpersonen zu lösen.

    Es ist unklar, wozu soll diese Diskussion dienen:

    Wie setzt man alle Fraktur-Bücher der Welt in Antiqua um?!

    Kommt drauf an, wie man Fraktur definiert, wieviele es davon gibt. Nimmt die Bedeutung des Wortes Fraktur als "gebrochen", dann umfasst das alle Schriften mit eckigem Character. Der englische Begriff Blackletter ist da praktischer. Ist z. B. die Bibel-Textura von Gutenberg eine Fraktur? Oder eine Schaftstiefel-Groteske?


    Rein pragmatisch für den Zweck von OCR sagt der Name garnichts. Relevant ist, ob die Formen unterschiedlich sind. Und das sind sie z. B. bei einer Breitkopf-Fraktur in den unterschiedlichen Schriftgrössen und für Titelseiten verwendeten schmalen oder engen Varianten. D. h. ein OCR-System erkennt die stärker verzierten Grossbuchstaben in den grösseren Schriftgraden sehr schlecht.


    Die "irrende" Entscheidung bei den grossen EU-Projekten ist m. M. n., ca. 300 Bücher aus 5 Jahrhunderten auszuwählen und damit ein OCR-System zu trainieren. So eine eierlegende Wollmilchsau wird halt nie perfekt funktionieren. Kann man mit einfacher Wahrscheinlichkeit abschätzen, das da bei grösseren Beständen Werke dabei sind, die eine eher ausgefallene Schrift verwenden, und die Erkennungsrate auf Buchstabenebene auf 85% runterfällt. Das sind dann auf Wortebene so ca. 50%. Die Erkennungsrate von Suchbegriffen (darum geht es den Bibliotheken primär), liegt dann bei 15-30%.

    Es geht auch überhaupt nicht um Umsetzung in "Antiqua", sondern in Unicode. Hat man einen Text mal in Unicode, dann kann man den in einem beliebigen der hundertausenden verfügbaren Fonts darstellen.

    Zitat von Angemeldet

    Da kennt sich aber jemand mit dem Personalschlüssel an deutschen Bibliotheken und Archiven nicht aus.


    Was würde das denn minimal für ein System erfordern?

    Die Bibliotheken oder Archive haben halt ein paar Mitarbeiter für die IT, darunter ein paar Programmierer. Und vielleicht, wenn überhaupt, ein zwei spezialisierte OCR-Wissenschafter. Dann eventuell noch Digitalisierungs-Personal, aber z. B. die ONB in Wien und die Bayrische Staatsbibliothek lassen von Google scannen und digitalisieren.

    Wen Du das in einer Woche durchhaben willst, brauchst Du eine leistungsfähige CPU mit 4 Kernen und modernem Instruktionssatz (AVX). Das ist im leistbaren Bereich z. B. ein Intel Core i7. Der muss auch gut gekühlt sein und macht entsprechenden Lärm. Ein Laptop hält so eine Dauerlast nicht unbedingt aus. Da ist das Risiko sehr hoch, dass Lötstellen auf den Platinen Schaden erleiden. Diese eine Woche ist nur ein Lauf. Solche Läufe muss man mehrfach mit verbesserten Daten oder Einstellungen wiederholen, um die Ergebnisse zu optimieren.

    Also ich mache das nicht, obwohl ich in einem Rechenzentrum (Hetzner) zwei geeignete Systeme gemietet habe, die bei Schaden vom Vermieter ersetzt werden müssen. Ich werde lieber die fertigen Modelle von der UB-Mannhein (GT4HistOCR und ONB, beide in vielen Varianten) runterladen und durchprobieren. Der Mitarbeiter der UB-Mannheim ist recht aktiv (Dissertant?) und tut auch sehr viel, um die Qualität der Ausgangsdaten zu verbessern.

    Naja gut, wenn man kalkuliert, dass man damit nur OCR-Durchläufe machen möchte, wäre vielleicht ein Rechner um die 1000 Euro schon ausreichend (Quad-Core sind ja mittlerweile Standard). Bei mir lohnt sich das aber deswegen nicht, weil ich vornemlich handschriftliche Quellen verarbeite und nur ein kleiner Teil Fraktur ist. Wenn es schon Trainingsdatensätze für Frakturschriften gibt, werden die sicher auf eine große Zahl Bücher anwendbar sein. Wie du schon sagst, ohne individuelle Kontrolle wird's auch dann nicht gehen. Aber auch hier - gute und kompetente Hilfskräfte - die sind mittlerweile wirklich unbezahlbar.


    Wie mir übrigens schon mehrfach bei dem Scan von Altregistraturen aufgefallen ist, wird die OCR-basierte Übertragung von Text in Unicode auch mit Mascheinenschriften ein Problem haben (bedingt durch stark schwankende Papierqualität v.a. in den 40er und 60er Jahren.) Ob das aber durch KI-basierte Programme wie tesseract behoben werden kann, da habe ich so meine Zweifel.

    Angemeldet Maschinenschriften sind auch nur Fonts. Die gab es übrigens auch in Fraktur und Schreibschriften für Schreibmaschinen, bzw. umgekehrt Schriften mit Schreibmaschinen-Character auch als Bleisatzlettern.

    Muss ich einmal ausprobieren. Ich habe eine eingescannte Registratur 1910-1960, mit verschiedenen Handschriften ausgefüllt und auch mit Schreibmaschine. Die teilweise unleserliche Kurrent kann ich nicht vollständig entziffern.

    Ich meine auch gar nicht fonts, sondern die Qualität der maschienenschriftlichen Vorlagen, wenn Farbbänder zu trocken waren oder schmierten, das Papier zu dünn war oder die Schrift stellenweise mechanisch abgetragen oder ausradiert wurde (von der Katastrophe Thermodruck nicht zu reden). Das Problem der handschriftlichen Einschübe kommt natürlich dazu.

    Zitat von wollmers

    Die teilweise unleserliche Kurrent kann ich nicht vollständig entziffern.

    Ich habe gehört, dafür soll es irgendwo ein Forum geben.

    Ich würde mich freuen, wenn mir einer der hier schreibenden Experten mir sagen kann, welcher Unterschied zwischen den Tesseract-Sprachdateien def.traineddata und deu-frak.traineddata besteht. Ich habe beide Sprachdateien an verschiedenen Frakturtexten ausprobiert und binzu exakt denselben Ergebnissen gekommen. Handelt es sich nur um eine Umbenennung, um dann auch Spachdateien für nichtdeutsche Frakturtexte benennen zu können?.

    Des weiteren: deu-frak.traineddata kann von meinem Programm FreeOCR nicht geladen werden. Dies akzeptiert anscheinend nur drei Buchstaben vor dem Punkt (xxx.traineddata). ich habe die Datei schlichtweg umbenant in dfr.traineddata. So ließ sich die Datei laden.

    Abbyy Finereader 15 wirbt mit der Fähigkeit zur Erkennung von Frakturschrift.

    Da war wohl die Werbung der tatsächlichen Lage voraus, denn Abby Finereader 15 enthält

    zum gegenwärtigen Zeitpunkt keine Fähigkeit zur Erkennung von Frakturschrift.


    Ich arbeite grad an meinem eigenen Server.


    Experimentiere grad mit verschiedenen Korrektur-Bildschirmen, zeilen- oder seitenweise.