synOCR synOCR - GUI für OCRmyPDF

[geimist]

Deinem Log entnehme ich, dass es Probleme mit den neu genutzten Pythonbibliotheken auf der ARM-Architektur zu geben scheint. Das kann ich leider nicht selbst testen.

Kannst du mal bitte

• eine Sicherung von synOCR mit Hyperbackup machen
• synOCR deinstallieren
• die aktuelle Releaseversion 1.4.5 installieren
• die Einstellungen mit Hyperbackup wieder herstellen

Und dann bitte nochmal mit einer einzelnen Datei einen neuen Versuch starten.

 

[Georgey]

Hey Danke,
jetzt hat es geklappt, der erste Versuch mit einer PDF hat zwar über 25 min gebraucht, der 2. ging schon schneller ( nur 12min) das ist mal egal, ist aber aktuell leider nicht mit gewünschtem Erfolg als Dateinamen, aber auch da werd ich wohl ein wenig in den OCR Optionen herumprobieren müssen.

PS: die RAM Ausnutzung ging nie über 54%

Danke nochmal für die Freundliche Hilfestellung.

 

[geimist]

Schön zu hören.

… ist aber aktuell leider nicht mit gewünschtem Erfolg als Dateinamen, aber auch da werd ich wohl ein wenig in den OCR Optionen herumprobieren müssen.

Eher mit den (YAML) Regeln.
Bei konkreten Fragen wird dir hier gern geholfen.

Ich weiß nicht, ob wir die nötigen Pythonmodule auf ARM64 zum Laufen / installiert bekommen. Also bitte nicht blind das nächste Release installieren.

 

[Georgey]

Alles klar, dann weiß ich bescheid

 

[bismosa]

Hallo!
Ich bin neuling mit synOCR. Finde das total praktisch!
Allerdings habe ich gerade ein Problem, das ich noch nicht verstanden habe. Bestimmt ist das in den 238 Seiten hier bereits behandelt worden, ich konnte es aber leider nicht finden.
Ich nutze recht simple Einstellungen:
Quelle: /volume1/Scan/
Ziel: /volume1/Scan/PDF
Backup: /volume1/Scan/synOCR/_BACKUP

Den rest habe ich auf Standardeinstellungen belassen.

Wenn ich nun einen Scan habe, der nur aus einem Bild (ohne Text) besteht, wird die neue Datei in den Ordner _Backup geschoben. Das Verzeichnis PDF bleibt leer. Warum? So sieht es im Log einer solchen Datei aus:

●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●
CURRENT FILE:   ➜ 20201229_111228.pdf
                  temp. target file: /tmp/tmp.3E2qchM7sz/step1_tmp_1742208596/20201229_111228.pdf

  -----------------------------------------------------------------------------------
  | processing PDF @ OCRmyPDF:                                                      |
  -----------------------------------------------------------------------------------

                ➜ OCRmyPDF-LOG:
                  reading file from standard input
                      1 [tesseract] Too few characters. Skipping this page
                      1 [tesseract] Too few characters. Skipping this page
                      1 [tesseract] Error during processing.
                      1 page is facing ⇧, confidence 0.00 - no change
                  Postprocessing...
                  Optimize ratio: 1.00 savings: 0.0%
                  Output sent to stdout
                ← OCRmyPDF-LOG-END

                target file (OK): /tmp/tmp.3E2qchM7sz/step1_tmp_1742208596/20201229_111228.pdf


  -----------------------------------------------------------------------------------
  | document split handling:                                                        |
  -----------------------------------------------------------------------------------

                splitpage count: 0

                no separator sheet found, or number of pages too small

  -----------------------------------------------------------------------------------
  | handle source file:                                                             |
  -----------------------------------------------------------------------------------

                ➜ File name already exists! Add counter (3)

                ➜ backup source file to: /volume1/Scan/synOCR/_BACKUP/20201229_111228 (3).pdf
                removed directory '/tmp/tmp.3E2qchM7sz/step1_tmp_1742208596/'

