www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Bildvorverarbeitung


Autor: Lukas M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich brauche einige Anregungungen für mein Abschlussprojekt:
Zwei möglichst große Bilder (je min. VGA (640x480) 24Bit RGB) sollen
gleichzeitig aufgenommen werden, der Kontrast und die Helligkeit
optimiert sowie die Kanten gesucht und markiert werden.
Die Bilder zeigen ein zu untersuchendes Objekt von verschiedenen
Blickwinkeln.
Eine Erweiterung auf 3-6 Bilder soll auch möglich sein.
Die Bilder sollen dann mittels einer geigneten Schnittstelle (USB,
Firewire?) an einen PC geschickt werden, wo sie weiterverarbeitet
werden.
Ich suche also
1) Erhältliche CCDs (Farbe)
2) Einen Mikrocontroller oder DSP der sowas schaffen kann
3) Ev. Alternativen
Am Prinzip (aufnehmen - Vorverarbeiten - an PC sendem) kann ich nichts
mehr ändern, aber ich bin ziemlich frei, was die anderen Komponenten
betrifft.
Je mehr Bilder pro Sekunde, desto besser.
Minimal sollten jedoch 0.5 Bilder/s geschossen werden.
Wichtig ist aber nur, dass sie gleichzeitig gemacht werden (Zu
beobachtendes Objekt bewegt sich), wann die Übertragung zum PC
stattfindet, ist zweitrangig.
Für die Kontrast- und Helligkeitsoptimierung muss zuerst der hellste
und dunkelste Punkt gesucht und dann jeder Bildpunkt normiert werden,
d.h. eine Division und eine Adition / Subtraktion sind notwendig.
Pro Bildpunkt.
Für die Kantensuche muss jeder Pixel einmal gelesen und mit 3-6 anderen
verglichen werden.

Autor: JojoS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mal so ein paar Tipps:
- CCD's in Farbe sind sehr teuer. Halbwegs günstige gibts hier:
http://www.theimagingsource.com/de/welcome/
- wenn sich die Objekte bewegen brauchst du progressive Scan, d.h.
keine Halbbildaufnahmen wie bei den billigeren CCIT Standard Kameras
- es gibt Framegrabber die haben ein FPGA on Board und machen darin die
genannten Vorberechnungen. Diese Boards sind aber teuer und die
Programmierung ist nicht ganz trivial
- es gibt gute Libs (z.B. Intel IPP, OpenCV) die schon gute Algorithmen
für die Bildbearbeitung und Kantensuche mitbringen. Die Intel Libs sind
sehr gut auf den P4 optimiert und damit superschnell.

Autor: Frank Erdrich (erdi-soft)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
CCDs findest du z.B. bei www.framos.de

Autor: Lukas M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im Prinzip brauche ich einen CCD wie er in einfachen Digitalkameras
verwendet wird.
Ideal wäre wenn der Sensor das Bild in einen auslesbaren Speicher
ablegen würde.
Ich benötige keine besonders aufwändige Kantensuche, sondern eben nur
die Vorverarbeitung, da der Rest im Rahmen eines anderen Projektes auf
dem PC erledigt wird.

Autor: Olaf K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein paar Gedanken:

Willst Du eigentlich die CCD-Kameras selber bauen oder auf fertige
Exemplare (z.B. Webcams/Videomodule) zurückgreifen? Eine CCD-Kamera
selbst zu entwickeln ist durchaus nicht trivial. Einen
USB-Webcam-Treiber auf einem µC allerdings auch nicht. Einen
Framegrabber oder ein Firewire-Interface könnte ich mir schon eher
vorstellen.

CCDs in Farbe sind übrigens durchaus nicht teuer, sondern im Gegenteil
meist deutlich billiger als die S/W-Gegenstücke. Grund ist, daß in
Massenprodukten ausschließlich Farb-CCDs verbaut werden, und daher die
Nachfrage wesentlich größer ist. Aber wie gesagt, ich würde versuchen,
auf fertige Module zurückzugreifen.

