Ich suche zur Erfassung mehrere gleichzeitiger Ereignisse eine
Entwicklungsplattform für Bildverarbeitung auf FPGA-Basis. Könnt ihr mir
etwas empfehlen? Im Grunde brauche ich zunächst nur bilder in 1280*960
oder ähnlich bei einer Bildrate von 60 pro Sekunde. Wichtig ist Echtzeit
um später Ereignisse mit mehreren Kameras aufzunehmen, vielleicht auch
bei höherer Bildrate. Habe bereits von Elphel (www.elphel.com) eine
interessante Lösung gefunden, gibt es ähnliche Alternativen? Was wäre
eine optimale Softwarelösung um mehrere Bildquellen zeitgleich
auszuwerten (Matlab? OpenCV?) und als JPEG zu speichern?
Bei 1280x960 kommen viele Plattformen in Frage, ich wuerde etwas mit
Xilinx Zynq Ultrascale+ nehmen, damit hat man eine Fuelle an
Moeglichkeiten.
Was fuer Kameras wilst du denn anschliessen? Was sind deine
Schnittstellen? Hier kann man die Auswahl dann wieder etwas eingrenzen.
ich verstehe gerade nicht, wonach du suchst.
Du möchtest Kameras "anschließen" und die Bilder zeitstempeln. Ok. Aber
dann fragst du nach einer Auswertungsmethodik? Wenn ich mich nicht irre,
tun sich sowohl Matlab als auch OpenCV mit FPGAs schwer. Also sollen die
FPGAs die Daten nur wegspeichern und die Auswertung geschieht am
Rechner? Warum nicht gleich ein Echtzeitbetriebssystem auf den Rechner
spielen und alles dort laufen lassen?
Oder, falls das unbedingt im FPGA sein muss: was heißt denn
"Auswertung"? Wie komplex wird's da? Läuft ein neuronales Netz mit
Millionen von Parametern? Oder wird nur die druchschnittliche Helligkeit
der Bilder verglichen?
Andreas schrieb:> 1280*960
Das ist Tech von vorgestern. Mein Kunde hat schon vor 4 Jahren komplett
auf HDMI2.0 umgestellt und arbeitet jetzt auf 3840x2160.
Momentan gibt es preiswerte HDMI-fähige Überwachungskameras von den
Chinesen, die direkt über IP senden. Kriegt man über Kabel bis zu 8
Stück dran. Auf Wunsch GigEVision. geht mir frame grabbern direkt in den
PC. Manuelle Verarbeitung mit Video-Chips, DSPs inklusive Bildfusion,
wenn unbedingt nötig. Brauchen aber nur wenige Kunden.
FPGAs braucht man da gar keine mehr für, es sei denn, dort muss eine
Sonderverarbeitung rein. Militär z.B.
Danke für Eure Tipps!
@Tobias:
Das sollten fertige Kameramodule sein, mit paralleller Ausgabe.
Ich habe noch von Micron ein Developer Kit. Schnittstellen zum PC sind
USB oder Ethernet. Mit günstigen USB kameras habe ich bereits
experimentiert, da dauert es aber teils bis zu 100ms bis das Bild
eintrifft. Per Ethernet habe ich vermutlich bessere Karten.
@rava: Die Auswertung soll selbstverständlich auf dem PC laufen.
Entschuldige die unpräzise Angabe. Das FPGA soll zunächst die Daten nur
schnell an den PC liefern, am liebsten schon JPEG-komprimiert. Alles
andere kommt später. Ich muß nur wissen wann die Bilder gemacht wurden
(auf ms genau). Also brauche ich nur den Zeitstempel vom FPGA und irgend
eine Möglichkeit in der Software darauf zuzugreifen.
Mir ist auch klar, dass es dafür Fertiglösungen von Machine Vision
Anbietern gibt, die alleridngs sehr kostspielig werden sobald man sie
programmieren will.
@Videomann: Ich brauche nicht mehr als die Auflösung, auch wenn es
Schnee von gestern ist. HDMI ist keine Option...
Schliesslich soll ein einfacher Algorithmus auf dem FPGA laufen, deshalb
ist das zunächst so angedacht.
Die Kameras haben heute selber alle FPGAs drinnen, die so ziemlich alles
können, was man da machen kann und muss. Alles fertig parametrierbar.
Schau dich mal bei den Industriekameras um. Es gibt allein in DE >10
Hersteller, die sowas haben.
von Lattice gibts eine VIP Demo Board. (Video Interface Platform) Sind
auch komplette gleich zwei Sony Sensoren drauf die gleich ein Bild
abgeben. Die Deep Learn Bibliotheken dazu heissen Caffe und TensorFlow.
Auswertung auf dem PC ist wegen der Leistungsaufnahme, dem schlechten
Echtzeitverhalten, der miserablen Zuverlässigkeit, den langen Bootzeiten
usw. zumindest beim autonomen Fahren und anderen wichtigen Anwendungen
verpönt
Moin,
das VIP hätte ich jetzt auch empfohlen, allerdings dann mit dem
separaten Zusatzbrett mit GigE und USB3-Option. Da gibts auch fertige
Referenzdesigns zum Streaming per YUV-raw oder MJPEG per RTP, guck mal
nach RFC2435. Auf PC-seite bist du mit gstreamer sehr flexibel was
Verarbeitung/Speicherung angeht. Wieviel Resourcen braucht deine
Verarbeitung? Allenfalls wird's irgendwann mit BRAM eng, debayer und
jpeg sind kleine Speicherfresser.
Ok, bin jetzt einen Schritt weiter. Das Lattice-Kit paßt wohl ganz gut
für einen ersten Ansatz. Habe auch schon einen freien JPEG-Encoder bei
opencores.org gefunden. Die Blockartefakte bei hoher Kompressionsrate
bereiten allerdings noch etwas Kopfschmerzen. Kennt jemant eine gute
Alternative? Gibt es verbesserte Algorithmen oder sollte man besser auf
JPEG2000 gehen?
Ich brauche keine neuronalen Netze oder solches. Der Algorithmus ist wie
gesagt recht einfach und sollte wenig Blockram benötigen.
Nimm sonst h264, JPEG und JPEG2000 sind nicht low latency. Die Bloecke
sind bei h264 kleiner und stoeren weniger. Opencores kannst vergessen.
Guck mal bei https://github.com/bcattle/hardh264.
Weiss nicht, was jetzt bei euch als "low latency" gelten soll, aber die
minimalen 8 Bildzeilen (und ein paar zerquetschte) bei JPEG sind mehr
als ausreichend, gemessen daran, dass auch bei einem
Rolling-Shutter-Sensor intern schon einiges an Verzögerung anfallen
kann. Das ist allerdings bei den meisten Sensoren, die Rohdaten
ausgeben, deterministisch (also Zeitpunkt der Aufnahme bestimmbar). Wozu
brauchst du dann noch low latency?
Bei JPEG2k kriegt man's mit Tiling auch in die Richtung, zumindest wenn
man einiges vom Standard abspeckt, hat dann aber auch wieder irgendwann
Block-Artefakte.
Bei JPEG kann man mit cleverem Residual-Coding die Block-Artefakte
wegbekommen. Ist aber nicht mehr Standard und nicht mal eben so
implementiert. Bin gespannt, wie sie's beim (zukünftigen) JPEG XS
hinkriegen.
Bei h264 ist "low latency" recht "bedingt" und der Encoder deutlich
komplexer.
Viel Spass kannst du bei den opencores-Sachen aber schon mal mit
effizientem Streaming haben. Es macht einen grossen Unterschied, ob ein
Codec nur ein "Beschleuniger" ist oder richtig synchron arbeitet.
Ansonsten gilt, wie fast immer: Zeit ist Geld (wenn nicht Lernprojekt),
darum würde ich mich auf den Kernalgo fokussieren und die Kompression
wenn nötig ganz am Schluss dazukaufen.
Andreas schrieb:> Per Ethernet habe ich vermutlich bessere Karten.>> @rava: Die Auswertung soll selbstverständlich auf dem PC laufen.
Da du das eine erkannt hast und das andere sowieso willst, dann verstehe
ich nicht, wozu jetzt noch ein FPGA gut sein soll.
Es gibt doch fix und fertige Überwachungskameras, die einen RTSP-Stream
liefern. Und selbst in recht hoher Qualität sind die nichtmal mehr allzu
teuer (~400€ für full HD). Und sie enthalten bei diesem Preis sogar
schon eine fertige Entzerrung für die Optik, Bewegungserkennung und
weiteren Schnickschnack, den man benutzen kann, aber nicht benutzen
muss...
Andreas schrieb:> @rava: Die Auswertung soll selbstverständlich auf dem PC laufen.> Entschuldige die unpräzise Angabe. Das FPGA soll zunächst die Daten nur> schnell an den PC liefern, am liebsten schon JPEG-komprimiert. Alles> andere kommt später. Ich muß nur wissen wann die Bilder gemacht wurden> (auf ms genau). Also brauche ich nur den Zeitstempel vom FPGA und irgend> eine Möglichkeit in der Software darauf zuzugreifen.
Vergiss das FPGA.
https://www.ximea.com/en/products/xilab-application-specific-custom-oem/embedded-vision-and-multi-camera-setup-xix/sony-imx174-fast-color-industrial-camera
Da bekommst Du per PCIe die rohen Kameradaten direkt mit 10 MBit/s in
Deinen Hauptspeicher geschrieben. Ohne weitere Latenzen. Direkter gehts
nicht. Triggern kannst Du per Software oder per Hardware
(Trigger-Signal-Inputs und Outputs vorhanden). Dann weißt Du wirklich,
wann das Bild entstanden ist. Global Shutter ist dann auch nützlich.
fchk
c-hater schrieb:> Da du das eine erkannt hast und das andere sowieso willst, dann verstehe> ich nicht, wozu jetzt noch ein FPGA gut sein soll.
Es gibt schon eine Reihe von Sachen, die man mit einem Bild on the fly
machen kann (und auch muss), bevor es in die Bildauswertung auf einen
Rechner geht. Das haben schon einige lernen müssen. Idealerweise packt
man die Daten, die der FPGA aus dem Bild ermittelt in den Datenstrom zum
PC mit hinein. Wenn allerdings die Karte nur den Videokanal hat, dann
wird das wiederum etwas tricky, geht aber.
So - hat etwas gedauert, bin jetzt ein Stück weitergekommen mit dem Kit
von Lattice.
Der Sensor ist allerdings nicht in unserem Sinn, aber das spielt für den
Algorithmus keine Rolle. Sorry daß ich darauf nicht näher eingehen kann.
Mir auch klar, daß die guten Tips nicht für lau sind, aber ich wollte
trotzdem noch ein Thema anschneiden: Bildkompression. JPEG haben wir
evaluiert, Problem ist die Bildqualität, sonst ist die Verzögerung
optimal. Welche Verfahren sind sonst noch im FPGA umsetzbar, kann man
verlustfreie Verfahren sinnvoll mit niedriger Latenz im Prinzip
schaffen, oder sollte man einen fertigen Standardcodec einkaufen?
Bisher haben wir Tests mit PNG und WebP gemacht, die ausreichend
komprimieren. Kann also in der Richtung sein.
Andreas schrieb:> Problem ist die Bildqualität
Klar ist JPEG verlustbehaftet. Aber die Frage ist ja: muss es unbedingt
verlustfrei sein? Steckt in jedem Pixel eine Information, die genau so
vom Bilsaufnehmer bis zur Anzeige/Verarbeitungssystem übertragen werden
muss? Oder reicht es nicht aus, wenn das JPEG Bild "ausreichend gut"
ist, weil die Information in der Gesamtheit des Bildes steckt (wie das
z.B. bei Fotos oder Filmen so üblich ist)?
Komprimierung und algorithmische Auswertung von Kamerabildern vertragen
sich nicht gut. Das gilt umso mehr, je schlechter die Bildqualität wird.
Mein Arbytegeber setzt daher PCIe-Kameras ein, die ihre Daten im
Rohformat in Echtzeit direkt in den Hauptspeicher des PCs schreiben.
PCIe Gen2 mit 2 oder 4 Lanes und 5 Gbit/s pro Lane lassen genug Luft für
reichlich Megapixel bei bis zu 200 Frames pro Sekunde.
Dieses Vorgehen hat sich hier sehr bewährt.
fchk
Lothar M. schrieb:> Andreas schrieb:>> Problem ist die Bildqualität> Klar ist JPEG verlustbehaftet. Aber die Frage ist ja: muss es unbedingt> verlustfrei sein? Steckt in jedem Pixel eine Information, die genau so> vom Bilsaufnehmer bis zur Anzeige/Verarbeitungssystem übertragen werden> muss?
Genau, wie Ex-Cheffe (Bildverarbeitungsbude) zu sagen pflegte, JPEG ist
verlustfrei, weil es das Rauschen entfernt und mehr als 10bit pro
Farbkanal sind unnötig weil der Mensch eh nur ca. 1000 Farbtöne
unterscheiden kann und die beiden unteren bits ohnehin im
Sensor/ADC-Rauschen untergehen.
Cheffe hatte da einen eigenen Komprimieralgo, der ca 1000 Logicelemente
benötigte. Ansonsten mal in den Klassiker ISBN: 978-3642130960 schauen,
worauf es wirklich ankommt.
Camera posterior bulbi schrieb:> mehr als 10bit pro Farbkanal sind unnötig weil der Mensch eh nur ca.> 1000 Farbtöne unterscheiden kann
Mit 10 Bit pro Farbe kann ich aber über 1000³ unterschiedliche Farben
darstellen. Da meinte er vermutlich 10 Bit für die gesamte
Farbinformation.
Lothar M. schrieb:> Camera posterior bulbi schrieb:>> mehr als 10bit pro Farbkanal sind unnötig weil der Mensch eh nur ca.>> 1000 Farbtöne unterscheiden kann> Mit 10 Bit pro Farbe kann ich aber über 1000³ unterschiedliche Farben> darstellen. Da meinte er vermutlich 10 Bit für die gesamte> Farbinformation.
Njein, er bezog sich auf die Grauwert-Digitalisierung eines Sensors mit
Bayer-Matrix. Genaugenommen sprach er also nicht von Farbtönen sondern
Helligkeitsabstufubgen einbes Graukeils die das Säugetierauge noch
auflösen kann.
https://www.hardwareluxx.de/images/stories/newsbilder/tfreres/2015/10-bit-ausschnitt-71cbac2d6216df6e.jpg
Um die Frage zu beantworten, wieviel Farben tatsächlich nötig sind,
müsste man vielleicht zu einem Palettenbasierenden System zugreifen,
weil bspw tiefere Grünauflösung wohl wichtiger für die
Bild(Helligkeits-) Information ist (deshalb hat eine Bayer-matrix auch
doppelt soviel grün-Filter). ein Bild mit einer gut gewählten Palette
von 1024 wirkt deutlich natürlicher als eins mit 3:4:3 bit R:G:B
https://en.wikipedia.org/wiki/Indexed_color
fchk schrieb:> PCIe Gen2 mit 2 oder 4 Lanes und 5 Gbit/s pro Lane lassen genug Luft für> reichlich Megapixel bei bis zu 200 Frames pro Sekunde.
Welche Kameras und wieviele lanes?
Lothar M. schrieb:> Da meinte er vermutlich 10 Bit für die gesamte> Farbinformation.
Die meisten industriellen Kameras haben einen 10Bit Ausgang pro Farbe.
Ich hatte auch schon welche mit 12 Bit x 3 und 10 Bit x 4 (RGBX).
Sensoren liefern durchaus noch mehr. Luminance mit 16 Bit in variabler
lokaler Dynamik. Vor Zeiten war ich mal in Sensorproduktion involviert,
welche >120dB absolute Dynamik hatten.
Im Consumerbereich wird nur abgeschnitten, entrauscht und reduziert. Je
nachdem, was an Beleuchtung da ist.
Das liegt am HDMI-Standard der ersten Generation, bei dem man nicht
ausreichend Bandbreite hatte. Auch mit HDMI 2.0 gehen 10 Bit nicht in
4:4:4 mit 60Hz.
Camera posterior bulbi schrieb:> weil der Mensch eh nur ca. 1000 Farbtöne> unterscheiden kann und die beiden unteren bits ohnehin im> Sensor/ADC-Rauschen untergehen.
Für Bildverarbeitung ist es unerheblich, was der Mensch sieht.
Man kann auch im Rauschen Information über Bildhinhalte ermitteln und zu
Messungen und Berechnungen heranziehen.
Geht dann frequenztechnisch von langen Bildfiltern bis hin die
Auflösungsgrenze des Optik, wenn nur noch 2 pxl angesteuert werden.
Muss nur die richtige Sorte Filter drauf. Das konnte ich unlängst
eindrucksvoll darlegen!
Mehr als 8 bit sind momentan nicht das Thema, aber kann noch werden.
Der Algorithmus arbeitet nicht auf dem komprimierten Datenstrom, aber
fürs speichern der Sequenzen (Archivierung von Ereignissen) wäre
Kompression vorgesehen. Es ist schlußendlich kein PC mehr im Spiel,
außer für Loggen und nachträgliche Auswertung, der Zeitstempel ist nur
noch für Synchronisation.
JPEG ist eigentlich ok, aber die Artefakte stören eben.
Rolling Shutter ist jetzt auch nicht das große Problem, den Sensor
wechseln wir dann einfach aus wenn mehr Qualität gefordert wird. Ich
stelle mir da einfach nur eine Realisierung von PNG o.ä. im FPGA vor
aber muß auch auf Ressourcen achten
Andreas schrieb:> im FPGA vor> aber muß auch auf Ressourcen achten
Die Zynq Ultras haben einen internen MPEG Kopressor in Hardware drin.
Muss nur angeschlossen werden.
Hein schrieb:> Die Zynq Ultras haben einen internen MPEG Kopressor in Hardware drin.> Muss nur angeschlossen werden.
Sinnfreier Hinweis da:
Andreas schrieb:> So - hat etwas gedauert, bin jetzt ein Stück weitergekommen mit dem Kit> von Lattice.
Hein schrieb:> Andreas schrieb:>> im FPGA vor>> aber muß auch auf Ressourcen achten>> Die Zynq Ultras haben einen internen MPEG Kopressor in Hardware drin.> Muss nur angeschlossen werden.
Sogar mit H.264 und 265. Man muss nur beachten, dass der einen Grossteil
in Logik macht und externen DDR Speicher braucht.
Wenn das aber kein Problem darstellt, ist das eine Klasse Sache.
Andreas schrieb:> Welche Verfahren sind sonst noch im FPGA umsetzbar, kann man> verlustfreie Verfahren sinnvoll mit niedriger Latenz im Prinzip> schaffen, oder sollte man einen fertigen Standardcodec einkaufen?> Bisher haben wir Tests mit PNG und WebP gemacht, die ausreichend> komprimieren. Kann also in der Richtung sein.
WebP ist m.E zu komplex für's FPGA, aber den PNG-Prädiktor kriegst du
gut umgesetzt und kommst mit dem klassischen Bitplane-Coding und
nachgeschaltetem Huffman-Coder auf ähnliche Kompressionsraten im
verlustfreien Bereich, die Latenz ist da im Bereich von Bildzeilen.
Hängt halt immens von der Bildquelle ab, ob monochrom oder Farbe, durch
Optik bedingte Korrelationen, Bayer-Pattern usw.
Wenn's nahezu verlustfrei (kaum sichtbare Artefakte) sein darf, kriegst
du mit blockweiser Wavelet-Dekomposition à la JPEG2k und Quantisierung
ganz gute Ergebnisse. Fürs FPGA sind mir allerdings keine
OpenSource-Codecs bekannt, und eine Eigenentwicklung ein recht
aufwendiges Unterfangen.
Bei 'nearly lossless' scheiden sich generell die Geister, da gibt es
eine Menge unterschiedlicher Metriken (PSNR, SSIM, ...). Siehe auch
encode.ru.
Tobias B. schrieb:> Sogar mit H.264 und 265. Man muss nur beachten, dass der einen Grossteil> in Logik macht und externen DDR Speicher braucht.
Die Latenz scheint da nur recht hoch zu sein, wie hoch konnte mir der MA
auf der Messe allerdings nicht sagen.
Strubi schrieb:> Tobias B. schrieb:>> Sogar mit H.264 und 265. Man muss nur beachten, dass der einen Grossteil>> in Logik macht und externen DDR Speicher braucht.>> Die Latenz scheint da nur recht hoch zu sein, wie hoch konnte mir der MA> auf der Messe allerdings nicht sagen.
Jep, das ist aber auch logisch und Codec bedingt, da holt man nicht mehr
viel raus. Bei den Kodierungsverfahren gehen die Algorithmen auch
zeitlich ueber die Frames. In PG252 sind die verschiedenen Latenzen
angegeben und reichen von 1 (beim Encoding) bis 5 (beim Decoding)
Frames.
Ist halt die Frage ob man wirklich H264 und H265 mit Echtzeit
kombinieren muss (Kompressionsverfahren und Echtzeit beissen sich immer
gegenseitig). Spontan faellt mir da nicht wirklich was ein, zumindest
nicht bei Kamerasystemen in Broadcast, Automotive und Medizin. Beim
Abspielen und Aufzeichnen von Content spielt Latenz keine Rolle und
selbst wenn, dann sind die ~80 ms auch kein Beinbruch (selbst fuer viele
Echtzeitanwendungen ist das noch in Ordnung).
Tobias B. schrieb:> Beim Abspielen und Aufzeichnen von Content spielt Latenz keine Rolle
Jepp, früher(tm) beim DVD-Rippen hat es auch keinen gestört, wenn der
Rechner über Nacht durchlief, um das Video auf CD-Größe zu bringen ;-)
Bernd schrieb:> Tobias B. schrieb:>> Beim Abspielen und Aufzeichnen von Content spielt Latenz keine Rolle> Jepp, früher(tm) beim DVD-Rippen hat es auch keinen gestört, wenn der> Rechner über Nacht durchlief, um das Video auf CD-Größe zu bringen ;-)
Stimmt, tolles Extrembeispiel! :-D
Tobias B. schrieb:Bernd schrieb:>> Beim Abspielen und Aufzeichnen von Content spielt Latenz keine Rolle> Jepp, früher(tm) beim DVD-Rippen hat es auch keinen gestört, wenn der
Hier verwechselt jemand Latzenz mit Bandbreite. Klar ist die Latenz
egal, aber die Bilder müssen in Echtzeit verpackt werden können und das
erfordert power. Also nix mit "warten über Nacht".
Hotte schrieb:> Tobias B. schrieb:> Bernd schrieb:>>> Beim Abspielen und Aufzeichnen von Content spielt Latenz keine Rolle>> Jepp, früher(tm) beim DVD-Rippen hat es auch keinen gestört, wenn der>> Hier verwechselt jemand Latzenz mit Bandbreite. Klar ist die Latenz> egal, aber die Bilder müssen in Echtzeit verpackt werden können und das> erfordert power. Also nix mit "warten über Nacht".
Ne, das passt doch. Der Xilinx Core schafft von der Bandbreite De- und
Encoding in 4K@30Hz (oder sogar 60Hz, muesste ich nachschauen), hat halt
Algorithmen bedingt ein paar Frames Latenz.
Dann wurde diskutiert, dass es praktisch keine Anwendung bei dem diese
Latenz eine Rolle spielt. Als Extrembeispiel wurde das DVD Rippen ins
Feld gefuehrt. Von daher ist die Argumentationskette in Ordnung, ich
denke hier ist jedem der Unterschied zwischen Bandbreite und Latenz
bewusst. ;-)
Tobias B. schrieb:> Jep, das ist aber auch logisch und Codec bedingt, da holt man nicht mehr> viel raus.
Könnte man aber eigentlich. Mit streifenweiser Codierung schafft man bei
h264 auch sub-frame Latenzen, da kann der Monitor bzw. Framebuffer noch
eher der Bösewicht sein (Ende zu Ende überprüft mit Lichtblitz und
Fototransistor).
Strubi schrieb:> Könnte man aber eigentlich. Mit streifenweiser Codierung schafft man bei> h264 auch sub-frame Latenzen, da kann der Monitor bzw. Framebuffer noch> eher der Bösewicht sein (Ende zu Ende überprüft mit Lichtblitz und> Fototransistor).
Kannst ja mal in PG252 reinschauen. Da gibts ein ganzes Kapitel zu dem
Thema und evtl. ist diese Option sogar vorhanden?