Stats:
  runtime last file:              ➜ 00:00:17

●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●

Warum wird keine Zieldatei erstellt?

Gruß
Bismosa

 

[Struppix]

Hallo Bismosa,
willkommen im Forum. Du hast Im GUI einen Schalter "Bilder Konvertieren" osä.. hast Du diesen gesetzt ?

Karsten

 

[bismosa]

Nein, den habe ich nicht gesetzt.
Ich verstehe den auch so, das auch Bilddateien (also keine PDF) verarbeitet werden?
Bisher bleiben Bilddateien im Quellordner. Das ist auch so gewünscht.
Es kommt aber auch öfter vor, das ich etwas als PDF scanne, das keinen Text enthält...

 

[geimist]

Bitte lade mal ein vollständiges Log hoch.
Ggf. müssen wir dann mal auch auf das erweiterte Loglevel stellen.

 

[bismosa]

Hallo!
Ich habe mal mit meinem Benutzernamen ein vollständiges Debug-Log hochgeladen.
Irgendwie verhält sich das "merkwürdig". Jedes Mal schaffen es wohl unterschiedliche Dateien. Nehme ich diese einzeln in das Verzeichnis funktioniert es. Zumindest bei meinen Tests.
Vielen Dank für den Support!

 

[geimist]

Es ist wirklich seltsam, das in letzter Zeit ein Fehler auftritt, bei dem (wahrscheinlich) von OCRmyPDF beschädigte PDFs ausgegeben werden. Und das, obwohl das auch von dir verwendete Image schon über 3 Jahre alt ist und sonst prima funktioniert hat.

Da deine DS eine Intel CPU hat, kannst du mal bitte die aktuelle Beta installieren (einfach drüber installieren – die Einstellungen bleiben erhalten). Darin gibt es ein paar Verbesserungen und auch Sicherungen, falls mal ein Dokument nicht korrekt verarbeitet worden ist.

Und bitte gib mal Feedback.

PS: Das erweiterte Loglevel kannst du jetzt wieder ausschalten, damit das Logfile etwas lesbarer wird.

 

[bismosa]

Hallo!
Danke für die Bemühungen!
In der Beta funktioniert alles so wie gewünscht. Das Verzeichnis mit den 24 PDF-Dateien wurde komplett abgearbeitet und es sind auch 24 PDF im neuen Verzeichnis.

Kannst du das neue Log auch gebrauchen?

Gruß
Bismosa

 

[geimist]

Das freut mich!

Kannst du das neue Log auch gebrauchen?

Wenn alles erfolgreich ist, dann nicht

 

[Yippie]

Sag Mal Stephan, kann es sein, dass die neue Beta 1.4.99.10 auch in Sachen Performance im DSM zugelegt hat?
Der Wechsel der Profile und das Speichern von Änderungen ist auf einmal extrem schnell

Ich muss jetzt aber nochmals einhaken bezgl. des neuen YML Keys dirname_RegEx bzw. der neuen Pfad Variablen §dirname_RegEx:

Wenn ich bspw. mit dieser RegEx (?i)(Jahr.*\d{4}) das vierstellige Jahr aus meiner PDF extrahiere, dann kann ich dieses für den Ausgabe-Pfad verwenden. Soweit so klar.

Kann ich auch im Postscript auf §dirname_RegEx zurückgreifen, ala ${dirname_RegEx}?
Denn ich möchte (ohne eine zweite Regel bemühen zu müssen) mittels des Kommandos rsync die PDF aus dem Ausgabe-Pfad in ein Zielverzeichnis meiner Wahl ins Unterverzeichnis §dirname_RegEx verschieben.

Ich habe mit dem neuen Schlüssel bereits experimentiert und dabei folgendes in der YML-Datei verwendet:

WORK_001:
    tagname: §yocr4-§mocr-§docr Zuwendungen
    tagname_RegEx:
    multilineregex: false
    dirname_RegEx: (?i)(Jahr.*\d{4})
    targetfolder: "Work/"