Was bedeutet "Die Bilder müssen gleichzeitig gemacht werden"? Webcams
oder einfachere Videokameras kann man nicht ohne weiteres
synchronisieren (bzw. nur mit Hardwareeingriffen), und falls jede z.B.
mit 30 Bildern/s sendet, hast Du einen maximalen Versatz von 1/60 s.
Wenn die Genauigkeit höher sein muß und das Budget nicht gar zu
beschränkt ist, könnte man fertige Firewire-Industriekameras verwenden,
da müßte es Geräte geben, die sich extern synchonisieren lassen. Als
Low-Budget-Lösung könnte man versuchen, Videomodule so umzubauen, daß
eins davon z.B. die Shutter- und Frametransfer-Impulse als "Master"
erzeugt und an die anderen Module weitergibt. Problematisch könnten
dabei unterschiedliche Belichtungszeiten je nach Beleuchtungssituation
sein.
Man könnte auch asynchron laufende CCD-Kameras mit langen
Belichtungszeiten verwenden und mit einer Blitzbelichtung arbeiten.

MfG Olaf

Autor: Lukas M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Selbst entwickeln will ich eigendlich nicht.
Ich muss nur 2 VGA 24Bit Bilder auf einen Mikrocontroller bekommen,
dort einige einfache Algorithmen durchlaufen lassen und das Ergebnis an
einen PC schicken.
Ich brauche auch keine dauernde Aufzeichnung, sondern muss nur auf ein
externen Signal (Minimalabstand 0.5 Sek) die Bilder einlesen.

