PDFs in Text konvertieren / OCR Software. Tipps gesucht

Ach, f… ey. Da will ich das mal mit tesseract probieren, und das Ding will und will nicht laufen:

Code:
[DS] Profile file not available (tesseract_opencl_profile_devices.dat); performing profiling.

[DS] Device: "Intel(R) Core(TM) i7-3615QM CPU @ 2.30GHz" (OpenCL) evaluation...
OpenCL error code is -54 at   when clEnqueueNDRangeKernel .
OpenCL error code is -54 at   when clEnqueueNDRangeKernel kernel_HistogramRectAllChannels .
OpenCL error code is -54 at   when clEnqueueNDRangeKernel kernel_HistogramRectAllChannelsReduction .
OpenCL error code is -54 at   when clEnqueueNDRangeKernel kernel_ThresholdRectToPix .
Setting return value to -1
[DS] Device: "Intel(R) Core(TM) i7-3615QM CPU @ 2.30GHz" (OpenCL) evaluated
[DS]          composeRGBPixel: 0.000167 (w=1.2)
[DS]            HistogramRect: 340282346638528859811704183484516925440.000000 (w=2.4)
[DS]       ThresholdRectToPix: 340282346638528859811704183484516925440.000000 (w=4.5)
[DS]        getLineMasksMorph: 0.004269 (w=5.0)
[DS]                    Score: inf

[DS] Device: "HD Graphics 4000" (OpenCL) evaluation...
[DS] Device: "HD Graphics 4000" (OpenCL) evaluated
[DS]          composeRGBPixel: 0.010907 (w=1.2)
[DS]            HistogramRect: 0.261216 (w=2.4)
[DS]       ThresholdRectToPix: 0.005070 (w=4.5)
[DS]        getLineMasksMorph: 0.017349 (w=5.0)
[DS]                    Score: 0.749564

[DS] Device: "GeForce GT 650M" (OpenCL) evaluation...
[1]    13643 illegal hardware instruction  tesseract --list-langs

Egal was ich versuche, immer Abbruch mit "illegal hardware instruction". :-/ Probiert mit der stable 3.0.5 und mit der alpha 4.0 (via brew).

Eigentlich hab ich weder die Zeit, noch den Nerv (ich bin schon wegen Vodafon/KD genervt genug) auf diesen Mist. Auf der anderen Seite brauche ich mal eine brauchbare Lösung.
 
Ach mist, hab beim letzten Versuch --with-opencl vergessen zu entfernen. Mal schauen ob es doch noch was wird.
 
Gna… jetzt läuft es, aber mit dem schlechtesten aller bisherigen getesten OCRs. Da kommt fast nichts lesbaren bei heraus. Aus geneu der Datei, woraus Finereader ein fast gutes Ergebnis produziert. :-(

Das meine ich damit, als ich meinte, daß ich den Aufwand scheue, der offenbar nötig ist überhaupt brauchbare Ergebnisse zu erziehlen. Und das jetzige Ergebnis ist derart schlecht, daß ich gerade Zweifel hab, ob es sich überhaupt lohnt sich damit weiter zu beschäftigen.
 
Das war eben mit der v3. Mit der v4alpha mit dem neuen LSTM (neuronal net). Klappt es jetzt super.
 
Das wundert mich jetzt. Tesseract wird gelobt und dann geht es nur mit der Alpha. Aber die Zeit war nicht vergeudet. Wenn Apple in die immer angekündigte Pleite geht, kannst Du auf Linux umsteigen falls Du kein Windows magst. ;)
 
Das wundert mich jetzt. Tesseract wird gelobt und dann geht es nur mit der Alpha. Aber die Zeit war nicht vergeudet. Wenn Apple in die immer angekündigte Pleite geht, kannst Du auf Linux umsteigen falls Du kein Windows magst. ;)
Du vermagst immer das Posive zu sehen, in all dem Elend. :)
 
Das Problem, was jetzt zu lösen ist: einen eleganten Workflow von Scanner --> einzelne JPGs --> FTP --> Hazel --> OCR --> durchsuchbares PDF --> Zielordner. Und mit elegant meine ich auch, daß alles nötige an einem Punkt zu finden ist und nicht über 10 Scripte an 5 Orten auf der Platte verstreut, so daß man sich bei kleinen Änderungen einen Wolf sucht. :)

