synOCR synOCR - GUI für OCRmyPDF

FoxageX

Benutzer
Mitglied seit
09. Jul 2021
Beiträge
20
Punkte für Reaktionen
2
Punkte
3
Hallo Stephan,

vielen Dank für den Hinweis.

Meine Frage ging genau in die von dir angesprochene Richtung, wie ich die Syntax frei ändern kann, also z. B. mit zweisteller Jahreszahl.

Dies ist über die GUI, so wie ich dich verstehe, derzeit allerdings nicht möglich.

Sofern es zukünftig möglich sein sollte, freue ich mich natürlich über die Flexibilität.

Besten Gruß!
 

FoxageX

Benutzer
Mitglied seit
09. Jul 2021
Beiträge
20
Punkte für Reaktionen
2
Punkte
3
Hallo Stephan,

eben gestestet - funktioniert wie gewollt. Wunderbar!

Viele User werden ja sicherlich die existierenden Parameter §yocr verwenden. Vielleicht sollte dies der 4-stellige Standard bleiben und der davon abweichende Parameter §yocr2 kann für die 2-stellige Datumsangabe genutzt werden. Oder man müsste es im Changelog explizit hervorheben, dass der Parameter entsprechend angepasst werden muss. Alternativ könnte die Syntax automatisch von §yocr zu §yocr4 beim Update geändert werden.

In jedem Falle danke ich dir für die sehr schnelle Umsetzung meiner Anforderung.

Besten Gruß!
 

geimist

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
04. Jan 2012
Beiträge
5.385
Punkte für Reaktionen
1.199
Punkte
234
Ich hatte das Ganze jetzt nicht getestet, aber weil bei so einer Sache keine Anpassung der GUI und DB notwendig sind und auch sonst keine großen Nebenwirkungen zu erwarten sind, konnte ich das mal auf die Schnelle einbauen. Freut mich, dass es wie gewünscht funktioniert.

Vielleicht sollte dies der 4-stellige Standard bleiben und der davon abweichende Parameter §yocr2 kann für die 2-stellige Datumsangabe genutzt werden.
So habe ich es eigentlich eingebaut. Alte Parameter sollten wie gewohnt den 4-stelligen Wert zugewiesen bekommen.
(§yocr2 und §yocr4 und das Gleiche für die anderen Jahresangaben wurden hinzugefügt - die bisherigen bleiben aber gültig).

War dein Gedanke nur prophylaktisch, oder hatte das nicht funktioniert?
 

FoxageX

Benutzer
Mitglied seit
09. Jul 2021
Beiträge
20
Punkte für Reaktionen
2
Punkte
3
Der Gedankengang war rein prophylaktisch. Ich hatte das eben auch noch einmal mit den bisherigen Parametern getestet. Ohne den Zusatz 2 oder 4 wird also stets der Standard (4-stellig) ausgegeben. Das klappt also.

Eventuell könnte dies im Infotext für damit nicht vertraute Augen noch transparenter dargestellt werden:

Entweder so:

§yocr2 (Datum / Jahr - im Text gefunden (zwei-stellig))
§yocr4 (Datum / Jahr - im Text gefunden (vier-stellig))
§yocr (Datum / Jahr - im Text gefunden (vier-stellig))

Oder man lässt den Paramter §yocr4 ganz weg (nach dem Motto: keep it simple) und macht es so:

§yocr (Datum / Jahr - im Text gefunden (vier-stellig))
§yocr2 (Datum / Jahr - im Text gefunden (zwei-stellig))

Vielleicht haben aber auch noch andere User einen passenden Hinweis dazu.

Besten Gruß!





 

geimist

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
04. Jan 2012
Beiträge
5.385
Punkte für Reaktionen
1.199
Punkte
234
Ich hatte es bewusst weggelassen. Alte Parameter sind für die Kompatibilität wichtig, müssen aber aus meiner Sicht nicht dokumentiert werden. Wer wissen möchte, welchen Parameter er nutzen muss, findet die entsprechende Info. Ich habe mich aber auch für eine klare Abgrenzung für einen zusätzlichen Parameter mit einer 4 entschieden. Ich denke, das ist verständlicher.

