Bilderkennung via Kamera

Servus!

Ich möchte mich an das schwierige Thema der Bildverarbeitung heran wagen...

Ich habe mir schon den sehr guten und interessanten Artikel von Zefram im RN - Wissensbereich durchgelesen.

dieser erklärt die Bildverarbeitung schon sehr gut.

Nur steh ich einen Schritt vorher schon vor einem Problem...

Das Bildverarbeitungstutorial setzt vorraus, dass ich eben jeden Pixel meines RGB-Bildes auslesen kann.

Aber wie mach ich das?!?

Versteht ihr mein Problem?

Ich wäre auch über ein paar hilfreiche Links zu diesem Thema sehr erfreut.

MfG

Jürchen

Was hast du denn für eine kamera?

Bis jetzt hab ich noch keine Kamera.

Ich habe überlegt, ob ich mir das Kamera-Modul von Conrad hole:

Best. - Nr.: 191004

Ich will eben nicht z.b. die fertige CMU-Cam nehmen, sondern mir selbst etwas entwickeln, damit ich eben auch viel lerne...

MfG Jürgen

afair werden die daten normalerweise für jeden pixel nacheinander gesendet. von oben links nach unten rechts zeilenweise.bin jetzt aber nicht der viel-ahnung-mensch.. aber benutz doch mal die suche ;) gibt einige leute hier im forum die mit kameras gearbeitet haben/arbeiten...

die camera sendet ein tv-fbas-signal, also keine pixel, die man evtl seriel senden kann und auswerten kann.

ich habe für mein küchenbot eine billige einfache lösung :
farbbild wird mit funkcam zum pc übertragen, im pc ist eine tv-karte(17,00 euro). ich habe mir mit dem "BCX TO C-Programm" ein captureprogramm geschrieben, welches die avicap32.dll direkt anspricht.
einmal wird auf der linken seite im fenster das original-videobild dargestellt und dann grabbe ich mit einer dll-funktion ein laufendes bild heraus (schnappschuss) und stelle diesen rechts dar zum auswerten nach einem bestimmten farbpixel(rgb), damit der roboter zb nach dem roten punkt vom pc aus gesteuert wird. dieses bild ist ein ganz normales pixelbild, welches man auch als bmp usw abspeichern kann.

Einfacher wäre da ne Webcam, nur ist die dann natürlich nur mit mehr Aufwand mobil zu bekommen.
Mit welcher Sprache willst du denn die Bildverarbeitung machen? Bzw. überhaupt auf nem PC oder auf nem µC?

Ich habe vor das ganze ohne PC zu machen. Der PC soll in erster Linie eine Wiedergabe-Funktion sein.
Die Auswertung soll über µC erfolgen. Kann man dann auch den ganzen Videostream verarbeiten, oder nur Snapshots?

Ich habe vor das ganze in C zu schreiben. Bis jetzt hab ich alles zwar in Bascom geschrieben, aber ich schreibe mir jetzt alles auf C.

MfG Jürgen

Was für einen µC willst du denn verwenden?
Auf der CmuCam ist nicht ohne Zweck ein 75 MHZ Controller...wenn du verstehs worauf ich hinaus will.

Wieviel Daten Du verarbeiten kannst, hängt davon ab, welche Algorithmen Du auf den Daten anwendest, wie groß die Bildauflösung in Pixeln ist, wieviele Farbkanäle Du verwendest, wie groß die Pixeltiefe pro Farbkanal ist und wieviele Frames/Sekunde die Kamera liefert (und ich habe mit Sicherheit noch einige Faktoren auf die Schnelle übersehen).

Eine konkrete Antwort kannst Du erst bekommen, wenn Du spezifizierst, wie die Eckdaten Deiner Anwendung aussehen.

Der Feld-Wald-und-Wiesen ATMegaxxxx stößt da aber schnell an Grenzen.

@ ähm_key:
Wahrscheinlich würde ich den selben Controller verwenden, wie er auf der CMU Cam oder Pob-EYE verwendet wurde. Ich habe eben in diesem Bereich noch nicht wirklich viel Ahnung.

ich möchte die kamera eben so programmieren, dass ich ihr über eine taste eben z.b. sagen kann:

Erkenne "Grün", so dass wenn dies passiert ist, mein roboter alles grüne abfährt.
oder ich ihr z.b. sagen kann, verfolge die rote kugel.