Schade, daß FineReader bzgl. Automation so gar nichts zu bieten hat, außer diesen einen Baustein für Automator. Das wäre schon sehr sehr Hilfreich gewesen, wenn man dort mit relativen Pfaden (incl. ./) arbeiten könnte. Dann hätte man "nur noch" das lästige Aufpoppende-Fenster-Problem. Die hätten sich keinen Abgebrochen, wenn sie da einen Hacken für "kein Fenster öffnen" eingebaut hätten. Als wenn das von denen nie einer wirklich mal ausprobiert hat.
 
wenn's um ftp-folder/OCR/alte-files-abräumen/OCR-files-verschieben-nach-ziel geht, dann kann man das gut mit einem queuedirectories-launchagent+shellscript machen.
 
Ich werde es mir mal ansehen, danke für den Tipp. Allerdings würde ich schon gerne den Weg über Hazel gehen, weil es instantan auf neue Dateien reagiert. Dann kann man auch längere Scan-Sessions so abarbeiten, daß der Flow kontinuierlicher ist (jeder fertige Scan -> OCR vs alle x Minuten die fertigen Scans -> OCR). Mal schauen.

Vermutlich werde ich vom Scanner doch lieber PDFs anstelle von Einzel-JPGs erzeugen lassen, um damit das Problem des "welche Datei gehört zu welchem Dokument" und doppelte Dateinamen, wenn man versehendlich den Namen vor dem Scan nicht eingegeben hat. In Verbindung mit dem Launchagent wäre bei Einzel-JPGs das Problem, daß der Agent mitten in einem Scan loslegen könnte und Dateien, die eigentlich zusammen gehören als zwei Dokumente behandelt werden.

Es gibt da viele potenzielle kleine "Fail"stricke, die es zu beachten gilt. Deshalb hab ich mich ja so sehr gegen diese Variante gesträubt. Hätte der Automator-Workflow von Finereader diese kleinen Optionen gehabt, die ich vermisse, wäre der Drops schon nach 5 Minuten gelutscht gewesen. Und so zieht sich das jetzt über Tage, bis der Workflow wirklich vertrauenswürdig (ich will nicht ständig überprüfen müssen, ob da irgendwas abhanden/durcheinander gekommen ist) stabil läuft. An sich stehe ich ja auf derartige "frickelei", nur hab ich eigentlich gerade nicht die Zeit dafür.
 
@Olivetti: eine kleine OT-Frage an dich: gibt es eine Möglichkeit eine GUI-Anwendung im Kontext eines speziellen Users schon zum Log-in-Screen headless zu starten? Ich würde gerne eine Kodi-Instanz, die ausschliesslich per Android bedient, nur Musik spielen soll, unter einem Nutzer "kodi" zusätzlich zu einem eingeloggten User laufen lassen. So könnte ich auch eine zweite Kodi-Instanz laufen lassen, die Audio + Video macht. Das Audio geht über diverse Audio-Out auf eine Audio-Matrix.

Hab ich da eine Chance? Falls es klappt, würde ich das nochmal in einem extra Thread beschreiben, wie man solch ein Setting aufbaut und benutzt.
 
Was mich ja auch an OCR-SW nervt ist, wenn sie selbst auch nochmal das Bild herunterrechnen wollen. Mein Scanner macht sehr schön kleine PDFs und wenn mir dann eine SW nochmal an dem verlustbehaftet kleingerechneten Bild nochmals mit verlustbehafteten verfahren versucht dran herumzurechnen, kommt i.d.R. (in meinem Fall) nur Murks heraus. Entweder ist das PDF am Ende sogar etwas größer und/oder es ist deutlich schlechter lesbar.
 
jeder fertige Scan -> OCR vs alle x Minuten die fertigen Scans -> OCR
kannst du machen, wie du's brauchst. siehe queuedirectories vs. watchpaths in launchd.

In Verbindung mit dem Launchagent wäre bei Einzel-JPGs das Problem, daß der Agent mitten in einem Scan loslegen könnte und Dateien, die eigentlich zusammen gehören als zwei Dokumente behandelt werden.
pdf sind dabei sowieso geeigneter, weil nur die scanSW wissen kann, ob einzel- oder multidokument. ansonsten müsstest du das via file(s)-benennungsregel lösen.

