Kann man Grafik nicht bis zum Schluss komprimieren?

[Mastermind]

Wir haben heutzutage schon bis zu 512MB VRAM auf dedizierten GraKas, bei der kommenden Generation ist mit bis zu 1GB zu rechnen. 32Bit-Systeme kommen inst Straucheln. Trotzdem ist der Platz knapp, bei hohen Auflösungen und hohen AA-Samplingwerten (von SSAA ganz zu schweigen) ist der Platzbedarf enorm. Dabei kommen bald Blu-Ray und HD-DVD. Platz für zahlreiche extrem hochauflösende Texturen satt. Trotzdem ist die Texturkompression AFAIK verlustbehaftet und nicht besonders effezient was den Platzgewinn angeht.

Dabei steigt doch auch die Rechenleistung und die GraKas werden immer mehr erweitert. Jetzt stelle ich mir vor, könnte man vielleicht auch auf der Karte immer noch komprimieren und zwar verlustfrei. Die nötige Geschwindigkeit für Echtzeitanwendungen sollte mit einem Hardware-Baustein, der dafür zuständig ist, kein Problem sein. Das einzige Problem welches ich sehe ist, dass Operationen nicht mehr so einfach durchgeführt werden können wie bei direkt vorliegenden, ich nenn sie mal "Bitmaps". Deswegen meine Frage:

Kann man mit Hilfe irgendwelcher mathematischer Verfahren Operationen so bearbeiten, dass sie direkt auf verlustfrei komprimierte Bilder wirken können?

Ich finde ein gutes Beispiel für das was ich meine sind die Display-Texturen bei Doom3. Wenige Farben, große gleichfarbige Flächen, dabei eine sehr hohe Auflösung. Ich würde darauf tippen, dass man mit PNG-Komprimierung auf 10% des Platzbedarfs runterkommt. Wenn jetzt also der geringere Platzbedarf einen höheren Geschwindigkeitsvorteil bietet, als der Aufwand für die Komprimierung an Geschwindigkeitsverlust bringt, dann hat sich das Verfahren gelohnt.

Ich könnte mir vorstellen, die komprimierten Daten auch so zum Bildschirm zu senden, denn erst dort müssen sie wirklich dekomprimiert vorliegen. Es ist schon abartig, dass man bei so modernen Anschlüssen wie DVI in der Auflösung beschränkt ist. Und alles nur, weil unkomprimierte Grafik enorm Bandbreite frisst. Dann baut man halt noch nen Baustein in den Monitor der dekomprimiert und alles wird gut. :smile:

Was haltet ihr von meiner Idee? :D

[grandmasterw]

Wir schwierig sein, weil du ja nicht einzelne Pixel komprimierst (berichtigt mich, hab von Texturkompression nicht sooo die Ahnung).

d.h. wenn du die Farbe eines Pixels änderst, wirkt sich das auf die Kompressionsmöglichkeiten der andern Pixel aus. Und wenn du da viele Transparente Bereiche hast, werden Pixel später öfters übermalt, d.h. das ganze dürfte unmöglich sein.

Vorstellen könnt ichs mir bei nem Tile-Based Renderer, der ein Tile eh nimmer anrührt, wenns fertig gerendert ist. Die sparen aber eh schon recht viel, da sie ja nur den Frontbuffer brauchen.

[Gast]

Und was soll das bringen? Es gibt definitiv immer Daten die sich gar nicht komprimieren lassen deshalb muss die verfügbare Bandbreite zum Monitor eh wieder die gleiche sein.

[Spasstiger]