Als Kameramodul hab ich nun vor dieses hier verwenden:
http://www.conrad.de/goto.php?artikel=190840

Was haltet ihr davon?

Ich schaffe es einen Roboter zum Fahren zu bringen, entfernungen zu messen, usw. aber ich bin eben noch ein neuling wenn es um so einen komplexen bereich geht...
Wenn ihr vorschläge/anregungen habt, wäre ich über diese sehr erfreut!

MfG JÜrgen

Ich glaube die Kamera ist nicht geeignet da sie einen analogen (PAL?) Ausgang hat und der ADC des Mega/PIC die digitalisierung des Signals bestimmt nicht schafft.

Such hier im Forum einfach mal alle Threads zum Thema Bildverarbeitung durch, in einem von denen wird eine Kamera mit Digitalausgang erwähnt die man per UART auslesen kann.
Ein mal kurz Google: http://www.sander-electronic.de/gm00031.html
...wäre wohl auch eine Möglichkeit.

Ausserdem denke ich es ist schon ein ARM, XScale oder ein AVR32 nötig um einigermassen Ergebnisse bei der Auswertung zu erhalten. Ich möchte mich auch bald mit dem Thema besfassen und bin gerade dabei mir die mathematischen Grundlagen die dazu nötig sind anzueignen. Ich wollte erst mal auf dem PC anfangen bevor ich Geld in teure Controller stecke.

Vielleicht wäre es auch für dich das beste erst ein mal damit zu beginnen aber achte darauf eine Kamera zu kaufen die du dann auch mit einem Controller auslesen kannst.

diese kamera von sander sieht nicht schlecht aus...
Wenn ich die bildveraarbeitung via PC mache, was benötige ich dafür?
Also: wie schließe ich die Kamera an den PC an(Tv-Karte?), wie wird das Bild dann weiter verarbeitet?
Ich hoffe das war jetzt nich zu viel des guten... :-)

MfG Jürgen

Wo wir wieder bei USB-WebCam wären ;)
Ich nutze Borland Delphi..es gibt aber auch noch viele andere schöne Sprachen und Entwicklungsumgebungen in denen man das machen kann.

Mal eine kleine Rechnung.
Angenommen, Du nimmst ein Bild von lediglich 100 * 100 Pixeln, was wahrhaftig nicht besonders gut ist. Dann wären das schonmal 10000 Pixel.
Bei der Angestrebten Farberkennung muss für jedes Pixel der R, G und B - Wert vorliegen. Werte von 0 bis 255, also 3 Byte pro Pixel. Macht 30000 Byte pro Minibild. Soll die Farberkennung auch bei Lichtverhältnissen arbeiten, wie sie ausserhalb eines optimalen Labors normal sind, so denke ich, kommt man um eine Umwandlung von RGB nach HSV nicht herum. Im HSV - Format haben wir wie bei RGB auch wieder drei Werte. H : 0..255 S : 0..255 und V : 0..360. Oops. 360. Also kein Byte, sondern schon mindestens 2 Byte wenn wir bei Integerwerten bleiben wollen. Macht also für das HSV-Bild nochmal mindestens 40000 Byte. Und da ist noch keine Zeile Code geschrieben.
Also. Nach meiner Einschätzung möchte ich vermuten, daß man für eine auch nur halbwegs brauchbare Bildverarbeitung, die man auch noch bezahlen kann, um einen E-Bay Laptop und eine einfache (USB)-Webcam nicht herumkommt.

[IN]Crusher: Wie ich schon gesagt habe sollte man darauf achten eine Kamera zu wählen die man auch per Embedded System auslesen kann also sollte sie möglichst Daten in digitaler Form ausgeben. Eine TV Karte wandelt ja ein analgoes Bildsignal in ein digitales um, also eine USB Cam oder wie gesagt Cam mit digitalausgang.
Aber ich denke eine USB Cam wäre auch ok da du schon ein Schnelles System zur verarbetung brauchen wirst und diese eh einen USB Host haben. Aber ein Laptop ist doch schon etwas Overkill, oder? Denke mal ein Industrie Computer wäre die etwas bessere und kleinere Wahl.
edit: ... und leichter

Zitat:

---

Nach meiner Einschätzung möchte ich vermuten, daß man für eine auch nur halbwegs brauchbare Bildverarbeitung, die man auch noch bezahlen kann, um einen E-Bay Laptop und eine einfache (USB)-Webcam nicht herumkommt.

