synOCR synOCR - GUI für OCRmyPDF

[geimist]

Ein j-Modell (= Junior) dient halt vorrangig dem Speichern von Daten. Sobald man da etwas mehr von ihnen verlangen würde, hätte man eh nicht viel Freude damit, weil die CPU einfach zu schwach ist.

Ich kann mir auch nicht vorstellen, dass du Docker schon mal auf diese Weise hättest installieren können.

 

[geimist]

Meines Wissens nicht. Wenn du z.B. ARM Prozessor fährst dann wird Docker dort nicht funktionieren.
Ich bin zwar kein super Experte im Docker-Bereich, aber das ist was ich so gelesen habe.

Nicht unbedingt. Es gibt Docker auch für arm64. Dann auf einer Synology aber nur über eine frickelige manuelle Installation. Für die DS220j sehe ich da keine Hoffnung, zumal der gewünschte Dockercontainer /—image auch für die entsprechende CPU bereitstehen muss.

 

[gunfran]

Moin @geimist
Ich hab auch gerade kurz mal danach gegoogelt. Scheint da wohl doch ein paar Möglichkeiten zu geben, allerdings hab ich da das Gefühl das bei der Zielgruppe der "kleinen" Modelle dies auch zu frickelig sein könnte mit auf shell-ebene arbeiten müssen usw.
Aber guter Hinweis.

 

[JackOh]

Die Output Datei wird immer mit einem falschen Datum benannt, obwohl ich einstelle, dass das Datum immer identisch mit der Quelldatei sein soll. Die Quelldatei kommt mit korrektem Datum-/Zeitstempel in den /input Ordner.

Woran kann das liegen?

Installierte Version: 1.2.0

 

[geimist]

Grundsätzlich würde ich dir mal die aktuelle Version 1.3 empfehlen, auch wenn es in diesem Bereich keine umfangreichen Änderungen gab - aber man weiß ja nie.

Wenn das nicht hilft, bräuchte ich mal ein entsprechendes Log (Uploadlink in meiner Signatur).

 

[Yippie]

Stephan,

gibt es eine Möglichkeit die Suche nach einem Datum, in einem gescannten Dokument, zu beeinflussen?

Beispielsweise durch die Angabe eines "Suchmusters" (RegEx) in der YAML-Datei, entweder in der Regel selbst oder in einer Subrule?

Damit meine ich jetzt nicht einen einfachen Suchtext anzugeben, sondern, wie synOCR generell das Datum für das aktuell gescannte Dokument finden soll, um damit die Tags, wie "§yocr4-§mocr-§docr" zu ersetzen.

Beispiel für eine mögliche Angabe "dateformat" in der YAML-Datei:

RENTE_1:
    tagname: "§yocr4-§mocr-§docr Renteninformation"
    tagname_RegEx: ""
    targetfolder: "/Rente/"
    condition: all
    dateformat: "dd.mm.yyyy" oder dateformat: "Datum dd.mm.yyyy" oder dateformat_RegEx: "Datum ^\s*(3[01]|[12][0-9]|0?[1-9])\.(1[012]|0?[1-9])\.((?:19|20)\d{2})\s*$"
    subrules:
    - searchstring: "Renteninformation"
      searchtyp: contains
      isRegEx: false
      source: content
      casesensitive: True

Hintergrund der Frage, siehe folgenden Ausschnitt eines Dokuments:

Aktuell wird das Datum bei (1) erkannt, ich hätte jedoch das Datum bei (2). Mit dem dateformat, wie oben angegeben, könnte ich mir vorstellen, das synOCR dann das Datum bei (2) findet, da "passender".

Gut, das Ganze ist sicherlich nicht wasserdicht, denn mit diesem Datumsformat könnten auch weitere Datum im Dokument in Frage kommen.

Möglicherweise könnte man das Ganze jedoch noch weiter aufbohren indem man eine weitere Option einbaut, sowas wie "dateindex: 2" und damit die Erkennung anweist, das zweite erkannte Datum zu verwenden?

Es gibt ja bereits eine Reihe von Option im GUI das Datum zu finden oder zu ignorieren, jedoch dürfte keine davon das ermöglichen wie ich oben dargestellt habe, oder?

