synOCR synOCR - GUI für OCRmyPDF

[lil-ac]

Das innerhalb der Rules die QR Codes hinterlegt sind.

 

[Gthorsten]

Ah ok, verstanden

 

[lil-ac]

Weil derzeit mache ich das so: Scan Deckblatt: Name: Benutzer Dokumentenart: Schreiben von Datum:
Und um Papier zu sparen, dachte ich es müsste doch auch bestimmt klappen, wenn man solche Infos in den QR Codes hinterlegt. Diese draufklebt und SynoOCR bearbeitet diese.

 

[geimist]

... Dort würde ich dementsprechend einen Code erstellen. Wie schon gesagt: Post - AOK - Max Mustermann. Dieses dann auf das Schreiben kleben, einscannen und verarbeiten lassen. …

Dann kleb es doch im Klartext drauf und lege in derYAML Regeldatei eine entsprechende Regel genau dafür an.
Barcodes oder QR Codes können derzeit weder identifiziert noch decodiert werden.

 

[gunfran]

Gute Idee, dann kopiere bitte nochmal das logfile mit Level 2 hier hin. Vielleicht kann man dann schon mehr sehen

Ich habe vermutlich den Grund entdeckt weshalb der Lauf bei mir unendlich weiter lief.

2022-09-12 09:45:58,706 - Parameter dateBlackLIst = 2001-06-21;1979-10-25;1978-05-01;2018-06-29
2022-09-12 09:45:58,706 - start checking blacklist
2022-09-12 09:46:11,893 - Blacklistdate 2001.06.21
2022-09-12 09:46:11,894 - Blacklistdate 1979.10.25
2022-09-12 09:46:11,894 - Blacklistdate 1978.01.05
2022-09-12 09:46:11,894 - Blacklistdate 2018.06.29
2022-09-12 09:46:11,894 - end checking blacklist
2022-09-12 09:46:11,894 - start search alphanumeric dates
2022-09-12 09:46:18,571 - found 0 alphanumeric dates
2022-09-12 09:46:18,572 - no alphanumeric dates found
2022-09-12 09:46:18,572 - end search alphanumeric dates
2022-09-12 09:46:18,572 - start search numeric dates
2022-09-12 09:46:18,653 - Found numeric date 01.05.1978
2022-09-12 09:46:18,654 - add 1978-05-01 00:00:00 because not in blacklist
2022-09-12 09:46:18,661 - Found numeric date 16.08.2022
2022-09-12 09:46:18,662 - add 2022-08-16 00:00:00 because not in blacklist
2022-09-12 09:46:18,669 - Found numeric date 08.08.2022
2022-09-12 09:46:18,669 - add 2022-08-08 00:00:00 because not in blacklist
2022-09-12 09:46:18,677 - Found numeric date 08.08.2022
2022-09-12 09:46:18,677 - add 2022-08-08 00:00:00 because not in blacklist
2022-09-12 09:46:18,685 - Found numeric date 08.08.2022
2022-09-12 09:46:18,685 - add 2022-08-08 00:00:00 because not in blacklist
2022-09-12 09:46:18,692 - Found numeric date 08.08.2022
2022-09-12 09:46:18,693 - add 2022-08-08 00:00:00 because not in blacklist
2022-09-12 09:46:18,700 - Found numeric date 08.08.2022
2022-09-12 09:46:18,700 - add 2022-08-08 00:00:00 because not in blacklist
2022-09-12 09:46:18,708 - Found numeric date 08.08.2022
2022-09-12 09:46:18,708 - add 2022-08-08 00:00:00 because not in blacklist
2022-09-12 09:46:18,716 - Found numeric date 08.08.2022
2022-09-12 09:46:18,716 - add 2022-08-08 00:00:00 because not in blacklist
2022-09-12 09:46:18,723 - Found numeric date 08.08.2022
2022-09-12 09:46:18,724 - add 2022-08-08 00:00:00 because not in blacklist
2022-09-12 09:46:18,731 - Found numeric date 08.08.2022
2022-09-12 09:46:18,731 - add 2022-08-08 00:00:00 because not in blacklist
2022-09-12 09:46:18,739 - Found numeric date 08.08.2022
2022-09-12 09:46:18,739 - add 2022-08-08 00:00:00 because not in blacklist
2022-09-12 09:46:18,746 - Found numeric date 08.08.2022
2022-09-12 09:46:18,747 - add 2022-08-08 00:00:00 because not in blacklist
2022-09-12 09:46:18,754 - Found numeric date 08.08.2022
2022-09-12 09:46:18,754 - add 2022-08-08 00:00:00 because not in blacklist
2022-09-12 09:46:18,762 - Found numeric date 08.08.2022
2022-09-12 09:46:18,762 - add 2022-08-08 00:00:00 because not in blacklist
2022-09-12 09:46:18,770 - Found numeric date 08.08.2022
2022-09-12 09:46:18,770 - add 2022-08-08 00:00:00 because not in blacklist
2022-09-12 09:46:18,777 - Found numeric date 08.08.2022
2022-09-12 09:46:18,778 - add 2022-08-08 00:00:00 because not in blacklist
2022-09-12 09:46:18,778 - found 17 numeric dates
2022-09-12 09:46:18,778 - end search numeric dates
2022-09-12 09:46:18,778 - found date 1978-05-01
2022-09-12 09:46:18,779 - Date scanning ended
                find_dates.py result:
                1978-05-01
                  Dates found: 1
                  check date ([yy]yy mm dd): 1978-05-01
                  Date 1978-05-01 is on ignore list. Skipping this date.

