Yearly Archives

34 Articles
Posted by Dirk Alvermann on

HTR+ oder Pylaia

Version 1.12.0

Wie ihr sicher schon gesehen habt, gibt es seit dem vergangenen Sommer neben HTR+ eine zweite Technologie für die Handschriftentexterkennung in Transkribus verfügbar – PyLaia.

Wir haben in den vergangenen Wochen mit PyLaia-Modellen experimentiert und möchten hier einige erste Erfahrungen und Eindrücke zu den Unterschieden von HTR+ und PyLaia dokumentieren. Heißt billiger auch schlechter? – Definitiv nein! Hinsichtlich der Accuracy Rate kann PyLaia es ohne weiteres mit HTR+ aufnehmen. Es ist oft sogar etwas besser. Die folgende Grafik vergleicht ein HTR+ und ein PyLaia-Modell, die mit identischem Ground Truth (ca. 600.000 Wörter) unter denselben Voraussetzungen (from the scratch) trainiert wurden. Verglichen wird die Perfomance mit und ohne Language Model.

Der vielleicht auffälligste Unterschied ist, dass die Ergebnisse von PyLaia-Modellen sich mit dem Einsatz eines Language Models nicht ganz so stark verbessern lassen, wie das bei HTR+ der Fall ist. Das ist nicht unbedingt ein Nachteil, sondern spricht eigentlich eher für eine hohe Grundverlässlichkeit dieser Modelle. Anders ausgedrückt: PyLaia braucht nicht unbedingt ein Language Model um sehr gute Ergebnisse zu erzielen.

Es gibt auch ein Gebiet, auf dem PyLaia schlechter abschneidet, als HTR+. PyLaia hat größere Schwierigkeiten „gebogene“ Zeilen korrekt zu lesen. Bei senkrechten Textzeilen ist das Ergebnis sogar noch schlechter.

Im Training ist PyLaia etwas langsamer als HTR+, das heißt, das Training dauert länger. Auf der anderen Seite ist PyLaia sehr viel schneller im „Antritt“. Es benötigt verhältnismäßig wenige Trainingsdurchgänge, um gute Ergebnisse zu erzielen. In den beiden Lernkurven kann man das recht gut erkennen.

Unsere Beobachtungen sind natürlich nicht erschöpfend. Sie beziehen sich bisher nur auf generische Modelle, die mit einem hohen Einsatz von Ground Truth trainiert wurden. Wir haben insgesamt den Eindruck, das PyLaia bei solchen großen generischen Modellen seine Vorzüge voll ausspielen kann.

Posted by Dirk Alvermann on

Wie man PyLaia-Modelle trainiert

Release 1.12.0

Seit der Version 1.12.0 ist es möglich in Transkribus neben den bewährten HTR+ Modellen auch PyLaia Modelle zu trainieren. Wir haben in den letzten Monaten damit einige Erfahrungen gesammelt und sind von der Performance der Modelle recht beeindruckt.

PyLaia Modell können wie HTR oder HTR+ Modelle über das übliche Trainings-Tool trainiert werden. Es gibt aber einige Unterschiede.

Wie bei einem normalen HTR+ Modell müsst Ihr den Namen des Modells, eine Beschreibung und die Sprachen für die das Modell eingesetzt werden kann, angeben. Anders als beim Training von HTR+ Modellen ist die Anzahl der Iterationen (epochs) auf 250 beschränkt. Damit kommt man aber nach unseren Erfahrungen sehr gut zurecht. Man kann auch PyLaia Modelle mit base models trainieren, also längere aufeinander aufbauende Trainingsserien konzipieren. Im Unterschied zum üblichen Training gibt es bei PyLaia eine Einstellung „Early Stopping“. Sie legt fest, wann das Training beendet werden kann, sofern ein gutes Ergebnis erreicht wird. Diesen Wert solltet Ihr zu Beginn eurer Trainingsversuche immer auf dieselbe Anzahl von Iterationen einstellen, die Ihr für das gesamte Training gewählt habt. Wenn Ihr also mit 250 epochs trainiert, sollte der Wert bei „Early Stopping“ genauso hoch sein. Andernfalls riskiert ihr, dass das Training zu früh beendet wird.

