synOCR synOCR - GUI für OCRmyPDF

[Monacum]

Du gibst eine OCR Rename Syntax an, aber eigentlich soll die Umbenennung ja über deine Regeln stattfinden, das beißt sich aus meiner Sicht. Da darf beispielsweise bei der Lebensversicherung nicht schon „Lebensversicherung“ auftauchen, weil deine YAML-Regel ja auch sagt, dass sie die Datei in „Lebensversicherung“ umbenennen soll. Ist quasi „doppelt gemoppelt“.

Bei mir steht in der OCR-Rename-Syntax als Einstellung X_§yocr4-§mocr-§docr§tag, der §tag wird dann über die YAML gesetzt hinter dem erkannten Datum. Das X_ hat nur die Bedeutung, dass ich mir die Datei nochmal anschaue, wenns eingescannt ist.

 

[Yippie]

Gut, verstehe ich, aber dennoch wird nur ein Profil verwendet und zudem werden in meinem Fall beide Quell-PDFs ins Ziel-Verzeichnis "./Cites" und keines in "./Lebensversicherung" gestellt.

Dies ist meines Erachtens aber unabhängig von der Benennung der Ziel-Dateien, oder?

 

[Monacum]

Was passiert denn, wenn du in der Regel als targetfolder noch Lebensversicherung angibst?

Und wenn nur das erste Profil verwendet wird, dann kann auch nichts in den Ordner Lebensversicherung verschoben werden.

 

[Yippie]

Was passiert denn, wenn du in der Regel als targetfolder noch Lebensversicherung angibst?

So hab ichs jetzt eingestellt (Auszug aus den beiden Tag-Dateien im jeweiligen Profil):

CITES_1:
    tagname: Cites
    tagname_RegEx: "[[:digit:]]{6}-[[:digit:]]{2,}"
    targetfolder: "/Cites/"

LV_1:
    tagname: Lebensversicherung
    tagname_RegEx:
    targetfolder: "/Lebensversicherung/"

Ändert jedoch gar nichts, zumindest nicht so wie erwartet: Eine Datei "Cites DE-DEG.pdf" außerhalb eines definierten Zielverzeichnisse, aber diese Ziel-Datei wäre dort ohnehin nicht richtig gewesen, denn die hätte ins Ziel-Vz "Lebensversicherung" gemusst.

und eine zweite Datei im korrekten Zielverzeichnis mit Namen "Cites DE-DEG220420-80.pdf".

Somit ist klar, dass das Profil "Lebensversicherung" niemals zum Einsatz kommt. Es wird offenbar nur ein Profil "Cites" verarbeitet und das schnappt sich beide Quell-PDFs. Eine davon kann es richtig zuordnen und ins korrekte Ziel-Vz stellen, das andere wird ebenfalls vom Profil "Cites" verarbeitet und korrekterweise falsch "interpretiert" und von daher nicht weiter umbenannt.

Das zweite Profil findet offenbar keine Quell-PDFs mehr und durchläuft keinen OCR-Prozess mehr.

Und wenn nur das erste Profil verwendet wird, dann kann auch nichts in den Ordner Lebensversicherung verschoben werden.

Das ist klar, aber warum wird in meinem Fall ausschließlich das erste Profil bzw. nur ausschließlich ein Profil verwendet?

 

[Monacum]

Weil das, wie Stephan oben schrieb, die Voreinstellung ist. Ein Profil dient dazu, einen Ordner zu überwachen, es funktioniert nicht, einen Ordner mit mehr als einem Profil überwachen zu lassen. Macht auch überhaupt keinen Sinn, erstelle einfach ein Profil, kombiniere deine beiden Regeln in einer Datei und dann verschiebt er das auch so, wie du das haben willst.

Ich habe wie gesagt auch mehrere Profile, bei mir werden aber auch die Dokumente in unterschiedliche Ordner gescannt und dann funktioniert das auch so wie von dir geplant.

 

[geimist]

Die Sache ist die:

• das erste Profil wird abgearbeitet
• es gibt keine einschränkende Kriterien - alle Dateien vom Quellverzeichnis werden abgearbeitet
• treffen keine Regeln zu, wird die Zieldatei lediglich im Root vom Ausgabeverzeichnis abgelegt
• das Quellverzeichnis enthält jetzt keine Dateien mehr
• jetzt wird das zweite Profil aufgerufen, welches keine Dateien mehr im Quellverzeichnis findet

Lösungsansätze:

Ich schiebe nun zwei Dateien gleichzeitig ins das Eingabe-Verzeichnis. "IMG_LV.pdf" und "IMG_CITES.pdf".

1. Gibt es eine Möglichkeit, deine Dokumente namentlich im Quelldateinamen zu unterscheiden?
   Vielleicht kannst du bei deinem Scanner ein zusätzliches Profil anlegen, welches den Dateinamen anpasst. Dann könnte man mit Suffix oder Präfix arbeiten
2. kannst du in unterschiedliche Quellordner scannen?
3. die zweite Möglichkeit ist weniger sauber:
   definiere im 1. Profil als Ausgabeverzeichnis das QUELLVERZEICHNIS
   alle Dateien, welche von der ersten Regel nicht in ein regeldefiniertes Verzeichnis verschoben werden (verwende idealerweise absolute Pfade, damit keine Unterordner im Quellverzeichnis verwendet werden, fall das stören sollte), verbleiben im Quellverzeichnis und sind für das nächste Profil verfügbar. Den OCR-Parameter -s (für skip Text) hast du ja schon angegeben. OCRmyPDF wird aber dennoch aufgerufen werden, auch wenn die Texterkennung nicht erneut durchgeführt wird.

(Ich hoffe, ich habe alle wesentlichen Punkte beim Querlesen der letzten Beiträge erfasst.)

 

[Avalox]

Wenn du ein Image manuell einspielst, musst du es auch in der GUI explizit auswählen. Dazu noch anmerkend: Die Fehlermeldung betrifft das Image von jbarlow83. In der GUI ist 'mein' Polyglot-Image ausgewählt. Möglicherweise hast du in unterschiedlichen Profilen verschiedene Images ausgewählt. Das bitte auch checken.

Das war/ist der entscheidende Punkt. Danke für den Hinweis. Habe noch das Dockerimage in der GUI geändert. Damit läuft auch die Verarbeitung wie Sie soll. Vielen Dank für den Support

 

[psychochicken80]

Hast du mal die verlinkte Version probiert?

Nein, dachte nicht, dass der Link für mich war. Allerdings funktioniert der auch gar nicht (für mich).

Habe -2 für Datum in der Vergangenheit eingetragen, da funktioniert es.

Zu diesen Einstellungen:
0 steht hier für unbegrenzt... Allerdings will ich z.B. überhaupt nicht in die Zukunft gucken. Ich kann natürlich jedes Jahr die Einstellung auf das aktuelle Jahr ändern, darf man dann natürlich nicht vergessen. Was passiert eigentlich, wenn man 2022 stehen lässt. Dann funktioniert es nächstes Jahr vermutlich nicht mehr so richtig? Probiere ich nachher auch mal aus...
0 sollte meiner Meinung nach für nichts stehen, also keine Suche in der Richtung. Ich finde +999 oder -999 sind eigentlich gleich unbegrenzt, oder?

 

[geimist]

Nein, dachte nicht, dass der Link für mich war. Allerdings funktioniert der auch gar nicht (für mich).

Sorry, das war in der Tat unglücklich formuliert.
@Gthorsten war fleißig und hat die Auswertung verbessert. Die Tage kommt noch ein neuer Build.

Allerdings will ich z.B. überhaupt nicht in die Zukunft gucken.

Zusätzlich kannst du noch "Datum Suchergebnis Reihenfolge" anpassen. Setzt du hier "jüngstes Datum in der Vergangenheit", sollte kein Datum in der Zukunft gesucht werden. Diese zwei Parameter überschneiden sich hier etwas in der Funktion.

 

[Gthorsten]

Nein, dachte nicht, dass der Link für mich war. Allerdings funktioniert der auch gar nicht (für mich).

Habe -2 für Datum in der Vergangenheit eingetragen, da funktioniert es.

Zu diesen Einstellungen:
0 steht hier für unbegrenzt... Allerdings will ich z.B. überhaupt nicht in die Zukunft gucken. Ich kann natürlich jedes Jahr die Einstellung auf das aktuelle Jahr ändern, darf man dann natürlich nicht vergessen. Was passiert eigentlich, wenn man 2022 stehen lässt. Dann funktioniert es nächstes Jahr vermutlich nicht mehr so richtig? Probiere ich nachher auch mal aus...
0 sollte meiner Meinung nach für nichts stehen, also keine Suche in der Richtung. Ich finde +999 oder -999 sind eigentlich gleich unbegrenzt, oder?