Autor: Markus K. (markus-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast Du mal ausgerechnet, wieviele Operationen pro Sekunde Du etwa
benötigst, damit Du überhaupt abschätzen kannst, welchen
Mikrocontroller Du brauchst (oder ob nicht doch ein FPGA das Mittel der
Wahl wäre). Auch über die Geschwindigkeit des Speicherinterfaces
solltest Du Dir Gedanken machen, schließlich willst Du mindestens etwa
4MB Bilddaten/s verarbeiten. D.h., die Kameras schreiben 4MB rein, Du
brauchst alleine für die Kontrastanpassung 2 Lese- und einen
Schreibvorgang, d.h. nochmals 12MB/s. Kantendetektion kann ich nicht
abschätzen, das kommt auf den verwendeten Algorithmus an.

Autor: Ingo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Kantenextraktion läuft i.d.R. auf dem Grauwertbild (ansonsten muss
das Bild erst in einen anderen Farbraum z.B. HSI transformiert
werden).

640x480*RGB in 8 bit = 3*307200Byte, da sind wir schon beim ersten
Problem: Wenn das Bild als ganzes verarbeitet werden soll musst Du
1MByte RAM frei haben.

Ich vermute mit Kanten markieren meinst Du, die Kanten im aufgenommenen
Bild zu markieren.

Einfache Kantenerkennung (Sobeloperator, da alles andere mit
Multiplikationen verbunden ist), geschätzt (MIPI = Million Instructions
Per Image):

ca 4 Operationen zur Bildung des Grauwertes für ein Pixel
ca. 14 Operationen/Pixel für Sobelfilterung
4 Operationen/Pixel für Histogrammbildung
2 Operationen/Pixel für Kantenentscheidung
3 Operationen/KantenPixel für Markierung
1 Operation/Pixel sonst

Der Rest (Schwellenbildung) ist vernachlässigbar. Die letzten beiden
Operationen mittel ich mal frech zu 2Ops/Pixel

Macht in Summe 26 Op/Pixel => 8 MIPI. Hinzu kommen 40ms für die
Aufnahme des Bildes, sofern der chips 25 Bilder/sec liefert.

Nehmen wir mal an Du hast eine Schnittstelle mit 3MBit zur Verfügung
über die Du ohne Start/Stop-Bits übertragen kannst, dann benötigst Du
für die Übertragung nochmal 640*480*3 Byte/3MBit/s = 2,46s.

Nun fehlt noch die Optimierung von Kontrast und Helligkeit. Das ist
dann schon wieder aufwändiger. Vielleicht ginge ein
Histogrammausgleich. Hab das allerdings noch nicht ausprobiert, wie das
aussieht wenn man von G->RGB schließt. Kann sein, dass dann die Farben
durcheinander kommen. Dafür schätze ich auf jeden Fall nochmals 8
Op/Pixel => 34 Op/Pixel total entspricht 10,5MIPI.

Dabei ist immer angenommen, dass Du ohne Waitstates auf den Speicher
zugreifen kannst.

Also, wenn Du alle 500ms ein Bild verarbeiten willst, musst Du in 460ms
(Rest geht für Bildaufnahme drauf) 10,5MIPI leisten können (ca. 23Mips)
und Du brauchst 1MByte 0-Wait-State RAM.

Wenn Du zwei Bilder gleichzeitig verarbeiten willst sind es 21MIPI in
460ms = 46Mips.

Autor: Lukas M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also müsste ein 66Mhz ARM das schaffen?
USB (2.0?) haben einige eh eingebaut.
Gleichzeitig verarbeiten muss ich eigendlich nicht, es wäre auch
möglich, jeden Sensor einzeln über einen eigenen MC an den PC zu
hängen.
Bleibt noch ndas Problem mit dem Bildaufnehmen.
In welchen Format liefern CCDs ein Bild?
Haben sie einen internen Speicher oder ein seriells Interfache?

Autor: Sssssss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

Also ich würde sagen vergiss es dafür nen DPS/uC zu nehmen.
Selbst auf nem DSP mit 150mhz wirds knapp bis unmöglich.

Mit nem FPGA ist das dagegen eine leichtigkeit.
Ich mache gerade etwas ähnliches mit später 4 CMOS Kameras mit je
25-50fps an einem FPGA (Xilinx Spartan3)

Alleine am einlesen der Bilddaten wirst du mit nem uC scheitern:
Die Kameras geben dir vor wie schnell die Daten reinkommen,
dh pro Pixel bekommst du einen LO->HI Wechsel.
Willst du das mit einem uC einlesen verbrätst du die ganze Zeit mit
warten.

Wobei mit 0.5fps wird das evtl noch klappen, wird aber trotzdem
aufwendig.

Die CMOS Sensoren liefern je nach Typ RGB888, YUV422, YUV444, RGB223,
... (meist einstellbar per i2c)
Gibt da relativ viel Auswahl. Problem ist nur an die Datenblätter zu
kommen.
Das für den Sensor den ich verwende hat 500 Seiten. Haben wir
auch nur über die Uni bekommen und mussten einen NDA unterzeichnen.

Autor: Ingo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also bei 66MHz ARM und mindestens 1MB 0-Wait-State RAM (12ns) wird das
m.E. so teuer, dass Du besser mit einer USB2.0 oder FireWire
Platinenkamera dran bist und die BVV auf dem Host (sprich: PC) laufen
lässt. Da hast Du Zugriff auf diverse Bildverarbeitungsbibliotheken
(mein Favorit: ltilib, findest Du bei sourcefourge) und muss Dir über
Takte etc. keine Gedanken machen.

Wenn Du mit weniger Bildern/s auskämest, wäre ein ARM oder DSP
vielleicht wieder interessant.

Autor: Lukas M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bildverarbeitung per PC ist eben NICHT meine Aufgabe.
Ich soll nur das Bild einlesen, vorverarbeiten und weiterleiten.
100Mhz SDRAM bekommt man billigst aus alten PCs der Pentium III
Generation.
Wie bekomme ich nun ein Bild von einer erhältlichen Kamera in diesen
Chip?
Zuerst wird das Bild im RAM gespeichert, dann greift ein ARM darauf zu
und verarbeitet die Daten und schließlich wird es versendet.

Autor: Markus K. (markus-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Ingo:
1MB SRAM mit 10ns kostet <10€.

@Lukas:
Kennst Du ein ARM-Board, das SDRAM akzeptiert? Selber bauen ist ja wohl
keine sinnvolle alternative.

Hier gibts ein Board mit einem Arm9 (200MHz) und 8MB DRAM für 400€:
http://shop.trenz-electronic.de/catalog/product_in...

Deutlich billiger ist z.B. ein FPGA-Starter-Kit, 1MB SRAM für 100€:
http://shop.trenz-electronic.de/catalog/product_in...

bye
  Markus

Autor: Lukas M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Selbst bauen ist sehr wohl eine Alternative, wenn ich nur wüsste was
aufs Board gehört.
Alle Hilfsmittel zur Platinenerstellung <0,2mm sind vorhanden

Autor: Ingo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Markus: Das ist schon klar, aber es kommen noch der uC,
Hostschnittstelle, Platine und Krimskrams dazu. Und das ist m.E. teurer
als der Unterschied zwischen einer Board-Kamera mit USB2.0 Schnittstelle
und einer ohne bei sonst gleichen Specs.

@Lukas
Ich weiss zwar nicht, warum man Dir als Aufgabe gibt das Rad neu zu
erfinden, da USB2.0 Kameras recht preiswert sind, aber wenn's denn
sein muss:

Also Du brauchst _mindestens_:

pro Kamera: ARM@>66MHz mit jeweils 1MB 10ns RAM, besser sind 2MB, da Du
dann nicht in-place die Bilder verarbeiten musst und ggfs. mit double
buffering arbeiten kannst (Gewinn: <40ms).

Dann muss der Chip jeweils schnell genug sein, um die RGB Signale
direkt in den Speicher schreiben zu können (bei RGB jeweils 8 bit von
den Ports lesen und ins RAM schreiben.) Voraussetzung: Du findest eine
Kamera, die die Signale auch so liefert. Farbraumtrafo YUV->RGB ist
rechenintensiv.

Allerdings könntest Du mit einem YCbCr Ausgang besser beraten sein, da
Du die Kantendetektion dann direkt auf dem Y-Kanal durchführen kannst.
Die Transformation nach RGB kann man danach (auf dem Host) machen, die
Kanten im RGB Bild bleiben dabei erhalten.

Schnittstelle zum Host, schnell genug das Ergebnisbild in der nach der
Berechnung noch bis zum nächsten Bild verbleibenden Zeit zu
übertragen.

Damit Du nicht den Überblick verlierst, solltest Du zuerst mal alle
Anforderungen aufstellen. Insbesondere vermisse ich im Moment, welche
Farbauflösung gefordert ist, welche optischen Parameter eine Rolle
spielen (Ortsauflösung), ... Diese haben ebenfalls Einfluss auf Dein
Design, da z.B. bei geringer erforderlicher Farb- und Ortsauflösung
vielleicht eine 4:2:2 oder 4:2:0 Kodierung der Daten, welche
Schnittstelle zum Host gefordert ist, ....

Autor: Lukas M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
USB Cams die preiswert sind vertragen sich nicht mit ihresgleichen am
selben PC.
Ich habe noch keine USB Kamera <150€ gefunden, deren Treiber mehrere
gleiche Kameras zeitgleich zulässt.
Das Projekt wurde mir zugeteilt.
Der Geg an der sache soll ja eben sein, das der MC einen Teil der
Bildverarbeitung übernimmt und der PC (Via C3 533Mhz) somit bei
mehreren angeschlossensen Kameras entlastet wird.
Anforderungen sind mindestens VGA (640*480) oder besser SVGA (600*800)
oder gar XGA (1024 * 768) mit 8 oder besser 24Bit Farbtiefe.
Der HostPC hat USB 2.0, IEEE 1394 ("Firewire") sowie 100MBit LAN an
schnellen Schnittstellen zur Verfügung.

Autor: Markus K. (markus-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Idee ist also, den PC durch einen Microcontroller zu entlasten, der
10-20% der Leistung des PCs hat. Wäre es da nicht sinnvoller, einen PC
zu nehmen, der eben 10-20% schneller ist?

Autor: Sssssss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

Ich kann dir echt nur raten einen FPGA zu nehmen.
Da gibt es sogar schöne eval Kits mit usb2.0 controller mit dabei.

Der große vorteil fpga gegenüber uC/DSP:
Du kannst bei jeder Flanke an der Vclk leitung die Daten vom Camerabus
übernehmen und direkt ins sram schreiben.
Du brauchst keine Warteschleifen um auf eine vclk/pixelclock änderung
zu reagieren etc.

Dann noch nen SRAM mit 10ns dran und fertig.

Ich hab vorher einige Experimente mit uC, DSP, Framebuffer + DSP, ...
gemacht.
Kannste alles knicken...
Braucht viel zu viel Ressourcen und ist fehleranfällig
(der framebuffer machte bei höheren fps zahlen zb murks etc)

Je nach komplexität deiner Berechnungen evtl FPGA in verbindung mit uC
oder DSP.
Aber nur mit uC/DSP wird das nichts.
Ok ausser du nimmst zb nen Blackfin DSP oder so.
Da is aber auch nix mehr mit von Hand löten...
Die kleineren Spartan3 gibts noch in handlötbarer Form.

Autor: Lukas M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit FPGAs habe ich mich leider noch nie beschäftigt.
Welcher ist für einen Umsteiger von MCs empfehlenswert und kann die
Kameradaten + USB verwalten?
Das andere Problem bleibt der CCD. Welchen Sensor soll ich nehmen?

Autor: Sssssss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

Also ich arbeite seit ein paar Wochen mit dem Spartan3 Board:
http://shop.trenz-electronic.de/catalog/product_in...
(ist aber ohne usb)

Zum anfangen/Einstieg ist das sicher nicht verkehrt.
Zum Beispiel eine Kamera dranpacken und ins sram schreiben lassen und
gleichzeitig auf nem vga monitor in RGB111 anzeigen.
Oder die Daten erstmal langsam per serieller Schnittstelle ausgeben.
USB dranpacken kann man später immer noch ;)

Natürlich musst du dir dann vhdl ansehen, ist nicht ohne.
Aber ich hatte damit keine Probleme. Kannst ja mal ein paar Tutorials
angucken ;)
Oder lad dir das Xilinx Webpack runter und probier drauf los.
Kannst sehr viel simulieren und dann gucken.

Zum Thema Sensor:
Das Hauptproblem sind die Datenblätter. Ohne die läuft nciht viel.
Die meisten Webcams benutzen CMOS Sensoren, am billigsten/am
einfachsten
in der Beschaffung wäre es wohl eine billige Webcam zu nehmen und die
Chips
auszulöten (geht super mit nem Heissluftfön, hab ich schon gemacht)
Da hast du dann gleich noch die passende Optik dazu.

CCD Sensoren kenne ich nur die aus
den Philips ToUCam Pro 840 oder die alte 740 (hat dieselbe elektronik
wie die 840 drin).
Die sind echt um weiten besser als jede vga cmos webcam die ich kenne
(hab einige ausprobiert).

Wie gesagt, nimm den Chip wo du das Datenblatt zu bekommst/findest.
Mit Datenblatt meine ich das vollständige Datenblatt(>>100 Seiten),
nicht diese 30S Zusammenfassungen.
Konfiguriert werden die meisten Sensoren per I2C, wenn du da nicht
die Bedeutungen der einzelnen Register kennst wirds schwierig.

Viele Hersteller machen ein Geheimnis aus den Datenblättern ::)