Der wichtigste Unterschied ist jedoch, dass im PyLaia Training ausgewählt werden kann, ob Ihr mit den Original-Images oder mit komprimierten Images trainieren möchtet. Hier lautet die Empfehlung ganz klar: trainiert mit komprimierten Images. Das PyLaia Training mit Original-Images kann im schlimmsten Fall (bei entsprechend großer Menge von GT) Wochen dauern. Mit komprimierten Images ist auch ein PyLaia Training innerhalb weniger Stunden oder Tage (wenn ihr bspw. mit etwa 500.000 Wörtern trainiert) beendet.

Tips & Tools
Für ausführlichere Informationen, besonders zur Einstellung spezifischer Trainingsparameter empfehlen wir euch das Tutorial von Annemieke Romein und die Richtlinien der READ Coop.

Posted by Dirk Alvermann on

Unser erstes öffentlich zugängliches Modell für die deutschen Kurrentschriften des 17. Jahrhunderts

Heute präsentieren wir „Acta 17“ als öffentlich zugängliches HTR  Modell.

Das Modell wurde anhand von mehr als 500.000 Wörtern aus Texten von etwa 1000 verschiedenen Schreibern aus der Zeit von 1580-1705 vom Universitätsarchiv Greifswald trainiert. Es kann mit deutschsprachigen, lateinischen und niederdeutschen Texten umgehen und ist in der Lage, einfache deutsche und lateinische Abkürzungen aufzulösen. Neben den üblichen Kanzleischriften enthielt das Trainingsmaterial auch eine Auswahl von Konzeptschriften und Druckschriften der Zeit.

Das gesamte Trainingsmaterial basiert auf Konsulentenanfragen, Prozessschriften und Urteilen aus dem Aktenbestand der Greifswalder Juristenfakultät Die Validierungssets basieren auf einer chronologischen Auswahl der Jahre 1580 – 1705 . GT & Validierungssets wurden von Dirk Alvermann, Elisabeth Heigl, Anna Brandt erstellt.

Aufgrund einiger Probleme bei der Durchführung umfangreicherer Serien von base model Trainings für HTR+ Modelle in den letzten Wochen haben wir beschlossen, ein von Grund auf neu trainiertes HTR+ Modell als öffentliche zugängliches Modell bereit zu stellen.

Es wird von einem PyLaia-Modell begleitet, das auf den gleichen Trainings- und Validierungssets basiert und ebenfalls ohne Nutzung eines Base Modells trainiert wurde.

Für das Validierungsset wählten wir Seiten, die einzelne Jahre des gesamten verfügbaren Materials repräsentieren. Insgesamt waren es  48 ausgewählte Jahre, fünf Seiten pro Jahr.

Wie sich die Modelle in den verschiedenen Zeiträumen des Validierungssets verhalten, könnt ihr im untenstehenden Vergleich sehen. Beide Modelle wurden ohne language model ausgeführt.

Posted by Anna Brandt on

Suchen und Bearbeiten von Tags

Release 1.11.0

Wenn man große Mengen von historischem Text taggt, wie wir das mit den Orts- und Personennamen probeweise versucht haben, hat man über kurz oder lang ein Problem: die Schreibweisen variieren sehr stark – oder mit anderen Worten, die Tag Values sind nicht identisch.

Nemen wir die Orte und daraus ein einfaches Beispiel. Als „Rosdogk“, „Rosstok“, „Rosdock“ oder noch anders wird immer derselbe Ort bezeichnet – die Hansestadt Rostock. Um das kenntlich zu machen, benutzt man die Properties. Wenn man das aber über mehr als zehtausend Seiten mit hunderten oder tausenden Orten (wir haben bei unserem Versuch ca. 15.000 Tags für Orte gesetzt) macht, verliert man leicht den Überblick. Und außerdem dauert das Taggen deutlich länger, wenn man zugleich Properties vergibt.

