Zeer regelmatig, te regelmatig, zie ik scanners onderpresteren in het dagelijks gebruik. Gisteren kreeg ik weer zo’n vraag. Een scanner die theoretisch 140 vel papier per minuut moet kunnen scannen, haalt in de praktijk de 20 vel nog niet eens, hoe kan dat?

Scanners worden aangeschaft met de theoretische scansnelheid uit de folder als uitgangspunt voor de uit te voeren prestaties. Het wordt niet altijd gezien en gemeten, maar er zijn tal van voorbeelden te vinden waar scanners die theoretisch 140 vel papier per minuut kunnen scannen in werkelijkheid de 20 vel per minuut niet eens halen. Als dat voldoende is om je dagproductie te halen, wordt er meestal schouderophalend aan voorbijgegaan, maar het blijft verspilling van operatortijd.

Wat zijn nou meestal de oorzaken dat scansnelheden niet gehaald worden. Wel, daar is wel iets over te zeggen.

De volgende factoren hebben een beperkende werking op de reëel te behalen gemiddelde scansnelheid:

• Resolutie
• Bestandsformaat
• Ligging (staand of liggend / portret of landscape)
• Intern geheugen (zowel cliënt als evt server)
• Aantal processoren
• Videokaart
• USB poort
• Netwerk bandbreedte
• Virusscanners

Theoretische snelheid vs realistische snelheid

Meestal wordt de snelheid van een scanner uitgedrukt in pagina’s A4 landscape (dus overdwars) gescand met een resolutie van 200 dpi/ppi. In de praktijk worden die pagina’s meestal portret (dus rechtopstaand) gescand met een resolutie van 300 dpi/ppi. Ook wordt in de theoretische snelheid geen rekening gehouden met verlies aan tijd door schoonmaken en verhelpen van kleine storingen en dergelijke. Daarom is het verstandig om de theoretische snelheid te verminderen met minstens 30% om een reëel te behalen productiesnelheid te kunnen berekenen.

Resolutie, bestandsformaat, RAM, netwerk, poorten.

Met resolutie wordt bedoeld het aantal puntjes per inch dat wordt waargenomen door de scanner. Dus met 300 dpi/ppi wordt bedoeld dat er 300 puntjes (dots of pixels) per inch (2,54cm) worden waargenomen. Hoe meer ppi/dpi hoe meer puntjes worden waargenomen en hoe groter de file wordt die tijdens het scannen wordt opgebouwd. Dus waar een pagina A4 op 200 dpi een ongecomprimeerde grootte oplevert van iets meer dan 11Mb wordt diezelfde pagina bij 300dpi praktisch 25Mb groot. Die ongecomprimeerde grootte is belangrijk als je beseft dat dat volume ook betrokken is in alle nabehandelingen die de scansoftware nog moet maken. Dus als de scancliënt (de software die de scanner aanstuurt) voorzien is van te weinig werkgeheugen (RAM), dan zal de buffer van het werkgeheugen snel vollopen en krijgt de scanner het signaal om de snelheid naar beneden bij te stellen zodat de scanner en scancliënt synchroon kunnen blijven lopen.

Complexer wordt het als een deel van de postprocessing van het scannen door een servercomponent wordt uitgevoerd. Dat kan bijvoorbeeld het OCR proces zijn, dat is het proces waarbij van de gescande teksten weer computer leesbare tekst wordt gemaakt. Ook hier geldt hoe groter het bestandsvolume hoe zwaarder het proces en dus hoe meer computertijd benodigd is. Wanneer dit geprogrammeerd is als een real-time verwerking dan zal ook hier een remmende werking op de scancliënt en dus op de scanner het gevolg zijn.

Daarnaast speelt in zo’n geval de netwerk bandbreedte een belangrijke rol. Even vanuit ons voorbeeld geredeneerd, een scanner die realistisch 100 vel per minuut kan scannen, produceert per uur: 60 x 100 x 2= 12.000 images (voor- en achterzijden) x 25Mb= 300.000Mb per uur oftewel 83Mb per seconde. Het kan dus geen kwaad systeembeheer te laten nakijken of het verkeer tussen scancliënt en server dat volume makkelijk aankan.

Ook de selectie van het te genereren bestandstype heeft invloed. In de vorige alinea's is aldoor uitgegaan van ongecomprimeerde bestanden. Soms wordt het gehele scanproces zodanig ingesteld dat pas als allerlaatste stap bij het aanmaken van een PDF/A bestand een jpegcompressie wordt toegepast. Dat betekent dus dat 25Mb per pagina het netwerk opgestuurd wordt. Compressie aan de basis, dus direct bij het scannen kan dat volume reduceren tot ruim minder dan één tiende hetgeen uiteraard gunstig uitpakt voor netwerktransport en dus indirect de scanner in staat stelt met hogere snelheid images af te leveren.

Afhankelijk van de leeftijd van het scansysteem  (werkstation en scanner samen) kan ook gekeken worden of het aantal processoren en de configuratie in het werkstation optimaal is. Uiteraard is dat afhankelijk van de specificaties van het werkstation en het operating systeem dat in gebruik is. Maar gecontroleerd dient te worden op hoeveel processoren de scancliënt kan draaien, of de configuratie 32bit of 64 bit is, is de videokaart toereikend, welke USB aansluiting is aanwezig en welke versie van het operating systeem actief is . Oudere windows systemen hebben meer beperkingen ten aanzien van de processortoewijzing en de maximale belasting van het RAM geheugen. Dus het kan zeer de moeite lonen een oud werkstation te vervangen door een moderner werkstation.

Virusscanners

Een laatste aparte alinea wil ik weiden aan virusscanners. Uiteraard is een modern systeem voorzien van adequate beveiliging, onder meer door een betrouwbare virusscanner. Het verdient echter nogal aanbeveling de scanner-output in de uitzonderingsregels van de virusscanner op te nemen. Het laatste dat je wil is dat de virusscanner iedere image die de scanner produceert beoordeeld en vrijgeeft. Dit verstoort in hoge mate de snelheid waarmee de bestanden kunnen worden weggeschreven, immers niet meer de scannersnelheid is dan de bepalende factor, maar de snelheid waarmee de virusscanner de images kan beoordelen en vrijgeven. Datzelfde geldt uiteraard ook voor de verwerking op een eventuele server. Let wel, dit is alleen mogelijk als het proces tussen scanner en werkstation een geheel vormen qua proces en er geen risico's aanwezig zijn dat de gescande bestanden geïnfecteerd raken door een virus of andere narigheid van buitenaf.