Btw, im GUI existieren ja eine Reihe von Optionen, die ich in der YAML-Datei so nicht bei der jeweiligen Regel oder global einstellen kann, oder irre ich mich da? Bspw. alle unten stehenden:

Konkret die oben bei (1) markierte Option, kommt dem, was ich gerne hätte, ja schon sehr nahe, jedoch kann ich nur entweder das 1. Datum oder das jüngste Datum suchen lassen.

Wenn man diese Option noch ausbauen könnte, wie: 1. Treffer, 2. Treffer oder ganz einfach x. Treffer, und in die YAML-Datei als Option einer Regel integrieren würde (nicht global, da jedes Dokument unterschiedliche behandelt werden könnte), dann wäre dies die Lösung des "Problems".

Michael

 

[Gthorsten]

hallo Michael,
die Erkennung des Datums läuft in einer python routine, die ich Stephan dazugesteuert habe.
Aktuelle werden halt alle gültigen Datumsformate gefunden und intern gesammelt. Also numerische wie alphanumerische.
Danach word geschaut ob der Anwender was damit machen möchte. Also das jüngste oder das älteste etc.
einschränken lässt sich das im Moment nicht weiter.
Das mit dem n-ten Treffer macht ja nur Sinn, wenn man es dann pro Tag(Regel) einstellen könnte.
Auch die Vorgabe eines bestimmten Datums pattern macht so nur Sinn.

 

[Yippie]

Das mit dem n-ten Treffer macht ja nur Sinn, wenn man es dann pro Tag(Regel) einstellen könnte.
Auch die Vorgabe eines bestimmten Datums pattern macht so nur Sinn.

Hi! Danke für die Antwort!

Ich habe soeben die aktuellste Version von synOCR installiert und auf Datumserkennung Python umgestellt und damit findet synOCR schon mal das Datum (in meinem Screenshot oben) bei (1) nicht mehr. Ist auf alle Fälle ein erster Erfolg ;-) denn es wird das Datum bei (2) erkannt.

Und ja, das Ganze macht tatsächlich nur Sinn, wenn man es pro Tag einstellen kann. Aufgrund der Vielzahl von Datums-Tags wohl eher ein unwahrscheinliches Unterfangen.

Wie im zweiten Teil meiner Nachricht geschrieben, wäre es dann eher machbar den Suchindex ohne der Angabe eines Pattern aufzubohren?

 

[Gthorsten]

nun auch ein Pattern pro tag(Regel) lässt sich realisieren.
nur muss dann hier auch Stephan mit ran, weil zuerst eine Änderung der gui nötig wäre, damit ich den Parameter bekomme.

gleiches gilt auch für den Index.
Das muss vom gui in das Script und dann in meine python routine.
dafür muss Stephan ran.

mit pattern sehe ich allerdings die Gefahr das da zu viele Fehler durch den User entstehen können...

 

[Yippie]

Wäre es möglich in das GUI eine Option aufzunehmen, mit der man nach einen kompletten OCR Durchlauf ein Shell-Script ausführen kann? Vielleicht auch gleich nich eine zweite Option mit deren Hilfe man ein Script vor dem Start der OCR Erkennung laufen lassen kann.

Ggf. im Falle des Preprocessing Script auch den Returncode des Scripts auswerten und den weiteren Ablauf, im Fehlerfall, abbrechen.

Das Postprocessing Script wäre dann sehr hilfreich, wenn man bspw. per YAML die Ergebnisse in unterschiedlichen Verzeichnissen auf dem Server, auf dem synOCR läuft, zunächst speichert um die Dateien dann aber auf einen zweiten Server oder generell eine andere Location zu verschieben.

Hintergrund in meinem Fall: synOCR läuft auf NAS1, die richtige Ablage befindet sich auf NAS2. Bisher musste ich somit immer die Dateien manuell verschieben.

Die Frage ist auch, ob man die Angabe eines Scripts gleich in die jeweilige Regel der YAML Datei einbaut, somit könnte man unterschiedliche Scripte verwenden, die aber bspw. nur bei erfolgreich angewendeter Regel ausgeführt wird.

 