Ich finde ein gutes Beispiel für das was ich meine sind die Display-Texturen bei Doom3. Wenige Farben, große gleichfarbige Flächen, dabei eine sehr hohe Auflösung. Ich würde darauf tippen, dass man mit PNG-Komprimierung auf 10% des Platzbedarfs runterkommt. Wenn jetzt also der geringere Platzbedarf einen höheren Geschwindigkeitsvorteil bietet, als der Aufwand für die Komprimierung an Geschwindigkeitsverlust bringt, dann hat sich das Verfahren gelohnt.
Das sind keine Texturen im klassischen Sinn, sondern GUIs, die aus vielen kleinen Bildern zusammengestückelt sind. Deshalb hält sich der Speicherverbrauch für die GUI-Texturen sehr in Grenzen, mit komprimierten Texturen ca. ein halbes MB je GUI (die Texturen in D3-Engine-Spielen liegen standardmäßig schon komprimiert vor neben den unkomprimierten TGA-Versionen für Ultra-High-Quality). Und ein halbes MB macht bei einem Verbrauch von 300 MB insgesamt überhaupt nichts aus.

[Monger]

Wenn ich dich richtig verstehe, denkst du an sowas wie prozedurale Texturen on-the-fly. Nette Idee, aber leider mit Schwächen.

Wie willst du dem Rechner beibringen, bei welchen Texturen (und in welchen Bereichen) sich eine Umrechnung in prozedurale Muster lohnen würde, und wo nicht?
Sobald du ebenmäßige Flächen hast, ist das ja gar kein Problem. Was, wenn du aber sehr detaillierte Texturen hast? Das extrem unregelmäßige farbliche Rauschen lässt sich mit keinen Formeln mehr vernünftig erfassen: die Beschreibung der Formeln würde mehr Speicherplatz verschlingen als das Bild selbst.

Jetzt mal angenommen, wir finden irgendeinen Algorithmus der die Finger von allzu komplexen Formen lässt. Dann haben wir einen Mischmodus, in dem wir je nach Situation die Texturen neu zusammenflicken müssen. Dann müssen wir irgendwelche eigenen Filtermechanismen erfinden, die allzu hässliche Artefakte verhindern...


Ne, vergiss es. Im Endeffekt ist nämlich Grafikkartenspeicher doch noch wesentlich billiger als GPU Leistung. Lieber nochmal 512 MB aufs Board packen, als ein unnötig kompliziertes und teures Chipdesign zusammenzufrickeln.

Wie schon hier im Forum öfters gesagt: manchmal ist die stupide Lösung eben doch die bessere.

[Gast]

mit verlustloser kompression für texturen in echtzeitgrafik wird das ganze wohl sehr schwer.

in einem verlustlosen verfahren gibt es immer auch mögliche farbwerte die sich garnicht komprimieren lassen, insgesamt wirst du vom kompressionsgrad eher geringer werden.

viel wichtiger aber noch: bei der echtzeitberechnung will man dass ein pixelblock immer gleich viel speicher verbraucht. beispielsweise braucht ein 4x4-block DXTC1-komprimiert immer gleich viel platz.
zusätzlich braucht man in der echtzeitberechnung oft zugriff auf einzelne texel einer textur, die man möglichst direkt adressieren will. das geht mit DXTC zwar auch nicht mehr, aber immerhin muss man nur einen 4x4-block dekomprimieren wenn man einzelne texel daraus braucht.

für "normale" texturen ist DXTC auch sehr gut geeignet, es erreicht recht gute kompressionsverhältnisse, bei praktisch nicht sichtbarem detailverlust.

für normalmaps gibt es ja mittlerweile 3Dc, hier wird allerdings nur eine recht geringe reale kompression erreicht (eine normalenrichtung wird einfach garnicht gespeichert und im shader rekonstruiert), eventuell lässt sich hier noch etwas besseres finden (vor allem da normalmaps oft große "einfärbige" flächen haben)

das einzige was noch fehlt ist ein kompressionsformat für FP-texturen.

[Gast]

Wieso gibts im Optikbereich nix intelligenteres als 2-4x Komprimierung. Was wir brauchen ist ein optisches MP3-Verfahren mit Kompression um die 10x.

[tokugawa]

Wieso gibts im Optikbereich nix intelligenteres als 2-4x Komprimierung. Was wir brauchen ist ein optisches MP3-Verfahren mit Kompression um die 10x.

Das wär sowas wie JPEG, und eben - wie MP3 - nicht verlustfrei.

[DaBrain]

Von wegen 2-4. DXT1 reduziert den Platzverbrauch auf ein Achtel!