---

Aber was ich dann nicht verstehe... bei der CMU oder Pob-Eye klappts doch auch ohne Pc...

Ich möchte eben auch so was in der art entwickeln... ich möchte mir eben nicht extra n industrie computer oder n laptop dafür holen... ist es denn z.b. möglich, dass ich mir einfach eine webcam hole und die software zur bilderkennung auf meinem normal pc programmiere und wenn ich sehe, dass das alles so klappt , wie ich es mir vorgestellt habe, ich mir dann eben die cam hole
http://www.sander-electronic.de/gm00031.html
und den quellcode dann auf nen µC packe (ich weiss... das muss schon nen großer/leistungsfähiger sein)...

wäre das ein sinnvoller entwicklungsverlauf?

MfG Jürgen

Hallo!
Ich persönlich verwende die CMUCam2.
Ich hatte keine Lust das Rad komplett neu zu erfinden.
Dir fehlt bestimmt die Ahnung so etwas wie die CMUCam selbst zu programmieren.
Weißt du, wie kompliziert das ist?
Da du anscheind noch nicht viele Vorkenntnisse hast, empfehle ich dir was fertiges zu kaufen.
Du kannst dich ja parallel noch mit etwas eigenem beschäftigen, aber wenn du Erfolge haben willst, nimm was fertiges, ist immernoch schwer genug.


MfG ACU

Ich hab die c3188 gerade auf der Werkbank liegen und
tüftle mit nem Mega16 gerade dran rum, ich kann dir sagen
der Mega hat da ganz schön zu schwitzen schon mit
der Datenübernahme ist der nicht schlecht beschäftigt.
Die Kamera schiebt 16 Bit, bzw. 2 x 8Bit mit mindestens
um die 2MHz rüber, zumindest ist das mein bisheriger
Entwicklungsstand. Ich hab die Cam schon gebremst
wo's nur geht um auch nur ne realistische Chance zu haben
Die Daten in den M16 zu übernehmen und dennoch,
bei 16MHz Takt hab ich nur 8 Zyklen um die Daten
reinzunehmen und wieder raus an ein Ram zu schieben,
das ist nicht viel ...
aber ich bin am Ball, mal sehen was ich noch rauskitzeln kann

Zitat:

---

Ich hatte keine Lust das Rad komplett neu zu erfinden.
Dir fehlt bestimmt die Ahnung so etwas wie die CMUCam selbst zu programmieren.
Weißt du, wie kompliziert das ist?

---

Ich hab die erfahrung gemacht, dass man mit den Herausforderungen wächst. und ich möchte mir eben nicht etwas fertiges kaufen, sondern das schon selbst entwickeln.

Es ist schon richtig, dass ich nicht so viel erfahrungen im bereich der Robotik hab, aber z.B. C/c++ beherrsche ich schon einigermaßen.

Ich hoffe ihr versteht das...
Ich finde es eben das interessanteste an dem hobby (so denke ich würd es den meisten hier gehen) die technik zu entwickeln.

Eben aus diesem grund hab ich mich dafür entschieden was eigenes zu machen und nicht eine fertige einheit zu kaufen...
Ich hoffe ihr versteht das.

MfG Jürgen

Ich befasse mich seit einiger Zeit mit dem Thema. Das ganze basiert zurzeit auf einer Gameboy-Kamera. Die Kamera liefert ein Graustufenbild von 128 * 128 Pixel, wobei der Grauwert jedes Pixels analog geliefert wird. Zum Auslesen verwende ich einen Mega32 mit 32 Kilobyte externem SRAM. Das Bild wird per RS232 (115000 Baud) an den PC geliefert und dort von einem Java-Programm angezeigt. Die Bildqualität ist eigentlich - wenn man mal die richtigen Einstellungen gefunden hat, und das dauert - sehr gut.

Zurzeit arbeite ich daran, einen Ball zu erkennen. Dazu wird das Bild in ein Kanten-Bild umgewandelt und darauf ein Hough-Algorithmus angewendet, der den Ball eigentlich sehr zuverlässig findet. Anfänglich machte alles der PC, mittlerweile habe ich aber die Kanten-Erkennung an den Controller delegiert und als nächstes wird auch noch der Hough-Algorithmus auf den Controller portiert.

Keine Ahnung was es wird, vielleicht ein Ballsammler-Roboter? Für Fragen & Ideen bin ich immer zu haben. O:)