[Gthorsten]

kannst du nicht einfach den target folder auf die zweite nas zeigen lassen....?

 

[Yippie]

Ja, wäre auch möglich. Guter Tipp. Allerdings könnte man ein Script noch für viele andere Dinge verwenden. Fällt mir aber gerade nix ein

 

[geimist]

Wäre es möglich in das GUI eine Option aufzunehmen, mit der man nach einen kompletten OCR Durchlauf ein Shell-Script ausführen kann?

Ich sehe da eine große Gefahr, JEDEM User die Möglichkeit zu geben, einfach Code ausführen zu lassen.
Aber der versierte Benutzer kann das ja gerne selbst tun. In dieser Datei:
/usr/syno/synoman/webman/3rdparty/synOCR/synOCR.sh
ab dieser Zeile (hier für einen Post-OCR-Prozess):
https://git.geimist.eu/geimist/synOCR/src/tag/v1.3.0/APP/ui/synOCR.sh#L1779

Für ein generelles Postskript halt am Ende der Datei.

Ggf. im Falle des Preprocessing Script auch den Returncode des Scripts auswerten und den weiteren Ablauf, im Fehlerfall, abbrechen.

Das kann man ja auch selbst gleich erweitern:

<dein skript>
if [ $? != 0 ]; then
    echo "Fehler"
    # nächste Datei:
    continue
fi

Dabei muss man wissen, dass der Arbeitsablauf zweigeteilt ist. Im ersten Teil (Funktion main_1st_step) findet die Bildkonvertierung, das Trennseitenhandling und OCR aller Dateien statt. Im zweiten Schritt (Funktion main_1st_step) werden dann erneut alle Dateien bzgl. der Tags, Datum, Sortierung und Umbenennung verarbeitet. Der Ausstieg in obigen Beispiel würde nur zur nächsten Datei im aktuellen Programmteil springen.

Hintergrund in meinem Fall: synOCR läuft auf NAS1, die richtige Ablage befindet sich auf NAS2. Bisher musste ich somit immer die Dateien manuell verschieben.

Ich sehe hier spontan zwei Möglichkeiten:

1. die Remoteordnerfunktion der Filestation zu nutzen
2. die per YAML-Regeln erstellte Zielstruktur auf das Ziel-NAS zu verschieben (Stichwort: Parameter --remove-source-files)

 

[Chr!s]

Hallo Zusammen, ich hoffe Ihr steinigt mich nicht wenn ich hier vllt. falsch bin aber irgendwie passt mein Anliegen zu mehreren Topics...
z.B. hier im Forum habe ich meinen Workflow zu EcoDMS ja bereits beschrieben, grundsätzlich Arbeitet ecoDMS auch gut aber mittlerweile bringt mich das Thema Lizenzzählung (damit bin ich nicht alleine, auch dazu gibts hier schon ein Topic) und damit verbunden die Zugriffssperre zu EcoDMS zur Weißglut. Ich nutze ja bereits SynOCR für die OCR bevor es an ecoDMS geht. Daher habe ich nun folgende Überlegung und experimentiere noch etwas: parallel zu EcoDMS die Nutzung von Synology drive.

Wir greifen tatsächlich meistens über Handy/Tablet auf Dokumente zu meistens direkt nach dem Einscannen in sofern bietet Synology Drive folgende Vorteile:
- der WAF wäre sicherlich wesentlich höher, denn der Zugriff ist jederzeit mobil über Handy/Tablet möglich ggf. auch offline
- das Handling in der Drive App ist besser als der Webclient in EcoDMS
- die Ablage in der Ordnerstruktur in Verbindung mit der Synchronisierung stellt für mich durchaus auch eine gewisse Backupfunktion dar

Was mir in nun aber fehlt:
Synology drive(insbesondere die APP) zeigt mir leider nicht die neuesten Aktivitäten an. Also wenn ich etwas Scanne und direkt nach der Bearbeitung durch synOCR den Scan öffnen möchte, muss ich diese Datei erst wieder suchen. Eine art Suchfilter/Suchvorlagen bietet Drive ja scheinbar nicht.

