Gscan2pdf Version 2.3.0 lahmt / weniger zuverlässig als Version 1.2.6

Du hast Probleme mit Deinem eMail-Programm, Webbrowser oder Textprogramm? Dein Lieblingsprogramm streikt?
Antworten
Benutzeravatar
marind
Beiträge: 78
Registriert: 07.08.2016 01:47:53

Gscan2pdf Version 2.3.0 lahmt / weniger zuverlässig als Version 1.2.6

Beitrag von marind » 09.06.2019 14:18:34

Liebe Scannergemeinde,

ich möchte gern ältere Dokumente in durchsuchbare pdfs umwandeln.
Dazu scanne ich mit einem Avision AB8350 und XSANE zwecks Abspeichern in tiff-Format. Anschließend überarbeite ich mit Gimp und speichere dort die tiff-Dateien mit Kompression (meistens CCITT-Gruppe-4-Fax).
(vgl. den interessanten Beitrag: https://www.dietmarjanowski.de/wordpress/?p=16627 )

Nun lasse ich in GScan2pdf die Texterkennung über tiff-Dateien laufen, um dort anschließend die Textlage zu überprüfen und ggf. zu korrigieren.

Unter Jessie mit Gscan2pdf, Version 1.2.6, lief alles wunderbar. Ich konnte alle "TIFFs" problemlos öffnen und bearbeiten.

Unter Stretch und jetzt auch Buster mit Gscan2pdf, Version 2.3.0, lassen sich voluminöse TIFF-Dateien nicht mehr öffnen oder das Programm friert beim Abspeichern ein.

Die Tests unter Ubuntu oder OpenSuse oder auch auf anderen Rechnern führen zu keinen besseren Ergebnissen.

Selbst bei kleineren (500 - 700 MiB) Dateien arbeitet Gscan2pdf sehr langsam, obwohl ich mittlerweile mit viel leistungsfähigerer Hardware arbeite als noch mit Jessie.

Mit den Meldungen des Programms kann ich nicht so viel anfangen:

Code: Alles auswählen

martin@Z390M:~$ gscan2pdf

(gscan2pdf:26794): Gtk-WARNING **: 13:18:32.490: Theme parsing error: gtk.css:127:35: The style property GtkButton:child-displacement-x is deprecated and shouldn't be used anymore. It will be removed in a future version

(gscan2pdf:26794): Gtk-WARNING **: 13:18:32.490: Theme parsing error: gtk.css:128:35: The style property GtkButton:child-displacement-y is deprecated and shouldn't be used anymore. It will be removed in a future version

(gscan2pdf:26794): Gtk-WARNING **: 13:18:32.490: Theme parsing error: gtk.css:129:34: The style property GtkCheckButton:indicator-size is deprecated and shouldn't be used anymore. It will be removed in a future version

(gscan2pdf:26794): Gtk-WARNING **: 13:18:32.490: Theme parsing error: gtk.css:130:36: The style property GtkCheckMenuItem:indicator-size is deprecated and shouldn't be used anymore. It will be removed in a future version

(gscan2pdf:26794): Gtk-WARNING **: 13:18:32.490: Theme parsing error: gtk.css:132:46: The style property GtkScrolledWindow:scrollbars-within-bevel is deprecated and shouldn't be used anymore. It will be removed in a future version

(gscan2pdf:26794): Gtk-WARNING **: 13:18:32.490: Theme parsing error: gtk.css:135:30: The style property GtkExpander:expander-size is deprecated and shouldn't be used anymore. It will be removed in a future version

(gscan2pdf:26794): Gtk-WARNING **: 13:18:32.490: Theme parsing error: gtk.css:142:29: The style property GtkStatusbar:shadow-type is deprecated and shouldn't be used anymore. It will be removed in a future version

(gscan2pdf:26794): GooCanvas-CRITICAL **: 13:25:07.475: goo_canvas_group_remove_child: assertion 'child_num < group->items->len' failed
martin@Z390M:~$ 

Hat jemand eine Idee dazu?

Marind
Librem 14, Version 4.13,
12x Intel@Core i7-1071OU CPU@1,10GHz
Arbeitsspeicher: 62,7 GiB

Thinkpad X1 Carbon: debian 10 - Buster / Dualboot Windows 10

Desktop: debian 10 - Buster
Motherboard: MSI MPG Z390M Gaming Edge AC
CPU: Intel Core i5 9600K 6x 3.70GHz
Arbeitsspeicher: 64GB

Benutzeravatar
Blackbox
Beiträge: 4289
Registriert: 17.09.2008 17:01:20
Lizenz eigener Beiträge: GNU Free Documentation License

Re: Gscan2pdf Version 2.3.0 lahmt / weniger zuverlässig als Version 1.2.6

Beitrag von Blackbox » 10.06.2019 22:38:58

Das Projekt besitzt eine Mailingliste wo du eventuell Hilfe bekommen kannst, denn das Tool und dein Problem sind schon recht speziell.
So erhöhst du zumindest die Chance auf eine Antwort und mit etwas Glück kannst du damit dein Problem auch lösen.
Eigenbau PC: Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Desktop PC: Dell Inspiron 530 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Notebook: TUXEDO BU1406 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Alles Minimalinstallationen und ohne sudo/PA/PW.
Rootserver: Rocky Linux 9.3 - Kernel: 5.14

Freie Software unterstützen, Grundrechte stärken!

Benutzeravatar
marind
Beiträge: 78
Registriert: 07.08.2016 01:47:53

Re: Gscan2pdf Version 2.3.0 lahmt / weniger zuverlässig als Version 1.2.6

Beitrag von marind » 12.06.2019 22:57:49

Danke, Blackbox,
ich versuch's ! :-)
marind
Librem 14, Version 4.13,
12x Intel@Core i7-1071OU CPU@1,10GHz
Arbeitsspeicher: 62,7 GiB

Thinkpad X1 Carbon: debian 10 - Buster / Dualboot Windows 10

Desktop: debian 10 - Buster
Motherboard: MSI MPG Z390M Gaming Edge AC
CPU: Intel Core i5 9600K 6x 3.70GHz
Arbeitsspeicher: 64GB

debianoli
Beiträge: 4068
Registriert: 07.11.2007 13:58:49
Wohnort: Augschburg

Re: Gscan2pdf Version 2.3.0 lahmt / weniger zuverlässig als Version 1.2.6

Beitrag von debianoli » 13.06.2019 09:22:18

Wieso nimmst du eigentlich tiff als Datei-Format? Das macht mM nur Sinn, wenn du zB im Bereich Print arbeitest. Für dein Vorhaben sehen ich keine Vorteile, da wäre ein Datei-Format wie PNG oder JPG sehr viel besser geeignet. Und vor allem sind die Scans dann nicht so riesig vom Speicher-Bedarf her.

Benutzeravatar
MSfree
Beiträge: 10684
Registriert: 25.09.2007 19:59:30

Re: Gscan2pdf Version 2.3.0 lahmt / weniger zuverlässig als Version 1.2.6

Beitrag von MSfree » 13.06.2019 09:40:59

debianoli hat geschrieben: ↑ zum Beitrag ↑
13.06.2019 09:22:18
...Und vor allem sind die Scans dann nicht so riesig vom Speicher-Bedarf her.
TIFF mit Kompression CCITT-Gruppe-4-Fax hat nur eine Farbtiefe von einem Bit und ist dann auch noch LZW-komprimiert. Der typische Kompressionsfaktor gegenüber einem RGB-Bild beträgt ca. 30-fach. Ein JPG mit noch ansehnlicher Qualität kommt auf Faktor 10-15. :wink:

debianoli
Beiträge: 4068
Registriert: 07.11.2007 13:58:49
Wohnort: Augschburg

Re: Gscan2pdf Version 2.3.0 lahmt / weniger zuverlässig als Version 1.2.6

Beitrag von debianoli » 23.06.2019 12:18:24

MSfree hat geschrieben: ↑ zum Beitrag ↑
13.06.2019 09:40:59
TIFF mit Kompression CCITT-Gruppe-4-Fax hat nur eine Farbtiefe von einem Bit und ist dann auch noch LZW-komprimiert. Der typische Kompressionsfaktor gegenüber einem RGB-Bild beträgt ca. 30-fach.
OK, die TIFF-Variante kannte ich nicht, da ich bisher nur mit TIFF im Druckbereich zu tun hatte. Da sind die Dateien naturgemäß "etwas" größer...

Aber das ist für mich insgesamt ein Problem bei Tiff, dass es bei dem Datei-Format einen dicken Wust an verschiedensten Einstellungen gibt. Und die richtigen zu finden, ist immer ein kleines Glücksspiel. Das macht jedes Programm immer etwas anders.

Benutzeravatar
marind
Beiträge: 78
Registriert: 07.08.2016 01:47:53

Re: Gscan2pdf Version 2.3.0 lahmt / weniger zuverlässig als Version 1.2.6

Beitrag von marind » 23.06.2019 13:35:15

Hallo debianoli, hallo MSfree,

das Arbeiten mit tif hat sich bei mir ergeben, weil Tesseract angeblich nur damit klar kommt:
https://www.linux-magazin.de/ausgaben/2 ... achlese/3/.

Nun habe ich es auf Deinen, debianoli, Tipp hin mal mit png versucht und es hat mit der Texterkennung unter gscan2pdf mit Einstellung Tesseract funktioniert. Meine Informationen waren scheinbar veraltet.

Aufgefallen ist mir dabei jedoch, dass der Rechner trotzdem sehr langsam arbeitet.

Gruß
Marind
Librem 14, Version 4.13,
12x Intel@Core i7-1071OU CPU@1,10GHz
Arbeitsspeicher: 62,7 GiB

Thinkpad X1 Carbon: debian 10 - Buster / Dualboot Windows 10

Desktop: debian 10 - Buster
Motherboard: MSI MPG Z390M Gaming Edge AC
CPU: Intel Core i5 9600K 6x 3.70GHz
Arbeitsspeicher: 64GB

Benutzeravatar
MSfree
Beiträge: 10684
Registriert: 25.09.2007 19:59:30

Re: Gscan2pdf Version 2.3.0 lahmt / weniger zuverlässig als Version 1.2.6

Beitrag von MSfree » 23.06.2019 13:47:46

marind hat geschrieben: ↑ zum Beitrag ↑
23.06.2019 13:35:15
Aufgefallen ist mir dabei jedoch, dass der Rechner trotzdem sehr langsam arbeitet.
Naja, in deinem ersten Post schreibst du was vom 500-700MiB großen TIFFs. Kein Wunder, daß das Ding lahm wird. Deine Bilder sind schlicht viel zu hoch aufgelöst, die Erkennungsrate wird dadurch jedenfalls nicht gesteigert.

Um z.B. OCR über eine DIN-A4 Seite laufen zu lassen, sollte es reichen, die Seite mit 300DPI zu scannen. Das resuliterende Bild hätte dann eine Größe von 2500x3500 Pixel, als Grauwertbild also unkomprimiert 8.8MB, was dann auch extrem viel schneller verarbeitet werden kann als deine 500MiB-Brocken.

Benutzeravatar
marind
Beiträge: 78
Registriert: 07.08.2016 01:47:53

Re: Gscan2pdf Version 2.3.0 lahmt / weniger zuverlässig als Version 1.2.6

Beitrag von marind » 23.06.2019 16:31:45

okay, einige fette Brocken sind dabei ... und in der Tat habe ich oft mit 350 dpi gescannt ...
Die von mir wahrgenommene Differenz zwischen Version 1.2.6 und Version 2.3.0 bleibt mir dennoch unerklärlich.
Librem 14, Version 4.13,
12x Intel@Core i7-1071OU CPU@1,10GHz
Arbeitsspeicher: 62,7 GiB

Thinkpad X1 Carbon: debian 10 - Buster / Dualboot Windows 10

Desktop: debian 10 - Buster
Motherboard: MSI MPG Z390M Gaming Edge AC
CPU: Intel Core i5 9600K 6x 3.70GHz
Arbeitsspeicher: 64GB

debianoli
Beiträge: 4068
Registriert: 07.11.2007 13:58:49
Wohnort: Augschburg

Re: Gscan2pdf Version 2.3.0 lahmt / weniger zuverlässig als Version 1.2.6

Beitrag von debianoli » 23.06.2019 17:40:03

Was sind denn das für Vorlagen, die dann auf 500 MB oder mehr kommen? Eine normale DIN A4 Seite Text kommt doch kaum auf diese Größe, selbst bei 300 dpi .

Hast du die Text-Umwandlung schon mal mit tessarect direkt in der Konsole getestet? Ist es dann auch langsam?

Benutzeravatar
marind
Beiträge: 78
Registriert: 07.08.2016 01:47:53

Re: Gscan2pdf Version 2.3.0 lahmt / weniger zuverlässig als Version 1.2.6

Beitrag von marind » 25.07.2019 20:56:27

Auf Eure Tipps hin, debianoli und MSfree, habe ich nun ein paar Scans mit 300 dpi statt mit 350 vorgenommen und das png- statt des tiff-Formates gewählt.

Manchmal benötige ich Zeitungsartikel mit integrierten Grafiken. Die beanspruchen dann Graustufen-Scan. Bei einem Artikel auf einer halben Zeitungsseite wächst die zu verarbeitende Datei auf knapp 6 MB.
Große Artikel im Strichzeichnungs-Scan geben sich mit knapp 1 MB zufrieden. Bei Strichzeichnung arbeite ich mit GIMP nach. Insgesamt kommt Tesseract dann zu guten bis sehr guten Ergebnissen.

Dennoch: Im Korrekturmodus der Texterkennung, also beim Nacharbeiten der Texterkennungsausgabe reagiert Gscan2pdf sehr lahm, bei den 5-6 MB-Dateien stürzte das Programm mehrfach ab.
Und wie gesagt: Das ist mir bei früheren Programmversionen nicht passiert.

Gruß
Marind


PS:
Leider gibt es nicht so viele Alternativen, wenn man auf Nacharbeiten der Texterkennungsausgabe angewiesen ist und mit dem "Originalbild" der Quelle arbeiten möchte. Die theoretischen Leistungsmerkmale von Gscan2pdf sind schon genial :D
Librem 14, Version 4.13,
12x Intel@Core i7-1071OU CPU@1,10GHz
Arbeitsspeicher: 62,7 GiB

Thinkpad X1 Carbon: debian 10 - Buster / Dualboot Windows 10

Desktop: debian 10 - Buster
Motherboard: MSI MPG Z390M Gaming Edge AC
CPU: Intel Core i5 9600K 6x 3.70GHz
Arbeitsspeicher: 64GB

Benutzeravatar
Revod
Beiträge: 3788
Registriert: 20.06.2011 15:04:29
Lizenz eigener Beiträge: MIT Lizenz

Re: Gscan2pdf Version 2.3.0 lahmt / weniger zuverlässig als Version 1.2.6

Beitrag von Revod » 25.07.2019 21:46:11

marind hat geschrieben: ↑ zum Beitrag ↑
25.07.2019 20:56:27
...
PS:
Leider gibt es nicht so viele Alternativen, wenn man auf Nacharbeiten der Texterkennungsausgabe angewiesen ist und mit dem "Originalbild" der Quelle arbeiten möchte. Die theoretischen Leistungsmerkmale von Gscan2pdf sind schon genial :D
Eventuell Debianocrfeeder
Systemd und PulseAudio, hmmm, nein danke.

Benutzeravatar
marind
Beiträge: 78
Registriert: 07.08.2016 01:47:53

Re: Gscan2pdf Version 2.3.0 lahmt / weniger zuverlässig als Version 1.2.6

Beitrag von marind » 25.07.2019 23:32:38

danke Revod,
ziemlich frisch, das Ding. Läuft bei mir noch nicht so richtig ...
viewtopic.php?f=29&t=174158
Gruß
Marind
Librem 14, Version 4.13,
12x Intel@Core i7-1071OU CPU@1,10GHz
Arbeitsspeicher: 62,7 GiB

Thinkpad X1 Carbon: debian 10 - Buster / Dualboot Windows 10

Desktop: debian 10 - Buster
Motherboard: MSI MPG Z390M Gaming Edge AC
CPU: Intel Core i5 9600K 6x 3.70GHz
Arbeitsspeicher: 64GB

debianoli
Beiträge: 4068
Registriert: 07.11.2007 13:58:49
Wohnort: Augschburg

Re: Gscan2pdf Version 2.3.0 lahmt / weniger zuverlässig als Version 1.2.6

Beitrag von debianoli » 26.07.2019 08:35:52

marind hat geschrieben: ↑ zum Beitrag ↑
25.07.2019 20:56:27
PS:
Leider gibt es nicht so viele Alternativen, wenn man auf Nacharbeiten der Texterkennungsausgabe angewiesen ist und mit dem "Originalbild" der Quelle arbeiten möchte. Die theoretischen Leistungsmerkmale von Gscan2pdf sind schon genial :D
Du kannst PDF sehr gut mit Debianpdfsandwich in PDF umwandeln, bei denen der Text hinter dem Originalbild steckt. Ein einfaches

Code: Alles auswählen

pdfsandwich -lang deu scan.pdf
erledigt den Job.

Benutzeravatar
marind
Beiträge: 78
Registriert: 07.08.2016 01:47:53

Re: Gscan2pdf Version 2.3.0 lahmt / weniger zuverlässig als Version 1.2.6

Beitrag von marind » 26.07.2019 11:03:55

Hallo debianoli,
vielen Dank für Deinen Hinweis!
Die Beispiele auf der Projektseite
http://www.tobias-elze.de/pdfsandwich/index.html
sind interessant. Und in den Paketquellen befindet sich bereits die letzte Version (0.1.7).
Leider kann die Texterkennungsausgabe nicht nachgearbeitet werden, was mir wichtig wäre.
Ich habe testweise Zeitungsartikel über pdfsandwich bearbeitet und XSane Vorlagen in Farbe, in Graustufen und in Strichzeichnung anfertigen lassen.
Teilweise verschwinden Grafiken und Bilder, teilweise wird um Grafiken herum kein Text erkannt. Kann hier leider keine Beispiele hochladen, aber die Ergebnisse eignen sich meines Erachtens nicht für einen professionellen Einsatz. pdfsandwich scheint auf Strichzeichnungsvorlagen beschränkt zu sein, was sich mit den Empfehlungen auf
https://wiki.ubuntuusers.de/pdfsandwich/
deckt:
Empfohlen werden Schwarz-weiße Vorlagen ohne Bilder, die Passung wird mit verschachtelten Vorlagen schwieriger. Eine Korrekturfunktion ist bisher leider nicht implementiert.
Farbige PDFs werden vom Programm stillschweigend in PDFs in Schwarz-Weiß umgewandelt!
Für einfache DIN-A-4-Schriftsätze und guten Vorlagen dürfte pdfsandwich brauchbare Ergebnisse liefern. Für Vorlagen mit modernen Layouts in Zeitschriften oder Zeitungen, in denen farbig und spielerisch die Wahrnehmung "aufgepeppt" wird, scheint mir pdfsandwich weniger geeignet.
Gruß
Marind
Librem 14, Version 4.13,
12x Intel@Core i7-1071OU CPU@1,10GHz
Arbeitsspeicher: 62,7 GiB

Thinkpad X1 Carbon: debian 10 - Buster / Dualboot Windows 10

Desktop: debian 10 - Buster
Motherboard: MSI MPG Z390M Gaming Edge AC
CPU: Intel Core i5 9600K 6x 3.70GHz
Arbeitsspeicher: 64GB

debianoli
Beiträge: 4068
Registriert: 07.11.2007 13:58:49
Wohnort: Augschburg

Re: Gscan2pdf Version 2.3.0 lahmt / weniger zuverlässig als Version 1.2.6

Beitrag von debianoli » 26.07.2019 11:34:46

Du kannst es noch mit dem Kauf-Programm VueScan von hamrick.com probieren. Damit kann man auch PDF mit Textinhalt erstellen.

Benutzeravatar
Revod
Beiträge: 3788
Registriert: 20.06.2011 15:04:29
Lizenz eigener Beiträge: MIT Lizenz

Re: Gscan2pdf Version 2.3.0 lahmt / weniger zuverlässig als Version 1.2.6

Beitrag von Revod » 26.07.2019 11:41:48

marind hat geschrieben: ↑ zum Beitrag ↑
25.07.2019 23:32:38
danke Revod,
ziemlich frisch, das Ding. Läuft bei mir noch nicht so richtig ...
viewtopic.php?f=29&t=174158
Gruß
Marind
... wieder das " Problem " mit einer Tiff Lib... Man kann in ocrfeeder auch Tesseract in den Einstellungen wählen, oder vlt. auch Debiangocr installieren und nochmals testen ( Ich nehme an Debianunpaper ist installiert, obwohl nur empfohlen, schadens tut's nicht ).

Und viell. nach tiff pakete suchen, mache ich immer so wenn was nicht richtig will, und vorhandenes erneut installieren, inkl. Abhängigkeiten.

Ocrfeeder auch mit pdf, oder odf Export versuchen, genau wegen der xy.odt Export Möglichkeit habe ich es am liebsten.
Systemd und PulseAudio, hmmm, nein danke.

Antworten