Glücklicherweise gibt es dafür eine Alternative. Man kann nämlich in den Tags suchen und zwar nicht nur im Dokument, das man gerade bearbeitet, sondern in der gesamten Collection. Dazu muss man im Menü einfach das „Fernglas“ auswählen, ähnlich als wenn man eine Volltextsuche oder KWS starten würde, nur dass man nun das Untermenü „Tags“ wählt.

Hier kann man den Suchbereich (Collection, Document, Seite) auswählen und auch auf welcher Ebene gesucht werden soll (Line oder Word). Dann muss man natürlich noch den entsprechenden Tag auswählen und wenn man die Suche einschränken  vmöchte den das getaggte Wort angeben. Die Suchergebnisse lassen sich auch sortieren. Auf diese Weise finden wir schnell alle „Rostocks“ in unserer Kollektion und können in den Properties die gewünschten Zusatzinformationen eintragen, etwa den heutigen Namen, die Geodaten und ähnliches. Diese „Eigenschaften“ kann man dann allen ausgewählten getaggten Worten zuweisen. Auf diese Art lassen sich Tagging und Anreicherung der Daten voneinander trennen und effizient durchführen.

Dasselbe geht natürlich mit solchen Tags wie „Person“ oder auch „Abbrev“ (dort würde man in den Properties bspw. die Auflösung/Expansion hintelegen).

Posted by Dirk Alvermann on

Taggen im Text

Wie alles andere, kann man auch das tagging auf sehr unterschiedlichen Niveaus und mit unterschiedlichen Ansprüchen in seine Arbeit integrieren. In Transkribus steht eine große Anzahl Tags für die unterschiedlichsten Anwendungsfälle zur Verfügung, von denen einige hier beschrieben sind.

Wir haben uns für einen Versuch mit lediglich zwei tags, nämlich „person“ und „place“ entschieden, um später eben über diese Tags einen systematischen Zugriff auf die entsprechenden Textstellen zu ermöglichen.

Transkribus übernimmt beim taggen automatisch den Begriff, der unter dem cursor steht als „value“ oder „label“ für den konkreten Fall. Wenn ich also, wie im Beispiel unten „Wolgast“ markiere und als „place“ tagge, dann sind schon zwei wesentliche Informationen festgehalten. Genauso verhält es sich mit dem Personennamen etwas weiter unten.

Transkribus bietet die Möglichkeit, jedes getaggte Element mit properties zu versehen, also bpw. den historischen Ortsnamen in der modernen Schreibweise wiederzugeben oder dem Personennamen eine gnd-Nummer zuzuordnen. Man kann auch weitere Properties erzeugen, meinetwegen Geodaten für Orte etc.

Angesichts der Textmenge, die wir verarbeiten, haben wir uns dafür entschieden, unseren Tags keine Properties zuzuweisen. Ledigklich die Ortsnamen werden, so gut es geht, identifiziert. Angestrebt ist dabei, dass wir bei der Präsentation im Viewer der Digitalen Biblitothek M-V die tag-values getrennt nach Personen und Orten neben dem jeweiligen Dokument anzeigen lassen können und dem Benutzer so eine systematische Navigation im Dokument ermöglichen.

Posted by Anna Brandt on

Taggen im WebUI

Für Aufgaben wie das Taggen von bereits transkribieren Dokumenten eignet sich das WebUI, welches besonders für Crowd-Sourcing-Projekte ausgelegt ist, sehr gut.

Das Taggen im WebUI funktioniert etwas anders als im Expert Client. Es gibt andere Tools und Einstellungen.

Wenn Ihr eure Collection und das Document im WebUI ausgewählt habt und etwas taggen wollt, müsst ihr bei der Seite die Ihr bearbeiten wollt „Annotation“ auswählen und nicht „plain Text“. Beide Modi sind ähnlich aufgebaut, außer dass in Annotation zusätzlich getaggt werden kann. Dafür müsst ihr wieder ganz normal die Worte markieren und mit Rechtsklick den entsprechenden Tag auswählen. Speichert immer wenn ihr die Seite verlasst, selbst wenn ihr auf der entsprechenden Seite in den Layout-Modus wechselt. Das Programm fragt nicht extra nach, wie es das im Expert Client tut und ohne speichern sind eure bereits gesetzten Tags verloren.

