synOCR synOCR - GUI für OCRmyPDF

[geimist]

Vielen Dank für deinen Input.
Ich würde gerne mal auf Rückmeldung von @Gthorsten warten, weil der gesamte Pythoncode aus seiner Feder stammt. Er wird es dann sicherlich so umsetzen, dass er das Problem langfristig abdeckt. Im Sommer ist er immer stark beschäftigt, aber die Tage werden ja schon kürzer

 

[DeeKay1]

Jep, macht natürlich Sinn.

@Gthorsten: Mein fix basiert schon auf dem aktuellsten Repo-Stand. Mir ist gerade aufgefallen, dass du letztes Jahr im Oktober schon den regex für regex_long_date und regex_short_date geändert hast. Diese Änderung ging zwar nie in ein Release, behebt aber an sich schon 2 meiner 3 weiter oben gemeldeten Datum-Fehlerkennungen. Mein PR (bzw. die Idee dahinter) fixt dann noch die fehlende Nummer 3.

 

[DeeKay1]

@Gthorsten: Sorry, ich schon wieder. Keine Ahnung ob das schon auf dem Radar ist, aber mit dem dataparser languages-Argument, könnte man dann auch die Parametrisierung der Datum-Werte angehen:

date_obj = dateparser.parse(regex_result.group(0), settings=settings_str, languages=['de'])

Bisher macht das Skript aus dem Regex-Ergebnis "3 Eur 93" bspw. noch ein valides Datum. Da kommt dann der aktuelle Zeitpunkt Minus ein paar Stunden raus.
Mit dem de-Languages-Argument weiß dataparser aber, dass "Eur" definitiv keine Monat ist und gibt aus der parse-Methode ein "none" raus. Ggf. könnte man die languages-Angabe ja über die bestehende synOCR-UI ja relativ einfach durch den User einstellbar machen.

EDIT: Sofern man das macht, könnte man auch wieder die Erkennung von DD.MM.YY mit aufnehmen, da über die Language-Angabe ja die "korrekte" schreibweise erkannt wird.

 

[Scythefiend]

Guten Morgen,

erstmals ein Riesen Lob.
Die Software ist echt super und ich habe dadurch meine persönliche Ablage endlich mal auf Vordermann gebracht.

Jetzt war ich ein bisschen am rumbasteln und bin auf ein Problem gestoßen, das sich einfach nicht lösen lassen will.

Ich versuche mittels Regex nach einem Ausdruck zu suchen - was auch klappt (Angebot ist in diesem Fall der Ausdruck) und danach nach einer Angebotsnummer. Das Problem ist bloß das er mir die Angebotsnummer nicht wiedergibt als Dateinamen.

Ich habe auch im Debug Modus die OCR und Log Datei mal angeschaut und glaube das Problem ist das
dass OCR anstatt eines ":" mal einen Stern oder mal ein Plus erkennt sowie x-mal ein Leerzeichen.
Ist es möglich das ich zwischen dem Wort und der Nummer sämtliche Whitespaces und sonstige Zeichen ignorieren kann bis die Nummer kommt.

Liebe Grüße und danke schon mal für die Mühe

 

[Struppix]

Hallo,
natürlich geht das, in verschiedenen Optionen.
Da aber die Frage nicht, naja nicht ganz eindeutig ist, versuche ich mal zu raten.

Zuallererst schalte doch mal im GUI den Schalter bei "Leerzeichen bereinigte Suche " ein. Damit dürfte, wenn sich nur mehrere Leerzeichen zwischen dem ersten Suchwort und der Nummer befinden, das Problem lösen lassen.
Wenn dort noch andere Wörter usw. stehen, könntest Du 2 Regeln nutzen,.
Oder viel eleganter geht es auch. Dazu gleich mehr, muss ich an meinen PC wechseln...

 

[Struppix]

So, besser als am Handy.

Versuche mal so:

rule_0001:
    tagname: Angebotsnummer_§tagname_RegEx
    tagname_RegEx: (?i)(?|(Angebot(\D*[N|n]um\S+|[\.\-\:\;\s]*Nr))\S*)\s+?\K(\S*\s*?(\d+\S*))+\b
    condition: all
    subrules:
    - searchstring: (?|(Angebot(\D*[N|n]um\S+|[\.\-\:\;\s]*Nr))\S*)\s+?\K(\S*\s*?(\d+\S*))+\b
      searchtyp: contains
      isRegEx: true

Wenn das nicht klappt, dann poste doch mal Deine Regel.

Karsten

 

[Scythefiend]

Huhu,

man bist du schnell ich hab gar nicht mit ner Antwort heute gerechnet
Hab einfach mal meinen Code hingeschrieben, aber werde zuerst mal deinen probieren

