Extrem rechenintensive Bild- / Videokomprimierungsschemata, die eine bessere Komprimierung bieten als der Industriestandard JPEG / H.264

Ich versuche, nach Bild- / Videokomprimierungsschemata zu suchen, die im Vergleich zu weit verbreiteten Industriestandards (dh JPEG / H.264) eine überlegene Komprimierungsleistung bieten (Bildqualität als konstant halten), aber aus Gründen, die entweder zu rechenintensiv oder zu ressourcenintensiv sind Eine intensive Implementierung auf CPU-basierten Workstations ist nicht möglich und wird daher in gängigen Standards nicht übernommen.

Ich konnte mir nur die fraktale Kompression als gutes Beispiel vorstellen. Kennt die Community weitere Beispiele?

— Ang Zhi Ping
quelle

In Bezug auf Bilder gibt es ausgefeiltere Algorithmen als JPEG, wie z. B. JPEG2000. JPEG2000 bietet verbesserte Komprimierungsverhältnisse, aber ich bin nicht sicher, ob die mangelnde Akzeptanz auf die Komplexität der Berechnungen zurückzuführen ist. Darüber hinaus wird JPEG für die meisten Anwendungen als "gut genug" angesehen, sodass es keine wirkliche Motivation gibt, etwas Besseres zu verwenden (zumal in modernen Systemen so viel Festplattenspeicher vorhanden ist). Diejenigen, denen höchste Bildqualität am Herzen liegt, wie professionelle Fotografen, meiden die Komprimierung häufig ganz und verlassen sich auf Rohaufnahmen der Bildsensorausgaben.

— Jason R

Ich denke, die Qualität von JPEG hängt mehr davon ab, wie viele Daten Sie wegwerfen, als davon, wie viel Zeit Sie damit verbringen, sie zu berechnen.

— Endolith

Hauptkomponentenanalyse / KLT / Hotelling-Transformationen können bei der Darstellung eines Signals mit einer kleinen Anzahl von Basisfunktionen eine viel bessere Arbeit leisten als die DCT, sind jedoch recht rechenintensiv. Ich bin mir nicht sicher, ob jemand tatsächlich vollständige Komprimierungsschemata mit ihnen durchgeführt hat.

— Eglaser

@eglaser: Möchtest du PCA / KLT / Hotelling näher erläutern? Es wäre gut, wenn Sie Ihre Antwort als Antwort posten könnten.

— Ang Zhi Ping

@eglaser KLT ist hinsichtlich der Energiekompaktheit besser als DCT. Dies bedeutet jedoch nicht unbedingt, dass es sich um einen besseren Codec handelt. Dies liegt daran, dass KLT für jedes Bild / Video-Stück einzigartig ist und Sie daher nicht nur die resultierenden Koeffizienten übertragen müssen, sondern auch den Kernel senden müssen.

— Dipan Mehta

Es gibt verschiedene Aspekte der Komprimierung - unabhängig davon, ob Sie sich auf ein Bild oder ein Video beziehen. (Möglicherweise ist Audio völlig anders, daher beziehe ich mich hier nicht darauf).

Wenn Sie sich wirklich die Geschichte des Komprimierungsstandards ansehen, als sie zum ersten Mal erstellt wurden, waren MPEG1-Echtzeitcodierer selten. Die CPU selbst reichte zu diesem Zeitpunkt nicht aus, um sie in Echtzeit zu erstellen. Es war jedoch nicht die Verarbeitungskomplexität (allein), die die Verwendung von Algorithmen mit höherer Komplexität unter Codecs stoppte. (Wahrscheinlich war der Hauptfaktor, der für das Einschließen / Ausschließen bestimmter Algorithmen verantwortlich war, a. Patente, b. Durchführbarkeit der Implementierung).

Ich möchte die Frage jedoch etwas einfacher umformulieren:

Welche anderen Forschungsergebnisse zur Komprimierung sind verfügbar, die noch auf den Markt kommen müssen (oder gar nicht kamen, sich aber für einige Anwendungen lohnen könnten)?

Hier sind einige Punkte zu beachten:

1. Besser verwandeln?

DCT war bei weitem eine universelle Transformation für alle Codecs. Es gibt jedoch viele Forschungsarbeiten, die darauf hinweisen, dass Wavelets besser sein könnten. In der Tat enthielt das einzige JPEG2000 Wavelets - aber dieser Standard selbst war kein großer Erfolg. Wahrscheinlich war es irgendwie besser als DCT; Insbesondere gibt es Behauptungen, dass Wavelets die DCT übertreffen [Siehe: Ref 1]

