synOCR synOCR - GUI für OCRmyPDF

[geimist]

Viel Platz nach oben ist ja nicht mehr, ausgehend von der aktuellen 1.4.99.6. Kann also nicht mehr all zu lange dauern

Ich beginne Betaversionen immer bei der Vorversion zu zählen (x.x.99.1__________________), damit ein folgendes Release auch eine höhere Versionsnummer als die letzte Beta hat. Und du ahnst nicht, wie hoch man die vierte Stelle zählen kann

Wie lange die Betaphase läuft, hängt davon ab, wie zufrieden alle mit den aktuellen Features sind und ob ich beim Wühlen in der ToDo-Liste noch weiteres mit einbauen kann und will

Z.B. bin ich mir noch nicht sicher, ob ich einen Schalter zum ignorieren von Text bei der Leerseitenerkennung mit einbauen sollte. Der durchschimmernde Text der Vorderseite ist wirklich das Problem bei @Yippie. Andererseits bietet die aktuelle Implementierung eine gute Sicherheit vor fälschlich gelöschten Leerseiten. Das muss ja zuverlässig funktionieren. Daher noch die offene Frage, ob bereits ein Anpassen der Scanparameter Abhilfe schafft.

 

[gunfran]

Persönlich glaube ich das bei dieser Funktion deine vorsichtige Variante schon gut ist.
Ich halte es schon für zu gefährlich das durch eine fälschliche Annahme eine Seite entfernt wird, die durchaus wichtig ist.
Auch wenn das nicht so schön wirkt, halte ich eine Leerseite innerhalb eines PDFs durch durchschimmern nicht für eine absolute Katastrophe.
Auch mit dem Wissen das ich als Privatperson lange nicht in dem Umfang scanne wie so manche User in Firmenumfeld.

 

[hilly]

Damit kann synOCR leider nicht dienen. Ich habe dir aber mal ein kleines Bashskript erstellt. Dieses baut ein Dockerimage mit lediglich 2 Programmen, die genau dein Vorhaben umsetzen. Nachdem das Image beim 1. Aufruf gebaut wurde, geht es ab dem 2. Start ganz fix.

Waow, mega! 1000 Dank!! Werd ich direkt später mal testen.

Hammer

Thx,

Hilly

 

[Yippie]

Kann dein Scanner in 1Bit Farbtiefe (also schwarz/weiß) scannen? Das könnte das Problem beheben und belohnt zusätzlich mit signifikant kleineren Dateien.

Werde das Mal prüfen, allerdings liegt seit heute ein Epson ES-580W hier im Büro. Vielleicht kann der ja sowas

BTW, ich war ja ohnehin etwas dämlich, als ich mein Posting verfasst habe. Ich habe zwei DS hier und auf beiden läuft synOCR. Auf derjenigen DS, die eigentlich nicht mehr produktiv fürs OCR verwendet wird, habe ich die jedoch die neue Beta eingespielt.
Die Erkennung von Leerseiten aber auf der Produktiv-DS getestet - ohne natürlich zuvor das Update von synOCR einzuspielen! Wie blöd muss man eigentlich sein???

Anyway, mit der Verwendung der korrekten DS und dem erneuten Test zum Entfernen der Leerseite änderte jedoch nichts am Ergebnis und, ich habs jetzt auch gesehen, dass es auf meiner "Leerseite" einen Text-Layer gibt mit unlesbaren Wörtern gibt.
Die scheint wohl tatsächlich beim Duplex-Scannen von der durchscheinenden Vorderseite "erkannt" worden zu sein.

Nachdem ich den Textlayer dann entfernt hatte und neu durch synOCR laufen habe lassen, wurde die Leerseite auch entfernt.
Dachte zwar, bei Vorhandensein von Textlayern in einer PDF, macht synOCR keine neue Texterkennung, aber offenbar trotzdem die Entfernung von Leerseiten(?).

 

[geimist]

Ja, dass Verhalten mit deinem Scan konnte ich hier nachstellen. Insofern hat deine Verwechslung nichts am Ergebnis geändert.
Da nicht alle Scanner einen 1Bit-Modus haben (ich scanne damit fast ausschließlich), habe ich mal versucht, das mit den in synOCR vorhandenen Tools einzubauen. Auf der Kommandozeile funktioniert das auch schon. Damit wird dein 529KB großer Scan zu einem 56KB kleinen Scan (ich hab ihn mal angehangen). Damit funktioniert dann auch wie erwartet die Leerseitenerkennung.