Man sieht das die Liste der Blacklistdaten am Anfang wie folgt gefunden wird: 2001-06-21;1979-10-25;1978-05-01;2018-06-29
Dann wird aber kurz danach ein Datum merwürdigerweise verdreht einer Collection zugefüht nehme ich an:
Blacklistdate 1978.01.05
Hierdurch entsteht eine Eintrag wie: add 1978-05-01 00:00:00 because not in blacklist

Aber in deiner Python-Prüfung in find_dates wird der 01.05.1978 wieder als Datum in der Blacklist erkannt.

1978-05-01
Dates found: 1
check date ([yy]yy mm dd): 1978-05-01
Date 1978-05-01 is on ignore list. Skipping this date.


Und mit dieser Datumsprüfung dreht sich das Script scheinbar im Kreis.

 

[Gthorsten]

Danke, ich gucke mir das nachher mal an

 

[DirkKn]

Die Erkennung von Umlauten ist bei großer Schrift sehr schlecht (z.B. beim Briefkopf)
weiß jemand, wie das verbessert werden kann?

 

[geimist]

Mir sind prinzipiell keine Erkennungsprobleme bekannt. Es handelt sich hier ja auch um ein OCRmyPDF-Problem. Vielleicht kannst du mal direkt beim Projekt anfragen.
https://github.com/ocrmypdf/OCRmyPDF/issues

 

[usefulvid]

Mein CanonMB5150 legt beim Scannen über den Einzug direkt eine fertige Datei an auch wenn noch weitere Blätter kommen.
Das Führt bei synocr dazu, dass die Datei verarbeitet und verschoben wir während der Drucker noch darauf zugreifen will.
Das Einzige was mir als Lösung einfällt ist eine verzögerte Verarbeitung.
Wie könnte ich diese einstellen? Oder gibt es noch eine bessere Lösung für mein Problem?
Kann ich mit YAML einstellen, dass dasdie Datei mindestens 30 sekunden alt sein muss?

 

[geimist]

Nutzt du das Monitoring mit den Inotify-Tools?

 

[usefulvid]

Nutzt du das Monitoring mit den Inotify-Tools?

genau

 

[geimist]

Es gibt ja verschiedene Events, die überwachbar sind. User @Syngen hatte dasselbe Problem wie du jetzt, weshalb ich das Event von create auf close_write geändert hatte. Das hat sein Problem gelöst. Daher staune ich jetzt, dass es bei dir wieder Probleme gibt.

