www.mikrocontroller.net

Forum: Gesperrte Threads 3D Animationen komprimieren + schnelle DEkomprimierung


Autor: Max (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
Youtube-Video "Micro Turbine Engine -CAD animation"
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
Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: DirectX (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Max (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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

Autor: DirectX (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Max (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: DirectX (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Animateur (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Dieser Beitrag ist gesperrt und kann nicht beantwortet werden.