Die Gameboy-Cam ist eigentlich ein Super-Einstieg. Hier im Forum gibt es einen langen Thread dazu.

Die Kann im Übrigen auch schon selbst die Kanten detektieren. Dadurch wird im Controller wieder Rechenleistung frei.

Du solltest Dir erstmal klar werden, welche Auflösung Du brauchst und welche Framerate. Daraus kannst Du dann abschätzen, wieviel Rechenleistung Du brauchst. Ich könnte mir durchaus vorstellen, dass da ein AVR ausreicht, andererseits gibts ARM7-Boards mit 64KB RAM (sowas wie auf dem POB-Eye) für etwa 70 Euro.

Vitis schreibt, bei den AVRs gibts das Problem mit der Datenerfassung, aber da hätte ich eher die Adressierung extern gemacht und so unabhängig vom AVR ins RAM geschrieben.

Zitat:

---

Zitat von ogni42

Die Gameboy-Cam ist [...] kann im Übrigen auch schon selbst die Kanten detektieren. Dadurch wird im Controller wieder Rechenleistung frei.

---

Jein. Der Kantenerkennungs-Algorithmus der GB-Cam liefert leider keine absolut scharfen Kanten, d.h. ein reines schwarz-weiss Bild, sondern verstärkt lediglich. Es muss also nach wie vor eine Entscheidung durchgeführt werden, um die Farbtiefe auf 1 Bit zu bringen. Und zudem hat der Controller während dem Auslesen genügend Zeit, eine Kantenerkennung durchzuführen, da man immer wieder auf den A/D-Wandler warten muss.

Zitat:

---

Zitat von Markus4004

Du solltest Dir erstmal klar werden, welche Auflösung Du brauchst und welche Framerate. Daraus kannst Du dann abschätzen, wieviel Rechenleistung Du brauchst. Ich könnte mir durchaus vorstellen, dass da ein AVR ausreicht, andererseits gibts ARM7-Boards mit 64KB RAM (sowas wie auf dem POB-Eye) für etwa 70 Euro.

---

Mit einem AVR kommt man auf jeden Fall schnell ans Limit, sowohl vom Speicher als auch von der Rechenleistung her. Nur schon, um das Bild mit 8 Bit Farbtiefe zu speichern (128 * 128 * 1 Byte = 16 KByte), braucht man ein externes RAM. Selbst ein 1 Bit Bild (128 * 128 * 1 Bit = 2 KByte) füllt das interne RAM randvoll. Wenn dann jedes Pixel einzeln, wahlfrei und oft x-fach aus dem externen RAM geholt werden muss, dann frisst das enorm Zeit.

