synOCR synOCR - GUI für OCRmyPDF

[geimist]

Wie gesagt der Wert der Gruppe, also dessen Variable ist das Problem, hier unter "tagname_RegEx: (?<Auszugnummer>\d{1,2})".
Wie frage ich den Wert / das Ergebnis der Gruppe ab bzw. gebe es aus.

(also mit RegEx kann ich dir bestimmt nicht helfen - da bist du offensichtlich fit genug)

Ich verstehe dein Problem noch nicht so ganz.
tagname_RegEx greift nicht auf den Fund der Regel zurück, sondern sucht eigenständig im Dokument. Liegt da ein Missverständnis vor?

 

[Struppix]

Ohje, ich befürchte ja.
Ich dachte das wäre das Resultat der Suche.

Nun, ich hoffe hier kann mir wer weiterhelfen.

Gruß
Karsten

 

[geimist]

Deshalb schrieb ich:

Der Regex gilt für das gesamte Dokument. Also erstellst du dir einen Regex, der dir in dem Fall nur die 14 ausgibt.

Hintergrund ist der, dass mit tagname_RegEx gezielt nach anderen Mustern für den Namen gesucht werden kann, als für die Erfüllung der Regel (so manch einer will es ja unabhängig davon nutzen).

Somit sollte dir doch mit einem einfachen RegEx in tagname_RegEx, der dir die Auszugsnummer liefert geholfen sein, oder?

 

[Struppix]

Genau das ist das Problem. Ich habe zu wenig Ahnung davon. Das sind meine ersten Versuche.

Ich kenne die Position der Nummer hinter dem Datum. Weiß aber nicht wie ich dies als Wert / Ergebnis abfrage / übergeben kann.

Für mich halt Neuland.

Gruß
Karsten

 

[Yippie]

Was schön wäre, wenn man in jeder Regel beliebig viele eigene Tags mit entsprechendem Suchmuster definieren könnte, um diese dann an beliebiger Stelle der Regel, bspw. im Dateinamen, wieder zu verwenden.

usertag: meintag_1,\d{1,2}
usertag: name_dokument,.*

 

[Struppix]

Was schön wäre, wenn man in jeder Regel beliebig viele eigene Tags mit entsprechendem Suchmuster definieren könnte, um diese dann an beliebiger Stelle der Regel, bspw. im Dateinamen, wieder zu verwenden.

usertag: meintag_1,\d{1,2}
usertag: name_dokument,.*

Das ist ja genau was ich versuche, aber zu wenig Ahnung von RegEx habe.
Per Suchstring die Passage finden und dann als Tag ausgeben.
Die verschiedenen Suchen = Tags musst Du dann auch in mehrere Regeln packen, aber das stört nicht ...

 

[geimist]

Ok, also brauchen wir für RegEx einen lookbehind.
Ein Beispiel hatte ich im Wiki aufgeführt.

 

[Struppix]

Bekomme das einfach nicht in. Verstehe den Syntax nicht.

 

[geimist]

Poste mal bitte eine Beispielzeile und beschreibe, was da immer vorkommt.

Edit:
Ich hab mal dein Beispiel vom Screenshot genommen: 09.11:2013-06:12:2013•14
Mit diesem RegEx erhält man die 14, wobei sich die Zahlen, aber nicht deren Anordnung davor ändern darf:
(?<=([0-9]{2}\.[0-9]{2}:[0-9]{4}-[0-9]{2}:[0-9]{2}:[0-9]{4}•{1}){1})[0-9]+

Falls es sich bei dem Punkt vor der 14 um ein Leerzeichen handeln sollte, dann so:
(?<=([0-9]{2}\.[0-9]{2}:[0-9]{4}-[0-9]{2}:[0-9]{2}:[0-9]{4}[\s]{1}){1})[0-9]+

(Link)

 

[Struppix]

Hallo Stephan,

super danke. Muss das nur noch verstehen ...

Karsten

 

[geimist]

REGEX KANN MAN NICHT VERSTEHEN

Guck dir mal den Link an. In der rechten Spalte werden alle Elemente aufgelistet. Ich würde dir auch empfehlen, zunächst das Erfüllen der Regel zu testen und dich anschließend um den Tagnamen zu kümmern – Step by Step.