=> lässt sich evtl. über eine Regel in synOCR einstellen dass alle Dokumente einmal in der Ordnerstruktur einsortiert werden und gleichzeitig eine Kopie in einem zentralen Ordner im Teamdrive Hauptverzeichnis abgelegt werden? Diesen könnte man ja dann regelmäßig leeren, es geht nur um den schnellen Zugriff nach dem Scan ohne weitere Suche.

Ich habe schon überlegt dafür den Backupordner von synOCR zu verwenden aber da ist ja die OCR glaube ich noch nicht drüber gelaufen.

=> gleiches nochmals für den inputordner von EcoDMS wobei ecoDMS die Dateien ja selber direkt löscht bzw. in die eigene Datenbank verschiebt

Aktuell möchte ich EcoDMS noch nicht ablösen denn ecoDMS hat durchaus auch seine Vorteile gegenüber Synology Drive bzw. einer Ordnerstruktur.

Freue mich über hilfreich Anregungen und Vorschläge.

 

[geimist]

Synology drive(insbesondere die APP) zeigt mir leider nicht die neuesten Aktivitäten an. Also wenn ich etwas Scanne und direkt nach der Bearbeitung durch synOCR den Scan öffnen möchte, muss ich diese Datei erst wieder suchen. Eine art Suchfilter/Suchvorlagen bietet Drive ja scheinbar nicht.

Das Thema gab es kürzlich. Es scheint so, dass die per Shell geänderten Dateien in Drive nicht getriggert werden. Erst wenn man sie öffnet, werden sie unter kürzlich auffindbar. Auch Tags für Drive lassen sich nicht einfach für Dokumente setzen, weil diese nicht in der Datei gesichert werden, sondern Benutzerabhängig ist.

Mir ist halt keine Dokumentation von Drive hierfür bekannt. Wenn es jemand weiß, bin ich sehr an Infos interessiert.

=> lässt sich evtl. über eine Regel in synOCR einstellen dass alle Dokumente einmal in der Ordnerstruktur einsortiert werden und gleichzeitig eine Kopie in einem zentralen Ordner im Teamdrive Hauptverzeichnis abgelegt werden? Diesen könnte man ja dann regelmäßig leeren, es geht nur um den schnellen Zugriff nach dem Scan ohne weitere Suche.

Vielleicht mit einer universellen RegEx-Regel. Dann muss man aber immer sicherstellen, dass zwei Regeln erfüllt werden (die Datei darf ja nicht nur in deinen zweiten Ordner landen, sofern es aufgrund der Universalregel geschieht).

 

[JackOh]

Datum und Uhrzeit der Datei wird nach Update auf 1.3.0 korrekt gesetzt. Aber es wird trotzdem ein Datum an den Dateinamen angehängt

Grundsätzlich würde ich dir mal die aktuelle Version 1.3 empfehlen, auch wenn es in diesem Bereich keine umfangreichen Änderungen gab - aber man weiß ja nie.

Wenn das nicht hilft, bräuchte ich mal ein entsprechendes Log (Uploadlink in meiner Signatur).

Mit dem Update auf 1.3. funktioniert es. Danke!

 

[geimist]

Aber es wird trotzdem ein Datum an den Dateinamen angehängt

Wie der Zieldateiname zusammengesetzt werden soll, kannst du in der synOCR GUI einstellen.

 

[Chr!s]

Das Thema gab es kürzlich. Es scheint so, dass die per Shell geänderten Dateien in Drive nicht getriggert werden. Erst wenn man sie öffnet, werden sie unter kürzlich auffindbar. Auch Tags für Drive lassen sich nicht einfach für Dokumente setzen, weil diese nicht in der Datei gesichert werden, sondern Benutzerabhängig ist.

Mir ist halt keine Dokumentation von Drive hierfür bekannt. Wenn es jemand weiß, bin ich sehr an Infos interessiert.


Vielleicht mit einer universellen RegEx-Regel. Dann muss man aber immer sicherstellen, dass zwei Regeln erfüllt werden (die Datei darf ja nicht nur in deinen zweiten Ordner landen, sofern es aufgrund der Universalregel geschieht).

