synOCR synOCR - GUI für OCRmyPDF

[geimist]

Nein, der Fehler geht auf meine Kappe - @Tommes ist nur so schlau, ihn gleich zu finden

Das Release der Version 1.3.1 findet ihr hier auf meinem Server (für DSM6 & DSM7): https://geimist.eu/synOCR/
Das Release enthält ausschließlich diesen Bugfix der GUI.

DOWNLOAD:​

➜ SPK DSM6​

➜ SPK DSM7​

 

[Tommes]

Könnte ja auch von @Tommes ganz bewusst für mich eingebaut wurde sein

Erwischt! Ich habe mir damals die Nächte um die Ohren geschlagen, eine passende BASH Funktion nur für dich zu schreiben, die auch nur dann ausgelöst wird, wenn sich aus den aktuellen Werten von Datum, Uhrzeit, Außentemperatur und Luftfeuchtigkeit, dividiert mit deinem Geburtstag und der GeoIP deines Standortes die Zahl Pi errechnen lässt. Als ich dann endlich fertig war und das @geimist gezeigt habe, meinte der nur so… Blödsinn, viel zu aufwendig… ich lösch hier in Zeile 229 einfach mal eine eckige Klammer raus… hat den selben Effekt und wird auch nur @Thonav treffen. Und was soll ich sagen. Hat geklappt!

Das war natürlich nur ein kleiner Scherz. Tatsächlich haben wir zwei das nur gemacht, um ein wenig die Werbetrommel für LogAnalysis zu rühren. Denn am Ende hat LogAnalysis den Fehler innerhalb Sekunden gefunden. Dieses LogAnalysis ist wirklich der Hammer, sag ich euch. Du solltest demnach nicht mir bzw. uns, sondern dem Typen danken, der LogAnalysis einst erfunden hat. Ach Moment Mal… das war ich ja sebst. Verrückt!

Tommes

 

[Moblo]

Hallo zusammen,
erst einmal herzlichen Dank für dieses geniale Programm! Bin zutiefst begeistert!
Da ich trotz Suche nicht fündig geworden bin, hier eine Frage:

Ist es möglich, leere/weiße Seiten, die zum Beispiel beim Duplex-Scannen entstehen können, automatisch entfernen zu lassen?

Vielen Dank und viele Grüße
Moritz

 

[geimist]

Kurz gesagt: nein. Es ist gar nicht so einfach, das bei einem Scan zu definieren. Aber es wäre mal wieder eine Gelegenheit, ob es mit Python dafür eine gute Methode gibt. Aber wie gesagt: derzeit nicht …

 

[facetto]

Ist es möglich, leere/weiße Seiten, die zum Beispiel beim Duplex-Scannen entstehen können, automatisch entfernen zu lassen?

EDIT: wer oder was entfernt dann bei mir die leeren seiten, der scanner?!



ja klar, das sollte sogar eine Standardeinstellung von synocr sein. such mal in den Einstellungen danach. es gibt natürlich eine grauzone, in der sie seiten dann nicht mehr als leer erkannt werden, z.b. manchmal wenn gescannte einheftloecher drin sind.

VG

 

[Moblo]

Vielen Dank für die schnellen, wenn auch diametralen Antworten. Ich bin darauf gekommen, da ich mich gerade über potentielle Dokumenten-Scanner informiere und einige bieten eine solche Funktion an.

 

[geimist]

EDIT: wer oder was entfernt dann bei mir die leeren seiten, der scanner?!

So wird es wohl sein

 

[facetto]

Hi Moritz, vergiss meine antwort, Stephan ist hier der Wissende.

bzgl.scanner kann ich den brother 1700 ADS empfehlen - der kann offensichtlich leere seiten entfernen ;-)

 

[plang.pl]

Ja, kann er. Macht er bei mir auch

 

[Foggy]

Hallo in die Runde,
ich bin auch ein begeisterter Nutzer. Vielen Dank für dieses geniale Tool.
Aktuell arbeite ich mich in die Regeln vertieft ein und es klappt auch schon ganz gut. An einer Stelle verzweifele ich aber gerade an regex:
In Dokumenten wird von einem zum nächsten Hochgezählt: also z.B. Nummer 22, Nummer 23 etc. Zwischen Nummer und der Zahl sind ein bis drei Leerzeichen. Mit der Regel:

