1D & 2D barcodes: lessons learned (1)

Blog
voorbeeld slechte barcode

Een duik in het diepe

Ik herinner me nog als de dag van gisteren dat ik ruim anderhalf jaar geleden in de eerste week van mijn huidige baan meteen in diverse barcode specificaties gedoken ben. De reden: Code 39 barcodes werden bij de een bepaalde klant niet of heel erg slecht gelezen, waardoor het vertrouwen in de scan oplossing afnam. Nu is mijn functie manager R&D en Delivery, maar van oorsprong en stiekem nog steeds ben ik developer en dus heb ik automatisch een bijna dwangmatige compulsieve neiging om de oorzaak van een probleem te achterhalen.

Het belang van barcodes bij scanning

Binnen de document capturing wereld worden barcodes om diverse redenen gebruikt. Hierbij kan gedacht worden aan document scheiding binnen een scanbatch, verrijking van documenten door metadata toe te voegen of het gebruiken van een sleutel waarmee de betreffende metadata in een extern systeem opgezocht kan worden. Het missen van een barcode om metadata toe te voegen dan wel op te zoeken is nog wel eenvoudig af te dekken door eisen aan aanwezigheid van metadata te stellen.

Het missen van een barcode bedoeld voor scheiding van documenten kan veel rampzaliger zijn. Zeker als deze scheiding juist moet gebeuren op een barcode met bepaalde metadata. Gevolg is dat documenten aan elkaar geplakt worden. In dit specifieke klant geval ging het om dossiers die geld waard zijn op het moment dat deze dossiers op orde (lees volledig) zijn. Iedere gemiste barcode kost dus zowel direct als indirect geld. Nu is dat uiteraard wel te ondervangen door een proces te organiseren zowel aan de voorkant bij het scannen, als aan de achterkant na het plaatsen van de documenten in een RMS. In deze tijd is dit echter natuurlijk niet meer wenselijk. Niet voor niets dat we werken aan volledige classificatie van inhoud en automatische scheiding van documenten op basis van inhoud. Deze blogpost gaat hier niet over; later meer hierover!

Schalen

Nadat ik zelf een specificatie geschreven had gericht op minimale formaten van barcodes bij diverse scan- en printresoluties, kwamen we vrij snel tot de conclusie dat er een probleem was in de grootte en kwaliteit van de barcodes. Het probleem werd met name veroorzaakt door een schaling bij het afdrukken, alsook door een mismatch in scan- en printresolutie. Nu is het voor de hand liggend, dat goede herkenning begint bij de kwaliteit in de hele keten van aanvoer. De praktijk is echter dat hier regelmatig problemen te vinden zijn.  Op het eerste gezicht leek hier niets aan de orde te zijn. Met het oog leken de barcodes in orde te zijn. Ze waren net iets lichter dan de barcodes die wel herkend werden.

Met de specificatie in de hand kwamen we tot de conclusie dat de barcode dusdanig geschaald was dat er te grote afronding verschillen optraden in de breedte van de modules/kolommen binnen de barcode. Een module is zowel de witte als zwarte streep binnen een 1D barcode. Code 39 ontleent zijn naam dan ook aan het feit dat er 3 brede en 6 smalle modules zijn, ofwel 3 brede uit 9 modules. Daarnaast zaten er barcodes tussen waarbij er een probleem met de zogenaamde start- en stop karakters was (* in het geval van code 39). Deze werden per ongeluk gedeeltelijk afgekapt in sommige gevallen.  De meeste barcode programma’s ondervinden grote problemen om uberhaupt te detecteren dat er een barcode staat als de start- en stopkarakters niet gevonden worden. Inmiddels is mijn oog genoeg getraind om een dergelijk probleem ook zonder software waar te nemen in een barcode 😉

Code 39

Een code 39 barcode wordt meestal gebruikt omdat ze zo eenvoudig te genereren zijn. Er is slechts een font nodig om van een “normale” tekst een barcode te maken. De afstand tussen modules behoort tussen de verhouding 2:1 en 3:1 te liggen en dient binnen de barcode zelf vast te zijn. Zoals gezegd dient er een start- en stopkarakter te zijn (*) en daarnaast kan als laatste karakter een zogenaamde check digit opgenomen worden. Dit is een modulo 43 controle over de voorgaande karakters in de barcode (minus start- en stopkarakter). Deze check digit is dus alleen een middel om te controleren of de gevonden waardes correct zijn. Laat nu juist dat meestal niet zo’n probleem bij het lezen van de barcodes zijn.

Een code 39 barcode bevat geen enkele redundantie (hierover in een volgende post meer). Er hoeft dus maar ergens in de barcode een probleem gebied te zijn en de hele barcode is niet meer te lezen. Neem daarbij dat de data dichtheid (hoeveel gegevens passen er binnen een barcode van bepaalde grootte) bij een code 39 ook nog eens laag is.

Vervelend was dat in sommige gevallen de barcode van deze klant door een telefoon wel goed gelezen werden. Leg maar eens uit waarom gespecialiseerde capture software de barcodes niet van een document kan lezen, terwijl de eerste de beste telefoon het wel kan. De uitleg is weliswaar logisch maar niet meteen voor de hand liggend. Hierbij kom je op het feit dat je met een telefoon op hoge resolutie (camera) met verschillende focus (hardware/software matig en handmatig) veelvuldig laat scannen op een heel specifiek deel van het document. Laten we nu net binnen de software in veel gevallen van te voren niet weten waar een barcode zich bevind binnen het document. Dit document krijgen we omwille van opslag- en verwerkingscappaciteit in de meeste gevallen op slechts 300 DPI binnen. Daarmee kom je dus op situaties uit waarbij dezelfde barcode engine (ZXing in dit geval) binnen de telefoon een barcode wel leest maar binnen scansoftware niet. ZXing is de standaard in Open Source barcode engines. Helaas bemerken we dat ZXing zeer slecht presteert op het moment dat de omstandigheden niet meer helemaal optimaal zijn

Barcode detectie voor herkenning

Dit is een van de redenen, waarom we zowel een eigen detectie toegevoegd hebben, alsook de mogelijkheid om barcodes met meerdere engines te lezen. Je merkt dat verschillende engines onder bepaalde omstandigheden beduidend beter presteren dan anderen. Daarnaast biedt onze eigen detectie de mogelijkheid om toch binnen afzienbare tijd met hoogst mogelijke kwaliteit barcodes parallel te lezen. We weten zeker dat er een barcode staat, ook indien barcode engines de barcode niet kunnen lezen.

Gevoeligheid van 1D barcodes

Op het moment dat de hele keten van afdruk en scan goed op orde is (en blijft) dan werken code 39 barcodes probleemloos. Toners/printkoppen willen in de praktijk nog wel eens slechter worden, rollers vuil worden of afdrukken “smeren” door de printer. Scanners worden vuil en lampen worden slechter. Om nog maar te zwijgen over compressie die in sommige gevallen onbedoeld gebruikt wordt. JBIG2 is een beruchte compressie binnen Multi Functional Printers, waardoor in de praktijk zelden van een ideale situatie gesproken kan worden. Hieronder een voorbeeld van een deel van een barcode. In de praktijk komen we nog veel slechter tegen dan deze.

voorbeeld slechte barcode

Achteraf gezien is de meest eenvoudig te genereren barcode dan wellicht ook niet de meest ideale barcode om te gebruiken…

Lees meer

Reageren is niet mogelijk.