gibt es eine Möglichkeit eine GUI-Anwendung im Kontext eines speziellen Users schon zum Log-in-Screen headless zu starten?
könnte theoretisch gehen, wenn du kodi-kodi und login-user-kodi auf verschiedene screens legst.
für kodi-kodi legst du einen script-starter an, der den user auf kodi wechselt und dann startet.
gibt es denn keine geeigneten headless-audioserver für macos?

und wenn mir dann eine SW nochmal an dem verlustbehaftet kleingerechneten Bild nochmals mit verlustbehafteten verfahren versucht dran herumzurechnen
das sollte aber vermeidbar sein. in tesseract müsste das m.W. einstellbar sein.
 
kannst du machen, wie du's brauchst. siehe queuedirectories vs. watchpaths in launchd.
Danke für die Stichworte.

pdf sind dabei sowieso geeigneter, weil nur die scanSW wissen kann, ob einzel- oder multidokument. ansonsten müsstest du das via file(s)-benennungsregel lösen.
Das Blöde ist, daß tesseract nur Bilddateien frisst, aber leider keine mehrseitigen TIFFs. Daher muß ich als Vorstufe das PDF erstmal zerlegen und dabei hoffen, daß es einen Weg gibt, daß dabei nicht an den Bildern herumgerechnet wird. Ich hab keine Lust >=300dpi-Bilder mit fast keiner kompression scannen zu müssen. Das würde alle Schritte doch arg in die Länge ziehen. Finereader hat die Meßlatte schon relativ hoch gelegt, unter die ich eigentlich nicht möchte. Und Finereader erreicht das mit 150dpi. Für tesseract teste ich mit 200dpi, was ich auch noch vertretbar finde. Aber 300, 400 oder gar 600dpi ergibt einfach zu fette Dateien, was den Scan-Vorgang auch ziemlich ausbremst. Sicherlich ist das für diese Auflösung nicht soo schlecht, aber verglichen mit 150/200dpi ist das ein Unterschied wie Tag und Nacht und ist um so stärker ausgeprägt, je mehr Seiten ein Dokument hat. Bis 7 Seiten laufen die Seiten in einem Zug auf Maximalgeschwindigkeit durch. Ab da gibt es dann immer wieder Gedenkminuten. Bis vor kurzem hatte das Gerät noch 512MB und hatte ab der 4. Seite mit dem Nachdenken angefangen. Leider gibt es von diesen RAM-Riegeln keine 2GB-Module. :)

In dem Scanner werkelt ein alter AMD Geode 500MHz mit nur 1GB RAM. Das Gerät hat übrigens zwar auch OCR, aber das erreicht ebenfalls nicht die Qualität, wie ich es haben will.

könnte theoretisch gehen, wenn du kodi-kodi und login-user-kodi auf verschiedene screens legst.
für kodi-kodi legst du einen script-starter an, der den user auf kodi wechselt und dann startet.
gibt es denn keine geeigneten headless-audioserver für macos?
Das Problem ist, daß der Audio-Only-Kodi in einer komplett eigenständigen Umgebung laufen muß, da es sich sonst die Daten mit dem Audio/Video-Kodi teilen möchte, was es dann wieder unmöglich macht sie auf unterschiedlichen Audio-Ausgängen herausspielen zu lassen. Die Windows-Version bietet die Möglichkeit, aber leider nicht die OSX-Version. Deswegen hab ich gehofft, daß es irgendeinen Trick gibt GUI-Apps noch vor dem Login-Screen headless starten zu lassen. Das hätte das Problem gelöst.

das sollte aber vermeidbar sein. in tesseract müsste das m.W. einstellbar sein.
Bis vor kurzem hat tesseract nur Bilder als ein/ausgabe akzeptiert. Ich meine ab der letzen 3er oder der 4.0alpha kann es auch direkt PDFs mit unsichtbarem Text-Layer direkt erzeugen. Nur deshalb ist es überhaupt noch bei mir in der Auswahl. Aber ob es an den Bildern herumrechnen will weiß noch nicht.
 