Danke für deinen Tipp mit der Regex...
ich bin nun einen riesen Schritt weiter, im Ergebnis ist es nun so dass meiner Regel der Scan 1x im Verzeichnis für neue Scans landet und einmal im Scaninput von EcoDMS sowie in der Ordnerstruktur sofern weitere entsprechende Regeln greifen.
Wenn ich nun etwas einscanne bei dem noch keine Regel für die Einordnung in der Ordnerstruktur greift, so greifen hoffentlich zumindest die beiden Regeln für die Einordnung in die beiden Scaninputordner.
Wenn ich nun in den Scaninputordner gehe erkenne ich sofort am fehlen der Tags im Dateinamen dass ich die Datei noch einsortieren und ggf. die Regeln erweitern muss. Bis jetzt ist das aber nur die erste Einschätzung anhand positiver Versuche.

Hier mal der Auszug aus der Regeldatei, evtl. hat jemand Anmerkungen, ich bin mir nämlich noch nicht sicher ob mit dieser Regel immer eine Kopie in den beiden Scaninputordnern landet.

input_1:
    tagname: 1
    targetfolder: /volume1/Scaneingang/
    condition: all
    subrules:
    - searchstring: .*
      searchtyp: contains
      isRegEx: true
      source: content
      casesensitive: false

input_2:
    tagname: 1
    targetfolder: /volume1/Scaninput/test/
    condition: all
    subrules:
    - searchstring: .*
      searchtyp: contains
      isRegEx: true
      source: content
      casesensitive: false

PS: ein riesen Lob und Dankeschön für synOCR!!! Je mehr ich mich nun damit auseinander setze, um so mehr ärgere ich mich dass ich mich nicht eher damit beschäftigt habe. Gut möglich dass ecoDMS in absehbarer Zeit abgelöst wird...

 

[Chr!s]

So ich habe nun weiter getestet und probiert und bin ziemlich begeistert
Durch das Testen und Importieren von bereits vorhandenen wie auch mit neuen PDFs bin ich allerdings auch auf "Schwierigkeiten" gestoßen:

bis die Regeldatei für den wiederkehrenden Papierverkehr weitestgehend vervollständigt ist bedarf es doch auch einiger Nachbesserungen an den Regeln daher hätte ich folgende Idee:

Wäre es realisierbar eine Option einzubauen bei der ein zweiter Input-Ordner verwendet wird und alle Scans aus diesem Ordner nach dem OCR Vorgang zunächst in einem zentralen Ordner zur manuellen Prüfung landen unabhängig davon welcher Zielpfad in der Regeldatei hinterlegt ist?

Wenn nach manueller Prüfung alles i.O. ist => Datei in den "richtigen" Input-Ordner verschieben, im nun 2. Durchlauf werden die Dateien im Zielpfad entsprechend der Regel abgelegt

Wenn nach manueller Prüfung etwas n.i.O. ist => Regeldatei anpassen und PDF nochmals in den zweiten Input Ordner verschieben und ggf. wiederholen bis das Ergebnis korrekt ist, wenn dann alles passt wird die Datei dann auch wieder in den "richtigen" Input-Ordner verschoben

Wenn ich alles richtig verstanden habe kann das im Prinzip schon jetzt mit 2 Profilen realisiert werden, man müsste dann aber auch immer mit 2 Regeldateien arbeiten die bis auf den Zielpfad immer identisch gehalten werden müssen.

 

[gunfran]

Ich denke was du willst kannst du mit zwei Profilen erreichen.

Pro Profil kannst du ja Ein- und Ausgabeordner definieren.

Du würdest dann zwei Regelfiles bauen, die die gleichen Tags bauen aber nicht in unterordner einsortieren. Dann würden die in deinen output-ordner des profils gehen.

Wenn du das kontrolliert hast schiebst du die Dateien in deinen Input-Ordner für die finale Einsortierung.

Die Profile laufen ja hintereinander weg und daher kommt es dann bei dir "nur" drauf an in welchem input-ordner du die pdfs legst.