Ok, das könnte man natürlich überlegen. Also 0 gleich nicht in Zukunft oder Vergangenheit, je nachdem wo es steht, und 999 für unbegrenzt.
@geimist ich hatte auch überlegt, das es ein nettes Feature wäre, gültige dstumsbereiche für jede rule zu wählen. Also als Beispiel eine Versicherung die erst 2022 abgeschlossen wird, kann ja auch Datumswerte ab 2022 haben.
Eine Kfzversicherung vlt schonab 2020...

Also eine globales min Max und wenn ich regel vorhanden, dann das als range.

 

[Yippie]

Lösungsansätze:

Frage: wäre es möglich die "OCR Rename"-Variablen auch in den YAML-Regeln zu verwenden und zwar nicht in den Zielpfaden, sondern in "tagname"?

CITES_1:
    tagname: "Cites DE-DEG§tag"
    tagname_RegEx: "[[:digit:]]{6}-[[:digit:]]{2,}"
    targetfolder: "/Cites/"
    condition: all
    subrules:
    - searchstring: "EUROPEAN UNION"
      searchtyp: is
      isRegEx: false
      source: content
      casesensitive: false
    - searchstring: "[[:digit:]]{6}-[[:digit:]]{2,}"
      searchtyp: contains
      isRegEx: true
      source: content
      casesensitive: false

LV_1:
    tagname: "§yocr4-§mocr-§docr Lebensversicherung"
    tagname_RegEx:
    targetfolder: "/Lebensversicherung/"
    condition: all
    subrules:
    - searchstring: "Versicherungsnummer"
      searchtyp: is
      isRegEx: false
      source: content
      casesensitive: true
    - searchstring: "LV-1111-2222-3333"
      searchtyp: is
      isRegEx: false
      source: content
      casesensitive: true

Warum die Frage? Ich würde jetzt Mal genau ein Profil erstellen und in der YAML-Datei den oben dargestellten Code kopieren.

Mein Gedanke dabei ist, dass es dann mehrere Regeln "CITES_1" und "LV_1" gibt die, soweit hab ichs bereits testen können, auch von synOCR beachtet werden.
Des Weiteren kann ich dabei ja je Regel ein eigenes UVz angeben. Nur aktuell habe ich das Problem, dass die Variablen in "tagname" nicht beachtet werden, in "targetfolder" jedoch schon.

Wäre es möglich in einer künftigen Version von synOCR, dass die Rename-Variablen auch in "tagname" beachtet werden?

Wie allerdings mit den folgenden Zeilen umgegangen wird, weiß ich noch nicht.

CITES_1:
    tagname: "Cites DE-DEG§tag"
    tagname_RegEx: "[[:digit:]]{6}-[[:digit:]]{2,}" 
  ...
    - searchstring: "[[:digit:]]{6}-[[:digit:]]{2,}"

Möglicherweise muss hierfür auch ein neues Tag noch eingeführt werden, um den (ersten) zutreffenden searchstring in tagname verwenden zu können, bspw.

CITES_1:
    tagname: "Cites DE-DEG§searchstr"
    tagname_RegEx: 
  ...
    - searchstring: "[[:digit:]]{6}-[[:digit:]]{2,}"

 

[allahopp]

Hätte mal noch eine Verständnisfrage (um meinen Wissenshorizont zu erweitern):

Wofür wird bei der Ausführung von synOCR eine Gruppe "docker" angelegt und wofür wird dieser bei der Abarbeitung des Skripts benötigt?

 

[Gthorsten]

Das umwandeln des PDF in Text wird durrch ocrmypdf erledigt. Das ist ein. Programm was in einer docker Umgebung ausgeführt wird. Und die Gruppe braucht docker unter Linux

 

[geimist]

Ok, das könnte man natürlich überlegen. Also 0 gleich nicht in Zukunft oder Vergangenheit, …

Ich werde es mir überlegen. Mit dem Vorschlag über den Weg von "jüngstes Datum in der Vergangenheit" sollte es ja erst mal realisierbar sein.

ich hatte auch überlegt, das es ein nettes Feature wäre, gültige dstumsbereiche für jede rule zu wählen.

Mit regelbasierten Datumsbereichen wären dann aber größere Umbauarbeiten nötig. Derzeit sind das getrennte Funktionen. Mal gucken …

CITES_1:
    tagname: "Cites DE-DEG§tag"
    tagname_RegEx: "[[:digit:]]{6}-[[:digit:]]{2,}"

Für was soll denn in dem Fall §tag stehen? Derzeit enthält §tag alle gefundenen Tags. Cites DE-DEG§tag würde ja sich selbst benennen.

