synOCR synOCR - GUI für OCRmyPDF

[Monacum]

Ich habe keine Ahnung, welche in Paperless Verwendung findet.

Mindestens 14.0.0.

Ich habe bei der Bilddatei bei beidem das gleiche Ergebnis.

 

[geimist]

Dann einfach mal das gewünschte Image über die Docker-GUI laden und in der synOCR-GUI für das gewünschte Profil auswählen.

 

[DeeKay1]

@DeeKay1:
Das Datumsskript wurde auf Version 1.0.4 aktualisiert (thx @Gthorsten). Bitte mal deine Problemdatei testen.

Gerade mal installiert und getestet.
Das erste was mir auffällt ist folgender Fehler im Log:

  -----------------------------------------------------------------------------------
  | check the python3 installation and the necessary modules:                       |
  -----------------------------------------------------------------------------------

[runtime up to now:    00:01:44]
chown: invalid user: 'synOCR:administrators'
                  Check Python:
                  python3 already installed (/usr/syno/synoman/webman/3rdparty/synOCR/python3_env/bin/python3)
                  Check pip:
                  pip already installed (pip 20.2.1 from /usr/syno/synoman/webman/3rdparty/synOCR/python3_env/lib/python3.8/site-packages/pip (python 3.8)) / upgrade available ...
                  Collecting pip
                    Using cached pip-23.0.1-py3-none-any.whl (2.1 MB)
                  Installing collected packages: pip
                    Attempting uninstall: pip
                      Found existing installation: pip 20.2.1
                      Uninstalling pip-20.2.1:
                        Successfully uninstalled pip-20.2.1
                  Successfully installed pip-23.0.1
                  read installed python modules:
                  Package    Version
                  ---------- -------
                  pip        23.0.1
                  setuptools 49.2.1
                  ➜ check python module "DateTime": ➜ DateTime was not found and will be installed ➜ ok
                  ➜ check python module "dateparser": ➜ dateparser was not found and will be installed ➜ ok
                  ➜ check python module "pypdf==3.5.1": ➜ pypdf==3.5.1 was not found and will be installed ➜ ok
                  ➜ check python module "Pillow": ➜ Pillow was not found and will be installed ➜ ok
                  ➜ check python module "yq": ➜ yq was not found and will be installed ➜ ok
                  ➜ check python module "PyYAML": ➜ PyYAML was not found and will be installed ➜ ok
ERROR at line 1007: chown -R synOCR:administrators /usr/syno/synoman/webman/3rdparty/synOCR/python3_env

Hab die vorigen Logfiles geprüft. Der kam bisher nicht.

EDIT: Vergiss das. Beim zweiten Lauf kommt der Error plötzlich nicht mehr.

 

[geimist]

Diese Zeile ist vor allem für den Fall gedacht, wenn synOCR über root aufgerufen worden ist und in Zukunft dann der User synOCR nicht ausgesperrt ist. Wird es vom User synOCR aufgerufen, passen die Rechte für die virtuelle Pythonumgebung eh.

 

[DeeKay1]

Ok. Aber ich hab zwischen den Aufrufen ja nichts geändert. Mich wundert das es nur einmal aufgetreten ist.

 

[geimist]

Mich wundert das auch gerade, weil es auch nur im Fall von root aufgerufen wird.
Ich konnte den Fehler auch nicht reproduzieren. Ich würde das jetzt aber auch nicht überbewerten, solange alles funktioniert. An der Stelle habe ich auch nichts wirklich etwas geändert.

 

[DeeKay1]

@DeeKay1:
Das Datumsskript wurde auf Version 1.0.4 aktualisiert (thx @Gthorsten). Bitte mal deine Problemdatei testen.

Danke, die "Mai"-Problemdatei funktioniert jetzt.

Ich würde das jetzt aber auch nicht überbewerten, solange alles funktioniert.

Tu ich auch nicht. Wollte es nur erwähnt haben.

 

[DeeKay1]

