Advanced Barcode Information

Fachhochschule Nordwestschweiz (FHNW) Abteilung fur¨ 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 handelsublichen¨ Barcodes, sowie den Weg zur Entscheidungsfindung der dafur¨ angebrachten Methoden zur effizienten Erkennung dieser Strichcodes mittels Auswertung von Pixeldaten uber¨ Computer Vision. Desweiteren wurde als Grundlage die zu verwendende Soft- und Hardware analysiert und zur Erklarung¨ und Erlauterung¨ aufkommender Sachverhalte herangezogen. Die gewonnenen Einsichten und ausprogrammierten Algorithmiken wurden anschliessend in eine modulare und erweiterbare Applikation eingebettet, welche das Abfragen von definierten Datenquellen uber¨ verschiedene Transportprotokolle, Caching von Daten und weiteren Features ermoglicht.¨ Diese Anwendung wurde zuerst fur¨ Nokia Smartphones der Serie 60 entwickelt und anschliessend aus Performancegrunden¨ auf Desktop Sys- teme plattformunabhangig¨ 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 fur¨ 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 Praprozess¨ ...... 53 3.7.2 Prozess ...... 56 3.7.3 Validierung ...... 59 3.8 Desktop Version – Implementation ...... 61 3.8.1 Graﬁscher 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 fur¨ 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 fur¨ 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 mochten¨ wir eben diesem Auftraggeber herzlich dafur¨ danken. Ebenso sprechen wir unserem Ansprechpartner, Oliver Ruf, fur¨ seine stetige Bereitschaft, uns bei Problemen zur Seite zu stehen, unseren Dank aus. Desweiteren gebuhrt¨ unserem betreuenden Dozenten und Leiter des IMVS, Prof. Dr. C. Stamm, Dank fur¨ sein Engagement und seine Unterstutzung.¨ Auch unseren Kommilitonen danken wir fur¨ die anregenden Gesprache¨ und Meinungen.

ABCinfo 6

1 Einleitung 1.1 Auftrag Zur Klarung¨ des Auftrages wird an dieser Stelle die Originalpassage aus dem Antrag fur¨ Projekt- und Diplom- arbeiten herangezogen: ’Heutzutage haben fast alle der gangigen¨ Mobiltelefone eine integrierte Kamera, welche hoch- auﬂosende¨ Bilder liefert. Die Projektarbeit umfasst die Entwicklung einer Applikation, welche mit dieser Kamera Barcodes als Bilder erfasst und mittels Computer Vision (CV) verarbeitet. Aufgrund der nun erhaltenen Identiﬁkation holt die Applikation zusatzliche¨ Informationen zu dem Produkt/Artikel/etc. aus dem Internet und stellt diese dem Anwender zur Verfugung.¨ Die zu verwendende Technologie ist die Python Programmiersprache, welche seit dem Januar 2006 von Nokia fur¨ die S60 Serie als OpenSource Projekt [14] veroffentlich¨ 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 fur¨ das Projekt erstreckt sich uber¨ 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 uber¨ die herrschenden Marktverhaltnisse¨ zu erlangen, werden hierzu die folgenden Projekte kurz erlautert:¨ • 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 dafur¨ ware¨ eine weitere Einarbeitung in die C-API und das proprietare¨ C-Umfeld von Symbian gewesen. Dieses Konzept wird zu einem spateren¨ Zeitpunkt in diesem Dokument aufgearbeitet und erlautert.¨

BaToo Das Barcode Recognition Toolkit [21] wurde an der ETH Zurich¨ 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 verfugbaren¨ Codes und der Dokumentation dazu ein erstes Bild uber¨ allfallige¨ Konzepte gemacht werden. Ausserdem hielten wir Kontakt zum Entwickler von BaToo, Robert Adelmann, der uns mit seiner Meinung nutzliche¨ Tipps geben konnte. Zum konkreten Inhalt und dessen Nutzen wird ebenfalls spater¨ in diesem Dokument eingegangen.

CodeCheck Zu Roman Bleichenbacher, Initiant und Entwickler von CodeCheck [22], wurde zu Beginn ein intensiver Kon- takt gepﬂegt. Sein Projekt hat nichts mit der Erkennung von Barcodes zu tun, vielmehr steht CodeCheck fur¨ 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 Verfugung¨ stellen zu konnen.¨ Nach einem Treffen und einer Projektvorstellung bei Roman Bleichenbacher, steuerte man eine gemeinsame Zusammenarbeit mit CodeCheck an. Die Fulle¨ 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 Komplexitat¨ mit sich bringt, erfolgreich durch- zufuhren,¨ 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 nachste¨ Phase beginnen kann. Im Folgenden werden diese Etappen beschrieben und reﬂektiert. 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 notigen¨ Werkzeugen und derer Handhabung vertraut zu machen. Dazu gehoren¨ das Installie- ren von Entwicklungsumgebungen, das Durcharbeiten von Tutorials, das Schreiben von Testprogrammen sowie das Lesen der Theorie, um sich uber¨ verschiedene Strategien und Konzepte zu informieren. Zusatzlich¨ wird an dieser Stelle auch daruber¨ diskutiert und beschlossen, wie das Projekt angegangen und verwirklicht werden soll. Die in dieser Phase gewonnenen Erkenntnisse werden im zweiten Abschnitt mit der Konzeptevaluierung naher¨ besprochen und erlautert.¨

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 Ausfuhrung¨ dieser ersten Etappe bildet das Fundament fur¨ einen im darauffolgenden Schritt efﬁzient ausgearbeiteten Entwurf. Insgesamt wurden fur¨ die Analysephase 20 Tage ausgelegt. Nach Abschluss dieses Schrittes musste man erkennen, dass eine Woche mehr Zeit fur¨ die Analyse angebracht gewesen ware.¨ 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 Gerate¨ erst bei derem Praxiseinsatz erlernt werden konnen.¨ Ansonsten konnte dieser Schritt erfolgreich und termingerecht abgeschlossen werden.

ABCinfo 9

1.3.2 Entwurf Die zweite Phase der Projektplanung besteht darin, die Resultate der ersten Phase zu nutzen um sie bedurfnisgerecht¨ in einen konkreten Entwurf der kompletten Architektur umzusetzen. Hierbei werden zuerst die verschiedenen Konzepte aus dem Analyseschritt herangezogen und weiter ausgearbeitet. Dazu werden unter anderem Testmodule entwickelt, welche den praktischen Bezug zur Analyse herstellen und die Entscheidung fur¨ die richtige Strategie unterstutzen.¨ Nachdem dieser, sich wiederholende, Schritt abgeschlossen wurde und die adaquatesten¨ Methoden zur Umsetzung der Algorithmik und der Applikation ausgewahlt¨ 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 erlautert¨ 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, deﬁnitiv 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. Zusatzlich¨ 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 implementieren. Die Entwurfsphase schlagt¨ in der Planung mit 41 Tagen zu Buche. Aufgrund der Erkenntnis, dass das zyklische evaluieren der Konzepte bis zur Entscheidungsﬁndung Zeit beanspruchen wurde,¨ erliess man fur¨ diesen Schritt eine langere¨ Frist. Diese Planungsentscheidung stellte sich als angemessen heraus. Am Stichtag standen die Konzepte und die Architektur wie geplant und es konnte mit der nachsten¨ Phase begonnen werden.

ABCinfo 10

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 Entwurfe¨ und Strategien. Die dabei entstehenden Probleme, welche in der Konzeption nicht vorhergesehen werden konnten, mussen¨ an dieser Stelle behoben werden. Dazu ist es unter Umstanden¨ notwendig, Konzepte zu erweitern, zu erganzen¨ oder gar ganzlich¨ zu ersetzen. Die praktische Implementierung von theoretischen Konzepten lasst¨ diesem Schritt seine zyklische Eigenschaft zukommen. Verschiedene Module und Programmteile mussen¨ mehrfach uberarbeitet¨ werden bis das gewunschte¨ Resultat erreicht wird.

Dauer Start Entwicklung 55 Tage Di, 16.1.07 Uberarbeiten¨ der Testmodule 13 Tage Di, 16.1.07 Erganzen¨ der Module (zyklisch) 15 Tage Fr, 2.2.07 Model-View-Controller 13 Tage Fr, 23.2.07 Uberarbeiten¨ MVC (zyklisch) 14 Tage Mi, 14.3.07 (a)

(b)

Abbildung 3: Gantt-Diagramm Entwicklungsphase

Um die Anwendungseigenschaften gemass¨ Auftrag zu entwickeln und somit den Mindestanforderungen dieses 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 lauffahig¨ zu gestalten.

ABCinfo 11

1.3.4 Optimierung/Testen Die letzte Phase beschaftigt¨ sich mit dem Testen und der Optimierung der Applikation. Dabei werden in ers- ter Linie alle moglichen¨ Benutzereingaben gepruft¨ und abgefangen, sowie alle Fehler- und Zustandsszenarios durchgespielt. Ebenso werden moglichst¨ viele Referenzvorlagen fur¨ 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 fur¨ Schritt verbessert. Eine Einschrankung¨ 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) Bugﬁxing (zyklisch) 5 Tage Di, 29.5.07 (a)

(b)

Abbildung 4: Gantt-Diagramm Optimierungs- und Testphase

Das Bewusstsein daruber,¨ dass dieser Schritt nicht unterschatzt¨ werden darf, liess ihm 46 Tage zur Vervollstandigung¨ 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 Pﬂichtenheft erscheinen, einzubauen. Diese erhohen¨ die Bedienerfreundlichkeit und verbessern gleichzeitig die Performance. Neue Ideen traten zum Vorschein, welche schliesslich nur aufgrund Zeitmangels nicht vollstandig¨ 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.

ABCinfo 12

1.3.5 Dokumentation Um die geleistete Arbeit einem Betrachter auf schlussige¨ Weise darlegen zu konnen,¨ ist eine verstandliche¨ Do- kumentation die wichtigste Arbeit uberhaupt.¨ 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 gelost¨ wurden. Ebenso muss die Planung ersichtlich sein und reﬂektiert werden, was im bisherigen Text das Hauptthema war.

Dauer Start Dokumentation 27 Tage Di, 5.6.07 Arbeitsbucheintrage¨ verarbeiten 2 Tage Di, 5.6.07 Konzepterkenntnisse verarbeiten 2 Tage Do, 7.6.07 Zusammentragen 3 Tage Mo, 11.6.07 Erganzen¨ / Korrigieren (zyklisch) 14 Tage Do, 14.6.07 Latex 2 Tage Di, 3.7.07 Prasentation¨ vorbereiten 2 Tage Do, 5.7.07 (a)

(b)

Abbildung 5: Gantt-Diagramm Dokumentationsphase

Ruckblickend¨ kann man die Projektplanung als erfolgreich betrachten. Es wurden alle Schritte so detailiert geplant, wie es im Vorfeld machbar war. Der Zeitplan konnte fur¨ fast alle Termine eingehalten werden und barg keine Uberraschungen¨ negativer Art. Ausgenommen ist die Analyse, welcher man 1-2 Wochen mehr Zeit hatte¨ einraumen¨ konnen.¨ Dieser Punkt hat uns gezeigt, dass ein Projekt dieser Dauer und in diesem Umfang mehr Forschung vorweg benotigt¨ hatte.¨ Diese Erkenntnis und das Wissen uber¨ die Wichtigkeit guter Planung werden uns in weiteren Projekten mit Sicherheit erfolgreich begleiten.

ABCinfo 13

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 besseren Verstandnis¨ wird Python an dieser Stelle vorgestellt. Python ist eine Programmiersprache, welche in den 90er Jahren in Amsterdam entwickelt wurde. Sie unterstutzt¨ objektorientierte, aspektorientierte und funktionale Programmierung. Es existiert eine umfangreiche Standard- bibliothek mit nutzlichen¨ Modulen fur¨ viele verschiedene Arten von Anwendungen. Python ist sehr eifach und ubersichtlich¨ gehalten. Die Lesbarkeit von Code steht im Vordergrund und erlaubt es Programmierern, sich ohne grossen Aufwand in eine fremde Applikation einzuarbeiten. Dies fordert¨ die Erweiterbarkeit auch in einem teamorientierten Sinne. Die automatische Speicherbereinigung von Python halt¨ das Speicherkontingent stets auf optimalem Niveau. Datentypen werden nicht, wie etwa in C++, statisch typgepruft¨ (d.h. vor der Programmausfuhrung),¨ 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 Einrucken¨ von Codeblocken¨ dient als Strukturierungselement und tragt¨ 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 return a+b ; 3 } 4

Listing 2: Codestrukturierung mit Python def add ( a , b ) : 1 return a+b 2 Ubrigens:¨ 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 ofﬁzielle BitTorrent-Client machen von Python Gebrauch.

Python vs. Java vs. C++ So bestechend die Einfachheit von Python ist, so kritisch muss die Performance gegenuber¨ anderen Program- miersprachen hinterfragt werden. Nachfolgend werden verschiedene Aspekte von Python mit ihrem Aquivalent¨ in Java und C++ verglichen.

Komplexitat¨ Wenn es darum geht die Komplexitat¨ von geschriebenem Code zu vergleichen, ist Python der eindeutige Gewinner. Python-Code ist kurzer,¨ intuitiver und schneller programmiert als Java oder gar C++ Code. Testprogramme, die fur¨ 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 konnen.¨ In Python ist dies schlichtweg eine leere Datei. In Java und C++ ist es die Klassen- und Main-Instanzierung.

ABCinfo 14

Dabei hat Python seinen Interpreter in einer Zeit von 0.04 Sekunden gestartet. Java benotigt¨ 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 grosseren¨ Applikationen ist diese Zeit eher von geringer Bedeutung. Nachdem der Interpreter resp. die virtuelle Maschine ihren Start vollzogen hat, kann die Objektallokation verglichen werden. Dabei wird eine leere Klasse erzeugt und mehrfach instanziert. Python benotigt¨ fur¨ 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 wahrend¨ der Programmausfuhrung¨ und der hauﬁgen¨ Instanzierung von Klassen demnach Geschwindigkeit einbussen.¨

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 ausgefuhrt¨ werden, zeigt C++ seine innere Performance. Um eine Liste mit 3 Millionen Eintragen¨ zu fullen,¨ benotigt¨ Python 31 Sekunden. C++ erledigt diese Aufgabe in nur 0.19 Sekunden. Ebenso liegt Python weit zuruck¨ 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.

ABCinfo 15

2.1.2 Nokia S60 (Model N93) Die zu verwendende Hardware besteht aus dem Mobiltelefon Nokia N93, welches zur Serie 60 der Nokia Smartphones gehort.¨ Die Software Grundlage bildet das Betriebssystem Symbian. Dieses ist zur Zeit in der Version 9.2 (3rd Edition) erhaltlich¨ und wurde von Nokia fur¨ seine eigenen Gerate¨ entwickelt.

(a) Nokia N93

Abbildung 6: Applikationsplattform - Nokia N93

Eigenschaften Die, fur¨ das Projekt wichtigsten, Eigenschaften des Nokia N93 umfassen: • 3.2 Megapixel CMOS Sensor • Carl-Zeiss Optik mit 3-fach optischem Zoom • Autofokus • WLAN, UMTS8 • 50 MB interner Speicher

CPU 8 Prozessor-Typ: Texas Instruments OMAP 2420 Architektur: ARM-11 (330 MHz) Fur¨ das N93 liefert Texas Instruments den Single-Chip Prozessor OMAP 2420, welcher alle Mobilstandards und eine Vielzahl von Multimedia Anwendungen unterstutzt.¨ Die mit 330 MHz getaktete Zentraleinheit ermoglicht¨ die parallele Verarbeitung von Funktionen. Weitere Features sind der 2D/3D Graﬁkbeschleuniger und die Un- terstutzung¨ aller gangigen¨ Peripheriestandards. Die ARM-11-Architektur beinhaltet eine Floating Point Unit, welche Floating Point Operationen auf Mikro- kontrollerebene realisieren kann. Dies ist keine Selbstverstandlichkeit,¨ da die meisten bisherigen Nokia Mobil- telefone Float-Operationen auf Softwarebasis emulierten.

ABCinfo 16

(a)

Abbildung 7: OMAP High-Performance Prozessor

Nokia S60 Symbian Programmierschnittstelle Die wohl leistungsfahigste¨ Variante um Anwendungen fur¨ ein 3rd Edition Smartphone von Nokia zu schreiben, ist die Nutzung der Nokia C-API unter Verwendung von C++. Leider ist sie nicht die efﬁzienteste und wohl auch die unbequemste (sofern nur High-Level Program- miersprachen betrachtet werden). Mit Hilfe der offentlich¨ zuganglichen¨ und gut dokumentierten C-API ist es moglich¨ fast alle Features des Mobiltelefons zu nutzen. An dieser Stelle mochten¨ wir Robert Adelmann der ETH Zurich¨ 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.’

ABCinfo 17

2.1.3 Python fur¨ S60 Seit dem Januar 2006 existiert das von Nokia ins Leben gerufene OpenSource Projekt Python fur¨ S60 (PyS60). Dem Entwickler steht damit fast die komplette Standardbibliothek von Python zur Verfugung.¨ Auf diese Weise ist es nun auch moglich¨ auf Mobilgeraten¨ sehr produktives Software Development zu betreiben. In kurzer Zeit kann, wie auch mit Python, viel erreicht werden. Desweiteren existieren eine Menge externer Module fur¨ PyS60, wie etwa XML Parser oder Bildverarbeitungsfunktionen. PyS60 selbst kommt mit einigen nutzlichen¨ Modulen fur¨ den Mobilbereich. Fur¨ dieses Projekt besonders interessant ist beispielsweise die Kamera API, die jedoch noch immer keinen Autofokus und bis vor kurzem auch keinen Viewfinder unterstutzt¨ 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 ermoglicht,¨ wurde diese noch nicht in die neuste PyS60 Ver- sion implementiert. Somit bleibt diese Pendenz beim Entwickler, der Funktionen, welche auf die automatische Scharfentiefeneinstellung¨ Einfluss nehmen, in C++ schreiben muss. Die Moglichkeit¨ 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 naher¨ beschrieben. Um einen Eindruck uber¨ die Performance von Python auf dem Mobilgerat¨ zu gewinnen, wurde ein Integer Benchmark auf verschiedenen Plattformen durchgefuhrt.¨ 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 fur¨ Python, welcher die Codeausfuhrung¨ 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 fur¨ Desktopsysteme im guten Mittelfeld. Da der HP Pavilion mit einem Dual-Core Prozessor der zweiten Generation ausgestattet ist, lauft¨ der Test dementsprechend performant. Das erwahnte¨ und getestete Psyco Modul wird zu einem spateren¨ Zeitpunkt naher¨ erlautert.¨ 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 Befurchtung,¨ dass Python, wie es bereits im Vergleich zu anderen Programmiersprachen auf Desktopsystemen der Fall war, die Geschwindigkeit auch auf Mobilgeraten¨ enorm bremsen wurde,¨ scheint sich an diesem Punkt zu bestatigen.¨

