synOCR synOCR - GUI für OCRmyPDF

[geimist]

Seltsam. Mal neugestartet?

 

[Ansel]

Hallo, irgendwie ist heute der Wurm drin. Regel wird erkannt, aber nicht umgesetzt

Dazu ist mein erstelltes Profil bei jedem öffnen verändert.. Änderungen werden ignoriert.

Seltsam. Mal neugestartet?

Ja gerade nach Neustart nochmal probiert und läuft..

Was mir aber auffällt sind Datumsangaben die so in der Datei gar nicht vorhanden sind. Mit wieviel DPI sollte man scannen, um synOCR korrekt arbeiten zu lassen?

 

[geimist]

Ideal sind 300 DPI. Mehr machen es in der Regel nicht besser.
Ist das Loglevel auf 2 gestellt, dann wird auch ein Textauszug im Logordner abgelegt. Da siehst du, was den Regeln zur Verfügung steht.

 

[maxl-zwo]

Hallo Stephan,

herzlichen Dank für Deine schnelle Hilfe für meine Datei im DINA4-Querformat. Deine Lösung funktioniert perfekt! Ich dachte zunächst, ich muss ein eigenes Profil anlegen, aber es funktioniert im Standardprofil mit allen Scans, egal ob Hoch- oder Querformat.

Gruß, Dietrich

 

[HUHA]

Please update to synOCR version 1.5 and try again.

Thank you.
It worked with update to version 1.5 Now those files are processed and start to appear in OUTPUT folder.
Have a nice day geimist!

 

[geimist]

877 Downloads von Version 1.5 in einem Monat.

Ihr seid ganz schön fleißig

 

[guidovg]

Ich habe jetzt leider mehrere Dateien, die nach der Verarbeitung mit OCR nicht mehr lesbar sind. Aus dem Scanner landen sie aber korrekt im BACKUP Ordner. Ich habe Dir eine LOG Datei hochgeladen, brauchst Du auch die defekte PDF dazu? Ich wäre Dir @geimist sehr dankbar, wenn Du einmal darauf schauen magst.

Ich habe die Option "-f erneutes OCRen erzwingen" deaktiviert und wieder auf -s gesetzt. Damit konnte die Datei verarbeitet werden. Der Fehler bezgl. der Meta-Daten ist nun nicht mehr vorhanden und die Datei ist lesbar.

 

[geimist]

Es ist immer daselbe mit den beschädigten PDfs und ich habe noch keine Ahnung, wo das Problem liegt. Das fing dieses Jahr an (auch mit der Vorversion 1.4.5, die schon über ein Jahr alt ist). Ob das möglicherweise mit dem Update des Containermanagers zu tun hat? Irgendwie kann ich mir das aber auch nur schwer vorstellen. Es scheint, dass OCRmyPDF bereits die Dateien defekt ausgibt - aber auch mit alten Images.

Brauchst du unbedingt das Polyglot-Image? Wenn nicht, verwende mal bitte das Standardimage. Manchmal hilft das Wechseln des Image.

Und wenn du mir Beispieldateien bereitstellen könntest (sie werden vertraulich behandelt), wäre ich dir sehr dankbar. Wenn es geht, den RAW-Scan und die beschädigte Version. Vielen Dank.

 

[guidovg]

Ich habe auf das Standardimage gewechselt und die Option -f gesetzt. Der Fehler tritt wieder auf. Ich habe Dir die Datei die aus dem Scanner gekommen ist, die OCR-Variante und das LOG-File hochgeladen.

 

[geimist]

Wie kann es anders sein: bei mir läuft die Datei natürlich fehlerfrei durch
Ich habe dennoch mal das Filehandling von OCRmyPDF geändert. Bitte teste mal diese Version: synOCR_DSM7_local.spk

 

[Yippie]

Mag eine dumme Frage sein, aber ich glaube ich steh irgendwie auf dem Schlauch:

Ich habe zwei Profile (profile_a.yml, profile_b.yml) mit jeweils gleichen Eingabe- und Ausgabeverzeichnissen. Beide Profile sind aktiviert.

Ich schicke eine PDF an synOCR, welches eigentlich mit profile_b.yml verarbeitet werden soll. Tut es aber nicht. Im Log steht ausschließlich eine Verarbeitung durch profile_a und damit wird keine der Regel aus dem zweiten Profil durchlaufen.

Ich habe aus Gründen der Übersichtlichkeit mein zuvor sehr umfangreiches Einzelprofile in zwei kleinere gesplittet und gehofft, dadurch eine besserer Übersichtlichkeit zu bekommen. Aber entweder spucken mir hier die gleichen Ein-/Ausgabepfade in die Suppe oder irgendetwas anderes läuft akt. schief.

Weiß jemand Rat?

 

[geimist]

Klar. Alles, was zu Profil A passt wird verarbeitet und macht den Quellordner leer.
In dem Fall musst du mit Suchpräfix oder Suchsuffix arbeiten und dich daher schon beim Scannen für ein Profil entscheiden.

 

[Yippie]

Dacht ich's mir, da ist was faul Danke für den Hinweis!

 

[guidovg]

Wie kann es anders sein: bei mir läuft die Datei natürlich fehlerfrei durch
Ich habe dennoch mal das Filehandling von OCRmyPDF geändert. Bitte teste mal diese Version: synOCR_DSM7_local.spk

Ich habe die Einstellungen gelassen und das neue *.spk installiert. Im LOG-File gab es keinen Meta-Daten Fehler und die Datei ließ sich fehlerfrei öffnen. Besten Dank.

 

[geimist]