Welche synOCR-Version nutzt du?

 

[usefulvid]

Welche synOCR-Version nutzt du?

1.2.0.11
ich habe bei dem Scanner das Gefühl, dass die Datei temporär "fertig" ist bis dann die nächste seite kommt. Könnte ich das irgendwie prüfen welchen status eine datei hat?

 

[geimist]

Also sollte das funktionieren. Da scheint es mir, dass dein Scanner die Datei zunächst schließt und anschließend für die nächste Seite wieder öffnet. Ich wüsste nicht, wie ich das noch restriktiver als mit close_write einstellen könnte. Man könnte natürlich wieder auf den Aufgabenplaner ausweichen. Aber damit kann man natürlich in dieselbe Falle laufen.

Könntest du mal den Fehler reproduzieren und anschließend das Monitoring stoppen oder neu starten und mir anschließend das Monitoring-Log schicken (das liegt auch im Logordner)? Wichtig ist, dass das Monitoring unterbrochen wird, damit die Logdatei endgültig geschrieben wird.

 

[usefulvid]

Hab es mit dem Link aus deiner Signatur hochgeladen. Wichtig ist nur der zweite Upload, den ersten kannst du ignorieren.

 

[geimist]

Vielen Dank für deinen Upload. Die auslösenden Events sind CLOSE_WRITE,CLOSE. Das ist schade, dass das dein Scanner so macht. Hättest du vielleicht die Möglichkeit, das Protokoll zu wechseln (z.B. von SMB auf FTP oder umgekehrt)? Keine Ahnung, ob das etwas bringt, aber vielleicht arbeitet er da etwas anders

 

[usefulvid]

das Protokoll zu wechseln

ne ganz schlimme sache. Geht nur mit SMB und dann auch noch nur SMBv1 und NTLMv1

 

[usefulvid]

Vielen Dank für deinen Upload. Die auslösenden Events sind CLOSE_WRITE,CLOSE. Das ist schade, dass das dein Scanner so macht. Hättest du vielleicht die Möglichkeit, das Protokoll zu wechseln (z.B. von SMB auf FTP oder umgekehrt)? Keine Ahnung, ob das etwas bringt, aber vielleicht arbeitet er da etwas anders

Wäre es eine möglichkeit mit der Prozessierung erst zu beginnen wenn der zeitstempel der Datei größer 30 Sekunden ist? Das würde mein Problem wahrscheinlich direkt lösen.

 

[geimist]

Wenn, dann nur optional. Es will ja nicht jeder warten. Dafür war manchen schon das kleinste (minütliche) Intervall des Zeitplaners zu lang - daher jetzt die Ordnerüberwachung.

Es ist aber auch so nicht trivial:

1. du scannst die erste Seite und dein Scanner schließt die Datei ➜ Event CLOSE_WRITE
2. jetzt wird die weitere Verarbeitung ausgelöst - in deinem Fall 30 Sekunden gewartet
3. du scannst weiter ➜ man müsste man den vorherigen Ablauf unterbrechen und erneut starten

Ggf. müsste man eine Prüfung am Ende der 30 Sekunden einbauen, ob sich der Zeitstempel zwischenzeitlich geändert hat.

Ich würde dir raten, dass mit einem eigenen Skript umzusetzen.

 

[geimist]

Guck dir mal diesen Einzeiler an. Wenn du in einen separaten Ordner scannst (/volume1/documents/tmp_input) und im Aufgabenplaner jede Minute dieses Skript laufen lässt, sollte dein Problem behoben sein. Nur alle Dateien, welche älter als eine Minute sind, werden in den finalen Inputordner verschoben.

find "/volume1/documents/tmp_input" -maxdepth 1 -iname "*.pdf" -mmin +1 -type f -exec mv {} "/volume1/documents/input" \;

-mmin +1 ist das Filterkriterium dafür, dass die Datei mindestens eine Minute alt sein muss.