Insgesamt finde ich den Qualitätsverlust bei DXTc nicht so schlimm. Auf einem Großteil der Texturen fällt er gar nicht auf. Eine Sandtextur sieht komprimiert z.B. nicht schlechter aus und minimale Farbabweichungen sehe ich auch nicht so eng.

Klare und feine Kontraste, das sind die eigentlichen Problemfälle. (weißer Hintergrund + dünne schwarze Linie). Immerhin kann man daraus noch eine 46-Bit Textur, oder eine Textur mit einer 8-Bit Palette machen. Wenn auch die beiden Möglichkeiten schlecht aussehen, kann man die Textur auch unkomprimert bei 24-Bit lassen. Viele dieser Ausnahmefälle sollte es sowieso nicht geben.

Normal Maps vertragen sich wirklich nicht besonders gut mit DXTc und auch 3dc ist noch nicht die optimale Lösung.


Übrigens kostet es ein bisschen Zeit eine größere Menge Texturen (200-300 MB?) zu komprimieren. Mit einem schnellen Verfahren geht es vielleicht noch, aber man verschenkt unnötig Bildqualität und bekommt als ausgleich nur eine längere Ladezeit...

[Zool]

Wieso gibts im Optikbereich nix intelligenteres als 2-4x Komprimierung. Was wir brauchen ist ein optisches MP3-Verfahren mit Kompression um die 10x.

Sowas gibt es schon recht lange. Ein rechtgebräuchliches Format nennt sich MPEG2 (vielleicht schon mal davon gehört :-)?) oder die Nachfolger auf MPEG4-Basis wie Divx, XVID, H.263.

Nur leider für 3D total unbrauchbar

[aths]

Von wegen 2-4. DXT1 reduziert den Platzverbrauch auf ein Achtel!Selbst wenn man sehr großzügig rechnet, kommt man nur auf 1/6.

[Gast]

Zool

Sorry aber Mpeg 2/4 divx ... sind definitiv keine Texturformate sondern zur Kompression von Filmen

Also ich würde wenn überhaupt Komprimieren unter DirectX DXTC einsetzen.
Etwas neues Entwickeln is immer ne gute Idee nur obs angenommen wird ist fraglich. Zudem kann man kann Bildkompression und Texturkompression nicht in einen Topf werfen.
Für Bildkompression gibts ne Menge Algos die gut sind, für Texturen müssen sieht es anders aus es geht halt nicht dass man JPEG oder JPEG2k für Texturen nutzt weil keine Pixel vorhanden sind die müssen erst Wiederhergestellt werden

[aths]

JPEG wäre als Block-Komprimierer im Prinzip für Texturkomprimierung geeignet, wirft aber durch die unterschiedlich langen Blöcke und durch die im Vergleich zu S3TC hochkomplexe Decoderlogik zu viele Probleme für den praktischen Einsatz heute auf.

[DaBrain]

Selbst wenn man sehr großzügig rechnet, kommt man nur auf 1/6.

Von 24-Bit zu DXT1 ist es ganau Faktor 6. Und von 32-Bit wäre es Faktor 8.

[Neomi]

Von 24-Bit zu DXT1 ist es ganau Faktor 6. Und von 32-Bit wäre es Faktor 8.

Na wenn man das so sehen will, dann ist 32 Bit auch nur eine 4:1-Kompression von FP32-Texturen, 256x256 ist eine 16:1-Kompression von 1024x1024, ...

Für die Kompressionsrate kann man eigentlich nur das zählen, was man aus den komprimierten Daten wieder rekonstruieren kann. Und da man aus DXT1 nur 1 Bit Alpha rekonstruieren kann, darf man nicht die vollen 8 Bit des Alphakanals zählen. Die unteren 7 Bit werden nämlich nicht komprimiert, sondern weggeworfen.

[DaBrain]

Gut, aber wenn ich eine halbtranspartente Textur habe müsste ich schon ein 32-Bit Format nehmen wenn es unkomprimiert sein soll.

Bei DXT1 könnte ich einfach einen Wert setzen.