ABCinfo 18

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. Fur¨ 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 Mobilgerat¨ kommt dieser Nachteil noch deutlicher zum Vorschein. Mit Rucksichtnahme¨ darauf, dass ein Mobiltelefon nicht mit einem Computer verglichen werden darf, leistet das Nokia N93 beachtliches. Seine Multimediafahigkeiten¨ und die Hardware sind auf dem neusten Stand der Tech- nik. Das Betriebssystem Symbian OS ist vielfaltig,¨ weist allerdings Schwachstellen im Memory Management auf (diverse Komplettabsturze¨ in nativen Applikationen, sowie in Drittanwendungen. Beispielsweise sturtzt¨ die Kameraapplikation nach 25 Aufnahmen ab). Ausserdem wurde die Sicherheitspolitik in der dritten Edition von Symbian dermassen verscharft,¨ dass es als Entwicklerplattform oftmals sehr muhsam¨ zu handhaben ist. Python fur¨ S60 ist in seiner Verwendung sehr bequem. Leider existiert es noch nicht sehr lange (2006), was sich anhand der vielen Fehlern des Interpreters erkennen lasst.¨ Ausserdem sind einige Teile und Module, welche im Projekt benotigt¨ gewesen waren,¨ nicht in PyS60 vorhanden. Wie und welche Werkzeuge und Mittel bei der Umsetzung der Applikation genutzt werden und warum man sich fur¨ oder gegen sie entschieden hat, wird der Abschnitt der Konzeption und des Entwurfes zeigen.

ABCinfo 19

2.2 Methodenanalyse Als nachstes¨ 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 Verstandnis¨ der Dekodie- rung unabdingbar ist. Desweiteren werden Ideen zur Applikationsarchitektur erforscht und ausgewertet. In der Realisierungsphase (Entwurf & Realisierung, siehe Seite 39), werden anschliessend die adaquatesten¨ Konzepte ausgewahlt¨ und fur¨ 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 spater,¨ im Jahr 1973, wurde in den Vereinigten Staaten der UPC Barcode (Universal Product Code) eingefuhrt.¨ Ein Jahr spater¨ 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) eingefuhrt.¨ 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 verdrangt¨ wird. Noch schneller wird der Code39 (2.2.1), welcher vor allem in der Industrie und Medizin eingesetzt wurde, durch die DataMatrix abgelost¨ (2.2.1). Der Hauptgrund fur¨ diese Entwicklung ist die Tatsache, dass mehr Informationen auf einer kleineren Flache¨ abgebildet werden konnen.¨ 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 Ofﬂineblogs. 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 Lucken¨ mit unterschiedlichen Dicken. Lineare Barcodes, auch Strichcodes genannt, sind die einfachste, kostengunstigste¨ und flexibelste Methode, Objekte maschinell zu kennzeichnen. Durch die Standardisierung ist ein weltweit funktionierendes Identifikationssystem geschaffen worden.

EAN EAN ist die Abkurzung¨ fur¨ European Article Number und ist die veraltete Bezeichnung fur¨ International Article Number. EAN ist ein Code, bestehend aus numerischen Zeichen zwischen 0 (null) und 9 mit einer ﬁxen Lange¨ von 8 oder 13 Zeichen. Die EAN Codes werden zentral verwaltet und auf Anfrage an Hersteller fur¨ ihre Produkte vergeben. Die europaische¨ 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-Landercode¨ der GS1 4 Ziffern Hersteller Nummer 1RFID = Der englische Begriff Radio Frequency Identification (RFID) bedeutet im Deutschen ’Identifizierung uber¨ Radiowellen’. RFID ist ein Verfahren zur automatischen Identifizierung von Gegenstanden¨ und Lebewesen. Neben der beruhrungslosen¨ Identifizierung und der Lokalisierung von Gegenstanden¨ steht RFID auch fur¨ die automatische Erfassung und Speicherung von Daten. [26] 2Ein Blog (engl. Wortkreuzung aus Web und Log), ist ein digitales Journal. Der Herausgeber dieses Journals wird Blogger genannt.

ABCinfo 20

7 623900 205080 5449 2 3 8 7 (a) EAN13 (b) EAN8

Abbildung 9: Abbildung 2.2.1 zeigt einen EAN13 und 2.2.1 eine EAN8 Barcode.

• 5 Ziffern fur¨ die Artikelnummer • 1 Ziffern fur¨ die Prufziffer¨

EAN8 Der EAN8 Code besteht nur aus zwei Blocken¨ zu je 4 Zeichen aus den Zeichensatzen¨ A (linker Teil) und C (rechter Teil). Die 8 Ziffern der EAN8 bedeuten: • 2 Ziffern fur¨ die Global Location Number • 3 Ziffern fur¨ die Hersteller Nummer • 3 Ziffern fur¨ die Artikelnummer, inkl. Prufziffer¨

ISBN ISBN ist die Abkurzung¨ fur¨ ’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 durfen¨ nur im eigenen Warenhaus fur¨ 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 Speziﬁkation der EAN Barcodes ist offen und frei verfugbar.¨ Sie kann beim Schweizer Kompetenzzentrum fur¨ Standards (GS1) unter [32] und [33] als PDF Datei bezogen werden. Der Aufbau und die Kodierung der Barcodes konnen¨ aus diesen Standards entnommen werden. In den folgenden Abschnitten werden die Eigenschaften von EAN beleuchtet, bevor die Kodierung und Dekodierung der Barcodes naher¨ beschrieben werden.

Grundbegriffe Um eine Abhandlung zum Aufbau und zur Handhabung von Barcodes zu ermoglichen,¨ bedarf es im Voraus der Klarung¨ gewisser Grundbegriffe.

Modul Ein Modul ist die kleinstmogliche¨ Einheit eines Barcodes. Ein Zeichen (beispielsweise 6’) besteht ’ immer aus 2 Balken und 2 Lucken,¨ 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. Lucke¨ Eine Lucke¨ ist die Inverse eines Balkens. Sie erscheint im Kontrast zum Balken hell und besteht aus un- bedruckter Flache.¨ Eine Lucke¨ kann ein oder mehrere Module breit sein. Synonyme: Space, unsichtbarer Strich.

ABCinfo 21

Zeichen Ein Barcode besteht aus Zeichen, welche numerischen oder alphanumerischen Naturen sein konnen.¨ Zeichensatz Ein Zeichensatz deﬁniert die moglichen¨ Zeichen, die ein Barcode kodieren kann. Ein Barcodetyp kann mehrere Zeichensatze¨ verwenden. Modulgruppe Eine Modulgruppe ist ein Verbund von Modulen, welche zusammen einen Balken oder eine Lucke¨ bilden. Barcode Ein Barcode ist eine Menge von Zeichen die eine Kontextinformation bilden. Er wird durch Modul- gruppen von Balken und Lucken¨ kodiert.

Verschlusselung¨ der Symbolzeichen Die nachfolgende Tabelle zeigt die Zeichensatze¨ A, B und C, welche fur¨ die Verschlusselung¨ der Ziffern im EAN Code verwendet werden.

Tabelle 1: EAN Zeichensatze¨ in Modulbreiten Ziffer Zeichensatz A Zeichensatz B Zeichensatz C LBLB LBLB BLBL 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 Zeichensatze¨ beschreiben den Aufbau der Ziffern 0 – 9, indem die Anzahl Module fur¨ Lucken¨ (L) und Balken (B) deﬁniert werden. Die Ziffer 0 (null) beispielsweise, wird im Zeichensatz A durch 3 Module des Typs Lucke,¨ 2 Module des Typs Balken und je einem Modul Lucke¨ und Balken kodiert. Diese Folge erzeugt eine eindeutig identiﬁzierbare Modulgruppe fur¨ die Ziffer 0 (null). Eine Lucke¨ kann als Folge binarer¨ ’False’ (0), ein Balken als Folge binarer¨ ’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 Lucken¨ und Balken invertiert werden. Die besagte Ziffer 0 (null) wird im Zeichensatz A als binares¨ 0001101 kodiert. Der Zeichensatz C beschreibt die Ziffer 0 (null) mit 1110010 (Zeichensatz A invertiert). Tabelle2 zeigt die Zeichens atze¨ in binarer¨ Form.

(a) Beispiel und Direktver- gleich fur¨ die Ziffer 0, im Zeichensatz A, B und C

Abbildung 10: Visualisierung der Ziffer 0 in den verschiedenen Zeichensatze,¨ Zeichensatz A (oben), Zeichen- satz B (mitte) und Zeichensatz C (unten).

ABCinfo 22

Tabelle 2: EAN Zeichensatze¨ in binarer¨ 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

Verschlusselung¨ 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 Binar¨ 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

Paritatswechsel¨ Anhand der Paritat¨ wird die Leserichtung eines Barcodes deﬁniert. Die folgende Tabelle wird bei der Kodierung, resp. Dekodierung eines Barcodes benotigt¨ und kommt im Folgenden zum Einsatz.

Tabelle 4: EAN Paritatstabelle¨ fuhrende¨ 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

Landercodes¨ Ein mit einer EAN identiﬁziertes Produkt tragt¨ den Landercode¨ des Herstellerlandes, welcher aus drei Ziffern besteht und an den Postionen 1, 2 und 3 abgespeichert wird. Die Webadresse zur vollstandigen¨ GS1 Landercode¨ Liste ist unter [8] vermerkt.

ABCinfo 23

Tabelle 5: EAN Landercode¨ 300 - 379 Frankreich 400 - 440 Deutschland 760 - 769 Schweiz 800 - 839 Italien 900 - 919 Osterreich¨

Tabelle 6: Zusammenfassung zum Aufbau des EAN13 Barcodes Format des EAN13 Barcodes Bezeichnung Landercode¨ Hersteller Artikelnummer Prufziffer¨ 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

Zunachst¨ 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 deﬁniert den Aufbau der Ziffer 8 mit L=1, B=2, L=1, B=3. Die Ziffer 8 wird also durch ein Modul Lucke,¨ zwei Module Balken, ein Modul Lucke¨ und drei Module Balken kodiert. Die Summe der beiden Lucken¨ 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 fur¨ die unterschiedliche Nutzung von Zeichensatzen¨ ist die spatere¨ Berechnung der Einergruppe 1, welche die Paritaten¨ des linken Teils beschreibt. Durch diese Paritatsziffer¨ am Anfang des Barcodes wird in Kombination mit der Tabelle 4 die Benutzung des jeweiligen Zeichensatzes A oder B fur¨ die Kodierung der entsprechenden Position bestimmt. Die Paritatsziffer¨ 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 Paritaten¨ des linken Teils (erste Sechsergruppe), kann die Paritatsziffer¨ errechnet werden. Ein Barcode kodiert also nicht 13 Zeichen, sondern lediglich 12. Die erste Ziffer wird aus den ersten 6 Zeichen berechnet. Dies ermoglicht¨ zugleich die Ermittlung der Leserichtung anhand der Paritat.¨

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 ofﬁziell registriert (Instore Barcode). UPC Barcodes sind hauptsachlich¨ 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 speziﬁziert [25]. Das Start- und Endzeichen wird mit einem *-Zeichen identiﬁziert. Code39 besitzt eine Erweiterung mit welcher es moglich¨ ist, beinahe den gesamten ASCII Zeichensatz darzu-

ABCinfo 24 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 altester¨ alphanumerischer Barcode, immernoch eine hohe Bedeutung.

Zweidimensionale Barcodes Die Uberschrift¨ 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 Ubergangsl¨ osung¨ zwischen linearen Barcodes und 2D Matrixcodes. Der Vorteil besteht aus den Vorzugen¨ der zweidimensionalen Kodierung und der gleichzeitigen Verwendung von alten Geraten¨ wie dem Handscanner oder CCD Lesegeraten.¨

PDF417 PDF ist die Abkurzung¨ fur¨ ’Portable Data File’. Das Einsatzgebiet bezieht sich hauptsachlich¨ auf die Logistik. Dieser Code eignet sich ideal dazu Zusatzinformationen anzubringen, wie beispiesweise Zustell- adresse, Versand- und sonstige Informationen. PDF417 teilt sich fur¨ jede Zeile dasselbe Start- und Endzeichen. Damit sind alle alphanumerischen Zeichen kodierbar.

Matrixcode Mit der Verwendung von Matrixcodes ist es moglich¨ ein vielfaches an Informationsdichte zu erhalten. Da das Gesamtbild des Codes benotigt¨ wird, sind Matrixcodes nur mit CCD-Scannern und –Kameras dekodierbar. Aufgrund der geringen optischen Auﬂosung¨ und der mechanischen Strahlablenkung, scheidet die Verwendung von Lasergeraten¨ 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 ursprunglich¨ 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 fur¨ Quick Response. Uber¨ drei Eckmarkierungen wird das Lesegerat¨ kalibiert. Die folgende Auﬂistung zeigt die hohe Informationsdichte von QR Codes. • binare¨ Daten: 23624 Bits • numerische Daten: 7089 numerische Zeichen • alphanumerische Daten: 4296 alphanumerische Zeichen

DataMatrix Der DataMatrix Code wird hauptsachlich¨ in der Elektronik- und Autoindustrie eingesetzt. Er ist mit allen gangigen¨ Drucktechniken, insbesonders mit der Direktmarkierung 3, aufzubringen. Zur Orientierung beim Lesen der vier Sektoren dieses Codetyps beﬁndet 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 fur¨ die Online Bahntickets eingesetzt. Mit dem Aztec Code konnen¨ bis zu 3750 numerische, oder 3000 alphanumerische Zeichen kodiert werden. Dabei beherrscht er den kompletten ASCII-Zeichensatz. Abhangig¨ von der Modulgrosse,¨ liegt die Fehlerkorrektur zwischen 25% und 40%. [24] Das Lesegerat¨ orientiert sich am Quadrat im Zentrum.

3Mit Direktmarkierung ist gemeint, dass Produkte direkt mittels Lasergravur oder Nadelgravur, wie auch mittels Pragung¨ markiert werden, das heisst es wird keine Etikette verwendet und der Code ist ﬁx mit der Objekt dauerhaft verbunden.

ABCinfo 25