schau dir auch mal entsprechende OCR-wrapper, wie OCRmyPDF oder pdfsandwich an, evtl. kommst du damit weiter.

was es dann wieder unmöglich macht sie auf unterschiedlichen Audio-Ausgängen herausspielen zu lassen.
daran könnte es eh' scheitern, weil du das unter macos nicht headless konfigurieren kannst. solange es keine kodi-headless-server-version gibt, wird das aus meiner sicht nix. warum muss es kodi sein, aus tagging und verwaltungsgründen? die letzte rettung wäre dann immer noch kodi in einer VM.
 
Es soll Kodi aus zwei Grunden sein:
  1. Ich finde Kodi gut :)
  2. Für Android gibt es die geniale Kodi-Fernbedienung Yatse. Der Clou an dem Ding ist, daß man sich Audio- und Video-Inhalte aufs Gerät streamen lassen kann, was ich sehr häufig nutze (auch während jemand ein Video auf dem TV schaut und schon andere Streamen). Z.B. beim Ins-Bett-Bringen der Kinder streame ich gerne Musik aufs Smartphone, um es dann via Bluetoothlautsprecher zu hören. Das kann sonst keine Fernbedienung. Ich könnte mir sogar Inhalte aufs Gerät runterladen (im Grunde so wie man bei Netflix filme herunterladen kann), ums dann Offline zu schauen. Darauf möchte ich definitiv nicht verzichten. Auch sonst ist es eine Klasse App. Sie speichert die Metadaten auch auf dem Gerät, so daß ich auch offline in der Lib herumwühlen kann.
Ich hab mir früher auch mal Plex angesehen, aber zumindest das Frontend hat mir überhaupt nicht zugesagt. Und mittlerweile braucht man dafür wohl auch ein Login. Und darauf hab ich überhaupt keine Lust.
 
ich würde mir mopidy/moped oder halt irgendwas mpd-mässiges installieren.
 
Liebe Community Member,

vorab - nein, ich habe den thread nicht vollständig gelesen. Ich dreh jetzt allerdings auch leicht am Rad.

Meine Frage ist folgende, was genau sind "durchsuchbare PDF"? Wie erstelle ich die? Sind nicht alle PDF durchsuchbar?

Hintergrund - ich wollte soeben meine Abschlussarbeit hochladen und sehe, dass die PDF "durchsuchbar" sein muss.

Die Arbeit ist auf Word 2007 geschrieben und mit CMD+P als PDF gesichert.

Öffne ich diese Datei nun in Vorschau und drücke CMD+F kann ich die Datei durchsuchen.

Oder hat das eine gar nichts mit dem anderen zu tun?

Kann mir hier jemand bitte einmal einen Crashkurs verpassen und mir auf die Sprünge helfen?

Besten Dank im Voraus!
 
Wenn du eine PDF aus einer Textverarbeitung wie Word erzeugst, oder über andere Tools aus einem derartigem Textdokument, sollte das PDF eigentlich immer durchsuchbar sein, da der Text im PDF wirklich auch Text ist.

Anders ist es, wenn du Dokumente über einen Scanner einscannst und daraus ein PDF erhälst. Dann ist das Ergebnis ein PDF, dessen einzelnen Seiten jeweils ein Bild des gescannten Dokuments sind. Um sie durchsuchbar zu machen, musst sie durch eine Texterkennung (OCR) laufen lassen. Idealerweise erhälst du dann als Ergebnis ein PDF, was wie das ursprüngliche PDF ausschaut, welches aber zusätzlich einen unsichtbaren Text-Layer über den Bildern hat, die den erkannten Text enthält. Dieser Text ist dann durchsuchbar. Die OCR-SW sollte die Skalierung des Textes so gewählt haben, daß die Wörter immer deckungsgleich mit den entsprechenden Wörtern der Bildebene sind. So kannst du dann ganz gezielt auch Text markieren und es schaut dabei so aus, als würdest du den Text der Bildebene auswählen können.

Ich hoffe es ist einigermaßen verständlich. :)
 
  • Gefällt mir
Reaktionen: tamuli, Ahrsib, Maren und eine weitere Person
Zurück
Oben Unten