synOCR synOCR - GUI für OCRmyPDF

[DeeKay1]

Da hast du natürlich recht, der Mai kann so nicht gefunden werden. Wundert mich aber, da ich eigentlich alles im unittest überprüft habe.
2 stellige und 4 stellige Jahreszahlen sollten aber gefunden werden.
Problematisch ist immer nur was dann hinter der Zahl kommt.
Vielleicht habe ich da nicht alles abgedeckt.
Werde mir das nach Feierabend mal ansehen. Auf der Arbeit habe ich leider keinen Zugriff auf den Code und meine Tests.
Also ein wenig Geduld

Sag Bescheid falls ich dir mit den Regex helfen kann.
Da wir mittlerweile sowieso schon Python im Einsatz haben, wäre es nicht eine Idee auf etwas fertiges, wie z.B. https://datefinder.readthedocs.io/en/latest/, zu setzen?

 

[Gthorsten]

Ungern. Aber ich kann mal versuchen ein paar Testdokumente zu erstellen.
Sofern ich find_dates.py korrekt interpretiere, dürfte es aber an den verwendeten Regex liegen.
Beispiele aus neueren Tests:
- 16. Mai 2022 wird von \s(((0[1-9]|[12][0-9]|3[01])\.?)?)\s(([a-zA-Z]{3}\.?)|([a-zA-ZäÄ]{4,12}))\s(\d{4}|\d{2}) nicht gefunden. Dafür müsste man die Längenbeschränkung hinter [a-zA-ZäÄ] von {4,12} auf {3,12} ändern
- Änliches Spiel für "(Stand 05.04.2022)". Das wird nicht gefunden, da hinter der Jahreszahl eine schließende Klammer ist, die durch den Regex nicht abgedeckt wird

Bezogen auf mein Beispiel ein par Beiträge zuvor, wurde auch 23.08.22 nicht gefunden, da die Jahreszahl 2-stellig ist und nicht 4-stellig.

Es ist spät und ich hab nicht die komplette find_dates.py im Detail durchgearbeitet, aber das sind mal meine ersten findings.

Also gerade mal eben geschaut. Das mit dem Mai war ein Schreibfehler in meinem unit test. Da stand maii .
Mit der klammer am Ende... Hier stellt sich die Frage was hinter einem Datum stehen darf.
Ich hatte in meinem Dokumenten sowas ähnliches, da stand hinter der Zahl ein buchstabe.... Deshalb hatte ich das so aufgebaut.
Ich kann aber die klammer.mit hinein nehmen.
Das mit mm/yyyy kann ich mit einbauen.
Mm/yy finde ich aber nicht eindeutig genug.

Schaue mir das aber in Ruhe nochmal an. Wird allerdings erst Donnerstag. Vorher lässt die Arbeit mich nicht

 

[DeeKay1]

Was spricht denn dagegen die Prüfung von "was darf hinter der zahl" auf \b zu ändern?
Mm/yy sollte auch machbar sein da ja der mm part nur 1-12 sein kann. Allerdings natürlich dennoch anfällig für Fehlinterpretationen.
Hast du auch mal geschaut wieso das Datum mit zweistelliger Jahreszahl nicht gefunden wurde? Also zB 01.12.22. Soweit ich das gesehen habe, akzeptieren die regex nur 4-stellige Jahreszahlen.

 

[ThomasC]

Also grundsätzlich werden von OCRmyPDF Dokumente im PDF-A Standard ausgegeben. Leider kommt es bei der Weiterverarbeitung durch die Pythonbibliothek PyPDF2 zu dem Fehler, dass die PDF-A Eigenschaft verloren geht. Dieses Verhalten ist dem Entwickler von PyPDF2 bekannt, wurde aber bisher leider nicht gefixt.

Wenn du darauf verzichten kannst, dass Tags und Autorname in die PDF geschrieben werden sollen, kannst du diesen Schritt mit folgendem Befehl im Terminal oder Aufgabenplaner überspringen lassen (die Änderung muss nach einem Update ggf. wiederholt werden):

/usr/syno/bin/synosetkeyvalue "/usr/syno/synoman/webman/3rdparty/synOCR/synOCR.sh" enablePyMetaData 0

Okay, nach der Deaktivierung funktionieren die gewünschten OCR Parameter

Cool wäre es, wenn zukünftig beides funktionieren würde. Dann drücke ich mal die Daumen das der Bug in naher zukunft gefixt wird!?.

VG Thomas

 

[Gthorsten]

Sag Bescheid falls ich dir mit den Regex helfen kann.
Da wir mittlerweile sowieso schon Python im Einsatz haben, wäre es nicht eine Idee auf etwas fertiges, wie z.B. https://datefinder.readthedocs.io/en/latest/, zu setzen?

Das setze ich auch ein, es hat aber nicht an allen Stellen geholfen. Deshalb habe ich zusätzlich, bzw als vorschaltstufe noch regex benutzt.

Die Frage ist trotzdem, was hinter einer Jahreszahl alles als Zeichen erlaubt ist bzw was wir zulassen wollen...

 

[Gthorsten]

Das mit der 2. stelligen Zahl habe ich noch nicht geschaut. Habe zuhause nur per Handy auf den Code geguckt. War nicht am PC. Das passt erst wieder am Donnerstag. Vlt auch morgen, aber das weiß ich noch nicht

 

[DeeKay1]

Keine Eile. Arbeit (und Family) geht immer vor. Ich ändere das derweil mal lokal bei mir. Sofern @geimist meinen alten Git-user entstaubt, könnte ich dir auch nen PR schicken.

 

[Gthorsten]

Kannst ruhig machen, muss es aber erst bei mir einpflegen, weil ich das ganze in meinem eigenen git repro habe

 

[geimist]

Ich hab gerade mal noch deine Variante getestet. Bitte noch von "-ge" auf "-g" ändern. Wenn die zu splittenden Dokumente nur eine Seite haben sind startPage und endPage gleich.

Danke, habe ich getestet und angepasst (-gt).
Das SPK aktualisiere ich dann bei der nächsten Gelegenheit, falls es noch in Update fürs Datum geben sollte.

 

[DeeKay1]

Also grundsätzlich werden von OCRmyPDF Dokumente im PDF-A Standard ausgegeben. Leider kommt es bei der Weiterverarbeitung durch die Pythonbibliothek PyPDF2 zu dem Fehler, dass die PDF-A Eigenschaft verloren geht. Dieses Verhalten ist dem Entwickler von PyPDF2 bekannt, wurde aber bisher leider nicht gefixt.

Wenn du darauf verzichten kannst, dass Tags und Autorname in die PDF geschrieben werden sollen, kannst du diesen Schritt mit folgendem Befehl im Terminal oder Aufgabenplaner überspringen lassen (die Änderung muss nach einem Update ggf. wiederholt werden):

/usr/syno/bin/synosetkeyvalue "/usr/syno/synoman/webman/3rdparty/synOCR/synOCR.sh" enablePyMetaData 0

In dem Issue wird gefragt ob man es mal mit der letzten version probieren kann. Ggf ist das ja schon gefixt?
https://github.com/py-pdf/pypdf/issues/1347

 

[geimist]

In der Tat scheint es jetzt ein PDF/A zu bleiben
Ich hatte das am Anfang immer beobachtet, aber jetzt nur noch gewartet, bis der Bug geschlossen ist. Sehr schön!
Allerdings gab es in der Zwischenzeit ab der Version 3.0 ein paar Änderungen, weshalb u.a. die Trennseiten nicht funktionieren. Das muss ich noch beheben.
Vielen Dank für den Tritt ins Schienbein

 

[Gthorsten]

Was spricht denn dagegen die Prüfung von "was darf hinter der zahl" auf \b zu ändern?
Mm/yy sollte auch machbar sein da ja der mm part nur 1-12 sein kann. Allerdings natürlich dennoch anfällig für Fehlinterpretationen.
Hast du auch mal geschaut wieso das Datum mit zweistelliger Jahreszahl nicht gefunden wurde? Also zB 01.12.22. Soweit ich das gesehen habe, akzeptieren die regex nur 4-stellige Jahreszahlen.

Ich habe mir das gestern nochmal angesehen.
Und ich habe auch noch ein paar alte Kommentare bei mir im git gefunden.
Das 2 stellige Jahr war am Anfang mit drin.
Das hat dann aber bei Tests und bei meinen eigenen Dokumenten zu vielen Fehlern geführt.
Also 20.01.22 was ist jetzt Monat und Jahr....

Ich kann das wieder mit rein nehmen, aber dann wird es auch wieder Probleme geben.
Da habe ich dann keine schlaue Idee wie wir das verhindern.

Den Mai habe ich gestern noch gefixt.

 

[gunfran]

Also 20.01.22 was ist jetzt Monat und Jahr....

Ich kann das wieder mit rein nehmen, aber dann wird es auch wieder Probleme geben.
Da habe ich dann keine schlaue Idee wie wir das verhindern

Ich bin kein riesiger Experte, aber wenn du jetzt z.B. fragst wegen Monate wie z.B. die Amis die tag und Monat im Vergleich zu uns vertauschen ist es da nicht aber immer so das sie / zum trennen von Tag, Monat und Jahr benutzen?

Wenn ich mich nicht irre ist das dort zumindest immer so.

Nur hast du von der Theorie her recht das es durchaus auch mal anders rum gebaut sein könnte. Allerdings würde ich da auf "offiziellen" Dokumenten wie Rechnungen, Gehalt usw. vermutlich nicht mit rechnen.

 

[DeeKay1]

Besten Dank.

Zwecks den 2-stelligen Jahren. Best Case: Man wertet die "-l"-Eigenschaft aus und prüft ob das ausgewählte Land das Jahr am Anfang oder am Ende hat (im Normalfall).
Anderenfalls Einsatz der 99%-Regel: Wenn 99% der User aus dem Teil der Welt kommen, in dem die Jahreszahl normalerweise ans Ende kommt, hardcodiere erstmal das Schema Tag.Monat.Jahr / Monat.Tag.Jahr.
Wir reden hier von Pattern-Matching, somit wird man nie den Fall von 100% korrekter Erkennung erreichen. Daher musst du mit der Wahrscheinlichkeit arbeiten, auf welches Pattern die User zum Großteil treffen werden. Wobei ich jetzt nicht sage, dass mein Fall derjenige mit der höheren Wahrscheinlichkeit ist.

 

[Gthorsten]

Mit I Eigenschaft, meinst du damit das Land abzufragen in dem der User sich gerade befindet, bzw die syno läuft?

 

[DeeKay1]

Jep. Wobei natürlich nicht sicher ist ob der User den Parameter auch setzt. Da hast du recht.

 

[Gthorsten]

Ok, und Stephan müsste die Info dann an mich weiter geben.... Ich gucke nochmal nach einer anderen Lösung.

 

[DeeKay1]

Andere Frage: ocrmypdf setzt im default ja optimization level 1 ein. In dem Moment wird lossless JBIG2 zur Bildkompression verwendet.
Seit dem Xerox-Desaster hat das BSI für DE, und auch weitere Länder, allerdings JBIG2-Kompression, egal ob lossy oder lossless, für rechtssichere Dokumente als ungeeignet und als nicht zu verwenden eingestuft. Gabs hierüber schon mal ein Diskussion? Wie handhabt ihr das bei euren Scans?
Prinzipiell sind gescannte Dokumente ja sowieso selten rechtssicher und man muss bei wichtigen Themen immer die Originale Aufhaben. Sofern man aber jbig2 verwendet, sind sie eben per Definition schon nicht rechtssicher.

 

[geimist]

Mit I Eigenschaft, meinst du damit das Land abzufragen in dem der User sich gerade befindet, bzw die syno läuft?

Eher die Sprache, die man im Dokument erkennen lassen möchte. Diesen Parameter kann man ja auch durch ein + beliebig kombinieren. Das macht es Schimmel schwieriger.
Die nächste Frage ist dann: Für welches Land steht denn dann z.B. englisch? GB? USA? Kanada? Botswana? Oder Australien? …

Überlegt hatte ich mir das schonmal. Aber das führt zu so vielen weiteren Eventualitäten, dass die Erkennung kaum sicherer wird - meiner Meinung nach.

ocrmypdf setzt im default ja optimization level 1 ein. In dem Moment wird lossless JBIG2 zur Bildkompression verwendet.
Seit dem Xerox-Desaster hat das BSI für DE, und auch weitere Länder, allerdings JBIG2-Kompression, egal ob lossy oder lossless, für rechtssichere Dokumente als ungeeignet und als nicht zu verwenden eingestuft. Gabs hierüber schon mal ein Diskussion?

Die Optimierunglevel kann man auf jeden Fall per Parameter steuern. Das Kompressionsverfahren müsste man mal testen. Wenn es aber über Parameter steuerbar ist, sollte es kein Problem sein.

 

[DeeKay1]

Die Optimierunglevel kann man auf jeden Fall per Parameter steuern. Das Kompressionsverfahren müsste man mal testen. Wenn es aber über Parameter steuerbar ist, sollte es kein Problem sein.

Jep, deswegen frage ich ja auch danach wie die community, oder auch du, es bei ihren Scans macht. Sofern ich gesehen habe ist jbig2 mit dem docker container immer aktiv. Es bliebe also nur die Option die Optimzation mit 0 zu deaktivieren.