staging.inyokaproject.org

Danke dir Hank!

Funktioniert bei mir gut unter Trusty mit xsane aus den Repositories mit einem HP Officejet 5500 der via usb am Raspberry Pi hängt und als Netzwerkscanner läuft.

Hi!

mtron, dich gibts noch ?! ☺ Schön von dir zu hören! Welche Version hast du ausprobiert? Bin noch am rumbasteln, um "Riesen-PDFs" zu verhindern, stelle ich demnächst wohl ins Wiki (siehe auch PDF). Mein Favorit ist ja die OCRmyPDF-Version 😉

so long

mtron, dich gibts noch ?!

Natürlich. Unkraut vergeht nicht 😉 Ich habe gerade die Version aus dem wiki mit meinem aktuellen Dienstvertrag probiert (die Dinger werden auch immer länger und unverständlicher...) Da ist es fein wenn man den schnell bei der Hand hat und stichwortartig das pdf durchsuchen kann. Ich muß sagen dass das Ergebnis ausgezeichnet ist. Vor ~ 10 Jahren als ich es das letzte mal unter damals noch debian probiert habe war OCR unter Linux unbrauchbar dagegen ist das Ergebnis dank google jetzt wirklich sehr gut.

Mein Favorit ist ja die OCRmyPDF-Version

Das werde ich mir sicher anschauen, Danke für den Tipp!

Hi!

mtron schrieb:

Ich habe gerade die Version aus dem wiki mit meinem aktuellen Dienstvertrag probiert (die Dinger werden auch immer länger und unverständlicher...) Da ist es fein wenn man den schnell bei der Hand hat und stichwortartig das pdf durchsuchen kann. Ich muß sagen dass das Ergebnis ausgezeichnet ist. Vor ~ 10 Jahren als ich es das letzte mal unter damals noch debian probiert habe war OCR unter Linux unbrauchbar dagegen ist das Ergebnis dank google jetzt wirklich sehr gut.

Ja, da ist etliches passiert... Die xsane2sandwich-Version aus dem Wiki? Dann ist es aber wohl nicht tesseract 3.03, was bei dir läuft? Damit bekomme ich zumindest mit der WIki-Version bzw. mit hocr2pdf und den von tesseract produzierten hOCR-Dateien gar nichts vernünftiges mehr hin. Daher auch die Versionen mit OCRmyPDF; die xsane2TesPDF-Version mit tesseract und der pdf-Konfiguration ist eher ein Schnellschuss, da kann man recht wenig dran drehen, Ausgabe wird riesig (da muss ich auch noch nacharbeiten)...

Mein Favorit ist ja die OCRmyPDF-Version

Das werde ich mir sicher anschauen, Danke für den Tipp!

Gute Software (also OCRmyPDF) verdient Werbung 😉

so long
hank

Heinrich Schwietering schrieb:

XSane-"Plugin" zum Erstellen durchsuchbarer PDF-Dateien mit tesseract

Download xsane2tesseractPDF

Geniales Skript, das Ergebnis ist wirklich gut. Hinweis: Beim Beenden von XSane werden allerdings (bei mir) die Textdateien (0 Byte) nicht gelöscht.

TausB

Hi!

Danke!

Hast du bei der Dateiangabe eine Endung mit angegeben? Mal weglassen, ansonsten am Ende des Skriptes einen rm-Befehl mit der verwendeten Endung dazu schreiben ( rm "$FILE_OUT.txt")

so long
hank

Heinrich Schwietering schrieb:

... Mir ist allerdings nicht ganz klar, wo der Unterschied zwischen Verfasser, Hersteller und Ersteller liegt...

Falls ich Du da noch Interpretationsvorschläge brauchst:

• Verfasser: Der "Erfinder" des Textes, z.B. der Chef.

• Hersteller: Die Firma, für die er arbeitet oder das Programm mit welchem das PDF erstellt wird.

• Ersteller: Die Sekretärin, die den Text schreibt.

