synOCR synOCR - GUI für OCRmyPDF

geimist

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
04. Jan 2012
Beiträge
5.567
Punkte für Reaktionen
1.391
Punkte
234
Das musst du probieren. Wenn der Stempeltext von der OCR gut erkannt wird, sollte das funktionieren. Ich würde einen Text wählen, der möglichst wenig zweideutige Zeichen enthält (B-8, l-I [L/i], 0-O, ect.)
 
Zuletzt bearbeitet:

Wahl-HHer

Benutzer
Mitglied seit
13. Aug 2020
Beiträge
29
Punkte für Reaktionen
7
Punkte
3
Aber mit dem Feld zum Ankreuzen wird es schwierig, oder? Hast du schonmal versucht herauszufinden warum die Dokumente nicht richtig erkannt werden?
Bei meinen Versicherungsunterlagen lag es z.B. oft daran, dass die Versicherungsscheinnummer mal in einem Format (1.234.567.89) und mal in nem anderen Format (123456789) drauf standen. Das gleiche mit SteuerID und Sozialversicherungsnummer.
Ich habe dann die verschiedenen Formate jeweils als Suchstring eingetragen und seit dem klappt die Zuordnung sehr gut.
 

lil-ac

Benutzer
Mitglied seit
14. Feb 2013
Beiträge
39
Punkte für Reaktionen
0
Punkte
6
Er trägt mir zu viele Tags ein. Sprich bei den Lohnunterlagen „Rechnung, Versicherung, Arbeit und Steuer“
 

Wahl-HHer

Benutzer
Mitglied seit
13. Aug 2020
Beiträge
29
Punkte für Reaktionen
7
Punkte
3
Also werden alle Begriffe erkannt, nur zu viele in einem Dokument. ;) "Rechnung" bei Lohnunterlagen wahrscheinlich wegen "Gehaltsabrechnung" oder so im Dokument, richtig? Das kannst du verhindern, indem du "§Rechnung" als Suchbegriff angibst. Wenn du mit einer YAML-Datei arbeitest dann "searchtyp: is" ,dann wird genau das Wort Rechung, aber nicht Gehaltsabrechnung gefunden.
 

lil-ac

Benutzer
Mitglied seit
14. Feb 2013
Beiträge
39
Punkte für Reaktionen
0
Punkte
6
Mit der YAML Datei habe ich mich noch nicht befasst. Muss ich mal die Tage schauen
 

geimist

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
04. Jan 2012
Beiträge
5.567
Punkte für Reaktionen
1.391
Punkte
234

Wahl-HHer

Benutzer
Mitglied seit
13. Aug 2020
Beiträge
29
Punkte für Reaktionen
7
Punkte
3
Ja, bezog sich auf die Idee mit dem Stempel mit einem Feld zum Ankreuzen.
 

lil-ac

Benutzer
Mitglied seit
14. Feb 2013
Beiträge
39
Punkte für Reaktionen
0
Punkte
6
Guten Morgen zusammen,

nun habe ich mir die YAML Datei mal angeschaut und erst klappte es wunderbar, doch dann bekam ich folgende Fehlermeldung:
-----------------------------------
| ==> installation info <== |
-----------------------------------

synOCR-user: root
synOCR-user is admin: no
synOCR-version: 1.1.902
Architecture: x86_64
DSM-build: 41890
Device: 920plus (3647395103)
current Profil: default
DB-version: 4
used image (created): geimist/ocrmypdf-polyglot:latest (2021-08-31T10:33:24)
used ocr-parameter: -srd -l deu
replace search prefix: yes
renaming syntax: §y-§m-§d_§tag_§tit
Symbol for tag marking:
Document split pattern:
source for filedate: ocr
ignored dates by search: 2021-02-29;2020-11-31
Docker Test: OK
Loglevel: normal
Application Directory: /usr/syno/synoman/webman/3rdparty/synOCR
Source directory: /volume1/Dokumente Scan/INPUT/
Target directory: /volume1/Dokumente - Tausch/OCR Scan Output/
BackUp directory: /volume1/Dokumente Scan/BACKUP/


----------------------------------
| ==> Funktionsaufrufe <== |
----------------------------------
? update image [geimist/ocrmypdf-polyglot:latest] ? image is up to date

PROCESSING: ? Nebenkostenabrechnung 2020.pdf (Tue Sep 7 00:00:05 CEST 2021)
temp. target file: /tmp/tmp.ngb6RqE68K/Nebenkostenabrechnung 2020.pdf

? OCRmyPDF-LOG:
reading file from standard input
Start processing 4 pages concurrently
3 skipping all processing on this page
1 skipping all processing on this page
4 skipping all processing on this page
5 skipping all processing on this page
6 skipping all processing on this page
2 [tesseract] Too few characters. Skipping this page
2 [tesseract] Too few characters. Skipping this page
2 [tesseract] Error during processing.
2 with existing rotation ?, page is facing ?, confidence 0.00 - no change
2 [tesseract] Empty page!!
2 [tesseract] Empty page!!
Postprocessing...
Optimize ratio: 1.00 savings: -0.1%
Image optimization did not improve the file - discarded
Output sent to stdout
? OCRmyPDF-LOG-END

target file (OK):
? search tags and date:
source for tags is yaml based tag rule file [/volume1/Dokumente Scan/INPUT/_TagConfig_[profile_default].txt]
validate the integrity of yaml-file:
ERROR at line 603: yamlcheck=$(yq v "${taglist}" 2>&1)
ERROR-Message: Error: yaml: line 223: found a tab character that violates indentation
ERROR at line 603: yq v "${taglist}" 2>&1
-----------------------------------
| synOCR exit with ERROR! |
-----------------------------------

Was mache ich falsch?
Vielen Dank schon mal.
 

geimist

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
04. Jan 2012
Beiträge
5.567
Punkte für Reaktionen
1.391
Punkte
234
ERROR-Message: Error: yaml: line 223: found a tab character that violates indentation
Wahrscheinlich hast du anstelle von Leerzeichen einen Tabulator eingesetzt.
Die YAML-Syntax basiert auf korrekt eingesetzte Leerzeichen.

Bitte überprüfe das mal.
 

Wahl-HHer

Benutzer
Mitglied seit
13. Aug 2020
Beiträge
29
Punkte für Reaktionen
7
Punkte
3
In deinem Logsteht zwar in Zeile 603, aber bei mir war es dann immer in der Zeile darunter. ;)
Meist nachdem ich die Datei mit notepad++ bearbeitet hatte. Dabei hat notepad++ scheinbar immer Tab eingefügt.
 

geimist

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
04. Jan 2012
Beiträge
5.567
Punkte für Reaktionen
1.391
Punkte
234
Ihr müsst auch aufpassen, wenn ihr solche Files in Windows bearbeitet, dass die Unixzeilenenden erhalten bleiben. SynOCR versucht das zwar zu korrigieren, aber eine Garantie darauf kann ich nicht geben.

Der Texteditor im DSM leistet für so etwas auch gute Dienste.

In deinem Logsteht zwar in Zeile 603, aber bei mir war es dann immer in der Zeile darunter
Das bezieht sich aber nicht auf die Zeile in deiner Regeldatei, sondern von synOCR.sh.
 

Tommes

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
26. Okt 2009
Beiträge
9.736
Punkte für Reaktionen
1.643
Punkte
314
Ihr müsst auch aufpassen, wenn ihr solche Files in Windows bearbeitet, dass die Unixzeilenenden erhalten bleiben.
… daher sollten solche Files immer als UTF-8 geladen und gespeichert werden. Kann man sowohl im Notepad++ als auch im DSM Text-Editor als Standard einstellen.
 

lil-ac

Benutzer
Mitglied seit
14. Feb 2013
Beiträge
39
Punkte für Reaktionen
0
Punkte
6
So Fehler gefunden.

Andere Frage, was muss ich ändern damit der Dateiname direkt umgeändert wird auf: Datum_Tagname? Aktuell macht er es so: Datum_Tagname_Dateiname
Vielen Dank noch mal :)
 

geimist

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
04. Jan 2012
Beiträge
5.567
Punkte für Reaktionen
1.391
Punkte
234
Jetzt hast du in der GUI als Umbenennungssyntax bestimmt §yocr-§mocr-§docr_§tag_§tit eingestellt.
Du müsstest §yocr-§mocr-§docr_§tag setzen.

§tit steht für "Titel der Originaldatei"

Bildschirmfoto 2021-09-07 um 10.11.30.png
 

Hoods

Benutzer
Mitglied seit
05. Mrz 2012
Beiträge
9
Punkte für Reaktionen
0
Punkte
1
Hallo zusammen,

ich benutzte synOCR auf DSM7 und habe folgende Probleme die ich nicht eingegrenzt / abgestellt bekommen. Vielleicht hat jemand einen Tipp?

1. Ich habe Quittungen die ich mittels Android App Swiftscan in pdf (inkl. OCR) umgewandet habe. Wenn synOCR diese Dateien verarbeitet ist eigentlich keine erneutest OCR'en notwendig. Ich lese das so, dass das "s" in den bisher genutzten (-srd -l deu) cmd line Optionen eigentlich ein erneutes Scannen vermeiden sollte oder?

Leider wird das pdf trotzdem verarbeitet (und aktualisiert) und der Text ist nach der Verarbeitung nicht mehr lesbar (durchsuchbar). Vorher war das pdf Dokument durchsuchbar. Lt. Logfile greift auch keine der definierten Regeln was nicht sein kann. Versuchsweise habe ich dann die cmd line Optionen --force-ocr, --skip-text, --redo-ocr getestet aber keine brauchbare Lösung gefunden. Ziel wäre die Dateien nicht erneut zu OCR'en aber entsprechend Regeln umzubenennen. Sollte das funktionieren?

2. Im Logfile erscheint folgende Meldung bei der betreffenden Regel

search by tag rule: "Quittung_15" ?
? condition: any
? tag: Quittung
? destination: Rechnungen
grep: invalid option -- 'K'
Usage: grep [OPTION]... PATTERN [FILE]...
Try 'grep --help' for more information.
>>> Rule is not satisfied

In der Regeldatei kann ich aber keine Fehler oder besagte "invalid option" finden.

Bin für jeden Hinweis dankbar.

Gruss Sven
 

geimist

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
04. Jan 2012
Beiträge
5.567
Punkte für Reaktionen
1.391
Punkte
234
  1. -s sollte hier helfen. Warum es das nicht tut, kann ich nicht sagen. Da wäre jbarlow83 als Entwickler von OCRmyPDF der bessere Ansprechpartner (synOCR reicht das PDF ja lediglich weiter). Mach doch am besten ein Issue dafür auf und berichte.

  2. Ich glaube, das hatte ich auch schonmal, aber noch nicht erforscht.
    Könntest du mal bitte die entsprechende Regel posten oder mir schicken? (Link in der Signatur)
 

Hoods

Benutzer
Mitglied seit
05. Mrz 2012
Beiträge
9
Punkte für Reaktionen
0
Punkte
1
Hi Stephan,

ich habe mich schon mal im issue tracker umgeschaut und werde die genannten Vorschläge durcharbeiten, kann aber ein wenig dauern. Ich habe mein Regelfile hochgeladen, wenn Du noch was brauchst sag gern bescheid.

Vielen Dank an dieser Stelle nochmal für synOCR !!

Gruss Sven
 

geimist

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
04. Jan 2012
Beiträge
5.567
Punkte für Reaktionen
1.391
Punkte
234
Kannst du mal bitte in der GUI das Loglevel auf 2 (debug mode) stellen, einen Durchlauf machen und nochmal das Log hochladen?
Danke
 

Hoods

Benutzer
Mitglied seit
05. Mrz 2012
Beiträge
9
Punkte für Reaktionen
0
Punkte
1
Hallo Stephan,

ich habe heute nochmal ein paar Tests gemacht (und auch ein Debug Log hochgeladen). Ein erneutes Verarbeiten der mit Swiftscan bereits OCR'ten Dateien führt dazu, dass der Text der OCR'ten Datei zerlegt wird und überall Leerzeichen eingefügt werden. D.h. aus K-U-N-D-E-N-B-E-L-E-G wird K - U - N - D - ..... und so weiter.

Ein ähnliches Problem ist auch hier beschrieben https://github.com/jbarlow83/OCRmyPDF/issues/794

Was mir noch nicht ganz klar ist, ich verwende aktuell wieder die Option "-srd -l deu", damit Dateien mit Text übersprunden werden. Die Frage ist, wird damit auch das umbenennen und verschieben in Ordner verworfen oder nur ein erneutes OCR des PDF unterdrückt?

Wie gesagt, obwohl ich die "s" Option nutze wird die Datei erneut OCR't und der Text zerhakt. Eine denkbare Lösung wäre, dass die Datei gar nicht von ocrmypdf verarbeitet wird und von synOCR nur das Umbenennen und Verschieben anhand der Tags durchgeführt wird.

Gruss Sven
 
Zuletzt bearbeitet:


 

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