Update: dein Code hat leider nicht geklappt aber ich hab meinen etwas überarbeitet und nun klappt es.

das einzige Peoblem ist nur noch das er mir die angebotsnummer 2x in der Benennung einfügt, weil es 2x im Text vorkommt.

hätte da jemand noch einen kleinen Tipp?

liebe Geüße Marcel

rule_001:
    tagname: §tagname_RegEx
    tagname_RegEx: \b(ANGEBOT)\b.\b(Nr)\W*\s(\d{6})
    condition: all
    multilineregex: true
    subrules:
    - searchstring: \b(ANGEBOT)\b.\b(Nr)\W*\s(\d{6})
      searchtyp: contains
      isRegEx: true
      multilineregex: true
      source: content
      casesensitive: true
    - searchstring: (\d{6})
      searchtyp: contains
      isRegEx: true
      multilineregex: true
      source: content
      casesensitive: false

 

[Struppix]

Hey Marcel,
lade mir bitte mal ein Beispiel Dokument hoch (in meiner Signatur), dann schaue ich nachher mal.

Karsten

 

[Scythefiend]

Danke dir Karsten!

 

[Gthorsten]

Hallo @DeeKay1 ,
Irhendwie ist mein login nicht ok gewesen.
Habe länger keine Benachrichtigung mehr bekommen, und da ich auf der Arbeit Land unter war, habe ich auch im forum nicht gelesen. .
Sind die Probleme die du gemeldet hattest schon gefixed?
Sonst schaue ich mir das ganze mal sn
Gruß
Thorsten

 

[schlomo]

Servus,

ich bin neu im Synology-Kosmos und gerade dabei das "Papierloses-Büro" anzugehen. Ich möchte mich vorab bei allen Mitwirkenden bedanken. Es macht mich echt sprachlos, wieviele ihre Kraft in solch tolle Lösungen stecken wie hier das Beispiel von synOCR. Vielen Dank an die Community.