Mir fällt gerade auf das synOCR die Originaldateien aus dem Quellordner löscht, nachdem die TargetFiles im Tmp-Order angelegt und das backup in den Archivordner kopiert hat.
Wäre es nicht "sicherer" die Dateien erst zu löschen, nachdem die Tagerkennung sauber durchgelaufen und die neu generierte PDF im Zielordner geschoben wurde?
Ich kann nicht beurteilen wie gut das Errorhandling von synOCR ist, aber wenn während der Tag-Erkennung etwas schief geht, bspw. bei Datei 1 von 5, und der ganze Prozess dann abbricht, wurden bereits alle 5 Dateien im Quellordner gelöscht.
Und ja, das steht natürlich alles im Log und die Backups sind natürlich auch noch da. Ich will nur mal anstoßen ggf. die Reihenfolge zu ändern.

EDIT: Moment, da scheint etwas nicht zu stimmen. Ich hatte gerade einen Lauf mit 3 Dateien. Die ersten beiden wurden in den temp-Ordner geschoben und ein Backup gemacht. Allerdings lief keine Tag-Erkennung darüber, sodass diese jetzt quasi im Nirvana sind. Nur bei der letzten Datei lief das volle Programm drüber.

EDIT 2: Grad nochmal mit einem Run mit 2 mal derselben getestet. Scheinbar läuft die Tagerkennung in der aktuellen Beta tatsächlich nur für die letzte Datei los.

EDIT 3: Das Problem ist Zeile 1790 in main_1st_step:

Das Haupt-Temp-Directory wird nicht zentral einmal erstellt, sondern pro Datei jedes mal neu. 1790 muss also aus der Funktion main_1st_step, oder zumindest aus der while, raus.

Meine ursprüngliche Frage zur Reihenfolge bzgl. des Löschens der Originaldatei bleibt aber noch bestehen

 

[geimist]

Das ist ein Grund, weshalb ich die temporären Dateien (sicherheitshalber) in der Version 1.3.0 in den Zielordner verlegt hatte. Die Herausforderung liegt in der zweistufigen Abarbeitung.

Noch mal kurz zur Erläuterung meines Gedankens dahinter:
Seit Version 1.3.0 gibt es die Möglichkeit, Dokumente automatisch aufteilen zu lassen und Bilder konvertieren zu lassen. In der Praxis bedeutet das, dass der Ablauf auf zwei Hauptschleifen aufgeteilt wurde. In der ersten werden Bilder zu PDFs konvertiert und PDFs gesplittet sowie OCR durchgeführt und im zweiten dann die endgültigen Quelldokumente verarbeitet (taggen, umbenennen, Metadaten setzen und einsortieren). Eigentlich würde ich die Backup- und Löschroutine erst dann laufen lassen, wenn ein Dokument endgültig verarbeitet ist. Dann müsste ich die Dateien aber irgendwie (auf sichere Weise) protokollieren / referenzieren. Ich kann sonst in der zweiten Schleife die ursprüngliche Quelldatei nicht mehr den erfolgreich verarbeiteten Dokumenten zuordnen.
Aber prinzipiell dürften keine Dokumente verloren gehen, sofern Backups aktiviert sind.

Aber ich kann auch die Einwände von @st3623 verstehen.

Zu deinem Problem @DeeKay1:
Meine Tests verliefen am Schluss erfolgreich. Bitte lass mir mal ein Log zu kommen, damit ich dein Voreinstellungen sehen kann und das Problem nachvollziehen kann.

 

[DeeKay1]

@geimist Siehe meinen Post über deinem. Ich hab Quelle/Fix als Edit eingefügt.

 

[geimist]

Danke, dass du mir gleich den Fehler aufgezeigt hast. Das konnte natürlich nicht passen. Weil ich aber mit einer fast leeren Regeldatei getestet hatte, ist mir das nicht aufgefallen.
Ich hab es mit Version 1.3.99.7 gefixt.