Dabei wurde der targetfolder nun komplett ignoriert und die PDF stattdessen in ein neu erstelltes Verzeichnis Jahr_2024 gestellt.

Ich hätte jetzt tatsächlich erwartet, dass das PDF weiterhin ins Verzeichnis Work gespeichert wird und sonst erstmal nichts.

Ich hätte weiterhin erwartet, dass wenn ich targetfolder : "Work/§dirname_RegEx" verwendet hätte, dass ich die PDF im Ausgabeverzeichnis Work/Jahr_2024 gefunden hätte.

 

[geimist]

Sag Mal Stephan, kann es sein, dass die neue Beta 1.4.99.10 auch in Sachen Performance im DSM zugelegt hat?

Schön, wenn es bemerkt wird. Ja, ich konnte glücklicherweise etwas verbessern (habe ich aber noch nachträglich in die Version .10 hereingenommen ohne einen extra Build bereitzustellen (2025-03-15_22-55)_b1a4b58_BETA)

Kann ich auch im Postscript auf §dirname_RegEx zurückgreifen, ala ${dirname_RegEx}?

Im Skript enthält $dirname_RegEx den RegEx, nicht aber das Ergebnis. Das (letzte) Ergebnis ist in $dirname_RegEx_result gespeichert – allerdings nicht auf Pfadkompatibilität geprüft, wofür du selbst sorgen müsstest.

 

[Yippie]

Im Skript enthält $dirname_RegEx den RegEx, nicht aber das Ergebnis. Das (letzte) Ergebnis ist in $dirname_RegEx_result gespeichert – allerdings nicht auf Pfadkompatibilität geprüft, wofür du selbst sorgen müsstest.

DAS wollte ich hören/lesen

Denn ich verwende bereits tagname_RegEx_result und da kommt mir das analoge dirname_RegEX_result gerade recht

Trotzdem würde mich interessieren, dass wenn ich, wie geschrieben,

dirname_RegEx: (?i)(Jahr.*\d{4})

in der YML-Datei eingetragen habe, jedoch §dirname_RegEx nirgends verwendet, warum synOCR dann trotzdem ein Ausgabeverzeichnis mit dem RegEx-Ergebnis erstellt und die PDF dort speichert statt in targetFolder?

Ich mein, wenn ich bspw.

tagname_RegEx: (?i)(Jahr.*)\s*\K.*((19|20)\d{2})

auch nur Mal so in meiner YML (bspw. zu Doku) stehen habe, aber nirgends §tagname_RegEx verwende, dann wird ja auch nicht mein Dateiname plötzlich um den Inhalt dieses RegEx ergänzt.

Ich hätte hier analoges Verhalten bei dirname_RegEx erwarten.

 

[geimist]

OK, verstehe. Muss ich mir die nächsten Tage nochmal angucken.

 

[Yippie]

Perfekt und Merci für all die kürzlichen Verbesserungen und Erweiterungen.
V.a. der Geschwindigkeitszuwachs begeistert mich enorm

 

[geimist]

Dein Wohl hat mir keine Ruhe gelassen

Ich hatte mich bei dieser Variable analog an tagname_regex orientiert. Aber ich finde es auch wie von dir gewünscht besser.
Bitte probiere mal hiermit: synOCR_DSM7_local_BETA.spk

 

[Tommes]

V.a. der Geschwindigkeitszuwachs begeistert mich enorm

Der Geschwindigkeitszuwachs ist in der Tat enorm und hat mich auch ziemlich begeistert. @geimist war auch so freundlich und hat mir verraten, was genau er geändert hat. Wenn man weiß, wie es geht, ist das auch absolut logisch, aber darauf wäre ich im Leben nicht gekommen. Von daher „Chapeau“

 

[geimist]

aber darauf wäre ich im Leben nicht gekommen

Wenn du wie ich bei jeder Funktion die Zeit misst, wärst du genauso drauf gekommen