TausB
Anmeldungsdatum: 26. November 2009
Beiträge: 1564
Wohnort: Terra incognita
|
Heinrich Schwietering schrieb: 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?!
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.
Hier noch ein direkter Größen-Vergleich (bei einer Rechnung mit einer kurzen Handnotiz - 300dpi): Größe FILE_OUT.1.pdf = 343 KB (mit OCR: 519 KB); Größe xsane natives PDF = 71 KB (mit OCR manuell: 74 KB). Beide OCR-Versionen sind in der Qualität identisch. Daher denke ich, dass Deine Vermutung "dass die PDF-Erstellung im Skript anders abläuft als die interne in Xsane" korrekt ist. Dieser Artikel gibt einen Hinweis, die angegebene Lösung via JPEG war bei mir allerdings nicht so erfolgreich ... PS: ... Bin aber noch nicht dazu gekommen, das genauer aufzubröseln.
Fühle Dich bitte nicht gehetzt. Ich stelle mich auch gern für Test etc. zur Verfügung, um eine Lösung zu finden. EDIT: Habe selber versucht eine Lösung zu finden. Inspiriert wurde ich von hier. Mein Vorschlag für eine Änderung des xsane2OCRmyPDF - Version 0.2 Skriptes: Erstelle erst eine TIFF-Datei und dann daraus mit tiff2pdf ein PDF, das ist dann noch kleiner als das native xsane PDF. 😉 (Am obigen Beispiel getestet: FILE_OUT.1.pdf(aus tif) = 39 KB [mit OCR: 55 KB]). Weil ich überwiegend in einem festen Format, z.B. A4, scanne, gebe ich dieses direkt an - so werden die in in xsane eingestellten DPI auch für das PDF verwendet. Zum Schluss nur noch das FILE_OUT.1.tif löschen. Konkret: Original: convert "$FILE_PATH" -resize $SIZE -units PixelsPerInch -density 300x300 "$FILE_OUT.1.pdf" 1>&2
ersetzen durch:
convert "$FILE_PATH" "$FILE_OUT.1.tif" 1>&2
tiff2pdf -o "$FILE_OUT.1.pdf" -z -u m -p "A4" -F "$FILE_OUT.1.tif" 1>&2 Original: # Remove temporary files
ergänzen um:
rm "$FILE_OUT.1.tif" EDIT2 Um die Idee von matzeSG (post) mit aufzunehmen, könnte man noch z.B. ergänzen (libimage-exiftool-perl muss installiert sein):
# Metadaten setzen
exiftool -Title="${FILE_OUT##*/}" -Creator="$USER" -Description="${FILE_OUT##*/}" -Author="$USER" -Subject="${FILE_OUT##*/}" -Producer="xsane2OCRmyPDF" -m -overwrite_original "$FILE_OUT.pdf"
/EDIT2 Bei dem Beipiel hat die OCR-Qualität darunter nicht gelitten. Ob das generell gilt, kann ich allerdings nicht sagen. Evtl. hast Du eine spezielle Testdatei als Referenz, mit der Du das nachvollziehen kannst. Noch etwas: Beim Testen von multipage-PDF fiel mir auf, dass Dein Original-Skript (nur bei mir?) nicht wie gedacht funktioniert. Die Seiten werden als einzelne PDF abgelegt. Oder wähle ich die falsche Einstellung (siehe Bild)? TausB
- Bilder
|
Heinrich_Schwietering
Wikiteam
(Themenstarter)
Anmeldungsdatum: 12. November 2005
Beiträge: 11314
Wohnort: Bremen
|
Hi! Nur ganz kurz zum angehängten Screenshot: Die Dateien werden bei dir einzeln abgelegt, weil du die Seitennummerierung aktiviert hast, jeder neue Scan bekommt also eine neue Nummer am Namensende, und damit werden sie nicht mehr in ein PDF zusammengefasst. Beim "Stiefelsymbol" die Null wählen, damit sollte es dann gehen. Die anderen Vorschläge sehen erst mal ganz plausibel aus, teste ich die Tage mal. Schon mal Danke für die Hinweise! so long hank
|
TausB
Anmeldungsdatum: 26. November 2009
Beiträge: 1564
Wohnort: Terra incognita
|
Heinrich Schwietering schrieb: Nur ganz kurz zum angehängten Screenshot: Die Dateien werden bei dir einzeln abgelegt, weil du die Seitennummerierung aktiviert hast, jeder neue Scan bekommt also eine neue Nummer am Namensende, und damit werden sie nicht mehr in ein PDF zusammengefasst. Beim "Stiefelsymbol" die Null wählen, damit sollte es dann gehen.
Das hat Sinn - alles klar (da ändere ich sonst nichts, daher bin ich gar nicht auf die Idee gekommen ...) EDIT Ja hat funktioniert. Noch eine Frage: Wieso verwendest Du yad aus der Drittquelle und nicht zenity aus den Quellen? Zu ersetzen wäre nur: Original:
$(yad --geometry -0-0 --title="xsane2OCRmyPDF" --button=Ja:2 --button=Nein:4 --text="Sollen weitere Seiten gescannt werden?")
durch:
$(zenity --question --title="xsane2OCRmyPDF" --height=100 --width=250 --text="Sollen weitere Seiten gescannt werden?") und Original:
{ if [[ $ret -eq 4 ]] ; then
durch:
{ if [[ $ret -ne 0 ]] ; then Der Vollständigkeit halber: Falls Du es übernimmst auf "A4" zu scannen und die DPI bzw. die "size" keine Rolle mehr spielen, können noch gelöscht werden:
SIZE=`identify "$FILE_PATH" | cut -d " " -f 3 `
echo $SIZE 1>&2 Läuft bei mir so problemlos. TausB
|
Heinrich_Schwietering
Wikiteam
(Themenstarter)
Anmeldungsdatum: 12. November 2005
Beiträge: 11314
Wohnort: Bremen
|
Hi! Yad hat mehr Möglichkeiten; ich hatte in frühen xsane2XXX-Versionen Zenity verwendet, aber z.B. die Platzierung der Fenster klappte damit, wenn ich es recht in Erinnerung nicht habe, nicht so wie ich es wollte. Kann auch sein, dass ich es hier aus einem anderen Skript übernommen habe, in dem ich andere Möglichkeiten brauchte. Zenity wird soweit ich weiß auch nicht mehr gepflegt. Aber es funktioniert natürlich auch 😉 so long hank
|
Heinrich_Schwietering
Wikiteam
(Themenstarter)
Anmeldungsdatum: 12. November 2005
Beiträge: 11314
Wohnort: Bremen
|
Hi! Hab' das mit tiff2pdf mal durchgespielt; klappt ganz gut (wobei ich kaum irgendwelche Größenunterschiede mit den diversen Optionen feststellen kann, im Zweifelsfall scheint es - zumindest bei einer schlichten Lineart-Vorlage - ein einfaches tiff2pdf -o Ausgabe.pdf Eingabe.tiff auch zu tun. Bei meinen Versuchen waren die Ausgaben ohne OCR ("$FILE_OUT.1.pdf", DIN-A4 Behördenbrief) knapp 50 kb groß, mit OCR als Xsane2OCRmyPDF-Ausgabe um die 88 kb. Ein von XSane "intern" hergestelltes PDF der selben Vorlage war ca. 80 kb groß, mit externer OCRmyPDF dann etwa 83 kb, also doch wieder etwas kleiner. Die Angabe einer Größe scheint auch komplett überflüssig zu sein; ich bekomme als Ergebnis PDFs in Größe der Vorlage. Ich würde Din-A4 nicht allgemein als Größe festlegen wollen; man könnte im Artikel aber darauf hinweisen, wie man das bewerkstelligen kann. so long hank
|
TausB
Anmeldungsdatum: 26. November 2009
Beiträge: 1564
Wohnort: Terra incognita
|
O.k. - das hört sich gut an. Wie groß ist denn bei Dir der gleiche Brief ohne tiff2pdf - also die bisherige convert-Version? Mit den Parametern hatte ich nicht viel gespielt - sie schienen mir aber unschädlich zu sein. Wenn's auch ohne geht - um so besser. 😉 Was hältst Du von der Integration der Metadaten (ggf. könnte man mit yad auch noch gezielt danach fragen)? TausB
|
Heinrich_Schwietering
Wikiteam
(Themenstarter)
Anmeldungsdatum: 12. November 2005
Beiträge: 11314
Wohnort: Bremen
|
Hi! Die Größendimensionen bei dem "ursprünglichen" xsane2OCRmyPDF-Skript decken sich mit deinen Werten - ca 400 kb für eine S/W-Seite als PDF, knapp 700 für die OCR-Version. Liegt also wirklich an der PDF-Erstellung mit convert. Wg. der Metadaten: deine Lösung mit exiftool funktioniert sehr gut. Natürlich wäre eine Abfrage für die Werte mit yad/zenity möglich; ich bräuchte sie allerdings nicht, es würde mich persönlich daher eher stören 😉. so long hank
|
TausB
Anmeldungsdatum: 26. November 2009
Beiträge: 1564
Wohnort: Terra incognita
|
Heinrich Schwietering schrieb: Die Größendimensionen bei dem "ursprünglichen" xsane2OCRmyPDF-Skript decken sich mit deinen Werten - ca 400 kb für eine S/W-Seite als PDF, knapp 700 für die OCR-Version. Liegt also wirklich an der PDF-Erstellung mit convert.
Prima, dass Du das verifizieren konntest. Der Unterschied ist schon beträchtlich ... - und der OCR-Text ist im PDF markierbar, so dass man schnell die Qualität der Texterkennung überprüfen kann. Die Texterkennung ist so gut, das ich die fehlende Rechtschreibprüfung verschmerze. Interessanter Weise scheint mir die Anzahl unsinnige Leerzeichen zwischen den Buchstaben auch deutlich geringer zu sein. Kurz: So bin ich sehr zufrieden! 👍
Wg. der Metadaten: deine Lösung mit exiftool funktioniert sehr gut. Natürlich wäre eine Abfrage für die Werte mit yad/zenity möglich; ich bräuchte sie allerdings nicht, es würde mich persönlich daher eher stören 😉.
Sehe ich eigentlich auch so - am schwanken bin ich nur bei der Eingabe von Schlüsselwörtern. Allerdings: Wenn der OCR-Text sowieso indexiert wird, dürfte das eigentlich egal sein. Na, dann gibt es vor Weihnachten ja noch ein aktualisierte Version von Dir ... 😛 TausB
|
Heinrich_Schwietering
Wikiteam
(Themenstarter)
Anmeldungsdatum: 12. November 2005
Beiträge: 11314
Wohnort: Bremen
|
Hi! Kann ich die Tage ins Wiki bringen, könntest du aber auch machen 🤓 Wenn Indizierung Thema ist wäre paperwork vielleicht auch ganz interessant. Noch ist allerdings da der Export der Dateien nicht vernünftig machbar, das ist jedenfalls mein Kenntnisstand. Angedacht war es, vielleicht ist es schon in einer Entwicklerversion umgesetzt. so long hank
|
TausB
Anmeldungsdatum: 26. November 2009
Beiträge: 1564
Wohnort: Terra incognita
|
Heinrich Schwietering schrieb: Kann ich die Tage ins Wiki bringen, könntest du aber auch machen 🤓
Durchaus denkbar - keine Frage, aber was ändert sich im Absatz xsane2OCRmyPDF? Eigentlich nichts, bis auf den Inhalt des Skriptes - und da kann es nur einen Herren geben: Den Autor; die Version "0.3"?! Evtl. könnte man erwähnen, das sich der OCR-Text durch Markierung zur Kontrolle in einem Viewer anzeigen lässt (falls Du das gemeint hast). Wenn Indizierung Thema ist wäre paperwork vielleicht auch ganz interessant. Noch ist allerdings da der Export der Dateien nicht vernünftig machbar, das ist jedenfalls mein Kenntnisstand. Angedacht war es, vielleicht ist es schon in einer Entwicklerversion umgesetzt.
Indizieren Standardsuchmaschinen, z.B. tracker, solche Dokumente nicht auch? Da ich z.Z. noch keine im Einsatz habe, hat mich Deine Aussage verunsichert ... Oder werden dort nur Tags und nicht die Inhalte ausgewertet? TausB
|
Heinrich_Schwietering
Wikiteam
(Themenstarter)
Anmeldungsdatum: 12. November 2005
Beiträge: 11314
Wohnort: Bremen
|
Hi! Tracker verwendet meines Wissens nach Angaben aus den Metadaten, aber nicht den kompletten Inhalt von Textdateien. Ist aber auch nur theoretisches, hab' sowas nie verwendet. Paperwork hingegen indiziert jedes Wort der Vorlage, zusätzlich können noch Labels/Schlagwörter vergeben werden; sinnvoll, wenn man einen Text/Brief sucht, in dem ein bestimmtes Wort vorkommt, man aber sonst nicht mehr viel dazu weiß - wenn man ihn denn mit Paperwork eingescannt hat ... so long hank EDIT Falsch, Tracker sucht doch in den Dateien selbst, sowohl in den Metadaten (z.B mp3-tags) als auch in Texten, siehe https://wiki.gnome.org/Projects/Tracker/WhatIsTracker
...hab-' ich wieder was dazu gelernt
|
TausB
Anmeldungsdatum: 26. November 2009
Beiträge: 1564
Wohnort: Terra incognita
|
Heinrich Schwietering schrieb: EDIT Falsch, Tracker sucht doch in den Dateien selbst, sowohl in den Metadaten (z.B mp3-tags) als auch in Texten, siehe https://wiki.gnome.org/Projects/Tracker/WhatIsTracker
Da war ich auch gerade ... 😉 EDIT: Habe gerade einen Schnelltest mit Tracker gemacht. Inhalte werden grundsätzlich gefunden. Allerdings werden Teilstrings nur gefunden, wenn der Anfang passt. Also beim Wort Wärmepumpen z.B.:
suche pumpe ▶ kein Treffer suche wärmepumpe ▶ kein Treffer suche wärmepumpe* ▶ Treffer suche *pumpe* ▶ kein Treffer
Aber das ist ein anderes Thema, hat mit OCR nicht viel zu tun. - Aber gut zu wissen, dass es geht. 😉 TausB
|
Heinrich_Schwietering
Wikiteam
(Themenstarter)
Anmeldungsdatum: 12. November 2005
Beiträge: 11314
Wohnort: Bremen
|
Hi! Hab das xsane2OCRmyPDF-Skript im Artikel auf den neusten Stand gebracht - Vielen Dank an dich, TausB ! so long hank
|
Heinrich_Schwietering
Wikiteam
(Themenstarter)
Anmeldungsdatum: 12. November 2005
Beiträge: 11314
Wohnort: Bremen
|
Hi! Nachtrag Habe noch etwas rumprobiert: mit econvert aus ExactImage erstellte PDFs, (dazu muss die interne XSane-ppm-Datei allerdings umbenannt werden, da sie eine etwas eigenwillige Dateiendung hat) werden etwas gleichgroße Dateien erstellt. Mit bmpp aus dktools (http://dktools.sourceforge.net/) sogar noch minimal kleinere. Dazu muss aber zunächst eine png-Datei aus der internen XSane-Datei erstellt werden, die dann mit bmpp in ein PDF umgewandelt wird. Allerdings sind die dktools nicht in den Quellen, muss man sich also selberbauen. so long hank PS: xsane2djvu macht aus der selben Vorlage allerdings noch mal eine nur knapp ein Drittel große Datei daraus, Texterkennungsqualität ist identisch 🤓
|
passer-domesticus
Anmeldungsdatum: 25. August 2008
Beiträge: 127
|
Leider habe ich es nicht hinbekommen, mit den Beschreibungen dieses Artikels und des anderen von https://wiki.ubuntuusers.de/OCRmyPDF/ die OCR in xsane zu integrieren. Insbesondere bleibt mir scheleierhaft, wie man die Skripte xsane2sandwich.sh und xsane2OCRmyPDF.sh von xsane aus zugänglich macht. Ich sehe zwar ein grünes Symbol in der Taskleiste, zwischendurch entsteht auch eine *.tiff-Datei meiner Scans. Die pdf-Datei am Schluß ist aber nicht durchsuchbar. Es wäre an der Zeit, aus beiden Artikeln einen zu machen und einen dritten zu dem hier in der Diskussion angesprochenen Thema "Volltextsuche". Was ich gerne hätte:
Aus xsane beliebig viele Seiten nacheinander einscannen, ohne zuvor gezählt zu haben, wieviele Blätter es sind, dabei einmal für alle folgenden Blätter einstellen, welche Bereiche der Vorlage in den Scan gehen sollen (notfalls zwischendurch noch mal durch den Vorschauscan gehen, so daß die geänderten Einstellungen dann für alle dann folgenden Seiten gelten), das Ergebnis in eine durchsuchbare PDF-Datei speichern und am liebsten nachher noch einen Durchlauf, in dem mir die Stellen in den Bilddateien gezeigt werden, an denen die OCR-Erkennung schlecht ging, um das Erkennungesergebnis manuell korrigieren zu können.
In der Windows-Welt können das verschiedene Programme, nach meiner Erfahrung recht gut Abbyy Fine Reader. Dummerweise habe ich es nicht hinbekommen, die Version 9.0 davon, die ich habe, mit Wine unter Linux ans Laufen zu bekommen. Es wäre natürlich schöner, mit freier Software eine anständige OCR-Erkennung von PDF-Dateien hinzubekommen, damit man deren Inhalte mit Volltextsuche findet.
|