automatisierte Straßenschilderkennung

Ich hatte als Passauer Gelegenheit, den Abschlussvortrag zu dieser Arbeit zu besuchen. Mir hat das Konzept gut gefallen, auch wenn die Implementierung natürlich noch raue Ecken hat. Es wäre prima, wenn man sich mit Bildverarbeitung das Mapping etwas erleichtern könnte.

Auto hab ich aber leider auch nicht - ist denn keiner experimentierfreudig hier? 😉

Funktioniert bereits bei Audi...
Schön, wenn es ja auch bei OSM landet.
Ich hoffe, keiner hat´s patentiert.

Ich habe mir mal meine Nikon Aw100 http://www.nikon.de/de_DE/product/digit … lpix-aw100 auf ein Fahrrad geschraubt und bin mal ein bisschen rumgefahren. Die Kamera hat einen GPS-Empfänger und kann auch den Weg mitloggen.

Leider habe ich es nicht geschafft, mit meinem Java Halbwissen 😉, den Tracker zum Laufen zu bringen.
In der schriftlichen Arbeit gibt es keine brauchbare Installationsanleitung.

Vielleicht kann da jemand mit mehr Wissen was basteln und die zusätzlichen Bibliotheken gleich mit einbinden, ähnlich wie bei JOSM.
So das man als Laie nur noch die *.jar Datei starten braucht.

Ich kann mich der Bitte nur anschließen.
Es wäre eine sehr brauchbare Erweiterung.
Lieber Peda,
wie ist´es mit dem Verfasser der Arbeit?
Will er noch weiter daran basteln?

Viele Grüße,
Marek

derandi wrote:

Leider habe ich es nicht geschafft, mit meinem Java Halbwissen 😉, den Tracker zum Laufen zu bringen.
In der schriftlichen Arbeit gibt es keine brauchbare Installationsanleitung.

Vielleicht kann da jemand mit mehr Wissen was basteln und die zusätzlichen Bibliotheken gleich mit einbinden, ähnlich wie bei JOSM.
So das man als Laie nur noch die *.jar Datei starten braucht.

Der java-Teil (der nur mit Java 7 läuft) greift dummerweise auf native, betriebssystem-abhängige Binaries aus OpenCV zurück. Gebundelt in der Executable Jar sind die JavaCV-Teile, allerdings fehlen dann noch ein paar Abhängigkeiten auf der folgenden Seite: http://code.google.com/p/javacv/ (-> Java 7 + OpenCV).

Melde mich, wenn das hier läuft, kann nichts versprechen...

Frage: Gibt es irgendwo Folien zum Vortrag oder ein Testvideo mit passenden Einstellungen? Mit meinem eigenen Video hat es leider nicht funktioniert, kein Schild wurde erkannt.

marek kleciak wrote:

Funktioniert bereits bei Audi...
Schön, wenn es ja auch bei OSM landet.
Ich hoffe, keiner hat´s patentiert.

Das juckt uns bei Open-Projekten überhaupt nicht 😉 Zudem müsste sich ein Patent auf eine bestimmte Methode beziehen - erfinde ich selbst eine andere Möglichkeit um das selbe Ergebnis zu bekommen, dürfte es nicht mehr unter das Patent fallen.
Eine "Schilderkennung" ist zudem ein normalers OCR bzw. eher Mustererkennung - ich glaube nich mal, dass man sowas überhaupt patentieren kann. Wäre so, als würde man die Berechnung einer Fläche - aus Breite und Höhe - patentieren wollen 😄

Das ist absolut richtig AlphaRay.
Vielmehr zeigt es den "Profis" dass OSM Themen aufnimmt, die als "professionell" galten.
Mich freut es sehr.

Noch eine Frage nach Passau: gab es Überlegungen, mit OpenCV4Android die gesamte Verarbeitung auf dem smartphone laufen zu lassen ohne erst ein sehr großes Video aufzunehmen und dies später auf dem eigenen Rechner zu analysieren? Dies wird ganz sicher nicht mit 25fps in Echtzeit laufen-mein Rechner hat das auch nicht geschafft. Vielleicht reicht 1 bis 2 fps voll und ganz aus für den Task?
Auf Google play finden ein paar opencv prototypen (eher Spielereien) da kam mir dieser Gedanke.

couchmapper wrote:

Noch eine Frage nach Passau: gab es Überlegungen, mit OpenCV4Android die gesamte Verarbeitung auf dem smartphone laufen zu lassen ohne erst ein sehr großes Video aufzunehmen und dies später auf dem eigenen Rechner zu analysieren? Dies wird ganz sicher nicht mit 25fps in Echtzeit laufen-mein Rechner hat das auch nicht geschafft. Vielleicht reicht 1 bis 2 fps voll und ganz aus für den Task?
Auf Google play finden ein paar opencv prototypen (eher Spielereien) da kam mir dieser Gedanke.

