Die Texterkennung (sog. OCR – Optical Character Recognition) sorgt bei Dokumenten verschiedenster Art dafür, dass Datei-Inhalte maschinell lesbar sind. Dadurch lassen sich Datei-Inhalte zum einen leicht markieren/kopieren (z.B. bei PDF-Dateien). Zum anderen werden die Inhalte der Dateien leicht durchsuchbar.
Der folgende Artikel zeigt daher, wie PDF-Dateien mit einer Texterkennung verarbeitet werden können. Ebenso wird gezeigt, wie Bilder einfach in PDF-Dokumente umgewandelt werden können, so dass diese danach ebenfalls maschinenlesbar sind.
Inhalt
OCR kurz erklärt
Bei OCR handelt sich es um die sog. Optical Character Recognition, also die Texterkennung bei Dokumenten, die an sich erst einmal nicht maschinenlesbar sind. Als Beispiel soll hier ein PDF-Dokument genannt sein. Der PDF-Standard wurde mit dem Gedanken entwickelt, dass PDF-Dateien unabhängig vom Anwendungsprogramm, vom Betriebssystem oder von der Hardware-Plattform jederzeit originalgetreu wiedergegeben werden können.
Nun wird euch sicherlich schon aufgefallen sein, dass es bei manchen PDF-Dateien vorkommt, dass hier keine Inhalte markiert/kopiert werden können. Hier fehlt dann ein sog. Text-Layer, der die Inhalte der Datei nochmals in maschinenlesbarer Form enthält. Wenn ein solcher Text-Layer vorhanden ist, lassen sich Inhalte in der PDF-Datei markieren und somit auch kopieren.
Genau dieser Text-Layer kann nun mittels OCR „nachgerüstet“ werden. Anschließend können Datei-Inhalte markiert/kopiert werden und sind – da maschinenlesbar – auch durchsuchbar. Beispielsweise kann im Windows-Explorer nach Inhalten gesucht werden, indem dem Suchbegriff noch „inhalt: “ vorangestellt wird.
Einziger Nachteil: Durch den zusätzlichen Text-Layer werden die Dateien etwas größer. Angesichts der Vorteile, die ein Text-Layer bietet, ist dieser Nachteil allerdings zu vernachlässigen.
Auf der Suche nach Programmen, die PDF-Dateien mit einem OCR-Text-Layer versehen können, gibt es unter Windows leider nicht viele Programme: Diese sind zudem meist kostenpflichtig oder zwingen den Benutzer zu einem bestimmten Workflow bei der Bearbeitung von PDF-Dateien.
Unter Linux sieht die Sache allerdings anders aus…
OCR für PDF-Dateien: OCRmyPDF
OCRmyPDF ist ein Kommandozeilen-Programm für Linux, mit dem PDF-Dateien einfach mit einem Text-Layer versehen werden können. Tesseract kommt dabei als OCR-Engine zum Einsatz.
Installation OCRmyPDF
Bei Debian und Ubuntu ist es bereits in den Paketquellen enthalten, so dass es einfach mit einem Befehl installiert werden kann:
apt-get update apt-get install ocrmypdf
Auch wenn das Programm bei manchen Distributionen nicht in den Paketquellen enthalten ist, kann es mit der Installationsanleitung auch hier installiert werden.
Bei der Installation werden alle automatisch alle Abhängigkeiten installiert, die für die Erkennung von englischen Texten benötigt werden. Damit auch Texte in anderen Sprachen erkannt werden können, müssen noch zusätzliche Sprach-Dateien für Tesseract installiert werden. Um beispielsweise auch deutsche Texte erkennen zu können, wird das deutsche Sprachpaket installiert:
apt-get install tesseract-ocr-deu
Eine Liste mit allen verfügbaren Sprach-Dateien findet man hier.
OCR mit OCRmyPDF
Um nun eine PDF-Datei mit einem Text-Layer zu versehen, reicht folgender Befehl:
ocrmypdf /mnt/temp/Dokument.pdf /mnt/temp/Dokument-OCR.pdf
Die originale PDF-Datei (/mnt/temp/Dokument.pdf) wird dabei nach der Verarbeitung als neue Datei (/mnt/temp/Dokument-OCR.pdf) gespeichert.
Der Aufruf kann noch mit Parametern versehen werden, um die Umwandlung besser kontrollieren zu können. Um beispielsweise einen Hinweis auf die enthaltenen Sprachen zu geben, erweitern wir den Befehl um den Parameter -l deu+eng. Damit wird der OCR-Engine mitgeteilt, dass im umzuwandelnden PDF vermutlich die Sprachen Deutsch und Englisch enthalten sind.
Eine Übersicht über alle möglichen Parameter findet man in der Dokumentation zu OCRmyPDF.
An dieser Stelle sei erwähnt, dass OCRmyPDF teilweise Warnungen ausgibt. Dies kann verschiedenste Ursachen haben, meistens ist dabei allerdings die Qualität des Ausgangs-Dokuments ausschlaggebend. Wenn dieses ein schlechter Scan ist, dann tut sich die Texterkennung hier schwer. Die Warnungen von OCRmyPDF können dabei allerdings ignoriert werden, es kann lediglich sein, dass die Texterkennung nicht sehr gut war und im Text-Layer des PDFs nicht alle Worte korrekt erkennt worden sind.
OCRmyPDF erzeugt standardmäßig PDF/A-Dateien. PDF/A ist dabei ein Dateiformat zur Langzeitarchivierung von PDF-Dateien. Alle Elemente, die zur Anzeige von PDF/A-Dokumenten benötigt werden, müssen dabei in der Datei selbst enthalten sein. Das sorgt dafür, dass PDF/A-Dateien immer etwas größer sind als normale PDF-Dateien. Es kann auch passieren, dass PDF/A-Dateien nicht alle Funktionen normaler PDF-Dateien bieten (da z.B. kein Javascript enthalten sein darf). Für den Privatgebrauch ist es daher eine Überlegung wert, für maximale Kompatibilität statt PDF/A-Dateien normale PDFs erzeugen zu lassen. Dies kann einfach mit dem Parameter –output-type pdf bewerkstelligt werden.
Ein vollständiger Aufruf von OCRmyPDF kann daher meist so aussehen:
ocrmypdf -l deu+eng --output-type pdf /mnt/temp/Dokument.pdf /mnt/temp/Dokument-OCR.pdf
OCR für Bilder: Umwandlung in (OCR-)PDF mittels Tesseract
Als ich vor etlichen Jahren angefangen habe, Dokumente (wie z.B. Rechnungen) zu Scannen, um diese auf dem Rechner archivieren zu können, habe ich diese noch nicht als PDF-Dateien, sondern als einfache Bild-Dateien (JPG) gespeichert. Dieses Dateiformat ist für diesen Zweck nicht gerade optimal, daher sollten diese Bild-Scans in PDF-Dateien konvertiert werden.
Hier kann OCRmyPDF auch zum Einsatz kommen, um diese Bilder in PDF-Dateien umzuwandeln. Allerdings habe ich hier mit Tesseract bessere Erfahrungen gemacht, so dass ich diese Dokument-Bilder eigentlich immer direkt über Tesseract in PDFs konvertieren lasse.
Die OCR-Engine Tesseract wurde ja bereits mit OCRmyPDF installiert. Falls dies noch nicht geschehen ist, reichen folgende Befehle, um Tesseract und die entsprechenden Sprach-Dateien zu installieren:
apt-get update apt-get install tesseract-ocr tesseract-ocr-eng tesseract-ocr-deu
Hier werden die Sprach-Dateien für Englisch und Deutsch mit installiert. Eine Übersicht über alle vorhandenen Sprach-Dateien findet man hier.
Die Umwandlung in PDFs mit Text-Layer erfolgt dann über folgenden Befehl:
tesseract /mnt/temp/Dokument.jpg /mnt/temp/Dokument-OCR -l deu+eng pdf
Der erste Parameter ist dabei das Input-Bild. Mit dem zweiten Parameter wird die Output-Datei angegeben (ohne Datei-Endung „.pdf“). Mit -l deu+eng wird der OCR-Engine wieder ein Hinweis auf die enthaltenen Sprachen gegeben. Der letzte Parameter (pdf) sorgt letzten Endes für die Umwandlung in eine PDF-Datei (und setzt die richtige Datei-Endung für die Output-Datei).
Automatisiert mit Skript
Jede PDF-/Bild-Datei nun einzeln mit einem Text-Layer zu versehen oder in eine (OCR-)PDF-Datei umzuwandeln, erfordert jedoch einiges an Aufwand. Das dachte ich mir auch, als ich die Vorgabe hatte, hunderte Dateien durch die Texterkennung zu jagen.
Aus diesem Grund habe ich ein Bash-Skript erstellt, welches die oben genannten Aufrufe automatisiert.
Nach dem Download des Skripts sollten noch folgende Punkte im selbst Skript angepasst werden:
- inputDirDefault/outputDirDefault: Standard-Verzeichnisse für Eingabe/Ausgabe.
- ocrmypdfCmdArgs: Parameter für den Aufruf von OCRmyPDF.
- imageConvertCmdArgs: Parameter für den Aufruf von Tesseract zur Umwandlung von Bildern in PDF-Dateien.
Bevor das Skript nun ausgeführt werden kann, muss dieses noch als auführbar markiert werden:
sudo chmod +x OCRmyFiles.sh
Nun erwartet das Skript beim Aufruf zwei Parameter:
- Ein Eingangs-Verzeichnis, in dem sämtliche PDFs/Bilder enthalten sind, die mittels Texterkennung behandelt werden sollen.
- Ein Ausgangs-Verzeichnis, in dem die Ergebnisse gespeichert sind
Ein typsicher Aufruf des Skripts sieht dann folgendermaßen aus:
ocrmyfiles.sh /mnt/OCR/Input /mnt/OCR/Output
Wenn diese Parameter weggelassen werden, werden die Standard-Verzeichnisse für Eingang/Ausgang genutzt (definiert in den Variablen inputDirDefault/outputDirDefault, siehe oben).
Das Skript führt nun folgendes aus:
- Es scannt das Eingangs-Verzeichnis (rekursiv) auf PDF-Dateien und Bilder.
- PDF-Dateien werden mittels OCRmyPDF mit einem Text-Layer versehen.
- Bild-Dateien werden in (OCR-)PDFs umgewandelt.
- Alle anderen Dateien werden ohne Änderung in das Ausgabe-Verzeichnis kopiert.
Nach dem Aufrufen des Skripts sollten sich im Ausgangs-Verzeichnis die gleiche Anzahl Dateien und dieselbe Verzeichnisstruktur befinden wie im Eingangs-Verzeichnis. Die (PDF-)Dateien werden jedoch etwas größer sein, da sie nun einen zusätzlichen Text-Layer beinhalten.
Das Skript ist unter MIT-Lizenz frei auf Codeberg verfügbar, so dass jeder es an die eigenen Bedürfnisse anpassen und erweitern kann.
Aus der Praxis
Mit diesem Skript wurde die Texterkennung von PDFs und Dateien nun weitgehendst automatisiert. Dies kann nun beispielsweise genutzt werden, um Dokumente durchsuchbar in der Cloud abzuspeichern. Im vorherigen Artikel Volltextsuche in Nextcloud (mit OCR) wurde beschrieben, wie man eine Volltextsuche in Nextcloud installieren kann. Hat man nun seine PDF-Dateien mittels OCR mit einem Text-Layer versehen, können diese in der Cloud einfach durchsucht werden.
Wenn man nun z.B. Dokumente mittels Scanner als PDF scannt, landen diese zunächst einmal in einem speziellen Eingangs-Verzeichnis (z.B. /mnt/LinuxShare/OCR/Input – in meinem Fall ist dies eine Netzwerk-Freigabe unter Windows). Anschließend lässt man das Skript für die Texterkennung laufen. Dieses erzeugt in einem Ausgangs-Verzeichnis (z.B. /mnt/LinuxShare/OCR/Output) die mit einem Text-Layer versehenen PDF-Dateien. Nun können diese Dateien in die Cloud hochgeladen werden. Nach dem nächsten Durchlaufen des Cronjobs für Nextcloud werden die neuen Dateien von der Volltextsuche erfasst und können anschließend über die Suche in der Dateien-App gefunden werden (sowohl über den Datei-Namen, als auch über Datei-Inhalte).
Fazit
Nach dem OCR-Scan für PDFs und Bilder können Inhalte dieser Dateien leicht kopiert werden. Darüber hinaus sind die Datei-Inhalte durchsuchbar. Gerade zu Zwecken der Archivierung ist dies unabhängig vom verwendeten Speicherort (Cloud, lokales Dateisystem, etc.) eine äußerst sinnvolle Angelegenheit. Damit kommt man dem „papierlosen Büro“ schon einen großen Schritt näher.
Weiterführende Artikel
- Volltextsuche in Nextcloud (mit OCR)
- Nextcloud auf Ubuntu Server 18.04 LTS mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban
- Ubuntu Server 18.04 LTS als Hyper-V Gastsystem installieren und optimal einrichten
Hallo Jan,
wie gut ist die Qualität der Texterkennung? Mit der kommerzieller Anbieter vergleichbar?
Herzliche Grüße
Michael
Hi Michael,
erfahrungsgemäß funktioniert die Texterkennung ziemlich gut. Leider habe ich keinen Vergleich zu kommerziellen Anbietern.
Allerdings ist das denke ich auch alles eine Frage des Ausgangs-Materials: Wenn der Scan schon schlechte Qualität hat, dann wird die Texterkennung auch nicht sonderlich viel leisten können. Aus der Erfahrung heraus würde ich jedoch sagen, dass es selbst mit Zeitschriften-Artikeln, die mit dem Spartphone abfotografiert worden sind und dementsprechend nur mittelmäßige Qualität haben, sehr gut funktioniert.
Gruß,
Jan
It works, nice
Zunächst einmal, vielen Dank für dieses klasse HowTo ;-)
„Auf der Suche nach Programmen, die PDF-Dateien mit einem OCR-Text-Layer versehen können, gibt es unter Windows leider nicht viele Programme: Diese sind zudem meist kostenpflichtig oder zwingen den Benutzer zu einem bestimmten Workflow bei der Bearbeitung von PDF-Dateien.“
Es gibt auch Freeware Win-Programme die das können, z. B. NAPS2 (https://www.naps2.com/)
Bei Windows mein Standard.
Liebe Grüsse
Hallo Nico,
ja, beim Thema PDF/OCR unter Windows wird die Luft echt dünn. Ich nutze kaum noch Windows, daher hatte ich hier nie meinen Fokus.
Trotzdem danke für den Hinweis, ist sicher auch für andere Windows-User interessant. Und die Software ist sogar noch Open Source!
Gruß,
Jan
Hi Jan,
würdest du diese Dateiablage mit PDF-OCR-Dateien einem DMS vorziehen?
Hi Stefan,
das kommt denke ich immer auf die Anforderungen an: Ein klassisches DMS bietet da schon deutlich mehr und ist extra für die Dokumenten-Ablage und -Verwaltung ausgerichtet. Bei Nextcloud ist dies nur eine Möglichkeit der Nutzung.
Für den privaten Bereich – wenn dir OCRte PDFs ausreichen, die getaggt und durchsucht werden können – kann die Nextcloud-Lösung auch schon ausreichend sein.
Gruß,
Jan
Hallo Jan,
ich bin gerade dabei deine Automatisierung mit dem Script nachzubauen. Funktioniert soweit ganz gut.
Ich habe ein lokales Verzeichnis in nextcloud eingebunden in dem ich die Ausgabe aus dem OCR Durchlauf einspiele. Dieser Ordner gehört dem Benutzer u. der Gruppe www-data. Die Daten aus dem Script Durchlauf gehören aber dem Benutzer root (script läuft als root). Nun mein Problem: die PDF´s können nun aus Nextcloud nicht gelöscht werden. Auf Grund meiner eher spärlichen Linux Kenntnissen ist es mir nicht möglich dieses Problem zu beheben. Hast du eine Idee wie ich das beheben kann?
Vielen Dank im vorhinein für deine Antwort.
Hallo Hermann,
hier gibt es wohl ein Problem mit den Datei-Rechten.
Das Skript für OCR muss auch unter dem User www-data ausgeführt werden, damit die Datei-Rechte so passen, dass diese auch durch Nextcloud geladen/verändert/gelöscht werden können.
Gruß,
Jan
Hallo Jan,
vielen Dank für deine Antwort.
Ich habe das ebenfalls schon versucht – und heute nochmals:
Alle Ordner (‚/home/nextcloud_share_folder/Scan_Eingang‘ u. ‚/home/nextcloud_share_folder/Dokumente_Eingang‘ – Ein u. Ausgabe für OCRmyFiles.sh) und ebenfalls ‚/etc/OCRmyFiles/‘ gehören dem User www-data. Wenn ich den Aufruf unter root direkt mit ‚/etc/OCRmyFiles/OCRmyFiles.sh‘ durchführe wird alles ordnungsgemäß durchgeführt – jedoch die PDF Dateien im Ausgabeordner gehören dem User root und können nicht aus Nextcloud verschoben werden.
Wenn ich unter root den Aufruf des Scripts mit ’sudo -u www-data /bin/bash –login /etc/OCRmyFiles/OCRmyFiles.sh‘ (also als www-data user) dann wird zwar die Datei in den Ausgabe Ordner verschoben jedoch nicht von OCR bearbeitet. Ebenfalls kommen mehrere Fehlermeldungen:
Unter anderem: ‚/bin/bash: /root/.bash_profile: Keine Berechtigung‘
zum Schluss noch: ‚PermissionError: [Errno 13] Permission denied: ‚/root/.reportlab_mods‘
Leider komme ich hier ohne Hilfe nicht weiter. :-(
Vielen Dank
Hallo Hermann,
was passiert, wenn du das OCR-Script per Cron (unter dem User www-data) aufrufst? Sind dann im Syslog ähnliche Fehlermeldungen zu finden, oder klappt das ganze dann?
Gruß,
Jan
Hallo Jan,
ich hoffe das es so richtig ist:
Ich habe mit dem Aufruf „sudo crontab -u www-data -e“ die Crontab des www-data users bearbeitet. Hier der Aufruf mit: */1 * * * * /etc/OCRmyFiles/OCRmyFiles.sh
Leider tut sich nichts.
Vielleicht kannst du mir den genauen Befehl für den Aufruf in der Crontab zukommen lassen.
Vielen Dank
Hallo Hermann,
du rufst das Skript hier ohne Eingabe-/Ausgabe-Verzeichnis auf, d.h. diese Verzeichnisse müssen im Skript selbst definiert werden. Mit dem Aufruf per Cron halte ich den Aufruf jede Minute für etwas knapp. Hier würde ich eher 15 Minuten empfehlen.
Warum sich nichts tut, kann man erst einmal nicht sagen. Um diesem Problem auf die schliche zu kommen, führe das Skript doch mal direkt unter dem User www-data auf der Kommandozeile aus. Vielleicht liefert das einen Hinweis auf einen Fehler, etc.
Gruß,
Jan
Hallo Jan,
ich habe es als cronjob unter www-data zum laufen bekommen.
Der Aufruf war falsch. Es geht bei mir nur mit folgendem Eintrag:
*/15 * * * * /bin/bash -c „/etc/OCRmyFiles/OCRmyFiles.sh“
Die Verzeichnisse habe ich im Script festgelegt. Die 1ne Minute habe ich nur zum Testen eingestellt gehabt.
p.s. in der Root crontab geht es ebenso nur mit /bin/bash -c …..
Vielen Dank
Gruß Hermann
Hallo Hermann,
OK, danke für den Hinweis. Trotzdem ist mir nicht ganz klar, warum das bei dir nicht mit dem direkten Aufruf nicht klappt.
Welche Distribution nutzt du hier?
Gruß,
Jan
Hallo Jan,
Ubuntu 18.04 lts.
Hallo Hermann,
OK, hier kann ich den Crontab-Befehl auch „direkt“ eingeben.
Der Aufruf des Skripts mit dem User www-data auf der Kommandozeile klappt einwandfrei?
Maja, du hast ja aber schon eine Lösung gefunden. Wenn das funktioniert, dann würde ich auch dabei bleiben.
Gruß,
Jan
Danke für die gute Anleitung jedoch.
Das script liegt bei mir aktuell im Scanner Benutzer und wenn ich es ausführen will kommt command not found. Obwohl ich als Root verbunden bin.
Wenn ich ocrmyfiles mit input.pdf und output.pdf eingebe und die verzeichnisse funktioniert es aber per Script nicht. Im Script habe ich nur das Default Input und Output Verzeichnis angepasst. Wohin muss das script denn gespeichert werden um es als crontab anzulegen und was kann die Ursache sein warum er sagt command not found. Installiert auf Ubuntu 18.04 LTS
Hi Michael,
wenn das Script per Crontab aufgerufen werden soll, dann ist immer der absolute Pfad zum Script mit anzugeben. Hier funktioniert dann so etwas nicht:
~/home/user/myscript.shEs muss in diesem Beispiel dann folgendermaßen lauten:
/home/user/myscript.shGruß,
Jan
Hallo Jan,
weißt du, ob man mit einem linux cli tool auch die gescannten Seiten begradigen?
Danke
VG Heinz
Hi,
ja, das müsste mit OCRmyPDF möglich sein. Am besten hier mal in die Dokumentation schauen.
Gruß,
Jan
Hallo Jan,
ich habe ein paar Fragen zu dem Script. Möchte zunächst aber erst mal erklären was ich vor habe.
Das Script möchte ich automatisiert über inotiywait gesteuert aufrufen.
Darin sehe ich den Vorteil das die Dateien sofort verarbeitet werden. Das Quellverzeichnis braucht in der NextCloud überhaupt nicht sichtbar werden.
Die fertigen Dateien könnten entweder über einen webdav mount, oder durch einen passenden curl Befehl direkt in die Cloud Struktur eingefügt werden.
Alternativ könnte man sie auch einfach hineinkopieren und einen file scan anstoßen.
Damit würde man als Anwender die Dokumente quasi sofort nach dem Scanvorgang vorfinden.
Ist die Nutzung der Funktion „cleanup_inputDir“ wirklich sicher?
Meine bash Kenntnisse reichen leider nicht um das mit Bestimmtheit sagen zu können.
Was passiert denn, wenn genau nach der Bearbeitung des letzten Dokumentes noch ein weiteres Dokument in das Quellverzeichnis hineinkommt.
Wird das dann nicht durch den Lösch-Befehl auch gleich entfernt, ohne bearbeitet worden zu sein?
Gruß
Henning
Hallo Henning,
also das Skript ist erst einmal nicht dafür gedacht, eine dauerhafte Überwachung mit sofortiger Umwandlung durchzuführen. Die Arbeitsweise ist hier eher: Zu einem gewissen Zeitpunkt x werden alle PDFs umgewandelt. Daher kann z.B. auch nicht garantiert werden, dass eine Datei umgewandelt wird, die genau zu zu einem Zeitpunkt in das zu überwachende Verzeichnis hinzugefügt wird, wenn das Skript gerade am Umwandeln ist.
Hier müsste man dann eine „zusätzliche Schicht“ einführen: Überwacht (inotifywait) wird hier nicht das Input-Verzeichnis des Skripts, sondern ein anderes Verzeichnis. Wenn notifywait dann eine neue Datei feststellt, muss diese Datei in das Input-Verzeichnis des Skripts verschoben werden. Anschließend wird das Skript aufgerufen. Während das Skript läuft, muss die Überwachung von inotifywait pausiert werden, so dass keine neuen Dateien hinzukommen. Wenn das Skript fertig ist, wird inotifywait wieder „scharf geschaltet“.
Auf diese Weise wird die Erfassung der Dateien und das eigentliche Umwandeln in zwei Schritte aufgeteilt. Damit sollten dann keine Dateien „unter den Tisch fallen“.
Gruß,
Jan
Hallo!
Danke für die prima Anleitung und das tolle Script.
Ich lasse das im Moment auf einem Pi2 laufen und es dauert schon ne Weile bis ein Dokument fertig ist.
Kann man damit rechnen, dass es auf nem Pi3 oder gar Pi4 deutlich schneller läuft?
Hi,
also letzten Endes ist ein Raspi 4 schon deutlich schneller als seine Vorgänger. Daher ja, sollte auf einem 4er schneller laufen. Erwarte allerdings keine Wunder…eine OCR-Bearbeitung „in Echtzeit“ wirst du hier auch nicht bekommen.
Gruß,
Jan
Naja, Raspi 4 ist bestellt – der hat ja auch mehr Ram, vielleicht boosted der ganze ja auch noch.
Ich kann ja berichten bei Interesse.
Hi,
ja, ein Erfahrungsbericht wäre hier sicher interessant.
Gruß,
Jan
Also, das Skript läuft auf einem Raspi4 4GB deutlich schneller. Gefühlt würde ich sagen mindestens Faktor 2 bis 3, vielleicht sogar mehr (ich hab’s leider nicht gemessen).
Ich habe jetzt noch folgendes Setup-Problem:
kann man Dein Skript irgendwie automatisch laufen lassen? Also z.B. einmal pro Stunde?
Oder wenn eine Datei im input Ordner erkannt wird?
Ich habe auf github in dem OCRmyPDF Projekt gesehen, dass es ein „watcher.py“ Skript was diese Ordnerüberwachung im Grunde macht, ich krieg das aber irgendwie nicht auf dem Raspi zum laufen. Ich weiß nicht ob das evtl nicht für Raspi gedacht ist.
Hi,
danke für die Rückmeldung. Ich hätte nicht gedacht, dass es auf einem Raspi 4 so viel schneller ist.
Automatisieren kannst du das ganz einfach per Cron (z.B. alle x Minuten). Mit der aktiven Überwachung eines Verzeichnisses habe ich mich noch nicht beschäftigt, daher kann ich dazu leider wenig sagen.
Gruß,
Jan
ich bin unsicher mit crontab…passt das so (alle 15 Minuten läuft das Skript)
*/15 * * * * sudo ./home/pi/OCRmyFiles.sh
Hi,
ich rufe das bei mit so auf:
*/15 * * * * /home/scripts/OCRmyFiles.sh "/pfad/zur/quelle" "/pfad/zum/ziel" > /dev/null 2>&1Wichtig ist hier die Angabe des absoluten Pfad zum Skript. „sudo“ kannst du dir sparen, wenn du das über den Crontab des Root-Users machen willst, hier wird dann alles mit Root-Rechten ausgeführt.
Gruß,
Jan
Hi Jan,
ich schon wieder. Hast Du ne Idee wie ich das ganze jetzt in Docker bringen kann? Ich finde keinen ocrMyPdf Docker Container für Raspberry.
Hi,
was heißt „kein Docker-Container für Raspi“? Sollte das gerade wegen Docker nicht unabhängig von der darunter liegenden Architektur sein? Was passiert, wenn du den Container auf dem Raspi starten willst?
Gruß,
Jan
Naja, der Container ist halt nicht für ARM vorgesehen..
Und der nicht offizielle Container läuft nicht
Hi,
das scheint dann vermutlich eine Komponente nicht kompatibel zu sein. Was passiert, wenn du dir aus dem Dockerfile ein eigenes Image baust? Vielleicht kann man das mit etwas Basteln auf dem Raspi zum Laufen kriegen.
Gruß,
Jan
Hallo,
ich habe das Script in mein Home Verzeichnis in den Unterordner „Scripts“ gelegt. Welche Rechte sollte ich vergeben?
Danke
Carsten
Hi Carsten,
das Skript braucht für die Ausführung eigentlich nur ein „chmod +x“. Ansonsten braucht der User, der das Skript ausführt, noch Rechte auf die Verzeichnisse/Dateien, die vom Skript verarbeitet werden sollen.
Gruß,
Jan
sehr gut, ich benutze das Skript auf dem Mac, ich musste nur
tmp=“${i//“$inputDir“/““}“ zu tmp=“${i//“$inputDir“/}“ ändern, dann läuft es gut durch.
Wow. Großartig zum Zeitsparen. Vielen Dank. Habe das ganze mit Ubuntu unter Windows gemacht und funktioniert einwandfrei. Durch dein Script auch ganz schnell zig files verbessert 👍
Qualität war etwas schlechter als direkt mit NAPS2 (manche Sachen wurden durch NAPS2 erkannt, die ocrmypdf ignoriert hatte) dafür schneller und batch modus möglich.
Was ich machen musste noch war (nachdem ich dein Script mit Windows (daher CRLF Zeilenende) gespeichert hatte) war es mit dos2unix zu LF zu ändern. Wäre natürlich auch direkt gegangen). Ansonsten kam die Meldung „-bash: ./ocrmyfiles.sh: /bin/bash^M: bad interpreter: No such file or directory“.
Nachdem ich das Script auf meinem Desktop im Ordner pdf gespeichert hatte, war das Ergebnis dann auch einfach zu erreichen.
– cd /mnt/c/Users/alex/Desktop/pdf
– ./ocrmyfiles.sh input/ ocr/
Danke für das Tool und Tutorial. Hatte schon mit dem Gedanken gespielt mir Acrobat für den Blödsinn zu kaufen 😅 Geht ja auch so.
Hi Alex,
ja, wieso Geld ausgeben, wenn da auch Open Source Lösungen gibt? ;-)
Danke für deine Erkenntnisse. Ich hatte das ganze bisher nur unter Linux am Laufen, aber es scheint ja auch unter Windows zu gehen.
Gruß,
Jan