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
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