synOCR synOCR - GUI für OCRmyPDF

[DeeKay1]

Hi @geimist
ich hab mal wieder ein Prob mit Regex
Allerdings diesmal nicht mit den eigenen Regeln sondern mit der Datumserkennung.
Bei dem Briefkopf unten ist ja ein Datum oberhalb der Adresse -> ...025*23.07.20*
Zwar ist rechts nochmal das "echte" Datum (17.07.2020) aber synOCR erkennt das linke natürlich zuerst.


Das führt dann zu dem hier:
check date (dd mm [yy]yy): "8535970"119025"23.07.20*./synOCR.sh: line 872: 10#8535970
119025
23 : syntax error in expression (error token is "119025
23 ")
? invalid format
check date ([yy]yy mm dd): "8535970"119025"23.07.20* ? invalid format
check date (mm dd [yy]yy): 17.07.2020 ? invalid format
Date not found in OCR text - use file date:

Zum einen versteh ich nicht, wieso er das Datum 23.07.20 nicht korrekt aus dem Briefkopf rauslöst, da dein Datums-Regex eigentlich korrekt ist. Prinzipiell wird mit dem Regex eigentlich alles vor und nach dem Datum entfernt - scheint aber hier irgendwie mit awk ein Spezialfall zu sein.
Zum anderen geht synOCR ja dann doch noch irgendwie auf das "echte" Datum, aber startet nicht mehr bei ddmmyy, sondern direkt bei mmddyy, wodurch das Format nicht passt.
Bevor ich hier Änderungen vorschlage wollte ich mal deine Meinung dazu abfragen.

 

[geimist]

Statt die Funktion parseRegex zu nutzen, könntest du es ja mal mit egrep -o versuchen. Die ganze Datumssuche ist eh noch nicht für mich zufriedenstellend. Ich würde gerne auch ausgeschriebene Monate erkennen können (1. Februar 2020), aber das macht die Internationalisierung noch schwerer. Hier wäre eine externe Bibliothek sehr nützlich. In Python gibt es wohl erweiterte Möglichkeiten (Python 3 ist ja ab DSM 7 nativ enthalten).

Kurz gesagt: ich bin für jede Verbesserung dankbar

 

[DeeKay1]

Alles klar. Dann geh ich mal an die Ablöse von awk. Das wäre auch mein erster Ansatz gewesen.

 

[DeeKay1]

Ok, das war einfach:
check date (dd mm [yy]yy): 23.07.20 ? valid
day: 23
month:07
year: 2020
? renaming:
apply renaming syntax ? 2020-07-23_#Beiträge_#Deutsche_Rentenversicherung_OCR

Zeile 867: founddate=$( egrep -o "\b([1-9]|[012][0-9]|3[01])[\./-]([1-9]|[01][0-9])[\./-](19[0-9]{2}|20[0-9]{2}|[0-9]{2})\b" <<< "$content" | head -n1 )

Entsprechend auch die Zeilen 894 und 919 anpassen.
Die paresRegex-Funktion wird danach nicht mehr verwendet und könnte dann auch gelöscht werden.

Bleibt nur noch die Frage ob es allgemeingültig ist, dass man das Datum im Briefkopf, also im Code oberhalb der Adresse in meinem Screenshot, nicht haben möchte und stattdessen erstmal nach dem nächsten Datum sucht. Ich würde die Aussage erstmal als richtig ansehen, seh das aber durch die Brille meines aktuellen Problems
Falls dem so wäre, könnte man die founddate-Suche ja ändern und erstmal nach "[...]egrep -o "\s([1-9]|[012][....]" anstatt nach "[...]egrep -o "\b([1-9]|[012][....]" suchen und nur im Nicht-Gefunden-Fall auf die "\b"-Variante switchen. Was meinst du?

 

[s-tyle]

Update: aktuell versuche ich mich an einer Lösung via Aufgabenplaner, die neuen gescannten pdf Dateien in den Eingangsordner zu schieben. Da ist noch was dran zu tun...Synology soll sich Dateien holen wenn sie in einem Netzwerkordner auftauchen
Aber dann: Läufts. Der synOCR-Aufgabenplaner fängt mit den Eingangsordner-Dateien an zu arbeiten

Was mir noch aufgefallen ist:
- insbesondere bei Zeugnissen, Zertifikaten steht idR oben Name und Geburtsdatum, am Ende Dokumentendatum und Unterschriften. Ich hätte gerade keine schlaue Idee, woran man das Differenzieren könnte, aber das führt zu falschen Datumswerten bei der Benennung. Das dürfte angelehnt an das Problem paar weiter oben sein.
- Bei Dokumenten aus dem letzten Jahrtausend mit zweistelliger Jahresangabe macht er aus z.B. 96 -> 2096. Als Lösungsansatz, der die meisten Abweichungen abfangen sollte hätte ich nur den Gedanken, an der Funktion wenn scan-jahr>aktuelles-jahr + 20 dann 19xx sonst 20xx einzubauen, weiter als 20 Jahre voraus dürfte nix in Dokumenten stehen. Wenn man strikt von Dokumentendatum ausgeht, dürfte es allenfalls bei Entwürfen um kurze Zeiträume voraus gehen, also vielleicht noch konsequenter 19xx wählen.
- Außerdem scheint synOCR auch Hochformat/Querformat anzupassen, das funktioniert aber nicht Zuverlässig, ein Datei-Hochformat gescanntes Querformat-Dokument ist weiter Datei-Hochformat (Inhalt 90° rechts gedreht, der Text wurde aber tatsächlich gut erkannt!), ein anderes Dokument hat erst zwei Seiten Datei-Hochformat - Dokument Hochformat und dann zwei Seiten Datei-Hochformat - Dokument Querformat, von den letzten beiden ist die erste korrekt gedreht, die zweite weiter "falsch" (Inhalt 90° links gedreht, hier klappt die Texterkennung garnicht, weil er auf dem Kopf denkt, was man an den Preisen auf der Seite sehr gut erkennen kann: 7,60 -> 09,L ). Auch hier leider keine Ahnung, wie man das Lösen könnte.

 

[s-tyle]

Noch ne Ergänzungsidee. Wenn ich es richtig verstanden habe gebe ich Tags ein, nach denen so gesucht wird und die dann so in den dateinamen gebaut werden. Bei Bedarf mit = eine Kategorie anlegen, die bei Verschieben in Kategorie Ordner genutzt wird, sosnt nicht?
Kann man auch iwie einen Tag-Alias anlegen, der in den Dateinamen gebaut wird, statt dem Suchtag?
(Falls noch nicht, ist vielleicht eine Syntax mit : möglich, also zB "Klaus-Peter:KP=Klaus;" -> Tag Klaus-Peter, Dateiname mit KP, Kategorie Ordner Klaus)

Mit Konsole rsync vom eingebundenen Fritz-Ordner in den Source Ordner läuft synOCR jetzt übrigens zuverlässig. Jetzt mühe ich mich an anderer Stelle um den rsync als benutzerdefiniertes skript, damit ausser datei scannen wirklich nichts dran zu tun ist.

 

[DeeKay1]

@s-tyle
Zwecks Hoch-/Querformat: Alles was mit OCR und PDF-Bearbeitung zu tun hat, erledigt nicht synOCR direkt sondern der docker container ocrmypdf.
SynOCR lässt dir aber in den Profiloptionen mit "OCR options" die Möglichkeit, auf das das Verhalten von ocrmypdf Einfluss zu nehmen.
Ich empfehle hierzu die Doku unter: Introduction — ocrmypdf 11.4.0.post1+gad20269 documentation
Für das Hoch-/Querformats-Thema solltest du mit --rotate-pages-threshold hier fündig werden: Cookbook — ocrmypdf 11.4.0.post1+gad20269 documentation
Umso niedriger du den Wert setzt, umso eher wird ocrmypdf eine Seite als gedreht erkennen und die Drehung im PDF auch korriegieren. Bei mir musste ich tatsächlich auf 0.5 runter gehen. Kann ich aber nicht generell empfehlen, muss jeder für sich selbst herausfinden. Ggf. sind da auch mehrere Profile notwendig.

Dein Thema mit den Tags solltest du über die erweiterten Tag-Möglichkeiten mittels yaml-Datei hinbekommen.
Für dein Klaus-Peter-Beispiel sollte die Config unten funktionieren. Im content wird nach "Klaus-Peter" gesucht, der Tag-Name im Dateinamen würde "KP" lauten und die Datei wird in den Ordner nach /irgendwas/Klaus verschoben.

Klaus-Peter-Tag-Config:
    tagname: KP
    targetfolder: /irgendwas/Klaus
    condition: all
    subrules:
    - searchstring: Klaus-Peter
      searchtyp: contains
      isRegEx: false
      source: content
      casesensitive: false

 

[s-tyle]

Jippa, die Search-String/Tagname Sache funktioneirt in der Tat, sehr sehr schick! Zweiter SearchString Block für einen Tag scheint auch zu gehen, das erweitert mein "Denken" nochmal ne ganze Ecke.
Bzgl. Rotation muss ich mich zu einem anderen Zeitpunkt nochmal weiter reinlesen wohl, vorher muss der Workflow selber funktionieren -> rsync Thema. Danke auch für die Blickrichtung aber dennoch schon mal.

 

[geimist]

Zweiter SearchString Block für einen Tag scheint auch zu gehen

Die Anzahl der subrules ist nicht beschränkt.
Ein Stolperstein, der derzeit nicht gut dokumentiert und auch noch nicht abgefangen wird: Regelnamen (Klaus-Peter-Tag-Config: im Beispiel) dürfen nur alphanumerisch sein, aber NICHT mit einer Zahl beginnen - daran verschluckt sich der JSON-Parser.

Zeile 867: founddate=$( egrep -o "\b([1-9]|[012][0-9]|3[01])[\./-]([1-9]|[01][0-9])[\./-](19[0-9]{2}|20[0-9]{2}|[0-9]{2})\b" <<< "$content" | head -n1 )

Vielen Dank

Falls dem so wäre, könnte man die founddate-Suche ja ändern und erstmal nach "[...]egrep -o "\s([1-9]|[012][....]" anstatt nach "[...]egrep -o "\b([1-9]|[012][....]" suchen und nur im Nicht-Gefunden-Fall auf die "\b"-Variante switchen. Was meinst du?

Da musst du mir mal in meiner Unwissenheit kurz erläutern, was der Schalter \s statt \b bewirkt (sorry, ich habe es mir jetzt nicht ergooglt).
Generell würde ich vorschlagen, nicht allzu viel Mühe in die aktuelle Datumssuche zu investieren, sondern diesen Bereich, wie angesprochen, mal grundlegend zu ändern. Aktuell geht es für synOCR bei mir rein gar nicht weiter - umso mehr freue ich mich über Unterstützung

 

[DeeKay1]

Ein Stolperstein, der derzeit nicht gut dokumentiert und auch noch nicht abgefangen wird: Regelnamen (Klaus-Peter-Tag-Config: im Beispiel) dürfen nur alphanumerisch sein, aber NICHT mit einer Zahl beginnen - daran verschluckt sich der JSON-Parser.

Sonderzeichen und um Umlaute sind auch ganz schlimm.

Generell würde ich vorschlagen, nicht allzu viel Mühe in die aktuelle Datumssuche zu investieren

Ja, das hatte ich erstmal auch nicht vor. Das aktuelle findet, in meinen Augen, zu 60-70% das richtige Datum. Die \s-Anpassung ist nur relativ klein/einfach, daher der Vorschlag

Da musst du mir mal in meiner Unwissenheit kurz erläutern, was der Schalter \s statt \b bewirkt

\b definiert Wortgrenzen. \b am Anfang des Datum-Regex führt also sowohl bei ".23.07.20#" als auch " 23.07.20#" zum Ergebnis "23.07.20".
\s definiert einen Whitespace, also zB die Leertaste oder einen Tab oder Zeilenumbruch. \s am Anfang des Datum-Regex führt bei ".23.07.20#" zu gar keinem Ergebnis, da "." kein Whitespace ist und bei " 23.07.20#" zum Ergebnis "23.07.20".
In meiner Denkweise wäre \s statt \b am Regex-Anfang völlig ausreichend, da sämtliche, für die Ermittlung des richtigen Datums, gefundenen Werte im Text selten direkt vor der ersten Zahl ein anderes Zeichen als eine oder mehrere Whitespaces haben.

 

[geimist]

Sonderzeichen und um Umlaute sind auch ganz schlimm.

Richtig (daher schrieb ich 'nur alphanumerisch' )

In meiner Denkweise wäre \s statt \b am Regex-Anfang völlig ausreichend

Das klingt logisch - vielen Dank auch dafür.

 

[voodoo44]

Moinsen, ist das Tool Quellcodeoffen, bzw. findet man den Code dafür irgendwo auf Github o.ä.?
In der aktuellen DSM 7 Preview funktioniert es nicht mehr und ich hätte mir sonst mal angeschaut, wie man das ggf. fixen kann

 

[geimist]

Du hast eine PN

 

[DeeKay1]

Hi @geimist,
ich hätte noch einen Änderungsvorschlag für das Auffinden des Datums ab Zeile 877. Gleiches müsste natürlich auch noch in den beiden folgenden IFs gemacht werden.

            currentyear=$(date +%y)
            if [ $(echo $date_yy | wc -c) -eq 3 ]; then
                if [$daty_yy -gt $currentyear]; then
                    date_yy="19${date_yy}"
                else
                    date_yy="20${date_yy}"
                fi
            fi

Durch die innere If Bedingung wird aus:
16.12.20 -> 16.12.2020
16.12.19 -> 16.12.2019
16.12.21 -> 16.12.1921

Da dort ja quasi das Dokumentdatum gesucht wird, also das Datum an dem das Dokument erstellt wurde, kann dieses eigentlich niemals in der Zukunft liegen. Hat bei mir bei der Benennung etwas älterer Dokumente geholfen, da dort gerne mal ein Datum mit 60-70 Jahren in der Zukunft im Dateinamen gesetzt wurde.

 

[geimist]

Vielen Dank - das hatte ich auch so auf meine ToDo-Liste

 

[DeeKay1]

Gerne, aber nimm das unten, hatte oben noch einen Fehler

            currentyear=$(date +%y)
            if [ $(echo $date_yy | wc -c) -eq 3 ]; then
                if [ $date_yy -gt $currentyear ]; then
                    date_yy="19${date_yy}"
                else
                    date_yy="20${date_yy}"
                fi
            fi

 

[Gortosch]

Hey voodoo44,

finde ich klasse, dass du mal schaust. Danke.


Grüße
Sven

 

[DeeKay1]

Hi @geimist

ich hätte eine größere Änderung zum Extrahieren des Dokumentdatums.
Folgendes ist mit drin:
- Kapselung der Extrahierlogik in eine rekursive Funktion. Für neue Datumsformate (dd/mm/yy, etc.) müssen darin nur noch drei If-Statements innerhalb der Funktion findDateByFormat angepasst werden
- Iteration durch alle gefundenen Datumswerte. Dadurch wird es (zukünftig) möglich, Datumswerte zu ignorieren. Bspw. hab ich oft das Problem, dass in offiziellen Dokumenten mein Geburtsdatum sehr oft am Anfang eines Dokuments steht. Dieses möchte ich natürlich ignorieren. Da hierfür natürlich auch Änderungen am UI notwendig sind, sollte die if-Bedingung in Zeile 56 erstmal noch entfernt werden.

Im Log sieht das dann so aus:

                  Using date format: 1 (1 = dd mm [yy]yy; 2 = [yy]yy mm dd; 3 = mm dd [yy]yy)
                  Dates found: 2
                  check date (dd mm [yy]yy):  04.11.85
                  currentCentury: 20
                  Date is most probably in the last century. Setting year to 1985
                  Date 04.11.1985 is on ignore list. Skipping this date.
                  check date (dd mm [yy]yy):  11.07.17
                  currentCentury: 20
? valid
                  day:  11
                  month:07
                  year: 2017
              ? renaming:
                  apply renaming syntax ? 2017-07-11_OCR

            findDateByFormat(){
                format=$1 # 1 = dd mm [yy]yy; 2 = [yy]yy mm dd; 3 = mm dd [yy]yy
                echo "                  Using date format: ${format} (1 = dd mm [yy]yy; 2 = [yy]yy mm dd; 3 = mm dd [yy]yy)"
                founddatestr=""
                if [ $format -eq 1 ]; then
                    # suche Format: dd[./-]mm[./-]yy(yy)
                    founddatestr=$( egrep -o "\s([1-9]|[012][0-9]|3[01])[\./-]([1-9]|[01][0-9])[\./-](19[0-9]{2}|20[0-9]{2}|[0-9]{2})\b" <<< "$content" | head )
                elif [ $format -eq 2 ]; then
                    # suche Format: yy(yy)[./-]mm[./-]dd
                    founddatestr=$( egrep -o "\s(19[0-9]{2}|20[0-9]{2}|[0-9]{2})[\./-]([1-9]|[01][0-9])[\./-]([1-9]|[012][0-9]|3[01])\b" <<< "$content" | head )
                elif  [ $format -eq 3 ]; then
                    # suche Format: mm[./-]dd[./-]yy(yy) amerikanisch
                    founddatestr=$( egrep -o "\s([1-9]|[01][0-9])[\./-]([1-9]|[012][0-9]|3[01])[\./-](19[0-9]{2}|20[0-9]{2}|[0-9]{2})\b" <<< "$content" | head )
                fi
                    # INFO about \y: In other GNU software, the word-boundary operator is ‘\b’. However, that conflicts with the awk language’s definition of ‘\b’ as backspace,
                # so gawk uses a different letter. The current method of using ‘\y’ for the GNU ‘\b’ appears to be the lesser of two evils.
                # https://www.gnu.org/software/gawk/manual/html_node/GNU-Regexp-Operators.html
                if [[ ! -z $founddatestr ]]; then
                    readarray -t founddates <<<"$founddatestr"
                    cntDatesFound=${#founddates[@]}
                    echo "                  Dates found: ${cntDatesFound}"
                    #for start
                    for currentFoundDate in "${founddates[@]}"
                    do
                        if [ $format -eq 1 ]; then
                            echo "                  check date (dd mm [yy]yy): $currentFoundDate"
                            date_dd=$(printf '%02d' $(( 10#$(echo $currentFoundDate | awk -F'[./-]' '{print $1}' | grep -o '[0-9]*') ))) # https://ubuntuforums.org/showthread.php?t=1402291&s=ea6c4468658e97610c038c97b4796b78&p=8805742#post8805742
                            date_mm=$(printf '%02d' $(( 10#$(echo $currentFoundDate | awk -F'[./-]' '{print $2}') )))
                            date_yy=$(echo $currentFoundDate | awk -F'[./-]' '{print $3}' | grep -o '[0-9]*')
                        elif [ $format -eq 2 ]; then
                            echo "                  check date ([yy]yy mm dd): $currentFoundDate"
                            date_dd=$(printf '%02d' $(( 10#$(echo $currentFoundDate | awk -F'[./-]' '{print $3}' | grep -o '[0-9]*') )))
                            date_mm=$(printf '%02d' $(( 10#$(echo $currentFoundDate | awk -F'[./-]' '{print $2}') )))
                            date_yy=$(echo $currentFoundDate | awk -F'[./-]' '{print $1}' | grep -o '[0-9]*')
                        elif  [ $format -eq 3 ]; then
                            echo "                  check date (mm dd [yy]yy): $currentFoundDate"
                            date_dd=$(printf '%02d' $(( 10#$(echo $currentFoundDate | awk -F'[./-]' '{print $2}' | grep -o '[0-9]*') )))
                            date_mm=$(printf '%02d' $(( 10#$(echo $currentFoundDate | awk -F'[./-]' '{print $1}') )))
                            date_yy=$(echo $currentFoundDate | awk -F'[./-]' '{print $3}' | grep -o '[0-9]*')
                        fi
                        
                        currentCentury=$(date +%y)
                        lastCentury="$(($currentCentury-1))"
                        echo "                  currentCentury: ${currentCentury}"
                        if [ $(echo $date_yy | wc -c) -eq 3 ]; then
                            if [ $date_yy -gt $currentCentury ]; then
                                date_yy="${lastCentury}${date_yy}"
                                echo "                  Date is most probably in the last century. Setting year to ${date_yy}"
                            else
                                date_yy="${currentCentury}${date_yy}"
                            fi
                        fi
                        date "+%d/%m/%Y" -d ${date_mm}/${date_dd}/${date_yy} > /dev/null  2>&1    # valid date? https://stackoverflow.com/questions/18731346/validate-date-format-in-a-shell-script
                        if [ $? -eq 0 ]; then
                            if [ $date_dd -eq 19 ] && [ $date_mm -eq 01 ] && [ $date_yy -eq 1988 ]; then
                                echo "                  Date ${date_dd}.${date_mm}.${date_yy} is on ignore list. Skipping this date."
                                continue
                            else
                                echo " ? valid"
                                echo "                  day:  ${date_dd}"
                                echo "                  month:${date_mm}"
                                echo "                  year: ${date_yy}"
                                dateIsFound=yes
                                break
                            fi
                        else
                            echo " ? invalid format"
                        fi
                        #founddate=""
                        #for end
                    done
                fi
                    
                if [ $dateIsFound = no ]; then
                    if [ $format -eq 1 ]; then
                        findDateByFormat 2
                    elif [ $format -eq 2 ]; then
                        findDateByFormat 3
                    fi
                fi
            }
            findDateByFormat 1

 

[MacHolgi]

Hallo Stephan,
jetzt muss ich kurz vor Weihnachten auch noch mit einem Problem um die Ecke kommen :-(

Was ich am laufen hatte und problemlos funktioniert hatte:
- Scanner scannt via Netzwerk auf USB-Stick, der an einer Fritz!Box 7390 angeschlossen ist
- die Scan-Ordner von der Fritz!Box ("Scan-OCR" und "Scans_ohne_OCR") sind als Remote-Ordner bei der Synology DS216plusII eingebunden
- Beim starten der Synology hat er brav alle Scans aus den beiden Quellordnern verarbeitet, in den Zielordner kopiert und die Originaldatei aus dem Quellordner gelöscht. Nach jeder PDF gab ein einen Quittungs-"Piep". Über den Aufgabenplaner hat die Synology nun alle 10 min. nach neuen PDFs geschaut.

Dann habe ich die Fritz!Box 7390 gegen eine 7490 getauscht. Den USB-Stick habe ich dabei umgesteckt. Da die Fritz!Box 7490 im Gegensatz zur 7390 auch den Namen des USB-Sticks im Laufwerkspfad berücksichtigt, habe ich noch die Remote-Ordner neu angelegt. Außerdem in der Fritz!Box 7490 SMB1 aktiviert. Ansonsten wurde nichts verändert.

Leider funktioniert nun die Verarbeitung der PDFs nicht mehr:
Nach dem Einschalten der Synology verarbeitet synOCR maximal eine PDF, meist wird diese nach der Verarbeitung nicht aus dem Quellordner gelöscht, manchmal aber doch, dann kommt auch einen "Piep". Aber es werden dann keine weiteren Dateien mehr verarbeitet.
Versuche ich auf der Seite "Übersicht" einen manuellen synOCR Durchlauf zu starten, bekomme ich die Meldung "synOCR läuft bereits!" Eine Prozess-ID und den Button "(Beenden erzwingen?)" Dann kann ich zwar einen weiteren Durchlauf starten, der kommt aber über das Fenster "Bitte warten Sie, bis die Daten fertig abgearbeitet wurden." nicht hinaus, im Log sehe ich, dass er die nächste Datei bearbeiten möchte - es passiert aber nichts mehr, auch wenn ich 20 min. warte. Im Docker wird synOCR gestartet und läuft.

Ich hänge mal die letzten Log-Dateien an. Da liegt jeweils ein Neustart der Synology dazwischen.
Mir fällt hier auf, dass bei allen weiteren Dateien (also ab der zweiten) dahinter steht: "No such file or directory". die Dateien sind aber definitiv im Verzeichnis vorhanden und myOCR hat auch Schreibrechte auf diesen Ordner..

Hast Du eine Idee, wo das Problem liegt?

Gruß, Holger

 

[geimist]

@s-tyle hat das selbe Problem. Es scheint an dem Ordnermount zu liegen. Er behilft sich mit einem Kopierskript und arbeitet nicht direkt im Remoteordner.