Regel_18:

    tagname: Abrechnung#§tagname_RegEx

    tagname_RegEx: (Nummer\s{1,})\d+

    targetfolder:

    condition: all

    subrules:

    - searchstring: Nummer\s{1,}\d+

      searchtyp: contains

      isRegEx: true

    - searchstring: Abrechnung

      isRegEx: false

gibt er am Ende aber als Dateinamen aus:

#Abrechnung#Nummer 25

*EDIT* Lustigerweise werden die Leerzeichen hier im Forum in der Ansicht weggekürzt; im Dateinamen sind 21 Leerzeichen zwischen der Nummer und der Ziffer.

Also mit viel zu vielen Leerzeichen im Namen. Ich habe schon alles mögliche Versucht, komme aber zu keinem gescheiten Ergebnis. Hat jemand eine Idee?
Gruß
Basti

 

[geimist]

Ab Version 1.3.0 gibt es in der GUI eine Einstellung, mit der multiple Leerzeichen im Suchtext auf eins reduziert werden können. Vielleicht hilft dir das. Alternativ kannst du dir im Loglevel 2 (debug mode) den OCR Textauszug im Logordner ansehen.

 

[Struppix]

Hallo Basti,
hierfür gibt es einige Möglichkeiten.

    tagname: Abrechnung#§tagname_RegEx

    tagname_RegEx: (Nummer\s{1,})\d+

    targetfolder:

    condition: all

    subrules:

    - searchstring: Nummer\s{1,}\d+

      searchtyp: contains

      isRegEx: true

    - searchstring: Abrechnung

      isRegEx: false

Leider kenne ich den Kontext nicht. Aber der einfachste Weg wäre so.

    tagname: Abrechnung#Nummer#§tagname_RegEx
    tagname_RegEx: (Nummer)\s+\K(\d+)
    targetfolder:
    condition: all
    subrules:
    - searchstring: (Nummer)\s+\K(\d+)
      searchtyp: contains
      isRegEx: true
    - searchstring: Abrechnung
      isRegEx: false

Der Parameter \K löscht die zuvor gemachte Ausgabe.

Gruß
Karsten

 

[Foggy]

Vielen Dank euch beiden! Beide Lösungswege funktionieren perfekt.
Gruß Basti

 

[DeeKay1]

Großes Lob, die aktuellen Versionen haben nochmal eine ordentliche Schippe draufgelegt.
Vor allem der Dokumententrenner ist interessant.
Bei doppelseitigen Dokumentenscans funktioniert ein einseitiger Trenner aber nicht wirklich, da das folgende Dokument eine leere Seite als 1te Seite (die Rückseite des Trennblatts) bekommt.
Ich hab mir deshalb mit einer doppelseitige bedruckten Trennseite beholfen. Die Dokumente werden dann auch so getrennt, wie erwartet. Allerdings wird eine weitere, komplett leere PDF erzeugt, die keinen Inhalt hat. Wahrscheinlich weil der Dokumentenprozessor zwischen den beiden Trennseiten, die ja auf demselben Blatt Papier sind, eine weiteres Dokument erwartet.

Beispiel Dokument 1 - Trennblatt (beidseitig mit Trennseite bedruckt) - Dokument 2

In der obigen Konstellation werden 3 Dokumente erzeugt: Dokument 1, komplett leeres PDF, Dokument 2

Wäre großartig wenn es eine Möglichkeit gibt die Erzeugung des leeren PDF-Dokuments zu verhindern.

 

[Monacum]

Das müsste eine Standardfunktion von OCRmyPDF sein, so dass das eigentlich auch ohne Probleme und leere Zwischenseiten funktionieren müsste, welches Trennblatt hast du denn verwendet? Standard sollte PATCH-T sein.

 

[geimist]

Bei doppelseitigen Dokumentenscans funktioniert ein einseitiger Trenner aber nicht wirklich …