Man müsste aber mal gucken, ob man RegEx so definieren kann, dass ein Wunschtext davor oder danach mit ausgegeben werden kann, der nicht Teil der Prüfung ist. Dafür kenne ich mich aber mit RegEx zu wenig aus. Vielleicht hat jemand eine Idee?

Wofür wird bei der Ausführung von synOCR eine Gruppe "docker" angelegt und wofür wird dieser bei der Abarbeitung des Skripts benötigt?

Noch ergänzend zu @Gthorsten seiner Antwort:
Docker braucht root-Rechte. Daher muss im Aufgabenplaner auch root als User ausgewählt werden. Soll aber über die GUI ein Programmlauf angestoßen werden können, so müsste man den User synOCR zu root machen. Das geht aber nicht so. Daher die gemeinsame Gruppe docker.

 

[Avalox]

Hi,

muss mich doch noch mal melden. Im Grunde läuft mein System nun fast perfekt. Dabei habe ich nur den Anspruch, dass die PDF´s OCR gelesen werden und im Zielpfad abgelegt werden. Ich mach also keine Filterung oder ähnliches.

Meine Schwierigkeit habe ich jetzt noch bei Dokumenten welche in der Ausgangsdatei im Querformat gespeichert sind. Ich habe zwar bei den "OCR Optionen" den Befehl zur automatischen Drehung angegeben.

-f -r -l deu+eng

Aber das klappt nicht oder nur teilweise. Gibt es noch andere Möglichkeiten dies zu erzwingen?

Vielen Dank.

 

[geimist]

@Avalox
Guck mal hier: #981

 

[peterhoffmann]

Derzeit in meinem Hauptprofil so:
--author xxx --jobs 4 --rotate-pages --rotate-pages-threshold 5 -dc --skip-text --clean-final -l deu --jbig2-lossy --optimize 3

Ich scanne in der Regel in schwarz/weiß und lege Wert auf möglichst kleine Dateien. Hier hilft --jbig2-lossy --optimize 3

Sind das noch deine aktuellen Einstellungen?

 

[Avalox]

@Avalox
Guck mal hier: #981

Tatsächlich habe ich mir das schon angeschaut. Mir ist aber unklar wo ich diesen Befehl hinterlegen muss? Kommt das in die Aktion (benutzerdefiniertes Script) der Aufgabe?

 

[geimist]

Mir ist aber unklar wo ich diesen Befehl hinterlegen muss?

Dort hin, wo du schon deine anderen OCRmyPDF-Parameter in deinem Profil in der GUI gesetzt hast. Also z.B. so:
-f --rotate-pages --rotate-pages-threshold 5 -l deu+eng

Sind das noch deine aktuellen Einstellungen?

Ja. Wenn's läuft, läufts …
Ich optimiere da nicht ständig. Aber wenn es andere Erfahrungen gibt, probiert man auch gerne mal aus.

 

[Yippie]

Man müsste aber mal gucken, ob man RegEx so definieren kann, dass ein Wunschtext davor oder danach mit ausgegeben werden kann, der nicht Teil der Prüfung ist. Dafür kenne ich mich aber mit RegEx zu wenig aus. Vielleicht hat jemand eine Idee?

DAS wäre eine Lösung, die ich auch schon getestet habe und habe sozusagen als Prefix einen Text vor dem eigentlichen reg. Ausdruck gestellt.

Ergebnis war jedoch nicht prickelnd, da die Zeile tagname_RegEx wohl den kompletten Ausdruck zur Evaluierung verwendet und nicht nur einen Teil davon. Man könnte, und da bin ich wieder bei dir Stefan, wohl überlegen noch einen Art tagname_Prefix und meinetwegen noch tagname_Postfix einführen, welcher dann das das finale Tag als zusammengesetzten String aus tagname_Prefix + tagname_RegEx + tagname_Postfix baut. Leerzeichen sollten dabei, wenn innerhalb der Zeichenkettet vorkommen, wie " Dies ist mein Prefix ", beachtet und nicht abgeschnitten werden.

Ich gehe davon aus, dass du der Programmierer bist, soweit ich dies bisher verstanden habe und dass du sowas einbauen könntest?

Aber letztendlich bleibt immer noch die Frage, ob auch die anderen Tags die heute schon im der Oberfläche genutzt werden können, wie §yocr4-§mocr-§docr, sowohl in tagname und in den neuen Optionen tagname_Prefix, tagname_Postfix genutzt werden können sollen.