Freut mich, dass das auch wie gewünscht funktioniert.
 

Tom1000

Benutzer
Mitglied seit
01. Jul 2021
Beiträge
21
Punkte für Reaktionen
3
Punkte
3
Das steht schon auf der Liste (so rein theoretisch … :rolleyes:).

Wahrscheinlich ließe sich das mit den in OCRmyPDF integrierten Tools relativ leicht realisieren. Die automatische Umsetzung in der Praxis finde ich dann schon schwieriger:
  • Sollen immer alle Dokumente im Eingangsordner zusammengefasst werden?
  • Soll man sich generell über einen Schalter in der GUI für eine Variante entscheiden müssen?
  • Soll das nur bei einer bestimmten Benennung greifen?
So kompliziert würde ich es im ersten Schritt gar nicht machen.

Wenn ich einen dicken Stapel scanne, weiss ich, dass da eine ganze Zahl an Einzeldateien im Eingangsordner liegt. Dann muss ich als User eben aufpassen, dass der Eingangsordner NUR mit den Teildateien belegt ist. Wenn ich dann starte, würde er alles, was im Eingangsordner ist zusammenfassen.

Also ein bisschen Eigenarbeit wäre zumutbar, da dieses Szenario nun auch nicht so häufig vorkommen sollte...
 

guidovg

Benutzer
Mitglied seit
26. Nov 2011
Beiträge
129
Punkte für Reaktionen
39
Punkte
34
Ich verstehe die Anforderung mit dem Zusammenfassen noch nicht so richtig. Ich scanne aktuell alles was pro Tag ins Haus kommt mit dem Scanner ein. Briefe, Rechnungen, Mitteilungen der Schule etc. Die sollen auf jeden Fall NICHT zusammengefasst werden. Ich denke, dass das Zusammenfassen eher ein Sonderfall ist und einen Schalter oder einen weiteren Workflow erfordern sollte. Oder habe ich da etwas falsch verstanden?
 

geimist

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
04. Jan 2012
Beiträge
5.385
Punkte für Reaktionen
1.199
Punkte
234
So sehe ich das auch. Ich könnte mir vorstellen, einen Ordner "merge" oder ähnlich zu verwenden. Alles was darin ist, soll zusammengestellt werden.
 
  • Like
Reaktionen: guidovg

s-tyle

Benutzer
Mitglied seit
30. Nov 2020
Beiträge
28
Punkte für Reaktionen
3
Punkte
3
Hallo zusammen, ich muss leider auch noch einmal nerven...
ich hole ein kleines bißchen aus, um möglichst ins Szenario zu holen und die ersten vier Rückfragen, damit man das nachvollziehen kann direkt zu erledigen.

Ich habe mich eigentlich sehr gut mit dem ganzen System eingelebt:
-> brother Multifunkti-Gerät scant pdf auf Fritz-Box Speicher (weil 24/7 verfügbar)
-> DS720+ schaut wenn sie läuft auf dem Fritz-Speicher mit Aufgabenplaner-Skript regelmäßig nach neuen Dateien und schiebt diese in den OCR-Einrang
-> synOCR schaut wenn die DS läuft mit Aufgabenplaner-Skript regelmäßig und verarbeitet Eingang zu Ausgang incl. Tagging
=> Drehung von Querformat habe ich mal als Thema gehabt, bin da aber nicht so richtig zu Rande gekommen, da sehr seltene Anwendungsfälle habe ich da aber auch wenig Leidenschaft reingelegt...
Soweit, so gut! ??

Jetzt wollte ich den "nächsten Schritt" im Kampf dem Papier machen und habe einen Dokumentenscanner gekauft. Der Plan war eigentlich recht einfach: schlicht vorne den Scanvorgang "austauschen", danach weiter verarbeiten wie bisher... Auf diese Weise sollten auch die Ordner mit Unterlagen aus Seminaren usw. aus dem Regal verschwinden, der Scanner schafft sich seinen Standplatz sozusagen selber ;-)