(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 Lesegerat¨ kalibriert sich an den Zentrumsmarkierungen.

ShotCode Der ShotCode [23] ist ein von der Cambridge University im Jahr 1999 entwickelter, kreisformiger¨ 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 Blocken¨ und zum zentralen Punkt und erstellt so ein Bitmuster. Hierfur¨ ist die Kamera eines Mobiltelefons oder eine Webcam ausreichend. Das Bitmuster wird anschliessend an einen Server ubertragen,¨ welcher die passende Kontextinformation zuruckliefert.¨ Meis- tens handelt es sich hierbei um Webadressen.

Barcode Lesegerate¨ Was fur¨ die Vielfalt an Barcodetypen und Anwendungen im Bereich der Barcodelosungen¨ zutrifft, gilt gleicher- massen auch fur¨ den Bereich der Dekodierung, der mit einer grossen Vielfalt an Lesegeraten¨ ausgestattet ist. Es wird zwischen drei Gruppen unterschieden, auf welche nachfolgend naher¨ eingegangen wird. Dabei wird jeweils lediglich die technische Funktionsweise erlautert¨ und auf Fakten wie Preis und Schnelligkeit verzichtet.

Lesestift Eine Leuchtdiode (LED) im Wellenlangenbereich¨ von Rot und eine Leuchtdiode im Infrarotbereich bestrahlen die zu lesende Oberﬂache.¨ Das reﬂektierte Licht wird durch eine Linse an den Fototransistor geleitet. Von dort ubernimmt¨ die Dekodierhardware die Daten.

ABCinfo 26

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 ubertragen.¨ Anstatt die Balken und Lucken¨ in Folge zu interpretieren, erstellt der Scanner ein binares¨ Muster aller Fotozellen die Informationen uber¨ Helligkeitswerte enthalten.

Laserscanner Der Laserscanner projiziert einen Laserstrahl uber¨ Polygonspiegel direkt auf den Barcode. Das vom Barcode reﬂektierte Licht wird uber¨ Spiegel und Linsen an einen Fototransistor geleitet. Theoretisch ist es m moglich¨ Barcodes mit einer Raumbewegung von 2.5 s zu dekodieren. Daher eignet sich der Laserscanner sehr gut fur¨ Warenhauser¨ oder Gepackabfertigungen.¨

Probleme Nicht nur die Architektur von beispielsweise CMOS Sensoren4 lassen ein Bild bei der Transformation von der Objekt- in die Bildebene an Qualitat¨ verlieren. Oft ist es der Fall, dass bereits das Objektbild eine schlechte Gute¨ besitzt. Der Ursprung dafur¨ liegt entweder im schlechten Aufdruck des Barcodes auf seinen Artikel, oder darin, dass der Barcode aufgrund der Verpackungseigenschaft zerknittert oder verzerrt ist. Mobilgeratekameras¨ haben zwar einen grossen technischen Fortschritt hinter sich, noch ist das ’Snap-and-Go’, wie man es von Spiegelre- ﬂexkameras her kennt, jedoch nicht gegeben. Eine ruhige Hand des Anwenders ist immernoch gefragt um eine optimale Bildqualitat¨ zu erhalten. Die folgenden Abbildungen visualisieren das angesprochene Guteproblem.¨

(a) Fehlende Pixel, falsche Breiten der (b) Zerstorte¨ und/oder fehlende Informati- (c) Schlechte Druckqualitat¨ Balken und Lucken¨ on durch Blitzlicht oder Reﬂektionen.

Abbildung 13: In den Bilder 13(a), 13(b) und 13(c) werden einige Problematiken bezuglich¨ des Eingangsbildes visualisiert.

Die linke Abbildung zeigt einen Barcode mit ungenauen Modulwerten. Balken und Lucken,¨ welche laut Spezi- fikation dieselbe Breite haben mussten,¨ weisen diese Eigenschaft nicht auf. Eine schlechte Druckqualitat¨ 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 zerstorten¨ Bildinformationen durch Blitzlicht und Reflektionen. Schlimmstenfalls sind nicht mehr alle benotigten¨ 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 spateren¨ Binarisierung eines Bildes. Dasselbe Problem tritt auf, wenn sich Farbe auf einer Oberflache¨ (meist Plastik) zusammenzieht und sich Lucken¨ innerhalb von Balken bilden. Umgebungselemente auf dem Bild, wie beispielsweise Inhaltsstoffangaben, konnen¨ die Algorithmik zur Deko- dierung ebenfalls beeintrachtigen,¨ da diese oft dieselbe Charakteristik wie der Barcode selbst haben.

4Complementary Metal Oxide Semiconductor (CMOS, dt. komplementarer¨ 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.

ABCinfo 27

In den folgenden Konzepten wird aufgezeigt, wie und womit diese Probleme vermindert oder gelost¨ werden konnen.¨ Dies gelingt nicht immer und lasst¨ die Erkenntnis zu, dass nicht jedes Bild, welches vom Auge als qualitativ ausreichend bewertet wird, auch tatsachlich¨ verwendet werden kann.

ABCinfo 28

2.2.2 Computer Vision Konzepte Punktoperationen Unter dem Begriff der Punktoperatoren versteht man Verfahren zur Anderungen¨ von Pixelwerten im Allgemei- nen, dies kann zum Beispiel eine Kontrastverstarkung,¨ Gamma- oder Helligkeitskorrektur sein. Sie verdanken ihren Namen der Tatsache, dass bei allen Verfahren jedes Pixel eines Bildes nur in Abhangigkeit¨ 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 Bildgrosse¨ und die Position des Pixels andert¨ sich nicht. Punktoperationen stellen meistens den ersten Schritt der Vorverarbeitung dar, um den Bildkontrast zu verstarken¨ oder Belichtungsfehler bei der Bildaufnahme auszugleichen.

Grauwertkonvertierung Grauwertbilder, auch als Intensitatsbilder¨ bezeichnet, verfugen¨ uber¨ einen Hellig- keitskanal, welcher die Helligkeit, die Intensitat¨ oder die Dichte des Bildes beschreibt. Die Darstellung erfolgt im Format 0 ··· (2k − 1). Ein Grautwertbild enthalt¨ also nur positive Werte. Der Wert 0 (null) beschreibt die minimale Helligkeit: schwarz. Bei einer Auﬂosung¨ von 8bit/Pixel, beschreibt der Wert 255 die maximale Hel- ligkeit: weiss.

Histogrammanalyse In der digitalen Bildverarbeitung beschreibt ein Histogramm die statistische Hauﬁgkeit¨ der Grauwerte, beziehungsweise der Farbwerte in einem Bild. Das Histogramm eines Bildes erlaubt eine Aus- sage uber¨ die vorkommenden Grau- oder Farbwerte und uber¨ den Kontrastumfang und die Helligkeit des Bil- des. In einem Farbbild kann ein Histogramm entweder uber¨ alle drei Farbkanale¨ oder fur¨ jeden Kanal einzeln erstellt werden. Die Bildverarbeitung arbeitet meist mit Grauwertbildern und arbeitet darum nur mit einem Histogramm.

Schwellwertbildung Der Schwellwert, auch hauﬁg¨ als Threshold (engl.) anzutreffen, beschreibt eine deﬁ- 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 Uberschreitung¨ 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 Zustande¨ fur¨ 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 ungleichmassiger¨ Ausleuchtung eines Bildes, kann es sinnvoll sein, den Schwellwert dynamisch anzupassen. Die Helligkeits- und Kontrast- verhaltnisse¨ der Umgebung sind dabei massgeblich. ( 1 falls pixelin ≥ Schwellwert pixelout = (1) 0 falls pixelin < Schwellwert

ABCinfo 29

Lokale Operationen Lokale Operatoren sind Verfahren, welche Pixelwerte abhangig¨ von ihrer Umgebung oder des ganzen Bildes, verandern.¨ 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 uberf¨ uhren,¨ 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 storender¨ Bildanteile, die Hervorhebung von informativen Bildanteilen oder die Restauration eines idealen Musters sein. Die Bildgeometrie andert¨ sich bei der Anwendung eines Filters nicht, das heisst, die Koordinaten bleiben erhalten.

Filtermatrix, -maske Filter bestehen in der Regel, aber nicht zwingenderweise, aus einer m · n Ma- trix. Jeder Eintrag dieser Matrix enthalt¨ einen Filterkoefﬁzienten, 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 uber¨ das Eingangspixel gelegt werden. Dieser sogenannte ’Hotspot’ kann innerhalb der Matrix frei gewahlt¨ 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 eingesetzt werden. Dieser scharft¨ das Bild mit einer speziellen Filtermatrix. Dabei kann beispielsweise eine 3 · 3 Matrix eingesetzt werden. Wird nur eine Bildzeile geﬁltert, 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 geglattet¨ und anschliessend mit einem Sobeloperator gefaltet. Das daraus resultierende Ausgangsbild enthalt¨ die horizontalen und vertikalen Gradienten (Kanten) des Eingangsbildes.

ABCinfo 30

(a) Canny Kantenhervorhebung (b) Canny mit anschliessender non maximum Suppression

Abbildung 14: Die Abbildungen zeigen mogliche¨ Ausgangsbilder (links) Canny Kantenhervorhebung und (rechts) Canny mit nachfolgender Non maximum Suppression.

Hough-Transformation Die Hough-Transformation analysiert das Kantenbild des Canny-Algorithmus und uberf¨ uhrt¨ es in seinen eigenen Transformationsraum. Das Ziel davon ist es, einfache geometrische Objek- te zu erkennen und zu lokalisieren. Die Nachteile dieser Transformation sind der hohe Rechenaufwand und Speicherbedarf.

ABCinfo 31

Globale Operationen Scanline Sampling Um die Pixelinformationen eines aufgenommenen Bildes zu extrahieren und diese zu analysieren, eignen sich verschiedene Strategien mehr oder weniger gut. Die einfachste Variante ware¨ das algorithmische Verarbeiten des kompletten Bildes ohne eine speziﬁsche Auswahl entsprechender Pixel. Um Re- chenzeit zu sparen, eignet sich die Alternative nur bestimmte Informationen aus dem Bild zu entnehmen. Der prizipielle Ansatz bezieht sich auf die Extraktion von mehreren horizontalen Pixelwerten. Diese Technik wird in diesem Projekt als Scanline Sampling bezeichnet. Dabei wird eine komplette Reihe an Pixelwerten ausgelesen und verarbeitet. Abbildung 15(a) visualisiert dieses Konzept anhand eines Barcodes mit roter Scanline und dem Scanline Signal in Abbildung 15(b).

255

(a) Eingangsbild (b) Signal der Scanline

Abbildung 15: Die Abbildungen zeigen ein mogliches¨ Eingangsbild (links) und (rechts) das Signal der Scanline des Eingangsbildes. Deutlich wird die Problematik der Uberf¨ uhrung,¨ respektiv Quantiﬁzierung, eines Signals von der Analogen in die digitale Welt.

Drei unterschiedliche Strategien zur Entnahme von Scanlines werden wie folgt beschrieben: Variante 1 Zur Performanceverbesserung werden nur wenige Scanlines gesamplet. Diese werden an der statistisch interessantesten Position im Bild entnommen. Die Verteilung der Scanlines kann linear oder nach Gauss’scher Verteilung erfolgen. Variante 2 Es wird ebenfalls eine bekannte Anzahl Scanlines abgetastet. Diese verteilen sich allerdings zufallig¨ uber¨ das ganze Bild oder uber¨ einen informativen Bereich. Variante 3 Aquivalent¨ zur ersten Variante werden Scanlines innerhalb eines Bereichs gesampled und linear oder nach Gauss ausgerichtet. Neu ist die Reihenfolge der Abtastung: Anstatt die Scanlines inkremen- tell von der Position 0 bis zur Position n-1 im sensitiven Bereich zu verteilen, werden die Samplings alternierend verteilt:

1. Scanline: Position (n/2) 2. Scanline: Position (n/2) - r 3. Scanline: Position (n/2) + r 4. Scanline: Position (n/2) - 2*r ... m-1. Scanline: Position 0 m. Scanline: Position n-1

Abbildung 16 visualisiert die moglichen¨ Scanline Verfahren. Die erste Scanline wird dabei rot eingefarbt,¨ die letzte Scanline wird gelb eingefarbt.¨ Dazwischen ergibt sich eine zunehmende Farbung.¨

ABCinfo (a) Variante 1 (b) Variante 2 (c) Variante 3

Abbildung 16: Visualisierung der drei Strategien zur Entnahme von Scanlines. 33

2.2.3 Applikationskonzepte Damit die Applikationsarchitektur geplant und umgesetzt werden kann, mussen¨ die verschiedenen Aspekte dieses Projektes reﬂektiert und die moglichen¨ Losungskonzepte¨ ausgearbeitet werden. Dies geschieht im folgenden Abschnitt in dem Strategien erlautert¨ und verglichen werden.

Model-View-Controller Die Frage nach der grundsatzlichen¨ Applikationsarchitektur beantwortet sich mit der Grosse¨ der Anwendung. Die Aufgabenverteilung kann im Prinzip in drei grobe Teile gegliedert werden. Wenn eine Datenstruktur vorhanden ist, benotigt¨ es dafur¨ eine Instanz. Wenn GUI Aus- und Eingaben getatigt¨ werden, benotigt¨ es dafur¨ eine zusatzliche¨ Instanz. Um die Daten sinngemass¨ zu verarbeiten erfordert es eine dritte Instanz. Ab einer gewis- sen Applikationsgrosse¨ macht es Sinn, diese Teile jeweils in einem eigenen Mechanismus zu handhaben. Ist dies der Fall, sprechen wir von einer Model-View-Controller Architektur. Das Model reprasentiert¨ die Daten, die View stellt ein GUI zur Verfugung¨ und der Controller ist fur¨ das Verhalten der Applikation zustandig.¨ Der entscheidene Vorteil, der sich aus diesem Modell ergibt, ist die Modularitat¨ und Erweiterbarkeit der Anwen- dung. Es kann ohne weiteres ein anderes GUI Framework eingesetzt werden, ohne die komplette Architektur zu andern.¨ Es kann ebenfalls eine andere Datenquelle abgefragt werden, solange die Schnittstelle fur¨ die Daten dieselbe bleibt. Gewisse Frameworks wie Swing (Java) oder Ruby on Rails stellen dem Entwickler eine bereits vorgefertigte MVC Architektur zur Verfugung.¨

(a)

Abbildung 17: MVC-Architektur als UML-Sequenzdiagramm

ABCinfo 34

Packaging Wenn Python bei kleineren Aufgaben eingesetzt wird, ist es die Regel ein monolithisches Skript zu schreiben, welches vom Interpreter verarbeitet wird. Je grosser¨ und komplexer die Anwendung wird, desto mehr sollte man von der objektorientierten Eigenschaft Pythons Gebrauch machen. Verschiedene Aufgaben sollten in Klassen ausgelagert werden. Dies erhoht¨ die Kapselung und lost¨ die Kopplung. Zur spateren¨ Erweiterbarkeit ist diese Strategie gut geeignet, da Code mehrfach, durch importieren der programmierten Module, verwendet werden kann. Die Geschwindigkeit wird, wie besprochen, durch vielfaches Instanzieren von Klassen zwar verlangsamt, kann aber in Kauf genommen werden. Alle Hilfsklassen werden in separate .py Dateien geschrieben. Diese konnen¨ in einem eigenen Ordner zusammengefasst und aus dem main.py importiert und verwendet werden. Ein anderes Konzept der Strukturierung in Python besteht in der Verwendung von Packages, wie sie aus Java bekannt sind. Dabei geht es darum, die in Module ausgelagerten Klassen in einer grosseren¨ Applikation, mit Hilfe von Ordnerstrukturen, logisch zu sortieren.

(a)

Abbildung 18: Python Packagestruktur

Bildaufnahme Um ein Objekt der realen Welt digital zu verarbeiten, muss es zuerst in die Bildebene umgewandelt werden. Dazu wird eine Aufnahmevorrichtung benotigt,¨ welche im Falle dieses Projektes bereits gegeben ist. Die Ka- mera des Nokia N93 ist zum Fotograﬁeren von Bildern bestens geeignet. Das eigentliche Problem besteht in der Ansteuerung dieser Kamera. Da bei der Aufnahme komplexe, mechanische Vorgange¨ realisiert werden mussen,¨ benotigt¨ es eine Applikationsschnittstelle. Im einfachsten Fall steuert der Programmierer die Kamera mit den gewunschten¨ Parametern an und erhalt¨ als Ruckgabewert¨ ein Rasterbild, welches im festen Speicher abgelegt wird. Python fur¨ S60 bringt das Modul ’camera’ in seinem Standardumfang mit sich. Mit diesem Modul besteht die Moglichkeit¨ die Kamera anzusteuern; leider in einem sehr bescheidenen Umfang. Es ist lediglich moglich¨ mit der Kamera ein Bild aufzunehmen und dieses abzuspeichern. Um das Projekt wie gewunscht¨ zu entwickeln, waren¨ aber ein Viewﬁnder (Live-Bild) und eine Autofokusansteuerung unumganglich.¨ Die Nutzung der Kamera mit umfangreichen Parametereinstellungen wie Weissabgleich und Blitzlicht etc. ist nur unter Nutzung der Nokia C-API moglich.¨ Diese wiederum kann nur direkt von C++ ganzlich¨ genutzt werden. Somit stellt sich das Problem, dass gewisse Applikationsteile in C++ geschrieben werden mussten¨ um beispielsweise ein Live-Bild der Kamera zu erhalten. Ein ahnliches¨ Problem zeigt sich mit dem dringend benotigten¨ Autofokussystem. Ohne eine Ansteuerung dessen, wurde¨ man nie die benotigte¨ Bildqualitat¨ zur Dekodierung von Barcodes erhalten. Hier gestaltet sich die Sachlage noch schwieriger, da Nokia zwar die Header-Datei zur Ansteuerung des Autofokus in ihrer API zur Verfugung¨ stellt, man aber auf die Implementation in Form einer Library vergebens wartet. Solange Nokia diese Bibliothek nicht freigibt, ist es unmoglich¨ den Autofokus anzusteuern. Und auch wenn die API auf den neusten Stand gebracht wird, besteht noch immer ein Problem: solange Python fur¨ S60 den Autofokus nicht ebenfalls in sein camera-Modul aufnimmt, bleibt nur die Moglichkeit¨ der Ansteuerung in C++. Ein weiteres Konzept besteht darin, den Benutzer der Applikation die native Kameraanwendung nutzen zu lassen, um ein Bild des Objektes aufzunehmen. Dieses kann anschliessend mit Hilfe eines Dateibrowsers innerhalb

ABCinfo 35 der Anwendung geladen werden. Eine solche Moglichkeit¨ darf als Notfallplan betrachtet werden. Wichtig ist lediglich, dass es zu einem spateren¨ Zeitpunkt problemlos moglich¨ ist, diesen Dateibrowser durch die neuen Python Kamerafunktionen zu ersetzen. Die Anwendungsschnittstellen mussen¨ demnach unabhangig¨ bleiben.

C++ Extensions / Wrapping Wie es in diesem Dokument schon mehrfach angesprochen wurde, wird an dieser Stelle naher¨ auf die Nutzung von C++ innerhalb von Python eingegangen. Wie in Abschnitt 2.1.3 begrundet,¨ kann es teilweise Sinn machen, manche Applikationsteile aus Performancegrunden¨ in C++ auszulagern. Wenn man gewisse Funktionen der Nokia C-API, welche sehr umfangreich ist, nutzen mochte,¨ kann es aber auch eine Notwendigkeit sein, C++ Extensions zu implementieren. Python selbst ist in seinem API Funktionsumfang (noch) beschrankt.¨ Als erstes benotigt¨ man das S60 C++ SDK (3rd) von Nokia. Weiterhin wird das SDK von PyS60 benotigt.¨ Dieses wird nach der Installation des C++ SDK entsprechend in die entstandene Ordnerstruktur kopiert. Anhand eines Beispiels wird gezeigt, wie es moglich¨ wird, den Exit-Button in Python Anwendungen mit einem anderen Text zu belegen. Diese Option bietet das native Python fur¨ S60 nicht an. Auf die Praprozessordirektiven¨ wird an dieser Stelle nicht eingegangen, da die Includes hauptsachlich¨ aus nor- malen und proprietaren¨ Nokia SDK Header Dateien bestehen.

Listing 3: Uikludges.cpp s t a t i c PyObject * u i k l u d g e s s e t r i g h t s o f t k e y t e x t 1 ( PyObject * / * s e l f * / , PyObject * a r g s ) 2 { 3 char * t e x t = 0 ; 4 TInt textlen = 0; 5 i f ( ! PyArg ParseTuple(args , ”u#”, &text , &textlen)) 6 { 7 return 0 ; 8 } 9 TPtrC text ((TUint16 *) t e x t , t e x t l e n ) ; 10 11 12 TRAPD( e r r , 13 CEikButtonGroupContainer :: Current()−>SetCommandL(EAknSoftkeyExit , text ); 14 CEikButtonGroupContainer :: Current()−>DrawDeferred (); 15 ); 16 17 18 RETURN ERROR OR PYNONE( e r r ) ; 19 } 20 Die Ansteuerung der Nokia API geschieht mit den Funktionen SetCommandL() und DrawDeffered(). Dabei wird der Text, welcher auf dem EAknSoftkeyExit-Key (Exit-Button) erscheinen soll, aus den Argu- menten, die an die Funktion ubergeben¨ werden, geparsed. Im Funktionsblock werden hauptsachlich¨ interne Python-Wrapper Ablaufe¨ sowie Fehlerabfangmechanismen (durch das Makro TRAPD) ausgefuhrt.¨ Die Funktion uikludges set right softkey text() enthalt¨ als Returnwert einen Pointer auf ein Py- Object, welches wiederum ein Wrapperobjekt ist.

Listing 4: Uikludges.cpp (2) static const PyMethodDef uikludges m e t h o d s [ ] = 1 { 2 {” s e t r i g h t s o f t k e y t e x t ” , 3 (PyCFunction) uikludges s e t r i g h t s o f t k e y t e x t , METH VARARGS} , 4 {0 , 0} / * s e n t i n e l * / 5 } ; 6

ABCinfo 36

Nachdem die API Aufrufe in einem Python Objekt gekapselt wurden, wird diese Methode einem Array des Types PyMethodDef ubergeben¨ und mit einem Namen fur¨ den Export versehen.

Listing 5: Uikludges.cpp (3) DL EXPORT( void ) i n i t uikludges () 1 { 2 PyObject * module = P y InitModule(” uikludges”, 3 (PyMethodDef *) u i k l u d g e s m e t h o d s ) ; 4 } 5 Wie es fur¨ Libraries notwendig ist, wird schliesslich die Funktion exportiert. Dies geschieht hier, indem das, mit der Funktion gefullte¨ Array uikludges methods, einem eindeutigen Namen uikludges zugewiesen und als eine Art Python-init Objekt exportiert wird. Nun muss die Datei Uikludges.cpp ubersetzt¨ werden. In dem erwahnten¨ SDK existieren Compiler und Skripts, welche den Entwickler dabei unterstutzen.¨ Das Ziel ist es eine .pyd (Python DLL) Datei zu erhalten, welche binaren¨ Code beinhaltet und importiert werden kann. Hierzu werden unter Windows die folgenden Befehle gestartet:

• bldmake bldﬁles Startet das bldmake Skript und generiert alle Makeﬁles die es zur Kompilierung benotigt.¨ • abld build gcce urel Startet das Perl Skript abld und kompiliert die C++ Datei mit dem GCCE Compiler in die entsprechende Umgebung.

Der nachste¨ Schritt besteht darin, ein Installationspaket zu generieren, welches auf dem Mobilgerat¨ installiert werden kann. Hierzu wird das Werkzeug makesis benotigt,¨ welches im C++ SDK enthalten ist. Es erwartet eine Package-Datei mit folgender Struktur:

&EN #{"uikludges"},(0xA00015D0),1,0,0, TYPE=SA %{"Vendor-EN"} :"Vendor" [0x101F7961], 0, 0, 0, {"S60ProductID"} "python\uikludges.py"-"c:\resource\uikludges.py" "_build\_uikludges.pyd"-"c:\sys\bin\_uikludges.pyd"

Uikludges.pkg gibt ’makesis’ an, wie die zu generierende .sis Datei heissen soll, fur¨ welche S60 Version sie ausgelegt ist (0x101F7961 steht fur¨ 3rd Version), woher die kompilierte .pyd Datei stammt und dass diese auf dem Mobilgerat¨ in das Systemverzeichnis installiert werden soll. Zu guter Letzt muss die .sis Datei signiert werden. Die Erklarung¨ wird hierbei auf sogenannte selfsigned-sisx Dateien beschrankt.¨ Ein Mobiltelefon der dritten Symbian Generation erwartet durchs eine erhohten¨ Sicherheitsbestimmungen, ein zertifiziertes .sisx Installationspacket. Dies wird erreicht, indem der Entwickler das Werkzeug ’makekeys’ aus dem SDK verwendet und damit eine .key und eine .cer Datei erzeugt. Sie beinhalten ein eigens gewahltes¨ Passwort, sowie die Angabe uber¨ die bestimmungsgemasse¨ Verwendung der Applikation. Eine Anwendung, welche beispielsweise das Netzwerk nutzen mochte,¨ muss mit anderen Parametern zertifiziert werden. Nach der Generierung des Schlussels¨ und der Zertifikate wird die .sis Datei mit denselben signiert. Somit wird eine .sisx Datei geschrieben, welche auf dem Mobilgerat¨ installiert werden kann. Anschliessend wird in der Python Konsole des Nokia N93 gepruft¨ ob die Extension wie gewunscht¨ funktioniert:

import u i k l u d g e s 1 uikludges. set r i g h t s o f t k e y text (u”Back”) 2

ABCinfo 37 wenn alles fehlerfrei funktioniert hat, andert¨ sich der Text auf dem Exit-Key in ’Back’. Soweit dieser Exkurs in die Welt der Extension Programmierung mit C++. Man erkennt die Komplexitat¨ anhand dieser sehr einfachen Anwendung rasch. Wenn jetzt noch Klassenstrukturen und Heap/Stack Operationen angewendet werden (mussen!),¨ wird das Design noch um einiges komplizierter, da die C++ Programmierung alleine (ohne Wrapping) schon sehr anspruchsvoll ist. Das Konzept der C++ Nutzung unter Python ist fur¨ Projekte mit langerer¨ Dauer oder mehr Ressourcen jedoch durchaus interessant.

XML Um Daten zu verwalten, zu gliedern und gleichzeitig auf einfache Art und Weise zwischenzuspeichern bedarf es einem konsistenten und standardisierten Format. Ein Ansatz um diese Vorgaben zu erfullen,¨ ist das Einfullen¨ von Daten in eine relationale Datenbankstruktur. Leider fuhrt¨ er dazu, dass das Zwischenspeichern (Caching) von Daten nicht moglich¨ ist. Bei Abfragen von einem Mobilgerat¨ aus, ist es angesichts der hohen Kosten pro Abfrage jedoch notig¨ ein System zu entwickeln um Daten konsistent zu erhalten. Ein weiteres Konzept besteht in der Verwendung der Extensible Markup Language (XML). Sie ist eine Sprache zur Darstellung hierarchischer Daten in Form von Textdateien. XML bietet alle Eigenschaften um die benotigten¨ Anforderungen zu erfullen.¨ In einer Baumstruktur konnen¨ Daten anhand ihres Schlusselwortes¨ ausﬁndig gemacht werden. Zusatzlich¨ ist es moglich,¨ gewisse Datensatze¨ aus einer grossen XML Datei zu ﬁltern und wiederum in eine eigene Datei zu schreiben. Das Aussondern der gewunschten¨ Informationen geschieht mittels einem geeigneten XML Parser. Beim Arbeiten mit XML bestehen fast keine Einschrankungen.¨ So sind beispielsweise Programmeinstellungen ebenfalls Daten und konnen¨ somit auch in einer XML Datei abgelegt werden. Dort konnen¨ sie von Benutzern ausgelesen und handisch¨ geandert¨ werden. Beispiel:

Listing 6: Ein XML-Beispiel 1 2 < t i t e l>Advanced BarCode Information 3 4 1234567890123 5 Kakaopulver 6 7 8 9876543210987 9 Milch 10 11 12

Parsing Wenn eine Datenstruktur wie die in Abschnitt 3.2.2 besprochene Extensible Markup Language (XML) eingesetzt wird, benotigt¨ es ein Hilfsmodul, welches im Stande ist XML zu verstehen. Es wird dabei ein sogenannter Parser verwendet. Er kann eine Baumstruktur nach bestimmten Elementen durchsuchen und von diesem Punkt an iterative Operationen, wie beispielsweise das Auslesen von Elementinhalten (’Kakaopulver’, ’Milch’, ...), anwenden. Ein solcher Parser konnte¨ von Hand geschrieben werden, was allerdings der sprichwortlichen¨ zweiten Erﬁndung des Rades nahekommen wurde.¨ Produktiver ist der Einsatz eines bereits existierenden Parsers, wie zum Beispiel ElementTree. Dieser ist speziell fur¨ Python geschrieben und kann auch auf dem Mobilgerat¨ eingesetzt werden. Noch efﬁzienter ist die C-Variante cElementTree, ebenfalls erhaltlich¨ fur¨ PyS60. Um einen Ubersicht¨ uber¨ die Performance von verschiedenen XML Parsern zu erhalten, dient die folgende Auswertung eines Benchmarks, bei dem auf einem Desktopsystem eine 3405 KiB (Kilo Bytes) grosse XML Struktur von der Harddisk in den Arbeitsspeicher geladen wird.

ABCinfo 38

Tabelle 7: XML Parser Benchmark Modul Zeit (in Sekunden) Speicherbelegung xml.dom.minidom (Python 2.1) 6.3 80’000 KiB xml.dom.minidom (Python 2.4) 1.4 53’000 KiB ElementTree 1.2 1.6 14’500 KiB cElementTree (C extension) 0.047 4’900 KiB

Caching Wie in Abschnitt 3.2.2 erwahnt,¨ wird ein Zwischenspeicher fur¨ die Daten benotigt.¨ Der Grund dafur¨ sind die, beim Download von Daten uber¨ das Mobilfunknetz, entstehenden Kosten. Der einfachste Weg ist es, die ge- ladenen Daten in eine lokale Datei zu schreiben und diese auf dem Mobilgerat¨ im nicht-ﬂuchtigen¨ Speicher abzuspeichern. Zu einem spateren¨ Zeitpunkt kann auf diese Daten, ohne eine externe Verbindung herzustellen, erneut zugegriffen werden. Zusatzlich¨ mussen¨ Archivierungsinformation daruber¨ abgelegt werden, woher die Daten stammen, um welche Daten es sich handelt und wie alt diese Daten sind. Ein Konzept besteht darin, diese Informationen in den Header der Datei zu schreiben und diese von dort wieder auszulesen. Dies wurde¨ allerdings bedeuten, dass auf der Suche nach einem bestimmten Datensatz jede Datei geoffnet,¨ durchsucht und analyisert und wieder geschlossen werden musste.¨ Um diesen Flaschenhals zu umgehen, bietet sich ein zweites Konzept an: die Overhead-Informationen werden in den Dateinamen eingebettet. Somit kann rasch und effektiv nach der Datenquelle, dem Inhalt und dem Entstehungszeitpunkt gesucht werden. Beispiel: amazon-9781569244296-13648.xml Der erste Teil des Dateinamens beschreibt, woher die Datei stammt. Der Mittelteil beinhaltet eine EAN und zeigt damit an, welche Daten die Datei beinhaltet. Im dritten Teil wird das Alter der Datei in Tagen seit 1970 abgespeichert. Die Dateiendung ist XML 3.2.2.

ABCinfo 39

3 Entwurf & Realisierung 3.1 Einleitung Die Phase der Analyse und Konzeption ist abgeschlossen. Die zur Verfugung¨ stehenden Mittel und Methoden wurden erforscht und analysiert. Von nun an gilt es, die Konzepte, fur¨ welche man sich entscheidet, in einen Applikationsentwurf umzusetzen und diesen anschliessend zu implementieren. Diese beiden Schritte konnen¨ als Realisierungsphase angesehen werden. Bevor die Entscheidungen zur Konzeption getroffen werden konnen,¨ muss eine Reﬂexion der Mittel und Werkzeuge gemacht werden. Man hat in der Analyse die Starken¨ und Schwachen¨ von Python auf Mobilgeraten¨ erforscht und ist zur Erkenntnis gekommen, dass algorithmische Be- rechnungen mit hoher Wahrscheinlichkeit nur langsam getatigt¨ werden konnen.¨ Der Grund, warum in diesem Projekt dennoch keine andere Programmiersprache als Python eingesetzt wird, liegt im Verhaltnis¨ des Aufwands zur Zeit. Wie bisher gezeigt wurde, ist das Entwickeln von C-Extensions in Python nicht banal und erfordet eine tiefere Einarbeitung in die C-API, in das speziﬁsche Programmieren mit C++ auf Symbian und in das Wrap- pen von Python DLL. Die Angabe von Robert Adelmann 2.1.2, welcher Erfahrung mit C++ auf Symbian hat, unterstreicht diese Aussage. Da diese Zeit hier nicht vorhanden ist, hat man sich dafur¨ entschieden, die Applika- tion und die Architektur, mit Rucksicht¨ auf die Eigenschaften der Programmiersprache, in Python zu schreiben. So werden beispielsweise Methoden, welche einen erhohten¨ Rechenaufwand bedeuten wurden,¨ durch andere Konzepte ersetzt.

Vorgesehene Anwendungsfeatures Die folgenden Eigenschaften sollen Teil der Applikation werden. Das Bedurfnis¨ danach ist entweder uber¨ das Pflichtenheft des Auftraggebers geregelt oder entstand durch eigene Ideen. • Dekodierung von Barcodes der EAN Klassen (Pflicht) • Darstellen von Artikelinformationen aus dem Internet (Pflicht) • Datencaching (Pflicht) • Modulare und erweiterbare Umgebung (Pflicht) • Erweiterbarkeit fur¨ weitere eindimensionale Barcodes wie Code39 (Feature) • Individuelle und dynamische Programmkonfiguration (Feature) • Plattformunabhangigkeit:¨ Symbian / POSIX / Windows (Feature) • Multiple Resource Polling (Feature) Es konnen¨ mehrere Datenquellen fur¨ eine Anfrage herangezogen werden. • E-Nummern Abfrage (Feature) • Barcode History (Feature) • Daten- und Bildbrowser (Feature)

ABCinfo 40

3.2 Konzeptrealisierung / Entscheidungen 3.2.1 Computer Vision Konzepte Grauwertkonvertierung Entscheidung Das Bild wird mittels einer vorhandenen Picture Image Library (PIL, [19]) fur¨ Desktopsysteme von RGB in Grauwerte umgewandelt, respektive anhand einer zu deﬁnierenden Formel umgerechnet. Begrundung¨ Da das Eingangsbild drei Farbkanale¨ beinhaltet muss es vor der Weiterverarbeitung durch den Al- gorithmus in Graustufen konvertiert werden. Dies vermindert den Umfang des Bildes und des Rechenauf- wandes ohne Bildinformationen zu zerstoren.¨ Viele bekannte Algorithmen basieren auf der Verarbeitung von Grauwertbildern (Beispiel Canny).

Canny-Algorithmus Entscheidung Die Kantendetektion mittels Canny-Algorithmus wird aufgrund von hoher Geschwindigkeitsein- busse nicht eingesetzt. Begrundung¨ Um storende¨ Umgebungsinformationen zu eliminieren, ware¨ es optimal, den Barcode aus seinem Umfeld zu extrahieren. Da die Algorithmik dazu aber sehr rechenaufwandig¨ ist, wird darauf verzichtet. Dieser Entscheid birgt neue Probleme, wie der Umgang mit Storinformationen.¨ Die Histogrammanalyse 2.2.2 greift dieses Problem erneut auf und versucht es zu losen.¨

Hough-Transformation Entscheidung Die Objekterkennung mittels Hough-Transformation wird ebenfalls aufgrund der Performance nicht angewandt. Begrundung¨ Ohne die Berechnung eines Kantenbildes mittels Canny-Algorithmus ist die Hough-Transformation nicht nutzbar.

Scanline Sampling Entscheidung Sampling von Pixelreihen uber¨ die gesamte Bildbreite unter Verwendung der beschriebenen Variante 3 aus Abschnitt 2.2.2. Begrundung¨ Es wird davon ausgegangen, dass ein Benutzer den Barcode bei der Bildaufnahme intuitiv zen- triert. Diese Tatsache kann man sich zu Nutzen machen und nur einen deﬁnierten Bereich in der Bildmitte mit Scanlines samplen. Durch die alternierende Scanline Verteilung wird erreicht, dass Storbereiche¨ im Bild fruhstm¨ oglich¨ verlassen werden konnen.¨ Da durch die Begrenzung auf 20% der mittigen Bildinfor- mation viele, hochst¨ wahrscheinlich unwichtige Pixel, nicht berechnet werden mussen,¨ erhoht¨ sich die Performanz des Algorithmus erheblich. Ein Kameramodul konnte¨ zudem derart aufgebaut werden, dass man den Benutzer anhand einer visuellen Angabe des sensitiven Bereichs direkt bei der Bildaufnahme unterstutzen¨ wurde.¨

Laplace-Filter Entscheidung Diese Filterart wird auf die gesampelten Scanlines angewandt. Begrundung¨ Da eine Laplace Filtermatrix als Hochpassfrequenzﬁlter fungiert, wird das Rauschen zwischen den Uberg¨ angen¨ von Balken zu Lucken¨ unterdruckt.¨ Die Scanline erhalt¨ eine hohere¨ Scharfe¨ und kann spater¨ besser weiterverarbeitet werden.

ABCinfo 41

Schwellwertbildung Entscheidung Die Schwellwertbildung bildet ein Fundament zur erfolgreichen Dekodierung von Barcodes, sie wird deswegen in einer dynamischen Form eingesetzt. Begrundung¨ Um die extrahierten Bildinformationen zu binarisieren muss ein Schwellwert zur Entscheidungs- grundlage gebildet werden. Da die globale Beleuchtung von Bildern jedoch sehr unterschiedlich sein kann und sich auf die Schwellwertbildung auswirkt, wird die Berechnung des Schwellwertes dynamisiert. Der Algorithmus kann somit bei einer misgluckten¨ Dekodierung den Wert eigenstandig¨ anpassen und die Pixel anhand einer neuen Vorschrift in binare¨ Werte umwandeln. Jegliche Information die durch das Dekodie- ren gewonnen werden konnte wird gespeichert und mit einer allfalligen,¨ zusatzlichen¨ Pixelauswertung korreliert.

Histogrammanalyse Entscheidung Die Histogrammanalyse wird zur Feststellung der geringsten Modulbreite implementiert. Begrundung¨ Um einen Barcode zu dekodieren muss die Information uber¨ die Breite eines Moduls vorhanden sein. Ohne sie ist es nicht moglich¨ die Algorithmik nach der vorgegebenen EAN Speziﬁkation umzusetzen. Mit der Erkenntnis der Modulbreite konnen¨ anschliessend alle Balken und Lucken¨ einer Scanline angepasst, respektive normalisiert werden.

Im folgenden werden zwei weitere Konzepte erlautert,¨ welche nicht direkt aus der Computer Vision stammen, sondern vielmehr speziell fur¨ dieses Projekt eingesetzt werden und zur optimalen Bildaufbereitung vor der Dekodierung beitragen.

Scanline Interpolation Begrundung¨ Bei der Interpolation der Scanline wird das Signal um den Faktor 4 verlangert.¨ Gleichzeitig wird das Signal mit Stutzwerten¨ erganzt¨ und erhalt¨ damit eine hohere¨ Auﬂosung.¨ Diese wird spater¨ bei der dynamischen Schwellwertbildung benutzt. Der dort implementierte Korrekturfaktor erhoht¨ oder verringert den Schwellwert. Durch diese Anpassung konnte¨ das Signal ohne Interpolation komplett zusammenfal- len. Mit der erhohten¨ Auﬂosung¨ fallt¨ der Schwellwert nur auf den nachsten¨ Interpolationspunkt und kann somit feinjustiert werden. Nach der Scharfung¨ durch Laplace verbessert dieser Schritt das Signal noch weiter.

Modulrestauration Begrundung¨ Wie erwahnt¨ konnen¨ Bildinformationen die den Barcode betreffen verfalscht¨ sein oder ganzlich¨ fehlen. Dabei sind Balken oder Lucken¨ gestaucht oder verzogen. Dank den Informationen der Histogram- manalyse und den Barcode Standards konnen¨ diese Fehler teilweise behoben werden indem Modulgrup- pen normalisiert werden. Dazu wird eine Lauﬂangenkodierung¨ angewandt, welche im Entwurf anhand eines Beispiels naher¨ erlautert¨ wird.

3.2.2 Applikationskonzepte Model-View-Controller Entscheidung Umsetzung der erwahnten¨ MVC Architektur mit 3 Komponenten (Model, View, Controller). Begrundung¨ Da in diesem Projekt sowohl Datenbestande,¨ sowie GUI Interaktionen und Kontrollinstanzen benotigt¨ werden, wird die Applikation wie erwahnt¨ strukturiert. Zu einem spateren¨ Zeitpunkt kann somit die GUI leicht auf ein anderes Framework adaptiert und zusatzliche¨ oder andere Datenbestande¨ als Quelle hinzugezogen werden.

ABCinfo 42

Packaging Entscheidung Auslagerungen der Klassen in Hilfsmodule und strukturieren der Module mit Hilfe von Packa- ging. Begrundung¨ Die Modularitat¨ und Erweiterbarkeit der Anwendung ist nur dann gegeben, wenn eine lose Kopp- lung und eine hohe Kohasion¨ gegeben sind. Zur Applikationsubersicht¨ und der Vereinfachung von Code- Reuse mussen¨ die entwickelten Module mittels Packaging in eine sinnvolle Struktur gebracht werden.

Bildaufnahme Entscheidung Nutzung eines Dateibrowsers zum Anwahlen¨ des Bildes, welches zuvor mit der nativen Mobil- kamera getatigt¨ wurde. Anschliessendes Dekodieren dieses Bildes. Begrundung¨ Das Kameramodul von Python fur¨ S60 beinhaltet zum jetzigen Zeitpunkt keinen Autofokus. Dieser ware¨ aber fur¨ ein geeignetes Bild unerlasslich.¨ Das Aufnahmemodul musste¨ in Eigenarbeit in C++ geschrieben werden. Da Nokia die Bibliothek zur Ansteuerung des Autofokus erst gegen Ende der Projektdauer publik gemacht hat, wird auf eine aufwandige¨ Implementation verzichtet. Die Schnittstelle des Dateibrowsers ist jedoch dieselbe wie fur¨ ein Kameramodul (Ruckgabewert:¨ Pfad zum Bild), darum kann das Dateibrowser Modul zu einem spateren¨ Zeitpunkt (wenn der Autofokus implementiert wurde) immernoch ersetzt werden.

XML Entscheidung Download der Daten von einer XML Quelle (PHP-API) und Speicherung der Daten als XML Datei. Begrundung¨ Die einfachste und efﬁzienteste Art Daten uber¨ das Internet zu laden ist die Nutzung einer XML Quelle. Diese Daten werden anschliessend lokal als XML Datei abgelegt. Mit dem XML Parser cEle- mentTree [5] konnen¨ diese XML Baume¨ anschliessend efﬁzient nach den benotigten¨ Daten abgesucht werden.

Parsing Entscheidung Einsatz des Moduls cElementTree. Begrundung¨ Um hierarchische XML Dateien, wie sie in diesem Projekt verwendet werden, einzulesen und auszuwerten, soll ein bereits existierender Parser Anwendung ﬁnden. Die C-Version von ElementTree ist uber¨ dies schneller als die pure Python Version (siehe7).

Caching Entscheidung Speichern der XML- und Bilddaten in einem eigenen Ordner. Herkunft, Inhalt und Alter der Daten werden im Dateinamen mitgespeichert. Begrundung¨ Damit alle Daten einfach und von menschlicher Logik interpretiert werden konnen,¨ wird die Strukturierung uber¨ den Dateinamen gewahlt.¨ Somit kann die Applikation die Archivierungsinforma- tionen nutzen um das GUI entsprechend vorzubereiten. Ferner ist der Cache-Controller in der Lage zu ermitteln, ob es sich bei einer Datei um einen aktuellen Datensatz handelt, oder ob dieser erneut heruntergeladen werden muss.

ABCinfo 43

Die evaluierten Konzepte sind nun ausgearbeitet und konnen¨ fur¨ einen Entwurf der Applikation und der Al- gorithmik herangezogen werden. Die entstehenden Diagramme und Strukturen basieren auf den gefallten¨ Ent- scheidungen und sind im Vorfeld fur¨ die anschliessende Realisierung zwingend notig.¨ Um die konkrete Struk- turierung besser planen zu konnen,¨ werden, wie in der Projektplanung erlautert,¨ Testmodule entsprechend den ausgewahlten¨ Konzepten geschrieben. Diese erleichtern und unterstutzen¨ die Entscheidung zum Entwurf und zeigen, welche Moglichkeiten¨ zur Implementationsplanung realistisch sind. Die Testmodule beziehen sich auf die folgenden Teile: • Image Controller • EBV Controller • Barcode Controller • Algorithmik • Cache Controller • Database Controller • Parsing Controller

ABCinfo 44

3.3 Packaging

(a) Package Ubersicht¨

Abbildung 19: Package Ubersicht¨ ABCInfo

ABCinfo 45

3.4 Klassen und Organisation Um zu verstehen wie die Daten in diesem Projekt gehandhabt werden, muss zuerst auf die speziﬁsche Ver- wendung von XML eingegangen werden. Folgende Datenstrukturen werden in XML gespeichert und von dort ausgelesen: • Externe Daten (Internet Downloads) • Applikationseinstellungen • Dateneinstellungen • E-Nummern Einstellungen

3.4.1 Externe Daten Viele Datenquellen, unter anderem inﬂexion.ch und Amazon, bieten ihre Daten als XML Dump an. Als Beispiel einer solchen Datei dient ein Auszug einer Abfrage beim Anbieter Amazon. Resultat der Anfrage nach EAN (in diesem Falle eine ISBN) 0872203417:

Listing 7: XML-Beispiel Amazon 1 ... 2 1 3 1 4 0872203417 5 6 Modern Political Thought: Readings from Machiavelli to Nietzsche 7 8 Book 9 ... 10

3.4.2 Applikationseinstellungen In dieser XML Datei werden Einstellungen zur Applikation gespeichert. Somit beinhaltet die Anwendung nur eine fest programmierte Datei (der Pfad zu den Applikationseinstellungen). Alles andere wird von dort aus dynamisch geladen. Der Aufbau dieser Datei ist selbsterklarend.¨ Die Inhalte werden mit cElementTree geparsed.

Listing 8: Settings application.xml 1 < s t a r t application> 2 5 3 4 E: \ python \ l i b \ a b c i n f o \ r e s o u r c e \ s e t t i n g s d a t a . xml 5 6 7 E: \ python \ l i b \ a b c i n f o \ r e s o u r c e \ s e t t i n g s enumber .xml 8 9 10 E: \\ python \\ l i b \\ a b c i n f o \\ r e s o u r c e \\xml\\ 11 12 13 E: \\ python \\ l i b \\ a b c i n f o \\ r e s o u r c e \\ h i s t \\ 14 15 16

ABCinfo 46

E: \ python \ l i b \ a b c i n f o \ r e s o u r c e \ WelcomeSplashScreen . jpg 17 18 19 E: \ python \ l i b \ a b c i n f o \ r e s o u r c e \ GoodbyeSplashScreen . jpg 20 21 22 E: \ python \ l i b \ a b c i n f o \ r e s o u r c e \ WaitSplashScreen . jpg 23 24 25

3.4.3 Dateneinstellungen Die Dateneinstellungen deﬁnieren welche Informationen eines XML Datensatzes von Bedeutung sind und wie diese Daten dem Benutzer im GUI angezeigt werden sollen. Sie dienen dem XML Parser spater¨ zum ﬁltern der gewunschten¨ Informationen.

Listing 9: Settings data.xml 1 < s t a r t d a t a> 2 3 Asin 4 ProductName 5 Author 6 L i s t P r i c e 7 AvgCustomerRating 8 ImageUrlMedium 9 http: //xml.amazon.com/onca/xml3?t=php9comweblot −20&dev− 10 t=D37FFQXOC3MRYZ&type=heavy&f=xml&mode=books&KeywordSearch= 11 12

80 13 14 15 ... 16 17 18

Erklarung:¨ Die Datenquelle ’Amazon’5 soll alle Eintrage¨ welche in gespeichert sind, aus der heruntergeladenen XML Datei parsen und in der GUI, mit der in desc= gespeicherten Bezeichnung, angezeigen.

3.4.4 E-Nummern Einstellungen Die Abfrage nach Zusatzstoffen in Lebensmittel, geschieht uber¨ den E-Nummern Index. Da die Struktur einer E-Nummern Abfrage (keine Mehrfachabfrage moglich)¨ statischer und kompakter, als jene der EAN Abfrage gestaltet ist, existiert auch hierzu eine eigene XML Einstellungsdatei. Der Aufbau ist an die Dateneinstellungen angelehnt.

Listing 10: Settings enumber.xml 1 ~~2 3~~

~~5Amazon.com ist ein amerikanisches Online-Versandhaus, das Bucher,¨ CDs, DVDs, etc. uber¨ das Internet verkauft.~~

~~ABCinfo 47~~

~~E NUMBER 4 NAME 5 GEFAHREN 6 BESCHRIEB1 7 VERWENDUNGSZWECK 8 9 http: //www. inflexion .ch/abcinfo/CodeCheck getENumber.php?request= 10 11~~

80 12 13 14 Nachdem an dieser Stelle geklart¨ ist, um welchen Typ von Datenstrukturen sich die Applikation kummern¨ muss, kann die Klassenaufteilung naher¨ erlautert¨ werden. Zum Einstieg wird die Anwendung grob skizziert, auf die Delegierung der Klassen wird nachfolgend speziﬁsch eingegangen.

~~(a) Klassen Ubersicht¨~~

~~Abbildung 20: Klassen Ubersicht¨~~

ABCinfo 48 main Kapselt jegliche GUI Aufrufe und instanziert mainCtrl. mainCtrl Startet und koordiniert alle Ablaufe¨ und Controller Aufrufe. Stellt dem GUI aufbereitete Datenresul- tate (Bild und Text) zur Verfugung¨ und bereitet GUI Callbacks vor. settingsCtrl Durchsucht XML-Applikationseinstellungen nach gewunschten¨ Eintragen¨ und gibt diese zuruck.¨ barcodeHistory Liest eine .txt Datei mit den letzten 10 Barcode Eingaben aus und schreibt neue Eintrage¨ in diese Datei. Der Speicherpfad der History wird in den XML- Applikationseinstellungen angegeben und vom settingsCtrl ausgelesen. Der Ruckgabewert¨ von barcodeHistory ist eine Liste mit Barcodes. extModuleHandler Durchsucht die XML- Dateneinstellungen (33(f) 3.3) nach vorhandenen Quellen und liefert diese an den entsprechenden Aufrufer (mainCtrl). Wenn die Quelle(n) vom Benutzer uber¨ das GUI selektiert wurde(n), parsed dieses Modul die entsprechenden Tags zur Quelle aus der XML Datei und ubergibt¨ sie an mainCtrl. connectionCtrl Uberpr¨ uft¨ ob gewunschte¨ Bild- und Textdaten bereits in aktueller Form im Cache vorliegen, oder ob diese von einer lokalen (uber¨ den Wrapper) oder entfernten (uber¨ Internet) Quelle geladen werden mussen.¨ Stellt je nach Resultat der Prufung¨ eine externe Verbindung her. Diese kann uber¨ WLAN, GPRS oder WAP realisiert und vom Benutzer entsprechend ausgewahlt¨ werden. checkCache Agiert als Hilfsmodul fur¨ den connectionCtrl; durchsucht auf Anfrage den Cache nach bereits vorhandenen Daten einer bestimmten Quelle mit bestimmtem Inhalt und uberpr¨ uft¨ deren Alter. Sollte eine aktuelle Version existieren, wird der connetionCtrl avisiert diese zu nutzen. wrapper Hat in diesem Zusammenhang nichts mit dem Python C-Wrapping zu tun, sondern kann eine lokale Datenmenge (XML) nach einem bestimmten Datensatz durchsuchen und diesen zuruckgeben.¨ parseCtrl Ubernimmt¨ die vom connectionCtrl angeforderte XML Datei. Zusatzlich¨ hierzu werden die vom Benutzer gewunschten¨ Informationen vom mainCtrl ubergeben.¨ Mit dieser Kombination von Datensatzen¨ ﬁltert der parseCtrl die gewunschten¨ Daten aus der XML Datei und schreibt diese in eine Datenstruktur. Diese wird dem mainCtrl zur weiteren Vorverarbeitung fur¨ die GUI zuruckgegeben.¨ imgCtrl Fungiert als Dateibrowser um Bilder vom Typ JPG/JPEG oder PNG zur Dekodierung zu laden, oder um Daten manuell vom Mobilgerat¨ zu loschen.¨ Der Pfad eines ausgewahlten¨ Bildes wird an den barco- deCtrl ubergeben,¨ wo es weiterverarbeitet wird.

~~ABCinfo 49~~

~~3.5 Sequenzen / Ablauf Der Ablauf der Applikation wird mit Hilfe eines UML Aktivitatsdiagrammes¨ aufgezeigt.~~

~~(a) Klassen Ubersicht¨~~

~~Abbildung 21: Sequenzdiagramm~~

~~ABCinfo 50~~

Die Methoden zum Auswahlen¨ der Quelle(n) und der Verbindungsart sind fur¨ die Menupunkte¨ ’Check Barcode’, ’Barcode History’ und ’Image & Data Browser’ dieselben. Da die Abfrage nach einer E-Nummer nur ein Resultat liefern kann, ist diese Operation intern kompakter desi- gned und benotigt¨ nur die Angabe der Verbindungsart. Das im kommenden Abschnitt gezeigte Diagramm (23) beleuchtet die Aktivitat¨ ’Barcode dekodieren’ naher.¨ Darin werden Ablaufe,¨ welche dem Benutzer verborgen bleiben, durchgefuhrt.¨

~~ABCinfo 51~~

3.6 Barcode Dekoder Voraussetzungen Bevor auf die Funktionsweise des Barcode Dekoders eingegangen wird, mussen¨ die Voraussetzungen an das zu verarbeitenden Bildmaterial bestimmt werden. • Wie bereits erwahnt,¨ muss der Barcode moglichst¨ waagrecht im Zentrum des Bildes platziert werden. Testlaufe¨ (4.2) zeigen, dass eine Rotationstoleranz von 10° im und gegen den Uhrzeigersinn besteht. • Der Barcode sollte moglichst¨ grossﬂachig¨ aufgenommen werden. Dazu empﬁehlt es sich die optische Zoomfunktion der Kamera ausnutzen. Wie spater¨ beschrieben storen¨ Umgebungsinformationen im Bild die Dekodierung des Barcodes. • Wichtig ist die Verwendung des Autofokus um die optimale Scharfe¨ des Bildes zu erhalten. • Der Einsatz von Blitzlicht sollte vermieden werden, da die dadurch entstehende mogliche¨ Uberbelichtung¨ die Strukturen des Barcodes zerstoren¨ und eine Dekodierung verunmoglichen¨ (13(b) zu Blitzlichtbilder). Andere Dekodieralgorithmen wie die des Projekts ’barcr’ weisen ahnliche¨ Restriktionen auf. Nachfolgend ein Auszug aus der Dokumentation dieser Software.

~~(a)~~

~~Abbildung 22: Auszug aus dem readme von barcr.~~

~~ABCinfo 52~~

~~3.7 Barcode Dekoder~~

~~(a) ABCinfo Barcode Decoder, Flussdiagramm~~

~~Abbildung 23: Flussdiagramm Algorithmik~~

Wie im Flussdiagramm (23) ersichtlich, besteht der Barcode Dekoder hauptsachlich¨ aus drei Verarbeitungsin- stanzen. Dem Praprozessor,¨ dem Prozessor und der Validierung. Im weiteren werden die evaluierten Konzepte (2.2.2) zur naheren¨ Erklarung¨ der Funktionsweise und der konkreten Implementation herangezogen.

~~ABCinfo 53~~

~~3.7.1 Praprozess¨~~

~~(a) ABCinfo Barcode Decoder, Prozesskette~~

~~Abbildung 24: Der Dekoder kann grundsatzlich¨ in drei Hauptgruppen unterteilt werden: die Vorverarbeitung (Praprozess),¨ der Hauptverarbeitung (Prozess) und Validierung (Validation).~~

Um das Bild auf den Dekodierprozess vorzubereiten werden die Pixelwerte der Bildaufnahme ausgewertet. Jedes Pixel ist zur Zeit noch in RGB vorhanden, setzt sich also aus den Farbwerten Rot, Grun¨ und Blau zusammen. Diese werden als dreikomponentiges Python Tupel reprasentiert¨ (zum Beispiel (255,0,0) fur¨ Rot). Eine dokumentierte und ofﬁzielle Funktion zum auslesen von Pixelwerten existiert in Python nicht. Auf den zweiten Blick entdeckt man die Funktion getpixel(), welche im Modul graphics vorhanden ist. Sie beinhaltet die gewunschte¨ Operation. Um Rechenzeit einzusparen werden nur die relevanten Bildinformationen extrahiert und abgespeichert. Leider ist es aufgrund von Geschwindigkeitsproblemen nicht moglich¨ Bilder uber¨ eine Video- funktion ’Frame-by-Frame’ auszulesen und zu verarbeiten. Wie konzeptuell erwahnt,¨ mussen¨ die RGB Bilddaten in Graustufen umgewandelt werden. Dies kann auf Desktopsystemen uber¨ die Python Imaging Library (PIL, [19]) geschehen. Da diese Bibliothek fur¨ das Mo- bilgerat¨ nicht verfugbar¨ ist, werden die Bilder dafur¨ mit folgender Formel umgerechnet.

pixelout = 0, 299 ∗ rin + 0, 587 ∗ gin + 0, 114 ∗ bin (5) Diese Funktion wird in der Klasse mobileUtilities des Package BarcodeController//utilities implementiert. Das erzeugte Grauwertbild wird anschliessend mit der erwahnten¨ Variante des alternierenden Scanline Sampling abgetastet. Der Benutzer erhalt¨ die Moglichkeit¨ die Dekodierung in einem Debug Modus zu starten. Dieser visualisiert die abgetasteten Pixelwerte im Ausgabebild. Dazu wird die Funktion calculateScanlinePositions() mit einem spezifischen Parameter aufgerufen. Um die Qualitat¨ der erhaltenen Scanline zu erhohen¨ wird der Laplace Filter mit der folgenden 1 ∗ 3 Filtermatrix verarbeitet. Diese, so zeigt es sich in Testmodulen, beinhaltet die optimalen Koeffizienten zur Verbesserung der Pixelwerte. Der Filter Hotspot befindet sich im Zentrum der Matrix.

1/1 ∗ −1 6 −1 (6) Nach der Interpolation der Scanline und der darauf folgenden Schwellwertbildung, wird das Histogramm zur Ermittlung der korrekten Balken- und Lucken-Modulbreiten¨ analysiert: 1. Aus einer binarisierten Scanline wird ein Histogramm uber¨ alle Frequenzlangen¨ (deﬁniert durch den Ubergang¨ von 0 zu 1 und von 1 zu 0) erstellt. 2. Anschliessend wird das Histogramm nach seinen vier Maxima durchsucht. Diese reprasentieren¨ die Brei- ten der Modulgruppen in Pixel. Zur Erinnerung: Module konnen¨ alleine, zu zweit, zu dritt oder zu viert eine Modulgruppe bilden. Diese wiederum wird als Balken oder Lucke¨ deﬁniert.

~~ABCinfo 54~~

~~(a) variable Schwellwertanpas- sung~~

~~Abbildung 25: variable Schwellwertanpassung einer Scanline~~

3. Wie erwahnt¨ wird der Barcode im Bild nicht extrahiert. Der Nachteil davon zeigt sich darin, dass eine Scanline die komplette Bildbreite beinhaltet, in welcher naturlich¨ auch, fur¨ den Dekoder, nicht informative Pixel abgebildet sind. Gemass¨ der nachfolgenden Formel zur Normalisierung der kleinsten Modulbreite, konnen¨ diese Storungen¨ beseitigt werden.

~~P3 unitSizes[i] smallestUnit = i=0 (7) 10~~

P3 unitSizes[i] ( i=0 ) + unitSizes[0] smallestUnit = 10 (8) 2 Die Normalisierung der Modulgruppen wird in der Funktion adjustUnits() der Klasse utilities des Package BarcodeController implementiert. Um adjustUnits() zu verwenden, wird zuvor eine Lauﬂangenkodierung¨ der Scanline durchgefuhrt.¨ Verantwortlich hierfur¨ ist die Funktion widthCounting(). Da die Scanline nach der Binarisierung nur noch die Werte 0 und 1 enthalt,¨ ist es lediglich notwendig die Anzahl der Aufeinanderfol- genden binaren¨ Werte zu speichern. Das folgende Beispiel erklart¨ die Funktionalitat¨ der Normalisierung. Gegeben Eine Scanline mit binarem¨ Pixelinhalt. Die Modulgrosse¨ ist 1. Der kleinste Balken, respektive die kleinste Lucke,¨ weist demnach eine Breite von 1 auf. Normalisierung Die Normalisierung ﬁndet in zwei Stufen statt.

Lauﬂangenkodierung¨ Die Anzahl Pixel zwischen jedem Ubergang¨ von 0 und 1 werden gezahlt.¨ Gespei- chert wird anschliessend die Information daruber,¨ wieviele Einsen und Nullen aufeinander folgen. ...1111111110011111110101111101001001101...

~~wird zu ...927111511212211...~~

~~adjustUnits() Die erwahnte¨ Funktion adjustUnits() passt die Modulbreiten an. Die 9 wird geloscht,¨ die 7 und die 5 werden auf die grosstm¨ ogliche¨ Modulbreite gesetzt.~~

~~...9271115111212211...~~

~~wird zu~~

~~ABCinfo 55~~

~~...241114111212211...~~

~~Die Modulbreiten sind somit normalisiert und konnen¨ von einer Liste in ein String Objekt umgefullt¨ werden.~~

Um CPU Zeit zu sparen werden Passagen, die langer¨ als die doppelte Lange¨ der breitesten Modulgruppe sind (8 Modulbreiten), aus der Scanline geloscht.¨ Diese Optimierung wirkt sich auf alle nachfolgenden Prozesse aus.

~~ABCinfo 56~~

~~3.7.2 Prozess~~

~~(a) ABCinfo Barcode Decoder~~

~~Abbildung 26: Haupt Prozess, die Dekodierung~~

Nachdem die zu dekodierenden Pixel uber¨ eine Scanline aus dem Bild entnommen und bestmoglichst¨ prapariert¨ wurden, ubernimmt¨ der eigentliche Dekodierprozess die Arbeit. Er erhalt¨ die optimierten Werte des Praprozess¨ und versucht diese nach den gegebenen Spefizikationen zu dekodieren. Dieser Schritt greift nicht mehr auf kon- zeptueller Ebene ein, das heisst er bedient sich keinen Bildverarbeitungsoperationen mehr, sondern konzentriert sich lediglich auf die Verarbeitung von bereits gegebenen Werten. Dieser Schritt unterteilt sich in die folgenden Aufgabengebiete: • Definitionen laden • Typenerkennung • Startzeichendetektion • Kontextinformation Dekodierung • Teilinformation Speicherung Um einen Barcodetypen zu dekodieren, mussen¨ die entsprechenden Definitionen geladen werden. Die Spezi- fikation zum Typ EAN13 befindet sich in der Klasse ean. Diese bietet die Speicherung der Definitionen der beiden EAN Typen (EAN13 und EAN8) an. Um weitere Barcodetypen zu dekodieren, empfiehlt es sich das Package ean in barcodeDefs umzubennen und weitere Definitionsklassen in dieses Package abzulegen. Die Barcode Typenerkennung (z.B. EAN oder Code39) kann uber¨ diverse Merkmale wie die Lange,¨ das Start- zeichen und/oder andere spezifische Muster erreicht werden. Eine Bestimmung uber¨ die Lange¨ kann jedoch nur bei Barcodes mit fix definierten Langen¨ erfolgen. Um einen Barcode vom Typen EAN13 zu dekodieren, bedarf es der Erkennung des sogenannten Startzeichens. Durch die fehlende Extraktion und den deswegen auftretenen Storungen¨ in der Bildumgebung des Barcodes, kann die Detektion der Positionierung des Startzeichens negativ beeinflusst werden. Es ware¨ zusatzlich¨ moglich¨ die Detektion des sogenannten Ruhezeichens, in der Mitte des Barcodes, zu imlementieren. Dies wurde¨ die Teilerkennung von Barcodes erlauben. Desweiteren ist es notig¨ die Lange¨ des Barcodes zu erkennen, um zwischen EAN13 und EAN8 differenzieren zu konnen.¨ Falls dies wunschenswert¨ ist, kann diese Erweiterung ohne Schwierigkeiten zusatzlich¨ implementiert werden. In dem Projekt wird zum jetzigen Zeitpunkt aus Zeitmangel darauf verzichtet. Die Lauflangenkodierung¨ des Praprozesses¨ konnte uns im vorherigen Abschnitt das folgende Resultat liefern:

~~...241114111212211...~~

~~ABCinfo 57~~

Das Startzeichen fur¨ EAN Barcodes setzt sich aus einem Balken, einer Lucke¨ und einem Balken zusammen. Diese haben alle die Breite von einem Modul. Es geschieht also ein direkter Ubergang¨ von Schwarz zu Weiss zu Schwarz. Die Lauﬂangenkodierung¨ liefert fur¨ diesen Sachverhalt den Wert 111. Es wird angenommen, dass die erste zutreffende Zahlenfolge das gesuchte Startzeichen darstellt. Da die Umge- bungsinformationen im Bild diesen Wert ebenfalls annehmen konnten,¨ ist die Verlasslichkeit¨ dieser Methode in Frage gestellt. Um dieses Problem zu umgehen, konnten¨ alle gefunden Startzeichen gespeichert und einzeln analysiert werden. Aus Performancegrunden¨ wird darauf verzichtet. Der Einsatz von mehreren Scanline Samplings uber¨ das Bild senkt die Erkennung eines falschen Startzeichens jedoch drastisch und reicht zur Eingrenzung des richtigen Startzeichens grosstenteils¨ aus. Per Deﬁnition besteht der EAN13 Barcode aus insgesamt 95 Modulen. Diese unterteilen sich wie folgt:

• 3 Module fur¨ das Startzeichen (111) • 42 (6 x 7) Module fur¨ den linken Teil (erste Sechsergruppe) • 5 Module fur¨ das Ruhezeichen (11111) • 42 (6 x 7) Module fur¨ den rechten Teil (zweite Sechsergruppe) • 3 Module fur¨ das Endzeichen (111)

~~Ab dem ersten erkannten Startzeichen werden also 89 (95-3-3) Module extrahiert:~~

~~...241114111212211... wird zu 4111212211...~~

Aus diesen Werten, welche mit hoher Wahrscheinlichkeit unseren Barcode darstellen, werden Modulpakete a` 7 Module gebildet. Zur Erinnerung: ein Zeichen eines EAN Barcodes besteht aus 7 Modulen. Jedes Modulpaket beinhaltet somit ein Zeichen (das Ruhezeichen kann geloscht¨ werden). 4111212211... wird zu 4111 2122 11...

Die Zeichensatze¨ A, B und C werden in der Klasse ean implementiert. Diese dient als Look Up Table (LUT), wobei der Index der kodierten Ziffer entspricht. Nach der Ubergabe¨ eines Modulpaketes wird der entsprechende Index in der LUT nachgeschlagen. Ein unabhangiges¨ Beispiel fur¨ die Abfrage der LUT : ... 3211 1123 1213 ... (n-1) (n) (n+1) (n+2) n-1: ... n : 0 A n+1: 0 B n+2: 8 A n+3: ...

~~ABCinfo 58~~

Wird das Modulpaket n in der LUT abgefragt, erhalt¨ man das Zeichen 0 des Zeichensatzes A. Fur¨ die linke Seite mussen¨ jeweils die Zeichensatze¨ A und B abgefragt und die Paritatsfolge¨ separat mitgefuhrt¨ werden. Bei der fertigen Dekodierung der linken Seite kann anschliessend das Zeichen der Position 0 berechnet werden (Pa- ritatszeichen).¨ Das Zeichen an der Position 1 wird immer mit dem Zeichensatz A kodiert. Fur¨ den rechten Teil wird ausschliesslich der Zeichensatz C verwendet. Um bei jeder Abfrage ein Zeichen zu erhalten, kann die LUT stets das statistisch bestmogliche¨ Resultat zuruckliefern.¨ Der Nachteil dabei ist, dass durch diese Strategie Bar- codes oftmals falsch dekodiert werden. Efﬁzienter ist es, lediglich die mit Sicherheit korrekten Zeichen in einer Tabelle abzuspeichern und zu einem spateren¨ Zeitpunkt die Resultate uber¨ mehrere Scanlines zu korrelieren (3.7.3).

~~ABCinfo 59~~

~~3.7.3 Validierung~~

~~(a) ABCinfo Barcode Decoder~~

~~Abbildung 27: Validierung~~

Nach der Verarbeitung der Information einer Scanline, wird das Ergebnis validiert. Dabei werden folgende Schritte absolviert: • Prufsumme¨ uberpr¨ ufen¨ • Kontextinformationen analysieren und korrelieren • Prufung¨ von Restriktionen Der ermittelte Barcode wird zunachst¨ auf seine Prufsumme¨ uberpr¨ uft.¨ Dies geschieht nach der folgenden For- mel: ! X X mod10 3 ∗ digiti + digiti + checksum = 0 (9) odd i even i Die Prufsumme¨ wird in der Klasse ean folgendermassen implementiert:

Listing 11: checkBarcode def checkBarcode(self , barcodeString , barcodeType): 1 t r y : 2 barcode = barcodeString 3 checksum = 0 4 f o r i in range(len(barcode )): 5 i f barcode[i] == ’?’: 6 return F a l s e 7 i f barcodeType == ”EAN13”: 8 i f ( i%2 == 0 ) : 9 # even (value *1) 10 checksum = checksum + int(barcode[i]) * 1 11 i f ( i%2 != 0 ) : 12 # odd ( v a l u e *3) 13 checksum = checksum + int(barcode[i]) * 3 14 i f (checksum % 10 != 0): 15 return F a l s e 16 i f (checksum % 10 == 0): 17 return True 18 except : 19 return F a l s e 20 Um die Korrektheit eines Barcodes sicher zu stellen muss die Funktion dieser Prufung¨ True zuruckliefern.¨ Im Idealfall kann die vollstandige¨ Kontextinformation eines Barcodes anhand einer einzelnen Scanline dekodiert werden. Sollte dies nicht der Fall sein, wird die Funktion analyseFrequency() der Klasse scanlineArray

ABCinfo 60 aufgerufen. Diese korreliert die erkannten Zeichen uber¨ alle Scanlines. Die folgende Abbildung zeigt die Resul- tate einzelner Scanlines eines Barcodes mit der Kontextinformation 7610811607393. Die Prufung¨ uber¨ eine gesamte Spalte der Tabelle lasst¨ den Ruckschluss¨ auf das wahrscheinlich korrekte Zeichen zu. ... [7, 6, 1, 0, 8, 1, 1, 6, 0, 7, 3, ’?’, ’?’] [7, 6, 1, 0, 8, 1, 1, 6, ’?’, 7, 3, ’?’, ’?’] [’?’, 6, 6, ’?’, ’?’, ’?’, ’?’, ’?’, 6, 0, 7, 3, 9] [’?’, 6, ’?’, ’?’, ’?’, ’?’, ’?’, 6, ’?’, ’?’, 3, ’?’, 3] [’?’, 6, ’?’, ’?’, ’?’, ’?’, 1, 6, 0, 7, 3, 9, 3] [’?’, ’?’, ’?’, ’?’, ’?’, 3, ’?’, ’?’, ’?’, ’?’, 6, ’?’, ’?’] [’?’, ’?’, ’?’, ’?’, 6, ’?’, ’?’, ’?’, ’?’, ’?’, ’?’, ’?’, ’?’] [’?’, 6, ’?’, ’?’, ’?’, ’?’, ’?’, 6, ’?’, ’?’, 3, ’?’, 3] ...

Um zu verhindern, dass der Dekoder ein falsches Resultat an die Anwendung zuruckgibt,¨ werden einige absch- liessende Tests durchgefuhrt.¨ Die Restriktionen fur¨ einen validen Barcode sind abhangig¨ vom Typ und werden fur¨ den Typ EAN in seiner Klasse in der Funktion restrictions() deﬁniert. Diese hat den Ruckgabewert¨ True fur¨ einen korrekten, respektive False fur¨ einen invaliden Barcode. Dieses Konzept kann problemlos auf andere Barcode Typen erweitert werden. Die Restriktionen fur¨ EAN13 Barcodes sind die folgenden: • Der Barcode muss eine Lange¨ von 13 Zeichen aufweisen, um eine Verwechslung mit dem UPC Barcode ausschliessen zu konnen.¨ • EAN13 darf weder mit 0 noch mit 2 beginnen, da diese Art von Barcodes nur als Instore Codes verwendet werden durfen.¨ Diese, nicht registrierten, Barcodes sind nicht eindeutig und konnen¨ uber¨ den DataController nicht abgefragt werden. • Die Summe des Barcodes muss grosser¨ als 0 (null) sein. Diese Restriktion hat zwei Grunde:¨ einerseits konnen¨ Barcodes vom Typ Code39 Kontextinformationen wie 000000000000 kodieren, andererseits kann das Resultat einer Scanline 000000000000 betragen. Die Prufsummenpr¨ ufung¨ wurde¨ dieses Re- sultat falschlicherweise¨ als korrekten Barcode interpretieren.

Ereignisse nach der Dekodierung Nachdem der zyklische Dekodierungsablauf abgeschlossen ist, hangt¨ es vom weiteren Verwendungszweck ab, was mit der Kontextinformation anschliessend geschieht. Bei der Anwendung auf dem Mobiltelefon wird der dekodierte Barcode als String an die Menu Callback Funktion enterBarcode() ubergeben¨ und weiter verarbeitet. Bei der Verwendung auf einem Desktopsystem liefert das GUI das entsprechende Resultat.

~~ABCinfo 61~~

3.8 Desktop Version – Implementation Der ursprungliche¨ Auftrag beinhaltete die Ausarbeitung und Implementierung des Algorithmus zur Anwendung auf dem Mobilgerat.¨ Die Dekodierung und die eigentliche PyS60 Applikation fur¨ Symbian wurden getrennt entwickelt. Dies ermoglicht¨ einerseits die anderweitige Nutzung der Algorithmik, andererseits funktioniert die Mo- bilapplikation auch ohne Dekodierung. Dies ist ein weiterer Aspekt der die Erweiterbarkeit und die Modularitat¨ des Projekts unterstreichen. Um den Auftrag zu erfullen¨ wurde alles daran gesetzt, rechenaufwandige¨ Operationen durch andere Strategien zu ersetzen. Wie die Analyse der Mittel am Anfang dieser Dokumentation vermuten liess, lauft¨ die Dekodie- rung auf dem Mobilgerat¨ nur sehr langsam. Um die Algorithmik dennoch brauchbar verwenden zu konnen,¨ wurde in einer Projektsitzung zusammen mit dem betreuenden Dozenten, dass die Dekodierung in einer eigens implementierten Applikation fur¨ Desktop Systeme realisiert und fur¨ diese optimiert wird. Somit kann die Algo- rithmik fur¨ UNIX, Mac OS X und Windows Systeme ohne weitere Verarbeitung und fur¨ Symbian OS 9.x mit zusatzlicher¨ Quellenabfrage verwendet werden. Die Desktop Version von ABCInfo ist plattformunabhangig¨ und mit einem WX GUI [7] realisiert. Die Anwen- dung kann aber naturlich¨ auch direkt von der Konsole gestartet und ohne GUI verwendet werden. Die Testsuite (4) kann nur vom Terminal ausgefuhrt¨ werden.

~~3.8.1 Graﬁscher Modus~~

~~(a) gestartete Applikation (b) dekodierende Applikation~~

~~(c) Applikations Menu (d) Popup mit der dekodierten Kontextinfor- mation~~

~~Abbildung 28: Die Abbildungen zeigen einige Screenshots der GUI unter OS X.~~

~~ABCinfo 62~~

~~3.8.2 Konsolen Modus Die Desktop Applikation kann im Konsolenmodus mit den folgenden Paramtern gestartet werden: using UNIX workstation Usage: abcinfo [options]~~

Options: -h, --help show this help message and exit -i IMAGE, --input=IMAGE the input image to decode -q, --quiet don’t print status messages to stdout -d, --debug running in debug mode -v, --version print the current version information -t SCRIPT, --test=SCRIPT run a test script (test suite) -o FILE, --output=FILE the output file of the testsuite -a FLOAT, --adjust=FLOAT give a float to adjust factor 0.5 ... 1.5

~~Dekodierung eines Barcodes ohne zusatzliche¨ Informationsausgabe mit Speicherung der Kontextinformation in einer Datei: abcinfo -q -i~~

Anzeige der ausgelesenen Scanlines: abcinfo -d -i dieser Aufruf erstellt ein Debug Bild im temporaren¨ Verzeichnis des erkannten Betriebssystems (Windows: C:/Windows/Temp). Die Positionen der gesampleten Scanlines werden darin angezeigt. Die erste Scanline ist rot eingefarbt¨ und wird mit steigendem Index gelber. Dabei wird folgende Hilfsfunktion benutzt:

Listing 12: scalableColor def scalableColor(self , index , highestValue): 1 step = 255/highestValue 2 r = 255 3 g = 0 + int(index * s t e p + 0 . 5 ) 4 b = 0 5 return ( r , g , b ) 6 Die PIL zeichnet auf dem Desktop System das entsprechende Debug Bild. Durch mehrfaches Offnen¨ und Schliessen des Bildes, ist der Debug Mode rechenintensiv und dementsprechend langsam. Der Parameter -q uberlagert¨ den Parameter -d. Die Testsuite wird in Abschnitt (4) beschrieben.

~~ABCinfo 63~~

3.9 Zusatzinformationen zur Implementierung der evaluierten Konzepte Das Eclipse SDK dient als Entwicklungsumgebung. Als Eclipse Feature wird PyDev (Python Developement Environment) installiert. In Kombination mit Python 2.5 konnen¨ somit Python Applikationen implementiert und getestet werden. Diese lassen sich, unter Berucksichtigung¨ der PyS60-speziﬁschen Module, ebenso auf dem Mobilgerat¨ ausfuhren.¨ Mit dem S60 SDK wird zum Testing ohne Mobilgerat¨ ein Smartphone Emulator mitgeliefert. Dieser reicht aus um einfache Operationen zu testen. Leider ist er sehr unperformant und lauft¨ sehr instabil. Ebenfalls auf diesem Modulator lassen sich Symbian C++ Programme ausfuhren.¨ Die hierzu geeignete Ent- wicklungsumgebung ist Carbide C++. Mit dem erarbeiteten Entwurf lassen sich die im vorherigen Abschnitt beschriebenen Programmteile implementieren. Trotz sorgfaltiger¨ Planung beim Entwurf treten wahrend¨ der Implementierung immer wieder Ungewissheiten auf, die vorweg nicht in der Problemlosung¨ berucksichtigt¨ wurden. Um diese zu beseitigen, ist es teils notwendig den Entwurf anzupassen oder andere Ansatze¨ zu verfolgen. Wie in der Projektplanung beschrieben ist die Implementierung deswegen eine zyklische Phase, in der Testmodule angepasst, zusammengefugt¨ und verbessert werden.

3.9.1 Applikationsentwicklung Das grosste¨ Hindernis wahrend¨ der Entwicklung der Mobilapplikation ist die Realisierung eines eigenen Kame- ramoduls. Wie schon vielfach angesprochen und naher¨ erlautert,¨ existiert fur¨ PyS60 kein geeignetes Modul zur Bildaufnahme in der geforderten Qualitat.¨ Losungsansatz¨ Implementierung als C-Extension. Machbarkeit Die Komplexitat¨ von C++ fur¨ Symbian wurde schon aufgezeigt. Anfangs wurde versucht ein Kameramodul in C++ zu schreiben. Zur damaligen Zeit existierte allerdings die Autofokus Bibliothek von Nokia noch nicht. Im laufe des Fruhlings¨ hat Nokia die entsprechende Library freigegeben und Python hat kurz darauf ein Modul mit Viewfinder vorgestellt. Leider immernoch ohne Autofokus. Die zeitliche Begrenzung des Projekts verhindert eine Umsetzung von Viewfinder & Autofokus in C++. Losung¨ Wie erwahnt,¨ wird anstelle eines Kameramoduls ein Bildbrowser implementiert. Fur¨ die Bildaufnahme ist die native Kameraanwendung ausserhalb der Applikation zustandig.¨ Weitere Hemmnisse bei der Entwicklung der Anwendung entstehen dadurch, dass Python fur¨ S60 erst seit 2006 existiert. Probleme des Interpreters und Fehlimplementationen der Module werden laufend korrigiert. So hat PyS60 zur Zeit beispielsweise noch Probleme mit dem Wireless LAN. Der Verbindungsaufbau zu einem Access Point ist nur langsam und kann das Modul keinen Zugriff herstellen, muss die Anwendung fur¨ einen erneuten Verbindungsversuch neu gestartet werden. Solche Probleme sind den Entwicklern von Python fur¨ S60 bekannt und sollten in einer der kommenden PyS60 Versionen behoben worden sein. Ein guter Einstiegspunkt zum aktuellen Stand von PyS60 ist das offizielle Nokia Forum unter: http://discussion.forum.nokia.com/forum/forumdisplay.php?f=102 Ein weiteres interessantes Problem birgt die Verwendung von cElementTree. Bei der Implementation der Ap- plikation und dem Zusammenspiel der einzelnen Module kann folgendes beobachtet werden: Wenn eine Datenquelle abgefragt wird und die entsprechende Datei nicht in einer aktuellen Version im Cache vorhanden ist, wird sie laut Definition aus dem Internet heruntergeladen und im Zwischenspeicher abgelegt. Die Anwendung weiss zu diesem Zeitpunkt noch nicht, ob der Inhalt dieser XML Datei wirklich der gewunschte¨ ist, oder ob eine Anfrage auf eine inexistente (oder ungewunschte)¨ EAN gemacht wurde. Erst nachdem cEle- mentTree mit seinem XML Parser die Datei nach den entsprechenden Schlusselw¨ ortern¨ durchsucht, kann die Anwendung erkennen ob sich das Resultat der Datenquelle mit dem gewunschten¨ Datensatz deckt. Sollte dies nicht der Fall sein, wird dieser Misstand von der Programmlogik erkannt und entsprechend verarbeitet. Das Problem besteht nun darin, dass ein inkorrekter Datensatz im Ressourcenverzeichnis vorhanden ist, welcher geloscht¨ werden muss. Da aber cElementTree die Datei mit einer eigenen Instanz geladen hat muss diese zuerst

ABCinfo 64 zerstort¨ werden, um wieder frei auf die Datei zugreifen und sie loschen¨ zu konnen.¨ Jedoch bleibt auch nach dem Aufruf des entsprechenden Destruktors die Datei immernoch gelocked und kann nicht geloscht¨ werden. Erst bei einem kompletten Shutdown der Anwendung wird die Datei zur Veranderung¨ freigegeben. Um dieses Problem zu losen,¨ muss man sich genauer daruber¨ informieren warum die Datei immer noch gesperrt ist. Ein Workaround ware¨ es, den Dateinamen eines inkonsistenten Datensatzes in eine Struktur zu schreiben und beim nachsten¨ Neustart alle Eintrage¨ darin und deren Pfade zu loschen.¨ Dieser komplette Sachverhalt wurde in der aktuellen Version noch nicht vollstandig¨ geklart.¨

3.9.2 Algorithmusentwicklung 3er und 6er Problem Hauﬁg¨ werden Modulgruppen bei der Barcode Dekodierung als Zeichen 3’ oder Zeichen 6’ erkannt. Die- ’ ’ ses Phanomen¨ kann zur inkorrekten Validierung eines Barcodes fuhren.¨ Die Ursache des Problems liegt darin, dass ein hochfrequentes Signal oftmals 4er Modulgruppen beinhaltet. Diese entstehen durch irrelevante Umge- bungsinformationen einer Scanline. Die Dekodierung von falschen Zeichen fuhrt¨ dann zu Problemen, wenn die inkorrekten Zeichen eine hohere¨ Anzahl als die korrekten Zeichen aufweisen. Die Korrelationstabelle fugt¨ die Scanline Resultate dann zu einer falschen Kontextinformation zusammen. false True Ein weiteres Problem des Algorithmus ist die Erkennung eines korrekten Barcodes trotz inkorrekter Kontext- information. checkDigit() pruft¨ die Prufsumme¨ auf Korrektheit. Das Problem lasst¨ sich mit Octave [15], einem MATLAB Pendant, erklaren:¨ Beispiel 1 octave:1> mod(0,10) ans = 0 Obwohl keine Kontextinformation dekodiert werden konnte, stimmt die Checksumme. Durch die Sum- mierung (3.7.3) der Kontextinformation wird dieses Problem behoben. Ist diese Summe 0, ist keine In- formation vorhanden, folglich ist der Barcode False. Beispiel 2 octave:2> mod((7*1+6*3+1*1+0*3+2*1+2*3+6*1+0*3+0*1+0*3+0*1+0*3+0*1),10) ans = 0 Die Prufsummenpr¨ ufung¨ verlauft¨ erfolgreich. Der rechte Teil des Barcodes besteht jedoch nur aus Nullen, da die Korrelation uber¨ mehrere Scanlines nicht dekodierbare Zeichen miteinander verrechnet hat. Dieser Fall kann grundsatzlich¨ an beliebigen Stellen im Barcode auftreten und fuhrt¨ zu einer falschen True Deklaration des Barcodes.

~~ABCinfo 65~~

4 Optimierung / Testen 4.1 Einleitung Nachdem die Applikation den Status eines Prototyps hat, wird sie ausgiebig getestet und optimiert. Die Pro- grammierung und deren Stil werden uberarbeitet¨ und verbessert. Fur¨ den zyklischen Prozess der Applikati- onsoptimierung wird auch der Fachbegriff Refactoring benutzt. Dabei werden folgende Punkte in der Struktur verbessert: • Lesbarkeit • Ubersichtlichkeit¨ • Erweiterbarkeit • Redundanzvermeidung Dies bedeutet, dass beispielsweise nichtssagende Variablennamen angepasst werden (’Bad Smell’), oder dass lange Funktionsblocke¨ in weitere Methoden aufgeteilt werden. Jene tragen dann den Namen der Tatigkeit¨ der Methode.

4.2 Testen Das Testen der Anwendung auf Benutzereingaben und die diesbezugliche¨ Erweiterung und Optimierung der Funktionen mit Fehlerabfangmechanismen ist ein wesentlicher Teil des Testens der Applikation. Um eine moglichst¨ grosse Kompatibilitat¨ bezuglich¨ der Datenquellen zu gewahrleisten,¨ ist es notwendig zu untersuchen, welche Art von Ruckgabewert¨ eine XML Quelle ausgeben kann. Wird bei der serverseitigen API eine invalide Kontextinformation abgerufen, kann es sein, dass ein Server-404 Fehler zuruckgegeben¨ wird. In diesem Fall resultiert aus der Abfrage keine valide XML Datei. Diese Moglichkeit¨ muss beim Parsen der Daten berucksichtigt¨ und abgefangen werden. Andererseits kann bei einer Abfrage nach einem inexistenten Datensatz eine valide XML Datei zuruckgeliefert¨ werden, welche aber nicht nach dem entsprechenden Filtersatz geparsed werden kann, da die Datei hauptsachlich¨ Informationen zur Fehlerkonstellation beinhaltet. Auch dieser Fall wird von der Applikation erkannt und abgefangen. Kann gar keine Verbindung zur Datenquelle erfolgen, meldet Python dies der Anwendung, worauf diese gar keine Daten erhalt.¨ In allen Fallen¨ weisen Fehlermeldungen den Benutzer auf die misslungene Abfrage hin. Neben den Benutzereingaben wird die Funktionsweise der Dekodierung und der Algorithmik gestestet. Anhand von selbst entwickelten Unit-Tests (der ABCInfo Testsuite) wird die Quote der korrekt dekodierten Barcodes ermittelt. Dabei wird eine Datei mit folgender Struktur von Hand angelegt: ... "/path/to/barcode/26012007365.jpg","7610058205499" "/path/to/barcode/26012007366.jpg","7610058205499" "/path/to/barcode/26012007367.jpg","7610535000111" "/path/to/barcode/26012007369.jpg","7640811782717" ... Es konnen¨ soviele Eintrage¨ wie gewunscht¨ gemacht werden. Getrennt werden Sie durch ein ’Newline’. Der erste Parameter gibt den Pfad zum Testbild an, der zweite ubergibt¨ das erwartete Resultat (also den korrekten Barcode). Der dekodierte Ist-Wert wird anschliessend mit dem Soll-Wert der Konﬁgurationsdatei auf folgende Eigenschaften verglichen: • Stimmen Soll- und Ist-Wert uberein?¨ • Stimmt der Ist-Wert wirklich oder wurde ein falscher Barcode als richtig erkannt? • Wie hoch ist die Erkennungsquote bei einer nicht vollstandigen¨ Dekodierung des Soll-Wertes?

~~ABCinfo 66~~

~~Die Testsuite wird wie folgt aufgerufen: abcinfo -t -o~~

~~Report.log enthalt¨ die Resultate der Prufung:¨ /path/to/barcode/evian.png;3068320084602;3068320084602;100.0;0.28;1 (1) (2) (3) (4) (5) (6)~~

~~1. Das getestete Bild 2. Ist-Wert 3. Soll-Wert 4. Prozentuelle Dekodierungsrate 5. CPU-Zeit in Sekunden fur¨ den Dekodierungsprozess 6. der AVG-Faktor, welcher zur Dekodierung eingesetzt wurde~~

Der Dekodieralgorithmus wurde mit 120 unterschiedlichen Testbildern aus verschiedenen Beleuchtungsszenen und Winkeln getestet. Das Resultat der Prufung:¨ TOTAL: 120 TRUE (true): 78.6324786325% (true barcodes detected as true ) TRUE (false): 10.2564102564% (false barcodes detected as true ) FALSE: 11.1111111111% (not detected barcode) AVG/BARCODE (time): 1.18365416447 seconds

~~(a) Dekodierfahigkeit¨~~

~~Abbildung 29: Mittels eines Kuchendiagramms wird die Dekodierfahigkeit¨ visualisiert, 8 von 10 Barcodes konnen¨ korrekt dekodiert werden.~~

Um den Rotationswinkel zu testen wird ein computergenerierter Barcode auf 360 verschiedene Gradwinkel getestet. Der Algorithmus kann den Barcode im Bereich von +10° bis -10° zu seiner waagrechten Ruheposition erkennen. Ob dabei 20% oder 30% der Bildhohe¨ gepruft¨ wird verandert¨ das Resultat nicht. TOTAL: 360 TRUE (true): 21.1111111111% (true barcodes detected as true ) TRUE (false): 5.83333333333% (false barcodes detected as true ) FALSE: 73.0555555556% (not detected barcode) AVG/BARCODE (time): 4.1412597351 seconds

~~ABCinfo 67~~

Da nicht dekodierbare Barcodes die Dekodierzeit in die Hohe¨ treiben und uber¨ 120 Barcodes trotzdem nur 1.1 Sekunden pro Barcode zur Erkennung notig¨ sind, kann der Algorithmus unter Berucksichtigung¨ der sprachs- peziﬁschen Eigenschaften, als durchaus performant bezeichnet werden. Ein qualitativ gutes Eingangsbild kann sogar problemlos in 0.1 – 0.2 Sekunden dekodiert werden. 8 von 10 Bildern konnen¨ dekodiert werden, ein Barcode wird nicht erkannt, einer wird nicht korrekt dekodiert und falscherlicherweise¨ als richtig erkannt.

~~ABCinfo 68~~

~~4.2.1 Testbilder Testbilder, dekodierbar Folgende Bilder sind problemlos dekodierbar.~~

~~(a) (b) (c) (d)~~

~~(e) (f) (g) (h)~~

~~(i) (j) (k) (l)~~

~~Abbildung 30: Abbildungen von dekodierbaren Barcodes~~

~~ABCinfo 69~~

~~Testbilder, nicht dekodierbar Aufgrund mangelnder Qualitat¨ der Aufnahme oder des Drucks selbst, lassen sich folgende Bilder nicht dekodieren.~~

~~(a) (b) (c) (d)~~

~~(e) (f) (g) (h)~~

~~(i) (j) (k) (l)~~

~~Abbildung 31: Abbildungen von nicht dekodierbaren Barcodes~~

~~ABCinfo 70~~

~~Testbilder, unerwartet dekodierbar Folgende Bilder sind entgegen den Erwartungen trotzdem dekodierbar.~~

~~(a) (b) (c) (d)~~

~~(e) (f) (g) (h)~~

~~(i) (j) (k) (l)~~

~~Abbildung 32: Abbildungen von unerwartet dekodierbaren Barcodes~~

~~ABCinfo 71~~

Testbilder, unerwartet nicht dekodierbar Folgende Bilder sind entgegen den Erwartungen nicht dekodierbar. Warum optisch gute Aufnahmen trotzdem keine korrekten Berechnungen zulassen, kann oft auf die Kombination unterschiedlicher Faktoren zuruckgef¨ uhrt¨ werden.

~~(a) (b) (c)~~

~~(d) (e) (f)~~

~~Abbildung 33: Abbildungen von unerwartet, nicht dekodierbaren Barcodes~~

~~ABCinfo 72~~

4.3 Applikationsoptimierung Die Geschwindigkeitsoptimierung ist ein zentraler Punkt der kompletten Architektur. Einerseits ist die Verwen- dung und Umsetzung der ausgewahlten¨ Konzepte verantwortlich dafur,¨ wie schnell die Dekodierung der Bilder und die Arbeit der Anwendung sein konnen.¨ Andererseits zeigt Python und Python fur¨ S60 wie sehr die Pro- grammperformance von der verwendeten Interpreter Version abhangig¨ ist. Alleine der Sprung von PyS60 1.3.21 auf 1.3.22 lasst¨ die Anwendung auf dem Mobilgerat,¨ bei gleich bleibendem Code, in der halben Zeit aufstarten. Dies zeigt, dass die gewahlten¨ Konzepte die richtigen sind und die Implementierung efﬁzient umgesetzt wurde.

4.4 Scriptsprache vs. Algorithmik Nachdem die Algorithmik nach bestem Wissen optimiert wurde, besteht immernoch ein zentrales ’Problem’: sie ist in einer Interpretersprache geschrieben und deshalb nicht besonders performant. In der Desktop Vari- ante tragt¨ dieser Sachverhalt kaum zum Unwohl des Anwenders bei. Das Mobilgerat¨ mit seinem auf Symbian basierenden PyS60 jedoch, bremst wo es nur kann. Der einzige Weg dieses Problem in der mobilen Deko- dierungsvariante zu umgehen, ware¨ die Reimplementierung der Algorithmik in einer anderen Sprache. Wie in diesem Dokument bereits mehrfach erwahnt¨ wurde¨ es sich anbieten, die Dekodierung in C++ auszulagern und uber¨ eine Python C-Extension zu laden. Das Vorhaben scheitert fur¨ dieses Projekt alleine am Aufwand und nicht an der Realisierbarkeit.

Prakompilierung¨ CPU-lastiger Abschnitte Ein weiterer Ansatz die Algorithmik zu beschleunigen ist der Einsatz eines sogenannten Just-in-Time Compilers (JIT). Dieser verbessert die Performance von vorliegendem Bytecode, indem er ihn bei Bedarf zur Laufzeit in nativen Maschinen-Code ubersetzt.¨ Dieser kann vom Prozessor direkt verarbeitet werden. Solche JIT Compiler existieren fur¨ den TI Prozessor des Nokia N93 leider nicht. Somit bleibt der Fokus der Optimierung bei der Desktop Variante. Es existieren hauptsachlich¨ zwei Varianten von JIT Compilern fur¨ Python: • Psyco [16] • PyPy Bei naherer¨ Betrachtung erschliesst sich eine weitere Restriktion: nur x86 Prozessoren konnen¨ zur JIT Kompi- lierung genutzt werden. Eine einfache und Entwicklerfreundliche Version eines JIT Compilers ist Psyco. Das Paket hierzu kann direkt in die vorhandene Python Struktur installiert werden und in der main.py Datei uber¨ den Befehl import psyco importiert werden. Der anschliessende Aufruf von psyco.full() weist Psyco an, alle moglichen¨ Funktionen in Maschinencode zu ubersetzen.¨ Laut Entwickler von Psyco kann eine Performancever- besserung von Faktor 100 eintreten und das Programm somit in der Geschwindigkeit einer in C++ geschriebenen Applikation ausgefuhrt¨ werden. Hauptsachlich¨ bei systemnahen, algorithmischen Operationen kann Psyco viel erreichen. In der Desktop Variante fur¨ x86 Prozessoren (UNIX und Windows) kann eine Barcodedekodierung um den Faktor 4 beschleunigt werden. Anstatt wie bisher 4 Sekunden, benotigt¨ die Dekodierung nur noch eine Sekunde. Psyco wird in der Anwendung einprogrammiert und direkt mit dem Installer ausgeliefert. Es wird keine zusatzliche¨ Installation benotigt.¨

~~ABCinfo 73~~

~~5 Ergebnisse~~

Ein grosser Ehrgeiz und viel zeitlicher Aufwand stecken in dem Projekt ABCInfo. Viel Schweiss und Herz- blut wurden in der Zeit der Entwicklung vergossen. Zuruckblickend¨ sind wir, das Projektteam, zufrieden mit den Ergebnissen. Die Struktur und Architektur der einzelnen Elemente wurde sorgfaltig¨ geplant. Das Resultat davon ist die problemlose Erweiterbarkeit, Anpassung und Wiederverwendung von Programmcode. Wir konnten eine mobile Anwendung schaffen, die uber¨ die Anforderungen hinaus eine Abfrage multipler Datenquellen ermoglicht.¨ Die Investitionen in das Projekt zeigen sich ebenfalls in der Kooperation mit externen Entwick- lern und Projekten. E-Nummern konnen¨ zusatzlich¨ abgefragt werden. Weitere Applikationsfeatures erganzen¨ die Mobilanwendung. Das Herzstuck¨ der Anwendung, die eigens entwickelte Algorithmik zur Dekodierung von Barcodes, konnte bestmoglichst¨ realisiert werden. In einer, fur¨ einen Prototypen sehr kurzen Rechenzeit, konnen¨ Barcodes vom Typ EAN13 dekodiert werden. Auch hier ist der komplette Aufbau derart gehalten, dass weitere Barcodes problemlos implementiert werden konnen.¨ Nachdem sich deﬁnitiv bestatigt¨ hat, dass die De- kodierung auf dem Mobilgerat¨ schlichtweg zu langsam ausgefuhrt¨ wird, entschieden wir uns kurzerhand den Algorithmus in eine eigene Anwendung auszulagern. Diese ist plattformunabhangig¨ nutzbar und demonstriert die Erkennung von Barcodes.

~~ABCinfo 74~~

6 Ausblick 6.1 Erweiterungen der Algorithmik Implementation weiterer Barcodes ABCInfo ist zur Zeit auf die Erkennung von EAN13 Barcodes ausgelegt, kann aber problemlos auf EAN8 und Code39 erweitert werden. Die Struktur der Dekodierung lasst¨ es muhelos¨ zu zusatzliche,¨ lineare Barcodes zu implementieren.

Extraktion des Barcodes aus dem Bild Mittels der Anwendung von Canny- und Hough-Operationen, liesse sich der Barcode in einem Bild erkennen und isolieren. Dies wurde¨ die Dekodierung in Geschwindigkeit und Zuverlassigkeit¨ erheblich optimieren. Um eine solche Extraktion zu realisieren, mussten¨ die entsprechenden Algorithmiken dazu in C Klassen ausgelagert werden, da die Berechnung sehr rechenintensiv ist.

Detektion der Gradlage des Barcodes im Bild Durch eine Hough-Objekterkennung konnte¨ man die Gradlage eines Barcodes erkennen und auskorrigieren. Auch dies wurde¨ die Zuverlassigkeit¨ der Dekodierung verbessern und den Benutzer bei der Bildaufnahme ent- lasten.

Ruckw¨ artsdekodierung¨ Wenn eine Gradlagenkorrektur implementiert wird, kann es passieren, dass ein Barcode um 180° zu seiner Normalausrichtung gedreht vorliegt. Dies wurde¨ einem Barcode entsprechen, welcher auf dem Kopf“ steht. ” Anhand der Paritatsanalyse¨ konnte¨ man eine Ruckw¨ artsdekodierug¨ implementieren.

6.2 Erweiterungen der Applikation Die Mobilapplikation ist bestmoglichst¨ auf Erweiterungen und Erganzungen¨ ausgelegt. Da alle GUI Funktionen in einer Klasse gekapselt sind, ist die Portierung auf ein anderes User Interface in kurzer Zeit machbar. Noch einfacher ist das Hinzufugen¨ zusatzlicher¨ Datenquellen. Die XML Struktur der Anwendung ermoglicht¨ es dem Benutzer weitere Quellen in einer Konﬁgurationsdatei anzulegen. Auch lokale Datenquellen konnen¨ auf dem Mobilgerat¨ gespeichert und abgefragt werden (Wrapping). Anhand der Kontextinformation des Dekodierpro- zesses ware¨ es moglich¨ auf den Typ des Produkts zu schliessen und dem Benutzer nur gewisse, dem Typen entsprechende Datenquellen, zur Auswahl zu stellen. Durch den Einsatz von cElementTree und das Auslesen und Anlegen von XML Baumen¨ ware¨ es, mit einer entsprechenden Funktion, auch moglich¨ Programmeinstellungen direkt uber¨ das GUI zu andern,¨ ohne die XML Datei von Hand umzuschreiben. Weiterhin konnten¨ automatische Programmupdates problemlos uber¨ das Internet gedownloaded und die Anwendung aktualisiert werden.

~~ABCinfo 75~~

~~7 Inhalt der beiliegenden CD~~

~~Abbildung 34: CD Menu~~

~~ABCinfo 76~~

~~8 Glossar~~

API Application Programming Interface, engl. fur¨ Programmierschnittstelle Binarisierung Trennung eines Signals in binare¨ Werte, meisst 0 (null) und 1 oder 0 (null) und 255. Computer Vision Der englische Begriff fur¨ die Bildverarbeitung. Nicht zu verwechseln mit der Bildbearbei- tung. CPU Central Processing Unit. Sie ist ist der Hauptprozessor und die Zentrale eines Computersystems. EBV Elektronische Bildverarbeitung. Sie nutzt die Mittel der Signalverarbeitung zur Aufbereitung und Spei- cherung von visuellen Informationen. Gantt Diagramm Ein Gantt-Diagramm oder Balkenplan ist ein nach dem Berater Henry L. Gantt (1861–1919) benanntes Instrument des Projektmanagements, das die zeitliche Abfolge von Aktivitaten¨ grafisch in Form von Balken auf einer Zeitachse darstellt. Im Unterschied zum Netzplan ist die Dauer der Aktivitaten¨ im Gantt-Diagramm deutlich sichtbar. Ein Nachteil des Gantt-Diagramms ist, dass die Abhangigkeiten¨ zwischen Aktivitaten¨ nur eingeschrankt¨ darstellbar sind. Dies ist wiederum die Starke¨ des Netzplans. GUI Graphical User Interface. Es stellt dem Benutzer eine grafische Schnittstelle zu der Funktionalitat¨ einer Applikation zur Verfugung.¨ Kompilierung Ein Prozess der Programmquellen von einer bestimmten Sprache in Byte- oder Maschinencode zur Ausfuhrung¨ auf der CPU umwandelt. PHP ’PHP: Hypertext Preprocessor’, ursprunglich¨ ’Personal Home Page Tools’ ist eine Skriptsprache mit einer an C bzw. C++ angelehnten Syntax, die hauptsachlich¨ zur Erstellung von dynamischen Webseiten oder Webanwendungen verwendet wird. PHP ist Open-Source-Software. PIL Python Imaging Library. Sie stellt Bildverarbeitungsfunktionen zur Verfugung¨ und unterstutzt¨ viele unterschiedliche Bildformate. Pixel Wird aus den Bezeichnungen ’Picture’ und ’Element’ abgekurzt.¨ Ein Pixel bezeichnet die kleinste Einheit einer digitalen Rastergrafik. Viewfinder Der ’Sicht-Finder’ entspricht dem Live-Bild, welches eine Kamerapplikation auf dem Display wie- dergibt. Es entspricht keiner Bildaufnahme, sondern erleichtert die Selektierung des gewunschten¨ Bildmo- tivs. Eine effektive Bildaufnahme entspricht dabei der Speicherung des Live-Bilds zu einem gewunschten¨ Zeitpunkt (allerdings in einer besseren Bildqualitat).¨ UML Unified Modelling Language. Sie ist eine Sprache zur Modellierung von Software und anderen Systemen. UMTS Universal Mobile Telecommunications System. Dies ist der Mobilfunkstandard der dritten Generation (3G) und bietet hohere¨ Datenubertragungsraten¨ als der GSM-Standard. WLAN Wireless Local Area Network. Dies ist ein Netzwerk, welches mit Funkwellen realisiert ist. XML Extensible Markup Language. Sie dient zur Darstellung hierarchisch strukturierter Daten in Form von Textdateien.

~~ABCinfo 77~~

~~Tabellenverzeichnis~~

1 EAN Zeichensatze¨ in Modulbreiten ...... 21 2 EAN Zeichensatze¨ in binarer¨ Form...... 22 3 Die EAN Hilfszeichen ...... 22 4 EAN Paritatstabelle¨ ...... 22 5 EAN Landercode¨ ...... 23 6 Zusammenfassung zum Aufbau des EAN13 Barcodes ...... 23 7 XML Parser Benchmark ...... 38

~~ABCinfo 78~~

~~Abbildungsverzeichnis~~

1 Gantt-Diagramm Analysephase...... 8 2 Gantt-Diagramm Entwurfsphase...... 9 3 Gantt-Diagramm Entwicklungsphase...... 10 4 Gantt-Diagramm Optimierungs- und Testphase ...... 11 5 Gantt-Diagramm Dokumentationsphase ...... 12 6 Applikationsplattform - Nokia N93...... 15 7 OMAP High-Performance Prozessor...... 16 8 Benchmark; * 1.5GHz, 1.25GB RAM; ** Dual-Core2 1.83GHz, 2GB RAM; *** das Psyco JIT Modul ist ein Just-in-Time Compiler fur¨ Python, welcher die Codeausfuhrung¨ 4-100 mal beschleunigt...... 17 9 Abbildung 2.2.1 zeigt einen EAN13 und 2.2.1 eine EAN8 Barcode...... 20 10 Visualisierung der Ziffer 0 in den verschiedenen Zeichensatze,¨ Zeichensatz A (oben), Zeichen- satz B (mitte) und Zeichensatz C (unten)...... 21 11 Abbildung 11(a) zeigt einen QR Code mit der Kontextinformation ’ABCinfo’ , Abbildung 11(b) zeigt eine Fastfood Verpackung...... 25 12 Abbildung 12(a) zeigt einen Aztec Code mit der Kontextinformation ’ABCinfo’...... 25 13 In den Bilder 13(a), 13(b) und 13(c) werden einige Problematiken bezuglich¨ des Eingangsbildes visualisiert...... 26 14 Die Abbildungen zeigen mogliche¨ Ausgangsbilder (links) Canny Kantenhervorhebung und (rechts) Canny mit nachfolgender Non maximum Suppression...... 30 15 Die Abbildungen zeigen ein mogliches¨ Eingangsbild (links) und (rechts) das Signal der Scanline des Eingangsbildes. Deutlich wird die Problematik der Uberf¨ uhrung,¨ respektiv Quantiﬁzierung, eines Signals von der Analogen in die digitale Welt...... 31 16 Visualisierung der drei Strategien zur Entnahme von Scanlines...... 32 17 MVC-Architektur als UML-Sequenzdiagramm ...... 33 18 Python Packagestruktur ...... 34 19 Package Ubersicht¨ ABCInfo ...... 44 20 Klassen Ubersicht¨ ...... 47 21 Sequenzdiagramm ...... 49 22 Auszug aus dem readme von barcr...... 51 23 Flussdiagramm Algorithmik ...... 52 24 Der Dekoder kann grundsatzlich¨ in drei Hauptgruppen unterteilt werden: die Vorverarbeitung (Praprozess),¨ der Hauptverarbeitung (Prozess) und Validierung (Validation)...... 53 25 variable Schwellwertanpassung einer Scanline ...... 54 26 Haupt Prozess, die Dekodierung ...... 56 27 Validierung ...... 59 28 Die Abbildungen zeigen einige Screenshots der GUI unter OS X...... 61 29 Mittels eines Kuchendiagramms wird die Dekodierfahigkeit¨ visualisiert, 8 von 10 Barcodes konnen¨ korrekt dekodiert werden...... 66 30 Abbildungen von dekodierbaren Barcodes ...... 68 31 Abbildungen von nicht dekodierbaren Barcodes ...... 69 32 Abbildungen von unerwartet dekodierbaren Barcodes ...... 70 33 Abbildungen von unerwartet, nicht dekodierbaren Barcodes ...... 71 34 CD Menu ...... 75

~~ABCinfo 79~~

~~Listings~~

1 Codestrukturierung mit C++ ...... 13 2 Codestrukturierung mit Python...... 13 3 Uikludges.cpp...... 35 4 Uikludges.cpp (2)...... 35 5 Uikludges.cpp (3)...... 36 6 Ein XML-Beispiel ...... 37 7 XML-Beispiel Amazon...... 45 8 Settings application.xml ...... 45 9 Settings data.xml...... 46 10 Settings enumber.xml...... 46 11 checkBarcode...... 59 12 scalableColor...... 62

ABCinfo Stichwortverzeichnis Abstract,2 CCD Scanner, 26 Analyse und Konzeption, 13 Laserscanner, 26 Barcodes, 19 Lesestift, 25 Speziﬁkation, 19 Typen Methodenanalyse, 19 Aztec Code, 24 Mittelanalyse, 13 Code39, 23 Komplexitat,¨ 13 DataMatrix, 24 Performance, 13 EAN, 19 Python, 13 MatrixCode, 24 Applikationskonzepte, 33 MaxiCode, 24 Bildaufnahme, 34 PDF417, 24 C++ Extension, 35 QR, 24 Caching ShotCode, 25 Caching, 37 Stapelcode, 24 MVC, 33 UPC, 23 Packaging, 34 Parsing Caching, 42 Parsing, 37 CD, 75 Wrapper, 35 cElementTree, 45 Wrapping, 35 CV XML, 37 Globale Operationen Applikationsoptimierung, 72 Scanline Sampling, 31 psyco, 72 Lokale Verfahren Canny, 29 Barcode Filter, 29 Begriffe, 20 Filtermatrix, 29 Balken, 20 Hotspot, 29 Barcode, 21 Hough, 30 Hilfszeichen, 21 Kantenhervorhebung, 29 Lucke,¨ 20 Punktoperationen Modul, 20 Grauwertkonvertierung, 28 Modulgruppe, 21 Histogrammanalyse, 28 Zeichen, 20 Schwellwertbildung, 28 Zeichensatz, 21 Threshold, 28 Dekoder Praprozess,¨ 52 Dokumentation, 75 Prozess, 56 Doxygen, 75 Validierung, 59 Voraussetzungen, 51 E-Nummer, 46 EAN Ehrlichkeitserklarung,¨ 83 Aufbau, 20 Einleitung, 6 Hilfszeichen, 22 Auftrag, 6 Paritat,¨ 22 Batoo, 7 Prufsumme,¨ 59 CodeCheck, 7 Zeichensatze,¨ 21 Projektplanung, 8 Geschichte, 19 Analyse, 8 Kodierung, 23 Entwicklung, 10 Lesegerate,¨ 25 Entwurf, 9 Optimierung, 11

~~80 81~~

Testen, 11 Symbian ReadBarC ReadBarJ,7 sis, 36 Entwurf Einleitung, 39 Testbilder, 68 Features, 39 Testen, 65 Entscheidungen, 40 Testsuite, 65 Applikationskonzepte, 41 Aufbau, 65, 66 Canny, 40 Evaluierung, 66 Grauwertkonvertierung, 40 Report, 66 Hough, 40 Titelseite, 1 Scanline Samping, 40 Vorwort, 5 Glossar, 76 Grauwertkonvertierung, 40 XML, 37 GUI Version, 61 Beispiel, 37 Parser Implementierung Benchmark, 37 C-Extension, 63 Carbide, 63 Eclipse, 63 Emulator, 63 PyDev, 63 Python, 63 Installer, 75

~~Konsolen Version, 62~~

~~Modulrestauration, 41~~

~~Nokia N93, 15 Absturz, 18 Benchmark, 17 CPU, 15 Crash, 18 Eigenschaften, 15 Symbian, 15 S60 Python S60, 17 Symbian, 15~~

~~Package, 44 Parsing, 42 Plakat, 75~~

~~Quelltext, 75~~

~~Scanline Entscheidung, 40 Interpolation, 41 Sampling, 31 Beispiele, 31 Varianten, 31~~

~~ABCinfo 82~~

~~Literatur~~

[1] barcodeisland.com. http://www.barcodeisland.com/. [2] barcr, upc barcode reader. https://sourceforge.net/projects/barcr-reader/. [3] Benchmarking, furryland.org. http://furryland.org/˜mikec/bench/. [4] Benchmarking, twistedmatrix.com. http://www.twistedmatrix.com/users/glyph/rant/ python-vs-java.html. [5] celementtree. http://effbot.org/zone/celementtree.htm. [6] celementtree. http://effbot.org/zone/celementtree.htm. [7] Das wxwidgets projekt. http://wxwidgets.org/. [8] Gs1. http://www.gs1.org/productssolutions/barcodes/support/prefix_list.html. [9] John a. webb: Readbarc. http://sourceforge.net/projects/readbarc/. [10] kaywa.com. http://qrcode.kaywa.com/. [11] Mvc, codeproject.com. http://www.codeproject.com/aspnet/ModelViewController/ image009.jpg. [12] netzmafia.de. http://www.netzmafia.de/skripten/modem/codes.html. [13] Nokia n93, nokia.ch. http://www.nokia.ch/A4334238. [14] Nokia opensource: Python for s60. http://opensource.nokia.com/projects/pythonfors60/. [15] Octave, a high-level language, primarily intended for numerical computations. http://www.gnu.org/ software/octave/. [16] Psyco jit compiler. http://psyco.sourceforge.net/. [17] Pys60 extensions. http://wiki.opensource.nokia.com/projects/PyS60_creating_ extensions. [18] Python forum. http://discussion.forum.nokia.com/forum/forumdisplay.php?f=102. [19] Python image library (pil). http://www.pythonware.com/products/pil/. [20] Python s60. http://wiki.opensource.nokia.com/projects/PyS60_python_modules. [21] Robert adelmann, eth zuerich: Batoo. http://people.inf.ethz.ch/adelmanr/batoo/. [22] Roman bleichenbacher, codecheck. http://www.codecheck.ch. [23] shotcode.com. http://www.cl.cam.ac.uk/research/srg/netos/uid/spotcode.html. [24] taltech.com. http://www.taltech.com/TALtech_web/resources/intro_to_bc/bcsymbol.htm. [25] Wikipedia. http://de.wikipedia.org/wiki/Barcode. [26] Wikipedia. http://de.wikipedia.org/wiki/RFID. [27] Wikipedia. http://de.wikipedia.org/wiki/Bildverarbeitung. [28] Wikipedia. http://de.wikipedia.org/wiki/Python_(Programmiersprache). [29] Wikipedia, mvc. http://de.wikipedia.org/wiki/Model_View_Controller. [30] Wikipedia, nokia nseries. http://de.wikipedia.org/wiki/Nokia_NSeries. [31] Fachkunde Industrieelektronik und Informationstechnik, ISBN: 9783808532485, volume 8. Europa Lehrmittel, 2003. [32] Gs1 spezifikation, kapitel 5.1. http://www.gs1.ch/Portals/3/2publish/001/1133/Page/5-1% 20v7-1.pdf, 2006. [33] Gs1 spezifikation, kapitel 5.4. http://www.gs1.ch/Portals/3/2publish/001/1133/Page/5-4% 20v7-1.pdf, 2006. [34] J. Adair. Location, tracking, and interpreting ean-13 bar code waveforms in a two-dimensional video stream. [35] I. M. Author. Some related article I wrote. Some Fine Journal, 99(7):1–100, January 1999. [36] W. Burger. Digitale Bildverarbeitung, ISBN: 9783540214656. Springer-Verlag Berlin, 2005. [37] D. Chai and F. Hock. Locating and decoding ean-13 barcodes from images captured by digital cameras. Edith Cowan University, Perth, Australia, 2005. [38] A. N. Expert. A Book He Wrote. Verlag Europa Lehrmittel, Erewhon, NC, 1999. [39] F. J. Johan Bylund. Visual barcode reading, 12 2005. [40] J. K. B. Kristin L. Granlund, Ernesto Staroswiecki. Visual code marker detection. [41] B. G. Michael Rohs. Using camera-equipped mobile phones for interacting with real-world objects. Institute for Pervasive Computing, Department of Computer Science, ETH Zurich, [email protected]. [42] C. F. Robert Adelmann, Marc Langheinrich. Toolkit for bar code recognition and resolving on camera phones – jump starting the internet of things. Institute for Pervasive Computing, ETH Zurich. [43] M. Sezgin. Survey over image thresholding techniques and quantitative performance evaluation. Journal of Electronic Imaging, 13, 2004. [44] P. Sundstrom.¨ Bar code reader for surface mounting systems, 2001. [45] T. Wittman. Lost in the supermarket: Decoding blurry barcodes. SIAM News, 37(7), September 2004.

~~ABCinfo 83~~

~~Ehrlichkeitserklarung¨~~

~~Hiermit bestatigen¨ die unterzeichnenden Autoren dieses Berichts, dass alle nicht klar gekennzeichneten Stellen von ihnen selbst erarbeitet und verfasst wurden.~~

~~...... Ort, Datum: Pascal Bender~~

~~...... Ort, Datum: Philippe O. Wagner~~

~~ABCinfo~~