Ich denke, Wavelet ist gegenüber DCT rechenintensiv (teilweise, weil 8x8-DCT-Implementierungen stark optimiert sind). Aber ich denke, ich bin nicht wirklich so viel geflogen, weil aus Sicht des Marktes DCT zu der Zeit weitaus weiter verbreitet war und der Unterschied in der Verbesserung für die Leute nicht so groß war, um zu wechseln.

2. Bewegungskompensation mit mehreren Hypothesen
Während MPEG 2 mit Bildern zufrieden war , haben umfangreiche Untersuchungen von Bern Girod [siehe Lit. 2] bewiesen, dass - das Konzept weit darüber hinaus erweitert werden kann. Tatsächlich hat H.264 eine große Verallgemeinerung der Bewegungskompensation mit mehreren Zielen vorgenommen - im Grunde kann man mehr als 16 Bilder speichern (vergleiche mit 2 in MPEG2), und tatsächlich kann die Vorhersage extrem hoch sein. $B$

Dies ist zwar bereits Teil des Standards in H.264 - dies wird jedoch noch nicht vollständig ausgenutzt. Es besteht die Notwendigkeit, eine derart umfangreiche Suche nach Bewegungsschätzung praktisch durchführbar zu machen. Die meisten H.264-Encoder sind noch im Entstehen begriffen, um das volle Potenzial davon auszuschöpfen.

3. Skalierbare Bild- / Videokomprimierung Die
skalierbare Bild- und Videokomprimierung ist wieder ein heiliger Gral dafür, wie die Mehrfachbeschreibungscodierung für Bild und Video durchgeführt werden kann. Grundsätzlich kann dasselbe Bild oder Video mit mehreren Auflösungen, Quantisierungen (Qualität) oder Bildraten codiert werden. Diese erzeugen unterschiedliche Qualitätsebenen im Verhältnis zur Bitrate direkt innerhalb desselben Streams - und der Streaming-Server kann die Bitrate und Qualität dynamisch anpassen, um das Video optimal an die Qualität anzupassen. Siehe [Ref. 3], [Ref. 4], [Ref. 5]

Ein wirklicher Erfolg ist nur progressives JPEG, das für Websites praktisch und in der Tat nützlich ist. Auch hier ist das Versprechen einer dynamischen Anpassung des Bitstroms groß, aber es funktioniert nur, wenn es praktische Systeme gibt, in denen die Schätzung einer solchen Bitrate möglich ist und die Art der Anpassung einem echten Zweck dienen kann. Im Videobereich gibt es jedoch trotz der Unterstützung in den Standards (MPEG2, MPEG4 und H.264) kaum eine Verwendung davon.

4. Objektvideo
Dies ist vielleicht der ultimative heilige Gral der Kompression. Das vom MPEG-Standardkörper selbst initiierte Objektvideo [Ref. 6] wurde jedoch auch durch umfangreiche Untersuchungen gestützt.

Die Grundidee besteht darin, das Video in verschiedene Objekte zu segmentieren, und später kann jedes dieser Objekte als separate Ebene behandelt werden. Jedes Objekt kann mit unterschiedlicher Bitrate, Quantisierung, Bildrate und sehr effizienter Vorhersage angewendet werden. Sie können solche Objekte auch so manipulieren, wie Sie es in Photoshop / Gimp tun können.

Wie sich jedoch herausstellt, ist die Segmentierung von realem Bild und Video mit wahrnehmungsrelevanten Objekten ein schwieriges Problem! Selbst wenn ich Encoder / Decoder habe, brauche ich Robus und ein Echtzeit-Segmentierungssystem, um die Dinge zu ermöglichen. Dies ist bei weitem ein wirklich offenes Problem, wie Sie Videos in Form eines solchen geschichteten Videos anwenden, damit es funktioniert.

5. Weitere Dimensionen
Abgesehen davon gibt es Codecs für Stereovideo (auch bekannt als Multiview) und 3D-Video (fast ähnliches Konzept), die zusätzlich versuchen, die Redundanz in der zusätzlichen Dimension zu reduzieren. Während hier noch geforscht wird, hat H.264 jetzt ein Profil dafür. Gleiches gilt für die Cinema-Codierung.

Es gibt noch viele Forschungsprojekte auf diesem Gebiet - die Videokomprimierung ist jedoch mittlerweile ein ziemlicher Rohstoffmarkt. Und Forschung, die im Wesentlichen keine neue Anwendung generiert oder bei der Implementierung Machbarkeitsprobleme aufweist, wird trotz ihres Einfallsreichtums praktisch nicht überleben.

Hoffe das hilft.

Verweise:

— Dipan Mehta
quelle