Das freut mich. Ich wäre so froh, wenn wir dieses üble Verhalten endlich abstellen könnten.

 

[Yippie]

Klar. Alles, was zu Profil A passt wird verarbeitet und macht den Quellordner leer.

Hab deine Antwort nochmals durchgelesen. Die besagte PDF passt aber nicht zu den Regeln von Profil A, sondern zu Profil B.

Bedeutet das trotzdem, dass nachdem keine Regel aus Profil A passt, die Verarbeitung trotzdem endet und so eine Art Fallback greift und daher niemals Profil B erreicht wird?

Ich frag nochmals anderes: Ich habe ja nur eine Quelle, einen Epson Scanner.
Dieser könnte zwar Prefixe an die Datei anfügen um das was du vorgeschlagen hast, zu erreichen, würde aber bedeuten, dass ich bereits auf dem Scanner zwei Scanprofile benötige, die jeweils ein anderes Prefix verwenden damit in synOCR eben entweder Profil A oder Profil B ausgeführt wird.

Das würde aber das ganze Handling verkomplizieren, denn ich müsste am Scanner das Profil auswählen welches den Regeln des jeweiligen Profils entspricht.

 

[geimist]

Hab deine Antwort nochmals durchgelesen. Die besagte PDF passt aber nicht zu den Regeln von Profil A, sondern zu Profil B.

Es ist nicht die Frage, ob die Regeln greifen, sondern ob der INPUT-Filter greift und somit das Profil getriggert wird. Wenn ja, wird immer in den Zielordner abgearbeitet – und wenn keine Regel greift, halt ohne Sortierung und Umbenennung.

 

[Struppix]

Das würde aber das ganze Handling verkomplizieren, denn ich müsste am Scanner das Profil auswählen welches den Regeln des jeweiligen Profils entspricht

Hallo,

wie ich schon mal beschrieben hatte, braucht jedes Profil einen eigenen Input Ordner. Was Du brauchst, und was ich ja schon länger nutze, ist ein vorgestelltes Profil, welches die Jobs vor sortiert und in die jeweiligen Profile verteilt. Ich nutze dafür insgesamt nur 5 Regeln in diesem Profil, um diese dann in die richtigen (bei Dir A und B) Profile zu verschieben. Im ersten Profil wird auch der Text Layer erzeugt, den man sich dann in den "Hauptprofilen" sparen kann, und hier hinein wird auch gescannt. Also nur ein Profil am Scanner.
Man kann dieses Prinzip beliebig ausbauen, was wirklich toll ist.
Im Übrigen schöner Nebeneffekt. Nicht funktionierende Dokumente, werden zumeist im ersten Profil aussortiert und im dortigen Error File abgelegt. Hier nutze ich dann mein Script um darüber auf dem Laufenden zu bleiben

Karsten

 

[Yippie]

Danke @Struppix für den Reminder, war mir tatsächlich entfallen und ich hab mir auch schon sowas in Gedanken zurecht gelegt.

Als mit anderen Worten: Ein Verschiebprofil welches in verschiedene Eingabeverzeichnisse (Eingabe1 -EingabeX) verteilt.

Die jeweiligen nachgelagerten Profile sind auf Eingabe1 bis EingabeX festgelegt und laufen dann eben im Nachgang durch.

Klingt für mich erstmal logisch, nur würde dies bedeuten, dass das erste Verschiebeprofil zunächst eine Gesamtheit aller Regeln der nachgelagerten Profile enthalten muss.

Ich versuchs Mal zu skizzieren:
Verschiebeprofil
Regel1, erkennt Dokument 1 -> Verschiebt nach Eingabe1
Regel2, erkennt Dokument 2 -> Verschiebt nach Eingabe1
Regel3, erkennt Dokument 3 -> Verschiebt nach Eingabe1

Regel4, erkennt Dokument 4 -> Verschiebt nach Eingabe2
Regel5, erkennt Dokument 5 -> Verschiebt nach Eingabe2
usw.

ProfilA, verarbeitet Verzeichnis Eingabe1
Regel1, Dokument1 wird verarbeitet und ins Zielverzeichnis 1 verschoben
Regel2, Dokument2 wird verarbeitet und ins Zielverzeichnis 2 verschoben
Regel3, Dokument3 wird verarbeitet und ins Zielverzeichnis 3 verschoben

ProfilB, verarbeitet Verzeichnis Eingabe2
Regel1, Dokument4 wird verarbeitet und ins Zielverzeichnis 4 verschoben
Regel2, Dokument5 wird verarbeitet und ins Zielverzeichnis 5 verschoben

Korrekt bisher?

Dies bedeutet doch dass sowohl das Verschiebeprofil alle Regeln aus ProfilA und ProfilB enthalten muss. Zumindest zur groben Sortierung, Regeln mit abgespeckten Bedingungen.
Die eigentliche Feinsortierung inkl. Benamung der Dateien findet in ProfilA bzw. ProfilB statt.

Wenn dem so ist, dann ist dieser Prozess abrr mit etwss mehr Aufwand verbunden, denn bei neu zu erkennenden PDFs muss ich ja in mindestens zwei Profilen pflegen: Immer im Verschiebeprofil und in einem weiteren.

OK, die Flexibilität und die Übersichtlichkeit der Regeln in den jeweiligen YAML Dateien steigt jedoch.

 

[Struppix]

Wie gesagt, ich benötige nur 5 Regeln zur Aufsplittung der Einzel Profile.
Es ist halt abzuwägen, wie man die Profile abgrenzt, und ob es einen Mehrwert bringt.