mikrocontroller.net

Forum: Digitale Signalverarbeitung / DSP Bildverarbeitung und Mustererkennung (Automobilbereich)


Autor: Johannes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich plane im Rahmen einer Diplomarbeit eine Verkehrsschilderkennung zu 
entwickeln. Da es da ja schon gibt wäre es aus meiner Sicht gut ein 
Gesamtsystem zusammenzustellen.

Ich dachte an 2 Kamnera für Stereo-Vison, Einspeisung von Daten auf den 
CAN-Bus sowie die Möglichkeit zur guten Softwaremäßigen Erweiterung. Die 
Frage stellt sich nach dem Controller/DSP/Prozessor der für solche 
Anwendungen geeignet ist, da es sich ja teilweise um rechenintensive 
Aufgaben handelt. Das ganz sollte am Ende in einem Auto mitführbar sein. 
Ich bin mir nicht ganz sicher ob ich mich mit dem Thema übernehme und es 
zunächst alles auf dem PC, zB in Matlab, testen sollte. Wobei mir eine 
Programmierung gleich in C/C++ am liebten wäre.

Am besten geeignet wäre dann sicher ein Evaluation Board. Für die 
Kameras brauche ich Ethernet oder USB. Bin auf die Reihe "Blackfin" von 
Analog Device gestoßen. Da gibt es zwar Boards für unter 300€, 
allerdings ist die Softwareumgebung mit 3500€ nicht gerade ein 
Schnäppchen.

Was meint Ihr? Welche Erfahrungen habt Ihr?

Grüße

Johannes

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Johannes,

das geht alles auch viel billiger, wenn man gewillt ist, sich mit der 
GNU-Toolchain (gcc, binutils) abzugeben. Meiner Meinung nach ist diese 
fuer den Blackfin inzwischen die bessere Wahl, die uClinux-Division von 
Analog Devices hat in den letzten Jahren excellente Arbeit geleistet.
Wir haben hier inzwischen einige Kameraprojekte mit dem Blackfin 537 
erschlagen, teils auch unter uClinux, um bestehende Programme 1:1 
uebernehmen zu koennen. Mit der Toolchain kann man allerdings auch prima 
"standalone"-Systeme entwickeln, allerdings ist es schon etwas mit 
Arbeit behaftet, von Bilderfassung ueber Verarbeitung bis Versand per 
TCP oder UDP alles selbst zu machen.

Ich verrate mal meine potentielle 'shopping list':

- GNU tools: blackfin.uclinux.org
- Debugger/Flasher: www.section5.ch/icebear (dort gibt's auch DEBIAN 
pakete und Beispielcode fuer "standalone"-Anwendungen)
- Stereo-Kameraboard von Bluetechnix (www.tinyboards.com)

Fuer eine "Billigloesung" sind die Omnivision-Sensoren (auf dem 
Bluetechnix-Kit) ganz gut geeignet, bringen aber fuer ein echtes Produkt 
meistens nicht die erforderliche Qualitaet.

Hoffe, das hilft dir weiter,

Gruss,

- Strubi

Autor: GagoSoft (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guuut, da hast Du Dir ja ein mächtiges Thema ausgewählt!

1) Stereo Vision ist SEHR aufwändig und für eine Symbolerkennung eher 
sinnlos.
2) für Bildverarbeitung benötigtst Du einiges an Rechenleistung und 
etwas Speicher. Versuch's mal mit BMP (leicht auszulesen) und einer 
Hochspache Deiner Wahl.

Ich bearbeite selbst ein selbstgewähltes Diplomarbeitsthema (mit Video & 
FPGA & Controller) - es artet eher aus.

Mein Tipp: nimm eher ein Thema, das ein Institut Deiner Wahl vorschlägt, 
die haben dann auch mehr Interesse daran, Dir bei Problemen zu helfen. 
Vorallem ist dabei das Thema weitgehend abgesteckt und überschaubar. 
Sollte ich nochmal vor die Wahl eines Diplomarbeitsthemas gestellt 
werden, würd ich kein selbsterfundenes Thema mehr nehmen.

----------------------------------
wer Rechtschreibfehler findet, darf sie behalten, Inhaltliche Fehler
nehme ich gerne zurück