Alle Tags erscheinen links neben dem Textfeld, wenn man auf dem entsprechenden Wort ist. Dort werden ebenfalls die im Expert Client gesetzten Tags angezeigt. Der ganze Annotation-Modus ist im Moment noch in der Beta Version.

Posted by Anna Brandt on

Werkzeuge zum Taggen

Release 1.11.0

In einem früheren Post hatten wir schon über unsere Erfahrungen mit dem Strukturtagging geschrieben und den dazu gehörigen Tools beschrieben. Für die meisten Nutzer (z. B. in Editionsprojekten und ähnlichem) ist aber das Anreichern von Texten mit zusätzlichen inhaltlichen Informationen noch wichtiger. Um eine Transkription mit inhaltlichen Auszeichnungen (Tags) zu versehen benutzt man in Transkribus die Tagging-Tools im Reiter „Metadata“/“Textual“.

Hier werden sowohl die verfügbaren Tags angezeigt, als auch die, die bereits auf den Text der Seite angewandt wurden. Mit dem Button Customize kann man genauso wie beim Strukturtagging selber Tags erstellen oder Shortcuts zu bestehende Tags hinzufügen. Die Shortcuts machen das spätere taggen im Transkript deutlich leichter und schneller. Will man auf Shortcuts verzichten, muss man die entsprechenden Wörter markieren und im Text (nicht im Image) mit einem Rechtsklick das gewünschte Tag auswählen. Natürlich kann ein Wort mehrfach getaggt werden.

Diese Tags sind nicht zu verwechseln mit den sogenannten TextStyles (zum Beispiel durchgestrichene oder hoch gesetzte Worte). Diese sind nicht unter den Tags zugänglich sondern über die Toolbar am unteren Rand des Textfensters.

Posted by Dirk Alvermann on

Tagging: wozu eigentlich? – wann und warum Tagging Sinn macht

Tagging erlaubt – zusätzlich zur Inhaltserschließung durch HTR – eine systematische Erschließung des Textes durch den späteren Benutzer. Anders als ein HTR-Modell, das seine Arbeit selbständig erledigt, muss das tagging größtenteils mauell erfolgen – ist also mit Aufwand verbunden. Bevor man also weitgreifende Pläne hinsichtlich des Taggings entwickelt, sollte eine realistische Aufwandsanalyse erfolgen.

Aufgrund der Menge des in unserem Projekt verarbeiteten Materials setzen wir das Tagging vorrangig dort ein, wo sie uns in der praktischen Arbeit am Text helfen. Das ist einmal beim Strukturtagging der Fall, wo mit Hilfe des Taggings und des daraus entwickelten P2PaLA die Layoutanalyse verbessert wird und dann natürlich auch beim taggen der textstyles im Falle von Streichungen und Schwärzungen, der Fall. Hier wird tagging also im Grunde „flächendeckend“ von uns eingesetzt. Fester Bestandteil unserer Transkriptionsregeln ist auch die Verwendung des „unclear“-Tags für Passagen, die vom Transcriber nicht korrekt gelesen werden können. Hier dient das Tag also eher der teaminternen Kommunikation.

Für die systematische Aufbereitung der Texte, für die bereits eine HTR durchgeführt wurde, experimentieren wir mit den Tags „person“ und „place“, um zumindest in dieser begrenzten Form eine systematische Erschließung anzubieten.

Posted by Elisabeth Heigl on

Compare Samples

Release 1.10.1

Das Tool „Compare Samples“ überprüft, wie der Name schon sagt, die Fähigkeiten eines HTR-Modells nicht anhand eines manuell ausgewählten Testsets, sondern auf der Grundlage eines Samples. Wie man solche Samples erstellt, dass sie eine objektive Alternative zu konventionellen Testsets darstellen und warum sie mit wesentlich weniger Aufwand als diese erstellt werden können, haben wir in einem früheren Beitrag erklärt.

