Dieser Scanner benötigt vor jeder Benutzung einen Firmware-Upload. Die entsprechende Firmware ist im Windows-Treiber enthalten und kann daraus extrahiert werden (Datei kopieren nach Installation unter Windows oder das CAPI-Archiv entpacken). Orte wo man solche Firmware herunterladen kann sind in ubuntuforums.org/archive/index.php/t-26911.html aufgelistet. Zur Konfiguration muss man dann noch in
/etc/sane.d/snapscan.conf eintragen wo die Firmware zu finden ist, z.B. »firmware /usr/local/lib/sane/Snape20.bin«.

Dann verwende man »sane-find-scanner« um den Scanner erkennen zu lassen, die Meldung sollte etwas sein wie: »found USB scanner (vendor=0×06bd [AGFA], product=0×2091 [ SNAPSCAN e20 ]) at libusb:001:006«. In manchen Fällen mit ein und demselben Scanner kam:
»found USB scanner (vendor=0×06bd [AGFA ], product=0×2091 [SNAPSCAN]) at libusb:001:008«

Dass SANE diesen Scanner unterstützt zeigt sich daran dass er in der Liste der für scanimage verfügbaren Geräte auftaucht: »scanimage -L« liefert »device `snapscan:libusb:001:006′ is a AGFA SNAPSCAN e20 flatbed scanner«.

SANEs gerätespezifische Optionen findet man dann mit: »scanimage –help -d snapscan:libusb:001:006«.

Nun besteht jedoch noch ein Problem beim Selbsttest von SANE: »scanimage -T« liefert:
»scanimage: open of device snapscan:libusb:001:006 failed: Error during device I/O«.

Fehlersuche:

• Das Problem liegt nicht an der falschen Firmware.
• Das Problem liegt nicht daran dass die Firmware oder /etc/sane/snapscan.conf aufgrund ungenügender Zugriffsrechte nicht erreichbare wäre. Denn es tritt auch unter dem Benutzer root auf.
• Jedoch tritt das Problem nicht immer auf: üblicherweise funktioniert es wenn man den Scanner aus- und wieder einschaltete und direkt als ersten Befehl »scanimage -T« (oder einen Befehl zum Scannen) ausführte.
• Das Auftreten des Problems hing nicht von der zum Scannen gewählten Auflösung ab.
• Folgendes Verhalten war reproduzierbar: Scanner aus- und sofort wieder einschalten, die Scanner-Deviceadresse ermitteln mit »sane-find-scanner« (ohne Wartezeit möglich) und damit einen Befehl zum Scannen starten (hier: getestet mit scanimage). Nach der Aufwärmphase wird dann ein erfolgreicher Scan durchgeführt, jedoch bleibt der Schlitten nach dem Scan auf halbem Rückweg stehen. Weitere Befehle funktionieren bis zum nächsten Neustart des Scanners nicht mehr oder nicht mehr zuverlässig, tw. wird nicht einmal mehr das Device erkannt.

Damit ist das Problem dasselbe wie in bugs.launchpad.net/ubuntu/+source/sane-backends/+bug/94226 beschrieben … es liegt, wie dort argumentiert, wahrscheinlich am Kernel bug 8231 ( bugzilla.kernel.org/show_bug.cgi?id=8231 ). Weitere Diskussion gibt es auf ubuntuforums.org/archive/index.php/t-26911.html bzw. ubuntuforums.org/showthread.php?t=26911 (derselbe thread). Dort wird berichtet dass ein möglicher Workaround manchmal sei, das Modul ppdev oder ehci-hcd zu entladen. Ersteres half nicht, letzteres Modul gab es nicht; und wenn man uhci-hcd entlädt so geht kein Scanner mehr; und nach erneutem Einfügen des Moduls besteht der Fehler weiterhin.

Mögliche Lösung: Kernel 2.6.20 rekompilieren ohne die Option USB_SUSPEND. Details: »This bug has been around since Feisty was released. It has to do with the experimental feature “USB selective suspend/resume and wakeup (EXPERIMENTAL) (USB_SUSPEND)” that is enabled in the Feisty kernel. If you recompile the kernel with this option disabled then you will be able to scan normally again. Even better, if you compile the 2.6.21 vanilla kernel with this enabled things will work as they should. There was a bug in the 2.6.20 kernel that has been fixed.« (nach ubuntuforums.org/archive/index.php/t-26911.html ).

Weitere mögliche Lösung: Kernel von Gutsy unter Feisty installieren. Oder alternativ: Gutsy Beta installieren. Beides siehe ubuntuforums.org/showthread.php?t=424397&page=4 .

Die einfachste Lösung ist aber folgendes Workaround: der USB-Port wird nicht sofort nach dem Ende des Scanvorgangs auf »SUSPEND« gesetzt denn der Scanner-Schlitten hat ja noch Zeit einen Teil des Rückwegs zurückzulegen. In dieser Zeit ist der scanimage-Befehl beendet, d.h. die Hardware steht wieder für weitere Befehle zur Verfügung. Wenn diese neuen Befehle den USB-Port so lange »wach halten« bis der Scanner-Schlitten in seine Ausgangsposition zurückgekehrt ist dann kann nach einer beliebig langen Zwischenzeit erfolgreich ein weiterer Scan durchgeführt werden. Das könnte z.B. ein weiterer scanimage-Befehl sein der den Scan-Schlitten bewegen muss (z.B. ein Vorschauscan) – dieser hält den USB-Port also bis zur Rückkehr des Schlittens wach und darüber hinaus, allerdings wird das Problem noch nicht gelöst: wie kehrt der Schlitten _danach_ zurück? Eine mögliche Lösung ist aber tatsächlich, alle benötigten Scans direkt als Befehle hintereinander zu schreiben und die Vorlage zu wechseln während der Schlitten zurückfährt. Leider ist die Option »–batch-prompt« von scanimage hier keine Lösung: vor dem ersten Scan und zwischen den Scans wird der Scanner hier auf SUSPEND gesetzt. Auch mit lsusb und sane-find-scanner kann man einen USB-Port »wach halten«: man wiederholt diese Aufrufe bis der Schlitten zurückgekehrt ist, mit »sleep 0.3« zwischen den Aufrufen. Allerdings tritt dann (zumindest im Fall von lsusb) dasselbe Problem auf – vielleicht tritt es also auf wenn der USB-Port des Scanners überhaupt in SUSPEND gesetzt wird, egal ob der Scanner dabei noch arbeitet oder nicht mehr? Dann wäre ein kleines Script eine Lösung das so lange »lsusb; sleep 0.3« ausführt bis der Benutzer Return drückt um den nächsten Scan zu machen. Dieser Gedankengang stimmt tatsächlich: nach einem Neustart des Scanners führe man eine Endlosschleife von »sleep 0.3; lsusb;« aus und kann dann mit dem Scanner ganz normal arbeiten, inkl. Vorschauscans und Scans mit xsane usw.. Der Befehl für die Endlosschleife: »while [ true ]; do sleep 0.3; lsusb; done«. Oder auch, um zu sehen dass / wann dieser Befehl arbeitet: »a=0; while [ true ]; do sleep 0.3; lsusb; ((a++)); echo iteration $a; done«. Oder auch, noch besser: »watch –interval=0,3 lsusb«.

Die restlichen Pixel (ab einer bestimmten horizontalen Linie) erscheinen entweder weiß (bei Scannen mit GIMP) oder als Wiederholung der letzte korrekt gescannten Zeile (bei Scannen direkt in xsane). Das Problem verschwindet mehr und mehr und schließlich ganz, wenn man denselben Ausschnitt in immer geringeren Auflösungen scannt oder wenn man den Ausschnitt verkleinert. So z.B. lässst sich z.B. eine vollständige Seite A4 problemlos in 150dpi scannen. Scans werden deutlich beschleunigt, wenn man die Option »Hohe Qualität« in den Standard-Optionen ausschaltet, das Problem verschwindet dadurch jedoch nicht. Das Problem hat auch nichts mit den Optionen »Qualitäts-Weißabgleich« oder »Verwende benutzerdefinierte Gammatabelle« zu tun. An der kritischen Stelle ist während des Scanvorgangs selbst kein geändertes Verhalten des Scannerschlittens zu beobachten, es scheint also ein Softwareproblem zu sein. Die kritische Stelle ist reproduzierbar, wenn Auflösung und Ausschnitt unverändert bleiben. Das Problem tritt nur beim Scannen in Farbe auf, nicht beim Scannen in Graustufen. Das Problem wird nicht behoben, wenn man de Option »Farbzeilen pro Lesevorgang« auf »Auto« oder »1« oder »16« stellt (Standardwert war 4). Das Problem trat auf mit xsane 0.97-4 und wird durch ein Update auf xsane 0.98b-1 nicht behoben (stattdessen werden dabei Fehler engeführt, die xsane erst einmal unbenutzbar machen).

Lösung: Das Problem liegt an xsane (nicht an SANE oder der Scanner-Hardware), denn es tritt bei Verwendung von QuiteInsane nicht auf. Also verwende man QuiteInsane, bis dieser xsane-Bug behoben ist.

Man lege die Schablone zum Scannen von Dias ein. Darauf lege man drei Dias so, dass sie im Scan von unten oder rechts richtig abgelesen werden können. Die auf der Schablone liegende Seite muss dabei natürlich die seitenrichtige Seite des Dias sein (meist die graue Seite des Diarahmens).

Man lege die Dias im Hochformat auf die Schablone. Man kann sie auch im Querformat auflegen, muss dann nur den unten gezeigten Scanbefehl anpassen. Hochformat macht jedoch die Wahrscheinlichkeit geringer, farbige Streifen durch defekte Elemente der CCD-Einheit im Bild zu haben (diese sieht man sonst deutlich, weil mit maximaler Auflösung gescannt wird). Wenn die CCD-Einheit dekete Elemente hat, kann man die Streifen evtl. durch Verwendung von Hochformat umgehen, ansonsten indem man die Schablone zum Scannen der Dias so anpasst, dass die Dias in einem Bereich gescannt werden, in dem die CCD-Einheit keine defekten Elemente hat.

Man schiebe die Schablone zum Scannen von Dias in die Ecke des Scannerglases, die der linken oberen Ecke beim Einscannen einer ganzen Seite entspricht. Auch schiebe man die Dias innerhalb der Schablone in die dorthin orientierte Ecke. So sind die Dias stets genau gleich positioniert, d.h. die im unten gezeigten Befehl zum Scannen von Dias gezeigten Maßangaben stimmen dann.

Man achte darauf, dass sich auf den Dias und dem Scannerglas kein Staub oder Dreck befindet. Bei einer Auflösung von 1200dpi sieht man das sonst deutlich.

Man lege ein neues Verzeichnis an, das die gescannten Bilder (eines Diamagazins) aufnehmen soll.

Befehl zum Scannen von drei aufgelegten Dias in Dateien, so dass der Dateiname eine sequentielle Nummer im Namen enthält, die so beginnt dass sie sich an die letzte Datei mit so aufgebautem Dateinamen im aktuellen Verzeichnis anschließt. Dieser Befehl scannt die drei Dias unter dem Scannerglas mit 1200 dpi in etwa 2min 45s ein.