Den Fall, dass Dokumente getrennt werden sollen, welche bereits auf einem Blatt Papier (Vor- und Rückseite) gescannt werden, hatte ich gar nicht als Eventualität betrachtet (weil in der Regel zusammengehörend).
Man ist ja auch nicht an das Trennblatt fixiert, sondern muss lediglich den gewünschten Begriff wählen. So könntest du einen Begriff wählen, der auf jedem Blatt vorhanden ist (evtl. der Begriff Seite) und definieren, dass Trennblätter erhalten bleiben sollen (was es in der separierten Form aber derzeit nicht gibt - das müsste ich einbauen).

Warum ein doppelseitiges Trennblatt für dich ein Workaround sein kann, ist mir fraglich. Meiner Meinung nach dürfte da etwas an meiner Logik nicht stimmen. Die Funktion findet sich hier, falls jemandem etwas auffallen sollte:
https://git.geimist.eu/geimist/synOCR/src/tag/v1.3.1/APP/ui/synOCR.sh#L1808

Das müsste eine Standardfunktion von OCRmyPDF sein, so dass das eigentlich auch ohne Probleme und leere Zwischenseiten funktionieren müsste, welches Trennblatt hast du denn verwendet? Standard sollte PATCH-T sein.

synOCR realisiert das direkt in Python (siehe voriger Link).
Hintergrund ist: ich möchte die Dokumente nicht zweimal an OCRmyPDF schicken.
Könntest du das mal etwas näher erleutern?

 

[Monacum]

Hi, bin von Paperless ausgegangen, sprich ebenfalls von OCRmyPDF; dort ist PATCH-T eben der Standard, wenn man es verwendet.

 

[Yippie]

Hi!

Ich habe gerade die neueste Version installiert und ein OCR laufen lassen.
Diese Regel wird angewendet, jedoch ist der Dateiname, der letztendlich angewendet wird, falsch, siehe unten.

RIESTER_3:
    tagname: "§yocr4-§mocr-§docr Renteninformation"
    tagname_RegEx:
    targetfolder: "/Riester/"
    condition: all
    subrules:
    - searchstring: "Renteninformation"
      searchtyp: is
      isRegEx: false
      source: content
      casesensitive: true
    - searchstring: "LV-?[[:digit:]]{4}-?[[:digit:]]{4}-?[[:digit:]]{4}"
      searchtyp: is
      isRegEx: true
      source: content
      casesensitive: true
    - searchstring: "Versicherungsnehmer"
      searchtyp: is
      isRegEx: false
      source: content
      casesensitive: true
    - searchstring: "Michael"
      searchtyp: is
      isRegEx: false
      source: content
      casesensitive: true

Aus der Log Datei:

rename tag is: "§yocr4-§mocr-§docr§yocr4-§mocr-§docr Renteninformation"

Und der Dateiname ist damit:
/volume1/Scanner/Ausgabe//Riester/2023-02-202023-02-20 Renteninformation.pdf

Kurzum, die aktuelle synOCR Version scheint die Datumstags zu duplizieren.
Die vorherige Version 1.3.0 tat das nicht.

Kann das jemand bestätigen und fixen?

Merci!

 

[geimist]

Du hast die Variablen offensichtlich selbst dupliziert. Check mal in der GUI deine globale Umbenennungssyntax. Wenn du immer das Datum vorm Namen willst, kannst du es in der Regel weglassen.
Der Tagname ergänzt ja die globals Umbenennung, aber ersetzt sie nicht.

Kurzum, die aktuelle synOCR Version scheint die Datumstags zu duplizieren.
Die vorherige Version 1.3.0 tat das nicht.

Das stimmt insoweit, dass vorher keine Variablen im Tagnamen möglich waren.

 

[Yippie]

Danke Stefan für deine Antwort!

In den GUI Optionen habe ich aber rein gar nix verändert. Einfach nur einen neue PDF durch das OCR gejagt, mehr nicht. Achso ja, zuvor ein Update auf 1.3.1 durchgeführt.

Würde aber jetzt bedeuten, dass sich die Verhaltensweise von synOCR verändert hat.
Gibts da ein Changelog? Denn weiter oben steht, dass mit 1.3.1 lediglich das GUI Anzeige Problem gefixt wurde.