synOCR synOCR - GUI für OCRmyPDF

geimist

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
04. Jan 2012
Beiträge
5.515
Punkte für Reaktionen
1.351
Punkte
234
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

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
04. Jan 2012
Beiträge
5.515
Punkte für Reaktionen
1.351
Punkte
234
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

Benutzer
Mitglied seit
20. Jun 2020
Beiträge
100
Punkte für Reaktionen
23
Punkte
24
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
 
Zuletzt bearbeitet:

geimist

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
04. Jan 2012
Beiträge
5.515
Punkte für Reaktionen
1.351
Punkte
234
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

Benutzer
Mitglied seit
20. Jun 2020
Beiträge
100
Punkte für Reaktionen
23
Punkte
24
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.
 

ZwickeZwacke

Benutzer
Mitglied seit
12. Apr 2021
Beiträge
4
Punkte für Reaktionen
0
Punkte
1
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..
 

ZwickeZwacke

Benutzer
Mitglied seit
12. Apr 2021
Beiträge
4
Punkte für Reaktionen
0
Punkte
1
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:

1678291131199.png
 

geimist

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
04. Jan 2012
Beiträge
5.515
Punkte für Reaktionen
1.351
Punkte
234
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

Benutzer
Mitglied seit
12. Apr 2021
Beiträge
4
Punkte für Reaktionen
0
Punkte
1
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:

1678307779704.png

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

Benutzer
Mitglied seit
14. Jul 2012
Beiträge
10
Punkte für Reaktionen
0
Punkte
1
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

Benutzer
Mitglied seit
14. Jul 2012
Beiträge
10
Punkte für Reaktionen
0
Punkte
1
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

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
26. Okt 2009
Beiträge
9.662
Punkte für Reaktionen
1.559
Punkte
314
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

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
04. Jan 2012
Beiträge
5.515
Punkte für Reaktionen
1.351
Punkte
234
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 :unsure: 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.
 
  • Like
Reaktionen: DeeKay1

st3623

Benutzer
Mitglied seit
14. Jul 2012
Beiträge
10
Punkte für Reaktionen
0
Punkte
1
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

Benutzer
Mitglied seit
14. Jul 2012
Beiträge
10
Punkte für Reaktionen
0
Punkte
1
> ... 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

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
04. Jan 2012
Beiträge
5.515
Punkte für Reaktionen
1.351
Punkte
234
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

Benutzer
Mitglied seit
22. Mai 2021
Beiträge
151
Punkte für Reaktionen
42
Punkte
28
> ... 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?
 


 

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