@Heinrich Schwietering,
Da es mittlerweile viele unterschiedliche Skripte von Dir gibt, ich aber ein spezielles gerade nicht finde, brauche ich Hilfe und oder einen Link. Ich verwende z.Z. xsane2tesseractPDF, gibt es auch eine Version mit Rechtschreibprüfung? Also workflow sollte so sein:

• Scannen mit xsane

• OCR-Erkennung per Skript mit

• Rechtschreibprüfung (damit später gesuchte Stichworte nicht zufällig ein Leerzeichen enthalten und daher nicht gefunden werden)

• Gute Lageerkennung des Textes

Wunsch-Ergebnis: PDF mit durchsuchbarer rechtschreibgeprüfter (evtl. mit LanguageTool?) Textebene.

Eigentlich bin ich mir fast sicher über so etwas schon einmal gelesen zu haben, aber ich finde es nicht wieder ...

TausB

EDIT
Leider ist die eingebettete Schrift im PDF-Viewer beim Markieren nur als Balken erkennbar. Wie kann die Eigenschaft der eingebetteten Schrift so verändert werden, das der Text beim Markieren lesbar wird? Im Bild-Beispiel entsprechen die ersten 2 Blöcke dem Ergebnis bisher. Die unteren beiden Blöcke zeigen ein unter Windows erstelltes PDF, bei dem der Text offensichtlich anderes eingebettet wird: Die Schrift ist bei Markierung prima zu lesen. Natürlich wurden beide Dateien mit dem gleichen Viewer (evince) betrachtet.
\EDIT

Hi!

LanguageTool ist mir noch gar nicht untergekommen, da müsste ich erstmal passen, werd' ich mir aber bei Zeiten mal zu Gemüte führen.

Rechtschreibprüfung ist mit der direkten PDF-Erstellung von tesseract (und damit leider auch für xsane2tesseractPDF) nicht möglich. Wie man die Markierungen "lesbar" bekommt, weiß ich leider auch nicht. Wäre ggf. beides ein "Issue" auf der tesseract-Seite wert; vielleicht gibts sogar schon was dazu, war länger nicht auf der Seite.

Die hocr2pdf-Funktion aus ExactImage funktioniert momentan leider mit tesseract auch nicht mehr, sodass momentan meines Wissens nach nur mit gscan2pdf eine Korrektur möglich ist; allerdings ist das ziemlich unkomfortabel...

so long
hank

EDIT: Vielleicht hattest du xsane2speech im Sinne, als du funktionierende Rechtschreibprüfung in Erinnerung hattest? Eignet sich aber leider nicht für PDF-Erstellung. Ansonsten gibt es zwar ein Firefox-Plugin, um hOCR-Dateien etwas komfortabler zu bearbeiten, aber da die auf hocr2pdf basierenden PDF-Erstellugen alle mehr oder weniger unbrauchbar geworden sind, ist das auch keine Lösung mehr, wo oben schon angemerkt...

Ansonsten könntest du es mit dem DjVu-Format (xsane2djvu) versuchen, in djvusmooth kann man ebenfalls Korrekturen vornehmen. Auch nicht "automatisiert", aber da hat man zumindest einen besseren Gesamtüberblick über den Text als in gscan2pdf.

Heinrich Schwietering schrieb:

... Wie man die Markierungen "lesbar" bekommt, weiß ich leider auch nicht. Wäre ggf. beides ein "Issue" auf der tesseract-Seite wert; vielleicht gibts sogar schon was dazu, war länger nicht auf der Seite.

Habe etwas geforscht und getestet. Meine These: Die Reihenfolge der Bild- und Textebene sind "nur" vertauscht. Leider habe ich keinen Parameter gefunden, der darauf Einfluß nimmt. EDIT: Oder kann pdftk die Layer tauschen? (Ist der Bildlayer eine Art Wasserzeichen zum Textlayer?) /EDIT. tesseract hat ja ein config-file mit unzähligen Parametern, aber das ist mir zu kompliziert, ich verstehe es nicht ...Bei der Ausgabe von ocrmypdf ist der Text lesbar EDIT2, leider ist die Erkennung deutlich schlechter, daher keine Alternative. Kann man das nicht mischen? Der Erkennung mit den einem Tool, die PDF-Erstellung mit dem anderen ... 😲 Weitere Tests (s.u.) beweisen das Gegenteil .../EDIT2

EDIT: Vielleicht hattest du xsane2speech im Sinne, als du funktionierende Rechtschreibprüfung in Erinnerung hattest?

Ja - das war es!

Eignet sich aber leider nicht für PDF-Erstellung.

☹

Danke für Deine Antworten
TausB

Das Skript xsane2OCRmyPDF Version 0.2 macht leider Probleme.

• Zum Testen habe ich eine Buchseite verwendet, zur Anschauung siehe Test150dpials.jpeg.

• Scannereinstellung immer 600 dpi Black und White - Lineart

  • 1. Scan: als PDF ohne OCR ▶ Dateigröße: 826KB

  • 2. Scan: als "Txt", daher mit direkter OCR ▶ PDF-Dateigröße: 7,8MB (!)

• Umwandlung PDF aus 1. Scan mit OCRmyPDF (Version 7.10.2014) ▶ Dateigröße: 1,0MB

• Kontrolle mit gimp, was für eine Auflösung die OCR.PDF haben:

  • PDF mit xsane2OCRmyPDF: 1200 dpi - darum ist die Dateigröße vermutlich auch so groß; trotz: unverändeter Zeile:
    

    convert "$FILE_PATH" -resize $SIZE -units PixelsPerInch -density 300x300 "$FILE_OUT.1.pdf" 1>&2

    hier scheint das Problem zu liegen - die Auflösung wird verdoppelt/vervierfacht.

  • PDF mit OCRmyPDF: 600 dpi

• Der Textlayer ist bei beiden PDF mit einem PDF-Viewer lesbar. 👍

• Die Texterkennung ist auf dem zweiten Blick wirklich exzellent! Warum erst auf den zweiten Blick?

  • Versucht man im PDF einzelne Wörter zu markieren, werden manche Worte optisch ausgelassen, siehe Text_fehlt_scheinbar.png.

  • Wird jedoch der gesamte Text markiert zeigen sich alle vermeintlichen Fehlstellen als doch vorhanden, siehe Alles_markiert.png.

  • Die Lage und Größe der Textboxen zeigen keine negativen Auffälligkeiten.

Mein Resümee:

• Das Skript xsane2OCRmyPDF verschlimmert in der vorliegenden Version die sehr guten Scanergebnisse von OCRmyPDF durch unnötiges Aufblähen der Dateigröße.

• Leider fühle ich mich außer Stande das xsane2OCRmyPDF so zu modifizieren, dass die Nutzung praktisch, aber die Original-Qualität von OCRmyPDF erhalten bleibt.

Nun mein Wunsch an Heinrich Schwietering: Bitte ändere das xsane2OCRmyPDF-Skript (ist doch bald Weihnachten)... 😎

TausB

Hi!

Auf die schnelle: Die Dateigröße liegt vermutlich an der 600-Auflösung; die ist im Normalfall auch übertrieben (wenn du nicht gerade Buchstaben im Zehntel-mm-Bereich scannst..); eigentlich sollten 300 dpi für Buchscans dicke ausreichen. Meiner Erfahrung nach sinkt die Erkennungsqualität mit höheren Werten sogar, weil mehr "Rauschen", kleine Flecken, Papierunebenheiten etc, "vergrößert" werden, und das zu Fehl-Erkennungen führt.

Ich kann das mit dem xsane2OCRmyPDF-Skript so noch nicht nachvollziehen, aber ich verwende auch nur 300-dpi-Scans; kann es die Tage aber nochmal überprüfen. Vielleicht schaust du dir derweil auch mal pdfsandwich an, da kannst du ziemlich genau anpassen, wie groß deine Ergebnisse werden sollen.

so long
hank

Hallo Heinrich Schwietering,

meine Kernaussage war: Obwohl nur mit 600dpi gescannt, hatte das durch xsane2OCRmyPDF erstellte PDF eine Auflösung von 1200dpi (!). Die Auflösung hat sich also durch das Skript verändert (!) Ansonsten ist mir klar, dass ich mit geringerer Auflösung kleinere Dateien bekomme ... 😛 Und ja, normal verwende ich auch nur 300dpi. Da ich mit OCRmyPDF sehr zufrieden bin, ist pdfsandwich keine Alternative. Netter wäre es ein xsane-Skript zu verwenden, welches die Auflösung nicht heraufgesetzt.

TausB

Hi!

Ja, schon klar. Versuch mal, im Skript den -density 300x300-Wert auf 600x600 zu setzen, sollte zumindest die Größe wieder auf das Ausgangsmaß setzen, zumindest wenn du 600 dpi verwenden möchtest.

so long
hank

Heinrich Schwietering schrieb:

Hi!

Ja, schon klar.

Mir nicht, ich scheine da ein Verständnisproblem zu haben. ☹

Versuch mal, im Skript den -density 300x300-Wert auf 600x600 zu setzen, sollte zumindest die Größe wieder auf das Ausgangsmaß setzen, zumindest wenn du 600 dpi verwenden möchtest.

Ja das kann ich bestätigen, funktioniert.

Also wenn der -density DPI-Eintrag geringer als die eingestelle Scan-DPI ist, wird eine PDF mit höhere Auflösung erstellt? Kannst Du mir zum Verständnis die Logik dahinter kurz erläutern? 😎

Daher ich muss das Skript je nach Bedarf vorab manuell anpassen: Der -density Eintrag muss immer dem eingestellten Wert beim Scannen übereinstimmen?!

...

Habe noch einmal alles mit 300dpi (-density und xsane) getestet. Ein Phänomen bleibt: Die mit dem Skript erstellte PDF ist signifikant größer (DPI ist aber 300 geblieben) als wenn ich mit den gleichen Einstellungen das PDF manuell mit OCRmyPDF erstelle. Wie kann das sein? Das Skript zum Aufrufen von OCRmyPDF sollte doch eigentlich darauf keinen Einfluss haben?!

Danke im voraus für Deine Erklärung.

TausB

Hi!

Versuch mal, im Skript den -density 300x300-Wert auf 600x600 zu setzen, sollte zumindest die Größe wieder auf das Ausgangsmaß setzen, zumindest wenn du 600 dpi verwenden möchtest.

Ja das kann ich bestätigen, funktioniert.

Schön

Also wenn der -density DPI-Eintrag geringer als die eingestelle Scan-DPI ist, wird eine PDF mit höhere Auflösung erstellt? Kannst Du mir zum Verständnis die Logik dahinter kurz erläutern? 😎

Ein 300-dpi-Scan wird mit einer density-Einstellung in der Größe 300 nicht verändert, ein 600-dpi-Scan der gleichen Vorlage ist aber viermal so groß wie ein entsprechender 300 dpi-Scan; insofern erscheint eine Vervierfachung bei density 300 dpi nicht ganz unlogisch.

Daher ich muss das Skript je nach Bedarf vorab manuell anpassen: Der -density Eintrag muss immer dem eingestellten Wert beim Scannen übereinstimmen?!

Scheint so, muss ich mir aber noch mal genauer anschauen.

Habe noch einmal alles mit 300dpi (-density und xsane) getestet. Ein Phänomen bleibt: Die mit dem Skript erstellte PDF ist signifikant größer (DPI ist aber 300 geblieben) als wenn ich mit den gleichen Einstellungen das PDF manuell mit OCRmyPDF erstelle. Wie kann das sein? Das Skript zum Aufrufen von OCRmyPDF sollte doch eigentlich darauf keinen Einfluss haben?!

Danke im voraus für Deine Erklärung.

Kann ich momentan noch nichts genaueres zu sagen; ist mir bisher noch nicht aufgefallen, sollte natürlich so auch nicht sein. Möglich ist, da die PDF-Erstellung im Skript anders abläuft als die interne in Xsane, dass unterschiedliche Voraussetzungen/Größen des "Eingabe"-PDFs für OCRmyPDF bestehen. Bin aber noch nicht dazu gekommen, das genauer aufzubröseln.

so long
habk