Wenn es einfach wäre, könnte es ja jeder...das Gerät ist eingerichtet, es Scannt auch PDF an die Fritz Box. Das Abhol-Skript holt diese PDF auch in den SRC-Ordner. Die Dateien haben aber nun einen anderen Präfix im Quelldateinamen. Den alten Scanner gibt es aber weiter, schon alleine, weil Bücher schlecht durch einen ADF passen... Ich habe nicht gefunden, ob man auch mehrere Präfixe im entsrechenden synOCR-Feld eingeben kann und deshalb das Profil geklont und dann den Präfix geändert. Das hat auch funktioniert, die DokScanner PDF sind verarbeitet worden und lagen im Ausgabeordner. (Altes Gerät in dieser Zeit nicht verwendet.)
Der zweite Seminar-Ordner war dann aber -tadaaa- fast ausschließlich im Querformat. Da waren Sie wieder meine alten Probleme. Ich habe dann hier nochmal durchgeschaut und versucht, dem Herr zu werden, letztlich hat
Code:
-srd -l deu --rotate-pages --rotate-pages-threshold 1
durchaus zu einer Rotation der Seiten geführt (ich habe mehrere Werte ausprobiert, 2 / 1 / 0.8 / 0.5 / 0.1).

Als zweites habe ich verschiedene Quell-Qualitäten ausprobiert (immer 300dpi, 200 war mir zu grob, aber dann mal s/w, mal Graustufen) um mit Dateigrößen und OCR-Qualität zu schauen (Textboxen in Graphiken usw.).

Ich kann leider nicht sagen warum, aber es tut sich nun einfach nichts mehr. synOCR arbeitet schlicht nicht mehr. Die Dateien kommen in den Quellordner, in Übersicht/Status werden auch entsprechend Dateien zu bearbeiten angezeigt, aber ein Aufgabenplaner-Durchlauf nach Timer, über "Ausführen" oder in synOCR selbst ein manueller Start führen nicht mehr zur Verarbeitung. Ich habe dann zur Probe mal in den alten Scanner gelegt, auch diese Datei wird nicht verarbeitet. DS Neustart (zweimal) ebenfalls ohne Veränderung.

Die Log-Datei schmeisst dazu folgendes, mit dem Profil vom neuen Scanner:
Code:
----------------------------------
    |    ==> Funktionsaufrufe <==    |
    ----------------------------------
ERROR at line 1241: pagecount_new=$(( $(get_key_value ./etc/counter pagecount) + $pagecount_latest))
ERROR at line 1242: ocrcount_new=$(( $(get_key_value ./etc/counter ocrcount) + 1))
ERROR at line 1243: pagecount_ID_new=$(( $(get_key_value ./etc/counter pagecount_ID${profile_ID}) + $pagecount_latest))
ERROR at line 1244: ocrcount_ID_new=$(( $(get_key_value ./etc/counter ocrcount_ID${profile_ID}) + 1))

PROCESSING:   ? ADS-2800W_20210815_002991.pdf (Sun Aug 15 14:04:08 CEST 2021)
                  temp. target file: /tmp/tmp.nAUgOUhcYw/20210815_002991.pdf

              ? OCRmyPDF-LOG:
               WARNING: The requested image's platform (linux/arm64) does not match the detected host platform (linux/amd64) and no specific platform was requested
               standard_init_linux.go:230: exec user process caused: exec format error
              ? OCRmyPDF-LOG-END

                  ?? failed! (target file is empty or not available)


    -----------------------------------
    |       ==> synOCR ENDE <==       |
    -----------------------------------

Und mit dem Profil vom alten Scanner:
Code:
    ----------------------------------
    |    ==> Funktionsaufrufe <==    |
    ----------------------------------