Ggf. müssen die Sonderzeichen auch noch etwas variabel gestaltet werden, wenn z.B. von der OCR einmal ein Punkt und einmal ein Komma erkannt wird. Dazu setzt man dann die möglichen Zeichen in eckige Klammern und danach noch die erforderliche Anzahl in geschweifte Klammern. [,.]{1}

 

[Struppix]

Hallo Stephan,

ich mal wieder ...
Habe inzwischen einige recht interessante Regeln erstellt. Die Möglichkeiten sind der Wahnsinn. Man kann sich so echt tolle Filenamen aus den Dokumenten zusammenbauen.

Eine völlig andere Frage: Ich bin gerade an diesen steinalten Kontoauszügen. Deren Qualität ist nicht mehr so doll. Es wird mit dem OCR nur Grütze ausgewertet. Komisch ist aber, dass aber das Datum immer richtig ist, egal wie schlecht der Scan bzw. das Original war.
Wo ist der Unterschied und hat man einen Einfluss darauf.

Weiterhin, wieso wird eigentlich immer ein Bindestrich verwendet, hier zB. beim Datum? Die meisten Programme (insb. Windows) interpretieren dies immer als Trennzeichen, was manchmal echt nervig sein kann. Gut kann ja automatisch zb. mit Joe drüber gehen. Wollte nur mal fragen

Gruß
Karsten

 

[Gthorsten]

Das mit dem Datum ist ganz einfach. Ich finde das Datum, formatierte es so und gebe es an Stephan zurück, und der nimmt es so als Teil des Dateinamen..

 

[geimist]

Komisch ist aber, dass aber das Datum immer richtig ist, egal wie schlecht der Scan bzw. das Original war.

Thorstens Datumssuche übertrifft halt alle Erwartungen

Wenn du das Loglevel auf 2 (debug mode) stellst, wird dir der gesamte OCR-Text ein eine eigene Textdatei im Logordner geschrieben. Da siehst du das, was als Grundlage für die Suche dient.

Weiterhin, wieso wird eigentlich immer ein Bindestrich verwendet, hier zB. beim Datum?

Was meinst du da genau?
Den Dateinamen (inkl. Datumszusammenstellung) kannst du dir ja in der GUI selbst zusammenstellen. Default sind da halt Bindestriche drin, kannst sie aber auch beliebig tauschen.

PS: @Struppix
Funktioniert jetzt die RegEx?

 

[Struppix]

Guten Morgen Stephan,

die RegEx Regeln funktionieren prima. Auch wenn ich noch experimentiere, sind da echt tolle Möglichkeiten.

Sicherlich kann ich die Bindestriche tauschen, aber sind doch voreingestellt

Das Log muss ich mal durchforsten. Sind zwischen den beiden Varianten, sprich Datum und OCR unterschiedliche Engines? Das ist schon verrückt, das die Erkennung so extrem schwierig ist, wenn die original Dokumente in so schlechter Qualität sind. Sind halt schon alt und ziemlich vergilbt.

Gruß
Karsten

 

[Gthorsten]

Ja und nein. Alles läuft in einem Skript.
Stephan ruft dann verschiedene Module auf. Zb ocr im docker, dann meine datumserkennung in python usw...

 

[Struppix]

Hallo @Thorsten @ Stephan,
einige Protokolle wimmeln nur so von Fehlern

Ja und nein. Alles läuft in einem Skript.
Stephan ruft dann verschiedene Module auf. Zb ocr im docker, dann meine datumserkennung in python usw...

Die Datumserkennung läuft sauber durch.

Thorstens Datumssuche übertrifft halt alle Erwartungen

Wenn du das Loglevel auf 2 (debug mode) stellst, wird dir der gesamte OCR-Text ein eine eigene Textdatei im Logordner geschrieben. Da siehst du das, was als Grundlage für die Suche dient.


Was meinst du da genau?
Den Dateinamen (inkl. Datumszusammenstellung) kannst du dir ja in der GUI selbst zusammenstellen. Default sind da halt Bindestriche drin, kannst sie aber auch beliebig tauschen.

PS: @Struppix
Funktioniert jetzt die RegEx?