Man sollte sich immer über die Qualtität im klaren sein. Bei einer Geschwindigkeit von 50 km pro Stunde kann es schon schwer werden die Nebenstraßen überhaupt auf dem Foto zu haben. Das kann man zum Beispiel bei Google streetview sehr schön sehen, wie gewisse Details einfach in der Tiefe nicht vorhanden sind, weil das Foto an einer anderen Stelle gemacht wurden.

marek kleciak wrote:

wie ist´es mit dem Verfasser der Arbeit? Will er noch weiter daran basteln?

Wie im Ausgangspost geschrieben: Nein, will sich auf sein Studium konzentrieren.
Sourcen sind aber zumindest da, und ich werd mich mal erkundigen ob er Schreibzugriff erteilt, Pull-Requests bearbeiten würde oder ob man andernfalls besser forken sollte.

couchmapper wrote:

Frage: Gibt es irgendwo Folien zum Vortrag oder ein Testvideo mit passenden Einstellungen? Mit meinem eigenen Video hat es leider nicht funktioniert, kein Schild wurde erkannt.

Weder noch. Ich frag mal ob er den noch online stellt. Die Folien waren nämlich wirklich super 🙂
Zu den Einstellungen erkläre ich vielleicht doch mal noch "kurz und grob" wie das funktioniert und was man da einstellen kann:

Man hat 1. einen "Color Filter" wo man über untere und obere Grenzen pro Farbkanal (Lower Limit und Upper Limit) einstellen kann, welche Farben ok sind (ist im rechten Vorschaubild weiß) und welche nicht ok sind (schwarz). Man kann dann unten mit dem Slider schnell durch das Video springen um mal für paar Stellen eine Vorschau zu haben, ob man mit der Filtereinstellung zufrieden ist. Mit "Add" fügt man dann den Filter hinzu. Man kann auch mehrere Filter hinzufügen damit man z.B. blaue und rote Schilder gleichzeitig erkennen kann. Mit den Buttons "Add standard *" kann man vorgefertigte Filter hinzufügen, die für seine Kamera für rote, blaue und gelbe Schilder angepasst wurden.

Im "Settings"-Tab kann man dann den 2. Schritt des Algorithmus konfigurieren. Die will ich jetzt eigentlich nicht unbedingt alle genau erklären und eigentlich bräuchte man da noch Presets je Kameraauflösung (ich denke die vorhandenen Werte sind für ein 720p Video geeignet). Ich versuche dennoch mal einen groben Überblick zu geben:

"Kernel size" kommt zigmal vor und ist ein Unschärfefilter der das Bild unschärfer macht, was dazu führt, dass Bildfehler wie rauschen unterdrückt wird und die Erkennungsleistung besser wird.

"Blob detection" ist für die "blobs" da. Das sind zusammenhängende (z.B. rote) Bereiche, die dann später als Schild erkannt werden könnten. Die Minimum und Maximum pixel-Werte sind besonders wichtig da sie z.B. bei blauen zusammenhängenden Werten den Himmel ausschließen oder bei roten Bereichen die kleinen LED-Leuchten des vorausfahrenden Fahrzeuges ausschließen.

"Sign tracker" ist für die Verfolgung von Schildern zuständig, damit das selbe Schild als solches erkannt wird und nicht als zig-fache Wiederholung erkannt wird.

"Circle detection" ist für die Erkennung runder Schilder. Minimum und Maximum "circle radius" sind wohl besonders interessant. Da die Erkennung auf Houghtransformation beruht, wirken sich die anderen Optionen besonders stark auf die Performance aus.

Aber wie gesagt: Mit einem 720p Video kann man das einfach mal as-is testen. Wie couchmapper bereits korrekt angemerkt hat: Man benötigt java7. Einfach mit java -jar GPStreetTracker.jar starten. Die JavaCV-Bibliotheken sind enthalten. Was man aber zusätzlich braucht sind die nativen OpenCV-Bibliotheken. Ich habe bei mir 2.4.4 installiert und damit läuft es problemlos. Das ganze läuft auch sicher problemlos auf Windows, da hat er es entwickelt, ich besitze nur Linux, da läuft es aber genauso gut 😉

Wenn das dann klappt, man ein Video geladen hat, das Plugin hinzugefügt und eingestellt hat kann man das ganze mit "Start" und nochmal "Start" starten. Am Ende braucht man halt noch das GPX-File und fertig. Ich kann es aber mangels brauchbaren Videos + GPX-Files nicht wirklich weiter testen, helfe aber sonst gerne jedem weiter. Mit meinen ungeeigneten Mini-Videos in schlechter Auflösung und Qualität klappt es aber dennoch schon erstaunlich gut.

