Hallo, erstmal vorweg ich bin in sachen bildverarbeitung durchaus vertraut und hab mich da auch schon an den ein oder anderen Filter herangewagt, jedoch ausschließlich auf dem PC über C, VHDL hab ich jetzt noch nicht so viel gemacht bin aber mit den Basics vertraut. Mir geht es hier auch weniger um den VHDL-Code an sich sondern mehr um die Theorie dahinter, trotzdem wär ich auch über vhdl-code oder beispielprojekten zum thema sehr froh Jetzt zum Projekt, es geht darum ein cmos-Kamera Modul an ein FPGA und anschließend an einen Blackfin anzubinden, der Blackfin schickt die Bilder dann komprimiert weiter, das wesentliche dahinter ist es sollte in Echtzeit laufen, daher ist mir der Blackfin alleine zu langsam. Die Kamera ist ein OV9655-Modul mit 1.3MPixel, sollte es bei diesem jedoch an der Verfügbarkeit scheitern kann auch ein OV7725 angeschlossen werden, die HighResolution ist jedoch nur für fotos vorgesehen, in Echtzeit sind die Bilder also in VGA-Auflösung Also jetzt zum Problem: Die Kamera schickt mir ja immer 10Bit daten Paralell und dazu noch einen Vertical-Sync output, die Daten werden bei diesem Modul ja Zeilenweise rausgeschrieben immer 10 Bit hintereinander. Wenn ich jetzt aber einen Sobel-Filter auf das System Anwenden will müssen ja vom Bild mindestens 3 Zeilen gespeichert sein, da ich ja sonst nicht die nötigen Daten in der Vertikale hab, aber das Verbraucht doch bei solchen Auflösungen jede Menge speicher wenn ich da immer 3 Zeilen speichern muss, bei Filtern mit größeren Matrizen wird die Speichermenge dabei ja auch noch mehr http://thomaspfeifer.net/fpga_dsp_bildverarbeitung.htm Ich hab jedoch gelesen dass bei diesem Projekt durchaus größere Datenmengen und größere Bilder (3MegaPixel) im FPGA verarbeitet werden Ich wollte euch deshalb Fragen ob ihr vielleicht wie man einen Sobel oder auch einen anderen Filter auf so große Bilder anwenden kann, ich glaub kaum dass hier das Bild zuerst in einen großen RAM gepackt wird und dann erst der Filter angwendet wird. Danke schon mal im voraus für die Hilfe lg Peter
Das braucht überhaupt keinen grossen Speicher. Du schreibst doch 3 Zeilen sind nötig. Neben der aktuellen Zeile 2 vorhergehende, d.h. 2 müssen gespeichert werden. Für den VGA Fall mit 9bit Auflösung (*), und 3x3 Matrix mit festen einstelligen Koeffizienten kriegt man das vermutlich sogar in einen Lattice MachXO2-640 rein. (*) 9 Bit deshalb, weil die beiden EBR des XO2-640 (aka BlockRam) 9 bit x 1024 organsiert werden können.
Danke für die Antwort :) Also wird das wirklich so mit Speichern der vorhergehenden Zeilen gemacht, ich dachte da gibts irgendeinen Trick dazu wie man das Speichern dieser Daten umgehen kann weil wenn ich jetzt mal von dem Projekt ausgehe was ich gepostet habe braucht das dann ja mindestens 13kB an RAM speicher zum speichern von zwei Zeilen Nur kurz noch dazu der Sensor schickt mir RAW-RGB daten
Du hast gar keine andere Wahl, als die Zeilen zu speichern, da sie vom Sensor nur einmal geliefert werden. Bei komplexen Algorithmen benötigst Du das gesamte Bild, bei linearen einfachen Prozeduren nur einige Zeilen. Beispiel hier: Beitrag "Re: Frage zu 2-dimensionalen Bildfiltern" Was sind denn so Deine diesbezüglichen Kenntnisse in C? Wir hätten da gerade wieder mal etwas Bedarf.
:
Bearbeitet durch User
Ich würde zuerst mal die 10 auf 8 bit kürzen. Die beiden Bits am Ende rauschen wahrscheinlich nur, und werden sonst wohl kaum noch wargenommen. Dann, worauf willst du den Filter laufen lassen? Auf R,G,B einzeln? Oder nur auf den Helligkeitswert? Oft reicht doch schon eine Kantendetektierung im Helligkeitsbereich aus. Nehmen wir mal RGB an, dann sie das pro VGA-Zeile 640*3 Bytes (bei 8 bit/Farbwert), das macht also 1920 Bytes. 3 Zeilen davon sind 5760 Bytes, oder 46 KBit. Selbst der kleinste Sparten-6 hat schon 75 KBit Distributed Ram. Dazu kommt noch Block Ram. Wo ist jetzt das Problem mit den 3 Zeilen?
Peter Kremsner schrieb: > > habe braucht das dann ja mindestens > 13kB an RAM speicher zum speichern von zwei Zeilen > > Nur kurz noch dazu der Sensor schickt mir RAW-RGB daten Alles kein Problem, der von mir erwähnte MachXO2-640 ist ein FPGA aus der alleruntersten Leistungsklasse. Der grösste aus der MachXO2 Familie hat bereits 26 1k*9 RAM Blöcke, und ist immer noch unterste Schublade. "Richtige" FPGAs (Lattice ECP2/3, Xilinx Spartan3/6, Altera Cyclone 2/4) haben viel mehr!
PittyJ schrieb: > Ich würde zuerst mal die 10 auf 8 bit kürzen. Die beiden Bits am Ende > rauschen wahrscheinlich nur, und werden sonst wohl kaum noch > wargenommen. Warum kürzen, die kosten im FPGA nicht viel. Manche Sensoren spucken bei einer guten Stromversorgung nicht mal so viel Rauschen aus. Aber ok, bei den manchen Omnivision-Vertretern waren die LSBs oft nicht mit Ruhm behaftet... Ansonsten habe ich betr. Blackfin und FPGA mit einigen gut verfügbaren Coremodulen gute Erfahrung gemacht. Wenn man doch mal noch DDR3-Ram braucht, lohnt sich ev. ein Spartan6-Modul mit bereits existierender Referenzimplementation für die DDR-Anbindung. Der Blackfin macht allerdings bei mir auch nur noch den Video-Server per TCP/IP, die gesamte BV/Kompression wurde so allmählich ins FPGA migriert. Zum Filter-Algo kam mir mal ein schönes Bild unter, nur wenn ich noch wüsste wo... Im Prinzip ist ein 3x3-Kernel recht einfach implementiert: +-------------+ (eine Bildzeile) >###************< <###************< <###************ > : Aktuelles Datum der Vorstufe (Sensor) # : Schieberegister (SR) auf Gatter-Basis * : BlockRAM-delay-FIFO Bei jedem Zyklus füllst Du deine Berechnungs-Pipe und reichst die Daten ins nächste SR weiter, bzw. führst die Zähler der delay FIFOs nach. Was bei Zeile (i) hinten rausrutscht, rutscht ins nächste SR in (i+1), oben gekennzeichnet mit '<'. Für manche Sobel brauchst Du ev. eine weitere derartige Stufe (je eine für horizontal/vertikal). Und dann sind da noch die Ränder, die ev. etwas Spezialbehandlung brauchen, oder du "cropst" sie einfach nachträglich weg. War jetzt vielleicht etwas wischiwaschi, aber so funktionieren m.W. so gut wie alle simplen Kernel-Ops. Relevant sind ev. noch die Anzahl Multiplier auf dem Chip, um die Faltung auch taktsynchron/resourcenarm zu schaffen. Schlussendlich gibts dann noch ein paar Delay-Kniffe, um die vorgegebene Taktfrequenz zu schaffen... Grüsse, - Strubi
Danke für die vielen guten Antworten :) Ich werd dass dan alles mal bei gelegenheit implementieren Robert Kuhn schrieb: > Was sind denn so Deine diesbezüglichen Kenntnisse in C? Wir hätten da > gerade wieder mal etwas Bedarf. Naja ich hab in C bisher nur auf Bilder und nicht auf videos alogrithmen ausgeführt und hab im Prinzip nur 2D Faltungen gemacht, also Weichzeichner, Kantendetektion, schärfe Filter usw
Peter Kremsner schrieb: > Robert Kuhn schrieb: >> Was sind denn so Deine diesbezüglichen Kenntnisse in C? Wir hätten da >> gerade wieder mal etwas Bedarf. > > Naja ich hab in C bisher nur auf Bilder und nicht auf videos alogrithmen > ausgeführt und hab im Prinzip nur 2D Faltungen gemacht, also > Weichzeichner, Kantendetektion, schärfe Filter usw Das Thema hat sich erledigt, wir haben jemanden beauftragt.
Schick ihm doch besser eine PN, oder nicht?
Strubi schrieb: > +-------------+ (eine Bildzeile) > >###************< > <###************< > <###************ > Bei jedem Zyklus füllst Du deine Berechnungs-Pipe und reichst die Daten > ins nächste SR weiter, bzw. führst die Zähler der delay FIFOs nach. > Was bei Zeile (i) hinten rausrutscht, rutscht ins nächste SR in (i+1), > oben gekennzeichnet mit '<'. Den Punkt verstehe ich nicht. Wieso fällt da was raus, läuft über oder verschiebt sich in die nächste Zeile?
Was verwendet ihr, eingekaufte Biblotheken, wenn ja wie heissen diese und was kostet es, oder habt ihr alles selbst gemacht. Ich habe viel auf PC gemacht.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.