Ansonsten habe ich aber diverse Fehler. Kann aber gerade nicht auf die Syn zugreifen, mein DDNS streikt wieder einmal
@ Stephan ich schicke Dir mal ein paar Protokolle, die ich noch auf dem Tab habe, da das wohl im System (oder bei mir, muss mich hier ja nicht wegen Unkenntnis outen) zu liegen scheint. Die sind noch Level 1. Testen mit Level 2 kann ich dann erst heute Abend.

Was mich nur wundert, die Scans von den neueren Dokumenten laufen alle sauber durch, nur bei den alten spinnt er. Da wird totales Sauerkraut ausgelesen. Habe es schon mit diversen Einstellungen versucht, mit mehr oder weniger Erfolg. Die Quote ist aber 1:4 oder schlechter. Will aber nicht ausschließen, dass das an mir oder meinem System liegt. Die Datumserkennung funktioniert immer.

Scannen tue ich mit dem ADS-1700W. Getestet habe ich alle dpi Varianten mit maximalem Kontrast uvm. Müsste vielleicht nochmal in Graustufen testen.

Vielen lieben Dank
Karsten

 

[geimist]

@ Stephan ich schicke Dir mal ein paar Protokolle, die ich noch auf dem Tab habe, da das wohl im System (oder bei mir, muss mich hier ja nicht wegen Unkenntnis outen) zu liegen scheint. Die sind noch Level 1. Testen mit Level 2 kann ich dann erst heute Abend.

In den ersten Logs schien es so, dass es da noch einen Fehler in der YAML-Syntax gab. Das war aber in den neueren behoben.

Darüber hinaus gab es die Meldung, dass du in den Regeln zwar regelbasierte Zielordner definiert hast, aber in der GUI nicht die passende Einstellung gesetzt hast (verwende Regel-definierte Ordner).

Das Loglevel 2 würde ich dir nur empfehlen, wenn man es unbedingt baucht (z.B. um sich mal den erkannten Text ausgeben zu lassen). Aufgrund der vielen Informationen ist es nicht die erste Wahl, Fehler zu finden.

Was mich nur wundert, die Scans von den neueren Dokumenten laufen alle sauber durch, nur bei den alten spinnt er. Da wird totales Sauerkraut ausgelesen.

Du kannst mal testen, ob es hilf, in den OCR-Paramtern statt -s (skip Text) -f (force / OCR erzwingen) zu setzen. Vielleicht hilft das schon.

 

[Struppix]

Hallo Stephan,

danke, dass Du Dir die Zeit hierfür nimmst.

In den ersten Logs schien es so, dass es da noch einen Fehler in der YAML-Syntax gab. Das war aber in den neueren behoben.

Ja das wird in mehreren Protokollen auftauchen. Ich teste immer verschiedene Varianten, um auszuschließen, dass die Regeln sich gegenseitig beeinflussen. Habe hier Listen aus denen ich mir die dann zusammen kopiere.

Darüber hinaus gab es die Meldung, dass du in den Regeln zwar regelbasierte Zielordner definiert hast, aber in der GUI nicht die passende Einstellung gesetzt hast (verwende Regel-definierte Ordner).

Das habe ich noch aus, da es mühselig ist, diese dann nach dem Testen rauszulöschen. Es ist schon interessant, wenn ich es richtig interpretiere, dass die Regeln von hinten nach vorne abgearbeitet werden, aber sich dann der Name von vorne nach hinten zusammensetzt. So habe ich die Anweisung zum Verschieben in der jeweils ersten Regel einer definierten Kategorie.

Du kannst mal testen, ob es hilf, in den OCR-Paramtern statt -s (skip Text) -f (force / OCR erzwingen) zu setzen. Vielleicht hilft das schon.

Prima Tipp: Werde ich gleich probieren, wenn ich daheim bin.

Wieder mal etwas wo ich mich richtig verspielen kann. Muss nur aufpassen Zuhause keinen Ärger zu bekommen

Gruß
Karsten

 

[geimist]

Wieder mal etwas wo ich mich richtig verspielen kann. Muss nur aufpassen Zuhause keinen Ärger zu bekommen

Mach doch ein Familienprojekt draus – da haben alles was davon