couchmapper wrote:

Noch eine Frage nach Passau: gab es Überlegungen, mit OpenCV4Android die gesamte Verarbeitung auf dem smartphone laufen zu lassen ohne erst ein sehr großes Video aufzunehmen und dies später auf dem eigenen Rechner zu analysieren? Dies wird ganz sicher nicht mit 25fps in Echtzeit laufen-mein Rechner hat das auch nicht geschafft. Vielleicht reicht 1 bis 2 fps voll und ganz aus für den Task?
Auf Google play finden ein paar opencv prototypen (eher Spielereien) da kam mir dieser Gedanke.

Leider sind die ARMs schon um einiges langsamer zumal die OpenCV für x86 mit SSE schon wirklich sehr sehr gut optimiert ist. Der spezielle Code wurde meines Wissens nach nicht auf ARM getestet, ich habe das aber schon in anderen Projekten gesehen, dass da schnell mal ein Faktor 10-50 drin ist. Die Überlegung war zwar da, erschien aber nicht sonderlich realistisch: Ein Schild wird nur erkannt wenn es wirklich in der Nähe des Autos ist, nicht unbedingt wenn du es mit dem Auge im Video erkennst. Unter der Annahme, dass man noch 2fps auf dem Handy schafft, dürfte bei einer Fahrt mit 100kmh kaum noch ein Schild im Video auftauchen bzw. noch weniger davon erkannt werden. Ich bin da also wenig optimistisch.

Ich habe keine Ahnung wie die Erkennung von Straßenschildern funktioniert. Außerdem dürfte sie deutlich schwieriger sein als die Erkennung von Zügen und Menschen in Ubahnhöfen.
Dort wird aber die Sache wesentlich vereinfacht, da man hier nur graustufen Bilder als Matrix auswertet. Vielleicht lassen sich ja so auch Muster erkennen.

Wie versprochen habe ich den Autor um die Vortragsfolien gebeten.

Diese können mittlerweile hier heruntergeladen werden.

Läuft die Java-Anwendung GPStreetTracker auch direkt unter Android?

Navi@Map09 wrote:

Läuft die Java-Anwendung GPStreetTracker auch direkt unter Android?

Nein, auf Android laufen nur Programme als apk-Dateien.

Für Java-Programme (*.jar) brauchst du eine Java-Laufzeitumgebung, und die gibt es nur für "normale" PCs ... zumindest wohl nicht für Android-Smartphones.

@stephan75: Vielen Dank für die Info 🙂

Irgenwie bekommen wir das JAVA-Sript GPStreetTracker unter WindowsXP und JVA 7 leider nicht zum laufen. Gibt es dazu eine Schritt-für-Schritt-Anleitung für uns? Besten Dank:)

OpenCV schon installiert? Wenn nicht fangt damit mal an.
http://sourceforge.net/projects/opencvlibrary/files/
Die neueste Version für Windows sucht ihr.

ja, OpenCV wurde in das Verzeichnis C:\OpenCV\... extrahiert. Wie geht es nun weiter?

Ob extrahieren reicht müsstet ihr mal ausprobieren. Ich tippe aber, dass C:\OpenCV\... auch noch in den PATH rein muss.

Weiter geht's mit: https://github.com/lynxxlynxx/GPStreetT … able%20jar -> dort die JAR-Datei herunterladen und lokal speichern. Die Datei müsste etwa 8,8 MB groß sein!

Direkter Link wäre: https://github.com/lynxxlynxx/GPStreetT … r?raw=true

Dann am besten auf Kommandzeile aufrufen mit:

java␣-jar␣GPStreetTracker.jar

Wenn da Fehlermeldungen der Art

\jniopencv_core.dll:␣Can't␣find␣dependent␣libraries

angezeigt werden, ist die OpenCV Installation nicht ok.

Wichtig: Anleitung für Windows folgen: http://docs.opencv.org/doc/tutorials/in … stall.html, dort besonders der Abschnitt Set the OpenCV enviroment variable and add it to the systems path

Wir erhalten immer beim Starten die Meldung

\jniopencv_core.dll:␣Can't␣find␣dependent␣libraries

angezeigt, obwohl die Umgebungsvariablen richtig eingetragen worden sind.

Hab mal den Dependency Walker angeworfen und die Abhängigkeiten analysiert. Mit dem JAR-File war leider eine ältere Version gebundelt, d.h. Java sucht aktuell z.B. nach OPENCV_CORE243.DLL. Das paßt nicht so recht zur Version 2.4.5. (Hab das nur unter Linux getestet und dort von Sources kompiliert, dort gab es diese Probleme nicht).

Könnt ihr mal die folgende Version anstelle der bereits installierten ausprobieren?

http://sourceforge.net/projects/opencvl … win/2.4.3/

32bit Java 7 + OpenCV 2.4.3 und im Pfad: ...opencv\build\x86\vc10\bin; funktioniert hier:

Juhu 🙂, mit der OpenCV 2.4.3 lässt sich nun das JAVA-Sript GPStreetTracker erfolgreich starten. 🙂 Besten Dank!

Navi@Map09 wrote:

Juhu 🙂, mit der OpenCV 2.4.3 lässt sich nun das JAVA-Sript GPStreetTracker erfolgreich starten. 🙂 Besten Dank!

• pedanterie an*
  

Es ist kein Java-Script, sondern ein Java-Programm. Es gibt da gerne mal die Verwechslung von JavaScript (eigentlich ECMA-Script genannt, aber jeder sagt JavaScript), das ist die Programmiersprache die clientseitig im Browser läuft, und Java, das ist die Sprache, die hier gemeint ist. Die beiden Sprachen haben aber sehr wenig miteinander zu tun.

Zum Thema: Ich habe immernoch im Kopf, eine Briefkasten-Leerungszeiten-Erkennung mit OpenCV und irgendeinem OCR zu schreiben. Ist aber noch im nur-Planungs-Stadium.

gormo wrote:

Die beiden Sprachen haben aber sehr wenig miteinander zu tun.

naja, ähnlich in der Syntax sind sie ja schon - bis auf die kleinen Gemeinheiten Feinheiten. Ich benutze beide im gleichen Projekt - Java für Servlets mit maven/jetty und Javascript für die Gui. Da muß man schon mal mental umschalten.

Ich habe immernoch im Kopf, eine Briefkasten-Leerungszeiten-Erkennung mit OpenCV und irgendeinem OCR zu schreiben. Ist aber noch im nur-Planungs-Stadium.

ich weiss nicht, soooo viele Briefkästen laufen einem ja nicht über den Weg. Irgendwie rechtfertigt das den Aufwand nicht. Firmenschilder, Hausnummern, Straßenschilder, Wegweiser und ähnliches scheinen mir häufiger zu sein. Allerdings ist beim Knipsen dort der Kontakt zur Bevölkerung intensiver 😉

<ironie>Interessant wäre eine Digi-Cam an einem flexiblen Endoskop mit der sich die reale Leerung durch die Post überprüfen ließe - bringt aber auch wohl nur Ärger ein</ironie>

Gruss
walter

wambacher wrote:

gormo wrote:

Ich habe immernoch im Kopf, eine Briefkasten-Leerungszeiten-Erkennung mit OpenCV und irgendeinem OCR zu schreiben. Ist aber noch im nur-Planungs-Stadium.

ich weiss nicht, soooo viele Briefkästen laufen einem ja nicht über den Weg. Irgendwie rechtfertigt das den Aufwand nicht. Firmenschilder, Hausnummern, Straßenschilder, Wegweiser und ähnliches scheinen mir häufiger zu sein. Allerdings ist beim Knipsen dort der Kontakt zur Bevölkerung intensiver 😉

Ich fänds halt super praktisch, wenn ich mit meinem Smartphone an einem Briefkasten vorbeikomme und einfach mal ein Foto schieße, und die App mir dann sagt, ob die zu diesem Briefkasten in der OSM liegenden Daten noch aktuell sind, oder ob hier überhaupt schon ein Kasten eingetragen ist. Die Datenqualität ist bei Briefkästen auch in größeren Uni-Städten (Beispiel Hannover) nicht so rosig.

<ironie>Interessant wäre eine Digi-Cam an einem flexiblen Endoskop mit der sich die reale Leerung durch die Post überprüfen ließe - bringt aber auch wohl nur Ärger ein</ironie>

Gleich ne Webcam innen an den Deckel kleben, mit Liveupload. Müsste auch automagisch erkennen können, ob nur ein Brief eingeworfen wird (bei "es wird nur kurz hell") oder geleert wird ("es wird länger hell"). Als Schmankerl noch n Lautsprecher dran, der "Danke, das Sie mich gefüttert haben!" sagt. Fertig ist der benutzerverwirrende Datenschutzalptraum. Also nicht tun...

Nur mal so: die Leerungszeiten (zumindest am Land) besagen nur, dass Briefe die an der genannten Uhrzeit im Kasten sind am selben Tag geholt werden. Mir fallen da durchaus Beispiele ein die mit 08:00 beschriftet sind, der Postler schlägt aber regelmäßig um 11 +/- ne Stunde da auf.

aber jetzt : b2t