Hallo zusammen, ich bin auf der Suche nach einer schlanken Lösung, um Bilddaten vom 20MP Sony Sensor über 10GEthernet zu übertragen. Das Sensor Interface ist MIPI und soweit klar. Bauchschmerzen macht mir die hohe Datenrate und das 10G Interface. 6Gb/s sind mit USB und Konsorten nicht mehr zu machen, also habe ich mir 10G auserwählt und recherchiere nun. Gibt es vielleicht ein kompaktes FPGA Eval Board mit 10G PHY, so dass ich hier nur noch das MIPI Interface "dranbauen" muss? Was denkt ihr ist bei einer Eigenentwicklung ein realistischer Foodprint des Boards? Stromversorgung, FPGA (sollte ja nicht der kleinste sein), DDR3-4 Speicher, 10G PHY, Steckverbinder usw brauchen schon Platz, so dass ich mal sehr optimistisch von 80x80mm, eher 100x100 ausgehen muss? Mit Xilinx habe ich schon einmal einen 4MP Sensor betrieben, hier aber noch CCD mit externen ADCs und das Interface war Parallel zu einem externen uC, der dann die 1 GigE gemacht hat. Nun möchte ich einen Schritt weiter gehen und das ganze komplett im FPGA abhandeln und eben einen zeitgemäßen Sensor verwenden. Wenn ich nun Bilddaten übertragen möchte, geht das nativ über 10G, oder muss ich mich dann noch mit der korrekten Implementierung von 10 GigE Vision beschäftigen? Vielen Dank! Arthur
Guck mal hier: https://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=13&List=Simple Und hier: https://shop.trenz-electronic.de/de/Produkte/
Moin, Arthur schrieb: > Stromversorgung, FPGA (sollte ja nicht der kleinste sein), OK. > DDR3-4 Speicher, Wozu zwischenspeichern? Willst du auch noch ne Verarbeitung machen, oder nur die Pixel moeglichst hurtig paketieren und durchschaufeln? > 10G PHY, Je nachdem welche Geschmacksrichtung von 10G Ethernet du haben willst, geht's vielleicht auch mit den im FPGA eingebauten Transceivern (und z.B. SFP+). Arthur schrieb: > Wenn ich nun Bilddaten übertragen möchte, geht das nativ über 10G, oder > muss ich mich dann noch mit der korrekten Implementierung von 10 GigE > Vision beschäftigen? Naja, was du halt haben willst: Wenn du GigE Vision haben willst, wirst du's einbauen muessen. Willst du SMPTE 2022-6, musst du das einbauen. Willst du was anderes, dann halt was anderes...Oder eben jemandem Geld zahlen, der weiss, wie das geht und was du brauchst. Gruss WK
Arthur schrieb: > ich bin auf der Suche nach einer schlanken Lösung, um Bilddaten vom 20MP > Sony Sensor über 10GEthernet zu übertragen. > > Das Sensor Interface ist MIPI und soweit klar. > > Bauchschmerzen macht mir die hohe Datenrate und das 10G Interface. > 6Gb/s sind mit USB und Konsorten nicht mehr zu machen, also habe ich mir > 10G auserwählt und recherchiere nun. Wie lang ist die Übertragungsstrecke? Was ist am anderen Ende der Leitung dran? Wie viele CSI-2 Lanes hast Du? Weswegen ich frage: Du solltest bei Deinem Problem eher über ein PCIe-Interface nachdenken. PCIe ist nicht nur auf Mainboards beschränkt, sondern kann auch extern nach außen geführt werden - mit bis zu 16 Lanes, wenn Du das mal brauchen solltest. Eigentlich sollten 4 PCIe-Lanes ausreichen. Vorteil von PCIe: minimale Latenz. Es gibt keine direktere Anbindung an den Prozessor. Deswegen sind alle schnellen SSDs PCIe NVMe SSDs. PCIe in FPGAs ist kein Problem, da gibts fertige Cores dafür, und die Transceiver sind direkt im FPGA drin. Heißt also auch: Der Hardware-Aufwand ist minimal. IPass oder MiniSAS-Stecker dran, ESD-Schutz nicht vergessen, und das wars. Beim RAM sollte das BlockRAM im FPGA reichen. Die Daten gehen dann ja eh direkt per PCIe ins PC-RAM. Für PCs gibts fertige Karten mit PCI-e Bridges drin, die auch Hotplug können. Und wenn Du wissen willst, wie andere Leute das machen: https://www.ximea.com/en/products/application-specific-oem-and-custom/pci-express-high-speed-cameras-xib/cb200cu-cm 20 MPixel, CMOSIS CMV20000 Sensor, PCIe x4 Interface, wahlweise als reine sw-Kamera oder mit Bayer-Filter. fchk
Dergute W. schrieb: > Je nachdem welche Geschmacksrichtung von 10G Ethernet du haben willst, > geht's vielleicht auch mit den im FPGA eingebauten Transceivern (und > z.B. SFP+). Es gibt eigentlich für alle 10G Varianten SFP+ Module, auch für 10GBASE-T. Das von fs.com habe ich schon verwendet. Fertige FPGA-Boards direkt mit 10GBASE-T gibt es wahrscheinlich gar nicht.
PS: Ich hätte gerne einen Link zu Deinem Kameramodul. Interessiert mich. fchk
Arthur schrieb: > Bauchschmerzen macht mir die hohe Datenrate und das 10G Interface. > 6Gb/s sind mit USB und Konsorten nicht mehr zu machen, Nur so aus Interesse: Warum geht USB nicht? USB 3.1 macht 10GBit/s und USB 3.2 20GBit/s. Laut https://www.elektronik-kompendium.de/sites/com/1310061.htm kommen da dann real 800MB/s (=6.4Gb/s) bzw. 1600MB/s (=12.8Gb/s) raus.
Hallo zusammen und danke für das ausführliche Feedback! >Wozu zwischenspeichern? Willst du auch noch ne Verarbeitung machen, oder >nur die Pixel moeglichst hurtig paketieren und durchschaufeln? Für den Beginn ist eigentlich nur durchschaufeln angesagt, aber wenn ich ein Board baue, möchte ich mir später ein paar Freiheiten offen halten. Ich denke auch darüber nach, zwei Sensoren anzusprechen, also zwei MIPI Interface zu haben. Dann bräuchte ich sicher den DDR zum Speichern. >Naja, was du halt haben willst: Wenn du GigE Vision haben willst, wirst >du's einbauen muessen. Willst du SMPTE 2022-6, musst du das einbauen. >Willst du was anderes, dann halt was anderes...Oder eben jemandem Geld >zahlen, der weiss, wie das geht und was du brauchst. Mit GigE habe ich bisher schon etwas gemacht. Da weiß ich, dass es ein Standard ist und man relativ problemlos die Daten übertragen bekommt incl. Paramtrierung der Kamera, ihrer Parameter, Framerate, Auflösung usw. Da habe ich das gen-i-cam XML und los gehts. Da kann ich dann auch easy ein anderes Sensor Modul verwenden. Wenn ich über 10G etwas anderes baue, muss ich mich um alles selber kümmern. Was die 10G Standards angeht, bin ich aber noch nicht sonderlich sattelfest. Es könnte also sein, dass es noch Alternativen gibt, die noch nicht auf dem Schirm habe. >Wie lang ist die Übertragungsstrecke? Was ist am anderen Ende der >Leitung dran? Die Strecke ist ca. 4-5m lang, also von der Kamera zum PC. >Wie viele CSI-2 Lanes hast Du? Im best case würde ich gerne zwei Sensoren ansteuern bzw. mir zumindest diese Möglichkeit seitens der Hardware offen halten. Damit hätte ich 2x4 MIPI Lanes. >Nur so aus Interesse: Warum geht USB nicht? USB 3.1 macht 10GBit/s und >USB 3.2 20GBit/s. Laut Mit USB habe ich in der Vergangen schlechte Erfahrungen gemacht. Das war irgendwie nie stabil. Mit USB3.0 ist es wohl jetzt besser geworden, wenn man die Cypress Chips verwendet. Wie es mit 3.1 oder gar 3.2 aussieht, weiß ich noch nicht. Gefühlt ist 10G ausgereifter und man findet mehr Infos dazu im Netz. Daher aus dem Bauch heraus die Entscheidung zu 10G. Ich kann aber auch gerne noch einmal Richtung USB3.1/2 recherchieren. Vielleicht liege ich da komplett falsch? Ich habe ja bei 20.1 MP so um die 6Mb/s... das muss das Interface hergeben zzgl. Wasserkopf. >PS: Ich hätte gerne einen Link zu Deinem Kameramodul. Interessiert mich. Das habe ich noch nicht in der Hand. Mir wurde bisher nur gesagt, dass dieser Sensor IMX214 unter anderen mit im Rennen ist. Es könnte also auch noch ein anderer werden. Meine Arbeit in meinem Praktikum wird sich nicht mit dem Sensormodul beschäftigen, sondern mit dem Konzept der Hardware zwischen MIPI und PC. Vielen Dank! Arthur
Wenn Du es einfach haben willst und 10G Ethernet verwendetn willst, dann schau Dir die NVidia Jetson Prozessormodule an. Die haben genügend MIPI CSI-2 Lanes für entweder 6 2-Lane-Kameras oder 3 4-Lane Kameras) plus Hardware für Debayering usw plus eine orgendtliche GPU drin. 10 Ethernet ist so erstmal nicht dabei, das müsstest Du per PCIe x4 anklemmen. Zum GigE-Standard: Hast Du den zugriffsbereit? Das ist ein kostenpflichtiger Standard, für den man Mitglied im Genicam-Konsortiom sein muss. Ohne Standarddokumente wirst Du kein standardkonformes GigE hinbekommen. Vergiss es einfach. Ansonsten steht mein Vorschlag, direkt mit PCIe in den PC reinzugehen, immer noch. 5m sind kein Problem, da gibts Lösungen für. Und: Du kannst direkt in den PC-Hauptspeicher reinschreiben, externes Puffer-RAM ist unnötig. fchk
>Ansonsten steht mein Vorschlag, direkt mit PCIe in den PC reinzugehen, >immer noch. 5m sind kein Problem, da gibts Lösungen für. Ich habe versucht zu finden, wie man direkt mit PCIe in den Rechner reinkommt bzw. welche Schnittstelle man dazu braucht. Gefunden habe ich als Ansatz Thunderbolt, oder habe ich etwas übersehen? Die ganzen anderen PCIe Anbindungen im Rechner sind ja nicht nach außen geführt (NVME, PCIe Stecker usw.). Ich möchte ungern eine Bastellösung, sondern eine üblich verfügabare Schnittstelle. So eine LAN Buchse für GigE Vision hat jeder Laptop und es ist bei geringerer Datenrate bei kleineren Sensoren abwärtskompatibel zu 1GigE. Wenn sich der GigE Standard als tauglich erweist, ist das Gen-I-Cam hoffentlich kein Showstopper und ich habe auch gesehen, dass es fertige GigE IPs gibt. Alles eine Kostenfrage... aber das muss dann der Arbeitgeber entscheiden.
Bei diesen ganzen Bitcoin Minern wird das PCIe über normales USB Kabel nach aussen geführt. Da gibt es auch direkt Platinen die rein passiv PCIe auf einen USB Stecker legen. Du brauchst ja auch nur das PCIe, also die paar Signale. Thunderbolt macht da viel mehr, das ist unnötig, USB macht auch mehr und unnötig.
So was meine ich: https://img.dxcdn.com/productimages/sku_452346_1.jpg Die kleine Karte kommt in den PC und extern hast du dann den 16x Slot. Wenn du den nicht brauchst kannst du natürlich auch eine USB Buchse auf deine Platine löten und dort das PCIe abgreifen.
Arthur schrieb: >>Ansonsten steht mein Vorschlag, direkt mit PCIe in den PC reinzugehen, >>immer noch. 5m sind kein Problem, da gibts Lösungen für. > > Ich habe versucht zu finden, wie man direkt mit PCIe in den Rechner > reinkommt bzw. welche Schnittstelle man dazu braucht. > Gefunden habe ich als Ansatz Thunderbolt, oder habe ich etwas übersehen? Ja. Nennt sich PCI Express External Cabling. Das ist so eine Karte, nur mit Redriver drauf: http://www.ioi.com.tw/products/proddetail.aspx?CatID=106&DeviceID=3035&HostID=2046&ProdID=1060128 Es gibt auch weilche mit zwei Ports und PCIe Bridge. So sehen die zugehörige Kupferkabel aus: http://www.ioi.com.tw/products/proddetail.aspx?CatID=102&HostID=2046&Cable_HostID=4030&ProdID=1020099 Über Glasfaser geht das 100m weit. Das sind die Buchsen und Einzelteile: https://www.molex.com/molex/products/family?key=ipass&channel=PRODUCTS&chanName=family&pageTitle=Introduction Dieses System gibts für 4, 8 und 16 Lanes und ist von der PCI-SIG standardisiert. Wie gesagt, es gibt keine schnellere, direktere und latenzärmere Schnittstelle. fchk
-gb- schrieb: > So was meine ich: > https://img.dxcdn.com/productimages/sku_452346_1.jpg > > Die kleine Karte kommt in den PC und extern hast du dann den 16x Slot. > Wenn du den nicht brauchst kannst du natürlich auch eine USB Buchse auf > deine Platine löten und dort das PCIe abgreifen. Falsch. Damit hast Du nur PCIe x1, und es wird USB3 Kabelage missbraucht. Dieses Zeugs wird für Renderfarmen benutzt, ist aber in keiner Weise ein offizieller Standard oder zur Nachahmung empfohlen. Die richtigen, industrietauglichen Lösungen hab ich ein Posting vorher aufgezeigt. fchk
Mag ja sein, aber funktioniert. Mit PCIe 4 sind das auch über 10 GBit/s. Noch besser wäre wenn der die Hardware direkt in einen PC steckt.
> Ja. Nennt sich PCI Express External Cabling.
Vielen Dank für den Input. Diese Kabel habe ich tatsächlich noch nicht
gefunden gehabt.
Somit bekommt man zumindest den PCIe eines Desktop-Rechners nach außen
gelegt. Laptops sehen da schon weider schwerer aus, aber da kann ich ja
nochmal nach einer Lösung suchen und ist auch nur ein Nice-to-have.
Mal schauen, wie man geschickt z.B. die Daten für das I2C/CCI durch PCIe
tunneln kann, das wäre bei GigE Vision ja schon fertig.
Aber großartige Infos!
Danke!
> Wenn sich der GigE Standard als tauglich erweist, ist das Gen-I-Cam > hoffentlich kein Showstopper und ich habe auch gesehen, dass es fertige > GigE IPs gibt. Alles eine Kostenfrage... aber das muss dann der > Arbeitgeber entscheiden. GenIcam ist, wie böse Zungen manchmal sagen, per se ein Showstopper. Auch mit Zugang zu allen Specs. Ich würde dazu raten, sofern es nicht die zigste IBV-Kamera werden soll, die Bilder per RTP-Standard zu übertragen und allenfalls zu komprimieren. Kommt oft vor, daß an einem 1G-Laptop-Ethernet alles nicht so tut wie gedacht und die Bandbreite mies ausfällt. Allerdings ist auch da ein vernünftiger 1G-IPcore inkl. Rtpstack nötig, da gibt es aber genügend kommerzielle Lösungen.
>Ich würde dazu raten, sofern es nicht die zigste IBV-Kamera werden soll, >die Bilder per RTP-Standard zu übertragen und allenfalls zu >komprimieren. Das Problem an einem, wie auch immer gearteten RTP protokoll ist, dass man alles selber bauen muss incl. dem I2C Transfer zur Kamera hin. Da wollte ich naiver Weise auf bereits existierende Lösungen zurückgreifen, wo man z.B. mit dem GigE Control Protokoll in der Kamera selber definierte Register beschreiben kann. Die Register mappe ich dann einfach auf I2C und kann damit den Sensor beschreiben. So habe ich es schon mal gemacht... andere/eigene Protokolle kenne ich noch nicht. Hast Du da zufällig einen guten Einstiegspunkt zur Recherche, wie ein solches RTP Protokoll via 10GE aussehen kann? Vielen Dank!
>Zum GigE-Standard: Hast Du den zugriffsbereit? Das ist ein >kostenpflichtiger Standard, für den man Mitglied im Genicam-Konsortiom >sein muss. Ohne Standarddokumente wirst Du kein standardkonformes GigE >hinbekommen. Vergiss es einfach. >Auch mit Zugang zu allen Specs. Die Specs sind übrigens kostenlos verfügbar nach Anfrage. Man muss nur Gebühren zahlen, wenn man Mitglied der AIA sein möchte, ein Produkt vermarkten möchte, was GigE zertifiziert ist und sein Produkt bei denen gelistet haben möchte. Zur Entwicklung "for internal use only" bekommt man die Specs auch so, wenn man also nur vom Standard an sich und dessen Funktionalität profitieren möchte und z.B. Standardsoftware verwenden will bzw. mittels Matlab/LabVIEW, die ja GigE unterstützten, an die Daten kommen möchte.
LabVIEW http://www.ni.com/tutorial/5750/en/ Matlab https://www.mathworks.com/help/imaq/acquire-images-from-gige-vision-cameras.html Von dieser Seite betrachtet hat der Standard also hinten raus vielleicht doch einige Vorteile?
Arthur schrieb: > Das Problem an einem, wie auch immer gearteten RTP protokoll ist, dass > man alles selber bauen muss incl. dem I2C Transfer zur Kamera hin. Da > wollte ich naiver Weise auf bereits existierende Lösungen zurückgreifen, > wo man z.B. mit dem GigE Control Protokoll in der Kamera selber > definierte Register beschreiben kann. Die Register mappe ich dann > einfach auf I2C und kann damit den Sensor beschreiben. > So habe ich es schon mal gemacht... andere/eigene Protokolle kenne ich > noch nicht. > Der gemeinsame Nenner von GigE (sprich dem Pleora-Standard) und dem Realtime Protocol (RTP) ist sowieso schon mal UDP, daran kommst du nicht vorbei. D.h. so oder so brauchst du da einen aufwendigeren Core, entweder eine harte State-Machine wie es Pleora macht, oder eine gut programmierbare Software-Lösung mit schlauer DMA-Engine, um die Bandbreite zu schaffen. Du hast schon mal zwei Datenkanäle: Eine für Konfiguration (GenICam oder was anderes) und den Video-Stream. Den Wrapper von GenICam nach i2c musst du dir bauen, oder von wem holen. Zum genannten IMX214 habe ich da bereits was fertig, das ist auch im Rahmen einer Dienstleistung im Source kriegen. > Hast Du da zufällig einen guten Einstiegspunkt zur Recherche, wie ein > solches RTP Protokoll via 10GE aussehen kann? Da gibt es unzählige RFCs zu, z.B. https://tools.ietf.org/html/rfc4175, Das dann nach 10G hochzuskalieren ist eine Frage des effizienten Datenschaufelns. GigE ist einfach das Gleiche in 'grün' und wurde auf Biegen und Brechen von der AIA zum Standard definiert, warum man da das Rad nochmal erfunden hat, hat politische Gründe :-) Die Frage ist halt, an welcher Ecke du drehen musst/willst. Die RFC-konformen Formate werden zum grossen Teil von der hocheffizienten gstreamer-Bibliothek verstanden, für GigE brauchst du die entsprechenden Libraries oder Viewer von deinem Kamerahersteller. Für mich als RFC-gewohnten Veteranen ist GigE/GenIcam ein bedingt guter Standard, wenn deine Front-End-Software es aber nun mal so unterstützt, ist das bei der Auswahl zweitrangig, solange es funktioniert. Wenn du allerdings mit LabVIEW bei 10G auffährst: Stirnrunzeln. Mit LV würdest du die Bandbreite nie ausnutzen. Da kann man gleich Kompression bei 1G fahren.
Ich hatte mal High-Speed Kameras mit USB-3. Die machten aber mehr Probleme, weil die Verbindung doch sehr empfindlich ist. Insbesondere über längere Zeit die hohen Datenraten zu halten, klappt nicht immer. Irgendwas hat sich dann doch weg gehängt. Ein Sony-Chip mit FPGA und SFP+ liegt gerade auf meinem Tisch. Da gibt es Kamerahersteller in Ostdeutschland, die bauen das für einen. Selber möchte ich das nicht machen.
Apropos PCIe: Finde ich eigentlich auch einen sehr eleganten 'hack'. Ein
Kollege hat mal high speed Video über SATA-Stecker getunnelt.
Aber das Problem dabei ist immer, dass man sich das Front-End eben mit
bauen muss, und keine goldene Referenz hat. Das könnte dann doch mehr
Arbeit kosten als eine standardisierte Ethernet-Lösung - und man hat am
Schluss eben doch eine Insellösung, die man zu einem Tool kompatibel
machen muss ("wrappen").
Mein Arbytegeber verwendet Ximea-Kameras in seinen Produkten. Die gibt es entweder mit USB3 oder mit PCIe. Nach unserer Erfahrung funktionieren die PCIe-Kameras deutlich besser, weil die CPU-Last und die Latenz einfach deutlich geringer sind und PCIe Gen2 x2 ist einfach schneller als USB 3.0. Die großen Kameras mit 20 oder 50 MPixel werden nur noch mit PCIe Gen2 x4 angeboten. Wenn Du davon 6 Stück an einem PC hast, weißt Du erst, was Bandbreite heißt und warum NUMA bei einem Multiprozessorsystem wichtig ist. Jede andere Schnittstelle würde bei solch einer Konfiguration in die Knie gehen, sei es wegen Bandbreite oder wegen CPU-Last. Daher auch meine Empfehlung. Die kommt nämlich aus der Praxis. Die Sensoren dieser Kameras haben übrigens normales Kleinbild-Format, im Gegensatz zu den Winz-Sensoren bei IMX214 und Konsorten. fchk PS: Vergiss Debayering und Weißabgleich nicht. Das willst Du bei diesen Bandbreiten nicht auf der CPU rechnen. Wirklich nicht. Also pack passende Hardware ins FPGA oder eine ordentliche GPU ins System.
:
Bearbeitet durch User
Hi, Du brauchst: GigE-Vision Standard <- RJ45/SFP+ <- 10G Phy <- Xilinx Zynq FPGA Richtig? GigE-Vision im FPGA ist nicht besonders kompliziert, da eh UDP-Stack. Ich durfte keine (kauf) IP-Cores verwenden, deshalb habe ich alles in VHDL implementiert. Für vom FPGA (Zynq) zum SFP+/Phy ist ein kostenloses IP-Core notwendig. Dabei ist nur zu beachten, dass Zynq 7er Serie den richtigen Speedgrade hat, sonst ist maximal 6 Gbs möglich. Sobald du die serielle Verbindung am Laufen hast, musst Du "nur" Eth-Frames zusammensetzen. Es ist nicht trivial, aber auch nicht besonders kompliziert (aber aufwendig). Aus Ethernet-Frames baust Du UDP-Pakete. Und da ist auch GigE-Vision nicht mehr weit ;-) Wenn Du 20kEuro übrig hast, dann kannst Du "Xilinx 10G/25G Ethernet Subsystem" (?) kaufen, daran schließt Du über AXI den DMA-controller an. Dann ist der Zusammenbau der GigE-Vision Pakete nur "Software". Grüße Kest
Allenfalls sollte man einen Teil der Verarbeitung, inkl Komprimierung am Frontend machen. Weil die ganzen Daten am PC nichts bringen. Ganz einfach nichts. Beim ersten mal Seek & Retry geraet's ins Stocken. Wer kann denn schon 20 Megapixel unkomprimiert in Echtzeit schauen. Womit denn ? Mein Screen hat fast 12M Pixel. Ich schau mir da Drohnenvideos an. Die kommen aber nur mit 20 Frames, oder so. Weil die Speicherkarte auch nicht schneller ist. Man kann's aber nur anschauen wenn sich hinreichend wenig aendert. Und die komprimieren schon, die SD Karte ist mit 100MByte/s spezifiziert. Das waere dann 1GBit. Also vergiss die 20Megapixel unkomprimiert in Echtzeit. Das ist dummes Zeug. Nimm eine realistische Datenrate, die du auch wegspeichern kannst. zB was eine Disk bringt. Da ist dann bei 200MByte/s langsam Schluss.
Zitronen F. schrieb: > Allenfalls sollte man einen Teil der Verarbeitung, inkl Komprimierung am > Frontend machen. Weil die ganzen Daten am PC nichts bringen. Ganz > einfach nichts. Beim ersten mal Seek & Retry geraet's ins Stocken. Es gibt mittlerweile auch SSDs. Die können Daten viel schneller speichern. So 2GB/s machen auch die besseren Consumer-SSDs. > Wer kann denn schon 20 Megapixel unkomprimiert in Echtzeit schauen. Er hat nichts von der Anwendung geschrieben. Bei GigEVision fällt mir u.a. auch industrielle Bildverarbeitung ein. > Womit denn ? z.B. mit einem DELL UP3218K, der hat 33MP. > Mein Screen hat fast 12M Pixel. Ich schau mir da > Drohnenvideos an. Die kommen aber nur mit 20 Frames, oder so. Weil die > Speicherkarte auch nicht schneller ist. Man kann's aber nur anschauen > wenn sich hinreichend wenig aendert. > Und die komprimieren schon, die SD Karte ist mit 100MByte/s > spezifiziert. Das waere dann 1GBit. Diese SD-Karte ist das beste, was die Technik heutzutage schafft? Bei den professionellen Videokameras (z.B. Aria DSMC2) geht das auch bis 300MB/s. Aber wahrscheinlich nicht auf eine SD-Karte.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.