Autor: Thomas Burkhart (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich kann auch nur den Blackfin empfehlen. Schau mal auf der Analog 
Devices Seite nach, bevor ich meine letzte Firma verlassen habe, hat ein 
Sales Ingeneur von denen uns eine Neue Variante gezeigt, die direkt 
einen schönen Video-Eingang und noch ein paar nette IO-Komponenten hat. 
Weiß leider den Typ nicht mehr genau. Vom Preis/Leistungsverhältnis sind 
die Blackfin derzeit unschlagbar wenns auf Rechenpower ankommt und die 
brauchst Du für Bildverarbeitung. Wir haben damit Gesichtsfindung 
gemacht.

Gruß

Thomas

Autor: Johannes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Strubi,

danke für die Links und Hinweise. Werde ich mir ansehen. OpenSource wäre 
mir persönlich auch am liebsten. Ist es richtig dass es dann eine Freie 
Entwickluingsumgebung gibt, ich mir den Quellecode für den Blackfin 
kompilieren und ihn dann flashen kann? Oder gibt es gar eine Art 
Betriebssystem für den Blackfin.

@GagoSoft:

Das Thema was mir vorgeschlagen wurde war die Schilderkennung und 
eventuell eine Einspeisung der Ergebnisse in den CAN-Bus. Ich bin auf 
dem Feld der Bildverarbeitung noch nicht sehr weit, denke aber es gibt 
schon Lösungen für diese Probleme der Erkkenung, d.h. irgendwelche 
Bibliotheken. Deswegen dachte ich mach ich noch etwas drum herum. Das 
kann natürlich schnell ausarten, deswegen wollte ich mich hier mal 
informieren. Ich habe noch 1-2Monate Zeit um mich auf das Thema 
festzulegen und mich mit der ganzen Problematik zu beschäftigen.

@ Thomas Burkhart:

Ja, ich denke der Blackfin ist geeignet und auch recht günstig für die 
Uni im Erwerb. Es sollen ja eventuell ja auch weitere Projekte damit 
realisiert werden können. z.B. Fahrspurerkennung etc.


Wie groß würdet Ihr zunächste den Aufwand einschätzen, Daten von einer 
Kamera (zB Webacm) auf den Blacfin zu bekommen um diese dann 
auszuwerten?


Grüße

Autor: Thomas Burkhart (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nimm am besten keine Webcam, sonst musst Du dich noch mit USB 
rumschlagen. Nimm ne Analoge Videocamera (PAL, schwarz/weis) mehr 
Auflösung wirst Du nicht brauchen für Verkehrsschilder.

Der Blackfinn den ich meine hat direkt einen Analogen Videoport, von dem 
die Daten per DMA in den Speicher befördert werden können. Falls Du an 
eine Digitalkamera (CMOS) kommst, bei der Du direkt das Sensorinterface 
rausgeführt bekommst, noch besser, da musst Du dann nur auf H- und 
V-SYNCS reagieren, damit due die reinkommenden Daten richtig im Speicher 
sortieren kannst. Der Blackfinn hat dazu übrigens ne ziemlich genial 
zweidimensionale DMA-Engine.

Gruß

Thomas

Autor: Daniel Freiberufler (freiberufler-daniel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

Ich hatte als Masterabschlussarbeit ein ähnliches Thema. Erkennung von 
Bewegungen mittels einer Videokamera

Dies sollte auch auf einem DSP laufen (Blackfin). Wir haben aber dann 
erst mal ne simulation in C++ bzw. Matlab gemacht. Das würde ich dir 
auch empfehlen, da man sich dann nicht so stark mit Hardwareproblemen 
und so weiter rumschlagen muss. Auch kann man fertige Bibliotheken von 
Mathlab in C++ einzubinden um etwas zu testen. Ich kam dann nie dazu das 
in nen DSP umzusetzen, da es bis zum Ende nur bedingt auf dem PC mit 
Matlabfunktionen lief.

Das größte Problem ist die Erkennung von Symbolen (Pattern) im Bild. Im 
Auto noch viel viel schwieriger als im Raum, wo die Lichtverhältnisse 
relativ konstant sind. An solchen Sachen arbeiten große Firmen und 
selbst die haben  keine 100% Trefferquote.

Also als Thema ist es recht interesant, da man viel über 
Bildverarbeitung lernt. Aber erwarte nicht zu viel von den Ergebnissen. 
Am Ende wirst du froh sein, wenn er zwischen Schildern und Menschen 
unterscheiden kann/könnte :-)

Autor: Johannes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Daniel Freiberufler:

Die Befürchtung, dass es zu vielen Problemen kommen wird, hatte ich auch 
schon. Ich bin auch ein absoluter Neuling in Sachen Bildverarbeitung. 
Dazu kommt, dass das Thema Bildverarbeitung hier am Lehrstuhl noch 
ziemlich neu ist und es eigentlich noch keine Arbeiten dazu gibt.

Auch kann ich es zeitlich schwer abschätzen was ich alleine in 6Montaten 
(eventuell +2) schaffen kann. Ich hab zwar Erfahrung mit Matlab, C und 
Mikrocontrollern, aber das hilft mir bei der Bildverarbeitung auch 
erstmal nicht:) Ich lese jetzt schon nebenher Bücher zu dem Thema, um 
einen Einstieg zu bekommen. Wie lange hattest Du Zeit für Deinen Master 
und was hattest Du für Vorkenntnisse?


Grüße

Johannes

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Johannes,

> OpenSource wäre
> mir persönlich auch am liebsten. Ist es richtig dass es dann eine Freie
> Entwickluingsumgebung gibt, ich mir den Quellecode für den Blackfin
> kompilieren und ihn dann flashen kann? Oder gibt es gar eine Art
> Betriebssystem für den Blackfin.

Ja, da gibt es einige, haengt halt immer davon ab, was man machen will. 
Besagtes uClinux ist eine minimal abgespeckte Linux-Variante, die für 
den Blackfin von Haus aus schon Bilderfassung von diversen 
Digitalsensoren beinhaltet. Der sog. PPI kann, wie schon Thomas erwaehnt 
hat, Bilder von vielen Digitalsensoren ohne Zusatzlogik einziehen 
(getestet haben wir das mit Omnivision, Micron und einem Custom-Sensor), 
dabei nimmt einem die DMA-Engine den ganzen Overhead ab. Wenn's analoge 
CCD-Sensoren sein muessen, muss man halt noch einen Codec-Chip einbinden 
(wie auf den Blackfin-EZKITs vorhanden).

Die Entwicklungsumgebung ist komplett frei, man kann sie bei section5.ch 
als Debian-Pakete runterladen oder sich von blackfin.uclinux.org selbst 
kompilieren. Es gibt dort auch eine Windows-Version, allerdings kann man 
mit dieser kein uClinux-Kernel compilieren 
(Windows-Dateinamen-Restriktionen).

Da das Thema doch fuer eine 6monatige Arbeit verflucht komplex ist, 
wuerde ich moeglichst funktionierende Komponenten verwenden und das 
ganze unter einem Linux-System mit GCC entwickeln. Spaeter laesst sich 
das ganze dann, wenn die Algorithmen funktionieren, prima auf das 
Embedded System uebertragen - zumindest hatte ich damals das Glueck, 
dass der Algorithmus auf Anhieb lief.

Fraglich, ob uClinux dann die erforderlichen Latenzzeiten abdeckt, dazu 
gibts aber wiederum Erweiterungen wie Xenomai, usw.
Im Automotive-Bereich wird wohl auch RTEMS eingesetzt.

Gruss,

- Strubi

Autor: Johannes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Strubi:

danke für die Infos und die realistische Einschätzung.

Also wenn ich das richtig verstehe wäre es wohl das beste, sich ein paar 
Bilder herzunehmen (aus dem Verkehr). Dann wird die Hauptaufgabe sein 
eine Mustererkennung zu implementieren. Das alles unter Linux und mit 
GCC. Sollte das funktionieren und vielleicht schneller als erwartet, 
könnte man die Sache ja noch auf den DSP ausweiten.

In Matlab gab es die schöne Funktion "imread()", mit der man aus einem 
Bild die entsprechende Matrix mit den Farbwerten in Matlab hatte. Sowas 
gibt ja bestimmt auch für den GCC, oder?


Grüße

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bist du sicher dass das in eine Diplomarbeit passt, Entwicklung eines 
Algorithmus UND Implementierung in Hardware?

Die Implementierung auf einem PC und einem Festkomma-DSP ist sehr 
unterschiedlich, mit neu kompilieren ist es nicht getan, eher mit neu 
schreiben: du hast andere Zahlenformate, DSP-Bibliotheken, 
IO-Anforderungen. Ich würde die Simulation deshalb erst mal so einfach 
wie möglich machen, d.h. mit Matlab.

Autor: Thomas Burkhart (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Johannes: Ich denke das ist die beste Herangehensweise. Erst mal auf 
dem PC zum Laufen zu bringen. Was die Portierung auf einen Fixkomma DSP 
angeht bin ich nicht ganz so pessimistisch. Wenn Du die Fließkommawerte 
in deinem Algorithmus zwischen -0.9999 und +1.0 halten kannst, was ofte 
der Fall ist, dann gibts beim Blackfin den praktischen Datentyp Fract, 
der kümmert sich um die richtige abarbeitung des Fließkommawertes ohne 
Performanceeinbußen.

Aber wie gesagt, erst mal den Algorithmus zum Laufen bringen. An dieser 
Stelle sei mal auf den Lehrstuhl für Bildverarbeitung der Uni-Jena 
verwiesen, die haben eine ziemlich mächtige freie 
Bildverarbeitungsbibliothek, die Du einfach runterladen kannst.

Gruß

Thomas

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Johannes,


> In Matlab gab es die schöne Funktion "imread()", mit der man aus einem
> Bild die entsprechende Matrix mit den Farbwerten in Matlab hatte. Sowas
> gibt ja bestimmt auch für den GCC, oder?

Ich persoenlich bin kein Fan von Matlab, teste Algorithmen lieber in C 
aus, heisst aber, man muss eine gute Library zusammenhaben, wenn man 
nicht jedesmal das Rad neuerfinden will. Damit waeren wir beim 
Stichwort: sowas wie imread() gibt's nicht in den Standard-Libraries, 
man hat da viel mehr Freiheiten in der Wahl. Da gibts die libpng, die 
libjpeg, oder div. BMP reader, um Bilder einzulesen.

Eine ganz tolle Alternative zu Matlab finde ich Python. Inzwischen gibts 
da eine Menge numerischer Bibliotheken (siehe auch Python Imaging 
Library 'PIL'), so dass man damit wunderbar maechtig prototypen kann. 
Wenn's einem dann noch zu langsam ist, kann man Python-Module in C 
portieren und hat damit die uebliche Geschwindigkeit, muss sich aber um 
die Verwaltung von Image-Objekten, usw. nicht kuemmern.

Zum Thema Fliesskomma: Das ist naemlich ein grosser Knackpunkt bei den 
Blackfins: Keine Floating-Point-Unit. Der Grund ist, dass die Dinger auf 
Stromsparsamkeit und Bild/Audio-Verarbeitung ausgelegt sind, nicht 
unbedingt auf numerische Berechnungen. Darum wuerde ich nach 
Moeglichkeit versuchen, keine Float-Berechnungen zu machen, die sind 
zwar auf dem Linux-PC schnell und "easy", aber brauchen dafuer auf dem 
Blackfin richtig Zyklen - und sind meist unnoetig. Das heisst 
natuerlich, dass man seine Arithmetik genau unter Kontrolle haben muss, 
also Ueberlaeufe und Vorzeichenbehaftung im Griff hat. Gibt dazu aber 
wiederum eine ganz brauchbare DSP library (libbfdsp) - ist bei der 
GNU-Distribution zum blackfin mit dabei. Und der Blackfin-Assembler ist 
notfalls leicht zu lernen, wenns ans Optimieren ginge.

Hoffe, das hilft dir bei dem komplexen Thema weiter.

Gruss,

- Strubi

Autor: Daniel Freiberufler (freiberufler-daniel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich hatte 6 Monate Zeit. Von Bildverarbeitung hatte ich fast keine 
Ahnung. Höchstens Grundkenntnisse. Eigentlich sollte ich auch nur ein 
bestehendes Projekt in einen DSP umsetzten. Es bestand schon eine 
Vorarbeit (Diplomarbeit meines Vorgängers). Allerdings war dieses 
Verfahren nicht brauchbar und so hat sich mein Thema geändert und ich 
musste den Algorithmus überarbeiten. Hätte ich neu begonnen, hätte es 
genauso lange gedauert

Die Zeit war bei Weitem nicht ausreichend um den Algorithmus auch noch 
in nen DSP zu packen. Ich hatte zwar bei der Progammierung schon darauf 
geachtet mit Fixedpoint zu rechnen usw. Aber Kameraschnittstelle usw. 
denke ich ist auch einiges an Arbeit. Ich muss allerdings dazu sagen, 
das ich auch nur 3 Punkte im Bild finden musste und dann aus diesen 3 
Punkten eine Bewegung berechnen musste. Das ist um einige Faktoren 
einfacher als das was du vorhast.

Ich will dich nicht demotivieren, da ich nicht einschätzen kann, was du 
so drauf hast, aber das ist schon eine sehr sehr schwierige Aufgabe. In 
6 Monaten eigentlich nicht zu schaffen. Größere Firmen arbeiten auch an 
diesen Themen. Aber wirklich brauchbare Systeme gibt es noch nicht. Und 
an diesen Systemen haben Spezialisten Jahre gearbeitet.

Autor: Thomas Burkhart (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na,, na, na, wer wird denn so persimistisch sein. Das bloße Auffinden 
der Schilder sollte nicht so schwer sein, sind ja ziemlich definierte 
Formen. Also eher Standardaufgabe der Bildverarbeitung. Was es noch 
nicht gibt und was wirklich schwer ist, diese in den Kontext eines 
fahrenden Autos zu setzen, d.h. für wen gelten die Schilder jetzt und 
ähnliches.

Also lass Dich nicht entmutigen und such Dir am besten eine Bilbliothek, 
die schon viele passende Funktionen hat. Mit Python würde ich hier gar 
nicht erst anfangen.

Wie gesagt Uni-Jena hat eine C++ Bibliothek. Alternativ kannst Du 
versuchen von der Firma MVTEC eine Studielizenz für deren 
Bildverabeitungssystem Halcon zu bekommen. Haben wir in unserer Firma 
eingesetzt, ist extrem mächtig und hat ein Scriptinterface mit dem man 
schnell mal Funktionen ausprobieren kann. Wenns damit läuft kannst DU 
die verwendeten Operationen immer noch in C implementieren. Wäre wohl 
der schnelllste Weg.

Mathlab würde ich auch nur empfehlen wenn Du wirklich ganz neue 
Algorithmen entwickeln willst. Für klassiche Bildverarbeitung gibst 
besseres.

gruß

Thomas

Autor: Maik H. (maikh)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Als Alternative zu der C++ Bibliothek aus Jena sei auch noch auf das 
OpenCV Projekt (http://sourceforge.net/projects/opencvlibrary/) von 
Intel hingewiesen. Intel stellt damit eine mächtige Sammlung von 
optimierten Algorithmen zur Signal- und Bildverarbeitung unter der GPL 
Lizenz zur Verfügung. In Kombination mit der Intel IPP ist das schon ein 
sehr mächtiges (und schnelles) Werkzeug. Vorteil von OpenCV ist, man 
findet im Netz ausreichend Dokumentation und beispiele, da es besonders 
an Universitäten recht verbreitet ist.

Gruß Maik

Autor: Thomas Burkhart (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Kleiner" Nachteil der Intel Sachen, es gibt sie nur für Intel 
Architekturen :-(

Autor: Maik H. (maikh)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da hast du natürlich recht, ich dachte dabei auch eher an die schnelle 
Evaluation seines Algos auf einem x86 System um sich dann auf die 
Implementierung auf dem DSP zu konzentrieren.

Autor: Johannes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Danke für die vielen Antworten. Ein nicht ganz einfaches Thema:)

Wahrscheinlich ist es wirklich das beste, die ganze Sache mit einer 
fertigen Bibliothek anzugehen. Und das am besten in C/C++.
Von der OpenCV hab ich auch schon einiges gehört, die von der Uni Jena 
macht aber auch einen guten Eindruck. Am liebsten wäre mir natürlich ein 
eigener Algorithmus um Schilder zu erkennen. Ich weiß nur nicht um den 
Aufwand. Ich weiß halt nicht ob die Verwendung einer solchen Bibliothek 
zu einfach für ne "Diplomarbeit" wäre (ist es sicher nicht..) bzw. wie 
weit sich da Dinge optimieren lassen.

Wie schnell hattet ihr denn mit OpenCV bzw. mit ICE (Uni Jena) erste 
Erfolge. Ich habe momentan etwa nur 10-15h pro Woche um mich mit der 
Thematik zu beschäftigen.

Wichtig wäre halt, dass man den Algorithmus am Ende auf einen DSP/µC 
portieren könnte.


Grüße

Autor: Johannes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
noch was:

Was könnt Ihr für Literatur zur Mustererkennung empfehlen? Am besten mit 
praxisnahen Beispielen. Bis jetzt verwende ich:

1. Handbook of pattern recognition and computer vision   - Chen, Chi-hau
2. Computer vision and image processing - Morris, Tim

Das erste ist ein Überblick über viele Verfahren und Anwendungen ohne 
näher auf die Grundlagen einzugehen, das zweite behandelt grundlegende 
Bildverarbeitungsverfahren und geht teilweise auch auf die 
Mustererkennung ein.


Grüße

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Etwas offtopic aber ich fürchte mit 10-15 Stunden/Woche erreichst Du 
nicht mal das (kleinere) Ziel Algorithmus zu entwickeln, geschweige denn 
Implementierung.

Für die Diplomarbeit wäre es auf jeden Fall viel zu groß.

Ansonsten fürde ich Folgendes machen:

wenn nur Standbilder analysiert werden müssten, dann würde ich ImageJ 
nehmen. Das ist Java und man kann schnell was machen (man muss sich 
nicht um "Laden", "Speichern" und so weiter kümmern.

Wenn auch "Live" Bilder analysiert werden müssen, dann würde ich zu 
VirtualDub greifen -- einfacher geht es nun wirklich nicht, um Videos zu 
processieren.

In beide Sachen musst Du Dich nicht einarbeiten, was spezielle 
Algorithmen angeht, es wird alles "per Hand" gemacht. Später kannst du 
dann alles in C umschreiben.

Grüße,

Kest

Autor: Johannes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ganz soll erstmal nur für ein Standbild funktionieren. Dürfte ja 
nicht so schwer sein dass in C einzulesen und weiterzuverarbeiten, 
oder?!

Was meinst Du mit Virtual Dub? Das ist doch eigentlich ein Tool im 
Videos zu bearbeiten.

Mit den 10-15h will ich neben meinem Praktiukum jetzt nutzen um mich in 
die Thematik einzuarbeiten. Um den Aufwand für das Diplom wenigstens 
etwas abschätzen zu können.


Grüße

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
zu VirtualDub:

Man kann für VirtualDub eigene PlugIns schreiben. Dann lädt man ein 
belibiges Video und lässt es laufen.... Es können Video-Effekte sein 
aber auch Pattern-Matching oder wie auch immer. Man hat nur ein Array 
mit Pixelwerten und ab da ist ja nur Pixelschieberei ;-) Bei manchen 
Sachen reicht sogar die Geschwindigkeit aus, um Live-Preview 
anzuschauen.

Ich mache viel Videoprocessing und hab die Erfahrung gemacht, dass wenn 
man später sowieso alles selber machen möchte (also keine vorgefertigetn 
Algos), sollte man auf MatLAB/OpenCV und Co verzichten um Überblick zu 
behalten. Dies aber nur meine eigene Meinung

Grüße,
Kest

Autor: Johannes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aha,

ist natürlich auch ne interessante Idee um erstmal was zu probieren und 
ne Live-Ansicht zu haben. Benutzen die Plugins eine eigene 
Programmiersprache?

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PlugIns können in VisualC++ programmiert werden. Ich habe ein Mal so ein 
Beispiel heruntergeladen und ab da ist dann einfach

Kest

Autor: Daniel Freiberufler (freiberufler-daniel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja mag sein, das ich etwas zu pesimistisch bin. Sind halt meine 
Erfahrungen gewesen und ich war schon ein bissel entäuscht, das ich 
nicht weiter kam. Aber muss ja bei dir nicht so laufen.

OpenCV ist relativ einfach zu nutzen. Es gibt Module um Videos zu laden, 
Kameraschnittstellen und Bitmapreader. Die Bilder lassen sich also 
schnell bereitstellen. Desweiteren gibt es Module wie Greyscaler, 
Kantendetektoren aber auch kompliziertere Sachen wie Gesichtserkennung. 
Desweiteren gibt es Module die dir Verwaltung von Datentypen 
vereinfachen.

Du musst dich einfach mal einlesen in OpenCV und ein paar Sachen 
probieren, dann wird das schon.

Von Videobearbeitungssoftware würde ich abraten, da du die Software 
unbedingt auf den DSP portieren möchtest. Das ist von einem C Programm 
meiner Meinung wesentliche einfacher als aus irgenteinem Skript.

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

moechte mich nochmal kurz den "Selbermachern" anschliessen:

Der Punkt ist ja immer, dass es was zu Lernen gibt, man also irgendwann 
genau wissen muss, was die Algorithmen machen. Ist der Diskussion 
"Visual IDE" gegen "Gnu/Make" aehnlich: Anfangs ist mit den 
Klickibunti-Tools wie Matlab, Labview, etc. alles recht easy, wenn's 
dann aber an die Implementation und effizientes Programmieren geht, 
stellen sich ganz andere Huerden auf.

Drum wuerde ich schon von Anfang an parallel entwickeln: Matlab, oder 
Python Imaging Library, oder was einem eben passt, kann man fuer's Ideen 
sammeln verwenden, und daneben schreibt man sich seinen eigenen Code per 
Library, oder eigenem Filter. Denn irgendwann rennt man in das Problem, 
dass die Library nicht genau das macht, was man will, und man kann es - 
sofern es geschlossener Code ist wie in Matlab, usw. - nicht mit 
vernuenftigem Aufwand debuggen.

Grade wenn's auf dem DSP laufen muss, sind Handoptimierungen noetig, 
also wird meist die "inner loop" nochmal in Assembler gehackt. Die 
Lernkurve ist zwar anfangs steil, aber es lohnt sich.

Letzte Worte aus dem Naehkaestchen: Fuer unsere Mustererkennung haben 
wir schlussendlich auf aufwendige Filter-Kernels (Sobel-Filter, usw.) 
und Vektorisierungsalgorithmen verzicht und schlussendlich alles von 
Hand geschrieben (in C und pur Integer). Konnte dann direkt von Linux 
auf Blackfin-uClinux portiert werden, nur die Bildacquisition wurde dann 
auf das video4linux-Interface umgestellt. Trotz Linux-Overhead sind wir 
da noch bei min. 10 frames/sec Verarbeitung.

Gruss,

- Strubi

Autor: Johannes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So,

nach einigen Recherchen werde ich das ganze von Anfang an versuchen in 
C/C++ zu machen. Zum einen habe ich eine gute Portierbarkeit, zum 
anderen den vollen Überblick (hoffe ich doch) was im Hintergrund 
passiert. Ausserdem gibt es ja für C gute Bibliotheken, um z.B. dieses 
SIFT (scale invariant feature transformation) zu verwenden.

Die meisten Forschungsansätze beim Auswerten von Bildern nach 
Verkehrsschildern beginnen bei einer Farbsuche. Damit wird ein Bereich 
(Region of interest) eingegrenzt, in dem dann per Pattern Matching oder 
Formenanalyse auf die Art des Schildes geschlossen wird. Eventuell gibt 
es dann noch eine Schrifterkennung um die Geschwindigkeit auszuwerten 
(bei Temposchildern).

Das mit dem DSP lasse ich erstmal aussen vor...

Ich habe gesehen, dass Siemens/VDO solche Systeme schon recht weit 
entwickelt hat 
(http://www.vdo.de/products_solutions/cars/driver-a..., da 
gibt es auch ein Video).

Jetzt stellt sich mir die Frage: lohnt es sich, Arbeit in ein solches 
Thema zu investieren. Es wird ja eine Diplomarbeit, also keine 
Forschung, so dass ich "nur" versuchen kann/werde, ein ähnliches System 
was hoffentlich etwas funktioniert, aufzubauen (also im wesentlichen 
Software). Interesse ist auf jeden Fall vorhanden. Das Thema ist halt 
neu hier am Lehrstuhl, so dass ja auch irgendwie angefangen werden muss. 
Wer hat Erfahrung mit solchen Sachen oder könnte mir da noch Tips in 
Richtung der Diplomarbeit geben ?!

Viele Grüße und schönen Abend noch

Johannes

Autor: selbst in Bildverarbeitung (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

wollte auch kurz was sagen da ich selbst mit industrieller 
Bildverarbeitung arbeite.


Ich denke einen Rechner aufzubauen ist keine großes Problem.
Sollte aber schon bei 800Mhz liegen.
Da würde ich evt. Embedded Board nehmen.
Sind aber ein wenig teurer.

BV Bilbliotheken - fertige - gibts haufenweise.
Cognex, Mil, Common Vision Blox, Halcon von MVtec. (wie schon erwähnt)
Damit ist die Auswertung kein Akt.
(Es sei denn - du mußt(willst es selbst machen)

Zu jedem Gibt auch freie Testversionen.
Meist mit begrenzter Laufzeit.
Wenn man freundlich fragt bekommt man aber für 4 wochen eine 
Evaluierungslizens.
Das sollte also nix kosten denke ich.

Aber die Kameras bzw das Bild wird das teuerste.
Wie willst du das Bild einziehen ?
Was für ne Kamera ?
Da liegt der Knackpunkt.

Oder soll es rein theoretisch werden ?

mfg
Martin

Autor: Johannes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

also mit der Auswahl der Kamera habe ich mich noch nicht beschäftigt. 
Wir haben hier einige Webcams von Axis die halbwegs brauchbare Bilder 
liefern, allerdings war ich damit noch nicht auf der Strasse unterwegs. 
Das Board von Blackfin hat ja z.B. einen analogen Videoeingang, so dass 
das eventuell auch eine Möglichkeit wäre. Schöne wäre wenn ich das ganze 
in C machen könnte um es später vielleicht wirklich auf einen DSP o.ä. 
zu portieren bzw. mein Nachfolger dies tun könnte.

Mein Ansporn für die Diplomarbeit wäre es, eine solche Mustererkennung 
selbst, d.h. ohne Verwendung von Bibliotheken, zu realisieren. Ob das 
was wird weiß ich leider nocht nicht :) Bin noch am einarbeiten und die 
Zeit läuft zu Glück noch nicht.

Gibt es freie Libraries um Matrizen in C vernüftig zu bearbeiten? Würde 
sonst die ganze Sache erstmal mit Matlab anfangen um mir zum probieren 
diesen Stress das alles selber machen zu müssen zu ersparen.


Grüße

Johannes

Autor: Moe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Google nach BLAS

Autor: Georg Hannes (hinkelstein)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo erstmal.

Ich habe mir mal ein paar Gedanken zu Ihrem Vorhaben gemacht.

Als erstes habe ich mal in die StVO geschaut und festgestellt, daß es 
ca. 200 Verkehrszeichen gibt.
Zweitens habe ich mir überlegt, wie die Verkehrszeichen wohl auf die 
Sensoren der Kamera(s) abgebildet werden. Antwort: Ziemlich verzerrt, da 
die "Schilder" in den seltensten Fällen senkrechte Ebenen zur optischen 
Achse der Kamera bilden und von dieser in der Mitte des "Schildes" 
durchstoßen werden. Kreise werden zu Ellipsen, Rechtecke zu Rhomben und 
die dreieckigen "Schilder" bleiben zwar dreieckig, haben dann aber 
Symmetrien mehr.
Der benötigte Suchalgorithmus muß diese Verzerrungen tollerieren können. 
Meine Idee wäre ein schon bekanntes Verfahren namens Kreuzkorreletion. 
In der Nachrichtentechnik und -verabeitung gerne angewendet um ein 
bekanntes Signal im Rauschen wieder zu finden. Ob sich allerdings schon 
jemals wer an einer zweidimensionalen Kreuzkorrelation probiert hat weiß 
ich nicht, müsste aber gehen. Der Rechenaufwand wird allerdings 
gewaltig: zum Erkennen nur eines einzigen "Schildes", dessen 
Musterfunktion in einer 64x64 Matrix liegt benötigt bei nur 640x480 
Punkten Bildformat über 1,25e9 Multiplikationen und Additionen. Zum 
Erkennen aller "Schilder" wäre also ein Rechnerverbund von über 200 
Prozessoren notwendig und schafft dann auch nicht einmal einen frame pro 
Sekunde.
Und wozu die stereometrische Verarbeitung für dieses Problem gut sein 
soll ist mir im höchsten Maße schleierhaft.

Trotz alledem find ich Sie sehr mutig. Solche Ingenieure braucht das 
Land.

Viel Erfolg

Georg Hannes
Dipl.Ing.

Autor: Johannes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Georg Hannes:

danke für Ihre Überlegungen. Das mit dem Steroervision war nur ne 
Schnapsidee um vielleicht Entfernungen schätzen zu können. Es bleibt 
aber bei einer Kamera.

Das ganze Bild mit einer KKF zu bearbeiten ist natürlich unmöglich. Die 
meisten Ansätze gehen dahin, dass zunächst mit einer Farbsegemntierung 
begonnen wird. Es wird also z.B. Rot gefiltert. Anschließend werden 
daraus die interessanten Bereiche (ROI) ermittelt und dann mit 
verschiedenen Verfahren, also z.B. der von Ihnen vorgeschlagenen KKF, 
geometrischen Analysen oder ählichem nur in diesen kleinen Bereichen 
gesucht. Das sollte den Rechenaufwand schonmal ungemein reduzieren.
Wie aufwendig dann die Implementierung ist weiß ich auch noch nicht.

Auch mit der Kamera bin ich mir nicht im klaren. Ich soll mich schon 
bald festlegen was für eine Kamera und was für Hardware ich benötige. 
Dabei steht vor allem die Framerate und die Qualität des Bildes im 
Vordergrund. Wichtig wäre ja sicherlich auch eine hohe Scharfentiefe. 
Ich liebäugle ja noch mit dem Blackfin - in Kombination mit einer 
analogen Kamera.

Hat jemand Empfehlungen für eime analoge Kamera in Verbindung mit einer 
Framegrabber-Karte bzw. dem Videomodul (von www.bluetechnix.at) für den 
Blackfin-DSP? Ich habe gesehen dass es auch CMOS-Module für den Blackfin 
gibt die sich über das PPI-Interface auslesen lassen, nur sind das die 
reinen Sensoren ohne Optik. Ich hätte aber schon gern was fertiges 
dami9t ich mich nicht auch noch darum kümmern muss. Das wird sonst nicht 
schaffbar.

Wäre für Tips sehr dankbar

Grüße

Johannes

Autor: Martin S. (strubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

zur 2D-Kreuzkorrelation haette ich folgende Bemerkung: Dank einiger 
netter Theoreme liesse sich diese per Multiplikation zweier Bilder im 
Fourier-Raum mit deutlich weniger Komplexitaet berechnen. ABER: In 
diesem Fall macht ein Problem die Loesungsidee zunichte: Die Schilder 
sind, wie schon erwaehnt, unter so einigen moeglichen Perspektiven 
sichtbar, also verzerrt, mal groesser, mal kleiner. Die KK bietet leider 
keine Projektions-Invarianz...
Im allgemeinen kommt man bei Mustererkennung mit Vektorisierung oder 
Ecken-Detektion schneller zum Ziel, ich denke, der von Johannes 
skizzierte Loesungsweg klingt vernuenftig.

Zur Kamera am Blackfin: Die analogen haette ich erst gar nich mehr 
angeschaut, das lohnt sich preislich nicht mehr, schon allein mit dem 
Aufwand der Ansteuerung des Codec. Es gibt von einer Hongkong-Firma 
(COMEDIA LTD) diverse Sensor-Module (Omnivision-Sensoren) mit Optik, wie 
z.B.:
AA-9620 (1280x1024, "raw bayer" format)
AA-9655 (1280x1024, YUYV-Format)

und einige kleinere Sensoren Typ "Handykamera" (mit mieser Aufloesung), 
ich glaube, irgendwas mit 7660, oder aehnlich. Einfach mal googeln..und 
am besten mal die Datasheets angucken. Beim 9620 muss man zusaetzlich 
noch die Farben selbst (per Bayer-Pattern) umrechnen! Beim 9655 ist die 
Konversion etwas 'billiger'.

In Deutschland fuehrt Intertec die Module, kosten um die 40 Euro als 
Einzel-Eval-Preis:

www.intertec-components.de

Falls dich die Omnivision-Dinger anfressen wuerden, haette ich auch 
einen Adapter von OV-Modul auf PPI-Stecker fuer die offiziellen BF537 
STAMP(EZKIT) eval kits. Fuer die Tinyboards allerdings muesstest du nen 
Adapter selbst "frickeln", allerdings gibt es dort ein Board mit Adapter 
fuer die 76XX-Flexkabel-Minisensoren, wenn ich mich recht entsinne.

Vorsicht: Der OV9655 ist ein 2.5V-Sensor. Ich bin mir nicht sicher, wie 
3.3V-tolerant dessen I/Os sind, ich hab auf meinem Evalboard ein CPLD 
als "Glue".
Bin eigentlich mit den Dingern ganz zufrieden, abgesehen davon, dass sie 
etwas bescheuert designt sind. Die Linsen sind natuerlich nicht das Ah 
und Oh, sind diese kleinen, direkt auf die Platine aufgeschrauben 
Mini-Mounts. Fuer das 9655 gibt es aber mehrere Linsen-Typen.

Allerdings ist das Ansteuern der Sensoren per i2c etwas eine Krankheit 
gewesen, aber auf dem Code dazu bleib ich auch nicht sitzen wie auf 
einem Ei :-), sprich, der Source (standalone wie auch Linux) ist 
verfuegbar.
Fuer akademische Zwecke sind die Teile von der Qualitaet her ganz ok, 
fuer ein (High-)Endprodukt natuerlich nicht zu gebrauchen, unter 
anderem, weil man keine Garantie fuer die Verfuegbarkeit eines solchen 
Moduls erhaelt.

Gruss,

- Strubi

Autor: Oszi40 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Abesehen vom Aufwand der Bildverarbeitung frage ich mich, wie Ihr die 
optischen Linsen im Frontbereich tagtäglich frei von Fliegen, Schmutz, 
Regen und Schnee halten werdet. Da ist noch viel Stoff für 
Diplomarbeiten.
Wahrscheinlich sind 2 Kameras für Kurvenfahrten schon zu wenig...

Gruß Lutz

Autor: Εrnst B✶ (ernst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Allein die Kamerawahl ist nicht ohne.
Im Auto muss die ja mit stark unterschiedlichen Lichtsituationen 
klarkommen (Entgegenkommendes Auto mit Fernlicht...) ohne geblendet zu 
werden.

Mit CCD ist da nix zu reissen, es gibt aber CMOS-Kameras mit 
entsprechenden Kennlinien ("HDR")...

Erster Google-Hit hierzu:
http://webvideo.uni-lueneburg.de/vd/pdf/070305-06.pdf


Übrigens, die 3D-Auswertung geht auch nur mit einer Kamera, wenn du die 
Eigenbewegung des Autos mit einrechnest.

Autor: joern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ohne fuer den Sinn zu garantieren, wuerde ich vielleicht versuchen, das 
Verkehrsschild zu entzerren (Also eine frontoparallele Ansicht zu 
erzeugen) und in eine definierte Position zu rotieren bevor ich es zu 
erkennen versuche, da dies den Aufwand erheblich reduzieren sollte. Dies 
wird wohl auch so bei planaren Mustern fuer 
Augmented-Reality-Anwendungen so gemacht. (Einfach mal googlen.)
Dafuer sollte man Eckpunkte des Schildes identifizieren (Natuerlich auch 
nicht einfach und ein Problem fuer sich), die grobe Schildform anhand 
der Anzahl ermitteln und aus vier Eckpunkten im Bild und den 
entsprechenden Punkten in der bekannten Schildform eine Homographie 
ermitteln, deren Inverse dann das Schild entzerrt. (Beispielsweise zu 
finden auf Seite 35 des Buches Multiple View Geometry von Hartley & 
Zisserman, in das reinzuschauen sich bei Deinem Problem sicherlich 
lohnt.)
Damit haette man dann eine definierte Ansicht in der richtigen Rotation, 
die zu vergleichen mit deutlich geringerem Aufwand moeglich sein sollte.
Ich weiss nicht, wie Deine Entzeitanforderungen sind, aber ich denke, 
dass es nicht ohne weiters auf einem Blackfin zu machen ist. 
http://thomaspfeifer.net/ (wirklich schoene Projekte) verwendet fuer 
Bilderkennung einen DM642-DSP, der deutlich mehr leistet. Ob damit Dein 
Problem in Echtzeit loesbar ist und wie man die umfangreichen 
Trainigsdaten fuer die verschiedenen Schilder (die sich durch den obigen 
Ansatz aber deutlich veringern sollten.) in so einer Applikation 
sinnvoll speichert, weiss ich aber auch nicht zu sagen.

Gruss, Joern

Autor: joern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach ja, schau Dir mal auf http://thomaspfeifer.net/ die Augmented 
Reality an.  Thomas Pfeifer hat dort ein Video, was genau zeigt, was ich 
gemeint habe. Zu sehen ist, wie eine frontoparallele und richtig 
rotierte Ansicht des Quadrats erzeugt wird. (Sieht ziemlich nach 
Echtzeit aus.)
Gruss, Joern

Autor: Johannes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die vielen Ratschläge und die schöne Homepage von Thomas 
Pfeifer.

Ich habe mal ein Video mit einer Axis-Webcam (W211M) während der Fahrt 
kurz vor Sonnenuntergang (es war noch hell genug) aufgenommen. Ich hatte 
ja die Hoffnung erstmal einen Farbfilter über das Bild zu schieben um 
dann .B. nur rötliche Bereiche zurückzulassen. Nur sind die eigentlich 
roten Schilder auf dem Video nicht mehr mehr rot, sondern 
braun-weiß-bläulich. Werde mal versuchen das noch in anderen Farbräumen 
ausser dem RGB (z.B. im HSV) auszuwerten.

Aber hier geht das Problem schon los: Ich brauch halt erstmal ne gute 
Kamera, bei der die Farbtreue möglichst hoch ist und die einen möglichst 
"echtzeitnahen" Zugriff auf die Bilder erlaubt.

Vom Rechenaufwand her denke ich immer noch dass am Anfang eine farbliche 
Trennung gemacht werden sollte. Anschließend werden diese Bereiche dann 
weiter verfeinert.


Grüße

Johannes

Autor: schnick schnack (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich glaube Du solltest das erstmal im "Reinraum" machen - sprich: nicht 
draussen auf der Straße sondern drinnen mit guten Lichtverhältnissen 
damit es überhaupt erstmal prinzipiell läuft.

Autor: Johannes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich glaube das werde ich auch machen.

Bei Fortschritten melde ich mich wieder.

Macht denn jemand hier was ähnliches? Vielleicht könnte man sich da 
zusammentun bzw. Gedanken austauschen ?! Wäre schön


Grüße

Johannes

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast Du Dir CUDA von nvidia mal angesehen?

Damit kann man alle Berechnungen von der Grafikkarte berechnen lassen, 
Funktioniert sehr gut und vor allem um Faktor x100 schneller als auf der 
normalen CPU. Vieles ist schon "vorgefertig", wie fft. Programmieren 
lässt sich alles in C.

Ich habe ja schon geschrieben, dass ich oft VirtualDub für Videos nehme, 
wenn ich was ausprobieren möchte. In VirtualDub rufe ich dann einfach 
CUDA-Funktion auf und processiere das Bild.

Na ja, war nur so ein Einwurf, vielleicht wäre es was für Dich.

Grüße,

Kest

Autor: Hannes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Johannes,

ich bin auch gerade auf der Suche nach ähnlicher Hardware (falls du noch 
suchst...). Habe eben hier auch schon einen neuen Thread erstellt: 
Beitrag "Embedded-System mit Kamera und genügend Performance für Bildverarbeitung"

... vielleicht für dich auch ganz interessant.

Gruß Hannes

P.S: Zu deinem Farbproblem: Hast du es mal mit einem manuellen 
Weißabgleich versucht (ist z.B. auch mit Photoshop nachträglich möglich 
wenn die Kamera dies nicht erlaubt)?

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Georg Hannes schrieb weiter oben:

"Meine Idee wäre ein schon bekanntes Verfahren namens Kreuzkorreletion.
In der Nachrichtentechnik und -verabeitung gerne angewendet um ein
bekanntes Signal im Rauschen wieder zu finden. Ob sich allerdings schon
jemals wer an einer zweidimensionalen Kreuzkorrelation probiert hat weiß
ich nicht, müsste aber gehen."

Und ob das in der Bildverarbeitung funktioniert! Wird standardmäßig zur 
Pattern identification angewandt, aber auch für Deformationsmessungen, 
motion analysis und Objektauthentifizierung.

Ich arbeite im Bereich Standardsoftware für die 2D-Grauwertkorrelation. 
Damit kann man Bewegungen analysieren, Verformungen messen u.s.w. von 
nanowinzigen Objekten (Mikrosystemtechnik) bis zu riesigen geologischen 
und glaciologischen Forschungsgegenständen (Bergrutsche, Gletscher)

Für die vorliegende Aufgabenstellung ist besonders nützlich, dass 
Beleuchtungsvariationen wegen der Normierung des 
korrelationskoeffiozienten unproblematisch bsind - in der BV an sich so 
sonst nicht üblich.

Objektverzerrungen können bis zu ca 20 Wunkelgrad von der Senkrechten 
meist ignoriert werden (nach eigenen kürzlichen Messungen), bei 
Verkehrszeichen dürften aber größere Abweichungen zu bearbeiten sein. 
D.H. die Originalbilder müssten testweise auf Grund einer 
Winkel-Hypothese "verzerrt" werden, um die Verkehrszeichen im 
Originalformat abbilden zu können. Auch an eine Grössenkorrektur muss 
vor der Korrelation gedacht werden. Also von jedem Originalbild eine 
Schaar seitlich " gessehnter" bilderin verschiedenen Masstäben  erzeugen 
und in denejn eine Korrelationssuche (zur Rechenzeitersparniss nach 
vorheriger Suche nach charakteristischen Formen mit konventioneller BV) 
audführen.

Lerider ist die Korrelation, wie von Hannes schon bemerkt, fürchtelich 
langsam. In Echtzeit in einem embedded system halte ich sie daher für 
noch nicht geeignet. Mit der künftigen Entwicklung von 
multicoreProzessoren wird sich das aber ändern, zumal sich 
Korrelationsalgorithmen prima parallelisieren lassen.. Lohnt also u.U. 
schon entsprechende Vorlaufntwicklungen zu beginnen.

Korelationssysteme für 2D- und 3D- Aufgaben werden u.a. angeboten durch:

DANTEC ULM
GOM GmbH Braunschweig
LIMES gmbH

und von uns (CWM Chemnitz). (2d-System VEDDAC, da wir davon ausgehen, 
dass mit der viel einfacheren, preisgünstigeren 2D- Technik wenigstens 
85% aller technischen Aufgabenstellungen lösbar sind :-)

Bei Interesse ist bei uns kostenfrei eine Startzahlbegrenzte 
Evaluationssoftware (PC, Windows XP) voriwegend für Deformations- und 
motion analysis (aber sicher auch bei ausreichendem Verständnis des 
Users für Experimente zur pattern recognition einsetzbar, 
Bildverzerrungen z.B. mit Atndardprogramen oder einfachen 
Eigenentwicklungen. ) unter www.cwm-chemnitz.de (Kontaktformular) zu 
beziehen.

Ich hoffe, Ihr toleriert diese Firmenangaben als erforderlich zur 
Information und weniger als Werbung.

Gruss Michael

Autor: Detlef _a (detlef_a)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>Lerider ist die Korrelation, wie von Hannes schon bemerkt, fürchtelich
>>langsam.

Die Korrelation zweier Signale läßt sich über die FFT rechnen, das geht 
auch zweidimensional, also mit Bildern. Wenn man die FFT der Bilder auf 
dem embedded System rechnen kann, dann geht auch die Korrelation.

BTW: Meine Lieblingstransformtion, die Hough Transformation, ist im 
Prinzip auch nen Korrelation .

Cheers
Detlef

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Die Korrelation zweier Signale läßt sich über die FFT rechnen, das geht
auch zweidimensional, also mit Bildern. Wenn man die FFT der Bilder auf
dem embedded System rechnen kann, dann geht auch die Korrelation."

Das ist richtig allerdings lassen sich die Grundprinzipien, die zur 
Vereinfachung der FFT gegenüber der "einfachen§ DFT und zur schnelleren 
Berechnung führen, auch sinngemäß ähnlich zur Straffung der berechnung 
verwenden, wenn man den Korrelstionskoeffizienten berechnet. Einen 
wirklich entscheideneden Rechenzeitunterschied gibt es bei otimierten 
Algorithmen wohl nicht. Wenn man bedenkt, dass man für die vorliegende 
Aufgabe ja nicht einfach zwei Bilder korrelieren muss, sondern z.T. 
wegen der unterschiedlichen perspektivischen Abbildung und der 200 
Zeichenmuster mit mehreren Referenzbildern arbeitet, erscheint mir das 
für embedded system doch etwas zeitkritisch.

Ich hab mir mal den obuigen Hinweis auf CUDA von nvidia auf der Webseite 
angeschaut - das sieht ja wirklich aussichtsreich nach Echtzeit aus, 
wenn man 128 Parallelprozessoren geballt auf eine Bildkorrelatione 
losgehen lassen kann.. Muss mir mal die FFT-Algorithmen in dem Paket 
näher beschnerchen, wie die sich eignen.

Allerdings besteht da das Problem, inwieweit das System für künftige 
Entwicklungen weiter unterstützt wird ?

Gruss oreganogold

Autor: funky (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
was ist da eigentlich draus geworden???

Autor: Andy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist ne olle Kamelle.
Bei Opel gibt es das demnächst zu kaufen, bei BMW auch.
Insofern nicht mehr interessant...

Autor: Johannes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

danke nochmal im Nachhinein für die vielen Anregungen. Ich habe mich 
allerdings dann doch gegen dieses Thema entschieden, da das am Institut 
ganz neu war und ich bei Null hätte anfangen müssen.

Aber gelernt haben wir hoffentlich alle etwas davon :)


Grüße

Johannes

Autor: Der Fast (der9gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mal eine gewagte Frage:

Gibt es Lasersysteme die ein Trichter ausstrahlen?
Müsste, ich meine sowas hier: 
http://www.night-tronic.de/productssimple31.html

aber nur halt auf die rechte Seite, wie ein gezielter Lichkegel.

Wenn einer dieser Laserstrahl auf ein reflektierendes Objekt trifft 
(Verkehrsschild) kann man doch dieses Licht detektieren? Sinnvoll wäre 
irgendein Moduliertes Signal, um keine Streuquellen zu detektieren.

IRLaser sendet -> trifft auf Schild -> Reflektionen -> IR Empfänger 
erkennt Reflektion

Dann die Position bestimmen (max Leuchtkraft im CCD Bild).

Anhand deren Position im Bild kann man den Rechenaufwand der weitern 
Bilderkennung vielleicht verringern, da die Position im Bild bekannt 
ist?

nur ne Idee..

Autor: Klaus2 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Hallo,

danke nochmal im Nachhinein für die vielen Anregungen. Ich habe mich
allerdings dann doch gegen dieses Thema entschieden, da das am Institut
ganz neu war und ich bei Null hätte anfangen müssen.

Aber gelernt haben wir hoffentlich alle etwas davon :)


Grüße

Johannes"

-> Weise entscheidung, es laufen bei Stereokameras (hier) im 
Automobilbereich Dinge ab, von denen du nur träumen wirst. Und auf jeden 
Fall mehr als eine "one man show"...ganz zu schweigen von dem 
finanziellen Aufwand, eine brauchbare (!) Lsg. hinzubekommen.

Klaus.

Autor: Der Fast (der9gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wieso sind Stereokammeras im Einsatz?

Entfernungsmessung, bessere Berchenbarkeit des abzulesenden Schildes??


würde mich mal so interssieren..


mfg

Autor: Bert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist es nicht Besorgnis erregend, dass dieser Thread so kurz nach einem 
offensichtlichen Insider-Einwurf aus der Automobiltechnik-Branche 
plötzlich abbricht? Dabei wurde es gerade interessant...

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.