„Compare Samples“ sieht zwar aus wie ein Validierungs-Tool, gehört aber eigentlich nicht dazu. Nicht dass man damit ein HTR-Modell nicht validieren könnte, aber dafür ist das Advanced Compare eigentlich besser geeignet. Die eigentliche Funktion von „Sample Compare“ ist, dass es Voraussagen oder Prognosen über den Erfolg eines HTR-Modells auf einem bestimmten Material erstellt.

Ihr erinnert euch vielleicht an den Model Booster. Wenn man für ein geplantes HTR-Training unter den inzwischen zahlreichen verfügbaren Public Models ein geeignetes HTR-Modell sucht, das als Base Model dienen kann, dann bietet es sich an, das zuerst mit „Compare Samples“ auf seine Eignung zu überprüfen.

Um für ein Sample eine solche Voraussage zu erstellen, müsst ihr zuerst die ausgewählten HTR-Modelle über das gesamte Sample laufen lassen (Davor habt ihr natürlich für das Sample schon den GT erstellt). Anschließend öffnet ihr im „Compare Samples“-Tool den Reiter Samples. Darin sind sämtliche Samples deiner aktiven Collection aufgelistet. Ihr wählt das Sample aus, das als Grundlage für die Vorhersage dienen soll. Jetzt könnt ihr in der Mitte das Modell auswählen, dessen Textversion als Referenz für den GT dienen soll. „Compute“ starten und fertig.

Das Tool errechnet euch jetzt Durchschnittswerte für alle Zeilen des Samples mit jeweils einem oberen Durchschnittswert (upper bound), einem unteren (lower bound) und einem Mittelwert. In der Spanne zwischen upper bound und lower bound sollte dann für 95 % eures Materials die Character Error Rate liegen mit der das gewählte HTR-Modell voraussichtlich arbeitet. In unserem Beispiel unten also zwischen 4,7 und 2,9 %.

Ihr könnt auf diese Art beliebig viele Modelle für euer Material vergleichen. Aber das Tool erlaubt auch ein paar andere Dinge. Ihr könnt z.B. sehr gut überprüfen, wie ein HTR-Modell mit oder ohne language model oder dictionary auf eurem Material arbeitet und ob sich also der Einsatz des einen oder anderen lohnt. Das bietet sich natürlich vor allem für die Überprüfung der eigenen Modelle an.

 

Tipps & Tools
Erstellt lieber mehrere kleinere Samples als ein gigantisches Sample für all euer Material. Ihr könnt sie z. B. chronologisch oder nach Schreiberhänden trennen. Das erlaubt euch später eine differenzierte Voraussage für den Einsatz von HTR-Modellen auf eurem gesamten Material oder auf Teilen davon.

Posted by Elisabeth Heigl on

CER? Keine Sorge!

Release 1.10.1

Die Zeichenfehlerquote (Character Error Rate – CER) setzt für eine gegebene Seite die Gesamtzahl aller Zeichen (n) – dazu gehören auch die Leerzeichen – ins Verhältnis zur geringsten Anzahl der Einschübe (i), Änderungen (s) und Streichungen (d) von Zeichen, die nötig sind, um das GT-Ergebnis zu erhalten. Um es noch mathematischer auszudrücken:

CER = [ (i + s + d) / n ]*100

Das bedeutet, dass auch sämtliche Kleinigkeiten statistisch vollwertige Fehler sind. Jedes fehlende Komma, ein u statt eines v, ein zusätzliches Leerzeichen oder auch ein Groß- statt eines Kleinbuchstaben fließen als „ganzer Fehler“ in die CER mit ein. Dabei stören die Kleinigkeiten weder beim Lesen und Verstehen des Textes, noch hindern sie die Suchmaschine am Finden eines Begriffs.

Schaue deshalb nicht nur auf die Zahlen sondern immer mal wieder auch in den Textvergleich. Dein Modell ist in der Regel besser, als es die CER und erst recht die WER suggerieren.

Zur Veranschaulichung haben wir das mal an einem Beispiel durchgerechnet: