synOCR synOCR - GUI für OCRmyPDF

[geimist]

In dem Issue wird gefragt ob man es mal mit der letzten version probieren kann. Ggf ist das ja schon gefixt?

Meine weiteren Tests zeigten, dass das Ergebnis jetzt zwar ein PDF ist, welches als Version 1.7 (also PDF/A) deklariert ist, aber immer noch nicht die Prüfung besteht. Ich werde es dennoch erst einmal so einbauen.

 

[geimist]

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.

Problemetisch scheint auch 'nur' der Lossy mode von JBIG2. JBarlow83 verweist selbst in diesem Zusammenhang auf den Sicherheitsaspekt hin.
Ich gehe also davon aus, wenn man nicht explizit --jbig2-lossy setzt, dass man damit auch diesem Aspekt aus dem Weg geht.

 

[DeeKay1]

In Bezug auf die Rechtssicherheit stimmt das leider nicht. Das BSI hat hier komplett JBIG2 rausgeschmissen. Was auch Sinn macht, da auch die loseless-Variante von JIBG2 auf substition setzt.
Aber gut, dann werd ich das für mich entscheiden müssen ob ich auf die Komprimierung ganz verzichten kann oder nicht.

Eine der Quellen: http://www.dkriesel.com/blog/2015/0317_bsi_verbietet_jbig2
Kann man aber auch in der TR 03138 nachlesen: https://www.bsi.bund.de/SharedDocs/...03138/TR-03138.pdf?__blob=publicationFile&v=5
Und hier noch was das ganze damals ins Rollen gebracht hat: https://www.youtube.com/watch?v=7FeqF1-Z1g0

 

[geimist]

Magst du mal ein Issue bei OCRmyPDF dazu aufmachen? Ich werde dazu nichts Erhellendes beitragen können, wenn aber einer, dann jbarlow83. Gerade in Bezug darauf, mit welchen Parametern man auf eine Alternative zugreifen kann.

 

[DeeKay1]

Ja, kann ich gern machen. Das synOCR damit wenig zu tun hat war mir schon klar.
Dennoch danke, du hast meine Frage damit quasi beantwortet.

 

[DeeKay1]

For the records: https://github.com/ocrmypdf/OCRmyPDF/issues/1077

 

[ZwickeZwacke]

Hallo Zusammen,

ich habe eine Frage die nicht ins aktuelle Thema passt, und die Suchfunktion sowie der Google Index hat mich nicht zum gewünschten Ergebnis geführt....

Ich habe folgendes Problem - wenn ich via Duplex Scan leere Seiten habe, oder via SYNOCR-SEPARATOR-SHEET versuche Dokumente zu trennen, stoppt der Prozess entweder nach der letzten leeren Seite bzw. nach der Seite vor dem Seperator Sheet...

Das Problem bzgl. dem Beenden nachdem eine leere Seite erkannt wurde (im log stand was von: [tesseract] Empty page!!) konnte ich beheben indem ich das -d für schiefe Scans entzerren in den SynOCR Optionen rausgelassen hatte.

Jedoch bleibt das Problem mit dem nicht-weiterverarbeiten der Dokumente nach dem Seperator Sheet..

 

[geimist]

Kannst du mir mal bitte ein vollständiges log hochladen (Link in meiner Signatur)?

 

[ZwickeZwacke]

Kannst du mir mal bitte ein vollständiges log hochladen (Link in meiner Signatur)?

Erledigt Merci für den Support!
Möglicherweise bin ich als "Etwas_aber_nur_ein_bisschen_versierter_als_ein_Dau" etwas zu doof das ordentlich einzurichten.



Zur Info - für die Suchfunktion sowie für #Google #Bing #DuckDuckGo #Duplex #leere Seite #Blank Page #Canon Maxify...
Für jeden der ein Papierloses Büro mit Hilfe eines Multifunktionsgeräts mit Duplex Scan Möglichkeit (in meinem Fall Canon Maxify MB5155 | MB5100) nutzen möchte - hier gibt es keine Möglichkeit seitens des Hersteller direkt auf ein Netzwerkshare zu Scannen und gleichzeitig leere Seiten zu skippen bzw. zu überspringen:

 

[geimist]

Also ich kann jetzt keinen direkten Fehler im Log finden und die (1.) Datei wird offensichtlich auch fertig abgearbeitet. Kürzlich hatten wir ja einen Fehler genau in diesem Zusammenhang gefixt - allerdings erst in der Beta. Magst du die mal probieren?
Beta: DSM6 | DSM7

 

[ZwickeZwacke]

Also ich kann jetzt keinen direkten Fehler im Log finden und die (1.) Datei wird offensichtlich auch fertig abgearbeitet. Kürzlich hatten wir ja einen Fehler genau in diesem Zusammenhang gefixt - allerdings erst in der Beta. Magst du die mal probieren?
Beta: DSM6 | DSM7

So, Versuch mit der Beta Version - jedoch ohne Ergebnis.
Spannenderweise hat er jetzt nicht das Separator Sheet entfernt und alles was danach kommt sondern:



Funfact: Auch mit der Beta funktioniert die "leere Seite" zwar ignorieren aber dafür alles verarbeiten nur - wenn ich die Funktion "entzerren" weg lasse

 

[st3623]

Lieber geimist,

vielen Dank für synOCR!
Das Package trifft einen echten "Pain-Point" und leistet einen Haufen Mehrwert!
Hut-Ab für eine tolle Umsetzung!

Nichtsdestotrotz wollte ich gerade ein Ticket für synOCR anlegen, hab allerdings keinen Account auf Deiner gitea-Instanz, weshalb wahrscheinlich dieser Mega-Thread hier die beste Möglichkeit, meine Anregungen loszuwerden:

1. Vorschlag: Github oder Gitlab anstatt privater gitea-Instanz.
Vorteil für Dich und das Projekt: Viel einfachere Zusammenarbeit mit Usern über Pull-Requests für Code und Doku, Tickets, etc., weil jeder einfach beitragen kann und nicht alles über diesen Thread hier laufen muss.

2. Ticket:

synOCR sollte keine Temp-Ordner oder Temp-Dateien im Target-Folder erzeugen!
----------------------------------------------------------------------------

Zur Zeit erzeugt synOCR im konfigurierten Target-Ordner temporäre Dateien/Directories á la "synOCR_tmp_1678280175".
Dadurch ist synOCR kein "good citizen" und verkompliziert die Zusammenarbeit mit anderen nachgelagerten Pipeline-Steps!

Konzeptionell stellt synOCR nur einen Schritt einer potenziell langen "Document-Processing-Pipeline" dar.
Vorgelagerte Schritte schaufeln irgendwie Quell-Dateien in den Source-Ordner und nachgelagerte Schritte verarbeiten die Dateien im Target-Ordner weiter.
synOCR sollte sich seiner Position in der Pipeline bewusst sein und:

1. im Source-Ordner nur Read- und Delete-Operationen ausführen, keine Creates und auch keine Writes.
2. im Target-Ordner nur Create- und Write-Operationen ausführen, keine Reads und Deletes.

Es könnte sogar sein, dass synOCR hier vom Admin auf irgendeine Weise die entsprechenden Rechte für die "falschen" Operations entzogen werden, um eine ordentliche Kapselung sicherzustellen.

In meinem Setup zum Beispiel ist der Target-Ordner als "Shared-Folder" für ein Cloud-Sync konfiguriert. Alle darin auftauchenden Dateien werden auf verschiedene Next-Cloud-Instanzen verteilt. Im Moment geschieht das auch mit den Temp-Ordnern, die dann alle möglichen nachgelagerten Probleme verursachen!

Genauso gut könnte der Target-Ordner der Eingangs-Ordner für irgendein Dokumenten-Management-System sein.
Auch das, wird an den temporären Dateien keinen Spaß haben.

Daher: Temporäre Dateien sollten in einem ordentlichen Temp-Ordner landen, so wie sie das DSM-zugrundeliegende Linux ganz normal bereitstellt!

 

[st3623]

Und noch eine Frage:
Unter welcher Lizenz stellst Du synOCR zur Zeit bereit?
Unter https://git.geimist.eu/geimist/synOCR hab ich auf die Schnelle keinerlei Hinweise auf irgendwelche Lizenz-Infos gefunden...

 

[st3623]

Noch ein Ticket:

Die Location und der Name des Rules-Files sollte konfigurierbar sein.
Zur Zeit heißt das File `_TagConfig_[profile_default].txt` und liegt zwingend im $SOURCE folder, was unter Umständen (siehe Ticket oben) nicht die beste Lösung für ein bestimmtes Setup sein muss.
Außerdem handelt sich anscheinend um ein YAML-File, was am besten eine `.yaml` File-Extension haben sollte, damit Text-Editoren gleich das richtige Syntax-Highlighting und ggf. Linting anwenden können.

Wenn `synCOR` mir als User einfach die Möglichkeit geben würde, eine beliebiges YAML-File irgendwo im File-System auszuwählen, wär alles geritzt.

Wie wär's, wenn ich z.B. in der "Tags to be searched" <TEXTAREA> einfach einen Filename eintragen kann, und fertig?
Dann könnte sich synOCR auch gleich noch den "rule file - create / convert" Button sparen und das UI wäre etwas konsistenter.
(Im Moment ist's z.B. unklar, was genau verwendet wird, wenn in der "Tags to be searched" <TEXTAREA> etwas eingetragen ist, aber gleichzeitig ein Rule-File existiert (dessen Präsenz in der UI ja auch nicht direkt sichtbar ist))

 

[Tommes]

Hi @st3623

Ich will mich nicht groß zu deinen Vorschlägen äußern, da dies natürlich von @geimist selbst beantwortet bzw. bewertet werden sollte. Aber eins hätte ich da…

1. Vorschlag: Github oder Gitlab anstatt privater gitea-Instanz.

Diesen Vorschlag kann ich nur befürworten, auch wenn ich in manchen Punkten immer noch meine liebe Mühe mit GitHub habe.

Tommes

 

[geimist]

1. Vorschlag: Github oder Gitlab anstatt privater gitea-Instanz.
Vorteil für Dich und das Projekt: Viel einfachere Zusammenarbeit mit Usern über Pull-Requests für Code und Doku, Tickets, etc., weil jeder einfach beitragen kann und nicht alles über diesen Thread hier laufen muss.

Das ist halt mit der Zeit so gewachsen. Der Gedanke, umzuziehen, geistert auch schon eine Weile in meinem Köppl rum. Das werden wir bestimmt mal machen …
Gespiegelt wird es ja bereits: https://github.com/geimist/synOCR

synOCR sollte keine Temp-Ordner oder Temp-Dateien im Target-Folder erzeugen!

Danke für dein Feedback. Irgendeinen Grund hatte das, warum ich das mit den Dokumenttrenner eingeführt hatte – fällt mir aber gerade nicht ein Dein Vorschlag ist aber auf jeden Fall konsequent und nachvollziehbar und ich werde mir das nochmal ansehen.

Unter welcher Lizenz stellst Du synOCR zur Zeit bereit?

Die Lizenz-Info liegt mit bei den Files, die gepackt werden.

Zur Zeit heißt das File `_TagConfig_[profile_default].txt` und liegt zwingend im $SOURCE folder, was unter Umständen (siehe Ticket oben) nicht die beste Lösung für ein bestimmtes Setup sein muss.

Ist es doch. Du kannst in deiner synOCR-GUI einen beliebigen Pfad angeben (so lang der User synOCR darauf Zugriff hat). Lediglich die automatische Erstellung (inkl. der Konvertierung der simplen GUI-Regeln) erfolgt an diesem Pfad, weil er bekannt ist. Die .txt Dateiendung habe ich gewählt, weil nicht jeder User wissen wird, wie er eine YAML-Datei öffnen kann. Aber wie gesagt: dem Anwender steht es frei, einen eigenen Pfad und Namen zu verwenden.

Wenn `synCOR` mir als User einfach die Möglichkeit geben würde, eine beliebiges YAML-File irgendwo im File-System auszuwählen, wär alles geritzt.
Wie wär's, wenn ich z.B. in der "Tags to be searched" <TEXTAREA> einfach einen Filename eintragen kann, und fertig?

Ist genauso möglich, aber nur manuell (wir haben noch keine Möglichkeit für einen Folder- Filepicker in der GUI finden können).

Dann könnte sich synOCR auch gleich noch den "rule file - create / convert" Button sparen und das UI wäre etwas konsistenter.
(Im Moment ist's z.B. unklar, was genau verwendet wird, wenn in der "Tags to be searched" <TEXTAREA> etwas eingetragen ist, aber gleichzeitig ein Rule-File existiert (dessen Präsenz in der UI ja auch nicht direkt sichtbar ist))

Der Button erscheint nur, wenn es sich bei der Angabe in dem Feld um keinen gültigen Pfad handelt (also auch, wenn es die Datei noch nicht gibt). Sobald da ein gültiger Dateipfad drinsteht, gibt es auch keinen Button. Es soll für unversierte User so einfach wie möglich sein.

 

[st3623]

Hallo Stephan,

> Ist es doch. Du kannst in deiner synOCR-GUI einen beliebigen Pfad angeben...

Stimmt. Hab ich gerade auch selbst gemerkt.
Vorschlag: Wenn ich den Button drücke, und die existierenden Tags in die initiale Rule-Datei exportiert werden, wie wär's, wenn dann gleich der Inhalt des "Tags to be searched" Feldes so upgedated wird, dass ich als User sehe, wie das gedacht ist?
Sprich: Alte Tag-Definition raus und Pfad `$SOURCE/_TagConfig_[profile_default].txt` rein.
Dann erschließt sich mir die Logik ganz von selbst.

Und der Vorteil ist, dass das Rule-File auch gleich aktiviert ist.
Ich hatte nämlich den Effekt, dass ich zwar den Button gedrückt hab und das YAML-File editiert hab, aber die Rules nicht aktiv waren.
Erst nach etwas mehr suchen hab ich entdeckt, dass ich ja noch den Filename entsprechend eintragen muss.

> Die Lizenz-Info liegt mit bei den Files, die gepackt werden.

Ok.
Vorschlag: Check das LICENSE File doch einfach direkt mit ein, in die Project-Root.
Das ist da, wo sich jeder der sich einigermaßen auskennt, danach suchen würde.

Besten Dank für den tollen Support hier!

 

[st3623]

> ... Gespiegelt wird es ja bereits: https://github.com/geimist/synOCR

Ah, ok, nice!
Da fehlt doch jetzt echt nicht mehr viel und Du kannst PRs etc. akzeptieren.
Und die Diskussionen über bestimmte Bugs, Features, etc. würden nicht den Thread hier verstopfen.

 

[geimist]

Vorschlag: Wenn ich den Button drücke, und die existierenden Tags in die initiale Rule-Datei exportiert werden, wie wär's, wenn dann gleich der Inhalt des "Tags to be searched" Feldes so upgedated wird, dass ich als User sehe, wie das gedacht ist?
Sprich: Alte Tag-Definition raus und Pfad `$SOURCE/_TagConfig_[profile_default].txt` rein.
Dann erschließt sich mir die Logik ganz von selbst.

Und der Vorteil ist, dass das Rule-File auch gleich aktiviert ist.
Ich hatte nämlich den Effekt, dass ich zwar den Button gedrückt hab und das YAML-File editiert hab, aber die Rules nicht aktiv waren.
Erst nach etwas mehr suchen hab ich entdeckt, dass ich ja noch den Filename entsprechend eintragen muss.

Genau so sollte es funktionieren. Ich würde mal vermuten, du hast im Anschluss nicht aktiv auf "speichern" geklickt, weshalb der Pfad nicht in die Profilkonfiguration übernommen wurde. Mal sehen, ob ich das mit kombinieren kann. Mit den ganzen GUI-Sachen habe ich eigentlich rein gar nichts am Hut und wir können froh sein, dass wir @Tommes haben

 

[Gthorsten]

> ... Gespiegelt wird es ja bereits: https://github.com/geimist/synOCR

Ah, ok, nice!
Da fehlt doch jetzt echt nicht mehr viel und Du kannst PRs etc. akzeptieren.
Und die Diskussionen über bestimmte Bugs, Features, etc. würden nicht den Thread hier verstopfen.

Aber bleibt dann nicht die Frage wer dann alles Änderungen vornehmen darf.. So ist das ganze ja unter einheitlicher Kontrolle. Wenn jetzt auf einemal viele Leute dran mitarbeiten gerät das ganze dann nicht ausser Kontrolle?