ERROR at line 1241: pagecount_new=$(( $(get_key_value ./etc/counter pagecount) + $pagecount_latest))
ERROR at line 1242: ocrcount_new=$(( $(get_key_value ./etc/counter ocrcount) + 1))
ERROR at line 1243: pagecount_ID_new=$(( $(get_key_value ./etc/counter pagecount_ID${profile_ID}) + $pagecount_latest))
ERROR at line 1244: ocrcount_ID_new=$(( $(get_key_value ./etc/counter ocrcount_ID${profile_ID}) + 1))

PROCESSING:   ? MFC-5895CW_003799.pdf (Sun Aug 15 14:06:02 CEST 2021)
                  temp. target file: /tmp/tmp.jyEEza1UjD/003799.pdf

              ? OCRmyPDF-LOG:
               WARNING: The requested image's platform (linux/arm64) does not match the detected host platform (linux/amd64) and no specific platform was requested
               standard_init_linux.go:230: exec user process caused: exec format error
              ? OCRmyPDF-LOG-END

                  ?? failed! (target file is empty or not available)


    -----------------------------------
    |       ==> synOCR ENDE <==       |
    -----------------------------------

Ich sehe da nur Abweichung bzgl. Platform (arm64 vs. amd64), wüsste aber nicht, wo ich da etwas verändert haben sollte...
Habt Ihr hier das Problem bereits einmal gehabt oder kennt trotzdem eine Lösung?
 