Dachte zwar, bei Vorhandensein von Textlayern in einer PDF, macht synOCR keine neue Texterkennung, aber offenbar trotzdem die Entfernung von Leerseiten(?).

Das kannst du mit den OCR-Parametern -s (skip Text) und -f (force OCR) beeinflussen.

Frage an alle:​

Soll ich eine Schwarzweiß-Konvertierung (1Bit Farbtiefe) mit einbauen

 

[wegomyway]

@geimist , ich geh von aus das der 1700er Brother 1bit kann .
Bedeutet doch das es entweder schwarz oder Weiß ist.
Ist die Option dann in den Profilen, wie jetzt "Leerseiten" drin und somit jeweils in den Profilen wählbar?
Dann sach ich mal gerne implantieren. Kann sich ja jeder aussuchen wo es für ihn Sinn macht nur Schwarz/weiß zu haben.
PS: Leerseiten-Option funktioniert gut. Hatte bereits Dokumente gescannt, die per Brief gekommen sind und die leeren Seiten wurden korrekt eliminiert.

 

[geimist]

Ja, der Brother sollte das von Haus aus können. Und ja: Es bedeutet, dass die Pixel nicht in Graustufen abgespeichert werden, sondern halt nur schwarz oder weiß. Für Briefe ist das ideal, aber nicht für Grafiken ect. Dadurch wird die Schrift gefühlt schärfer, die Dateien kleiner und Störungen wie ein Durchscheinen der Rückseite werden minimiert.

Wenn ich das einbaue, dann als eigenes Element inkl. Parameter in der GUI.

 

[wegomyway]

@geimist, DANN gerne!
Wenn es was zum „Betatesten“ gibt .

 

[Yippie]

Wenn ich das einbaue, dann als eigenes Element inkl. Parameter in der GUI.

Danke! Ich bin halt immer ein Freund von was ich selbst beeinflussen kann ist mir immer am liebsten, allerdings pfriemelt natürlich nicht jeder in irgendwelchen Config-, YML- oder INI-Dateien rum.

Sprich diese Option würde ich gerne in den YML-Regeln übersteuern können, wie schon die auch die Erkennung von Leerseiten generell.

Aber Mal ganz grundsätzlich: Ich scann ja ein Dokument welches mein Scanner dann als PDF ablegt und das ist ja schon Mal in Grautönen oder eben farbig. Was macht dann dieses 1bit-Dings/Option in synOCR?

Wird diese Option mein PDF nachträglich manipulieren oder wie muss ich mir das vorstellen?
Ich meine, wenn der Scanner diese Option hardwareseitig anbietet, dann würde ich tatsächlich am Ende ein PDF haben, welches nur schwarz/weiß ist, aber im Fall der Software?

 

[geimist]

Diese Funktion kann ich erst recht nicht über YAML anbieten, da sie ja vor dem OCR angewandt wird. Und ja: die Dateien werden verändert. Sonst gäbe es ja nicht die beschriebenen Vorteile:

Dadurch wird die Schrift gefühlt schärfer, die Dateien kleiner und Störungen wie ein Durchscheinen der Rückseite werden minimiert.

Ich habe dir ja mal dein Test-Scan konvertiert oben mit angehangen.

Das diese Option nicht für jeden Scan gut ist, ist ja klar. Das müsste man dann über zusätzliche Profile in synOCR steuern, wie man es ja in dem Fall im Scanner auch tut.

 

[Yippie]

Das diese Option nicht für jeden Scan gut ist, ist ja klar. Das müsste man dann über zusätzliche Profile in synOCR steuern, wie man es ja in dem Fall im Scanner auch tut.

Das wäre tatsächlich eine Möglichkeit, also ein zweites, drittes usw. Profil mit entsprechender YML-Datei.

Was mir noch in den Sinn kommt, aber sehr zeitintensiv sein wird: Mit der neuen Optionen das PDF temporär, intern in 1bit umwandeln, dann entscheiden was die Leerseiten sind und diese Seiten dann in der Original-PDF entfernen.

Die temp. 1bit-Datei am Ende natürlich wieder entfernen.

 

[geimist]

Das wäre tatsächlich eine Möglichkeit, also ein zweites, drittes usw. Profil mit entsprechender YML-Datei.

synOCR Profile kann man ja duplizieren (inkl. dem Verweis auf eine gemeinsame YAML-Regeldatei). Nur die Quellordner müssten unterschiedlich sein.