Meine bisherigen Schritte mit synOCR verliefen ganz vielversprechend, bis ich zur automatischen Ordnerüberwachung mit inotify gekommen bin. Ich habe es über "Easy Install" dem Paketzentrum hinzugefügt (vgl. https://synocommunity.com/), da mir im Downloadbereich nicht klar war, welches Paket eingebunden werden muss

(DSM 7.x: 7.1 alpine 7.1 alpine4k 7.1 armada370 7.1 armada375 7.1 ...u.v.m.)

Sobald ich das Paket installiere und den Inbox-Ordner von inotify überwachen lasse, bekomme ich folgende Fehlermeldung im Log in den Errorfiles:

  -----------------------------------------------------------------------------------
  | processing PDF @ OCRmyPDF:                                                      |
  -----------------------------------------------------------------------------------

                ➜ OCRmyPDF-LOG:
                  reading file from standard input
                  Input file is not a PDF, checking if it is an image...
                  cannot identify image file '-'
                  UnsupportedImageFormatError
                ← OCRmyPDF-LOG-END

                  ┖➜ failed! (target file is empty or not available)
                ➜ File name already exists! Add counter (1)

Entferne ich das Paket und nutze die Aufgabenplanung zum abholen der PDFs, funktioniert wieder alles reibungslos.
Übersehe ich eine notwendige Konfiguration oder andere Einstellung, die hier Abhilfe schaffen kann? Ich vermute der Fehler liegt eher bei mir als beim Paket. Vielen Dank für eure Unterstützung.

Beste Grüße

 

[geimist]

Herzlich willkommen hier im Forum @schlomo

Das ist wirklich eigenartig. Diesen Fehler hab ich bisher noch nicht gesehen. Die Fehlermeldung besagt, dass das Quelldokument nicht als PDF erkannt wurde. Aber inotify ändert keine Dokumente. Daher habe ich gerade noch nicht wirklich eine Idee.
inotify mach ja eigentlich nichts anderes wie der Aufgabenplaner: es startet die synOCR Routine, welche sich dann die definierten PDFs im Quellordner einverleibt.

2 Fragen:

1. wenn die Ordnerüberwachung aktiv ist:
   Kannst du den Fehler auch reproduzieren, wenn du ein Dokument in den Quellordner verschiebst, welches bereits einmal korrekt verarbeitet wurde?
2. welchen Scanner nutzt du?

 

[schlomo]

Hallo gebimst,

Zu 1. Wenn ich die Ordnerüberwachung wieder aktiviere und eine bereits verarbeitete Datei ablege, läuft es bisher sauber durch. Interessant
zu 2. ScanSnap IX1600

Meine Vermutung war ebenfalls, dass es mit dem Output vom Scanner zusammenhängt.

Das Skurrile ist, sobald ich inotify deinstalliert, das NAS neustarte und wieder mit dem Aufgabenplaner arbeite, funktioniert es reibungslos. Das ganze ist beliebig oft in alle Richtungen reproduzierbar.

 

[geimist]

Danke für die Tests.

Zu 1.:
Ich hatte gehofft und eigentlich auch erwartet, dass es grundsätzlich funktioniert. Schön, dass dem so ist.

Zu 2.:
Ich vermute, dass es hier das gleiche Problem gibt, wie bei Canonscannern. Dort ist es so, dass die gescannten Dokumente fortlaufend auf das NAS geschrieben werden, auch wenn der Scan noch nicht abgeschlossen ist (z.B. im Fall mehrerer Seiten). Inotify erkennt, wenn bei einer Datei der Schreibstatus abgeschlossen ist und triggert dann synOCR. Canonscanner öffnen die Datei aber gleich wieder, um sie weiterzuschreiben. Das kommt dann zum Konflikt.

Ich kann dieses Problem nicht beheben, weil sich dieses Verhalten nicht von gewünschtem Verhalten unterscheiden lässt. Aber es gibt einen Workarround, indem man einen 2. Quellordner in Verbindung mit einem kleinen Skript im Aufgabenplaner nutzt. Das habe ich in den FAQs beschrieben: "PDF-Dateien werden von synOCR verarbeitet, obwohl der Scanner noch nicht alle Seiten eingescannt hat."

Bitte probiere das mal aus.
Viel Erfolg.

 

[schlomo]

Spannend! Wenn ich den Workaround so angehe wie beschrieben, bekomme ich folgenden Log Eintrag:

  -----------------------------------------------------------------------------------
  | processing PDF @ OCRmyPDF:                                                      |
  -----------------------------------------------------------------------------------

                ➜ OCRmyPDF-LOG:
                  docker: Error response from daemon: Conflict. The container name "/synOCR" is already in use by container "26224b3b01bc12527b85cc528fe8d4f16a09b62823b65d76deab0dbbb832da0c". You have to remove (or rename) that container to be able to reuse that name.
                  See 'docker run --help'.
                  cat: write error: Broken pipe
                ← OCRmyPDF-LOG-END

                  ┖➜ failed! (target file is empty or not available)
                                  ERROR-Directory [/volume1/SynOCR/Consume/ERRORFILES] will be created!

Das Dokument landet anschließend trotzdem im Scan-Ordner mit OCR. Jetzt ist sogar die Verwirrung verwirrt

 

[geimist]

Das passiert, wenn der synOCR Container noch läuft, bzw. nicht richtig beendet wurde. Siehst du in Docker noch einen Container namens "synOCR"?
Wenn ja, kannst du ihn beenden und ggf. löschen (sollte beim Beenden automatisch verschwinden).

 

[schlomo]

Wurde Docker nicht durch den Container Manager abgelöst? Im CM sehe ich nur die drei mitgelieferten Images, aber keine Container.

Beste Grüße

 

[geimist]

Das ist korrekt - sollte nur allgemein formuliert sein.

 

[schlomo]

Das bedeutet zusammenfassend entweder Scanner tauschen oder entweder den Aufgabenplaner in regelmäßigen Abständen synOCR triggern oder den beschriebenen Umweg über ein temporäres Verzeichnis gehen und das ebenfalls über ein Script regelmäßig prüfen lassen um dann inotify zur Überwachung zu nutzen.

Hier stellt sich mir die Frage, welchen Vorteil es gibt, in diesem Konstrukt inotify zu nutzen, wenn es trotzdem auf ein zyklischen Script Aufruf hinausläuft. Oder übersehe ich hier wichtige Details? Schonmal vielen Dank für den grandiosen Support, ohne diesen würde ich immer noch im Trüben fische.... äh.... scannen.

Beste Grüße

 

[geimist]

In der Tat: In Verbindung mit einem Scanner, der dieses eigenartige Verhalten des permanenten Schreibens an den Tag legt, und in man in diesem Zusammenhang dann das Hilfsskript nutzt, hat Inotify keinen wirklichen Mehrwert.

Allerdings könnte man mit etwas Mühe auch das Hilfsskript mit Inotify aufbauen und bei Änderungen einen Timer zurücksetzen (das Hilfsskript verschiebt nur Dateien mit einem gewissen Alter). Das würde wahrscheinlich helfen, wenn man das Standby der HDDs nicht durch den Aufgabenplaner stören möchte.

Sorry, wenn dein Problem jetzt nicht perfekt gelöst ist. Ich würde aber in Verbindung mit solch einem Scannerverhalten immer mit dem Hilfsskript und temporärem Quellverzeichnis arbeiten, weil es sonst immer wieder zu Konflikten kommen kann, wenn der Aufgabenplaner zeitgleich die Dateien verarbeiten möchte, die gerade noch gescannt werden.