Bei den Tests jetzt auf die Schnelle sind z.T. noch Trennseiten enthalten geblieben. Das muss ich mir später nochmal ansehen.

---

Moin Männers und Danke für die neue Beta. Soeben installiert und, wie von Euch mitgeteilt, öffnet sich die Oberfläche in einem neuen Fenster.
Alles ok. Habe auch gleich eine Datei (Anlage) durchgejagt und leider habe ich den Eindruck, dass die Erkennung ein wenig schlechter ist. Parallel ließ ich die Datei auf anderer DS durch paperless-ngx durchjagen - das Ergebnis war hier besser. Gibt es eine Erklärung oder bilde ich es mir ein?
Grüße!!

Ergebnisse der Erkennung:
1. SynOCR

Luge
wird nicht zur Wahrheit, falsches wird nicht richtig
und das Bose wird nicht gut, nur weil es von einer Mehrheit
akzeptiert wird.
Eine

2. paperless-ngx

Eine Luge
wird nicht zur Wahrheit, falsches wird nicht richtig
und das Böse wird nicht gut, nur weil es von einer Mehrheit akzeptiert wird.

Bei mir sieht das Ergebnis deines Bildes so aus:

Eine Lüge
wird nicht zur Wahrheit,
falsches wird nicht richtig
und das Böse wird nicht gut,
nur weil es von einer Mehrheit
akzeptiert wird.

OCR-Parameter: -dcs -l deu
Das aktuelle :latest Image von OCRmyPDF

 

[geimist]

Bei den Tests jetzt auf die Schnelle sind z.T. noch Trennseiten enthalten geblieben. Das muss ich mir später nochmal ansehen.

fixed …

 

[DeeKay1]

Ich konnte den Fehler auch nicht reproduzieren. Ich würde das jetzt aber auch nicht überbewerten, solange alles funktioniert. An der Stelle habe ich auch nichts wirklich etwas geändert.

Hag grad deine neuste Beta installiert - wieder das gleiche. Halb so wild, funktioniert ja alles. Aber es scheint irgendwie am ersten Aufruf nach Installation/Update zu liegen.

 

[geimist]

Das kommt aus der Funktion zur Prüfung und Einrichtung der virtuellen Pythonumgebung. Wenn alles gut geht, läuft die ja nur einmal nach einem Update.
https://git.geimist.eu/geimist/synO...44f46b957794f2315d81f7/APP/ui/synOCR.sh#L1007

 

[DeeKay1]

@geimist
Hast du eigentlich einen docker hub pro account? Oder wie setzt du den Auto-Build um, sofern das base image von jbarlow aktualisiert wird?
Ich habe mir jetzt 3 docker-files gebaut, die jeweils alle language-Dateien für tesseract, tesseract_best, tesseract_fast im Image bereitstellen.
Angefangen hatte ich mit best, da ich mit bestimmten Dokumenten Probleme bei der Erkennung von Zahlen hatte. Da wurde bei meiner Hausnummer ständig statt einer 1 ein l (kleines L) erkannt.
Die Dockerfiles bestehen nur aus ein paar Zeilen. Da du den automatisierten build scheinbar schon am Laufen hast, möchtest du die Images vielleicht unter deinem geimist-Account bereitstellen?

 

[DeeKay1]

Btw hab ich im Log seit der aktuellsten Version immer diese Fehler:

Dabei verwende ich multilineregex bisher noch gar nicht im yaml.

 

[geimist]

Kannst du vernachlässigen. Das stammt von der YAML-Prüfung, sofern der Parameter nicht gesetzt ist.

Für das andere gibt es eine PN

 

[DeeKay1]

@Gthorsten
Eine Idee wieso er bei der Zeile auf dieses Datum kommt? Und ja, es wird wohl Zeit in den Setting ein Max-Year anzugeben

 

[Gthorsten]

Gucke ich nachher. Sitze fast auf dem Zahnarzt Stuhl

 

[Gthorsten]

Kannst mir die eine Zeile mal. Als pn schicken?