Autor: AxelR. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast Du in meinen anderen Threads, wo es um ähnliche Sachen ging, schon
die C-328 von Comedia entdeckt? Die gibt es z.B. beim Herrn Sander in
Berlin.
Diese Kamera sendet die Daten gleich als JPG-Datei mit 115200 auf der
seriellen Schnittstelle. Die Parameter(Auflösung etc.) lassen sich auch
über die serielle parametrieren. Ist aber relativ langsam!

http://www.sander-electronic.de/gm00021.html

Gruß
AxelR (vonna arbeit ohne passwort, daher das "y" in der mailadresse)

Autor: Lukas M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andere Frage:
Wie sieht es eigendlich mit Netzwerkkameras aus?
Sind die brauchbar?
Welche ist empfehlenswert?

Autor: Sssssss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

Wenn du noch BV durchführen willst solltest du gucken dass du auf raw
Bildern arbeitest.
Wenn ein Bild erstmal (verlustbehaftet) komprimiert war (zb JPG) dann
findest du darin
die tollsten "Informationen".

Netzwerkkameras hab ich letztens was interessantes gefunden:
http://www.elphel.com/

Dadrin werkelt auch ein fpga den man evtl umprogrammieren könnte.
Denn die Kameras liefern auch nur einen komprimierten Datenstrom wenn
ich
mich richtig erinnere.

Elphel hat auch Mitarbeiter/Benutzer in Deutschland,
einfach mal hinmailen, die sind sehr hilfsbereit.

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.