Moin, ich muss für ein Projekt ein 1080i=720p 25fps Signal in Echtzeit Filtern, z.B. Kantendetektion, Hochpassfilter... Kriegt das ein FPGA hin? Welches bräuchte ich da? Ich kann nur schwer einschätzen, wie leistungsstark der FPGA sein muss.
EchtzeitMuss schrieb: > Ich kann nur schwer einschätzen, wie leistungsstark der > FPGA sein muss. Und hier kann keiner hellsehen, solange du nicht mehr Infos bringst
Moin, So ganz allgemein: > Kriegt das ein FPGA hin? Ja. > Welches bräuchte ich da? Kein ganz kleines. > Ich kann nur schwer einschätzen, wie leistungsstark der FPGA sein muss. Unterschaetze nicht den Aufwand, dein Signal in's FPGA zu bringen und wieder raus. Also alles ausser Filtern. Gruss WK
EchtzeitMuss schrieb: > Moin, > > ich muss für ein Projekt ein 1080i=720p 25fps Signal in Echtzeit > Filtern, > z.B. Kantendetektion, Hochpassfilter... Kriegt das ein FPGA hin? Welches > bräuchte ich da? Ich kann nur schwer einschätzen, wie leistungsstark der > FPGA sein muss. Das bekommen moderne FPGAs locker hin. Mein Tipp: Erst die Algorithmen Entwickeln, durch Simulation verifizieren, dann das FPGA Projekt mit der Hersteller Toolchain aufsetzen und dort kannst du dann munter die verschiedenen FPGAs durchprobieren und schauen ob sie das Design packen. In der Xilinx Welt werden das alle modernen Typen hinbekommen, von Spartan 7 bis Virtex 7, haengt nur davon ab wieviele Algorithmen du hast und wie gross die sind. 1080i @ 25fps sind weit unter 74,25 MHz (abhaengig davon wie du das interlaced vorher prozessierst und bufferst), das erzeugt heutzutage nur ein muedes Laecheln. ;-)
Das solltest du mit nem PC machen. Capture Card rein, und dann gängige Libs wie OpenCV etc. nutzen. Da du scheinbar mit nem FPGA noch nicht wirklich was gemacht hast, wirst du kein HDMI und auch keine Filter für Bildsignale in absehbarer Zeit hinbekommen. Außerdem kannst du alles mit Videodateien testen, bevor du dich um HDMI Capture kümmerst. Der Elgato CamLink wäre perfekt dafür geeignet. Der sollte mit OpenCV gehen.
Donni D. schrieb: > Da du scheinbar mit nem FPGA noch nicht wirklich was gemacht hast, wirst > du kein HDMI und auch keine Filter für Bildsignale in absehbarer Zeit > hinbekommen. Ist ja nicht so dass die gaengigen FPGA Hersteller eine Klicki-Bunti Anwendung anbieten, in der man fertige IPs einfach zusammenklicken kann. Und selbst einfachste Filter haben bei uns schon die Praktikanten hinbekommen. Man muss halt einfach mal anfangen und machen, dann merkt man auch dass alles nur halb so tragisch ist.
Das mag vielleicht sein. Aber ein gesamtes System mit HDMI, Filtern, Ausgabe etc. wird nicht mal eben aus IPs klicki bunti zusammen gesteckt. Zumal je nachdem auch Lizenzkosten fällig werden. Klar, wenn die Zeit da ist, leg los. Aber warum, wenn es sehr viel einfacher, schneller und kostengünstiger am PC geht? Zumal, wenn man mit einem FPGA noch nie was zu tun hatte, und es keine Voraussetzung ist, einen zu nutzen.
Ganz oben steht als Anforderung FPGA. Warum es diese Forderung gibt ist doch erstmal Wurst. Woher nimmst du allerdings an, dass sich der FPGA einfach durch einen PC mit Processing Kette ersetzen laesst? Vielleicht spielen noch andere Bedingungen eine Rolle, warum ein FPGA gewaehlt wurde. Auch weisst du noch nichts ueber den Video in und Output. Vielleicht bekommt er die Video Daten schon parallel, vll. hat er entsprechende Konverter Chips die HDMI nach parallel machen. Die Frage ist: Kann ein FPGA die Beispiel Filter bereitstellen und wie leistungsstark muss er sein? Und die Antwort ist: Ja kann er, sogar relativ einfach und daher muss das FPGA nichtmal sehr gross sein sondern ist eher in der unteren Klasse zu finden. Die Groesse haengt dann letztendlich von der genauen Aufgabe ab. Ich sehe hier noch 0 Grund einen Systemwechsel vorzuschlagen. Lass doch den TO einfach seine Erfahrungen machen.
Der TE fragt, ob es mit einem FPGA möglich ist. Nicht, dass es mit einem FPGA gemacht werden muss. Wenn dem so ist, dann ja, ist es eben so. Ich habe lediglich einen Vorschlag gemacht, wie das ganze im Handumdrehen zu erledigen ist, halt ohne FPGA. Wenn der TE schreibt es muss ein FPGA sein ist doch gut, ich hab lediglich eine zweite Option geäußert. Und da der Anfangspost danach klang, dass noch wenig Erfahrung mit einem FPGA vorhanden ist, ist ein System mit HDMI Eingang nicht der einfachste Einstieg. Da ich nun alles meinerseits zum Thema geäußert hab, bin ich damit erst mal raus.
Der Knackpunkt sind die Interfaces, nicht das FPGA ansich. Es gibt einige Boards mit denen man das machen kann. Die Frage ist aber allgemein zu schwammig und riecht für mich nach Trollerei. Frei nach Hallervorden: Brauchen mehr Details.
Ingo L. schrieb: > EchtzeitMuss schrieb: >> Ich kann nur schwer einschätzen, wie leistungsstark der >> FPGA sein muss. > Und hier kann keiner hellsehen, solange du nicht mehr Infos bringst Wie will er denn den Bildfilter bauen, wenn er nicht weiß wie so was aussieht? Und wenn er weiß wie sowas aussieht, kann man die Elemente zählen. Manchmal weiß ich wirklich nicht, wen Firmen an ihre Aufgaben dranstellen. Ingenieure können das nicht sein ... denn die wissen sich zu helfen.
Donni D. schrieb: > Das solltest du mit nem PC machen. Capture Card rein, und dann gängige > Libs wie OpenCV etc. nutzen. Welchen DSP will man da nehmen? Wie schnell kannst du mit open CV in Echtzeit arbeiten? Und welche Capture Card? Die komprimieren doch das Signal, das aber wäre doch gerade Aufgabe des FPGA, das vorher zu machen, bevor komprimiert wird. Kantenfilter auf MPG-Kanten ist nicht so prickelig.
Da nimmt man gar keinen DSP, sondern die CPU oder eben GPU, je nachdem ob und wie die Filter unterstützt werden. Und ja, die Capture Card komprimiert das ganze ein bisschen, aber bei einem 720p Signal, bzw. generell, wirst du bei einer Datenrate von bis zu 30MBit/s keinen Qualitätsverlust wahrnehmen. Und in Echtzeit bekommst du das mit moderner Hardware locker hin.
Donni D. schrieb: > Da nimmt man gar keinen DSP, sondern die CPU oder eben GPU, je nachdem > ob und wie die Filter unterstützt werden. Diese Pauschalitaet ist absoluter Unfug. Ein FPGA ist hier genau das Mass aller Dinge (nebst spezialisierten ASICs in Bildsensoren die oft auch einen ISP entahlten) um Video Signale in Echtzeit zu verarbeiten, weil du nur hier das auch wirklich kannst. Schau dir doch einfach mal den Signal Pfad in einem GPU basierten System an. Der erste Frame wird im Speicher gebuffert, dann wendest du einen Filter darauf an und wird vor der Ausgabe wieder gebuffert. Da hast du schonmal 2 Frames Latenz ohne ueberhaupt etwas weltbewegendes erreicht zu haben. Bei einem FPGA hast du das nicht. Deine Latenz ist hier begrenzt durch das Pipelining und die liegt in der Regel im Bereich von ein paar Pixel, respektive Zeilen wenn du Algorithmen auf vertikaler ebene hast. Ein Hochpassfilter ist da ein super Beispiel. Hochpassfilter die rein horizontal arbeiten haben sogut wie keine Latenz. Wenn du dann noch die vertikale Ebene dazu nimmst, dann musst du entsprechend Zeilen buffern damit dir die Information aus mehreren Zeilen vorliegt. Ein Beispiel dazu aus meiner taeglichen Praxis sind Endoskop Systeme wo Hochpass Filter gerne eingesetzt werden um feinste Adern oder Nerven hervorzuheben, damit der Arzt nicht ausversehen mit dem Skalpel da reinschneidet. Hier werden bei allen grossen Herstellern FPGAs fuer das Video Processing verwendet um die Latenz moeglichst gering zu halten. Nichts ist ekliger als Latenz bei der Fuehrung des Endoskops, aehnlich wie ein Keyboard Spieler der zuviel Delay zwischen Tastendruck und der Wahrnehmunng des Tons im Ohr hat.
:
Bearbeitet durch User
Ich habe garn ichts pauschalisiert, meine Antwort bezieht sich auf den Text darüber, und da wird gefragt, welchen DSP ich einsetzen würde um mit OpenCV etc. die Daten zu Verarbeiten. Und da ist ganz klar die Antwort: gar keinen. Wenn der TE 100% Echtzeit / Vorhersehbarkeit bei einer Verarbeitung haben möchte, kann er ja den FPGA nehmen. Ich habe, wie aber auch schon 10 mal erwähnt, lediglich eine Möglichkeit aufgezeigt, wie es einfach, schnell und kostengünstig mit dem PC funktioniert. Wenn du im medizinischen Bereicht arbeitest, wo du die von mir vorgestellte Möglichkeit nicht nutzen kannst, ist das ja Ok. Ich bezweifle aber, dass der TE das hier auch benötigt. Und wie groß die Latenz in wirklichkeit ist, wenn man es mit einem GPU basiertem Processing macht, kann ich nicht sagen, wenn du da Infos zu hast wäre ich sehr interessiert daran, ich bezweifle aber, sie liegt weit unterhalb der Wahrnehmungsgrenze. Alles was ich auf Anhieb so beim schnellen Googlen gefunden habe, zeigt eine Processingzeit von <3ms, meist je nach Filter <1ms. Wenn einem das nicht reicht, kann man immer noch zum FPGA greifen. Wie gesagt, ich will das Processing mit dem FPGA in keinster weise schlecht reden, ich nutze auch FPGAs für Breitbandige Ethernet Processings, aber wo es geht probiere ich eher auf Software / Pc zu setzen, weil es "einfacher", schneller und günstiger ist.
Donni D. schrieb: > Ich habe, wie aber auch schon > 10 mal erwähnt, lediglich eine Möglichkeit aufgezeigt, wie es einfach, > schnell und kostengünstig mit dem PC funktioniert. Bei einem FPGA bist du ebenfalls schnell und kostenguenstig unterwegs. Vor allem wenns um Stueckzahlen geht. Auch die Entwicklung ist kein Hexenwerk, ob man sich da in die PC Programmierung einarbeitet oder in moderne FPGA Enwicklungsmethoden macht kein Unterschied. Donni D. schrieb: > Und wie groß die > Latenz in wirklichkeit ist, wenn man es mit einem GPU basiertem > Processing macht, kann ich nicht sagen, wenn du da Infos zu hast wäre > ich sehr interessiert daran, ich bezweifle aber, sie liegt weit > unterhalb der Wahrnehmungsgrenze. Alles was ich auf Anhieb so beim > schnellen Googlen gefunden habe, zeigt eine Processingzeit von <3ms, > meist je nach Filter <1ms. Wenn einem das nicht reicht, kann man immer > noch zum FPGA greifen. Das haengt davon ab was du machen willst. Nimmst du z.B. die Bildverarbeitung um die Video Daten von einem Bildsensor zu verarbeiten. Dann hast du eine relativ grosse Verarbeitungskette (DeBayering, Farbkorrektur, Noise Reduction, Gamma Korrektur und in der Regel noch weitere Farbanpassungen, z.B. Saettigung, und Format Anpassungen um den Monitor zu Speisen). Das Problem bei einem GPU bsiertem System ist nun, dass mit jedem weiterem Filter das ganze anfaengt nicht mehr zu funktionieren und Frames gedroppt werden mussen. Das System skaliert einfach unglaublich schlecht. Bei einem FPGA hast du das Problem nicht, der skaliert rein mit seiner groesse. Die Angabe von der Processing Time ist natuerlich so erstmal sinnlos. Aber ja, es gibt Systeme in denen sind 3ms schon gefaehrlich. Man denke an autonomes Fahren. Deshalb kommen hier auch FPGAs zum Einsatz und nicht wenig. Ebenso sind die 3ms nur die Verarbeitungszeit. Dazu kommt noch das Capturen des Eingangs und das Buffern fuer die Ausgabe. Da bist du dann schon bei 2 Frames, macht bei 60 Hz ueber 32 ms. Mit speziellen Capture Karten kann man auch hier optimieren, z.B. wenn man eine nimmt die nicht komprimiert, dann kann man direkt mit dem RAW Processing beginnen sobald die Daten da sind. Das OS mit seinem Scheduler verhindert aber auch hier, dass das ein Echtzeit Processing ist. Donni D. schrieb: > Wie gesagt, ich will das Processing mit dem FPGA in keinster weise > schlecht reden, ich nutze auch FPGAs für Breitbandige Ethernet > Processings, aber wo es geht probiere ich eher auf Software / Pc zu > setzen, weil es "einfacher", schneller und günstiger ist. Passt halt in keinster Weise zu den Anforderungen des TO. Und die Empfehlung das mit einem PC zu machen zeugt nicht gerade von Professionalitaet. Daher sollte man wenn man in dem Bereich nicht arbeitet sich vielleicht ein bisschen zurueckhalten und nicht erklaeren was jemand machen soll sondern wie man es selbst machen wuerde. Ds wuerde auch die eigene Kompetenz auf dem Gebiet klarstellen was wiederum hilft die Qualitaet der vorgeschlagenen Loesung zu bewerten. ;-)
Tobias B. schrieb: > Auch die Entwicklung ist kein > Hexenwerk, ob man sich da in die PC Programmierung einarbeitet oder in > moderne FPGA Enwicklungsmethoden macht kein Unterschied. Soso. Ich kann diese Einschätzung nicht teilen. > Und die > Empfehlung das mit einem PC zu machen zeugt nicht gerade von > Professionalitaet. Eigentlich schon. Erstens sind die Dinger billig und weit verbreitet, zweitens weiß der TO doch noch gar nicht, welche Filterung er genau will. Man kann erst dann optimieren, wenn die Verarbeitungskette klar ist. Natürlich kann ein FPGA die richtige Lösung sein. Aber möglicherweise sitzt der auf einer Grabberkarte oder es kümmert sich doch eine GPU oder eine CPU um die Bilddaten. Und Echtzeitfähigkeit geht auch mit Windows. Man muß Windows in eine eigene Task stecken, so wie es Beckhoff bei seiner SPS macht. Duke
Duke Scarring schrieb: > Tobias B. schrieb: >> Auch die Entwicklung ist kein >> Hexenwerk, ob man sich da in die PC Programmierung einarbeitet oder in >> moderne FPGA Enwicklungsmethoden macht kein Unterschied. > Soso. Ich kann diese Einschätzung nicht teilen. Dann hast du dich auch noch nicht wirklich damit befasst. Ich bin imemr wiede beeindruckt was selbst Bacheloranten in relativ kurzer Zeit hinbekommen. MAn muss sich halt mit den modernen Methoden befassen, dann kommt man auch in kuerzester Zeit an sein Ziel. Beispiel zum Thema: https://shop.trenz-electronic.de/de/28871-Zybo-Z7-20-akademisch-Zynq-7000-ARM/FPGA-SoC-Plattform-SDSoC-Voucher Dazu gibt es ein HDMI BEeispiel: https://github.com/Digilent/Zybo-Z7-20-hdmi Wenn man das als Startpunkt nimmt, dann bekommt selbst ein Anfaenger in ein paar Tagen seinen ersten Video Filter zum laufen. Der Rest ist wie bei allem auch Uebungssache. Man muss halt einfach mal furchtlos an die Sache rangehen und FPGAs nicht als etwas Komplexes betrachten. Wenn ich mir da ein PC System anschaue, mit all seinen HW Komponenten, nemm OS, der Application, dann ist das doch deutlich komplizierter als etwas was bare-metal auf nemm FPGA laeuft. Duke Scarring schrieb: > Und Echtzeitfähigkeit geht auch mit Windows. Man muß Windows in eine > eigene Task stecken, so wie es Beckhoff bei seiner SPS macht. Sorry, das ist aber alles andere als Echtzeit (allein Windows ist nichtmal ansatzweise ein Echtzeit Betriebssystem). Und genau daher widerspreche ich dem, dass man via PC an die Aufgabe rangehen sollte.
Du redest von Anforderungen des TE, der hat aber bis auf: Filter, HDMI und 720p NICHTS gesagt. Seine Anforderung Echtzeit kann da vieles Bedeuten, erstmal heißt es Latenz 0ms und das geht so eh nicht. Also gehe ich erst mal davon aus, der will es nicht aufzeichnen und Bearbeiten, sondern direkt wieder ausgeben. Und gemeldet hat er sich seit dem Startposting auch nicht mehr. Und das die Einarbeitung in einen FPGA genau so einfach sein soll wie für PC Software, würde ich wie Duke Scarring auch anzweifeln. Gerade wenn es ans Timing geht kann es recht knifflig werden. Muss nicht, aber kann. Wenn er schon Erfahrung hat mit FPGAs kann es alles schneller gehen. Und wieso du dauernd von 2 Frames minimale Letenz redest ist mir auch nicht ganz klar. Capturecard Bild rein, Kopieren auf die GPU per DMA, da setze ich mal Frech 0ms an, ok 1ms, Bearbeitung 3ms, und das Teil kann schon in die Ausgabe. Wie gesagt, ich kenne mich auch mit FPGAs aus und nutze sie selber, aber solang der TE nicht seine Echtzeitfähigkeit und von Latenz <1ms redet, bleibe ich dabei, PC ist die bessere Wahl.
Sorry, dass ist störe, aber Echtzeit bedeutet nur, dass das System innerhalb einer vorher definierten Zeit garantiert ein Ergebnis liefert. Da kann man die Zeit auch auf einen Tag festsetzen, wenn das System das erfüllt ist es ein Echtzeitsystem.
Donni D. schrieb: > Du redest von Anforderungen des TE, der hat aber bis auf: Filter, HDMI > und 720p NICHTS gesagt. Seine Anforderung Echtzeit kann da vieles > Bedeuten, erstmal heißt es Latenz 0ms und das geht so eh nicht. Genau und all diese sind mit einem FPGA easy abgedeckt. Ich seh da nicht ansatzweise ein Problem. Auch seine Beispiel Algorithmen sind einfache Beispiele die sich super implementieren lassen, mittels HLS sogar einfacher und schneller als man denkt. Und 0ms nicht, aber Pixel wird verarbeitet im naechsten Taktzyklus nach dem Eintakten. Und das ist nicht 0 ns Latenz, aber im Bereich von ein paar Pixel Clockzyklen, also im ns Bereich. Da darf man dann schon von wirklicher Echtzeit sprechen, zumal ein FPGA da rein deterministisch ist und die Latenz konstant bleibt. Donni D. schrieb: > Und das die Einarbeitung in einen > FPGA genau so einfach sein soll wie für PC Software, würde ich wie Duke > Scarring auch anzweifeln. Gerade wenn es ans Timing geht kann es recht > knifflig werden. Muss nicht, aber kann. Wenn er schon Erfahrung hat mit > FPGAs kann es alles schneller gehen. Das haben frueher meine Praktikanten schon hinbekommen und selbst die Studenten wenn wir einen Versuchsaufbau bei irgendwelchen Hochschultagen hatten. FPGA Entwicklung ist weder etwas Komplexes noch ein Hexenwerk. Man muss halt einfach mal ran und anpacken. Hilfe gibts im Netz mehr als genug. Donni D. schrieb: > Und wieso du dauernd von 2 Frames minimale Letenz redest ist mir auch > nicht ganz klar. Capturecard Bild rein, Kopieren auf die GPU per DMA, da > setze ich mal Frech 0ms an, ok 1ms, Bearbeitung 3ms, und das Teil kann > schon in die Ausgabe. Weil die Capture Karte das Bild erstmal dekomprimieren muss. Mit dem komprimierten Bild kannst du im Processing nichts anfangen, das muss raw vorliegen. Und falls du das Bild wieder ausgeben moechtest (dazu hat der TO wie du schon schreibst nichts angegeben), dann muss er das Bild in einen Framebuffer schreiben zum ausgeben. Da braucht er mindestens einen Doublebuffer damit er keine Artefakte in der Ausgabe hat. Da kommt dann nochmal ein Frame Latenz drauf. Eine Uebersicht was Framegrabber fuer Latenzen haben, siehst du hier: https://techwatch.de/testreihen/capture-card-test/ Das ist sogar im Bereich von 10 Frames aufwaerts. Hier mal noch ein Whitepaper zu dem Thema was ich auf die Schnelle finden konnte: http://www.bertendsp.com/pdf/whitepaper/BWP001_GPU_vs_FPGA_Performance_Comparison_v1.0.pdf Donni D. schrieb: > Wie gesagt, ich kenne mich auch mit FPGAs aus und nutze sie selber, aber > solang der TE nicht seine Echtzeitfähigkeit und von Latenz <1ms redet, > bleibe ich dabei, PC ist die bessere Wahl. Und das ist das Problem, es ist keineswegs die bessere Wahl. Evtl. fuer dich weil du mit FPGAs nicht so bewandert bist und dir das nicht zutrauen wuerdest. Aber selbst Anfaenger koennen heute schon schnell Erfolge erzielen (vorallem im Bereich Videoverarbeitung), man muss sich halt nur mal trauen. Gustl B. schrieb: > Sorry, dass ist störe, aber Echtzeit bedeutet nur, dass das System > innerhalb einer vorher definierten Zeit garantiert ein Ergebnis liefert. > Da kann man die Zeit auch auf einen Tag festsetzen, wenn das System das > erfüllt ist es ein Echtzeitsystem. Das stimmt allerdings. Und genau deshalb wuerde ich niemals auf ein System setzen dass die Latenz schon nach unten beschraenkt (zumal bei einem FPGA die Latenz deterministisch und kosnattn ist, das erreicht ein GPU System allein schon durch das OS nicht). Sonst merkt man evtl. viel zu spaet dass man aufs falsche Pferd gesetzt hat und darf erstmal nenn Technologie Wechsel durchfuehren. Und dann wirds richtig ineffektiv. ;-)
:
Bearbeitet durch User
Du kannst ja schreiben so viel du willst, von Latenzen und und und. Ändert trotzdem nichts daran, das auch du die Anforderungen des TEs nicht kennst. Vielleicht bist auch einfach du zu sehr auf deine FPGAs eingefahren, weil du dich mit Software nicht auskennst? Ich hatte schon geschrieben, dass ich auch selbst mit FPGAs arbeite, auch an komplexeren Projekten (10G Ethernet etc.). Scheinbar möchtest du es ja nicht verstehen, dass ich den FPGAs nicht abgeneigt bin, aber eben auch Software hier sehr wahrscheinlich ausreichend ist, der TE äußert sich ja nicht mehr. Du scheinst dagegen zu glauben das Software nie zu gebrauchen ist und für alles, wo man ein FPGA einsetzen kann, also quasi alles, auch einen nehmen sollte. Damit bin ich nun endgültig raus, du scheinst wohl zu festgefahren in deiner Meinung zu sein.
Tobias B. schrieb: > Und 0ms nicht, aber Pixel wird verarbeitet im naechsten Taktzyklus nach > dem Eintakten. Und das ist nicht 0 ns Latenz, aber im Bereich von ein > paar Pixel Clockzyklen, also im ns Bereich. Was in so ziemlich allen Anwendungsfällen irrelevant ist. Du bist die Ausnahme, nicht die Regel. > Da darf man dann schon von wirklicher Echtzeit sprechen, > zumal ein FPGA da rein deterministisch ist > und die Latenz konstant bleibt. Auch das ist normalerweise komplett irrelevant, solange der Jitter unterhalb einer Framedauer bleibt. > Das haben frueher meine Praktikanten schon hinbekommen und > selbst die Studenten wenn wir einen Versuchsaufbau bei > irgendwelchen Hochschultagen hatten. Üblicherweise haben Studenten bei sowas aber mindestens ein Vierteljahr, wenn nicht sogar ein Dreivierteljahr Tiefenbespaßung mit FPGAs und HDL. > FPGA Entwicklung ist weder etwas Komplexes noch ein Hexenwerk. > Man muss halt einfach mal ran und anpacken. > Hilfe gibts im Netz mehr als genug. Für OpenCV mit GPUs gibt es wesentlich mehr. > Weil die Capture Karte das Bild erstmal dekomprimieren muss. Blödsinn. HDMI schiebt in aller Regel RGB oder YUV422 raus, da muss nix "dekomprimiert" werden (außer "jeweils zwei Pixel verrechnen"). Das ist nicht die gleiche Hausnummer wie ein Debayer mit PDAF-Pixelkorrektur. > Und das ist das Problem, es [PC] ist keineswegs die bessere Wahl. Für die meisten Anwendungsfälle, wenn es um Entwicklung und nicht um Stückzahlen geht, doch. > Das stimmt allerdings. Und genau deshalb wuerde ich niemals auf ein > System setzen dass die Latenz schon nach unten beschraenkt ...du bezahlst also lieber im Voraus für Anforderungen, die möglicherweise garnicht existieren. Machst du auch alle anderen Datenverarbeitungen im FPGA, auch für den Hobbygebrauch? Weil könnte ja sein, dass die UART- oder SD-Kommunikation im ns-Bereich exakt sein muss... oder übertreibe ich gerade etwas?
:
Bearbeitet durch User
Mit einer PC-Loesung sind durchaus Latenzen im Sub-Frame-Bereich moeglich, es gibt eine Menge industrielle Framegrabber, die das machen, und da wird nichts komprimiert. Nur ist HDMI da nicht gerade Usus. Da der Fragessteller aber keine Details zu seinen 'Echtzeitanforderungen' liefert und offenbar auch kein Interesse an einer dahingehenden Diskussion hat, ist es wohl auch weiterhin muessig, sich darueber zu streiten. Eine spezifische FPGA-Loesung einzusetzen lohnt sich nur, wenn das System embedded/ohne Linux laufen soll/muss (Stromsparend/Sicherheitsaspekte usw.) oder eben gerade ein Bilderfassungsgeraet ist, was HDMI/GigE ausgibt (und weniger latenzbehaftet sein muss als z.B. eine GoPro). Solange die klassische Frage 'wo sollen die Daten hin' nicht mal eroertert wird, macht's auch so gar keinen Sinn, Komplexitaeten a la ZynQ reinzubringen.
So, jetzt zu Effekten und Rechenlast: Ich habe jetzt als Spaß mal den OpenShot Editor installiert und ein 1080p Video geladen. Darüber einen Effekt gelegt und das läuft auf meiner CPU, 8550U noch fast flüssig. Also ohne das vorher rendern zu lassen sondern das wird direkt berechnet. Ohne Nvidia/AMD GPU. Wenn ihr einen Videoeditor habt der Kantenerkennung als Effekt bietet dann probiert das einfach mal aus. Aber auch der VLC kann Effekte. Das funktioniert wunderbar flüssig, man kann sogar mehrere Effekte gleichzeitig verwendet nur bei zu vielen ruckelt das Video dann. Jedenfalls glaube ich dass Kantenerkennung auf einer aktuellen CPU oder GPU ohne Probleme läuft. Und bei 1080i/720p wunderbar flüssig.
S. R. schrieb: > Tobias B. schrieb: >> Und 0ms nicht, aber Pixel wird verarbeitet im naechsten Taktzyklus nach >> dem Eintakten. Und das ist nicht 0 ns Latenz, aber im Bereich von ein >> paar Pixel Clockzyklen, also im ns Bereich. > > Was in so ziemlich allen Anwendungsfällen irrelevant ist. > Du bist die Ausnahme, nicht die Regel. Dann wird es schleunigst Zeit mal in der Branche ein Praktikum zu machen. Deine Aussage ist aber mal sowas von falsch. Kannst ja z.B. mal bei Basler nachfragen, einfach mal bei der naechsten Messe an deren Stand gehen. Die werden dir sicher gerne erzaehlen wo ueberall ein FPGA eingesetzt wird. S. R. schrieb: >> Da darf man dann schon von wirklicher Echtzeit sprechen, >> zumal ein FPGA da rein deterministisch ist >> und die Latenz konstant bleibt. > > Auch das ist normalerweise komplett irrelevant, solange der Jitter > unterhalb einer Framedauer bleibt. Auch das ist eine Verallgemeinerung die voellig Praxis fern ist. Endoskopie, autonomes Fahren, Broadcasting, Highspeed Imaging zur QS (z.B. Sortieranlagen) sind ganz prominente Beispiele in denen das nicht toleriert werden kann. Auch die Jitter Grenze von unterhalb einem Frame ist absolut willkuerlich dahin geplappert und zeugt von keinerlei Fachkompetenz. S. R. schrieb: >> Das haben frueher meine Praktikanten schon hinbekommen und >> selbst die Studenten wenn wir einen Versuchsaufbau bei >> irgendwelchen Hochschultagen hatten. > > Üblicherweise haben Studenten bei sowas aber mindestens ein Vierteljahr, > wenn nicht sogar ein Dreivierteljahr Tiefenbespaßung mit FPGAs und HDL. Und in OpenCV etc. muss man sich nicht einarbeiten? Was ist denn dein Argument warum du glaubst dass die FPGA Entwicklung komplexer sein soll als z.B. mit OpenCV zu arbeiten? S. R. schrieb: >> FPGA Entwicklung ist weder etwas Komplexes noch ein Hexenwerk. >> Man muss halt einfach mal ran und anpacken. >> Hilfe gibts im Netz mehr als genug. > > Für OpenCV mit GPUs gibt es wesentlich mehr Es gibt auch mehr Salzwasser als Suesswasser auf der Welt, trotzdem bin ich froh dass aus meinem Wasserhahn nicht ersteres kommt. ;-) Mehr ist keine Metrik fuer besser, wieder durchgefallen. S. R. schrieb: > Blödsinn. HDMI schiebt in aller Regel RGB oder YUV422 raus, da muss nix > "dekomprimiert" werden (außer "jeweils zwei Pixel verrechnen"). Das ist > nicht die gleiche Hausnummer wie ein Debayer mit PDAF-Pixelkorrektur. Genau und eine gewoehnliche Grabber Karte, z.B. mit USB Anschluss macht dann eine Komprimierung auf das Signal und jagt es z.B. via USB in den PC. Klar kannst du auch professionelle Grabberkarten nehmen die dir die Daten raw praesentieren. Dann bist du aber auf keinenfall kostenguenstig unterwegs. Und Funfact am Rande: Was steckt in diesen KArten drin? Ein FPGA, welch Wunder. S. R. schrieb: >> Und das ist das Problem, es [PC] ist keineswegs die bessere Wahl. > > Für die meisten Anwendungsfälle, wenn es um Entwicklung und nicht um > Stückzahlen geht, doch. Bisher hast du nicht einen genannt und redest von den meisten. Auch hier ist 0 Inhalt. Ja, auch ich kenne viele Anwendungen in denen ich ein PC System bevorzugen wuerde und kann daher sehr wohl abschaetzen wann was am besten geeignet ist. Und hier faellt die Wahl ganz klar auf den FPGA. S. R. schrieb: >> Das stimmt allerdings. Und genau deshalb wuerde ich niemals auf ein >> System setzen dass die Latenz schon nach unten beschraenkt > > ...du bezahlst also lieber im Voraus für Anforderungen, die > möglicherweise garnicht existieren. Machst du auch alle anderen > Datenverarbeitungen im FPGA, auch für den Hobbygebrauch? Weil könnte ja > sein, dass die UART- oder SD-Kommunikation im ns-Bereich exakt sein > muss... oder übertreibe ich gerade etwas? Du machst den gleichen Denkfehler wie Donni, weil du glaubst dass die Entwicklung aufwendig ist. Die Beschaffungskosten sind erstmal hoeher als beim FPGA. Ein Evalboard mit HDMI In/Out liegt bei ca. 200€. Dafuer bezahlst du alleine die Grabberkarte. Und um sich in die FPGA Toolchain einarbeiten geht wahrscheinlich sogar schneller, als sich in die unzaehligen PC basierten Video Bearbeitungsframeworks einzuarbeiten. Dazu kommt noch dass du ein System hast mit OS, einer Treiberschicht, dem SDK fuer die Grabberkarte und erst dann kommt eine Applikation. Und jetzt meinst du ernsthaft dass ist weniger komplex als ein FPGA? Sorry, dann wuerde ich ernsthaft mal anfangen ein Praktikum in der Bildverarbeitungsbranche zu machen, man lernt nie aus. ;-)
Gustl B. schrieb: > Aber auch der VLC kann Effekte. Das funktioniert wunderbar flüssig, man > kann sogar mehrere Effekte gleichzeitig verwendet nur bei zu vielen > ruckelt das Video dann. Jedenfalls glaube ich dass Kantenerkennung auf > einer aktuellen CPU oder GPU ohne Probleme läuft. Und bei 1080i/720p > wunderbar flüssig. Fluessig und geringe Latenz sind zwei unterschiedliche paar Schuhe. Was hier passiert ist, dass ein paar Frame gebuffert werden um immer einen nachschieben zu koennen damit nichts rueckelt. Je groesser der Buffer, desto geringer die Wahrscheinlichkeit fuer einen Ruckler, jedoch erkaufst du dir damit eine groessere Latenz.
Tobias B. schrieb: > jedoch > erkaufst du dir damit eine groessere Latenz. Exakt. Da wäre es mal interessant was die Anwendung am Ende können soll.
Strubi schrieb: > Mit einer PC-Loesung sind durchaus Latenzen im Sub-Frame-Bereich > moeglich, es gibt eine Menge industrielle Framegrabber, die das machen, > und da wird nichts komprimiert. > Nur ist HDMI da nicht gerade Usus. Jep Full ACK. Aber dann ist die Loesung auch nicht mehr Easy Peasy sondern man muss sich mit dem SDK des Grabbers auseinandersetzen (oft hat man da auch spezielle Grabberkarten mit einem FPGA drauf die dann relativ easy mit der Hersteller Software programmiert werden koennen um das Processing zu uebernehmen). Das ist dann in etwa der gleiche Aufwand wie sich mit einer FPGA Toolchain zu befassen, wobei man evtl. noch Gefahr laeuft als Privatanwender da nichtmal Zugriff darauf zu bekommen. Aber beide Loesungen haben definitiv ihre Daseins Berechtigung. Strubi schrieb: > Da der Fragessteller aber keine Details zu seinen > 'Echtzeitanforderungen' liefert und offenbar auch kein Interesse an > einer dahingehenden Diskussion hat, ist es wohl auch weiterhin muessig, > sich darueber zu streiten. Da wird wohl auch nichts mehr kommen. Aber immerhin dient der Thread dazu Wissen zum Thema FPGA vs CPU/GPU zu eroertern. Strubi schrieb: > Eine spezifische FPGA-Loesung einzusetzen lohnt sich nur, wenn das > System embedded/ohne Linux laufen soll/muss > (Stromsparend/Sicherheitsaspekte usw.) oder eben gerade ein > Bilderfassungsgeraet ist, was HDMI/GigE ausgibt (und weniger > latenzbehaftet sein muss als z.B. eine GoPro). Nicht unbedingt. Auch hier ist Medizintechnik ein gutes Beispiel. FPGA macht die Bildverarbeitung Linux System verarbeitet die Patientendaten, speichert Bilder und Videos, etc. Jede Anwendung hat halt eine bestmoegliche Loesung. Und die Argumentation das FPGA komplizierter als PC ist, ist halt leider an den Haaren herbeigezogen. Gerade die Ganze HLS Geschichte hat die Entwicklung von einfachen Videofilter so unfassbar einfach gemacht, dass es kein Unterschied mehr ist ob ich da irgendwelchen C Code reinhacke oder ein SDK von einer Grabberkarte verwende. Man sollte einfach aufhoeren den Leuten abzusprechen dass sie Dinge nicht hinbekommen, nur weil man selber an seiner Grenze ist. Getreu dem Motto: "Wenn ich das kann, kann das jeder" statt "Wenn ich das nicht kann, dann du auch nicht". ;-)
Gustl B. schrieb: > Tobias B. schrieb: >> jedoch >> erkaufst du dir damit eine groessere Latenz. > > Exakt. Da wäre es mal interessant was die Anwendung am Ende können soll. Und wenn man das nicht weiss, waehlt man im Zweifel immer die Loesung die einen nicht beschraenkt und die Gefahr laeuft dass ein Technologiewechsel noetig ist (ganz klassisches Projektrisko Management). Kuenstlich Latenz ins System Pumpen kann man am Ende immer noch. ;-)
Tobias B. schrieb: > Und um sich in die FPGA Toolchain einarbeiten geht wahrscheinlich sogar > schneller, als sich in die unzaehligen PC basierten Video > Bearbeitungsframeworks einzuarbeiten. > > Dazu kommt noch dass du ein System hast mit OS, einer Treiberschicht, > dem SDK fuer die Grabberkarte und erst dann kommt eine Applikation. Und > jetzt meinst du ernsthaft dass ist weniger komplex als ein FPGA? Sorry, > dann wuerde ich ernsthaft mal anfangen ein Praktikum in der > Bildverarbeitungsbranche zu machen, man lernt nie aus. ;-) So langsam glaube ich, du hast noch nie etwas mit Bildbearbeitung / Videoprocessing am PC in Software erledigt. In die Toolchain schneller einarbeiten, als in die am PC? Was benötigst du für die Softwarelösung? Genau, einen Texteditor, wenn es angenehm sein soll Atom, VSCode etc. Fertig. Du installierst dir Python und OpenCV, übrigens in einem Command im Terminal erledigt. Und in welche unzähligen Frameworks willst du dich einarbeiten? Hier wird NUR von OpenCV gesprochen, dem quasi Standard. Hier mal ein paar Beispiele, wie wenig Zeilen es braucht, Filter auf ein Bild anzuwenden, die Adaption auf ein Video ist dann ein Witz. https://pythonexamples.org/python-opencv-image-filter-convolution-cv2-filter2d/ Allein für das Constraint File wirst du mehr Zeilen brauchen, als du bei der Softwarelösung insgesamt brauchst. Ja, natürlich hat man ein System mit OS, Treibern, SDK etc. Darum kümmert sich aber KOMPLETT die Library OpenCV. Vielleicht solltest du mal ein Praktikum bei einer Softwarebude machen, denn dann wirst du sehen, man lernt nie aus.
OhGott schrieb: > Ja, natürlich hat man ein System mit OS, Treibern, SDK etc. Darum > kümmert sich aber KOMPLETT die Library OpenCV. Vielleicht solltest du > mal ein Praktikum bei einer Softwarebude machen, denn dann wirst du > sehen, man lernt nie aus. Ich behaupte auch nicht das man mit OpenCV langsam ist, sondern dass man mit einer FPGA Loesung genauso schnell ans Ziel kommt. Hier kuemmert sich auch das SDK um den HDMI In- und Output und den HLS Code fuer einen Videofilter schreibst du auch in einem Texteditor und fertig. Und wenn man mag auch direkt als HDL, ist etwas aufwendiger aber nicht dass man gleich in ganz andere Zeitskalen vorrueckt. Ich seh nicht was daran so schwer verstaendlich ist. Wo sind den jetzt exakt die Knackpunkte warum das mit einem FPGA so unfassbar viel laenger dauern soll? Die ganzen FPGA Hersteller arbeiten immer mehr und mehr dahin, dass Rapid Prototyping zu optimieren. Und da hat sich in den letzten Jahren eine Menge getan. Einfach mal ausprobieren und dann eine Meinung bilden. OhGott schrieb: > Allein für das Constraint File wirst du mehr Zeilen brauchen, als du bei > der Softwarelösung insgesamt brauchst In der Xilinx Welt uebernimmt das Vivado z.B. komplett fuer dich sofern der Hersteller wie z.B. beim Zybo Board ein entsprechendes Board Design mitliefert: https://it.mathworks.com/help/hdlcoder/examples/define-and-register-custom-board-and-reference-design-for-zynq-workflow.html#d120e20791 Du waehlst im Block Design Creator einfach aus welche Features du nutzen willst und die Constraints werden automatisch erzeugt. Vor 10+ Jahre waere die Umsetzung auf einem FPGA in der Tat noch wirklich mit Arbeit verbunden gewesen. Aber mittlerweile nehmen die Tools einem genausoviel Arbeit ab, wie es die ganzen Software basierten Frameworks machen. Man muss sich halt man ransetzen. Ich traue das auch einem Anfaenger zu in wenigen Tagen etwas auf die Beine zu stellen. Aber im Allgemeinen gebe ich da allen recht, dass man mit Software schneller ans Ziel kommt. Jedoch auf welchen Zeitskalen wird hier diskutiert? Was ich in Software an einem Tag schaffe brauch ich mit einem FPGA ja nicht gleich 10 Tage. Man muss sich halt modernen Methoden bedienen und dann ist man da ebenfalls flott unterwegs.
Ich rede hier von 5 Minuten Installation und 5 Minuten Code zusammensuchen, wohl gemerkt, für einen Anfänger mit ein wenig Erfahrung im Developer Umfeld. Da du ja scheinbar die Fähigkeiten an deinen misst bezüglich Einfachheit etc., kann ich dir sagen, ich schaffe es in unter 10 Minuten. Da ist wahrscheinlich beim FPGA nicht mal der Fitter durch gelaufen. Niemand hat gesagt, dass ein FPGA in speziellen Scenarios wie Medizin, Automotive etc. ersetzt werden sollte. Nur, dass man eben nicht immer direkt ein riesen FPGA rankarren sollte, wenn es die Anforderungen nicht erwarten. Zeig doch mal, wie du es in 30 Minuten schaffst, ein System mit HDMI Eingang, Ausgang, Hochpassfilterung mit anpassbaren Koeffizienten etc. hinzubasteln. Testbenches für Komponenten die nicht vom Hersteller kommen natürlich nicht vergessen. Natürlich dann noch schnell erweiterbar, falls andere Filter zum Einsatz kommen sollen, ist bei Software nämlich nur fix ein Funktionsaufruf. Wenn du all das unter 30 Minuten schaffst sage ich Respekt, aber zweifle dann trotzdem an, dass es jeder andere mit weniger Erfahrung schafft.
OhGott schrieb: > Ich rede hier von 5 Minuten Installation und 5 Minuten Code > zusammensuchen, wohl gemerkt, für einen Anfänger mit ein wenig Erfahrung > im Developer Umfeld. Da du ja scheinbar die Fähigkeiten an deinen misst > bezüglich Einfachheit etc., kann ich dir sagen, ich schaffe es in unter > 10 Minuten. Da ist wahrscheinlich beim FPGA nicht mal der Fitter durch > gelaufen. Framegrabber Karte einbauen, Treiber installieren, evtl. noch das passende SDK. Auch hier kommt einiges an Arbeit zusammen. Und wenn man ein System from scratch aufzieht und ein abgeschlossenes embedded System will kommt sogar noch die OS Installation und Konfiguration hinzu. Auch hier wird das eine unter- und das andere ueberschaetzt. OhGott schrieb: > Niemand hat gesagt, dass ein FPGA in speziellen Scenarios wie Medizin, > Automotive etc. ersetzt werden sollte. Nur, dass man eben nicht immer > direkt ein riesen FPGA rankarren sollte, wenn es die Anforderungen nicht > erwarten. Und ich habe nirgens behauptet dass ueberall FPGAs eingesetzt werden muessen. Aber das setzt ein Mindestmass an Textverstaendnis vorraus. OhGott schrieb: > Zeig doch mal, wie du es in 30 Minuten schaffst, ein System mit HDMI > Eingang, Ausgang, Hochpassfilterung mit anpassbaren Koeffizienten etc. > hinzubasteln. Testbenches für Komponenten die nicht vom Hersteller > kommen natürlich nicht vergessen. Natürlich dann noch schnell > erweiterbar, falls andere Filter zum Einsatz kommen sollen, ist bei > Software nämlich nur fix ein Funktionsaufruf. Wenn du all das unter 30 > Minuten schaffst sage ich Respekt, aber zweifle dann trotzdem an, dass > es jeder andere mit weniger Erfahrung schafft. 30 Minuten sind unmoeglich, an einem halben Tag kommt man da aber schon richtig weit. Und du willst jetzt ernsthaft wegen den paar Stunden Mehraufwand die bzgl. Echtzeit Verabreitung schlechtere Technologie bevorzugen? Und wenn jemand keine Erfahrung hat, dann schafft er es auch nicht einen OpenCV Filter in Python in 5 Minuten zum laufen zu bringen und schon gar nicht seinen eigenen zu schreiben. Testbenches sind dann natuerlich auch keine geschrieben, aber du schreibst auch in 5 Minuten nicht deine Unit Tests. Und Unit Tests fuer OpenCV sparst du dir wahrsheinlich auch komplett. von daher hinkt der Vergleich hier gewaltig. Durch das AXI Subsystem ist auch eine Erweiterung ueberhaupt kein Problem. Mit dem Vorteil dass ein FPGA seine Echtzeitfaehigkeit behaelt wenn die Rechenlast waechst. Auch hier wuerde ich also erstmal auf einen FPGA setzen solange die Requirements nicht naeher bekannt sind um mich nicht im Vorfeld schon in die Brennesseln zu setzen. Sobald diese naeher spezifiziert sind und eine Softwareloesung Sinn macht, wuerde ich auch ohne zu zoegern wechseln. Wenn diese aber unbekannt bleiben, muss man erstmal pessimistisch an die Sache rangehen, sonst faengt man naemlich wieder von vorne an wenn der Projektumfang waechst. Und mehr habe ich in dieser ganzen Diskussion auch nie behauptet. Und ich denke nicht dass ich hier irgendjemanden irgendeinen Beweis schuldig bin. Du darfst mich aber gerne fuer einen Tagessatz buchen, dann siehst du ja was man im Stande ist an einem Tag zu schaffen. ;-)
:
Bearbeitet durch User
Achso, du brauchst also kein OS um Mit dem FPGA zu arbeiten. Treiber scheinbar auch nicht. Sehr interessant. Testbench nur für selbst geschriebene Module, die IPs der Hersteller sollten ja gehen. Für so etwas simples wie Videoinput, Filter drauf und Ausgabe ist ja nicht mal ein UnitTest erforderlich, das sind ja nur 10 Zeilen testbarer Code. Und doch, der OpenCV Filter läuft in 5 Minuten, hab doch ein Beispiel link gegeben. Copy and Paste und fertig. Alles in allem hast du prima dargelegt, dass du scheinbar wenig Ahnung von Softwareentwicklung und deren Möglichkeiten hast. Wenn du einen halben Tag benötigst für diese simple Aufgabe und dann scheinbar nur ‚weit gekommen bist’, statt fertig, es jemand anders aber in wegen mir 30 Minuten macht, fällt mir die Wahl leicht. Auch im Automotive Bereich wird viel in Software erledigt, kannst ja mal bei nVidia vorbei schauen, wie deren Produkte für autonomes fahren etc. aussehen.
OhGott schrieb: > Alles in allem hast du prima dargelegt, dass du scheinbar wenig Ahnung > von Softwareentwicklung und deren Möglichkeiten hast. Und du wie wenig Ahnung du von Embedded Systems hast. Ich habe oben doch extra den Kontext erlaeutert. Aber im Allgemeinen hast du ein gewaltiges Textverstaendnis Problem. Ich meine mich zu erinnern dass es dazu auch VHS Kurse zu dem Thema gibt, vielleicht da mal anfragen?
Tobias B. schrieb: >>> Und 0ms nicht, aber Pixel wird verarbeitet im naechsten >>> Taktzyklus nach dem Eintakten. Und das ist nicht 0 ns >>> Latenz, aber im Bereich von ein paar Pixel Clockzyklen, >>> also im ns Bereich. >> >> Was in so ziemlich allen Anwendungsfällen irrelevant ist. >> Du bist die Ausnahme, nicht die Regel. > > Dann wird es schleunigst Zeit mal in der Branche > ein Praktikum zu machen. Bei uns liegt zwischen Sensor und dem fertigen Bild grundsätzlich eine Latenz von 8 Frames. Im Highspeed-Modus nutzen wir eine etwas verkürzte Pipeline und arbeiten mit 4 Frames. Das ist für uns völlig ausreichend. Die meisten Anwendungsfälle benötigen keine maximale Latenz im einstelligen ns-Bereich. > S. R. schrieb: > Endoskopie, autonomes Fahren, Broadcasting, Highspeed > Imaging zur QS (z.B. Sortieranlagen) sind ganz prominente > Beispiele in denen das [Jitter] nicht toleriert werden kann. Wir hantieren mit Videos, und (etwas weiter gefasst) auch mit Broadcasts. Solange der Jitter unterhalb einer Framelänge bleibt, gibt es auf der Ausgabeseite keinerlei messbare Effekte. Vorne kommen 30-120 fps rein, hinten kommen 30-120 fps raus, die Framerate ist auf beiden Seiten absolut stabil. Erkläre mir mal, warum die Verarbeitung dazwischen (die Black Box) jetzt auch noch pixeltaktgenaue Latenzen haben muss. > Auch die Jitter Grenze von unterhalb einem Frame ist absolut > willkuerlich dahin geplappert und zeugt von keinerlei Fachkompetenz. Nun, wahrscheinlich ist meine Fachkompetenz einfach an anderer Stelle als deine Fachkompetenz. Ich sage ja nicht, dass du Unrecht hast - sondern dass du ziemlich enge Scheuklappen trägst. > Und in OpenCV etc. muss man sich nicht einarbeiten? > Was ist denn dein Argument warum du glaubst dass die FPGA > Entwicklung komplexer sein soll als z.B. mit OpenCV zu arbeiten? Ich habe sowohl mit OpenCV als auch mit FPGAs gearbeitet, und die letzten Jahre dann mit Kamerasystemen. Diese Erfahrungen - und auch die Erfahrungen vieler Studenten, mit denen ich sowohl lernend als auch lehrend zu tun hatte, sprechen dafür. > Genau und eine gewoehnliche Grabber Karte, z.B. mit USB Anschluss > macht dann eine Komprimierung auf das Signal und jagt es z.B. via > USB in den PC. Ich wüsste jetzt nicht, von was für komischem Unfug du da faselst. So ziemlich jede billige Webcam kann einen YUV-Datenstrom schicken, in der Regel ist das NV12. Unsere Lösung schiebt UYVV via MIPI-CSI in den SoC. Klar kannst du dich auch doof anstellen und MJPG anfordern. Dann bekommst du einen komprimierten Datenstrom mit recht unbekannter Latenz - aber hey, dann hast du dich doof angestellt. Habe ich mich mit meiner Bachelorarbeit auch, bis mir das irgendwann aufgefallen ist und ich das ordentlich gemacht habe. > Klar kannst du auch professionelle Grabberkarten nehmen > die dir die Daten raw praesentieren. Ich habe hier eine recht antike Microsoft-Webcam, eine etwas bessere Logiech-Webcam, und im Büro steht ein professioneller HDMI-auf-USB3-Konverter rum. Da kommt überall YUV raus. > Dann bist du aber auf keinenfall kostenguenstig unterwegs. Ab 3€ auf dem Grabbeltisch bist du dabei... > Und Funfact am Rande: Was steckt in diesen KArten drin? > Ein FPGA, welch Wunder. Ich bin mir ganz sicher, dass in den Webcams kein FPGA drin ist, viel zu teuer und zu energieintensiv. Die eine Cam hat schon gute 10 Jahre auf dem Buckel. Im Framegrabber steckt sicherlich ein FPGA, aber der kann auch 4k30 über USB3 und 4k60 in MJPEG in Echtzeit. Aber nur, weil da ein FPGA verbaut ist, muss ich für meinen Anwendungsfall keinen verbauen. Millionen Fliegen fressen Scheiße, deswegen muss das für mich nicht die bevorzugte Nahrungsquelle sein. > Bisher hast du nicht einen genannt und redest von den meisten. Ich hab ein paar umgesetzt, kann aber darüber nicht reden. Das, womit ich die letzten Jahre verbracht habe, läuft auf Embedded-Systemen. Das sind keine PCs, aber im hier relevanten Betrachtungswinkel unterscheiden sie sich nicht besonders. > Und hier faellt die Wahl ganz klar auf den FPGA. "Hier" gibt es nichtmal klare Anforderungen. :-) > Du machst den gleichen Denkfehler wie Donni, weil du glaubst > dass die Entwicklung aufwendig ist. Oh, das ist sie. Dein Denkfehler ist zu behaupten, dass FPGA-Entwicklung ähnlich einfach und effizient ist wie Programmierung. > Die Beschaffungskosten sind erstmal hoeher als beim FPGA. > Ein Evalboard mit HDMI In/Out liegt bei ca. 200€. Dafuer > bezahlst du alleine die Grabberkarte. Aber für die entsprechenden FPGAs sind da die Lizenzkosten für Vivado/Quartus noch nicht mit drin. Die IPs für HDMI kommen ebenfalls nicht gratis - im Gegensatz zu OpenCV und gcc. Beide mit kommerzieller Qualität. > Und um sich in die FPGA Toolchain einarbeiten geht wahrscheinlich sogar > schneller, als sich in die unzaehligen PC basierten Video > Bearbeitungsframeworks einzuarbeiten. Es reicht, sich in eine FPGA-Toolchain einzuarbeiten und es reicht, sich in ein Bildbearbeitungsframework einzuarbeiten. Schau dich mal auf dem Arbeitsmarkt um, was da fähigen Softwareentwicklern rumläuft und vergleiche das mit der Anzahl an fähigen FPGA-Entwicklern. Wenn du FPGA kannst und Software nicht - und so schätze ich dich ein - dann bist du ein Paradebeispiel für Hammer, Nägel und Aussehen. > Sorry, dann wuerde ich ernsthaft mal anfangen ein Praktikum in der > Bildverarbeitungsbranche zu machen, man lernt nie aus. ;-) Du scheinst zu glauben, dass ich ein absoluter Anfänger ohne Ahnung bin. Ist nicht so. ;-) Bin mit meinem Job auch recht zufrieden, habe bereits in der Bildverarbeitungsbranche zu tun und weiß, dass für unterschiedliche Anforderungen unterschiedliche Lösungen sinnvoll sind.
S. R. schrieb: > Bei uns liegt zwischen Sensor und dem fertigen Bild grundsätzlich eine > Latenz von 8 Frames. Im Highspeed-Modus nutzen wir eine etwas verkürzte > Pipeline und arbeiten mit 4 Frames. Das ist für uns völlig ausreichend. > > Die meisten Anwendungsfälle benötigen keine maximale Latenz im > einstelligen ns-Bereich. Ihr redet so halb aneinander vorbei. Selbst 4 Frames Latenz sind bei 30 Fps 133 ms. Das ist schon so viel dass man damit z. B. keine Shooter mehr sinnvoll zocken kann. Es geht hier auch nicht um den ns Bereich. Was wirklich sinnvoll ist hängt von der Anwendung ab die wir weiterhin nicht kennen. Da bringt das ganze Ratespiel nix. Aber noch zu den Framegrabbern: Die gibt es in extrem günstig https://www.ebay.de/itm/4K-Game-Video-Capture-Card-HDMI-zu-USB2-0-1080P-HD-Recorder-Live-Video-Streaming/264798031041? aber ob da ein FPGA drinnen ist? Man findet zwar Bilder vom Innenleben diverser Grabber, aber da sind die ICs abgeschliffen. Allerdings liefert so ein Grabber ganz sicher kein Rohbild. Das passt nämlich nicht durch USB2.
S. R. schrieb: >> Sorry, dann wuerde ich ernsthaft mal anfangen ein Praktikum in der >> Bildverarbeitungsbranche zu machen, man lernt nie aus. ;-) > > Du scheinst zu glauben, dass ich ein absoluter Anfänger ohne Ahnung bin. > Ist nicht so. ;-) Bin mit meinem Job auch recht zufrieden, habe bereits > in der Bildverarbeitungsbranche zu tun und weiß, dass für > unterschiedliche Anforderungen unterschiedliche Lösungen sinnvoll sind. Jetzt nicht mehr, aber du musst auch zugeben dass der jetzige Beitrag deutlich mehr Expertise darstellt, als der vorherige. ;-) S. R. schrieb: > Bei uns liegt zwischen Sensor und dem fertigen Bild grundsätzlich eine > Latenz von 8 Frames. Im Highspeed-Modus nutzen wir eine etwas verkürzte > Pipeline und arbeiten mit 4 Frames. Das ist für uns völlig ausreichend. > > Die meisten Anwendungsfälle benötigen keine maximale Latenz im > einstelligen ns-Bereich. Das ist schon ein Haufen Holz. Und ich habe auch nie etwas vom einstelligen ns Bereich geschrieben. Wenn man keine Daten buffert, dann liegt man im Bereich von mehreren Pixel Clockzyklen (da ist man dann irgendwo in den 100er ns oder sogar darunter). Sobald man Zeilenspeicher braucht ist man im us und wenn ganze Frames gebuffert werden eben im ms Bereich. Dort wo es auf Hand / Auge Koordination ankommt hat man haeufig die Anforderung dass man unterhalb 2 Frames bleiben muss. Z.B. in der Medizintechnik moechte man das weitestgehend druecken, einfach um dem Arzt das Gefuehl zu geben dass sich ein digitales Endoskop wie ein optisches "anfuehlt". Aehnlich dem Beispiel das ich mit dem Keyboarder gegeben habe. Deine 4 Frames sind hier schon 64 ms, da faengt es schon an eklig zu werden und 8 Frames mit den 128 ms sind in keinster Weise mehr akzeptabel (jeweils bei 60 Hz wohlgemerkt, darunter wirds entsprechend schlimmer). Auch dort wo schnell auf den Bildinhalt reagiert werden muss, z.B. Kollisionsdetektion, kann ich mir nicht vorstellen dass 8 Frames akzeptabel sind. Ein Auto das mit 30 m/s = 108 km/h unterwegs ist, legt in 128 ms eine Strecke von 3.6m zurueck. Das ist ein Haufen Holz wenns darum geht den Fussgaenger ueber den Haufen zu fahren oder nicht. S. R. schrieb: > Nun, wahrscheinlich ist meine Fachkompetenz einfach an anderer Stelle > als deine Fachkompetenz. Ich sage ja nicht, dass du Unrecht hast - > sondern dass du ziemlich enge Scheuklappen trägst. Das hat nichts mit Scheuklappen zu tun. Der TO fragt danach ob ein FPGA geeignet ist. Ja das ist er und zwar richtig gut. Ohne weitere Infos nehme ich erstmal an dass er erstmal harte Echtzeit Bedingungen hat und ich impliziere durch die Frage nach dem FPGA dass er ein Embedded System moechte (sonst haette er nicht nach nemm FPGA gefragt sondern wohl gleich wie er mi den Daten in den PC kommt, soviel Verstand traue ich jemanden zu der hier fragt). Und ich finde es immer wieder verwerflich wenn Leute eine klare Frage stellen (in diesem Fall schafft das ein FPGA und welche Leistungsklasse braucht er) immer wieder der Einwand kommt es anderst zu machen, obwohl die Aufgabe nicht bekannt ist. Es wird doch einen Grund geben warum er nach FPGA fragt, ich behaupte das ist eine gute Idee und in dem ganzen Topic hab ich eingeworfen dass das auch kein Aufwand ist und er da ein Lebenswerk vor sich hat. Nicht mehr und nicht weniger. Wenn beim Requirements Engineering erstmal keine Fakten vorhanden sind, dann geht man eben vom schlimmsten aus, zumal in diesem Fall ein FPGA nicht ansatzweise so schlimm ist wie dargestellt. Kantendetektion udn Hochpassfilter sind 2 hervorragende Beispiele die sich im FPGA implementieren lassen. Da braucht selbst ein Anfaenger nicht davor zurueck zuschrecken. S. R. schrieb: >> Du machst den gleichen Denkfehler wie Donni, weil du glaubst >> dass die Entwicklung aufwendig ist. > > Oh, das ist sie. Dein Denkfehler ist zu behaupten, dass FPGA-Entwicklung > ähnlich einfach und effizient ist wie Programmierung. Naja du beschreibst halt immer noch nicht wo da irgendwelche potentielle Huerden sein sollen. Das ist halt auch wieder nur inhaltloses Geblubber und zeugt nicht davon, dass du viel Erfahrung in der FPGA Entwicklung hast (zumindest nicht in der modernen). S. R. schrieb: >> Und Funfact am Rande: Was steckt in diesen KArten drin? >> Ein FPGA, welch Wunder. > > Ich bin mir ganz sicher, dass in den Webcams kein FPGA drin ist, viel zu > teuer und zu energieintensiv. Die eine Cam hat schon gute 10 Jahre auf > dem Buckel. Wuesste nicht wo ich das behauptet habe, eine Webcam ist halt auch keine HDMI Grabberkarte. ;-) S. R. schrieb: >> Die Beschaffungskosten sind erstmal hoeher als beim FPGA. >> Ein Evalboard mit HDMI In/Out liegt bei ca. 200€. Dafuer >> bezahlst du alleine die Grabberkarte. > > Aber für die entsprechenden FPGAs sind da die Lizenzkosten für > Vivado/Quartus noch nicht mit drin. Die IPs für HDMI kommen ebenfalls > nicht gratis - im Gegensatz zu OpenCV und gcc. Beide mit kommerzieller > Qualität. Lizenzkosten fallen fuer das obige Board keine an und die IPs kann er 4 Stunden frei nutzen bevor sie Offline gehen. Danach muss er das Board resetten. Wenn er das ganze verkommerzialisiert dann kann er auch das bisschen Kleingeld fuer die IPs berappen. S. R. schrieb: >> Und um sich in die FPGA Toolchain einarbeiten geht wahrscheinlich sogar >> schneller, als sich in die unzaehligen PC basierten Video >> Bearbeitungsframeworks einzuarbeiten. > > Es reicht, sich in eine FPGA-Toolchain einzuarbeiten und es reicht, > sich in ein Bildbearbeitungsframework einzuarbeiten. Schau dich mal > auf dem Arbeitsmarkt um, was da fähigen Softwareentwicklern rumläuft und > vergleiche das mit der Anzahl an fähigen FPGA-Entwicklern. > > Wenn du FPGA kannst und Software nicht - und so schätze ich dich ein - > dann bist du ein Paradebeispiel für Hammer, Nägel und Aussehen. Ich mache sowohl das eine, als auch das andere, daher kann ich das auch ganz gut miteinander vergleichen. Und ich behaupte auch nicht dass man mit einem FPGA schneller unterwegs ist, jedoch sind die Zeitskalen nicht so dramatisch weit auseinander wie hier gemacht wird. Und wenn das ganze in ein Embedded System verpackt wird, dann holt der FPGA auch noch deutlich auf, weil der ganze OS Spass mit Yocto oder Buildroot wegfaellt. Bis da ein System mal durchkonfiguriert ist und gebaut, geht auch einige Zeit ins Land. Nicht zu vergessen der Wartungsaufwand den du dir einfaengst weil du ein viel komplexeres System hast (kannst ja mal ein Schichtenmodell fuer beide Varianten aufstellen). Ich bevorzuge halt in allen Bereichen moderne Loesungen und moderne Loesungen gehen halt immer mehr in Richtung rapid Prototyping und da hat die FPGA Welt in den letzten paar wenigen Jahren extremst aufgeholt. Da muss man sich halt mal rantrauen, dann erkennt man auch das Potenzial. Gustl B. schrieb: > Selbst 4 Frames Latenz sind bei 30 Fps 133 ms. Das ist schon so viel > dass man damit z. B. keine Shooter mehr sinnvoll zocken kann. Immerhin gehen in dem Bereich die Latenzen vom OS Scheduler unter. ;-) Aber ein interessantes Beispiel mit den Spielen, jedoch in der Diskussion nicht ganz passend, weil moderne Grafikkarten (zumindest die fuer die Spieler) halt aufs Rendern optimiert sind. Da muessen dann deutlich weniger Daten im Speicher geschoben werden was die Latenzen auch wieder angenehm nach unten drueckt. Gustl B. schrieb: > Aber noch zu den Framegrabbern: > Die gibt es in extrem günstig > Ebay-Artikel Nr. 264798031041? > aber ob da ein FPGA drinnen ist? Man findet zwar Bilder vom Innenleben > diverser Grabber, aber da sind die ICs abgeschliffen. Allerdings liefert > so ein Grabber ganz sicher kein Rohbild. Das passt nämlich nicht durch > USB2. Sicher nicht, aber wie du sagst, da ist nix mit Rohbild. Da wird ein kleiner ARM basierter Prozessor mit einem Hardware H.264/265 oder aehnlichem Encoder drinnen stecken. Aehnlich wie ein Raspberry Pi nur abgespeckt.
Tobias B. schrieb: > Ich behaupte auch nicht das man mit OpenCV langsam ist, sondern dass man > mit einer FPGA Loesung genauso schnell ans Ziel kommt. Hier kuemmert > sich auch das SDK um den HDMI In- und Output und den HLS Code fuer einen > Videofilter schreibst du auch in einem Texteditor und fertig. Und wenn > man mag auch direkt als HDL, ist etwas aufwendiger aber nicht dass man > gleich in ganz andere Zeitskalen vorrueckt. Jetzt aber nicht im Ernst, oder? Bei der so tollen HLS-Geschichte sind noch einige Dinge nicht sauber definiert, wie Rundungen, Dithering, Overflow-Szenarion, etc. - aber aus C-Konstrukten HDL zu machen ist auch einfach IMHO broken by design. Das dann aber in Verbindung mit med. Diagnostik zu bringen? Sehr mutig. Den jetzigen Status kenne ich nicht, beim letzten Regresstest, nachdem das Vivado-Zeug in die Ecke flog, stellte sich raus: Simulation korrekt, post-map-Verifikation: Overflow-Szenario moeglich. Ja, man hat ein schnelles Ergebnis, aber debuggt sich dann einen Wolf bei den Details. Als ich das letzte mal beim grossen X am Stand (EW 2018) eine HLS-Filter-Demo gesehen habe, stellte sich auf genaue Nachfrage hinaus, dass ein Teil auf dem ARM-Core laeuft, aus Zeitgruenden, gemeint war die Erstellungsdauer der Demo. Bei einer anderen Bude, die ich hier mal nicht nenne, habe ich mit ner blauen LED-Lampe in die Linse geleuchtet. Ups, woher kommt das Schwarz? Lasse mich gerne updaten, aber glaube es nur noch, wenn ich die Testbench der vollen Simulation, und zwar im VHDL-Modell gesehen habe (es gibt eine Menge kaputter Verilog-Modelle, die signed extension nicht richtig machen). Zum Thema SDK/Linuxkameras wurde wohl schon alles gesagt, man kriegt mit einer gstreamer-OpenCV-Pipeline locker unter 30 ms Latenz hin. Geht auch drunter (< 1ms mit RT-Erweiterungen wie Xenomai), aber da die Interfaces schon gar nicht geklaert sind, sind Ende-Zu-Ende-Erwaegungen erst mal voellig irrelevant.
Martin S. schrieb: > Bei der so tollen HLS-Geschichte sind noch einige Dinge nicht sauber > definiert, wie Rundungen, Dithering, Overflow-Szenarion, etc. - aber aus > C-Konstrukten HDL zu machen ist auch einfach IMHO broken by design. > > Das dann aber in Verbindung mit med. Diagnostik zu bringen? Sehr mutig. > Den jetzigen Status kenne ich nicht, beim letzten Regresstest, nachdem > das Vivado-Zeug in die Ecke flog, stellte sich raus: Simulation korrekt, > post-map-Verifikation: Overflow-Szenario moeglich. Ja, man hat ein > schnelles Ergebnis, aber debuggt sich dann einen Wolf bei den Details. Manche Dinge gehen gut, manche nicht. Von Diagnostik habe ich docht nichts geschrieben, wobei auch das Feld Diagnostik riesig ist. Einen Hochpass Filter ist Beispielsweise ein gutes Beispiel wo HLS die Entwicklung beschleunigen kann, die besser sichtbaren Kanten koennen der Diagnostik dienen. Haengt jetzt davon ab was du unter Diagnostik verstehst, die Diagnose macht immerhin noch der Arzt. Eine maschinelle Tumorerkennung wuerde ich z.B. niemals in einem FPGA realisieren, weil viel zu komplex. Aber hier hat man auch keine Echtzeit Bedingung und es reicht jeden n-ten Frame zu untersuchen. Aber ich gestehe: Das "genauso schnell" ist vll. uebertrieben, nenne wir es "nur unwesentlich langsamer". Ich will jetzt hier auch keine HLS Werbung machen, weil ich selbst kein Fan davon bin. Fakt ist aber, dass man fuer verhaeltnismaessig einfache Applikationen ein Werkzeug hat, mit denen man schnell ans Ziel kommt. Leider oft zu Lasten der Qualitaet mit den ganzen Krankheiten die dahinter stecken, weswegen ich das nicht unbedingt in sicherheitskritischen Applikationen wie Medizintechnik einsetzen wuerde (zumindest nicht in Klasse C oder auch B). Aber fuer einen Einsteiger zum ein bisschen am ersten Videofilter rumspielen, warum nicht? Und was anderes habe ich auch nie behauptet. Ich frag mich langsam echt was hier immer wieder gelesen wird um es hinterher aus dem Zusammenhang zu reissen - das obige HLS Beispiel steht im Kontext zum Vergleich mit dem Pythin 10 Zeiler und via HLS hat man eben auch entsprechend kompakten Code. Vielleicht sollten alle mal etwas runterfahren und am eigenen Textverstaendnis arbeiten. Wuerde allen hier besser stehen. ;-) Martin S. schrieb: > Zum Thema SDK/Linuxkameras wurde wohl schon alles gesagt, man kriegt mit > einer gstreamer-OpenCV-Pipeline locker unter 30 ms Latenz hin. Geht auch > drunter (< 1ms mit RT-Erweiterungen wie Xenomai), aber da die Interfaces > schon gar nicht geklaert sind, sind Ende-Zu-Ende-Erwaegungen erst mal > voellig irrelevant. Das ist klar, muss ja auch, sonst muss man anfangen Frames zu droppen. Unterhalb 1ms klappt dann halt auch schon nicht mehr auf der CPU weil die der Scheduler vom OS in die Quere kommt. Deshalb gehen viele Hersteller hin und bieten eine Grabberkarte mit FPGA an. Via Software lassen sich relativ einfach in einer GUI Videofilter zusammenstellen, das wird dann in den FPGA geladen und gut ist. Wie weit man mit Xenomai kommt weiss ich nicht, ich finde da auf die schnelle keine Benchmarks. Wenn ich mir die Latenz von den ganzen USB Grabberkarten anschaue, dann gehen aber selbst die 30ms unter und haben keine Relevanz mehr. ;-)
:
Bearbeitet durch User
Gustl B. schrieb: > Selbst 4 Frames Latenz sind bei 30 Fps 133 ms. Das ist schon so viel > dass man damit z. B. keine Shooter mehr sinnvoll zocken kann. Für übliche Videoverarbeitung ist das z.B. völlig ausreichend. > Man findet zwar Bilder vom Innenleben diverser Grabber, > aber da sind die ICs abgeschliffen. Allerdings liefert > so ein Grabber ganz sicher kein Rohbild. Das passt nämlich > nicht durch USB2. Die Dinger liefern alle ein Rohbild, nur eben mit verminderter Auflösung bzw. verminderter Bildwiederholrate. Wie der von mir genannte Grabber: 4k60 mit MJPG, 4k30 mit VUY420 oder 720p15 mit YUV420 über USB2. Ich habe noch kein UVC-Gerät gesehen, was nicht mindestens einen YUV-Modus hatte. Müsste aber im Standard nachschlagen, ob das garantiert ist. Tobias B. schrieb: > Das [8 bzw. 4 Frames] ist schon ein Haufen Holz. > Und ich habe auch nie etwas vom einstelligen ns Bereich geschrieben. Naja, du schriebst von einzelnen Pixeltakten. Als ob es zwingend notwendig sei, dass man die Daten live ohne Pufferung jenseits von ein paar Flipflops filtern können müsse. Und das muss man eben oft genug (meist) nicht. > Dort wo es auf Hand / Auge Koordination ankommt hat man haeufig > die Anforderung dass man unterhalb 2 Frames bleiben muss. Das ist richtig, aber eben - wie gesagt - anforderungsabhängig. Deswegen haben moderne Fernseher einen "Game Mode" mit möglichst geringer Latenz (meist trotzdem 2 Frames oder mehr) und einen normalen Modus, der auch deutlich mehr haben kann. > Aehnlich dem Beispiel das ich mit dem Keyboarder gegeben habe. > Deine 4 Frames sind hier schon 64 ms, da faengt es schon > an eklig zu werden und 8 Frames mit den 128 ms sind in keinster Weise > mehr akzeptabel Ich weiß, aber wie gesagt, das hängt von den Anforderungen ab. Und in der Regel sind 1-2 Frames problemlos tolerierbar - und dazu braucht es keinen FPGA. Dass wir meist 8 Frames haben, ist historisch gewachsen. > Auch dort wo schnell auf den Bildinhalt reagiert werden muss, z.B. > Kollisionsdetektion, kann ich mir nicht vorstellen dass 8 Frames > akzeptabel sind. Naja, so viel schlechter als die menschliche Reaktionszeit ist das nicht. Nur mit dem Unterschied, dass maschinelle Bildverarbeitung immer das gesamte Bild betrachtet und nicht nur einen kleinen Fokuspunkt. Und meines Wissens arbeiten viele Algorithmen im autonomen Fahren ohnehin nur auf einem Subset aller Frames, in Graustufen und zweidimensional. Ist vielleicht besser geworden, weiß ich nicht. > Das hat nichts mit Scheuklappen zu tun. Der TO fragt danach ob > ein FPGA geeignet ist. Ja das ist er und zwar richtig gut. ...und das wiederum hängt davon ab, was er eigentlich mit den Daten machen möchte. Und das wissen wir nicht. > Ohne weitere Infos nehme ich erstmal an dass er erstmal harte > Echtzeit Bedingungen hat und ich impliziere durch die Frage > nach dem FPGA dass er ein Embedded System moechte Das sind so ziemlich die extremsten Annahmen, die du treffen kannst - und in diesem Forum so ziemlich immer falsch. Wenn Begriffe wie "Echtzeit" auftauchen, dann ist damit ziemlich oft weder harte noch weiche Echtzeit gemeint (und auch nicht im Sub-Millisekundenbereich). > Es wird doch einen Grund geben warum er nach FPGA fragt, > ich behaupte das ist eine gute Idee und in dem ganzen > Topic hab ich eingeworfen dass das auch kein Aufwand ist > und er da ein Lebenswerk vor sich hat. Nicht mehr und nicht weniger. Ich behaupte, dass er nach FPGA fragt, weil er gelesen hat, dass die benutzt werden und wissen wollte, ob das für ihn passt. Weil das ist hier die übliche Vorgehensweise. :-) > Wenn beim Requirements Engineering erstmal keine Fakten vorhanden > sind, dann geht man eben vom schlimmsten aus, zumal in diesem Fall > ein FPGA nicht ansatzweise so schlimm ist wie dargestellt. Wenn man schon ein paar Jahre damit gearbeitet hat, sind FPGAs nicht schlimm. Wenn nicht, dann... verbringt man damit erstmal ein paar Jahre, bis man ordentliche Ergebnisse (jenseits der Trivialfälle) bringt. Zu HLS muss ich nichts weiter sagen, das haben andere bereits getan. > Kantendetektion udn Hochpassfilter sind 2 hervorragende > Beispiele die sich im FPGA implementieren lassen. Das ist richtig. Und jetzt bitte noch Objekterkennung dazu, am besten mit TensorFlow, weil es da bereits fertige Modelle gibt. Und schon ist dein FPGA tot. > Naja du beschreibst halt immer noch nicht wo da > irgendwelche potentielle Huerden sein sollen. Die FPGA-Werkzeuge (ich kenne ISE und Vivado, gehe aber davon aus, dass sich das alles nichts nimmt) sind wesentlich komplizierter in ihrer Bedienung als übliche Programmier-IDEs, weil der grundlegende Workflow komplizierter ist. Hat man das einmal verstanden, nimmt sich das nicht viel - bis dahin scheitert man an jeder Ecke. Die verwendeten HDL-Sprachen (Verilog, VHDL) sind wesentlich komplizierter als übliche Programmiersprachen und erfordern ein massives Umdenken. Ohne das mal von Grund auf gelernt zu haben wird das absolut garnix. Die Dokumentation von FPGA-Entwicklung ist wesentlich schlechter als von Programmierung. Einfach bedienbare SDKs und Bibliotheken, wie es sie in der Programmierwelt zuhauf gibt (z.B. OpenCV, Python, Matlab) sind in der FPGA-Welt entweder nicht vorhanden oder sehr schnell sehr teuer. Und das meinte ich, als ich schrieb, dass ein Student, der ein Bildfilter in einer Woche hingeschrieben bekommt, vorher auch drei bis neun Monate Tiefenbespaßung mit FPGAs hatte. Denn sonst kriegt der das nicht hin. > Das ist halt auch wieder nur inhaltloses Geblubber > und zeugt nicht davon, dass du viel Erfahrung in der > FPGA Entwicklung hast (zumindest nicht in der modernen). Nur weil ich nicht alles hinschreibe, weil ich nicht für Romane bezahlt werde, ist meine Aussage also wertlos. Interessante Denkweise. > Wuesste nicht wo ich das behauptet habe, eine Webcam > ist halt auch keine HDMI Grabberkarte. ;-) Ich bin mir sehr sicher, dass unser HDMI-Grabber auch kein FPGA ist. Und eine Webcam unterscheidet sich von einem HDMI-Grabber jetzt auch nicht besonders... vor allem dann nicht, wenn aus beiden ein UVC-Anschluss rausfällt. > Ich mache sowohl das eine, als auch das andere, daher kann ich das > auch ganz gut miteinander vergleichen. Und ich behaupte auch nicht > dass man mit einem FPGA schneller unterwegs ist, jedoch sind die > Zeitskalen nicht so dramatisch weit auseinander wie hier gemacht wird. Das gilt unter der Voraussetzung, dass man mit FPGAs umgehen kann. Im Gegensatz zur normalen Programmierung ist das jedoch nicht der Fall. Die Einstiegshürden sind deutlich höher. > Und wenn das ganze in ein Embedded System verpackt wird, dann > holt der FPGA auch noch deutlich auf, weil der ganze OS Spass > mit Yocto oder Buildroot wegfaellt. In der Regel kommt ein FPGA nicht alleine. Zumindest in der Vergangenheit, in der ich mal lebte, klebte da immer ein SoC in der Nähe, für den man ein passendes Image brauchte. Ob ich das Yocto nun für meinen SoC mit Grabberkarte konfiguriere und alles in OpenCV entwickle, oder ob ich das Yocto für den Xilinx Zynq konfiguriere, um die Daten vom FPGA über Ethernet rauszuschieben, ist doch am Ende egal. Oder implementierst du Ethernet, Webserver und TLS-Layer auch in HDL? > Ich bevorzuge halt in allen Bereichen moderne Loesungen und > moderne Loesungen gehen halt immer mehr in Richtung rapid > Prototyping und da hat die FPGA Welt in den letzten paar > wenigen Jahren extremst aufgeholt. Also in meiner Erfahrung lässt sich Rapid Prototyping wesentlich einfacher am PC erledigen... billige USB Webcam ranklemmen, die Algorithmen in Python runterschreiben und mal schauen - während der Grabber noch bei der Post liegt. Das kriege ich wahrscheinlich schneller hin als Vivado zu installieren, ein FPGA-Board zu bestellen und den ersten Frame da korrekt einzuspeisen. > Gustl B. schrieb: >> Aber noch zu den Framegrabbern: >> Die gibt es in extrem günstig >> Ebay-Artikel Nr. 264798031041? >> aber ob da ein FPGA drinnen ist? Man findet zwar Bilder vom Innenleben >> diverser Grabber, aber da sind die ICs abgeschliffen. Allerdings liefert >> so ein Grabber ganz sicher kein Rohbild. Das passt nämlich nicht durch >> USB2. > > Sicher nicht, aber wie du sagst, da ist nix mit Rohbild. Da wird ein > kleiner ARM basierter Prozessor mit einem Hardware H.264/265 oder > aehnlichem Encoder drinnen stecken. Aehnlich wie ein Raspberry Pi nur > abgespeckt. Das Teil ist ein stinknormales UVC-Device und spricht MJPG (ist angegeben) und ziemlich sicher auch YUV (vermutlich YUV422 @ 720p15 oder so). Mit H.264 ist da nix, denn damit kann man außer direktem Livestreaming nicht viel anfangen. In der Regel will man aber zwischendurch bearbeiten (z.B. zusätzliche Informationen einblenden), das geht mit H.264 nicht besonders gut. Außerdem konvertiert das Teil eingangsseitig von 4K (wahrscheinlich 4K30) auf 1080p30 runter. Das ist heutzutage alles Standard in SoCs, da braucht man keinen FPGA für. In billigen China-Tablets sind oft Kamerasensoren drin, die keine Bayerdaten ausgeben, sondern YUV. Entsprechend können die ganzen Billigchipsätze damit nativ umgehen.
S. R. schrieb: > Gustl B. schrieb: >> Selbst 4 Frames Latenz sind bei 30 Fps 133 ms. Das ist schon so viel >> dass man damit z. B. keine Shooter mehr sinnvoll zocken kann. > > Für übliche Videoverarbeitung ist das z.B. völlig ausreichend. Was ist denn die uebliche Videoverarbeitung? Gibt es da eine Definition was ueblich und unueblich ist? S. R. schrieb: > Tobias B. schrieb: >> Das [8 bzw. 4 Frames] ist schon ein Haufen Holz. >> Und ich habe auch nie etwas vom einstelligen ns Bereich geschrieben. > > Naja, du schriebst von einzelnen Pixeltakten. Als ob es zwingend > notwendig sei, dass man die Daten live ohne Pufferung jenseits von ein > paar Flipflops filtern können müsse. > > Und das muss man eben oft genug (meist) nicht. Dann kannst du das doch bestimmt zitieren wo ich das geschrieben habe? Oder kann es sein, dass ich nur geschrieben habe, dass ein FPGA dazu in der Lage ist und man daher "wirkliche" Echtzeitbedingungen erfuellen kann? Es ist schon der Wahnsinn wie sehr du dir einbildest dass ich den Software Ansatz verteufle und mir deshalb irgendwelche Worte in den Mund legst. S. R. schrieb: >> Das hat nichts mit Scheuklappen zu tun. Der TO fragt danach ob >> ein FPGA geeignet ist. Ja das ist er und zwar richtig gut. > > ...und das wiederum hängt davon ab, was er eigentlich mit den Daten > machen möchte. Und das wissen wir nicht. Mit den gegebenen Anforderung ist ein FPGA ganz kalr ein Kandidat um die Aufgabe zu loesen. HDMI, Datenrate, Echtzeit und seine Beispiel Algorithmen. Nichts was der FPGA nicht schafft und auch nichts was komplex/teuer zu implementieren ist. Er fragt ob FPGA geeignet ist und das ist er. S. R. schrieb: > Das sind so ziemlich die extremsten Annahmen, die du treffen kannst - > und in diesem Forum so ziemlich immer falsch. Wenn Begriffe wie > "Echtzeit" auftauchen, dann ist damit ziemlich oft weder harte noch > weiche Echtzeit gemeint (und auch nicht im Sub-Millisekundenbereich). Mal wieder eine der inhaltslosen Verallgemeinerungen. Fakt ist dass ein FPGA fast keine Einschraenkungen mit Echtzeitanforderungen hat. Die Loesung mit dem FPGA schraenkt daher erstmal den sehr allgemeinen Loesungsraum nicht ein und ist daher auch erstmal eine technologisch sinnvolle Loesung. Erst durch deine Verallgemeinerungen greifen deine Argumente und das ist wirklich schlechter Diskussionsstil. S. R. schrieb: >> Kantendetektion udn Hochpassfilter sind 2 hervorragende >> Beispiele die sich im FPGA implementieren lassen. > > Das ist richtig. Und jetzt bitte noch Objekterkennung dazu, am besten > mit TensorFlow, weil es da bereits fertige Modelle gibt. > > Und schon ist dein FPGA tot. Auch hier passt du wieder die Anforderungen willkuerlich an. Wenn das die Anforderungen waeren wuerde ich zwar auch ein FPGA nehmen, aber etwas aus der Ultrascale+ Klasse und eine Mischung aus FPGA, CPU und GPU fahren. Sonst behaupte ich jetzt: Und jetzt noch bitte Latenz unter 1 us und schon ist deine Software tot. Aber das merkst du hoffentlich selbst, dass dein Argument ein bisschen peinlich war. S. R. schrieb: > Die FPGA-Werkzeuge (ich kenne ISE und Vivado, gehe aber davon aus, dass > sich das alles nichts nimmt) sind wesentlich komplizierter in ihrer > Bedienung als übliche Programmier-IDEs, weil der grundlegende Workflow > komplizierter ist. Hat man das einmal verstanden, nimmt sich das nicht > viel - bis dahin scheitert man an jeder Ecke. > > Die verwendeten HDL-Sprachen (Verilog, VHDL) sind wesentlich > komplizierter als übliche Programmiersprachen und erfordern ein massives > Umdenken. Ohne das mal von Grund auf gelernt zu haben wird das absolut > garnix. > > Die Dokumentation von FPGA-Entwicklung ist wesentlich schlechter als von > Programmierung. Einfach bedienbare SDKs und Bibliotheken, wie es sie in > der Programmierwelt zuhauf gibt (z.B. OpenCV, Python, Matlab) sind in > der FPGA-Welt entweder nicht vorhanden oder sehr schnell sehr teuer. > > Und das meinte ich, als ich schrieb, dass ein Student, der ein > Bildfilter in einer Woche hingeschrieben bekommt, vorher auch drei bis > neun Monate Tiefenbespaßung mit FPGAs hatte. Denn sonst kriegt der das > nicht hin. Auch das ist ein Block an Verallgemeinerungen und persoenlichen Erfahrungen. Warum gehst du davon aus dass der TO da auch Probleme haben wird? Weil du es nicht hinbekommst, kann er es auch nicht? Ich kann mich noch ziemlich genau an mein erstes FPGA Projekt erinnern. Auslesen und auswerten von einem 3D Gyrosensor. Das war in 3 Monaten, inkl. grafischer Darstellung in Labview und Platinen Fertigung (Entflechten, Layouten, Aetzen, Bestuecken) abgeschlossen. Unterschaetz mir die Studenten nicht, nur weil du selbst deine Schwierigkeiten hast. Recht gebe ich dir aber in dem Punkt mit der Informationsmenge. Die ist in der FPGA in der Tat deutlich spaerlicher, aber in der Qualitaet absolut brauchbar. Muss man sich halt reinarbeiten. Deshalb jemanden abzuraten er soll statt einem FPGA was anderes nehmen ist aus diesem Grund voellig absurd. S. R. schrieb: > In der Regel kommt ein FPGA nicht alleine. Zumindest in der > Vergangenheit, in der ich mal lebte, klebte da immer ein SoC in der > Nähe, für den man ein passendes Image brauchte. Das ist auch wieder eine Verallgemeinerung die ueberhaupt nichts zur Sache beitraegt. Sehr wohl kommen in den verschiedensten Bereichen FPGAs alleine vor. Ist aber voellig unabhaengig von dieser Diskussion. In dem Fall des TO ist die Frage gerade FPGA vs PC, bzw. FPGA vs SoC. Und wenn man pro SoC argumentiert, weil das einfacher und schneller entwickelt ist, dann muss man auch den Mehraufwand fuer die Bereitstellung des zugrundelegenden Systems betrachten. Habe ich schon angemerkt, dass hier unbedingt etwas mehr Kompetenz zum Thema Textverstaendnis noetig waere? S. R. schrieb: > Ob ich das Yocto nun für meinen SoC mit Grabberkarte konfiguriere und > alles in OpenCV entwickle, oder ob ich das Yocto für den Xilinx Zynq > konfiguriere, um die Daten vom FPGA über Ethernet rauszuschieben, ist > doch am Ende egal. Oder implementierst du Ethernet, Webserver und > TLS-Layer auch in HDL? Auch hier, Verallgemeinerung war nicht das Thema. Selbstverstaendlich wuerde ich das nicht in HDL machen (vll. Ethernet noch in absoluten Ausnahmefaelle wenn man z.B. aufgrund irgendwelchen Risikomanagements keine Software im System haben moechte um die Zulassung zu vereinfachen). Habe ich auch nie behauptet. Irgendwie glaub ich langsam, dass das ein seltsamer Fetisch ist. S. R. schrieb: > Also in meiner Erfahrung lässt sich Rapid Prototyping wesentlich > einfacher am PC erledigen... billige USB Webcam ranklemmen, die > Algorithmen in Python runterschreiben und mal schauen - während der > Grabber noch bei der Post liegt. Das kriege ich wahrscheinlich schneller > hin als Vivado zu installieren, ein FPGA-Board zu bestellen und den > ersten Frame da korrekt einzuspeisen. Aus meiner auch. Wenn ich einen Videofilter selbst entwickeln muss, mache ich das auch erst am PC, am liebsten mit Python. Damit kann man sich dann auch direkt Testvektoren fuer die HDL Simulation generieren. Trotzdem bleibt die Aussage korrekt das die FPGA Industrie immer weiter daran arbeitet die Methoden zu verbessern (oder sich neue Auszudenken) um das Rapid Prototyping auf FPGA Basis voranzubringen. HLS und SDAccel sind da die prominentesten Beispiele aus dem Hause Xilinx (sorry fuer die staendige Xilinx Werbung, aber da bin ich nunmal am tiefsten drin). S. R. schrieb: > Außerdem konvertiert das Teil eingangsseitig von 4K (wahrscheinlich > 4K30) auf 1080p30 runter. Das ist heutzutage alles Standard in SoCs, da > braucht man keinen FPGA für. Auch hier: Hab ich nie behauptet, lern lesen. Zumal du mir zustimmst da du selbst SoCs schreibst (nichts anderes ist ein ARM Core mit einem HW Encoder). Und ob H.264/265 oder MJPG ist unerheblich, es wird halt komprimiert damit man die Daten via USB 2.0 rausschaufeln kann. Am PC kommst du zwar an jedes Pixel zur weiteren Verarbeitung ran in der Gesamtheit hat dein Bild halt Informationen aufgrund der Komprimierung verloren.
:
Bearbeitet durch User
Tobias B. schrieb: > Und ob H.264/265 oder MJPG ist unerheblich, es wird halt > komprimiert damit man die Daten via USB 2.0 rausschaufeln kann. Richtig, aber irrelevant. Es gibt neben USB 2.0 auch modernere Alternativen gibt, für die das nicht mehr gilt. Zum Beispiel das inzwischen ziemlich weit verbreitete USB 3.1 oder - weil ich damit arbeite - MIPI-CSI. > Am PC kommst du zwar an jedes Pixel zur weiteren Verarbeitung > ran in der Gesamtheit hat dein Bild halt Informationen aufgrund > der Komprimierung verloren. Naja, wenn du weiterhin der Meinung bist, dass aus einem UVC-Gerät ausschließlich verlustbehaftete komprimierte Daten rauskommen, dann will ich dich mal in deiner Welt nicht weiter stören. Auf den Rest deiner Ausführungen gehe ich nicht weiter ein. Das wird ein Roman, den du dann wieder mit Nebenkriegsschauplätzen zerfaserst. Da ist mir meine Zeit zu schade. Der TO hat eh nur getrollt.
S. R. schrieb: >> Am PC kommst du zwar an jedes Pixel zur weiteren Verarbeitung >> ran in der Gesamtheit hat dein Bild halt Informationen aufgrund >> der Komprimierung verloren. > > Naja, wenn du weiterhin der Meinung bist, dass aus einem UVC-Gerät > ausschließlich verlustbehaftete komprimierte Daten rauskommen, dann will > ich dich mal in deiner Welt nicht weiter stören. > > Auf den Rest deiner Ausführungen gehe ich nicht weiter ein. Das wird ein > Roman, den du dann wieder mit Nebenkriegsschauplätzen zerfaserst. Da ist > mir meine Zeit zu schade. Der TO hat eh nur getrollt. Auch hier wieder, du hast wirklich ein Problem mit Textverstaendnis. Das war im Zusammenhang mit dem USB 2.0 Geraet. Wenn du mir erklaerst wie man ein 1080p@30 Hz Video ueber USB 2.0 schaufeln kannst ohne Komprimierung, waere das sehr spannend zu Erfahren. Kleine Rechenhilfe: 1920x1080x30Hzx24bit = ca. 1.5 Gb/s. Das sind 3x soviele Daten wie die USB 2.0 Spezifikation vorsieht. So langsam muss es doch auch dir mal peinlich sein? Les doch einfach ein zweites mal bevor du schreibst. ;-)
:
Bearbeitet durch User
Tobias B. schrieb: > Wenn du mir erklaerst wie > man ein 1080p@30 Hz Video ueber USB 2.0 schaufeln kannst Ich habe nie behauptet, dass dies möglich sei.
Offensichtlich behauptest du dass aus einem UVC Geraet keine verlustbehafteten Daten rauskommen. Dann kannst dua uch erklaeren wie du ein 1080p bei 30Hz ueber USB 2.0 uebertraegst. Oder musst du etwa zugeben, dass du mir falsche Worte in den Mund gelegt hast? Ala S. R. schrieb: > Naja, wenn du weiterhin der Meinung bist, dass aus einem UVC-Gerät > ausschließlich verlustbehaftete komprimierte Daten rauskommen, dann will > ich dich mal in deiner Welt nicht weiter stören. ??? Bloed, nich? Ist aber auch nicht weiter schlimm. Jetzt faellt mir auch endlich wieder ein woher ich dein Nutzername kenne. Und wenn man sich alte Diskussionen von dir ansieht, sieht man immer wieder das selbe Muster, nahe an der Grenze zum Getrolle. Eigentlich schade, haette ich mir viel Lebenszeit ersparen koennen. :-(
:
Bearbeitet durch User
Tobias B. schrieb: > Offensichtlich behauptest du dass aus einem UVC Geraet keine > verlustbehafteten Daten rauskommen. Dein Textverständnis ist mangelhaft und dein Wissen für jemanden, der anderen "mach mal ein Praktikum" empfiehlt, ebenfalls. Alle mir bekannten UVC-Geräte (das sind einige) bieten sowohl MJPG als auch YUV an. Der Treiber entscheidet. Die verfügbaren Auflösungen und Bildwiederholraten orientieren sich an der Bandbreite. Soll ich dir das jetzt noch Waldorfschulengerecht vortanzen? Muss ich dir, einem Profi vom Fach, erklären, was "720p15" bedeutet? Kennst du das Konzept "es gibt mehrere Möglichkeiten" oder "Kompromiss"? Tobias B. schrieb: > Dann kannst dua uch erklaeren wie du > ein 1080p bei 30Hz ueber USB 2.0 uebertraegst. Ich habe noch immer nicht behauptet, dass dies möglich sei. Dementsprechend werde ich dir auch nicht erklären, wie etwas Unmögliches durchgeführt wird.
S. R. schrieb: > Tobias B. schrieb: >> Dann kannst dua uch erklaeren wie du >> ein 1080p bei 30Hz ueber USB 2.0 uebertraegst. > > Ich habe noch immer nicht behauptet, dass dies möglich sei. > Dementsprechend werde ich dir auch nicht erklären, wie etwas Unmögliches > durchgeführt wird. Ein letztes mal, dann ists mir auch egal, du wirst es eh nicht raffen. Du legst mir Aussagen in den Mund die ich nie behauptet habe ala S. R. schrieb: > Naja, wenn du weiterhin der Meinung bist, dass aus einem UVC-Gerät > ausschließlich verlustbehaftete komprimierte Daten rauskommen, dann will > ich dich mal in deiner Welt nicht weiter stören. Ich drehe jetzt den Spiess um und Wende die gleiche Diskussionstaktik bei dir an Tobias B. schrieb: > Offensichtlich behauptest du dass aus einem UVC Geraet keine > verlustbehafteten Daten rauskommen. Dann kannst dua uch erklaeren wie du > ein 1080p bei 30Hz ueber USB 2.0 uebertraegst. Ich weiss genauso gut wie du, dass die Frage nicht beantwortet werden kann. Ich hoffe jedoch dass es bei dir klickt macht und die merkst was fuer einen asozialen Diskussionstil du hast. Und ja ich nenne es bewusst asozial, weil es nicht angehen kann, dass man sich erst fuer etwas vereidigen muss, was man nie behauptet hat, bevor man in der eigentlichen Diskussion fortfuehren kann. Soviel zur Rhetorik (wobei das eigentlich keine Rhetorik sondern Kindergarten Diskussionsnveau ist) und das war auch diesbezueglich der letzte Beitrag von mir. Vielleicht laesst sich der Thread ja noch noch retten. Und dazu ist es auch Wurst ob sich der TO nochmal meldet, das Thema ist auch so interessant genug um es zu diskutieren.
Tobias B. schrieb: > Soviel zur Rhetorik Naja, mit den ganzen Ad-Hominem-Angriffen hast du angefangen. :-)
Um die Diskussion nochmal mit ein paar Fakten aufzuwärmen: Die USB Video Class-Spezifikation spezifiziert viele mögliche Formate, schreibt aber keines zwingend vor. Was unter welchen Randbedingungen möglich ist, entscheidet also ausschließlich das Gerät. Eine Microsoft VX800 (USB 2.0) unterstützt beispielsweise ausschließlich YUY2 (also unkomprimiertes YUV 4:2:2), in allen Auflösungen und Bildwiederholraten. Eine hier rumliegende Logitech Konferenzkamera (USB 2.0) unterstützt sowohl MJPEG und YUY2, wobei beide Varianten sämtliche Auflösungen unterstützen. Die maximalen Bildwiederholraten unterscheiden sich, bei 1920x1080 sind es 30fps (MJPEG) bzw. 2fps (YUY2). Ein im Büro liegender HDMI-Framegrabber (USB 3.1) unterstützt MJPEG (komprimiert), YUY2 (unkomprimiert YUV 4:2:2) und NV12 (unkomprimiert YUV 4:2:0). MJPEG liefert maximal 4096x2304 bei 30 fps, NV12 maximal 3840x2160 bei ebenfalls 30 fps. Für YUY2 liegt die maximale Auflösung bei 3840x2160 und jeweils geringeren Bildwiederholraten verglichen mit NV12. (Consumer)4K-Video ist damit also problemlos drin. Nachtrag: An einem USB 2.0-Anschluss sind ebenfalls alle Auflösungen verfügbar, allerdings mit massiv reduzierten Bildwiederholraten bei den höheren Auflösungen. Ein UVC-Gerät mit MPEG2-TS, H.264 oder VP9 (alle spezifiziert) ist mir noch nicht untergekommen. Würden wir ohnehin nicht unterstützen können. Schlussfolgerung: USB-Kameras lassen sich prima auch ohne Kompressionsartefakte betreiben und sind damit für Videoverarbeitung grundsätzlich geeignet, egal ob mit oder ohne FPGAs. Hat mich jetzt nicht überrascht, schließlich habe ich das vor knapp einem Jahrzehnt schonmal gemacht. Man musste dem Treiber nur sagen, dass man YUY2 haben will.
:
Bearbeitet durch User
S. R. schrieb: > Schlussfolgerung: USB-Kameras lassen sich prima auch ohne > Kompressionsartefakte betreiben und sind damit für Videoverarbeitung > grundsätzlich geeignet Wird ja auch seit Jahren schon mit USB2.0 in der industriellen BV so gemacht. Gäbe auch noch den USBVision-Standard, die Latenzen sind auch da im Bereich von Zeilen bei entsprechend designten Video-Queues und Rolling-Shutter-Sensoren. Habe das hier auch schon mit Kameras auf FX3-Basis von LED-Blitz bis Monitor (ende zu ende) mit Photosensoren durchgemessen. Damit hat hoffentlich der akademische Kindergarten jetzt auch Sommerferien.
Ganz so einfach ist das nicht, denn er muss ja EchtzeitMuss schrieb: > 1080i ... filtern, also bei einer vollständigen Bildverarbeitung jeweils auf ein zuvor gespeichertes Halbbild zurückgreifen oder er hat jeweils nur den halben Informationsgehalt zum Bearbeiten. Und bei bewegten Bildern ist das nochmal was anderes. Erstmal müssen 2 Bilder erzeugt, dann gematched, nach Objekten getrennt und dann zeilenweise zusammengesetzt werden und das ganze gfs noch mit Subpixelinterpretatation, um die Bewegung rauszubekommen. In der Tat ginge das mit einer GPU am einfachsten, was den Erstellungsaufwand angeht (zumindest, wenn man bei Null anfängt und nichts parat hat). Der FPGA bleibt in jedem Fall die kosteneffektvste Lösung, was Stückkosten angeht, weil man nur ein SRAM und einen 10,- Euro FPGA braucht.
Jürgen S. schrieb: > Ganz so einfach ist das nicht, denn er muss ja >> 1080i > ... filtern, Naja, der TO schrieb "1080i=720p", also gehe ich mal davon aus, dass er damit die Bandbreite meint und nicht das exakte Format. Ansonsten hast du natürlich vollkommen recht.
Jürgen S. schrieb: > In der Tat ginge das mit einer GPU am einfachsten, was den > Erstellungsaufwand angeht (zumindest, wenn man bei Null anfängt und > nichts parat hat). Der FPGA bleibt in jedem Fall die kosteneffektvste > Lösung, was Stückkosten angeht, weil man nur ein SRAM und einen 10,- > Euro FPGA braucht. Je nach Algorithmus kann man vll sogar auf das Deinterlacing verzichten. Die Kantendetektion beispielsweise waere so ein Fall bei der man evtl. auch aus den Halbbildern brauchbare Informationen filtern kann. Haengt natuerlich stark vom Bildinhalt der Quelle ab. Aber ein Versuch ist es wert. :-)
Der TO meldet sich gar nicht mehr. Wie kommt das bloß? Liegt das u .U. an der heißen Luft die hier von den üblichen Verdächtigen ausgestoßen wird? Immerhin enthält die soviel Energie, dass man ein komplettes AKW einsparen könnte. kwt.
Tobias B. schrieb: > Je nach Algorithmus kann man vll sogar auf das Deinterlacing verzichten. > Die Kantendetektion beispielsweise waere so ein Fall bei der man evtl. > auch aus den Halbbildern brauchbare Informationen filtern kann. Aber in Y nur in der halben Auflösung und das ist durchaus ein Problem. Mit einem p-Format Kanten suchen, ist allerdings auch keine Herausforderung. Was nett ist, sind Kanten in einem lbl-Stereobild. Das läuft ähnlich, hat nur noch einen Freiheitsgrad mehr.
:
Bearbeitet durch User
Melodram schrieb: > Der TO meldet sich gar nicht mehr. Wie kommt das bloß? Es könnte auch daran liegen, dass der TO mal eben irgendwas in allenmöglichen Foren raushaut und dann ÜBERALL erklärt bekommt, dass seine Frage unvollständig ist, die Herangehensweise naiv wirkt, die Lösung auf der Hand liegt, weil FPGAs eben genau so etwas am Besten können (und das jedes Kind weis) und der TO dann den Schwanz einklemmt. Es könnte auch daran liegen, dass manch einer gerne ein wenig mitdiskutieren will und nicht mit Klarnamen postet, um sein Nichtwissen nicht zu offenbaren und dann "melodramatische" Zwischenrufe unter anderem nick in die Runde wirft, um seinen eingeklemmten Schwanz zu pflegen. Die Frage des TO klingt wie: Ich will gerne ein Radio bauen mit Empfang und so und wüsste gerne, ob das mit Elektronik zu machen ist. Oder ich will Bildverarbeitung mit MATLAB machen und bin nicht sicher, ob ein 3GHz PC dafür reicht oder ob es eine 5 GHz PC sein muss. Natürlich kann man Fragen zu FPGAs stellen, wenn man etwas nicht weis, aber: Solche Leute, lieber "Melodramatischer", die nicht einmal in der Lage sind, sich so einfach zu beantwortende Sachverhalte selber zu beantworten oder wenigstens die Fragen zu googlen, die sind in keinster Weise dafür geeignet, Elektronik, Software oder gar Bildverarbeitung zu machen. Wer von FPGAs so gar nichts weis, der braucht auch nicht zu glauben, dass er da irgendwass Sinnvolles zusammenbringt. BV ist zwar kein Zauberland, aber es braucht neben Grundlagenwisse eine gewisse Mindestintelligenz, die leider bei Vielen der Fratzenbuch/YT-Generation nicht vorliegt. Sie sind zu einfachsten Dingen nicht fähig, wollen aber ganz großartige Sachen machen.
Jürgen S. schrieb: > Aber in Y nur in der halben Auflösung und das ist durchaus ein Problem. > Mit einem p-Format Kanten suchen, ist allerdings auch keine > Herausforderung. Genau, deshalb auch die Ergaenzung dass es vom Bildihalt abhaengt. Wenn man z.B. ein fettes Schachbrett hat, dann sollte das auch auf 1080i easy sein die Kanten zu finden. Bei feinen Strukturen wie z.B. Nervenbahnen oder Blutaderchen eher schwierig.
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.