Es geht um die Verarbeitung des Datenstroms direkt vom Bildsensor weg, also etwas Vorverarbeitung (Weißabgleich, Pixelkorrektur, Rauschreduktion, evtl. HDR) und Kompression auf handlebare Datenraten (<100MByte/s). Bildsensoren haben oft beeindruckende Schittstellen >15Gb/s. Consumer-Geräte haben dafür natürlich einen ASIC verbaut; sollen es aber nur wenige Stück werden, was verwendet man da am sinnvollsten? Am fexibelsten ist sicher eine Kombination aus FPGA und DSP. Mich würde interessieren, was da so in etwa geeignet wäre? Die top DSPs sind alle ziemlich mit Funktionen überladen, die in der Anwendung nicht gebraucht werden wie Ethernet MACs, Kryptographie-Einheiten etc... Dafür misse ich eine vernünftige Schnittstelle zum Sensor, die GPIOs sind zu langsam, andere Schittstellen meißt zu schmal (die Schittstellen sind oft 24bit breit). Mit dem FPGA kann man da sicher was hinhacken, aber da muss es doch elegantere Möglichkeiten geben? DSPs scheinen ja ordentlich zu Buche zu schlagen und die größeren bewegen sich preislich locker oberhalb von top Desktop-CPUs. Kurz: wie machen es Geräte wie Kino-Kameras oder im Bereich Machine Vision?
ImageProcessor schrieb: > Consumer-Geräte haben dafür natürlich einen ASIC verbaut; sollen es aber > nur wenige Stück werden, was verwendet man da am sinnvollsten? FPGA. Die Schnittstellen von Bildsensoren sind individuell. > Am fexibelsten ist sicher eine Kombination aus FPGA und DSP. > Mich würde interessieren, was da so in etwa geeignet wäre? Was genau sind Deine Anforderungen? > Mit dem FPGA kann man da sicher was hinhacken, > aber da muss es doch elegantere Möglichkeiten geben? Hinhacken lassen. Helion Vision bietet für Lattice an. Es gibt Kamera-Kits für und von Xilinx und Altera. Allerdings weniger mit >15Gb/s. > DSPs scheinen ja ordentlich zu Buche zu schlagen und die größeren > bewegen sich preislich locker oberhalb von top Desktop-CPUs. Wenn Du einerseits Bildsensoren mit Datenraten von >15Gb/s ansprichst und anderseits die Preisregion von top Desktop-CPUs als unpassend empfindest, dann verstehe ich das nicht. Welchen Bildsensor möchtest Du verwenden. > Kurz: wie machen es Geräte wie Kino-Kameras oder im Bereich Machine > Vision? FPGA oder ASIC, wie Du schon festgestellt hast.
Dieser Bildsensor ist in Kameras in der 500€-Klasse (incl. Objektiv etc.) verbaut, kann also nicht so extrem viel kosten: http://www.aptina.com/assets/downloadDocument.do?id=979 Auf FPGAs habe ich kaum was gefunden, das bis 1080p funktionieren würde; DSPs schienen mir da eher geeignet zu sein. Allerdings müsste man da die Kameradaten erst in PCIe oder Ähnliches konvertieren, um sie in den DSP zu bekommen.
ImageProcessor schrieb: > Auf FPGAs habe ich kaum was gefunden, das bis 1080p funktionieren würde; Kaum was kostenloses an IP Cores meinst Du sicher ;-)
Hallo, bei solchen Anwendungen ist eine Kombination aus FPGA oder ASIC und Prozessor nötig. Der FPGA / ASIC kümmert sich als aller erstes um das empfangen und richtgie mappen der empfangenen Daten. In ihm können auch direkt erste Bearbeitungen gemacht werden: Korrekturen für tote Pixel Debayering Weißabgleich, Gamma etc. Farbraumumwandlung All diese Aufgaben geschehen unkomprimiert und in echtzeit. Datenraten von 300Mbit/s PRO LANE sind bei heutigen Bildsensoren nichts besonderes. Dann hast du meist noch mehrere Lanes parallel. Das packt selbst der beste DSP nicht. Ein FPGA bewältigt sowas locker. Die Kompression würde ich wahrscheinlich eher als Aufgabe für den Prozessor sehen. Grüße, Jost
ImageProcessor schrieb: > Dieser Bildsensor ist in Kameras in der 500€-Klasse (incl. Objektiv > etc.) verbaut, kann also nicht so extrem viel kosten: > http://www.aptina.com/assets/downloadDocument.do?id=979 Prinzipiell schon, weil der Hersteller der 500EUR-Kameras eine andere Stückzahl abnimmt als Du. > Auf FPGAs habe ich kaum was gefunden, das bis 1080p funktionieren würde; > DSPs schienen mir da eher geeignet zu sein. Ob es einen aktuellen Xilinx-FPGA gibt, der den von Dir genannten 4K-Sensor bedienen kann, weiß ich nicht (SLVS ?). Für 1080p gibt es Lösungen. Edit: Wenn Du am Ende komprimierte Bilddaten haben möchstest, dann nimmst Du vielleicht doch gleich die 500EUR Consumer-Kamera und greifst die Daten an den Kontakten der Flashkarte ab.
Für 1080p60 Kompression mit H.264 finde ich für FPGAs Belegungen von > 100k LUTs auf den neuesten Familien bei mehr oder weniger voller Ausnutzung der möglichen Speicherbandbreite. Dass das mit der ca. 4-fachen Datenrate noch funktionieren soll bezweifle ich. Und doch können immer mehr Consumer-Geräte wie Smartphones 4k-Video aufnehmen, d.h. die Kompression funktioniert problemlos auf einer "normalen" CPU. Daher kommt die Frage, ob nicht eine Standard-CPU angemessener wäre?
Die Smartphones machen das mit der GPU. Ebenfalls die GPU nutzen Raspberry und Derivate über MIPI. Soweit 1080p. Jost hat ja bereits geschrieben, dass für die (h264)-Kompression der FPGA vielleicht nicht die beste Wahl ist. Wenn Du aber keine andere Wahl hast, bleibt nur der FPGA mit der Brechstange (mehrere FPGAs parallel). Es wäre günstig, wenn Du darlegen könntest, was Deine Selbstbau-Motivation ist und warum Du für 4K mit Kompression nicht einfach die Daten von einer gekauften Kamera (Flashinterface, 1-10GigE, Framegrabber usw.) abholst. Die Selbstbaulösung wird ein Vielfaches teurer.
Ok, das war sehr undeutlich ausgedrückt... Natürlich übernimmt die Codierung ein Hardwarebeschleuniger mit am SoC, allerdings ist sowas ja mehr oder weniger auf jeder moderneren (PC)-CPU mit drauf. Die Alternative zum dicken FPGA wäre doch, einen kleinen FPGA zu nehmen, der evtl. einfache Vorverarbeitung macht und ansonsten vor allem da ist die Daten vom Bildsensor z.B. auf PCIe zu wandeln, so dass man den rest auf einem gewöhnlichen PC machen könnte. Klar ist das absolut nicht stromsparend etc., aber es scheint mir eher bezahlbar und machbar als die Alternative aus FPGA und evtl. DSP.
Das Ziel ist, die Möglichkeit zu haben, während interessanter Momente einige Sekunden die volle Datenmenge zwischenspeichern zu können, ohne dabei den kontinuierlichen Livestream zu unterbrechen; Das Video soll mehr oder weniger unkomprimiert (aber in geringerer Auflösung, z.B. 1080p) live übertragen werden, gleichzeitig aber komprimiert weggespeichert werden. Das ganze kommt einer Slow-Motion-Kamera mit zusätzlicher Liveübertragung ziemlich nahe.
Für 4K ist noch das noch nicht auf jeder CPU drauf. Dafür gibt es teure Kameras, die wie gesagt dennoch ein Vielfaches günstiger sind als eine Selbstbaulösung. Und für 1080p kannst Du den Raspberry für 20EUR her nehmen und über Netzwerk h264 rausstreamen.
Lars R. schrieb: > Die Smartphones machen das mit der GPU. Ebenfalls die GPU nutzen > Raspberry und Derivate Umgangssprachlich sagen das zwar viele so, aber es ist natürlich nicht die GPU ansich (also nix OpenCL oder so), sondern ein fester dafür optimierter IP Core, der manchmal halt bei der GPU mit dabei ist. 4K, Selbstbau, Kostengünstig Zwei von den Punkten kannst Du Dir aussuchen ;-) Wobei es drauf ankommt was Du unter kostengünstig verstehst - aber wenn eine PC CPU für Dich teuer ist dann lass es lieber.
Ich baue keine 4K-Kameras. Aber vielleicht kaufe ich eine 10GigE ein und verkaufe die an den TE als Selbstbaukamera.
Klar, dass das Selbstbau nicht wirtschaftlich ist (wann ist er das schon, wenn man ehrlich ist?). Es geht viel mehr um den Weg und darum, am Ende die volle Kontrolle darüber zu haben. Auch wenn es dann schon veraltete Technik ist, wenn's mal fertig wird. Aber wenn es so ein tolles, günstiges, voll kontrollierbares Kameramodul schon gibt finde ich auch eine andere Herausforderung.
>Es geht viel mehr um den Weg
Bla, bla, bla. Rumgetrolle pur.
@ImageProcessor: Ne, das wäre schon eine feine Sache, mach ruhig. Wir sind ja auf jede Deiner Fragen eingeganen. Hoffe das hilft Dir weiter. Halt uns auf dem Laufenden. Wenn Du's fertig hast, kauf Dir eventuell welche ab.
Definitiv FPGA. Allerdings brauchst du dann auch ein großes FPGA mit viel Logik. Zum Vegleich wir haben mal für ein ähnliches Projekt ein FPGA verwendet, das bei einem Bestücker bei einer Abnahme von 1000 Stück pro Jahr gut 160 Euro gekostet hat. Ein passendes Prototypen-Board kostet dich dann bestimmt nen 1000er, weil du dann ein Multilayer-Board brauchst, möglicherweise sogar HDI! Wenn du über das Ganze nicht so bescheid weißt und das Projekt alleine durchziehen willst, dann kann ich dir davon nur abraten! Du kannst mit Kosten von mindestens 1000 Euro rechnen und alleine das PCB-Design wird dich alleine für mehrere Monate beschäftigen und dann muß ja auch noch Code geschrieben werden, der dem System das Leben einhaucht. Also mache es nicht!
Stephan schrieb: > Du kannst mit Kosten von mindestens 1000 Euro rechnen Das reicht nicht mal ansatzweise wenn da wirklich H.264 @4K gemacht werden soll ;-)
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.