by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Konstantin Baierer
    @kba
    Ist das parallel zum ocr4all workshop?
    Christian Reul
    @chreul
    jap, hamse super hinbekommen. hatte noch gemosert, dass diese terminanfrage etwas fragwürdig sit, solang enoch kein programm feststeht, mit verweis auf den workshop...
    Konstantin Baierer
    @kba
    klassisch.
    Christian Reul
    @chreul
    ja, ist etwas unschön aber jetzt auch nicht sooo wild. ich melde mich zeitnah noch einmal zwecks planung/"programm". es kann sich ja jeder schon einmal ein paar gedanken machen :-)
    Kay-Michael Würzner
    @wrznr
    @chreul Mit großem Interesse lese ich https://arxiv.org/pdf/1909.04032.pdf
    Gerade Tabelle 2 gibt ja einen schönen, kompakten Überblick über Stärken und Schwächen der einzelnen Werkzeuge.
    Verschiedene Haken sind mir jedoch nicht klar: Warum bekommt bspw. Tesseract einen Haken bei der Erkennung von historischem Text weniger als OCR4all?
    Kay-Michael Würzner
    @wrznr
    Auch das Training von Tesseract kommt schlechter weg. Da steht es gar 3:1 für ocr4all. Selbst OCRopus werden bessere Trainingsmöglichkeiten zugeeignet als Tesseract. Das kann ich beim besten Willen nicht nachvollziehen und würde mich über eine Erläuterung sehr freuen.
    While Tesseract has its strengths in the fully automatic out of the box processing of
    modern texts it falls short when it comes to historical material.
    Was wohl bspw. @stweil dazu denkt?
    Kay-Michael Würzner
    @wrznr
    Böse Zungen könnten fragen: Wo sind die Zahlen, die das belegen? In Tabelle 9 sind sie nicht.
    Christian Reul
    @chreul

    oje, das hat länger gedauert als ich dachte. war fast zu erwarten, dass man es mit so einer tabelle nicht allen recht machen kann und ich weiß auch noch, dass es da damals schon zahlreiche diskussionen zu den häkchen gab ;-).

    die haken für den eigentlichen OCR/ATR part wurden aus der vorherigen tabelle übernommen, die wir wiederum versucht haben so objektiv wie möglich aus den zitierten papern abzuleiten, die entsprechende vergleiche angestellt haben. dort hat calamari deutlich am besten abgeschnitten. da calamari (leider noch immer) die einzige OCR engine in OCR4all ist, wurden diese haken dann auch in die nächste tabelle übernommen, wie auch im paper beschrieben. ein weiterer wichtiger punkt war die geschwindigkeit, v. a. auch beim training, da im gesamten paper ein fokus auf sehr frühen drucken und somit werksspezifisches training gelegt wurde. da hat tesseract aufgrund der fehlenden (vernünftigen?) GPU unterstützung sehr schlecht abgeschnitten. ansonsten war das training auf realen daten mit der default version meines wissens damals auch noch relativ umständlich aber wann genau sich da etwas geändert hat, weißt du sicher besser als ich und das spielte für die tabelle auch keine wirkliche rolle. bzgl OCRopus: es handelt sich um OCRopus 3, was in den zitierten evaluationen vergleichbare genauigkeiten lieferte und signifikant schneller war.

    zu den zahlen in tabelle 9: dazu gab es umfassende evaluationen in unserem DHd paper, inklusive tesseract. dort wurden allerdings eher bestehende, frei verfügbare modelle als engines verglichen. da es sich im ocr4all paper hierbei nur um eine ergänzende evaluation handelt, haben wir uns für einen vergleich mit dem kommerziellen state-of-the-art entschieden, der auch bei den vorevaluationen (DHd) nach calamari am zweitbesten abschnitt. aufgrund des trivialen layouts, hängen die ergebnisse natürlich hauptsächlich vom verwendeten OCR modell ab. mittlerweile wurden ja mit dem GT4HistOCR bzw. dem DTA19 korpus neue tesseract modelle trainiert, die vermutlich deutlich stärker als die alten sind. das nützt nur dem paper, das eben, wie jedes andere paper auch, nur eine momentaufnahme ist, nicht recht weiter.

    versteh mich bitte nicht falsch. ich bin für jedes feedback sehr offen und lasse meine meinung gerne ändern bzw. erweitere meinen horizont auch gern aber die sache mit der related work ist, gerade im bereich der historischen OCR, schlicht nicht ganz einfach. ich habe für meine diss gerade insgesamt fast 60 seiten RW über verschiedenste aspekte geschrieben und das war so ziemlich das schmerzhafteste, was ich je zu tun hatte. oft gibt es schlicht keine veröffentlichten evaluation und wenn es welche gibt, sind sie oft fragwürdig. zudem gibt es in einigen aktiven projekten ständig fortschritte und die veröffentlichungszeit von paper beträgt standardmäßig mehrere monate. somit bleiben einem oft nur erfahrungsberichte, hörensagen und austausch mit anderen. wie stark die meinungen da auseinander gehen können, weißt du ja vermutlich sehr gut, da du ja sicher auch schon die ein oder andere diskussion mit uwe hattest ;-).

    zusammengefasst: ich denke, dass die häkchen durch die im paper definierten kriterien und zugrunde liegenden evaluationen gerechtfertigt sind. der von mir zitierte satz hat allerdings wirklich optimierungspotential. ich denke tatsächlich nach wie vor, dass tesseracts hauptstärke das out-of-the-box processing moderner texte ist, einfach da es, im gegensatz zu allen anderen OCR engines, eine riesige masse an gemischten modellen zur verfügung stellt. die aussage zum "historischen material" ist aber zu hart bzw. zu wenig differenziert. unser fokus hier in würzburg und auch der des papers liegt auf sehr frühen drucken, bei denen regelmäßig werksspezifisch trainiert werden muss, bei denen Otsu keine gute wahl hinsichtlich der segmentierung ist, bei denen fixe zeilenrechtecke häufig suboptimal sind, usw. dass tesseract aber z. b. auf frakturschriften des 19. jh. sehr gute ergebnisse erzielen kann, davon bin ich längst überzeugt, auch ohne, dass mich stefan diesbzgl. noch einmal extra aufklärt ;-).

    die kritik nehme ich mit. mir ist nur wichtig, dass das ganze im richtigen kontext gesehen wird und ich nicht wieder vorschnell als "tesseract-hater" abgestempelt werde oder als jemand, der die RW recherche schleifen lässt, da nämlich in meinen augen eher das gegenteil der fall ist. ich möchte tesseract übrigens auch schon länger in ocr4all einbinden, was ja durch die (hoffentlich zeitnahe) integration der ocr-d lösungen, auch bald erledigt sein sollte.

    Stefan Weil
    @stweil
    Es hängt halt immer davon ab, in welche Schachtel man greift. Die typische Tesseract-Installation mit Linux-Distributionen greift auf die Repositories unter https://github.com/tesseract-ocr/ zurück, und damit ist für historische Drucke tatsächlich kein Blumentopf zu gewinnen. Aber wenn man schon OCR Engines vergleicht, die alle mit neuronalen Netzen arbeiten, dann sollte man idealerweise auch alle mit den gleichen Trainingsdaten füttern. Das ist inzwischen für den Tesseract-Part tatsächlich nicht mehr so schwer.
    Christian Reul
    @chreul
    sorry an den rest, dass das jetzt so lang wurde aber ich denke, dass sich da durchaus ein auch für die AG relevantes problem abzeichnet. ich sehe das immer wieder, dass leute, die sich nachweislich gut mit dem thema auskennen, zu völlig unterschiedlichen einschätzungen kommen. evtl. sollten wir halbwegs zeitnah einmal versuchen, eine ausführliche, faire und maximal aussagekräftige evaluation von existierenden methoden auf die beine zu stellen. ich glaube das wurde auch beim ersten halle-treffen schon vorgeschlagen. das erscheint mir gerade in hinblick auf den ocr-d abschluss dringender den je. evtl. auch eine idee für den demnächst anstehenden mini-DHd-antrag?
    Stefan Weil
    @stweil
    Ich erkenne neidlos an, dass alle OCR-Software mit GPU-Unterstützung Tesseract in der Geschwindigkeit bei Training und Erkennung um Längen schlägt. Oder eigentlich stimmt das nicht ganz: ich bin schon etwas neidisch und hätte gerne auch für Tesseract GPU-Unterstützung.
    Ideal wäre es, wenn man die trainierten Modelle durchgängig mit aller Software verwenden könnte. Benjamin meinte mal, das sollte möglich sein.
    Christian Reul
    @chreul
    @stweil das sehe ich auch so. s. o., im dhd paper lag der fokus auf den vergleich von existierenden modellen und es wurde keine aussage über die engines getroffen (ocropus und calamari ausgenommen, da diese trainiert wurden und somit ein fairer vergleich möglich war). alles völlig legitim meiner meinung nach.
    die leichte fehlformulierung im ocr4all paper (für uns ist "historisch" im normalfall 1600 und früher, semi sinnvoll, ich weiß) gestehe ich, wie gesagt, gerne ein und in der tabelle sind die "abzüge" hauptsächlich auf den fehlenden GPU support zurückzuführen, was für unsere anwendung eben wirklich ein riesen problem ist.
    joa, das wäre natürlich wirklich ideal
    Stefan Weil
    @stweil
    Die mit GT4HistOCR trainierten Tesseract-Modelle funktionieren ganz gut mit Texten aus dem 16. Jahrhundert, sind also nicht auf Fraktur des 19. Jahrhunderts beschränkt. Im Rahmen des Pilot-Tests von OCR-D haben wir das mit einem Buch von Melanchthon getestet.
    Christian Reul
    @chreul
    ja, im korpus sind neben dem großen dta19 korpus einige kleinere subkorpora enthalten, die teils deutlich frühere werke enthalten. die performanz der gemischten modelle schwankt aber leider noch sehr stark. in den ocr4all evaluationen schwankten die CERs auf werken vor 1600 von ca. 2% bis fast 30%. da musste dann eben immer fleißig werksspezifisch nachtrainiert werden, um auf durchschnittlich ~0,5% zu kommen.
    Kay-Michael Würzner
    @wrznr
    @chreul @stweil Danke für Eure Antworten. Für meine Erwiderung muss ich mir ein bisschen Zeit nehmen. Ganz so einfach, von wegen das ist eine Momentaufnahme und man kann es nicht allen Recht machen, ist es leider nicht. Aber wie gesagt, dazu möchte ich ein bisschen ausholen und etwas sachlicher im Ton sein, als heute Nachmittag. Sry dafür!
    Christian Reul
    @chreul
    schon ok. mir ist bewusst, dass das ein heikles thema ist und sehe schon auch ein, dass gerade 1-2 formulierungen durchaus angriffsfläche bieten und demnach natürlich auch hinterfragt/kritisiert werden dürfen und sollen. alles gut. da ich im moment im quasi-urlaub bin, kann es übrigens auch unter der woche etwas dauern, bis ich reagiere.
    Christian Reul
    @chreul

    @all im folgenden ein paar infos bzw. erste ideen/vorschläge zur unserem AG treffen auf der DHd jahrestagung anfang märz in paderborn. sorry, dass das etwas länger gedauert hat aber ich hatte die letzten zwei wochen mit nachwuchs und diss abgabe alle hände voll zu tun.

    ich hab mal ein hackmd erstellt (https://hackmd.io/yo7rddsBRS6r20yI_aZQeQ) und dort einfach ein paar gedanken zusammen gebrainstormt. um zeitnahe ergänzungen etc. wird gebeten. ich würde gerne im laufe der kommenden woche eine doodle umfrage bzgl. einer telko (vermutlich dann die woche drauf) an die liste schicken und dabei auch direkt auf ein programm für die telko verweisen, was wiederum von den programmideen für das treffen abhängt. danke :-)

    Konstantin Baierer
    @kba
    Unabhängig von der Kontroverse Gratifikation zum Nachwuchs, ich hoffe alle sind gesund und munter
    Christian Reul
    @chreul
    @kba vielen dank, alles gut :-)

    @wrznr @stweil da ich jetzt endlich mal wieder etwas zeit und einen klaren kopf hatte, hab ich mir noch einmal ganz in aller ruhe ein paar sachen durchgelesen. bzgl. des dhd papers und auch der "häkchen-gebung" im ocr4all paper bin ich nach wie vor der meinung, dass das so legitim und in ordnung ist, bin da aber, wie gesagt, für jegliche diskussion offen.

    bzgl. des tesseract abschnitts im ocr4all sieht es leider ganz anders aus und ich gebe zu, dass es da keine zwei meinungen geben kann: selbst im kontext des papers und dem fokus auf sehr (!) frühe drucke (der an der fraglichen stellen in keinster weise deutlich wird), ist der absatz schlicht schlecht und vermittelt ein völlig falsches bild. ich gebe gerne zu, dass ich einige vorbehalte bzgl. tesseract für unsern haupteinsatzbereich habe (otsu, zeilenrechtecke, kein GPU support) aber das steht im paper halt schlicht nicht.

    beim von kay zitierten satz kommt dann zu allem überfluss auch noch eine englisch schwäche bzw. eine ärgerliche doppeldeutigkeit hinzu. ich finde durchaus, dass tesseracts hauptstärke der out-of-the-box komplettworkflow inklusive der riesigen menge an gemischten modellen für moderne skripte/sprachen ist, allerdings kann das verwendete "falls short" neben dem intendierten "kann das bei historischen drucken nicht matchen" eben auch "versagt auf historischen drucken" bedeuten, was natürlich nicht stimmt aber hier wohl häufig so aufgefasst werden wird.

    ich muss zugeben, dass mich die geschichte maßlos ärgert, da das ganze selbstverständlich in keinster weise meinen/unseren sonst mmn vergleichweise sehr hohen ansprüchen an sorgfalt etc. bei veröffentlichungen entspricht. letztendlich bleibt mir jetzt aber leider zunächst lediglich ein (in diesem punkt) bedingungsloses und durchaus beschämtes "mea culpa". ich werde jetzt mal den editor kontaktieren (das paper ist mittlerweile natürlich veröffentlicht :-X) und fragen, ob sich da noch etwas ändern lässt. noch einmal viel dank für den hinweis. scheiße.

    Stefan Weil
    @stweil
    @chreul, auch von mir herzlichen Glückwunsch zum Nachwuchs und alles Gute.
    Bezüglich der aus dem dta19 Korpus gewonnenen Trainingsdaten: gibt es eine Chance, diese noch nachzubessern, z. B. bestimmte systematische Fehler zu korrigieren?
    Das Training kommt inzwischen sowohl bei Calamari als auch bei Tesseract in Bereiche, wo Fehler in den GT-Daten relevant werden.
    Christian Reul
    @chreul

    @stweil vielen dank :-)

    ich habe mir die ursprünglichen daten bzw. die daten, die ich und vermutlich auch uwe damals vor jeglicher weiterverarbeitung erhalten haben, noch einmal angesehen und leider sind auch die bereits vorverarbeitet und die buchstabenteile fehlen auch dort schon. wenn überhaupt, könnte johannes evtl. noch die farbzeilen haben aber ich befürchte, dass die zeilen aus bereits vorarbeiteten seitenbildern extrahiert und dann erkannt und gematcht wurden. tendenziell könnte man das ganze, vermutlich dann auf pagexml basis, noch einmal wiederholen aber ich weiß nicht, ob es den aufwand wert ist.

    wie häufig treten diese schwereren fehler denn in etwa auf? es stimmt natürlich, dass das dem training nicht gerade hilft aber solange die betroffenen zeilen nicht zur evaluation verwendet werden und das nur ab und zu einmal auftritt, würde ich eigentlich keinen größeren einfluss erwarten.

    trainiert ihr eure modelle eigentlich immer auf allen vorhandenen daten? dadurch, dass bei den frei verfügbaren fraktur19 daten die zeilenanzahl pro werk so stark schwankt (dta19 teilweise 10.000+, archiscribe häufig 50-) haben wir sehr gute erfahrungen damit gemacht, zuerst auf allem zu trainieren, was da ist und anschließend das resultierende modell noch einmal zu verfeinern bzw. breiter aufzustellen, indem man aus jedem vorhandenen werk z. b. noch einmal max. 50 zeilen auswählt und damit nachtrainiert. ich glaube wir hatten da damals bereits an die 150 frakturwerke aus dem 19. jh. die könnte man dann ggf. auch noch einmal halbwegs effizient auf vorverarbeitungs und segmentierungsfehler prüfen.

    Kay-Michael Würzner
    @wrznr
    @chreul Ich danke Dir für Deine ehrlichen Worte und natürlich kann so etwas passieren. Man muss hier natürlich auch die Reviewer kritisieren, denen diese offensichtlich unterschiedlichen Maßstäbe, die an die einzelnen Werkzeuge angelegt werden, und die latente tendenziöse Beschreibung von tesseract nicht aufgefallen sind. Den Vorschlag, eine gemeinsame, vorurteilsfreie Evaluierung zu machen, finde ich richtig gut. Gestern hatte ich die Gelegenheit, mit @uvius darüber zu sprechen. Er wäre auch sehr an einer Kooperation hier interessiert!
    Christian Reul
    @chreul
    tjo, die reviewer haben sich tatsächlich (leider) fast ausschließlich auf die länge des papers eingeschossen. 55 seiten waren evtl. wirklich etwas viel :-). die gemeinsame evaluation ließe sich dann wohl tatsächlich gut als kleines AG projekt durchführen bzw. zumindest teilweise damit verknüpfen. können wir ja bei der nächsten telko und/oder in paderborn näher besprechen. wäre auch ein guter aufhänger für ein erstes "working paper".
    andbue
    @andbue
    Falls jemand hier an Zeilensegmentierung sitzen sollte: Ben Kiessling steckt offenbar gerade recht viel Arbeit in einen trainierbaren Segmenter, der Baselines produziert die dann mit seam carving zu Polygonen erweitert werden. [https://github.com/mittagessen/kraken/blob/blla/kraken/lib/segmentation.py]. Das ganze scheint trainierbar auf der Basis von PageXML, alto oder binären Masken zu sein. Falls jemand zufällig Baselines herumliegen hat, wäre es sehr spannend, das mal auszuprobieren!
    Clemens Neudecker
    @cneud

    https://www.dropbox.com/s/lpcvz9eph1hsiov/Zwischenergebnisse.pdf

    :clap: Hoffe wir können die nächste Tage auch noch dazu sprechen!

    stefanCCS
    @stefanCCS
    CCS_2020-03_DHdPaderborn_OCR-AG.pdf
    Die Folien wie heute gezeigt ...
    Clemens Neudecker
    @cneud

    CCS_2020-03_DHdPaderborn_OCR-AG.pdf

    Schön das CCS schon ALTO 4.1 bietet (Alleinstellungsmerkmal!). Wohl auch ein Verdienst von Joachim :-)

    stefanCCS
    @stefanCCS
    Danke für die Blumen ...
    ... als ALTO-Erfinder solten wir aber schon versuchen vorne weg mit zu gestalten ...
    ... und ja, Joachim hat da sicherlich einen wichtigen Beitrag geleistet.
    Clemens Neudecker
    @cneud
    @chreul DHd2020 Mitgliederversammlung: done - Danke für die Folien!
    Christian Reul
    @chreul
    servus, danke fürs vertreten, auch an konstantin.
    wenn sich hier wieder alles etwas normalisiert hat, arbeite ich das treffen mal ein bisschen auf (da wirds wohl auch rückfragen geben) und melde mich dann wieder bzgl. des weiteren vorgehens.
    Kay-Michael Würzner
    @wrznr
    @stefanCCS „ALTO-Erfinder“: Krass. Das wusste ich gar nicht. Ich dachte immer ALTO wäre von einer ganzen Gruppe von Institutionen und Firmen im Rahmen des METAe-Projekts entwickelt worden. So kann man sich irren.
    Kay-Michael Würzner
    @wrznr
    Auch die Doku unter https://github.com/altoxml/documentation müsste ggf. angepasst werden.
    Clemens Neudecker
    @cneud
    @wrznr Ich glaube Günter würde auch darauf bestehen seine Finger bei der Kreation von ALTO mit im Spiel gehabt zu haben :smiley:
    Kay-Michael Würzner
    @wrznr
    @cneud Interessant.
    stefanCCS
    @stefanCCS
    @wrznr , @cneud : Ich wollte hier gar nicht so angeben, dass wir die "einzig, waren ALTO-Erfinder" sind und insbesondere möchte ich auf keinen Fall die Leistung von anderen schmälern. Die Aussage sollte eher dahin deuten, dass wir halt vom Anfang an aktiv dabei sind ...