Ja, so eine Idee mit dem parallelen Ablauf kam mir auch schon. Das wäre sicherlich auch möglich, macht den Code aber immer unübersichtlicher. Dass müsste man alles irgendwie vom User steuerbar machen, weil der eine dies möchte und ein anderer jenes.

 

[FoxageX]

Helft mir mal, ich bin verzweifelt. (nicht wirklich )
Ich hab jetzt einen grösseren Schwung von PDFs durch meine Tags laufen lassen.
Nun ist es so, da es derzeit noch keine Tag Verknüpfungen gibt (Tag: A,B,C=Ordner D), habe ich A=Ordner D,B=Ordner D,C=Ordner D, gesetzt.
Nun habe ich die konvertierten PDFs an mehreren Orten doppelt liegen. Wahrscheinlich "by design"....

Wie bekomme ich:
a) mehrere Tags abgearbeitet - Wenn Du findest dann.... hopp dahin....
b) das bitte nur an einem Zielort.

Derzeit habe ich "nutze Kategorieordner" statt "nutze Tags" eingestellt.

Ist dieses Thema eigentlich jemals wieder diskutiert worden?
Auch ich sehe mich derzeit mit gewisser Mehrarbeit belastet, wenn PDFs, die mehrere Tags beinhalten (#Name1, #Name2, #Name3) in mehreren Ordner (Name1, Name2, Name3) einsortiert werden und in diesem Beispiel dann 3 Mal vorliegen, obwohl zum Schluss nur eine Datei benötigt wird.
Gibt es eine Möglichkeit, solche Dateien mit mehreren Tags in nur einen Ordner einzusortieren, zum Beispiel in denjenigenen Ordner, zu dem der entsprechende Tag beim Durchsuchen des PDFs am häufigsten gefunden wurde? Oder schlicht in den Ordner mit dem zuerst gefundenen Tag im PDF? Besten Gruß

 

[geimist]

Wie kann synOCR denn wissen, welche Tags dem User am wichtigsten sind?
Und nur aus der Anzahl der Fundstellen eine Priorität abzuleiten würde ich nicht als ein sehr zuverlässiges Kriterium betrachten.
Wenn ich z.B. eine Rechnung vom Zahnarzt habe, möchte ich sie vielleicht in Rechnungen einsortiert haben. Ein anderer User aber in der Kategorie Gesundheit. Andere wieder in beide. Gar nicht so einfach …

Vielleicht hilft es schon, wenn man nicht für jeden Tag einen Zielordner definiert.
Von Anfang an ist es aber so geregelt, dass bei mehreren Zielen Hardlinks gesetzt werden (es also keinen Einfluss auf den Speicherplatz hat).

 

[wegomyway]

Sodele, ich komme mit meinem extrem verzögerten letztem „Projekt“ daher. Aus meinem Sommerwohnsitz „stapeln“ sich reichlich Rechnungen. Also alles, was im Zuge der Jahre mal gekauft wurde und nur für den Sommerwohnsitz ist in einer schicken DIN-A4-Kiste mit Aufdruck „Schlecker“ untergebracht (da war mal was ). Die Anwesenheit der Kiste stört meiner Chefin. So muss ich handeln, sonst Hausverbot .
Gefühlt habe ich die Hälfte der Threadseiten hier durch, finde aber nicht entscheidende Hinweise o. ä., um im Grunde nur eines zu wollen/haben (ich bilde mir ein das ein User genau das hier zum Thema gemacht hat):
Auf jedem Doku/Rechnung etc. steht fast 100%tig das Datum (egal ob Rechnungsdatum, Kaufdatum oder Bestelldatum). Dieses Datum reicht aus, dass das als Dateiname im dann abgelegten PDF drinsteht. Da ja da reichlich Jahre an Dokus vorhanden sind, will ich das gar nicht auf die Spitze treiben, Beispielsweise das die Dokus auch noch nach Jahreszahl wegsortiert werden. Da kann ich schnell händisch abarbeiten. Die meiste Arbeit ist eh den Stapel da zu scannen und eben einzusortieren. Danach geht es um vielleicht mal 10–15 Dokus jährlich. Über die Volltextsuche ist es ja dann relativ praktisch zu finden, was man sucht (immer in Abhängigkeit der „Suchwörter“).
Wie sollte/muss eine Regel aussehen, um das realisiert zu bekommen?
Kann mir da jemand ggf. den Stress der Chefin vom Hals nehmen?

 

[Struppix]

Hey Holger, schreib mal per PN was genau Du brauchst. Willst Du nur die Jahreszahlen aus dem Datum verwenden und dann Ordner anlegen und in diesen verschieben?

 

[geimist]

Das ginge auch ohne YAML.

• Einfach in der GUI als OCR-Rename Syntax §yocr-§mocr-§docr §tit (§tit kann auch weg, wenn man den Quelldateinamen nicht mit verwenden möchte). Stelle die Datumssuche auf "Python" für bestmögliche Ergebnisse.
• Über dem Feld OCR-Rename Syntax gibt es die Zielauswahl. Hier kannst du auch Jahresordner oder Jahr/Monat-Ordner wählen.
• Um nicht jedes Dokument einzeln zu scannen, verwende Trennblätter.

 

[wegomyway]

@geimist , bin deiner Kurzanleitung gefolgt ... wa soll ich schreiben ? Testdoku war auch von 2024, der Ordner wurde automatisch angelegt und besagtes Doku lag da drin mit korrektem erkannten Datum
Des Wegen die Spende Kaffee
Ich hatte vorher nämlich bereits alles eingerichtet, einmal in der GUI von synOCR und im Web vom 1700er, eben noch die 4te Schnelltaste angelegt und los ging es.
@Struppix, hast PN

 

[Struppix]

Dann antworte ich mal hier. Ja das geht über das GUI. Schon ewig übrigens ....

Der Vollständigkeit halber hier per YAML

Hier der Postscript Befehl, in die erste Regel des Regeblocks, der für eine zusammenhängende Benennung verwendet wird.

newtargetdir=$(echo "$(( ${date_yy} ))") && newtargetfile=$(echo "${NewName}") && mkdir -p "${output%/*}/${newtargetdir}" && filecount=$(find "${output%/*}/${newtargetdir}" -maxdepth 1 -type f -name "${newtargetfile}*.pdf" -printf '.' | wc -c) && if [ "${filecount}" -eq 0 ]; then mv "${output}" "${output%/*}/${newtargetdir}/${newtargetfile}.pdf"; else mv "${output}" "${output%/*}/${newtargetdir}/${newtargetfile} (${filecount}).pdf"; fi

Oder Ihr setzt diese Regel ganz nach oben Eurer YAML

rule_1001:
    tagname:
    targetfolder: /<EUER PFAD>/
    postscript: newtargetdir=$(echo "$(( ${date_yy} ))") && newtargetfile=$(echo "${NewName}") && mkdir -p "${output%/*}/${newtargetdir}" && filecount=$(find "${output%/*}/${newtargetdir}" -maxdepth 1 -type f -name "${newtargetfile}*.pdf" -printf '.' | wc -c) && if [ "${filecount}" -eq 0 ]; then mv "${output}" "${output%/*}/${newtargetdir}/${newtargetfile}.pdf"; else mv "${output}" "${output%/*}/${newtargetdir}/${newtargetfile} (${filecount}).pdf"; fi
    condition: all
    subrules:
    - searchstring: .
      searchtyp: contains

Karsten

 

[wegomyway]

Guten Morgen allerseits, nach einigen bereits gescannten Dokus leert sich die Kiste.

Die Leerseiten-Funktion arbeitet zuverlässig (nur in der GUI aktiviert, keine weiteren Einstellungen vorgenommen). Es kommt vor, das die eine oder andere Leerseite (wirklich zum Vernachlässigen) drin bleibt.
Erklärung: Gehst beim hiesigen Baumarkt kaufen, bekommst ’nen DIN-A4-Zettel und den Kassenbon der angetackert wird, einmal mittig quer und längst gefaltet und ab in irgendeine Tasche. Diese Knickstellen, wenn ausgeprägt, bilden sich hinten eben ab. Die sind dann halt so kräftig das diese leere Seite mit drin ist. ABER ist absolut selten!

Beim Erkennen vom Datum kommt es vor das die 2-stellige Jahreszahl auf einem Doku nicht erkannt wird und das Doku dann mit, beispielsweise, heutigem Datum abgelegt wird. DAS liegt aber eben an dem Erzeuger/Ersteller des Dokumentes. Auch das in geringer Anzahl. Wird einfach geändert und verschoben.
Die YAML geh’ ich heut noch an. Gestern einfach spät.