geimist

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
04. Jan 2012
Beiträge
5.385
Punkte für Reaktionen
1.199
Punkte
234
SORRY :(

Für die Verwirrung bin ich verantwortlich - ich bastel gerade am ocrmypdf-polyglot Image für arm64 und dieses hat das Image für amd64 überschrieben. Bitte lösche einfach das entsprechende Image in der Dockergui. Beim nächsten Run wird wieder das korrekte Image gezogen.

btw:
Wer weiß, wie man ein Image auf unterschiedlichen Architekturen baut und beim Push in den Docker Hub entsprechend tagt damit ein bestehendes Image für eine andere Architektur nicht überschrieben wird?
(amd64 baue ich auf der DS / arm64 in einem UTM virtualisierten Debian auf dem Mac)
 
Zuletzt bearbeitet:
  • Like
Reaktionen: s-tyle

s-tyle

Benutzer
Mitglied seit
30. Nov 2020
Beiträge
28
Punkte für Reaktionen
3
Punkte
3
...Bitte lösche einfach das entsprechende Image in der Dockergui. Beim nächsten Run wird wieder das korrekte Image gezogen....
Und genau so geht es nun auch wieder :cool:(y).

Kannst Du mir evtl. noch verraten, wie ich zwei unterschiedliche Quelldatei Präfixe in ein Profil bekomme? Oder geht das tatsächlich so nicht?
 

geimist

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
04. Jan 2012
Beiträge
5.385
Punkte für Reaktionen
1.199
Punkte
234
Dein Weg mit den 2 Profilen war doch goldrichtig (man kann nur EIN Präfix je Profil angeben).
Alternativ die Frage: Brauchst du unbedingt den Präfix? Wenn eh alle PDFs mit dem gleichen Profil abgearbeitet werden sollen, dann kannst du auch ganz auf die Präfixerkennung verzichten.
Genauso bei der Seitenorientierung:
Solltest du eh alles in der richtigen Ausrichtung scannen, dann kannst du auf den Parameter r, bzw. --rotate-pages --rotate-pages-threshold n ganz verzichten.
 

s-tyle

Benutzer
Mitglied seit
30. Nov 2020
Beiträge
28
Punkte für Reaktionen
3
Punkte
3
Dann habe ich das zumindest nicht übersehen (ein ; hatte nicht geholfen und dann hab ich mir einfach so beholfen, später aber gemerkt, dass ich nun z.B. bei der Rotations-Geschichte die Einstellungen immer in zwei Profile übernehmen muss...
Wenn eh alle PDFs mit dem gleichen Profil abgearbeitet werden sollen, dann kannst du auch ganz auf die Präfixerkennung verzichten.
Das ist in der Tat ein Gedanke... Der MuFu verpasst dem Dateinamen in jedem Fall ein Präfix. Ich lasse das dadurch ja auch entfernen, der DokSanner hat ein anpassbares Präfix (Da kommt mir gerade: vielleicht sollte ich das einfach auf den MuFu Präfix anpassen :unsure:).
Solltest du eh alles in der richtigen Ausrichtung scannen, dann kannst du auf den Parameter r, bzw. --rotate-pages --rotate-pages-threshold n ganz verzichten.
Ich scanne das Dokument immer im Hochformat, das ist quasi technisch bedingt durch die Scanner. In einzelnen, wenigen Dokumenten ist das sogar im Dokument gemischt, ich möchte also eigentlich genau nicht auf die Funktion verzichten. Der Wert 1 hat bei den letzten die noch kamen aber durchaus passende Ergebnisse mit gemischter Ausrichtung innerhalb eines Dokumentes gebracht, das sollte nu so also auch passen.
Einmal für mein (Tuning-)Verständnis bitte: Je größer der Wert, desto höher die Hemmschwelle zur Drehung, also desto weniger gedreht, richtig? Wie ist denn da der gültige Wertebereich? Und worauf wendet er die Schwelle an, sprich was sind "Drehkriterien"?
 

geimist

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
04. Jan 2012
Beiträge
5.385
Punkte für Reaktionen
1.199
Punkte
234
Einmal für mein (Tuning-)Verständnis bitte: Je größer der Wert, desto höher die Hemmschwelle zur Drehung, also desto weniger gedreht, richtig? Wie ist denn da der gültige Wertebereich? Und worauf wendet er die Schwelle an, sprich was sind "Drehkriterien"?
Ich kann dich da auch nur an die Hilfe von OCRmyPDF verweisen: https://ocrmypdf.readthedocs.io/en/latest/cookbook.html#correct-page-rotation

Das Thema gab u.a. auch schon mal hier #981

Der MuFu verpasst dem Dateinamen in jedem Fall ein Präfix. Ich lasse das dadurch ja auch entfernen, der DokSanner hat ein anpassbares Präfix (Da kommt mir gerade: vielleicht sollte ich das einfach auf den MuFu Präfix anpassen :unsure:)
Richtig!
 

FoxageX

Benutzer
Mitglied seit
09. Jul 2021
Beiträge
20
Punkte für Reaktionen
2
Punkte
3
Hallo zusammen,

ich möchte die Rotation von Seiten kurz aufgreifen, um auf ein Thema zu sprechen kommen, welches mich schon etwas länger beschäftigt.

Sofern die Seitenausrichtung nicht korrekt durchgeführt wird (kommt ja mal vor bei einigen Seiten) und das Dokument somit nicht in der richtigen Ausrichtung vorliegt, ist die OCR entsprechend kryptisch und nicht zu gebrauchen (es kommt halt nur Kaudawelsch heraus).

Nun kann man manuell mit einem vorhandenen Programm (ich nutze Power PDF) die OCR seitenweise durchführen. Zuvor muss man die falsch rotierten (oder nicht rotierten) Seiten entsprechend korrekt ausrichten.

Hat hier jemand Automatisierungsmöglichkeiten erkannt, die ich nicht sehe?
 

s-tyle

Benutzer
Mitglied seit
30. Nov 2020
Beiträge
28
Punkte für Reaktionen
3
Punkte
3
Ich habe hier auch noch interessante Ergebnisse bei der Rotation, aktuell hat er auf kariertem Papier geschriebene Notizen nach dem scannen schlicht zu 80% auf den Kopf gedreht...
Ich glaube, dass das Thema Rotation mit langwierigem Feintuning an einem Dokument beim nächsten ohnehin schon wieder nicht 100% passt, würde da also eher einen "90% Erreichungsgrad" bei der Rotation anstreben, da alles andere und sehr viel Zeit kosten wird.
Hat hier jemand Automatisierungsmöglichkeiten erkannt, die ich nicht sehe?
meine 2ct:
Ich fände sinnvoll, wenn dann bei Fehlern eine manuelle Rotation einzelner Seiten erfolgen kann. Ich weiß nicht, ob es hier etwas gibt, dass "auf Synology" läuft oder schlicht auf dem jeweiligen System laufen muss. (Ich habe in der früheren Vergangenheit sowas mit pdfsam (https://pdfsam.org/de/download-pdfsam-basic/) gemacht, die Basic Version ist kostenlos und für nahezu alle Plattformen erhältlich.
Im zweiten Gang würde ich vielleicht einen zweiten Eingangsordner anlegen und mit einem weiteren Profil, dass neuOCR erzwingt stumpf synOCR bzw. OCRmyPDF seine Arbeit an der Korrekturgerichteten Datei nochmal machen lassen.

So hat man bei einzelnen fehlerhaften Seiten das vermutlich relativ schnell behoben, Datei direkt bei der ersten falschen Seite im PDF-Editor öffnen und von diesem aus direkt in den reOCR Ordner speichern, am Rest ist dann nichts mehr neues zu tun, das sollte dann seinen gewohnten Weg wieder gehen. Oder denke ich noch was falsch?
 

s-tyle

Benutzer
Mitglied seit
30. Nov 2020
Beiträge
28
Punkte für Reaktionen
3
Punkte
3
Noch zwei kurze Ergänzungen vom Direkt-Selbstversuch:
ich habe PDFsam mit mehr Voransicht in Erinnerung, etwa wie hier: https://pdfsam.org/de/pdfsam-visual/#rotate-pdf
Vermutlich ist der Zahn der Zeit dazu gekommen, dass das nun nicht mehr Basis-Version ist, sondern kostet.
Mit der Basis-Version geht es aber auch, ohne Seitenvorschau, hier kann man "einfach" die zu drehenden Seitezahlen bzw. -bereiche angeben, das Ergebnis ist dann das gleiche. Schön ist, dass man dem auch direkt einen entsprechenden Ausgabeordner beibringen kann und so direkt ins reOCR Verzeichnis spült ohne noch Dateien per Hand zu schubsen.
Wenn hier noch jemand was besseres weiß, gerne für Win/Mac/Linux verfügbar und am liebsten OpenSource, immer her damit!:geek:

Ich habe jetzt mal ein zweites Profil angelegt, als OCR-Optionen ist jetzt -l deu --redo-ocr und als OCR-Rename Syntax $tit eingetragen. Das scheint soweit zu klappen, als dass er eine einmal benannten und ggf. korriegierten/ergänzten Dateinamen nicht wieder neu zusammensetzt und jetzt auch die Seiten, die vorher falsch ausgerichtet und Kauderwelsch erkannt waren jetzt stimmen. :giggle: Aaaber: er überschreibt die alte "File.pdf" nicht, sondern macht eine "File (1).pdf" draus. Gibts hier noch einen Steuercode zu?
 

geimist

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
04. Jan 2012
Beiträge
5.385
Punkte für Reaktionen
1.199
Punkte
234
er überschreibt die alte "File.pdf" nicht, sondern macht eine "File (1).pdf" draus. Gibts hier noch einen Steuercode zu?
Für den Anwendungsfall eines (automatisch) forcierten Überschreibens gab es bisher keine Notwendigkeit - also nein …
 

DanielWW

Benutzer
Mitglied seit
07. Jan 2019
Beiträge
16
Punkte für Reaktionen
1
Punkte
3
Hallo,
im Zuge des Uprades auf DSM 7.0 hat synOCR zunächst nicht funktioniert. Bei dem Versuch den Fehler zu beheben, habe ich es geschafft synOCR zu entfernen und anschließend neu zu installieren. - Das war nicht so geschickt.

Die Software läuft jetzt, aber ich habe alle meine (umfangreichen) Einstellungen verloren.
Ich verfüge über ein vollständiges NAS-Backup. Besteht die Möglichkeit die synOCR Konfiguration aus einem Backup wiederherzustellen?

Vielen Dank für Eure Hilfe und viele Grüße - Daniel
 


 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat