Advanced BarCode Information - Fachhochschule Nordwestschweiz (FHNW) Abteilung f ur angewandte Informatik
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Fachhochschule Nordwestschweiz (FHNW)
Abteilung für angewandte Informatik
Advanced BarCode Information
PAX 0607 19
eingereicht von: Pascal Bender
Philippe O. Wagner
eingereicht am: Muttenz, 6. Juli 2007
Betreuer: Herr Prof. Dr. Christoph Stamm
Assistent: Herr Oliver Ruf
2
Zusammenfassung
Diese Projektarbeit beschreibt die evaluierten Konzepte zur Dekodierung von handelsüblichen Barcodes, so-
wie den Weg zur Entscheidungsfindung der dafür angebrachten Methoden zur effizienten Erkennung dieser
Strichcodes mittels Auswertung von Pixeldaten über Computer Vision.
Desweiteren wurde als Grundlage die zu verwendende Soft- und Hardware analysiert und zur Erklärung und
Erläuterung aufkommender Sachverhalte herangezogen.
Die gewonnenen Einsichten und ausprogrammierten Algorithmiken wurden anschliessend in eine modulare
und erweiterbare Applikation eingebettet, welche das Abfragen von definierten Datenquellen über verschiede-
ne Transportprotokolle, Caching von Daten und weiteren Features ermöglicht. Diese Anwendung wurde zuerst
für Nokia Smartphones der Serie 60 entwickelt und anschliessend aus Performancegründen auf Desktop Sys-
teme plattformunabhängig portiert.
ABCinfo
3
Inhaltsverzeichnis
1 Einleitung 6
1.1 Auftrag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 Ausgangslage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3 Projektplanung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3.1 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3.2 Entwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3.3 Entwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3.4 Optimierung/Testen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3.5 Dokumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2 Analyse und Konzeption 13
2.1 Mittelanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.1 Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.2 Nokia S60 (Model N93) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.3 Python für S60 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1.4 Erkenntnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2 Methodenanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.1 Aufbau von Barcodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.2 Computer Vision Konzepte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.3 Applikationskonzepte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3 Entwurf & Realisierung 39
3.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2 Konzeptrealisierung / Entscheidungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.2.1 Computer Vision Konzepte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.2.2 Applikationskonzepte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.3 Packaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.4 Klassen und Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.4.1 Externe Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.4.2 Applikationseinstellungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.4.3 Dateneinstellungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.4.4 E-Nummern Einstellungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.5 Sequenzen / Ablauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.6 Barcode Dekoder Voraussetzungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.7 Barcode Dekoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.7.1 Präprozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.7.2 Prozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.7.3 Validierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.8 Desktop Version – Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.8.1 Grafischer Modus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.8.2 Konsolen Modus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.9 Zusatzinformationen zur Implementierung der evaluierten Konzepte . . . . . . . . . . . . . . . 63
3.9.1 Applikationsentwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.9.2 Algorithmusentwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
ABCinfo
4
4 Optimierung / Testen 65
4.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.2 Testen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.2.1 Testbilder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.3 Applikationsoptimierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.4 Scriptsprache vs. Algorithmik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5 Ergebnisse 73
6 Ausblick 74
6.1 Erweiterungen der Algorithmik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.2 Erweiterungen der Applikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
7 Inhalt der beiliegenden CD 75
8 Glossar 76
Stichwortverzeichnis 80
Literatur 82
ABCinfo
5
Vorwort
Die vorliegende Arbeit entstand am Institut für Informatik der Fachhochschule Nordwestschweiz (FHNW). Sie
begann mit ihrem KickOff am 23. Oktober 2006 und dauerte bis zum 6. Juli 2007. Dank unserem Auftraggeber,
dem Institut für mobile und verteilte Systeme (IMVS) der FHNW, durften wir einen interessanten und abwechs-
lungsreichen Einblick in die Welt der mobilen Applikationsentwicklung in Kombination mit der Anwendung
von Computer Vision auf Mobiltelefonen geniessen. An dieser Stelle möchten wir eben diesem Auftraggeber
herzlich dafür danken. Ebenso sprechen wir unserem Ansprechpartner, Oliver Ruf, für seine stetige Bereitschaft,
uns bei Problemen zur Seite zu stehen, unseren Dank aus. Desweiteren gebührt unserem betreuenden Dozenten
und Leiter des IMVS, Prof. Dr. C. Stamm, Dank für sein Engagement und seine Unterstützung. Auch unseren
Kommilitonen danken wir für die anregenden Gespräche und Meinungen.
ABCinfo
6
1 Einleitung
1.1 Auftrag
Zur Klärung des Auftrages wird an dieser Stelle die Originalpassage aus dem Antrag für Projekt- und Diplom-
arbeiten herangezogen:
’Heutzutage haben fast alle der gängigen Mobiltelefone eine integrierte Kamera, welche hoch-
auflösende Bilder liefert. Die Projektarbeit umfasst die Entwicklung einer Applikation, wel-
che mit dieser Kamera Barcodes als Bilder erfasst und mittels Computer Vision (CV) verar-
beitet.
Aufgrund der nun erhaltenen Identifikation holt die Applikation zusätzliche Informationen
zu dem Produkt/Artikel/etc. aus dem Internet und stellt diese dem Anwender zur Verfügung.
Die zu verwendende Technologie ist die Python Programmiersprache, welche seit dem Januar
2006 von Nokia für die S60 Serie als OpenSource Projekt [14] veröffentlich wurde.
Die besondere Herausforderung dieses Projektes sind die Erkennung der Barcodes mittels CV
und die Entwicklung einer modularen und erweiterbaren Umgebung.’
Die Ziele, welche mit diesem Auftrag erreicht werden sollen, setzen sich wie folgt zusammen:
• Funktionierender Prototyp (zur Vorstellung bei potentiellen Kunden)
• Benutzerdokumentation
• Technische Dokumentation
Der angestrebte Zeitraum für das Projekt erstreckt sich über 36 Wochen und startet mit dem KickOff Meeting
vom 23.10.2006 bis hin zum Abgabedatum am 6.7.2007.
ABCinfo
7
1.2 Ausgangslage
Im Vorfeld dieser Arbeit wurde nach bereits existierenden Implementationen geforscht. Um einen ersten Ein-
druck über die herrschenden Marktverhältnisse zu erlangen, werden hierzu die folgenden Projekte kurz erläutert:
• ReadBarC / ReadBarJ
• BaToo
• CodeCheck
ReadBarC / ReadBarJ
Das ReadBar Projekt [9], welches als C++, sowie als Java Implementation von John A. Webb entwickelt wurde,
beinhaltet einen Algorithmus zum dekodieren von Barcodes auf Symbian basierten Mobiltelefonen. Da wir
unseren eigenen Algorithmus zur Dekodierung entwickeln wollten und dieser auf Python basieren sollte, wurde
darauf verzichtet eine Portierung von C++ (oder Java) auf Python vorzunehmen. Ebenso wenig wollten wir
die existierende Rechenvorschrift als C-Extension in Python einbinden und als Modul verwenden (Python-
Wrapping). Die Voraussetzung dafür wäre eine weitere Einarbeitung in die C-API und das proprietäre C-Umfeld
von Symbian gewesen. Dieses Konzept wird zu einem späteren Zeitpunkt in diesem Dokument aufgearbeitet
und erläutert.
BaToo
Das Barcode Recognition Toolkit [21] wurde an der ETH Zürich von Robert Adelmann entwickelt und existiert
als C++, sowie als Java Implementation. Der Ausblick auf einen eigens entwickelten, auf Python basierenden
Algorithmus, verwarf auch hier die Idee einer Implementation von Fremdcode.
Obwohl keines dieser beiden Projekte als ’Codelieferant’ diente, konnten wir uns anhand des frei verfügbaren
Codes und der Dokumentation dazu ein erstes Bild über allfällige Konzepte gemacht werden. Ausserdem hielten
wir Kontakt zum Entwickler von BaToo, Robert Adelmann, der uns mit seiner Meinung nützliche Tipps geben
konnte. Zum konkreten Inhalt und dessen Nutzen wird ebenfalls später in diesem Dokument eingegangen.
CodeCheck
Zu Roman Bleichenbacher, Initiant und Entwickler von CodeCheck [22], wurde zu Beginn ein intensiver Kon-
takt gepflegt. Sein Projekt hat nichts mit der Erkennung von Barcodes zu tun, vielmehr steht CodeCheck für
eine Datenbank mit einer enormen Menge an Produktinformationen. Hinzu kommen Allergikerinformationen,
auf welche anhand von E-Nummern zugegriffen werden kann. Die Idee unsererseits war es, anhand von detek-
tierten Barcodes auf diese Informationen zuzugreifen, um diese dem Benutzer zur Verfügung stellen zu können.
Nach einem Treffen und einer Projektvorstellung bei Roman Bleichenbacher, steuerte man eine gemeinsame
Zusammenarbeit mit CodeCheck an. Die Fülle an abrufbaren Informationen rundet den Datenteil des Projekts
ab.
Wie sich im Verlauf der Arbeit herausstellen musste, entwickelte sich eine Kooperation nur schleppend und
musste einige Tage vor Projektabgabe abgesagt werden.
ABCinfo
8
1.3 Projektplanung
Um ein Projekt, welches 36 Wochen dauert und eine gewisse Komplexität mit sich bringt, erfolgreich durch-
zuführen, bedarf es einer Planung im Vorfeld.
Insgesamt besteht die Planung aus 5 Hauptphasen, welche in sich wiederum in Zwischenschritte aufgeteilt sind.
Gewisse Abschnitte werden als zyklisch beschrieben, da sie oftmals durchlaufen werden, bis die nächste Phase
beginnen kann. Im Folgenden werden diese Etappen beschrieben und reflektiert. Das hierzu herangezogene
Instrument ist das Gantt-Diagramm (8), welches die Planung visualisiert.
1.3.1 Analyse
Da dieses Projekt den Einsatz von neuen Technologien fordert, ist es in einem ersten Schritt von grosser Bedeu-
tung, sich mit den nötigen Werkzeugen und derer Handhabung vertraut zu machen. Dazu gehören das Installie-
ren von Entwicklungsumgebungen, das Durcharbeiten von Tutorials, das Schreiben von Testprogrammen sowie
das Lesen der Theorie, um sich über verschiedene Strategien und Konzepte zu informieren. Zusätzlich wird an
dieser Stelle auch darüber diskutiert und beschlossen, wie das Projekt angegangen und verwirklicht werden soll.
Die in dieser Phase gewonnenen Erkenntnisse werden im zweiten Abschnitt mit der Konzeptevaluierung näher
besprochen und erläutert.
Dauer Start
Analyse 20 Tage Di, 24.10.06
Installation Software 3 Tage Di, 24.10.06
Python kennenlernen 7 Tage Fri, 27.10.06
Nokia API kennenlernen 4 Tage Di, 7.11.06
Recherche Konzepte 6 Tage Mo, 13.11.06
(a)
(b)
Abbildung 1: Gantt-Diagramm Analysephase
Die exakte Ausführung dieser ersten Etappe bildet das Fundament für einen im darauffolgenden Schritt effizient
ausgearbeiteten Entwurf.
Insgesamt wurden für die Analysephase 20 Tage ausgelegt. Nach Abschluss dieses Schrittes musste man erken-
nen, dass eine Woche mehr Zeit für die Analyse angebracht gewesen wäre. Somit haben sich Teile der Analyse
mit dem Entwurf, insbesondere mit dem Schreiben von Testmodulen, vermischt. Diese Tatsache kann aber auch
als normaler Ablauf angesehen werden, da gewisse Eigenschaften der Programmiersprache und der Geräte erst
bei derem Praxiseinsatz erlernt werden können. Ansonsten konnte dieser Schritt erfolgreich und termingerecht
abgeschlossen werden.
ABCinfo9
1.3.2 Entwurf
Die zweite Phase der Projektplanung besteht darin, die Resultate der ersten Phase zu nutzen um sie bedürfnisgerecht
in einen konkreten Entwurf der kompletten Architektur umzusetzen.
Hierbei werden zuerst die verschiedenen Konzepte aus dem Analyseschritt herangezogen und weiter ausgear-
beitet. Dazu werden unter anderem Testmodule entwickelt, welche den praktischen Bezug zur Analyse herstel-
len und die Entscheidung für die richtige Strategie unterstützen. Nachdem dieser, sich wiederholende, Schritt
abgeschlossen wurde und die adäquatesten Methoden zur Umsetzung der Algorithmik und der Applikation aus-
gewählt und verfeinert wurden, kann damit begonnen werden, die Architektur mittels UML 2.0 8 und dessen
Werkzeuge zu planen und aufzuzeigen. Abschnitt 3 dieser Dokumentation erläutert den Entwurf konkret.
Dauer Start
Entwurf 41 Tage Di, 21.11.06
Konzeptideen sammeln 5 Tage Di, 21.11.06
Konzepte konkretisieren 5 Tage Di, 28.11.06
Testmodule entwickeln 14 Tage Di, 5.12.06
Image Controller 2 Tage Di, 5.12.06
EBV Controller 2 Tage Do, 7.12.06
Barcode Controller 2 Tage Mo, 11.12.06
Algorithmik 2 Tage Mi, 13.12.06
Cache Controller 2 Tage Fr, 15.12.06
Database Controller 2 Tage Di, 19.12.06
Parsing Controller 2 Tage Do, 21.12.06
Konzeptentwurf 2 Tage Sa, 23.12.06
Architektur (UML, API, ...) 8 Tage Di, 26.12.06
Konzept, definitiv 7 Tage Fr, 5.1.07
(a)
(b)
Abbildung 2: Gantt-Diagramm Entwurfsphase
Der Abschluss des Entwurfschrittes besteht darin, zu wissen, welche Konzepte zur Umsetzung der Applikation
weiterverfolgt werden. Zusätzlich ist der konkrete Aufbau (Klassen) und der Ablauf (Sequenzen) bekannt. Mit
diesen Grundlagen kann damit begonnen werden, die Anwendung zu realisieren und alle Vorgaben zu imple-
mentieren.
Die Entwurfsphase schlägt in der Planung mit 41 Tagen zu Buche. Aufgrund der Erkenntnis, dass das zyklische
evaluieren der Konzepte bis zur Entscheidungsfindung Zeit beanspruchen würde, erliess man für diesen Schritt
eine längere Frist. Diese Planungsentscheidung stellte sich als angemessen heraus. Am Stichtag standen die
Konzepte und die Architektur wie geplant und es konnte mit der nächsten Phase begonnen werden.
ABCinfo10
1.3.3 Entwicklung
Nachdem in zwei Schritten die Mittel und Methoden analysiert und die Konzepte ausgearbeitet wurden, besteht
die dritte Phase, unter Einsatz der in Vorlesungen vermittelter Techniken und Anwendungen, aus der Realisie-
rung eben dieser Entwürfe und Strategien.
Die dabei entstehenden Probleme, welche in der Konzeption nicht vorhergesehen werden konnten, müssen an
dieser Stelle behoben werden. Dazu ist es unter Umständen notwendig, Konzepte zu erweitern, zu ergänzen oder
gar gänzlich zu ersetzen. Die praktische Implementierung von theoretischen Konzepten lässt diesem Schritt sei-
ne zyklische Eigenschaft zukommen. Verschiedene Module und Programmteile müssen mehrfach überarbeitet
werden bis das gewünschte Resultat erreicht wird.
Dauer Start
Entwicklung 55 Tage Di, 16.1.07
Überarbeiten der Testmodule 13 Tage Di, 16.1.07
Ergänzen der Module (zyklisch) 15 Tage Fr, 2.2.07
Model-View-Controller 13 Tage Fr, 23.2.07
Überarbeiten MVC (zyklisch) 14 Tage Mi, 14.3.07
(a)
(b)
Abbildung 3: Gantt-Diagramm Entwicklungsphase
Um die Anwendungseigenschaften gemäss Auftrag zu entwickeln und somit den Mindestanforderungen die-
ses Projektes gerecht zu werden, wurden 55 Tage eingeplant. Die Applikation konnte in dieser Zeit abermals
korrigiert und um Features erweitert werden. Die veranschlagte Dauer von knapp 3 Monaten erwies sich als
ausreichend um eine erste Version der Anwendung & Algorithmik lauffähig zu gestalten.
ABCinfo11
1.3.4 Optimierung/Testen
Die letzte Phase beschäftigt sich mit dem Testen und der Optimierung der Applikation. Dabei werden in ers-
ter Linie alle möglichen Benutzereingaben geprüft und abgefangen, sowie alle Fehler- und Zustandsszenarios
durchgespielt. Ebenso werden möglichst viele Referenzvorlagen für das Testen der Algorithmik eingespielt.
Die gewonnenen Ergebnisse dienen anschliessend zur Optimierung der Anwendung und der Algorithmik. Die-
ser Schritt ist, wie bereits die Entwurfsphase, zyklisch ausgelegt. Das Programm und seine Rechenvorschrift
werden somit Schritt für Schritt verbessert. Eine Einschränkung besteht fast nur durch die zeitliche Begrenzung
des Projektes, sowie durch gewisse grundlegende Eigenschaften der Mittel und Methoden. In Abschnitt 3.6
werden diese Grenzen behandelt und dargelegt.
Dauer Start
Testen / Optimierung 46 Tage Di, 3.4.07
Komponententesten 15 Tage Di, 3.4.07
Testen der Einzelmodule 9 Tage Di, 3.4.07
Optimierung der Einzelteile 6 Tage Sa, 14.4.07
(zyklisch)
Gesamttesten 31 Tage Mo, 23.4.07
Testen der Anwendung 5 Tage Mo, 23.4.07
Optimierung der Applikation 21 Tage Mo, 30.4.07
(zyklisch)
Bugfixing (zyklisch) 5 Tage Di, 29.5.07
(a)
(b)
Abbildung 4: Gantt-Diagramm Optimierungs- und Testphase
Das Bewusstsein darüber, dass dieser Schritt nicht unterschätzt werden darf, liess ihm 46 Tage zur Vervollständigung
zukommen. Das Testen brachte Fehler zum Vorschein, die in dieser Phase behoben werden konnten. Gleichzei-
tig wurde die Applikation optimiert. Konkret bedeutet dies, dass die Zeit genutzt werden konnte, um Features,
welche nicht im Pflichtenheft erscheinen, einzubauen. Diese erhöhen die Bedienerfreundlichkeit und verbessern
gleichzeitig die Performance. Neue Ideen traten zum Vorschein, welche schliesslich nur aufgrund Zeitmangels
nicht vollständig umgesetzt werden konnten. Mehr dazu in Abschnitt 6 – Ausblick.
Das Ziel des Projektes war es die Applikationsversion auf den Status eines Prototyps zu bringen. Dazu reichte
die Dauer dieser Phase aus.
ABCinfo12
1.3.5 Dokumentation
Um die geleistete Arbeit einem Betrachter auf schlüssige Weise darlegen zu können, ist eine verständliche Do-
kumentation die wichtigste Arbeit überhaupt. Sie beinhaltet alle Punkte, welche unter 1.3 – Projektplanung
angesprochen werden, im Detail. Dabei wird die Eigenleistung ausgeleuchtet und kritisch hinterfragt. Die Me-
thodenkompetenz, mit welcher die Arbeit angegangen und gehandhabt wurde, soll ebenso ersichtlich sein, wie
die Fachkompetenz, mit welcher Aufgaben- und Problemstellungen gelöst wurden. Ebenso muss die Planung
ersichtlich sein und reflektiert werden, was im bisherigen Text das Hauptthema war.
Dauer Start
Dokumentation 27 Tage Di, 5.6.07
Arbeitsbucheinträge verarbeiten 2 Tage Di, 5.6.07
Konzepterkenntnisse verarbeiten 2 Tage Do, 7.6.07
Zusammentragen 3 Tage Mo, 11.6.07
Ergänzen / Korrigieren (zyklisch) 14 Tage Do, 14.6.07
Latex 2 Tage Di, 3.7.07
Präsentation vorbereiten 2 Tage Do, 5.7.07
(a)
(b)
Abbildung 5: Gantt-Diagramm Dokumentationsphase
Rückblickend kann man die Projektplanung als erfolgreich betrachten. Es wurden alle Schritte so detailiert
geplant, wie es im Vorfeld machbar war. Der Zeitplan konnte für fast alle Termine eingehalten werden und barg
keine Überraschungen negativer Art. Ausgenommen ist die Analyse, welcher man 1-2 Wochen mehr Zeit hätte
einräumen können. Dieser Punkt hat uns gezeigt, dass ein Projekt dieser Dauer und in diesem Umfang mehr
Forschung vorweg benötigt hätte.
Diese Erkenntnis und das Wissen über die Wichtigkeit guter Planung werden uns in weiteren Projekten mit
Sicherheit erfolgreich begleiten.
ABCinfo13
2 Analyse und Konzeption
2.1 Mittelanalyse
2.1.1 Python
Die komplette Applikation soll laut Auftrag die Python Technologie verwenden. Zum Einblick und dem besse-
ren Verständnis wird Python an dieser Stelle vorgestellt.
Python ist eine Programmiersprache, welche in den 90er Jahren in Amsterdam entwickelt wurde. Sie unterstützt
objektorientierte, aspektorientierte und funktionale Programmierung. Es existiert eine umfangreiche Standard-
bibliothek mit nützlichen Modulen für viele verschiedene Arten von Anwendungen.
Python ist sehr eifach und übersichtlich gehalten. Die Lesbarkeit von Code steht im Vordergrund und erlaubt
es Programmierern, sich ohne grossen Aufwand in eine fremde Applikation einzuarbeiten. Dies fördert die
Erweiterbarkeit auch in einem teamorientierten Sinne.
Die automatische Speicherbereinigung von Python hält das Speicherkontingent stets auf optimalem Niveau.
Datentypen werden nicht, wie etwa in C++, statisch typgeprüft (d.h. vor der Programmausführung), sondern
dynamisch verwaltet. Durch diese ’dynamische Typisierung’ wird erst zur Laufzeit entschieden, welcher Inhalt
den Datentypen zugeordnet wird.
Ein weiterer Unterschied zu anderen Programmiersprachen besteht darin, auf welche Art Python Leerzeichen
behandelt. Das Einrücken von Codeblöcken dient als Strukturierungselement und trägt eine semantische Rele-
vanz. Auf das Gliedern mit Klammern wird hingegen verzichtet.
Ein Beispiel:
Listing 1: Codestrukturierung mit C++
i n t add ( i n t a , i n t b ) 1
{ 2
r e t u r n a+b ; 3
} 4
Listing 2: Codestrukturierung mit Python
d e f add ( a , b ) : 1
r e t u r n a+b 2
Übrigens: Python wurde nicht etwa nach der gleichnamigen Schlangenart, sondern nach der britischen Komi-
kertruppe Monty Python benannt.
Teile von Google sowie die komplette YouTube Umgebung wurden in Python realisiert. Auch Programme wie
der offizielle BitTorrent-Client machen von Python Gebrauch.
Python vs. Java vs. C++
So bestechend die Einfachheit von Python ist, so kritisch muss die Performance gegenüber anderen Program-
miersprachen hinterfragt werden. Nachfolgend werden verschiedene Aspekte von Python mit ihrem Äquivalent
in Java und C++ verglichen.
Komplexität Wenn es darum geht die Komplexität von geschriebenem Code zu vergleichen, ist Python der
eindeutige Gewinner. Python-Code ist kürzer, intuitiver und schneller programmiert als Java oder gar C++ Code.
Testprogramme, die für Benchmarks geschrieben wurden, enthalten in Python 921 Bytes, in Java 2’742 Bytes.
Allgemeine Programm Performance Um den Initialisierungs Overhead zu messen, wurde der minimalste
Code geschrieben, mit welchem die verschiedenen Programmiersprachen ihre Umgebung starten können. In
Python ist dies schlichtweg eine leere Datei. In Java und C++ ist es die Klassen- und Main-Instanzierung.
ABCinfo14
Dabei hat Python seinen Interpreter in einer Zeit von 0.04 Sekunden gestartet. Java benötigt 0.25 Sekunden.
Dies bedeutet, dass Python seine Umgebung 6.3 mal schneller starten kann als Java, was vor allem bei kleineren
Programmen einen Geschwindigkeitsvorteil bringt. Bei grösseren Applikationen ist diese Zeit eher von geringer
Bedeutung.
Nachdem der Interpreter resp. die virtuelle Maschine ihren Start vollzogen hat, kann die Objektallokation vergli-
chen werden. Dabei wird eine leere Klasse erzeugt und mehrfach instanziert. Python benötigt für die Allokation
von 1 Mio. Instanzen 211.11 Sekunden, wohingegen Java nur 23.65 Sekunden braucht. Dies entspricht einem
8-fachen Vorsprung in Java. Python wird während der Programmausführung und der häufigen Instanzierung von
Klassen demnach Geschwindigkeit einbüssen.
Netzwerk / IO Performance Wenn es um Input/Output Operationen auf Dateiebene geht, sind Python und
Java praktisch gleichwertig. Bei Netzwerkverbindungen liegt der Flaschenhals bei der Abindung und nicht bei
der Applikation selbst.
System-Level Performance Wenn systemnahe Funktionen und algorithmische Berechnungen ausgeführt wer-
den, zeigt C++ seine innere Performance. Um eine Liste mit 3 Millionen Einträgen zu füllen, benötigt Python 31
Sekunden. C++ erledigt diese Aufgabe in nur 0.19 Sekunden. Ebenso liegt Python weit zurück wenn es darum
geht, eine leere Loop 20 Millionen mal zu durchlaufen. In nur 0.18 Sekunden absolviert C++ diesen Test, wobei
es bei Python 31.81 Sekunden bedarf.
ABCinfo15
2.1.2 Nokia S60 (Model N93)
Die zu verwendende Hardware besteht aus dem Mobiltelefon Nokia N93, welches zur Serie 60 der Nokia
Smartphones gehört. Die Software Grundlage bildet das Betriebssystem Symbian. Dieses ist zur Zeit in der
Version 9.2 (3rd Edition) erhältlich und wurde von Nokia für seine eigenen Geräte entwickelt.
(a) Nokia N93
Abbildung 6: Applikationsplattform - Nokia N93
Eigenschaften Die, für das Projekt wichtigsten, Eigenschaften des Nokia N93 umfassen:
• 3.2 Megapixel CMOS Sensor
• Carl-Zeiss Optik mit 3-fach optischem Zoom
• Autofokus
• WLAN, UMTS 8
• 50 MB interner Speicher
CPU 8
Prozessor-Typ:
Texas Instruments OMAP 2420
Architektur:
ARM-11 (330 MHz)
Für das N93 liefert Texas Instruments den Single-Chip Prozessor OMAP 2420, welcher alle Mobilstandards und
eine Vielzahl von Multimedia Anwendungen unterstützt. Die mit 330 MHz getaktete Zentraleinheit ermöglicht
die parallele Verarbeitung von Funktionen. Weitere Features sind der 2D/3D Grafikbeschleuniger und die Un-
terstützung aller gängigen Peripheriestandards.
Die ARM-11-Architektur beinhaltet eine Floating Point Unit, welche Floating Point Operationen auf Mikro-
kontrollerebene realisieren kann. Dies ist keine Selbstverständlichkeit, da die meisten bisherigen Nokia Mobil-
telefone Float-Operationen auf Softwarebasis emulierten.
ABCinfo16
(a)
Abbildung 7: OMAP High-Performance Prozessor
Nokia S60 Symbian Programmierschnittstelle Die wohl leistungsfähigste Variante um Anwendungen für
ein 3rd Edition Smartphone von Nokia zu schreiben, ist die Nutzung der Nokia C-API unter Verwendung von
C++. Leider ist sie nicht die effizienteste und wohl auch die unbequemste (sofern nur High-Level Program-
miersprachen betrachtet werden). Mit Hilfe der öffentlich zugänglichen und gut dokumentierten C-API ist es
möglich fast alle Features des Mobiltelefons zu nutzen. An dieser Stelle möchten wir Robert Adelmann der
ETH Zürich zitieren. Er wurde von uns auf den Aufwand seines C++ Projektes zur Barcodedekodierung (1.2)
angesprochen.
’J2ME Version ging sehr schnell (...) Mit C++ Symbian sieht die Sache ganz anders aus. Nach 6
Monaten wird man in diesem doch sehr speziellen C++ Dialekt so langsam warm.’
ABCinfo17
2.1.3 Python für S60
Seit dem Januar 2006 existiert das von Nokia ins Leben gerufene OpenSource Projekt Python für S60 (PyS60).
Dem Entwickler steht damit fast die komplette Standardbibliothek von Python zur Verfügung. Auf diese Weise
ist es nun auch möglich auf Mobilgeräten sehr produktives Software Development zu betreiben. In kurzer Zeit
kann, wie auch mit Python, viel erreicht werden. Desweiteren existieren eine Menge externer Module für PyS60,
wie etwa XML Parser oder Bildverarbeitungsfunktionen.
PyS60 selbst kommt mit einigen nützlichen Modulen für den Mobilbereich. Für dieses Projekt besonders in-
teressant ist beispielsweise die Kamera API, die jedoch noch immer keinen Autofokus und bis vor kurzem
auch keinen Viewfinder unterstützt hat. Der Viewfinder ist das Live-Bild resp. der Sucher, welcher nach der
Initialisierung der nativen Mobiltelefonkamera auf dem Bildschirm erscheint. Obwohl die Nokia C-API die
Ansteuerung der Autofokus Hardware seit kurzem ermöglicht, wurde diese noch nicht in die neuste PyS60 Ver-
sion implementiert. Somit bleibt diese Pendenz beim Entwickler, der Funktionen, welche auf die automatische
Schärfentiefeneinstellung Einfluss nehmen, in C++ schreiben muss.
Die Möglichkeit die Nokia C-API in Python zu nutzen, bezeichnet man als C-Extension Programmierung.
Diese ist nicht ganz trivial und wird in den Applikationskonzepten (2.2.3) beim Problem der Bildaufnahme
näher beschrieben. Um einen Eindruck über die Performance von Python auf dem Mobilgerät zu gewinnen,
wurde ein Integer Benchmark auf verschiedenen Plattformen durchgeführt. Dabei werden die Fibonacci Zahlen
in 5 Messreihen mit einer Rekursionstiefe von 30 berechnet. Auf den getesteten Plattformen wurde der Standard
Interpreter von Python verwendet.
Plattform (Mobil) Zeit (in Sekunden)
Nokia N93 (3rd) 80.47
Nokia N73 (3rd) 192.77
Plattform (Desktop)
PowerPC G4* 7.13
Hewlett-Packard Pavilion dv6000** 1.58
Hewlett-Packard Pavilion dv6000 0.09
mit Psyco JIT Modul***
(a)
Abbildung 8: Benchmark; * 1.5GHz, 1.25GB RAM; ** Dual-Core2 1.83GHz, 2GB RAM; *** das Psyco JIT
Modul ist ein Just-in-Time Compiler für Python, welcher die Codeausführung 4-100 mal beschleunigt.
Schon zu diesem Zeitpunkt erkennt man die grosse Schwachstelle von systemnahen Operationen mit Python
auf dem Mobiltelefon. Der Wert, den der PowerPC G4 mit 1.5 GHz liefert, liegt für Desktopsysteme im guten
Mittelfeld. Da der HP Pavilion mit einem Dual-Core Prozessor der zweiten Generation ausgestattet ist, läuft der
Test dementsprechend performant. Das erwähnte und getestete Psyco Modul wird zu einem späteren Zeitpunkt
näher erläutert. Die Erkenntnis, dass Psyco eine hohe Leistungssteigerung auf x86 Systemen bewirken kann,
spielt im Verlaufe des Projektes eine nicht unwichtige Rolle.
In Abschnitt 2.1.1 wurde Pythons System-Level Performance zum ersten Mal angesprochen. Die Befürchtung,
dass Python, wie es bereits im Vergleich zu anderen Programmiersprachen auf Desktopsystemen der Fall war,
die Geschwindigkeit auch auf Mobilgeräten enorm bremsen würde, scheint sich an diesem Punkt zu bestätigen.
ABCinfo18
2.1.4 Erkenntnisse
Python ist eine starke und einfach zu nutzende High-Level Programmiersprache. Da Advanced BarCode Infor-
mation modular und erweiterbar aufgebaut sein soll, ist die Wahl der Sprache angemessen. Ausserdem kann
damit in 36 Wochen viel erreicht werden.
Die Kehrseite liegt darin, dass ein Grossteil der Applikation aus Algorithmik bestehen wird. Für dieses maschi-
nennahe Programmieren ist Python weniger geeignet. Die Benchmarks der letzten Abschnitte haben gezeigt,
dass Python durch seine fast schon zu sehr auf High-Level ausgelegte Architektur, alle systemnahen Operatio-
nen verlangsamt. Auf dem Mobilgerät kommt dieser Nachteil noch deutlicher zum Vorschein.
Mit Rücksichtnahme darauf, dass ein Mobiltelefon nicht mit einem Computer verglichen werden darf, leistet das
Nokia N93 beachtliches. Seine Multimediafähigkeiten und die Hardware sind auf dem neusten Stand der Tech-
nik. Das Betriebssystem Symbian OS ist vielfältig, weist allerdings Schwachstellen im Memory Management
auf (diverse Komplettabstürze in nativen Applikationen, sowie in Drittanwendungen. Beispielsweise stürtzt die
Kameraapplikation nach 25 Aufnahmen ab). Ausserdem wurde die Sicherheitspolitik in der dritten Edition von
Symbian dermassen verschärft, dass es als Entwicklerplattform oftmals sehr mühsam zu handhaben ist.
Python für S60 ist in seiner Verwendung sehr bequem. Leider existiert es noch nicht sehr lange (2006), was sich
anhand der vielen Fehlern des Interpreters erkennen lässt. Ausserdem sind einige Teile und Module, welche im
Projekt benötigt gewesen wären, nicht in PyS60 vorhanden.
Wie und welche Werkzeuge und Mittel bei der Umsetzung der Applikation genutzt werden und warum man
sich für oder gegen sie entschieden hat, wird der Abschnitt der Konzeption und des Entwurfes zeigen.
ABCinfo19
2.2 Methodenanalyse
Als nächstes werden die Methoden, durch welche die Anwendung entstehen soll, analysiert. Dabei geht es
einerseits darum, verschiedene Verfahren zur Bildverarbeitung und Barcodeerkennung in Betracht zu ziehen,
andererseits wird ein Vorwissen zum Aufbau der Barcodes geschaffen, welches zum Verständnis der Dekodie-
rung unabdingbar ist. Desweiteren werden Ideen zur Applikationsarchitektur erforscht und ausgewertet. In der
Realisierungsphase (Entwurf & Realisierung, siehe Seite 39), werden anschliessend die adäquatesten Konzepte
ausgewählt und für die Realisierung der Anwendung eingesetzt.
2.2.1 Aufbau von Barcodes
Geschichte
Die Grundlagen zur Arbeit mit Barcodes wurden bereits 1949 von Joseph Norman Woodland und Bernard Silver
erarbeitet. Knapp 25 Jahre später, im Jahr 1973, wurde in den Vereinigten Staaten der UPC Barcode (Universal
Product Code) eingeführt. Ein Jahr später wurde in einer Filiale der amerikanischen Supermarktkette ’Marsh’
das erste, mit einem Strichcode markierte Produkt, eine 10er Packung ’Juicy Fruit’ des Herstellers ’Wrigley’,
von einer Scannerkasse erfasst und verkauft. [25] Europa hat im Jahr 1976 die ’European Article Number’
(EAN) eingeführt. Heute ist sie unter dem Namen ’International Article Number’ bekannt.
Im Handel wird auch heute noch vorwiegend der EAN Barcode (2.2.1) eingesetzt, wobei dieser mittelfristig
durch RFID 1 Chips verdrängt wird. Noch schneller wird der Code39 (2.2.1), welcher vor allem in der Industrie
und Medizin eingesetzt wurde, durch die DataMatrix abgelöst (2.2.1). Der Hauptgrund für diese Entwicklung
ist die Tatsache, dass mehr Informationen auf einer kleineren Fläche abgebildet werden können. Der ’Barcode’
entwickelt sich somit vom Identifkationsmedium zum Informationsmedium. Dieser Fortschritt hat bereits Ende
der achtziger Jahre begonnen und schreitet unaufhaltsam fort. In der Gegenwart werden auch spezielle Codes
wie der Shotcode 2.2.1 als Marketinginstrument eingesetzt. Blogger 2 verwenden Matrixcodes wie den QR
Code 2.2.1 zur Erstellung von Offlineblogs. Trotz den neuen Arten und Einsatzgebieten, sind die klassischen,
eindimensionalen Barcodes nach wie vor fester Bestandteil unseres Alltags.
Typen und Spezifikationen
Lineare Barcodes, Eindimensionale Barcodes Lineare, eindimensionale Barcodes sind nach allgemeiner
Formulierung ein Muster aus parallel angeordneten, alternierend hellen und dunkeln Linien und Lücken mit
unterschiedlichen Dicken. Lineare Barcodes, auch Strichcodes genannt, sind die einfachste, kostengünstigste
und flexibelste Methode, Objekte maschinell zu kennzeichnen. Durch die Standardisierung ist ein weltweit
funktionierendes Identifikationssystem geschaffen worden.
EAN EAN ist die Abkürzung für European Article Number und ist die veraltete Bezeichnung für International
Article Number.
EAN ist ein Code, bestehend aus numerischen Zeichen zwischen 0 (null) und 9 mit einer fixen Länge von 8 oder
13 Zeichen. Die EAN Codes werden zentral verwaltet und auf Anfrage an Hersteller für ihre Produkte vergeben.
Die europäische Artikel Nummer ist nach der DIN Norm 66236 festgesetzt.
EAN13 Die 13 Ziffern der EAN13 bedeuten:
• 7 Ziffern: Global Location Number bestehend aus:
3 Ziffern EAN-Ländercode der GS1
4 Ziffern Hersteller Nummer
1 RFID = Der englische Begriff Radio Frequency Identification (RFID) bedeutet im Deutschen ’Identifizierung über Radiowellen’. RFID
ist ein Verfahren zur automatischen Identifizierung von Gegenständen und Lebewesen. Neben der berührungslosen Identifizierung und der
Lokalisierung von Gegenständen steht RFID auch für die automatische Erfassung und Speicherung von Daten. [26]
2 Ein Blog (engl. Wortkreuzung aus Web und Log), ist ein digitales Journal. Der Herausgeber dieses Journals wird Blogger genannt.
ABCinfo20
7 623900 205080 5449 2387
(a) EAN13 (b) EAN8
Abbildung 9: Abbildung 2.2.1 zeigt einen EAN13 und 2.2.1 eine EAN8 Barcode.
• 5 Ziffern für die Artikelnummer
• 1 Ziffern für die Prüfziffer
EAN8 Der EAN8 Code besteht nur aus zwei Blöcken zu je 4 Zeichen aus den Zeichensätzen A (linker
Teil) und C (rechter Teil). Die 8 Ziffern der EAN8 bedeuten:
• 2 Ziffern für die Global Location Number
• 3 Ziffern für die Hersteller Nummer
• 3 Ziffern für die Artikelnummer, inkl. Prüfziffer
ISBN ISBN ist die Abkürzung für ’International Standard Book Number’. Dieser Code besteht aus einem
adaptierten EAN13 Barcode. Die Ziffern 0, 1 und 2 werden dabei durch die Zeichenfolgen ’978’ oder ’979’
ersetzt.
Instore Barcodes Instore Barcodes sind EAN kodierte Barcodes, welche nicht in der globalen Datenbank
registriert sind. Diese Barcodes sind nicht eindeutig und dürfen nur im eigenen Warenhaus für Eigenprodukte
wie Back- und Frischwaren verwendet werden. Diese Barcodes sind nicht eindeutig und beginnen mit einer 0
oder einer 2.
Aufbau eines EAN Barcodes Die Spezifikation der EAN Barcodes ist offen und frei verfügbar. Sie kann
beim Schweizer Kompetenzzentrum für Standards (GS1) unter [32] und [33] als PDF Datei bezogen werden.
Der Aufbau und die Kodierung der Barcodes können aus diesen Standards entnommen werden. In den folgen-
den Abschnitten werden die Eigenschaften von EAN beleuchtet, bevor die Kodierung und Dekodierung der
Barcodes näher beschrieben werden.
Grundbegriffe Um eine Abhandlung zum Aufbau und zur Handhabung von Barcodes zu ermöglichen, bedarf
es im Voraus der Klärung gewisser Grundbegriffe.
Modul Ein Modul ist die kleinstmögliche Einheit eines Barcodes. Ein Zeichen (beispielsweise 6’) besteht
’
immer aus 2 Balken und 2 Lücken, welche insgesamt aus 7 Modulen bestehen (1 Zeichen = 7 Module).
Beispiele solcher Module werden in der Abbildung 10 dargestellt.
Balken Ein Balken ist ein sichtbarer, dunkel gedruckter Verbund, bestehend aus einem oder mehreren Modulen.
Synonyme: Strich, Bar, Linie.
Lücke Eine Lücke ist die Inverse eines Balkens. Sie erscheint im Kontrast zum Balken hell und besteht aus un-
bedruckter Fläche. Eine Lücke kann ein oder mehrere Module breit sein. Synonyme: Space, unsichtbarer
Strich.
ABCinfo21
Zeichen Ein Barcode besteht aus Zeichen, welche numerischen oder alphanumerischen Naturen sein können.
Zeichensatz Ein Zeichensatz definiert die möglichen Zeichen, die ein Barcode kodieren kann. Ein Barcodetyp
kann mehrere Zeichensätze verwenden.
Modulgruppe Eine Modulgruppe ist ein Verbund von Modulen, welche zusammen einen Balken oder eine
Lücke bilden.
Barcode Ein Barcode ist eine Menge von Zeichen die eine Kontextinformation bilden. Er wird durch Modul-
gruppen von Balken und Lücken kodiert.
Verschlüsselung der Symbolzeichen Die nachfolgende Tabelle zeigt die Zeichensätze A, B und C, welche
für die Verschlüsselung der Ziffern im EAN Code verwendet werden.
Tabelle 1: EAN Zeichensätze in Modulbreiten
Ziffer Zeichensatz A Zeichensatz B Zeichensatz C
L B L B L B L B B L B L
0 3 2 1 1 1 1 2 3 3 2 1 1
1 2 2 2 1 1 2 2 2 2 2 2 1
2 2 1 2 2 2 2 1 2 2 1 2 2
3 1 4 1 1 1 1 4 1 1 4 1 1
4 1 1 3 2 2 3 1 1 1 1 3 2
5 1 2 3 1 1 3 2 1 1 2 3 1
6 1 1 1 4 4 1 1 1 1 1 1 4
7 1 3 1 2 2 1 3 1 1 3 1 2
8 1 2 1 3 3 1 2 1 1 2 1 3
9 3 1 1 2 2 1 1 3 3 1 1 2
Die Zeichensätze beschreiben den Aufbau der Ziffern 0 – 9, indem die Anzahl Module für Lücken (L) und
Balken (B) definiert werden. Die Ziffer 0 (null) beispielsweise, wird im Zeichensatz A durch 3 Module des
Typs Lücke, 2 Module des Typs Balken und je einem Modul Lücke und Balken kodiert. Diese Folge erzeugt
eine eindeutig identifizierbare Modulgruppe für die Ziffer 0 (null). Eine Lücke kann als Folge binärer ’False’
(0), ein Balken als Folge binärer ’True’ (1) interpretiert werden.
Der Zeichensatz B besteht aus einem gespiegelten Zeichensatz A. Der Zeichensatz C besteht aus einem Abbild
des Zeichensatzes A, in welchem die Lücken und Balken invertiert werden. Die besagte Ziffer 0 (null) wird im
Zeichensatz A als binäres 0001101 kodiert. Der Zeichensatz C beschreibt die Ziffer 0 (null) mit 1110010
(Zeichensatz A invertiert). Tabelle 2 zeigt die Zeichensätze in binärer Form.
(a) Beispiel und Direktver-
gleich für die Ziffer 0, im
Zeichensatz A, B und C
Abbildung 10: Visualisierung der Ziffer 0 in den verschiedenen Zeichensätze, Zeichensatz A (oben), Zeichen-
satz B (mitte) und Zeichensatz C (unten).
ABCinfo22
Tabelle 2: EAN Zeichensätze in binärer Form
Ziffer Zeichensatz A Zeichensatz B Zeichensatz C
0 0001101 0100111 1110010
1 0011001 0110011 1100110
2 0010011 0011011 1101100
3 0111101 0100001 1000010
4 0100011 0011101 1011100
5 0110001 0111001 1001110
6 0101111 0000101 1010000
7 0111011 0010001 1000100
8 0110111 0001001 1001000
9 0001011 0010111 1110100
Verschlüsselung der Hilfszeichen Jeder Barcode hat gewisse Hilfszeichen, beim EAN handelt es sich dabei
um ein Start- und Endzeichen, sowie um ein Trennzeichen, welches die linke und die rechte Barcodeseite trennt.
Tabelle 3: Die EAN Hilfszeichen
Hilfszeichen Anzahl Module Elementbreite Binär
L B L B L
Startzeichen 3 1 1 1 101
Trennzeichen 5 1 1 1 1 1 01010
Endzeichen 3 1 1 1 101
Paritätswechsel Anhand der Parität wird die Leserichtung eines Barcodes definiert. Die folgende Tabelle
wird bei der Kodierung, resp. Dekodierung eines Barcodes benötigt und kommt im Folgenden zum Einsatz.
Tabelle 4: EAN Paritätstabelle
führende Ziffer Position Symbolzeichen
1 2 3 4 5 6
0 A A A A A A
1 A A B A B B
2 A A B B A B
3 A A B B B A
4 A B A A B B
5 A B B A A B
6 A B B B A A
7 A B A B A B
8 A B A B B A
9 A B B A A A
Ländercodes Ein mit einer EAN identifiziertes Produkt trägt den Ländercode des Herstellerlandes, welcher
aus drei Ziffern besteht und an den Postionen 1, 2 und 3 abgespeichert wird.
Die Webadresse zur vollständigen GS1 Ländercode Liste ist unter [8] vermerkt.
ABCinfo23
Tabelle 5: EAN Ländercode
300 - 379 Frankreich
400 - 440 Deutschland
760 - 769 Schweiz
800 - 839 Italien
900 - 919 Österreich
Tabelle 6: Zusammenfassung zum Aufbau des EAN13 Barcodes
Format des EAN13 Barcodes
Bezeichnung Ländercode Hersteller Artikelnummer Prüfziffer
Position 0 1 2 3 4 5 6 7 8 9 10 11 12
Zeichensatz A oder B C
EAN Kodierung Zur Veranschaulichung des folgenden Sachverhaltes, wird der Barcode mit der Kontextin-
formation 1234567890128 betrachtet. Um den Barcode in einem ersten Schritt zu analysieren, wird seine
Kontextinformation in zwei Sechsergruppen und eine Einergruppe zerlegt. Es entstehen dabei die folgenden
Gruppen:
1 + 234567 + 890128
Zunächst wird die zweite Sechsergruppe 890128 betrachtet. Sie bildet den rechten Teil eines Barcodes. Diese
Seite wird stets mit dem Zeichensatz C aus der Tabelle 1 kodiert. Um den Aufbau der ersten Ziffer 8 dieser
Gruppe zu verstehen, wird die besagte Tabelle konsultiert. Sie definiert den Aufbau der Ziffer 8 mit L=1, B=2,
L=1, B=3. Die Ziffer 8 wird also durch ein Modul Lücke, zwei Module Balken, ein Modul Lücke und drei
Module Balken kodiert. Die Summe der beiden Lücken und Balken muss eine Modulanzahl von 7 aufweisen
um komplett zu sein.
Die erste Sechsergruppe 234567 wird entweder mit dem Zeichensatz A oder dem Zeichensatz B kodiert und
bildet den linken Teil des Barcodes. Grund für die unterschiedliche Nutzung von Zeichensätzen ist die spätere
Berechnung der Einergruppe 1, welche die Paritäten des linken Teils beschreibt.
Durch diese Paritätsziffer am Anfang des Barcodes wird in Kombination mit der Tabelle 4 die Benutzung des
jeweiligen Zeichensatzes A oder B für die Kodierung der entsprechenden Position bestimmt. Die Paritätsziffer
1 beschreibt die Nutzung der folgenden Datensatzvorschrift: AABABB. Die erste Ziffer der ersten Sechsergrup-
pe, wird somit durch den Zeichensatz A kodiert, die zweite Ziffer ebenfalls. Die dritte Ziffer wird durch den
Zeichensatz B etc. beschrieben. Bei der Dekodierung eines Barcodes, wird die Einergruppe vorerst ignoriert. Es
werden nur die beiden Sechsergruppen dekodiert. Anhand der Paritäten des linken Teils (erste Sechsergruppe),
kann die Paritätsziffer errechnet werden. Ein Barcode kodiert also nicht 13 Zeichen, sondern lediglich 12. Die
erste Ziffer wird aus den ersten 6 Zeichen berechnet. Dies ermöglicht zugleich die Ermittlung der Leserichtung
anhand der Parität.
UPC Der UPC Barcode ist mit dem EAN Barcode Aufbau identisch. Er kann jedoch nur 12 zeichen kodieren.
Wird dem UPC Barcode eine Null vorangestellt ist er kodierungstechnisch kompatibel mit dem EAN13 Barcode,
die Kontextinformation ist aber nicht offiziell registriert (Instore Barcode). UPC Barcodes sind hauptsächlich in
den USA und in Kanada verbreitet.
Code39 Code39 ist ein alphanumerischer Barcode mit folgendem Zeichenvorrat:
A .. Z, 0 .. 9, $, %, /, +, ., -
Er ist unter ISO/IEC 16388 spezifiziert [25]. Das Start- und Endzeichen wird mit einem *-Zeichen identifiziert.
Code39 besitzt eine Erweiterung mit welcher es möglich ist, beinahe den gesamten ASCII Zeichensatz darzu-
ABCinfo24
stellen. Da ein ASCII Zeichen aus zwei Zeichen des Barcodes besteht, ergibt sich dabei jedoch eine geringe
Informationsdichte.
Aufgrund des einfachen Aufbaus und der hohen Drucktoleranz geniesst Code39, trotz seines Status als ältester
alphanumerischer Barcode, immernoch eine hohe Bedeutung.
Zweidimensionale Barcodes Die Überschrift dieses Abschnittes ist nur bedingt korrekt. Zweidimensionale
Barcodes bestehen nur selten wirklich aus Bars. Die meisten 2D Codes basieren auf dem Prinzip der Matrixco-
dierung.
Stapelcode Der Stapelcode ist eine Übergangslösung zwischen linearen Barcodes und 2D Matrixcodes. Der
Vorteil besteht aus den Vorzügen der zweidimensionalen Kodierung und der gleichzeitigen Verwendung von
alten Geräten wie dem Handscanner oder CCD Lesegeräten.
PDF417 PDF ist die Abkürzung für ’Portable Data File’. Das Einsatzgebiet bezieht sich hauptsächlich auf
die Logistik. Dieser Code eignet sich ideal dazu Zusatzinformationen anzubringen, wie beispiesweise Zustell-
adresse, Versand- und sonstige Informationen. PDF417 teilt sich für jede Zeile dasselbe Start- und Endzeichen.
Damit sind alle alphanumerischen Zeichen kodierbar.
Matrixcode Mit der Verwendung von Matrixcodes ist es möglich ein vielfaches an Informationsdichte zu
erhalten. Da das Gesamtbild des Codes benötigt wird, sind Matrixcodes nur mit CCD-Scannern und –Kameras
dekodierbar. Aufgrund der geringen optischen Auflösung und der mechanischen Strahlablenkung, scheidet die
Verwendung von Lasergeräten aus. Zudem reicht die Entnahme einer einzelnen Scanline zur anschliessenden
Auswertung nicht mehr aus.
QR Code Der zweidimensionaler QR Code wurde in Japan von der Firma ’Denso’ im Jahre 1994 entwickelt.
Er wurde ursprünglich in der Automobilindustrie eingesetzt, ist aber heute sehr weit verbreitet. Mittlerweilen hat
er den Sprung nach Europa geschafft, wo Firmen wie ’kaywa’ [10] in Kooperation mit ’Swisscom Mobile’ ihre
Dienstleistungen mit Hilfe des QR Codes anbieten. QR steht für Quick Response. Über drei Eckmarkierungen
wird das Lesegerät kalibiert. Die folgende Auflistung zeigt die hohe Informationsdichte von QR Codes.
• binäre Daten: 23624 Bits
• numerische Daten: 7089 numerische Zeichen
• alphanumerische Daten: 4296 alphanumerische Zeichen
DataMatrix Der DataMatrix Code wird hauptsächlich in der Elektronik- und Autoindustrie eingesetzt. Er ist
mit allen gängigen Drucktechniken, insbesonders mit der Direktmarkierung 3 , aufzubringen. Zur Orientierung
beim Lesen der vier Sektoren dieses Codetyps befindet sich am linken, sowie am unteren Rand je ein Balken.
Aztec Code Dieser Code ist zweidimensional und nicht standardisiert. Er wird von der Deutschen Bahn sowie
der SBB für die Online Bahntickets eingesetzt. Mit dem Aztec Code können bis zu 3750 numerische, oder 3000
alphanumerische Zeichen kodiert werden. Dabei beherrscht er den kompletten ASCII-Zeichensatz. Abhängig
von der Modulgrösse, liegt die Fehlerkorrektur zwischen 25% und 40%. [24] Das Lesegerät orientiert sich am
Quadrat im Zentrum.
3 Mit Direktmarkierung ist gemeint, dass Produkte direkt mittels Lasergravur oder Nadelgravur, wie auch mittels Prägung markiert
werden, das heisst es wird keine Etikette verwendet und der Code ist fix mit der Objekt dauerhaft verbunden.
ABCinfo25
(a) QR Code (b) Cheeseburger in Japan
Abbildung 11: Abbildung 11(a) zeigt einen QR Code mit der Kontextinformation ’ABCinfo’ , Abbildung 11(b)
zeigt eine Fastfood Verpackung.
(a) Aztec
Code
Abbildung 12: Abbildung 12(a) zeigt einen Aztec Code mit der Kontextinformation ’ABCinfo’.
MaxiCode Firmen wie UPS verwenden den MaxiCode zum Einsatz in ihrer Logistik. Dieser Code ist rasch
dekodierbar und weist eine sechseckige Form auf. Das Lesegerät kalibriert sich an den Zentrumsmarkierungen.
ShotCode Der ShotCode [23] ist ein von der Cambridge University im Jahr 1999 entwickelter, kreisförmiger
Barcode. Er wird von einer Kamera eines mobilen Telefons oder einer Webcam erkannt und ausgewertet. Der
ShotCode besteht aus einem zentralen Punkt, welcher von mehreren Ringsegmenten umgeben ist. Die Erken-
nungssoftware misst den Abstand und den Winkel zwischen den Blöcken und zum zentralen Punkt und erstellt
so ein Bitmuster. Hierfür ist die Kamera eines Mobiltelefons oder eine Webcam ausreichend. Das Bitmuster
wird anschliessend an einen Server übertragen, welcher die passende Kontextinformation zurückliefert. Meis-
tens handelt es sich hierbei um Webadressen.
Barcode Lesegeräte
Was für die Vielfalt an Barcodetypen und Anwendungen im Bereich der Barcodelösungen zutrifft, gilt gleicher-
massen auch für den Bereich der Dekodierung, der mit einer grossen Vielfalt an Lesegeräten ausgestattet ist.
Es wird zwischen drei Gruppen unterschieden, auf welche nachfolgend näher eingegangen wird. Dabei wird
jeweils lediglich die technische Funktionsweise erläutert und auf Fakten wie Preis und Schnelligkeit verzichtet.
Lesestift Eine Leuchtdiode (LED) im Wellenlängenbereich von Rot und eine Leuchtdiode im Infrarotbereich
bestrahlen die zu lesende Oberfläche. Das reflektierte Licht wird durch eine Linse an den Fototransistor geleitet.
Von dort übernimmt die Dekodierhardware die Daten.
ABCinfo26
CCD Scanner Ein CCD Scanner arbeitet mit einer oder mehreren Leuchtdioden, welche den Barcode mit
Licht bestrahlen. Eine Abbildung des Barcodes wird anschliessend an eine Reihe von Fotozellen übertragen.
Anstatt die Balken und Lücken in Folge zu interpretieren, erstellt der Scanner ein binäres Muster aller Fotozellen
die Informationen über Helligkeitswerte enthalten.
Laserscanner Der Laserscanner projiziert einen Laserstrahl über Polygonspiegel direkt auf den Barcode. Das
vom Barcode reflektierte Licht wird über Spiegel und Linsen an einen Fototransistor geleitet. Theoretisch ist es
möglich Barcodes mit einer Raumbewegung von 2.5 m s zu dekodieren. Daher eignet sich der Laserscanner sehr
gut für Warenhäuser oder Gepäckabfertigungen.
Probleme
Nicht nur die Architektur von beispielsweise CMOS Sensoren4 lassen ein Bild bei der Transformation von der
Objekt- in die Bildebene an Qualität verlieren. Oft ist es der Fall, dass bereits das Objektbild eine schlechte Güte
besitzt. Der Ursprung dafür liegt entweder im schlechten Aufdruck des Barcodes auf seinen Artikel, oder darin,
dass der Barcode aufgrund der Verpackungseigenschaft zerknittert oder verzerrt ist. Mobilgerätekameras haben
zwar einen grossen technischen Fortschritt hinter sich, noch ist das ’Snap-and-Go’, wie man es von Spiegelre-
flexkameras her kennt, jedoch nicht gegeben. Eine ruhige Hand des Anwenders ist immernoch gefragt um eine
optimale Bildqualität zu erhalten. Die folgenden Abbildungen visualisieren das angesprochene Güteproblem.
(a) Fehlende Pixel, falsche Breiten der (b) Zerstörte und/oder fehlende Informati- (c) Schlechte Druckqualität
Balken und Lücken on durch Blitzlicht oder Reflektionen.
Abbildung 13: In den Bilder 13(a), 13(b) und 13(c) werden einige Problematiken bezüglich des Eingangsbildes
visualisiert.
Die linke Abbildung zeigt einen Barcode mit ungenauen Modulwerten. Balken und Lücken, welche laut Spezi-
fikation dieselbe Breite haben müssten, weisen diese Eigenschaft nicht auf. Eine schlechte Druckqualität oder
die perspektivische Verzerrung bei der Bildaufnahme sind die Ursache dieses Problems. Oft bringen Flaschen
und Verpackungen aus Plastik und Papier diese Eigenschaften mit sich.
Die mittlere Abbildung zeigt einen Barcode mit zerstörten Bildinformationen durch Blitzlicht und Reflektionen.
Schlimmstenfalls sind nicht mehr alle benötigten Informationen zur Dekodierung vorhanden und das Bild wird
unbrauchbar. Die Ausleuchtung des Barcodes soll deshalb ohne Blitz nur durch die Nutzung des Umgebungs-
lichtes erfolgen.
Die rechte Abbildung zeigt ein Beispiel eines mangelhaften Druckbildes. Die dabei ins Papier diffundierte Farbe
birgt Probleme bei der späteren Binarisierung eines Bildes. Dasselbe Problem tritt auf, wenn sich Farbe auf einer
Oberfläche (meist Plastik) zusammenzieht und sich Lücken innerhalb von Balken bilden.
Umgebungselemente auf dem Bild, wie beispielsweise Inhaltsstoffangaben, können die Algorithmik zur Deko-
dierung ebenfalls beeinträchtigen, da diese oft dieselbe Charakteristik wie der Barcode selbst haben.
4 Complementary Metal Oxide Semiconductor (CMOS, dt. komplementärer Metall-Oxid-Halbleiter) ist eine Logikfamilie aus der Elek-
tronik. Ein Active Pixel Sensor (APS, deutsch: aktiver Pixelsensor) ist ein Halbleiterdetektor zur Lichtmessung, der in CMOS-Technologie
gefertigt ist und deshalb oft als CMOS-Sensor bezeichnet wird.
ABCinfo27
In den folgenden Konzepten wird aufgezeigt, wie und womit diese Probleme vermindert oder gelöst werden
können. Dies gelingt nicht immer und lässt die Erkenntnis zu, dass nicht jedes Bild, welches vom Auge als
qualitativ ausreichend bewertet wird, auch tatsächlich verwendet werden kann.
ABCinfo28
2.2.2 Computer Vision Konzepte
Punktoperationen
Unter dem Begriff der Punktoperatoren versteht man Verfahren zur Änderungen von Pixelwerten im Allgemei-
nen, dies kann zum Beispiel eine Kontrastverstärkung, Gamma- oder Helligkeitskorrektur sein. Sie verdanken
ihren Namen der Tatsache, dass bei allen Verfahren jedes Pixel eines Bildes nur in Abhängigkeit von seinem
Farb- oder Grauwert und seiner Position im Bild ein neuer Farb- oder Grauwert berechnet wird, ohne dass eine
Nachbarschaft, seine Umgebung oder gar das Gesammtbild betrachtet wird. Die Bildgrösse und die Position des
Pixels ändert sich nicht. Punktoperationen stellen meistens den ersten Schritt der Vorverarbeitung dar, um den
Bildkontrast zu verstärken oder Belichtungsfehler bei der Bildaufnahme auszugleichen.
Grauwertkonvertierung Grauwertbilder, auch als Intensitätsbilder bezeichnet, verfügen über einen Hellig-
keitskanal, welcher die Helligkeit, die Intensität oder die Dichte des Bildes beschreibt. Die Darstellung erfolgt
im Format 0 · · · (2k − 1). Ein Grautwertbild enthält also nur positive Werte. Der Wert 0 (null) beschreibt die
minimale Helligkeit: schwarz. Bei einer Auflösung von 8bit/Pixel, beschreibt der Wert 255 die maximale Hel-
ligkeit: weiss.
Histogrammanalyse In der digitalen Bildverarbeitung beschreibt ein Histogramm die statistische Häufigkeit
der Grauwerte, beziehungsweise der Farbwerte in einem Bild. Das Histogramm eines Bildes erlaubt eine Aus-
sage über die vorkommenden Grau- oder Farbwerte und über den Kontrastumfang und die Helligkeit des Bil-
des. In einem Farbbild kann ein Histogramm entweder über alle drei Farbkanäle oder für jeden Kanal einzeln
erstellt werden. Die Bildverarbeitung arbeitet meist mit Grauwertbildern und arbeitet darum nur mit einem
Histogramm.
Schwellwertbildung Der Schwellwert, auch häufig als Threshold (engl.) anzutreffen, beschreibt eine defi-
nierte Grenze zur Verarbeitung eines Signals. Bei Unterschreitung des Schwellwertes, wird das Signal in einen
neuen Ausgabewert umgewandelt. Meist ist dieser Wert 0 (null). Bei Überschreitung des Wertes, wird das Si-
gnal auf einen konstanten Wert gehoben. Dieser ist meist 1 um nur Werte von 0 oder 1 zu erhalten, oder bei
Grauwertbildern (8bit) 0 oder 255. Diese Trennung der Signale resultiert in einer Binarisierung der Werte. Es
existieren nur noch zwei unterschiedliche Zustände für einen grossen Wertebereich. Diese Eigenschaft kann
man sich zur Trennung eines Barcodes vom Hintergrund mittels einer Schwellwertoperation zu nutzen machen.
Die Grundlagen hierzu sind die Helligkeitswerte der einzelnen Bildpunkte. Bei ungleichmässiger Ausleuchtung
eines Bildes, kann es sinnvoll sein, den Schwellwert dynamisch anzupassen. Die Helligkeits- und Kontrast-
verhältnisse der Umgebung sind dabei massgeblich.
(
1 falls pixelin ≥ Schwellwert
pixelout = (1)
0 falls pixelin < Schwellwert
ABCinfo29
Lokale Operationen
Lokale Operatoren sind Verfahren, welche Pixelwerte abhängig von ihrer Umgebung oder des ganzen Bildes,
verändern. Diese Verfahren werden in der Regel mittels Filter auf ein Bild angewandt.
Filter Operationen, welche ein Eingangsbild mit Hilfe einer mathematischen Operation in ein Ausgangsbild
überführen, werden als Filter bezeichnet. Die folgenden Filter beziehen sich im Wesentlichen auf Rasterbilder.
Das Ziel einer Filterung ist die Verbesserung eines vorhandenen Musters. Dies kann eine Reduktion störender
Bildanteile, die Hervorhebung von informativen Bildanteilen oder die Restauration eines idealen Musters sein.
Die Bildgeometrie ändert sich bei der Anwendung eines Filters nicht, das heisst, die Koordinaten bleiben erhal-
ten.
Filtermatrix, -maske Filter bestehen in der Regel, aber nicht zwingenderweise, aus einer m · n Ma-
trix. Jeder Eintrag dieser Matrix enthält einen Filterkoeffizienten, welcher das Gewicht beschreibt mit dem die
Nachbarpixel des zu transformierenden Pixels multipliziert werden. Ein Pixel g(x, y) im Ausgangsbild besteht
demnach aus dem Wert, welcher sich durch das Gewichten, Summieren und Dividieren durch die Gesamtsum-
me der Filtergewichte seines Ursprungswertes mit den entsprechenden Nachbarspixeln ergibt. Die Filtermatrix
muss zur Berechnung nicht zwingend mit ihrem Zentrum über das Eingangspixel gelegt werden. Dieser soge-
nannte ’Hotspot’ kann innerhalb der Matrix frei gewählt werden. Damit wird erreicht, dass nicht alle umliegen-
den Pixel in die Berechnung miteinbezogen werden. Die Filtermatrix kann sowohl positive, wie auch negative
Werte beinhalten.
Anwendung des Filters
X
pixelout ← pixelin (u + i, v + j) · Filter(i, j) (2)
(i,j)R
[27], [36]
Kantenhervorhebung
Laplace-Filter Zur Hervorhebung der Kanten in einem Bild kann ein sogenannter Laplace Filter einge-
setzt werden. Dieser schärft das Bild mit einer speziellen Filtermatrix. Dabei kann beispielsweise eine 3 · 3
Matrix eingesetzt werden. Wird nur eine Bildzeile gefiltert, bietet sich die Verwendung eines Filtervektors 4 an.
1 1 1
1/1 ∗ 1 −4 1 (3)
1 1 1
1/1 ∗ −1 2 −1 (4)
Canny-Algorithmus Dieser Algorithmus wurde von John Canny entwickelt und beschreibt ein Verfahren
zur Kantendetektion in Grauwertbildern. Der Canny-Algorithmus besteht aus diversen Faltungsoperationen und
liefert ein Ausgangsbild der Kanten des Eingangsbildes. Dabei werden die Kanten hell, der Hintergrund dunkel
dargestellt. Das Bild wird zuerst mit einem Gauss Filter geglättet und anschliessend mit einem Sobeloperator
gefaltet. Das daraus resultierende Ausgangsbild enthält die horizontalen und vertikalen Gradienten (Kanten) des
Eingangsbildes.
ABCinfoSie können auch lesen