Die Rechenleistung des AVR setzt natürlich relativ enge Grenzen. Echtzeit-Bearbeitung z.B. für einen halbwegs schnellen Roboter, kann man mehr oder weniger vergessen. Bei einem 128 * 128 Bild dauert die Verarbeitung des Bildes bei einem 16 MHz Quarz pro Befehl, den man durchschnittlich auf ein Pixel anwendet, 1 ms. Und es dürfte klar sein, dass sich schnell hunderte bis tausende Befehle pro Pixel ansammeln. (z.B: http://de.wikipedia.org/wiki/Hough-Transformation)

Für einfache, nicht zeitkritische Anwendungen sollte ein AVR fürs erste reichen. Für alles andere ist er meiner Meinung nach überfordert. Die GB-Cam sollte für erste Versuche aber gut ausreichen, es bräuchte wohl schon einen mächtigen Controller, der die Bilder der GB-Cam voll ausreizen kann. Wobei die GB-Cam an Beleuchtung, Grösse und Entfernung der Objekte doch gewisse Ansprüche stellt...

Zitat:

---

Zitat von mirage

Mit einem AVR kommt man auf jeden Fall schnell ans Limit, sowohl vom Speicher als auch von der Rechenleistung her. Nur schon, um das Bild mit 8 Bit Farbtiefe zu speichern (128 * 128 * 1 Byte = 16 KByte), braucht man ein externes RAM. Selbst ein 1 Bit Bild (128 * 128 * 1 Bit = 2 KByte) füllt das interne RAM randvoll. Wenn dann jedes Pixel einzeln, wahlfrei und oft x-fach aus dem externen RAM geholt werden muss, dann frisst das enorm Zeit.

---

Es gibt auch AVRs mit 8KB internem RAM. Aber das meinte ich nicht, ich bin eigentlich schon von externem RAM ausgegegangen.

Worum es mir ging:
Wie groß die Auflösung sein sollte hängt davon ab, wie weit er sehen will und wie groß das kleinste erkennbare Objekt sein soll. Da kann es durchaus sein, dass ihm 80x60 Pixel reichen. Und 80x60 Pixel sind weniger als ein drittel von 128x128.

Zitat:

---

Die Rechenleistung des AVR setzt natürlich relativ enge Grenzen. Echtzeit-Bearbeitung z.B. für einen halbwegs schnellen Roboter, kann man mehr oder weniger vergessen. Bei einem 128 * 128 Bild dauert die Verarbeitung des Bildes bei einem 16 MHz Quarz pro Befehl, den man durchschnittlich auf ein Pixel anwendet, 1 ms. Und es dürfte klar sein, dass sich schnell hunderte bis tausende Befehle pro Pixel ansammeln. (z.B: http://de.wikipedia.org/wiki/Hough-Transformation)

---

Ich bin jetzt davon ausgegangen, dass er für den Anfang farbige Klötzchen erkennen will oder sowas in der Art. Und dafür sollte ein AVR schon reichen.

Markus

Zitat:

---

Zitat von Markus4004

Worum es mir ging:
Wie groß die Auflösung sein sollte hängt davon ab, wie weit er sehen will und wie groß das kleinste erkennbare Objekt sein soll. Da kann es durchaus sein, dass ihm 80x60 Pixel reichen. Und 80x60 Pixel sind weniger als ein drittel von 128x128.

---

Und da gibt es in der Tat wieder unterschiede in _Grössenordnungen_. Einen Ball zu erkennen, der unmittelbar vor der Kamera liegt zu erkennen, oder aber einen Ball irgendwo im Zimmer zu finden - zwischen diesen Aufgaben liegen Welten an die Anforderungen der Kamera. Die benötigte Auflösung dürfte etwa mit dem Quadrat der Entfernung steigen...

Zitat:

---

Zitat von Markus4004

Ich bin jetzt davon ausgegangen, dass er für den Anfang farbige Klötzchen erkennen will oder sowas in der Art. Und dafür sollte ein AVR schon reichen.
Markus

---

Wobei er dann irgendwelche Farbseh-Möglichkeiten braucht. Im einfachsten Fall einfach einen Farbfilter vor die Kamera. Farbkameras werden dann aber schnell teurer und vorallem aufwändiger zum auslesen - da ist die Gameboy-Cam halt schon optimal. Für 10 EUR gekauft, Schaltung mit 1 uC, 2 Logik-ICs, 1 SRAM, AVR mit 11 MHz niemals an der Grenze.

Die GBCam hat mehrere Kantenerkennungsmodi (s. Datenblatt, Edge-Extraction und Edge-Enhancement). Letzterer verstärkt die Kanten, ersterer liefert ein Binärbild.

Auf den ADWandler muss man nur dann warten, wenn man nicht genügend Speicher hat, sprich: nur auf dem aktuellen Bild arbeiten kann. Ansonsten lässt sich das per ISR erledigen und parallel dazu auf einem anderen Puffer arbeiten.

Also würdet ihr mir von einem Einstieg über USB-Webcam doch abraten?

Zitat:

---

Worum es mir ging:
Wie groß die Auflösung sein sollte hängt davon ab, wie weit er sehen will und wie groß das kleinste erkennbare Objekt sein soll. Da kann es durchaus sein, dass ihm 80x60 Pixel reichen. Und 80x60 Pixel sind weniger als ein drittel von 128x128.

---

Ich sag mal so... es ís doch immer besser mehr daten "zur auswahl" zu haben, oder nicht?

mit eben einem höher aufgelöstem bild kann ich doch bessere ergebnisse erzielen.(Bitte korrigiert mich, wenn ich falsch liege...)

und wenn das (zum größten teil) nur einen finanziellen unterschied macht, mit welcher auflösung ich arbeite, dann soll mir das irgendwo egal sein...
ich mein.. dafür ist das mein hobby.

mfg jürgen

Sicher ist das besser. Es kostet nur mehr Speicher und Rechenoperationen. Es kommt eben immer auf das Gesamtsystem an. Es ist nicht nur ein finanzieller Unterschied, da z.B. die ATMega Familie per XMEM Interface nur max 64kByte RAM adressieren kann. Wenn Du Bilder hast, die größer sind, fängst Du dann ganz schän zu tricksen an.

Wenn Du Dich erst mal nur mit Bildverarbeitung beschäftigen willst - und nicht sofort einen Roboter per BV steuern - bist Du mit einer preiswerten USB Kamera und einem PC besser dran.

OK, dann werd ich mir als erstes ne USB-Cam holen. damit werde ich mich erstmal nur mit Bildverarbeitung beschäftigen. wenn ich das dann hinbekommen hab, werd ich mich eben mit ner anderen kamera beschäftigen, die dann auf meinen roboter kommt.

mfg Jürgen

Zitat:

---

Zitat von ogni42

Es kommt eben immer auf das Gesamtsystem an.

---

Genau so ist es. Je nachdem was du tun willst und worauf das System schlussendlich laufen soll, wirst du komplett andere Ansätze verfolgen müssen. Teleskop, Brille, Infrarotkamera oder Foto-Apparat, sie alle dienen uns irgendwie zum Sehen - auf ganz unterschiedliche Art und Weise, was sich in völlig unterschiedlicher Technologie ausdrückt.

Ganz ähnlich ist die Frage, ob du z.B. mit der Kamera...
...Echtzeit-Kollisionsabfrage,
...Objektsuche in einem Raum,
...Unterscheidung von eingesammelten Objekten,
...Texterkennung
etc. realisieren willst. Überlege dir am besten schon am Anfang, was du _ungefähr_ tun willst und dimensioniere deine Experimentierplattform entsprechend.

Bis jetzt ist angedacht, dass ich die Kamera zur Kanten- uznd Objekterkennung verwende.
Ich mach mich jetzt halt als ersten drann und hol mir ne webcam und eigne mir das wissen zur bilderkennung via PC an. wenn das alles funktioniert wollt ich mir nen anderes kamera modul holen und nach und nach alles auf µC verlagern...

MfG JÜrgen

Hallo zusammen!

Leider hatte ich, da ich für mein Studium in München aus dem guten Hessen umziehen musste nicht wirklich viel Zeit für die Robotik gehabt...
Das soll sich jetzt wieder ändern.

Ich hab mir jetzt ne Webcam besorgt. Das ist die PS2 Eyetoy Cam. Mit der möcht ich nun den Einstieg in die Bildverarbeitung hinbekommen. Ich hab aber keine Ahnung, wie ich überhaupt das Bild abfangen kann...

Mit welcher Software muss ich denn das überhaupt Programmieren?
Gehe ich da recht in der Annahme, dass ich mir zum einen eine VB oberfläche Programmieren muss und dann aber eben ein Programm für die Bildverarbeitung in C/C++ schreiben muss?
Und wie bekomm ich dann die Verbindung zwischen dem capturen und dem umwandeln hin?

MfG Jürgen

Du kannst natürlich alles in C++ machen. Wenn Du auf dem PC mit Windows arbeitest gibt es zwei Möglichkeiten: Entweder über DirectX oder WDM (vielleicht kennt jemand noch eine dritte Möglichkeit).

Da musst Du Dich dann durch die Beschreibungen qiälen. Es gibt IIRC aber im Netz einige Programmbeispiele für C++. Einfach mal nach ggln.

hi,
ich kann dir dafür matlab empfehlen( studentenversion 80€) oder aber scilab, ist nicht ganz so schnell, aber umsonst und ähnlich aufgebaut.
mfg jeffrey

Ich hab im moment ein eher generelles Problem bzw. mehrere Probleme:

1. wie kann ich meinem programm sagen, dass es ein bild bzw. einen stream von meiner kamera verarbeiten soll

2. wie kann ich überhaupt dieses Bild/stream in einem Programm dann anzeigen lassen?

MfG JÜrgen

Hallo zusamen!
Ich hab jetzt ne weile gegoogelt, finde aber irgendwie nicht die antworten, die ich benötige..
Wie habt ihr das denn z.b. hinbekommen, die Daten eurer webcam auslesen zu lassen?

MfG Jürgen

Hardware mit GBCam und AVR gebastelt. Die Bilder dann an den PC übertragen.

Für WebCams (per USB am PC angeschlossen) gibt es SDKs oder Du nimmst VfW, bzw. DirectX