Guten Tag, ich suche einen Algorithmus, um animierte Bildsequenzen komprimiert über ein (langsames) Netzwerk zu transportieren und beim Empfänger (Embedded device mit geringer Rechenleistung) mit wenig Rechenaufwand zu rekonstruieren. Ich suche eher Links zu etablierten Algorithmen als gutgemeinte Fantasien, wie der ideale Algorithmus aussehen könnte, wenn ich der Enkel von Einstein und Hawking wäre, 100 Jahre Zeit hätte, eine Idee zur Marktreife zu bringen, einen Quantencomputer besäße, und und und... Wichtige Anforderungen sind: + Billige Dekomprimierung beim Empfänger!!! (daher scheidet z.B. MPEG aus) + Komprimierung in Echtzeit möglich auf typischen 3GHz DualCore PC, wenigstens 640x480 pixel @10 fps + Farbtreue ist weniger wichtig als Erhaltung der Geometrie und scharfer Kanten (z.B. wäre das Verschwimmen von Kanten wie in JPGs unerwünscht, ist aber vermutlich nicht ganz vermeidbar) + verlustfreie Abbildung nach ein paar Frames, wenn die Bildsequenz statisch wird Da die Auswahl eines guten Algorithmus immer vom Anwendungsfall abhängt, hier ein typisches Beispiel: http://www.youtube.com/watch?v=8DcLrxoaRFk Ich frage mich, ob es möglich ist, die Tatsache auszunutzen, dass aufeinanderfolgende Einzelbilder stark korrellieren und sich im wesentlichen durch eine geometrische Transformation und geringe Änderungen der Licht- und Farbverteilung unterscheiden. Noch ein Hinweis, für die Komprimierung steht nur das 2D Bild zur Verfügung, nicht die 3D Daten. Daher ist die geometrische Transformation, die z.B. eine 3D Rotation beschreibt, lokal variabel und müsste erst aus dem 2D Bild approximiert werden. Mein erster Ansatz ist ZRLE (zlib run length encoding), wie es von VNC im RFB Protokoll verwendet wird. Gibt es für die Animation bewegter 3D Objekte bessere Ansätze? Gruß Max
:
Verschoben durch User
Max schrieb: > um animierte Bildsequenzen komprimiert Was den nun Bilder oder 3D? Max schrieb: > etablierten Algorithmen ZIP/LZW Max schrieb: > Daher ist die geometrische Transformation, die z.B. > eine 3D Rotation beschreibt, lokal variabel und müsste erst aus dem 2D > Bild approximiert werden Hä? Wenn die 3D Daten nicht vorliegen dan hast du einfach ein Bild. Und da wird so schnell auch kein "3D" sich rekonstruieren lassen. Wenn du viel "gleichfarbiges" im Bild hast würde sich auch PNG als Transportformat gepaart mit einer Differenzdatenübertragung anbieten.
Max schrieb: > Hinweis, für die Komprimierung steht nur das 2D Bild zur Verfügung, > nicht die 3D Daten. Daher ist die geometrische Transformation, die z.B. > eine 3D Rotation beschreibt, lokal variabel und müsste erst aus dem 2D > Bild approximiert werden. D.H. die 3D-Rekonstruktion aus dem 2D-Video hast du schon fertig? Und das dargestellte Objekt ist bekannt? Dann verschieb deinen Algorithmus halt auf die Kompressor-Seite, und übertrag nur noch die Koordinaten. Sind dann nur wenige Bytes pro Frame, und der Anzeige-Teil ist mit OpenGL schnell gemacht.
>> um animierte Bildsequenzen komprimiert >Was den nun Bilder oder 3D? Es geht um Bildsequenzen, die bewegte 3D-Objekte abbilden. Nichts ungewöhnliches, oder? >Hä? Wenn die 3D Daten nicht vorliegen dan hast du einfach ein Bild. Und >da wird so schnell auch kein "3D" sich rekonstruieren lassen. Nein. Aber MPEG Encoder analysieren z.B. blockweise, mit welchem Bewegungsvektor sich jeder Block bestmöglich aus vorherigen Frames vorhersagen lässt, ohne jedes Wissen was sich da eigentlich bewegt. Da sich in meinem Fall eine Gruppe starrer Körper bewegt, ließe sich diese Information eventuell ausnutzen. >D.H. die 3D-Rekonstruktion aus dem 2D-Video hast du schon fertig? Und >das dargestellte Objekt ist bekannt? Nein, das war nur ein Gedanke, um zu fragen, ob euch Lösungen in dieser Richtung bekannt sind. Einzig und allein die Bildsequenz ist verfügbar und soll komprimiert werden. >Dann verschieb deinen Algorithmus halt auf die Kompressor-Seite, und >übertrag nur noch die Koordinaten. Sind dann nur wenige Bytes pro Frame, Nein. Das 3D-Object hat mehr Vertices als ein VGA-Bild Pixel hat. >und der Anzeige-Teil ist mit OpenGL schnell gemacht. Es geht um einen Eigenbau-Mikrokontroller OHNE OpenGL, deshalb Bildübertragung! Max
Max schrieb: > Es geht um einen Eigenbau-Mikrokontroller OHNE OpenGL, deshalb > Bildübertragung! Dann würde ich den umgekehrten Weg gehen... > "Eigenbau-Mikrokontroller" => Also ein FPGA-Design? => Oder ein "Of-the-Shelf"-µC in einer eigenen Schaltung? Falls ersteres: Suchen welche Video-Decoding IPs es kostenlos oder billig gibt, das nehmen. Falls zweiteres: Suchen ob es überhaupt einen Video-Codec gibt, für den der µC schnell genug ist. Ggfs. auf µC mit Video-Coprozessor oder Video-DSP ausweichen. (TI Omap3/4 zum Bleistift) Realtime-komprimierung auf PC-Seite ist mit ner 3GHz/DualCore CPU sicher problemlos machbar. Es kann zwar sein, dass du mit einem selbstgebastelten, exakt auf deine Szene zugeschnittenten Codec geringfügig besser fährst, aber die "100 Jahre Zeit" dazu hast du wohl nicht. Stattdessen: Standard-Codec (sh oben) verwenden, allerdings die Bandbreiten-Steuerung selbst implementieren (Statt VBR/CBR) Damit kriegst du dann auch fast verlustfreie Keyframes nach Zeiten ohne Bewegung hin.
>Dann würde ich den umgekehrten Weg gehen...
Ja klar. Meine wichtigste Anforderung war "Billige Dekomprimierung beim
Empfänger!!!". Deshalb beseitigst du mal eben die Anforderung.
Warum sagst du nicht einfach: ersetze das langsame Netzwerk durch ein
schnelles, den Mikrocontroller durch einen Gaming-PC, verzichte auf
Komprimierung und gut ist!
Hardware steht. Die Anforderungen habe ich grob genannt. RFB mit ZRLE
ist eine gerade noch akzeptable Lösung, aber ich fragte nach möglichen
Verbesserungen. Nicht nach Änderungen der Hardware oder der
Anforderungen.
Max
Ich hab doch schon geschrieben PNG mit DeltaEncoding dollte noch einigermaßen fix sein, du könntest ja wenigstens mal sagen was für eine HW du benutzt, (8, 16, 32bit mc...) und welche Framerate du erreichen willst, welche Dekomprimierungsrate du erreichen willst (auch 10fps?) und welche Datenraten deine "Verbindung" schafft.
Max schrieb: > Ja klar. Meine wichtigste Anforderung war "Billige Dekomprimierung beim > Empfänger!!!". Deshalb beseitigst du mal eben die Anforderung. Ich habe die Anforderung nicht beseitigt, ich habe sie als zentralen und wichtigsten Punkt verstanden und als Grundlage für meinen Vorschlag verwendet. Dass deine Ziel-Hard und Software jedoch unveränderlich ist, und sie NUR und AUSSCHLIESSLICH RLE Dekomprimieren kann hättest du gleich am Anfang sagen können. Dann hätten wir uns den ganzen Thread sparen können.
Willkommen bei mikrocontroller.net, Max! Dies ist kein Forum, um Antworten zu erhalten. Dies ist ein Forum, das Moderatoren und gescheiterten Existenzen erlaubt, sich Fragen zurechtzuinterpretieren, so dass sie zu jedem Thema etwas zu sagen haben und mit ihrem Wissen glänzen können, das sonst niemanden interessiert. Google "hierarchical image compression" und spar dir deine Zeit. mikrocontroller.net ist zum Kaputtlachen geeignet, aber nicht zum Erfahrungsaustausch.
Da das hier ja so zum kaputtlachen ist und du es jetzt sogar für nötig hälst dir selbst den Tip zu geben mal bei Google zu suchen, dann tu das bitte auch.
Thread beobachten
Seitenaufteilung abschalten