Archiv verlassen und diese Seite im Standarddesign anzeigen : DXT reif für ne Ablöse?
Mr. Lolman
2007-07-13, 17:34:16
Hab mir heut ein Oblivion Texturepack von Qarl geladen. Größe: 1.7GB als 7z gepackt. Ungepackt sinds 2.7GB dds Files. Diverse Dateien lassen sich von 1.35MB auf 0.75MB verlustfrei mit 7z packen. Nun ist ja das DXT Format selbst auch schon dummerweise verlustbehaftet und lässt sich aber (im Gegensatz zu JPG) trotzdem noch weiter (verlustfrei) verkleinern. Irgendwie drängt sich da der Eindruck einer schwachen Effizienz auf.
Eure Meinung dazu?
san.salvador
2007-07-13, 17:40:09
Bei Texturen gehts ja auch darum, sie möglichst flott parat zu haben, da kann man dann nicht warten, bis ein genial geschrumpftes Päckchen geöffnet ist.
Aber Dxt ist ja auch nicht wirklich frisch und heute wäre bestimmt anderes möglich, aber um das mit Fakten zu untermauern fehlt mir das Wissen. :)
SavageX
2007-07-13, 17:51:01
DXT/S3TC führt keine Entropie-Kodierung durch, so dass sich nach der Durchführung der verlustbehafteten Informationsreduzierung keine verlustfreie Kompression anschließt.
Bei z.B. JPEG wird zuerst eine Cosinustransformation gemacht (das ist verlustfrei - bis vielleicht auf Rundungsfehler), dann werden die Koeffizienten quantisiert (das ist die Informationsreduzierung) und dann wird das ganze noch platzsparend abgelegt (Huffman-Codierung - verlustfreie Kompression).
Ich übersetz mal.
Sprich: Als wie wenn JPEG nur durch quantisieren der Koefizienten geschrumpft würde.
Sprich2: DXT/S3TC Texturen sind garnicht gepackt. Sie sind nur datenreduziert. Da davor keine Entropie-Kodierung stattfindet, kann man es hinterher auch nicht mehr verlustfrei packen.
Frage: Soll das heißen, 7-zip oder Winrar packen DXT nicht verlustfrei? :|
Ob es aus der technischen Sicht Sinn machen würde ein neues Format mit Entropie-Kodierung und Packalgorythmus auszustatten? Fachleute vor =)
Ich denke der Mehraufwand an Transistoren und die zusätliche Leistungsaufnahme sollte man nicht außer acht lassen.
Gleichzeitg denke ich aber, daß ein paar Hundert Mhz ASIC der (in Hardware eben) Huffman entpacken kann, es schon auf die zigfache Geschwindigkeit eines Softwareentpacker auf einem C2D@3Ghz bringen würde.
Die Entwicklung/Aufwand würde aber kaum an die preiswertere Methode rankommen. 1GB VRAM, PEG-Durchsatz, 64bit Systeme mit 4 oder 8 GB, Platten mit hunderten von GBs + der Durchsatz einer popeligen 500GB sata2 Samsung (als Beispeil) und und und.
][immy
2007-07-13, 18:39:04
Ich übersetz mal.
Sprich: Als wie wenn JPEG nur durch quantisieren der Koefizienten geschrumpft würde.
Sprich2: DXT/S3TC Texturen sind garnicht gepackt. Sie sind nur datenreduziert. Da davor keine Entropie-Kodierung stattfindet, kann man es hinterher auch nicht mehr verlustfrei packen.
Frage: Soll das heißen, 7-zip oder Winrar packen DXT nicht verlustfrei? :|
Ob es aus der technischen Sicht Sinn machen würde ein neues Format mit Entropie-Kodierung und Packalgorythmus auszustatten? Fachleute vor =)
Ich denke der Mehraufwand an Transistoren und die zusätliche Leistungsaufnahme sollte man nicht außer acht lassen.
Gleichzeitg denke ich aber, daß ein paar Hundert Mhz ASIC der (in Hardware eben) Huffman entpacken kann, es schon auf die zigfache Geschwindigkeit eines Softwareentpacker auf einem C2D@3Ghz bringen würde.
Die Entwicklung/Aufwand würde aber kaum an die preiswertere Methode rankommen. 1GB VRAM, PEG-Durchsatz, 64bit Systeme mit 4 oder 8 GB, Platten mit hunderten von GBs + der Durchsatz einer popeligen 500GB sata2 Samsung (als Beispeil) und und und.
der geschwindigkeitsverlust beim entpacken wäre wahrscheinlich aber nichts gegen den geschwindigkeitsverlust beim auslesen der daten von der festplatte. von daher sollte es sich ansich lohnen die daten gepackt von der festplatte aus zu lesen.
könnte mir aber vorstellen, da das spiel von der xbox 360 kommt das sie vermeiden wollten das durch einen kratzer ein komplettes datenarchiv zerstört wird, wodurch dann sofort ein ganzer haufen an daten defekt sein könnten.
gibt es eigentlich schon einen richtigen nachfolger von DXT der auch von nvidia und ati grafikkarten unterstützt wird?
Neomi
2007-07-13, 20:41:08
Eine Datei, die man mit einem normalen Packer gepackt hat, kann man auch nur als ganze Datei wieder entpacken. Angenommen, eine 64 MiB große Datei wurde auf 11 MiB gepackt. Jetzt will man mal eben 16 Byte haben, die in der ungepackten Datei exakt 62 MiB nach Start der Datei zu finden sind. Wieviel muß man entpacken? 16 Bytes? Nein, 62 MiB und 16 Bytes. Für einen Texturzugriff ist sowas undenkbar.
Mit einem blockbasierten Format, wie es die DXT-Formate sind, ist die Position des Blocks mit den gewünschten Texeln alleine durch die Koordinaten zu berechnen und der Block kann ohne Kenntnis des Inhaltes der anderen Blöcke entpackt werden. Natürlich kann die reine Kompressionsrate nicht mit Archivpackern mithalten, aber DXT ist ja auch nicht als Archivformat gedacht. Beim gezielten und schnellen Zugriff auf Teildaten sind blockbasierte Formate die einzige Option neben komplett ungepackten Daten.
DXT durch ein Archivformat zu ersetzen, weil das beim Archivieren besser ist, würde einfach nur zu desaströsen Ergebnissen führen. Man pflügt auch keine Felder mit tiefliegenden Sportwagen, obwohl die auf der Rennstrecke jeden Trecker abhängen.
[immy;5667517']der geschwindigkeitsverlust beim entpacken wäre wahrscheinlich aber nichts gegen den geschwindigkeitsverlust beim auslesen der daten von der festplatte. von daher sollte es sich ansich lohnen die daten gepackt von der festplatte aus zu lesen.
Echte Archivformate (die, deren Primärziel kleine Dateien sind) sind viel zu lahm beim entpacken, aber simple Kompressionsalgorithmen sind durchaus empfehlenswert. LZSS z.B. ist richtig gut. DXT-Formate können meist nochmal ordentlich gepackt werden, wenn auch nicht annähernd so gut wie mit echten Archivpackern. Dafür ist LZSS beim Entpacken praktisch nur durch die Speicherbandbreite begrenzt.
(del)
2007-07-13, 21:10:54
Eine Datei, die man mit einem normalen Packer gepackt hat, kann man auch nur als ganze Datei wieder entpacken. Angenommen, eine 64 MiB große Datei wurde auf 11 MiB gepackt. Jetzt will man mal eben 16 Byte haben, die in der ungepackten Datei exakt 62 MiB nach Start der Datei zu finden sind. Wieviel muß man entpacken? 16 Bytes? Nein, 62 MiB und 16 Bytes. Für einen Texturzugriff ist sowas undenkbarJa wann greift sowas aber? Werden Texturen meist in eine einzige große Datei zusammengefügt, aus welcher sie dann Stückweise geholt werden?
Falls nicht, wo liegt das Prob? Falls ja, kann man ja die Einzeltexturen packen udn sie DANN in einer großen Datei zusammenfügen.
Alternativ check ich nicht wie du das meinst :tongue: Ich sehe das aber erstmal aus der Sicht der Dateiebene.
Natürlich kann die reine Kompressionsrate nicht mit Archivpackern mithalten, aber DXT ist ja auch nicht als Archivformat gedachtWas ist denn nun? Ist DXT komprimiert oder nur datenreduziert? (so wie ich das oben meinete. bessere Bezeichnungen fallen mir momentan nicht ein)
aber simple Kompressionsalgorithmen sind durchaus empfehlenswert. LZSS z.B. ist richtig gut. DXT-Formate können meist nochmal ordentlich gepackt werden, wenn auch nicht annähernd so gut wie mit echten Archivpackern. Dafür ist LZSS beim Entpacken praktisch nur durch die Speicherbandbreite begrenzt.s.o.
Es geht darum wie die Daten im VRAM vorliegen, und da ist ein nicht-konstanter Packfaktor einfach nicht zielführend, bzw. sehr schwer zu implementieren.
Ah... Ja klar :frown: Das geht ja erstmal "roh" in den VRAM. Ok. Gepeilt. Danke.
BH
Obwohl... kann man keinen Packer machen wo das Ratio ("Packfaktor"?) nicht feste ist? Man würde einige Texturen so nicht ganz so optimal packen (können), andere aber schon beachtlich.
Würde dann vielleicht von Farbanteilen abhängen usw.
BH
Ich meinte "feste IST" :(
Neomi
2007-07-13, 21:48:04
Ja wann greift sowas aber? Werden Texturen meist in eine einzige große Datei zusammengefügt, aus welcher sie dann Stückweise geholt werden?
Wie gesagt, es geht um die Daten im Grafikspeicher. Da muß die Kompression blockbasiert sein, damit schnell auf die Texel zugegriffen werden kann. Lange davor, wenn die Texturen aus einer Datei geladen werden, spricht nichts gegen eine Nutzung einer weiteren (dann nicht blockbasierten) Kompression.
Was ist denn nun? Ist DXT komprimiert oder nur datenreduziert? (so wie ich das oben meinete. bessere Bezeichnungen fallen mir momentan nicht ein)
DXT ist beides. Die Farben werden auf 16 Bit Genauigkeit (dank Mischfarben pro 4x4 Texelblock eher ein wenig mehr) reduziert und dann noch in Blöcken komprimiert. Jeder Block enthält zwei Referenzfarben in 16 Bit, zwei zusätzliche werden interpoliert, jeder Texel nutzt eine dieser vier Farben. Pro Farbblock à 8 Bytes werden 16 Texel gespeichert.
Obwohl... kann man keinen Packer machen wo das Ratio ("Packfaktor"?) nicht feste ist? Man würde einige Texturen so nicht ganz so optimal packen (können), andere aber schon beachtlich.
Die feste Packrate ist ja gerade eine Anforderung an das Format, damit es für Texturen überhaupt geeignet ist. Ein geeignetes Format muß blockweise arbeiten, jeder Block muß die gleiche Zahl an Texeln enthalten und die gleiche Menge an Speicher belegen. Die Blöcke müssen dabei so klein wie möglich sein und mit einer sehr simplen Logik (immerhin muß das in etlichen TMUs integriert werden) entpackt werden können. Ich sehe da kein echtes Optimierungspotential mehr ausgehend von DXT. Was noch fehlt, sind Kompressionsformate für Floatingpoint-Datentypen.
DaEmpty
2007-07-13, 22:11:01
Eure Meinung dazu?
Da gibts jedes Jahr einige Papers zu dem Thema.
*Aktuelles Beispiel* (http://research.microsoft.com/~hoppe/ratrees.pdf)
Das Kosten-/Nutzen-Verhältnis ist abgesehen von Spezialfällen aber bisher noch relativ schlecht. Es wird aber wohl in Zukunft definitiv ein Thema werden, da man Bandbreite sparen muss.
Bei Texturen gehts ja auch darum, sie möglichst flott parat zu haben, da kann man dann nicht warten, bis ein genial geschrumpftes Päckchen geöffnet ist.
Aber Dxt ist ja auch nicht wirklich frisch und heute wäre bestimmt anderes möglich, aber um das mit Fakten zu untermauern fehlt mir das Wissen. :)S3TC ist eine extrem gute Methode. (Untersuchungen zur Texturkomprimierung war das Thema meiner Diplomarbeit.)
][immy
2007-07-14, 11:19:36
Eine Datei, die man mit einem normalen Packer gepackt hat, kann man auch nur als ganze Datei wieder entpacken. Angenommen, eine 64 MiB große Datei wurde auf 11 MiB gepackt. Jetzt will man mal eben 16 Byte haben, die in der ungepackten Datei exakt 62 MiB nach Start der Datei zu finden sind. Wieviel muß man entpacken? 16 Bytes? Nein, 62 MiB und 16 Bytes. Für einen Texturzugriff ist sowas undenkbar.
das stimmt nicht ganz. ich habe z.B. letzte tage mit dem code eines open source zip-internet entpackers experimentiert. diesem war es möglich nur die teile zu entpacken die du auch brauchst ohne die komplette zip-datei runterzuladen. sprich es werden nur die daten geladen, de man auch benötigt. leider habe ich keine ahnung mehr wo sich dieser entpacker befindet denn ich brauchte eher die funktionalität eine zip-datei in einen URi-pfad zu entpacken.
ein zu rechenintensiver algorithmus darf natürlich nicht verwendet werden, aber die festplatte ist richtig langsam im vergleich zum entpacken von daten im speicher.
Man sucht trotzdem viel zu lange nach der Stelle wo die Daten liegen. Bei DXT weiß die GPU sofort woher sie ein Texel an den Koordinaten x,y findet.
Wenn man besser komprimieren will muss man mehr Indirektionen einbauen und das verschlechtert die Performance.
=Floi=
2007-07-14, 11:50:34
gibt es überjaupt noch einen sinn für sowas?
level werden ja vor dem spielen in den vram und ram geladen (bei über 90% der spiele) und dann hat es sich in den meisten fällen auch mit dem laden
bandbreiten nehmen auch sehr stark zu (bald wird es 2gb vram mit GDDR4 @ 2ghz geben was ungefähr 256gb/sek bandbreite entsprechen würde ) deshalb sehe ich da keinen wirklichen sinn darin neue resource hineinzustecken, wenn es auch so problemlos geht und die gesparten transistoren in andere flaschenhälse gesteckt werden können (siehe HD2900XT als argument dafür)
Es geht nicht um's Laden. Das übertragen der Texturdaten dauert nicht mal eine Sekunde über PCIe.
Texturkompression ist nur dazu da VRAM und Speicherbandbreite zu sparen und das ist beides immer noch kein Gut das man beliebig zur Verfügung hat.
Falls nicht, wo liegt das Prob? Falls ja, kann man ja die Einzeltexturen packen udn sie DANN in einer großen Datei zusammenfügen.
das kann man ja auch gerne machen für die speicherung der texturen auf der festplatte/cd/dvd.
wenn eine TMU aber ein bi-sample erzeugt braucht sie genau 4 bestimmte samples aus der textur die nun im VRAM liegt. diese müssen dann schnell genug zur verfügung stehen, ohne die ganze textur auslesen zu müssen
micki
2007-07-16, 18:26:50
Hab mir heut ein Oblivion Texturepack von Qarl geladen. Größe: 1.7GB als 7z gepackt. Ungepackt sinds 2.7GB dds Files. Diverse Dateien lassen sich von 1.35MB auf 0.75MB verlustfrei mit 7z packen. Nun ist ja das DXT Format selbst auch schon dummerweise verlustbehaftet und lässt sich aber (im Gegensatz zu JPG) trotzdem noch weiter (verlustfrei) verkleinern. Irgendwie drängt sich da der Eindruck einer schwachen Effizienz auf.
Eure Meinung dazu?wenn du texturen in DXT konvertierst, werden sie danach oft sehr gut packbar, mit lz87 bekommst du schon locker packraten auf <50%.
dxt wurde aber auch nicht mit dem ziel entwickelt texturen kleiner zu machen, sondern bei gleicher groesse mehr pixel/details zu bieten. das mag zwar aenlich klingen, aber es ist ein anderer gedanke dahinter.
ne JPG-artige kompression koennte man heutzutage ebenfalls sehr leicht in hardware giessen, DXT suckt gerade an weichen farbverlaeufen, dafuer koennte man DCT/iDCT sehr gut nutzen. quasi als komplementaer kompressions format. da das komprimieren blockweise ist, koennte man ebenfalls sehr gut mittels hardware darauf indizieren.
Apropos. Es gibt ein nVIDIA-D3D10-Demo das on-the-fly auf der GPU JPEG entpackt.
Aber das Problem bei JPEG ist, dass man schlecht weiß wo die Blöcke sind, weil sie eben verschieden groß sind.
micki
2007-07-17, 09:27:51
Apropos. Es gibt ein nVIDIA-D3D10-Demo das on-the-fly auf der GPU JPEG entpackt.nein gibt es nicht, nur iDCT und YCbCr->RGB
Aber das Problem bei JPEG ist, dass man schlecht weiß wo die Blöcke sind, weil sie eben verschieden groß sind.
deswegen wuerde man die entropiekodierung bei der sache weglassen und einfach nur blockweise komprimieren.
nein gibt es nicht, nur iDCT und YCbCr->RGB
Mmkay. Ich hab's mir nicht so genau angeschaut.
deswegen wuerde man die entropiekodierung bei der sache weglassen und einfach nur blockweise komprimieren.
Wäre das dann wirklich mit vertretbarer Qualität möglich?
deswegen wuerde man die entropiekodierung bei der sache weglassen und einfach nur blockweise komprimieren.Wie sieht das bei 2 bpt (Bit pro Texel) aus? JPEG erreicht mit Ach und Krach 1 bpp (Bit pro Pixel), aber nur mit allen Tricks wie Entropiekodierung und Farbsubsampling, und relativ großen Blöcken bei der Y-Komponente (8x8.) Da man im ungünstigsten Fall beim Texturieren vier Blöcke gleichzeitig braucht, müssten dann immer 256 dekomprimierte Texel im Speicher liegen, statt wie bisher 64 (4 Blöcke à 4x4 Texel.)
Geht man davon aus, dass die Adressierung einem POT-Schema (Power-of-Two) folgen sollte, sind Verfahren mit 3 bpt nutzlos. Man müsste gleich auf 2 bpt kommen, was jedoch in vielen Fällen nicht mehr ausreichend ist. Die Packman-Texturkomprimierung http://www.cs.lth.se/home/Tomas_Akenine_Moller/pubs/packman_sketch.pdf arbeitet bei Blöcken von 4x2 mit 4 bpt und würde bei 4x4-Blöcken nur 3 bpt beanspruchen, allerdings ist fraglich ob die Qualität dann noch ausreicht – und wie gesagt wären solche Verfahren hässlich in der Adressierung.
micki
2007-07-17, 14:06:20
Wäre das dann wirklich mit vertretbarer Qualität möglich?
wenn man es wirklich fuer "weiche" texturen benutzen will und dxt weiterhin fuer die hochfrequenten, kann man mit DCT/iDCT sehr gut arbeiten. gutes beispiel waere z.b. die blendlayer fuers terrain, wenn man dxt verwendet und an einer stelle 3layer sehr abwechslungsreich sind (rgb) dann entsteht ziemlich blockiges blenden zwischen layern. alternativ nimmt man halt r8g8b8(a8) aber das zieht nun wieder viel mehr speicher. wenn man dafuer DCT/iDCT nutzen wuerde, koennte man die weichen uebergaenge haben.
wenn man es wirklich fuer "weiche" texturen benutzen will und dxt weiterhin fuer die hochfrequenten, kann man mit DCT/iDCT sehr gut arbeiten. gutes beispiel waere z.b. die blendlayer fuers terrain, wenn man dxt verwendet und an einer stelle 3layer sehr abwechslungsreich sind (rgb) dann entsteht ziemlich blockiges blenden zwischen layern. alternativ nimmt man halt r8g8b8(a8) aber das zieht nun wieder viel mehr speicher. wenn man dafuer DCT/iDCT nutzen wuerde, koennte man die weichen uebergaenge haben.PVRTC bietet eine 2-Bit-Komprimierung für weiche Übergänge ohne Fouriertransformationen. http://web.onetel.net.uk/~simonnihal/3d.html
Mr. Lolman
2007-07-17, 14:23:51
Die Packman-Texturkomprimierung arbeitet bei Blöcken von 4x2 mit 4 bpt und würde bei 4x4-Blöcken nur 3 bpt beanspruchen, allerdings ist fraglich ob die Qualität dann noch ausreicht
Die Qualität von Packman ist bei 4x2 Blöcken schon schlechter als S3TC.
Vom Qualitätsstandpunkt würd ich eher eine YCbCr Kompression mit Farbsubsampling verwenden, wofür sich ATI1N und ATI2N anbieten. Damit man aber in die Nähe der Größe von S3TC kommt, dürfte man CbCr nur mehr als 4x4 Blöcke abspeichern, was dann wiederum oft sichbares Colorbleeding enstehen liesse.
Trotzdem würds imo häufig besser als S3TC aussehen...
micki
2007-07-17, 14:25:59
Wie sieht das bei 2 bpt (Bit pro Texel) aus? JPEG erreicht mit Ach und Krach 1 bpp (Bit pro Pixel), aber nur mit allen Tricks wie Entropiekodierung und Farbsubsampling, und relativ großen Blöcken bei der Y-Komponente (8x8.)
das ist mein bild http://img149.imageshack.us/img149/7580/lenauj8.png
mit sehr grossen bloecken (hab kein kleiners vorliegen) ich speicher nur koefizienten von x+y<24 (also 300stuck) beim 64*64 block (pro channel bei 16Y1Cb1Cr,also 16luminanzpixel pro 1chrominanzpixel).
an kontrastreichen stellen sieht man zwar artefakte, aber bei weichen uebergaengen (siehe spiegel) ist es doch garnicht so schlecht.
Da man im ungünstigsten Fall beim Texturieren vier Blöcke gleichzeitig braucht, müssten dann immer 256 dekomprimierte Texel im Speicher liegen, statt wie bisher 64 (4 Blöcke à 4x4 Texel.)bei Dct koennte man auch mit 4x4 arbeiten, aber 8*8 oder 16*16 sollten nicht so dramatisch schlecht sein.
Geht man davon aus, dass die Adressierung einem POT-Schema (Power-of-Two) folgen sollte, sind Verfahren mit 3 bpt nutzlos. Man müsste gleich auf 2 bpt kommen, was jedoch in vielen Fällen nicht mehr ausreichend ist.
nicht zwangsweise, solange die bloecke statische groessen haben, waere eine etwas flexiblere indizierung moeglich,man muesste schauen wie man die dann organisiert, z.b. hat man CbCr runterskaliert, somit koennte man davon ausgehen dass 4Y (bzw 16Y)bloecke+2chrominanz am ende alligned sind damit sie ein guenstiges allignment im vram haben. dann hat man schon ne "krumme" zahl von bytes pro block.
Die Packman-Texturkomprimierung arbeitet bei Blöcken von 4x2 mit 4 bpt und würde bei 4x4-Blöcken nur 3 bpt beanspruchen, allerdings ist fraglich ob die Qualität dann noch ausreicht – und wie gesagt wären solche Verfahren hässlich in der Adressierung.
ich glaube solche verfahren haetten einiges an potential, zum einen laesst sich iDCT dank FFT gut parallel ausfuehren, zum anderen hat das system das potential variable kompressionen zu haben (fix pro textur, aber jede textur koennte anders stark komprimiert sein, der witz ist ja sogar dass mit staerkerer kompression->weniger coefizienten->schnellere dekompression moeglich waere).
zudem koennte man aus den coefizienten, bei so smoothen texturen, eventuell die mipmaps aus den selben daten generieren ohne sie extra abspeichern zu muessen... das muesste ich nochmal ausprobieren :)
Die Qualität von Packman ist bei 4x2 Blöcken schon schlechter als S3TC.
Vom Qualitätsstandpunkt würd ich eher eine YCbCr Kompression mit Farbsubsampling verwenden, wofür sich ATI1N und ATI2N anbieten. Damit man aber in die Nähe der Größe von S3TC kommt, dürfte man CbCr nur mehr als 4x4 Blöcke abspeichern, was dann wiederum oft sichbares Colorbleeding enstehen liesse.
Trotzdem würds imo häufig besser als S3TC aussehen...Was ist ATI1N und ATI2N? (Links?)
Packman liefert bei 4x2-Blöcken bei guter Komprimierung schon erstaunliche Qualität bei normalen Fotos, ist allerdings nicht so vielseitig verwendbar wie S3TC.
YCbCr-Umwandlung ist nicht unproblematisch, da man effektiv zwei Bit Farbauflösung verliert (nur ca. 1/4 des YCbCr-Raumes (Achsen von 0..1) liegen im RGB-Würfel.) Farbsubsampling verschlechtert die Allzweck-Verwendbarkeit (worunter auch Packman leidet.)
das ist mein bild http://img149.imageshack.us/img149/7580/lenauj8.png
mit sehr grossen bloecken (hab kein kleiners vorliegen) ich speicher nur koefizienten von x+y<24 (also 300stuck) beim 64*64 block (pro channel bei 16Y1Cb1Cr,also 16luminanzpixel pro 1chrominanzpixel).
an kontrastreichen stellen sieht man zwar artefakte, aber bei weichen uebergaengen (siehe spiegel) ist es doch garnicht so schlecht.
bei Dct koennte man auch mit 4x4 arbeiten, aber 8*8 oder 16*16 sollten nicht so dramatisch schlecht sein.
nicht zwangsweise, solange die bloecke statische groessen haben, waere eine etwas flexiblere indizierung moeglich,man muesste schauen wie man die dann organisiert, z.b. hat man CbCr runterskaliert, somit koennte man davon ausgehen dass 4Y (bzw 16Y)bloecke+2chrominanz am ende alligned sind damit sie ein guenstiges allignment im vram haben. dann hat man schon ne "krumme" zahl von bytes pro block.
ich glaube solche verfahren haetten einiges an potential, zum einen laesst sich iDCT dank FFT gut parallel ausfuehren, zum anderen hat das system das potential variable kompressionen zu haben (fix pro textur, aber jede textur koennte anders stark komprimiert sein, der witz ist ja sogar dass mit staerkerer kompression->weniger coefizienten->schnellere dekompression moeglich waere).
zudem koennte man aus den coefizienten, bei so smoothen texturen, eventuell die mipmaps aus den selben daten generieren ohne sie extra abspeichern zu muessen... das muesste ich nochmal ausprobieren :)Alles nicht notwendig da PVRTC vergleichbare (oder bei scharfen Kontrasten deutlich bessere) Ergebnisse bei geringeren Kosten und Blockgrößen bietet. MIP-Maps nehmen kaum Speicherplatz ein, On-The-Fly-Generierung dürfte bei hohen MIP-Stufen schwieriger werden. Willst du primär Farbverläufe speichern, also unscharfe Texturen, reicht auch eine kleinere Texturauflösung.
Die YCbCr-Umwandlung ist wie gesagt nicht unproblematisch (Verlust von Farbauflösung.) Farbsubsampling verschlechtert die allgemeine Verwendbarkeit was den Content angeht. Nicht immer hat man Fototexturen.
Demirug
2007-07-17, 14:32:14
Was ist ATI1N und ATI2N? (Links?)
Das sind die 3Dc Formate oder bei D3D10 BC4 und BC5.
Das sind die 3Dc Formate oder bei D3D10 BC4 und BC5.Also 1- und 2-Kanal-Graustufen-Kodierung (à la DXT5-Alpha) mit 4 bpt?
micki
2007-07-17, 14:38:52
Alles nicht notwendig da PVRTC vergleichbare (oder bei scharfen Kontrasten deutlich bessere) Ergebnisse bei geringeren Kosten und Blockgrößen bietet. MIP-Maps nehmen kaum Speicherplatz ein, On-The-Fly-Generierung dürfte bei hohen MIP-Stufen schwieriger werden. Willst du primär Farbverläufe speichern, also unscharfe Texturen, reicht auch eine kleinere Texturauflösung.speicher dir ein bild mit entsprechendem speicherverbrauch (etwa 300:4096,also ca 128*128) und skalier das wieder auf 512*512, du wirst sehen es sieht weit schlechter aus als was DCT bietet und DXT kannst du da auch nicht verwenden, eben wegen dem weichen farbverlauf.
Die YCbCr-Umwandlung ist wie gesagt nicht unproblematisch (Verlust von Farbauflösung.) Farbsubsampling verschlechtert die allgemeine Verwendbarkeit was den Content angeht. Nicht immer hat man Fototexturen.
genau wie dxt nicht fuer alle texturen nutzbar ist, so ist es DCT auch nicht, es waere nur eine ergaenzung wie ich schon sagte.
micki
2007-07-17, 14:40:23
Also 1- und 2-Kanal-Graustufen-Kodierung (à la DXT5-Alpha) mit 4 bpt?
so in etwa
speicher dir ein bild mit entsprechendem speicherverbrauch (etwa 300:4096,also ca 128*128) und skalier das wieder auf 512*512, du wirst sehen es sieht weit schlechter aus als was DCT bietet und DXT kannst du da auch nicht verwenden, eben wegen dem weichen farbverlauf. S3TC kann man bei weichen Farbverläufen gut gebrauchen. Enthält die Textur nur weiche Verläufe, kann man wie gesagt auch deren räumliche Auflösung senken.
genau wie dxt nicht fuer alle texturen nutzbar ist, so ist es DCT auch nicht, es waere nur eine ergaenzung wie ich schon sagte.Man kann nicht beliebig viele TC-Algos in Hardware gießen, schon gar nicht so aufwändige die auf FFT basieren. S3TC ist für alles gut. Lade dir doch mal eine Tool (da gibts von NV und von ATI was) und probiere sie aus. Fotos werden in der Regel ohne wahrnehmbaren Qualitätsverlust gespeichert, ob es nun Farbverläufe sind oder es sich um hochfrequenten Content handelt. Nur vergrößern sollte man S3TC-komprimierte Texturen nicht unbedingt.
Anbetrachts der aktuellen Technik halte ich S3TC trotz seines Alters für ausoptimiert. Man sollte jetzt lieber TC-Verfahren für FP16- und FP32-Texturen entwickeln und in Hardware gießen.
micki
2007-07-17, 14:52:53
S3TC kann man bei weichen Farbverläufen gut gebrauchen. Enthält die Textur nur weiche Verläufe, kann man wie gesagt auch deren räumliche Auflösung senken.wie gesagt, bekommst du beim hochskalieren entsprechend artefakte von denen du bei DCT kaum etwas siehst, versuch es mal mit dem lenabild, skalier es dir auf 128*128 runter und wieder bilinear auf 512*512.
Man kann nicht beliebig viele TC-Algos in Hardware gießen, schon gar nicht so aufwändige die auf FFT basieren.wenn man vor 8jahren platz fuer dxt hatte, hate man heute sicher auch etwas platz fuer fft, wie geagt, in hardware ist das viel simpler als als cpu-code.
S3TC ist für alles gut. Lade dir doch mal eine Tool (da gibts von NV und von ATI was) und probiere sie aus. Fotos werden in der Regel ohne wahrnehmbaren Qualitätsverlust gespeichert, ob es nun Farbverläufe sind oder es sich um hochfrequenten Content handelt.ich hoffe das ist reine ironie, jeder weiss dass gerade photos bei DXT sehr leiden, besonders bei weichen farbverlaeufen.
which is 4bpp, looks good with most textures, but there are exceptions. DXT1 doesn't perform very well with photographical images
Packman wurde etwas weiterentwickelt zu ETC (Ericsson Texture Compression) und ist der einzige echte herstellerübergreifende Standard in OpenGL ES 2.0.
das ist mein bild http://img149.imageshack.us/img149/7580/lenauj8.png
mit sehr grossen bloecken (hab kein kleiners vorliegen) ich speicher nur koefizienten von x+y<24 (also 300stuck) beim 64*64 block (pro channel bei 16Y1Cb1Cr,also 16luminanzpixel pro 1chrominanzpixel).
an kontrastreichen stellen sieht man zwar artefakte, aber bei weichen uebergaengen (siehe spiegel) ist es doch garnicht so schlecht.
Ich finde es nicht gerade sinnvoll, einfach nur die hohen Frequenzen abzuschneiden. Da kann man auch schlicht die größte Mipmap weglassen. Lena in 2bpt PVRTC sieht jedenfalls besser aus.
Mr. Lolman
2007-07-17, 15:13:56
Lena in 2bpt PVRTC sieht jedenfalls besser aus.
Hast du da zufälligerweise auch nen Link parat?
Heute abend sollte ich dazu kommen das Bild hochzuladen.
War hier im Thread schonmal http://web.onetel.net.uk/~simonnihal/3d.html
Mr. Lolman
2007-07-17, 15:35:31
War hier im Thread schonmal http://web.onetel.net.uk/~simonnihal/3d.html
Da gibts aber kein Bild von Lena, oder überseh ich da was?
micki
2007-07-17, 16:06:46
Da gibts aber kein Bild von Lena, oder überseh ich da was?
das ist ein lustiges paper
z.b. meint der autor dass man statt die komponenten auf 8bit zu erweitern und dann zu interpolieren, erst interpolieren kann und dann auf 8bit erweitern, wir wissen ja alle wie dieser smarte trick bei GF1 bis GF3 mit dxt1 funktionierte *hehe*
An sich beschreibt das paper eine art Wavelet transformation, ein lowfrequenz bild mit einem highfrequenz anteil, seperat gespeichert und damit interpoliert man zwischen den lowfrequenz pixeln. gibt sehr viele moeglichkeiten wie das system ausserhalb seiner idealisierten testwelt "verkackt" *hehe*
und wegen den 5bit/pixel/channel kann man sich smoothe bilder genau wie bei dxt schenken.
Hm PowerVR hat das Ding aber anscheinend wirklich implementiert. Nur so als Anmerkung.
micki
2007-07-17, 16:22:08
Hm PowerVR hat das Ding aber anscheinend wirklich implementiert. Nur so als Anmerkung.
um wirklich zu beurteilen wie gut das aussieht, muesste man wirklich mal Lena sehen. zum einen scheint das quellmaterial schon artefakte zu haben (im paper) zum anderen wurden da echt stellen ausgesucht wo DXT seine defizite hat (smooth gradients und r g b die ineinander blenden).
Lena in PVRTC 2bpp (http://www.xm45.de/pic/LenaPVRTC2.png)
Lena in PVRTC 4bpp (http://www.xm45.de/pic/LenaPVRTC4.png)
Bild von hier: http://en.wikipedia.org/wiki/Standard_test_image
das ist ein lustiges paper
z.b. meint der autor dass man statt die komponenten auf 8bit zu erweitern und dann zu interpolieren, erst interpolieren kann und dann auf 8bit erweitern, wir wissen ja alle wie dieser smarte trick bei GF1 bis GF3 mit dxt1 funktionierte *hehe*
Da bezieht er sich auf den ersten Interpolationsschritt, der bei S3TC gar nicht existiert. *hehe*
und wegen den 5bit/pixel/channel kann man sich smoothe bilder genau wie bei dxt schenken.
Wie "smooth" solls denn sein? Weiche Farbverläufe funktionieren eigentlich ganz gut.
micki
2007-07-18, 09:39:48
Da bezieht er sich auf den ersten Interpolationsschritt, der bei S3TC gar nicht existiert. *hehe*ich dachte das bezieht sich auf die interpolation fuer die farbpalette.
Lena in PVRTC 2bpp (http://www.xm45.de/pic/LenaPVRTC2.png)
Lena in PVRTC 4bpp (http://www.xm45.de/pic/LenaPVRTC4.png)
Wie "smooth" solls denn sein? Weiche Farbverläufe funktionieren eigentlich ganz gut.beim 2bit bild sind die farbverlaeufe (siehe schulter) irgendwie besser als beim 4bit bild(wohl wegen der noch kleiner aufgeloesten grud-textur), dafuer schaut es sehr kaputt aus an den scharfen kanten. beim 4bit genau andersrum, kanten sind sehr genau, aber der farbverlauf zeigt doch schon banding, der dither/noise effekt macht das ein wenig weg.
aber fuer 2bit (bzw4) schaut es schon sehr gut aus
aber fuer 2bit (bzw4) schaut es schon sehr gut ausUnd besser als die vorgeschlagene DCT-Variante. Bei kleineren Blockgrößen lohnt es nicht, im Frequenzraum zu arbeiten.
das ist ein lustiges paper
z.b. meint der autor dass man statt die komponenten auf 8bit zu erweitern und dann zu interpolieren, erst interpolieren kann und dann auf 8bit erweitern, wir wissen ja alle wie dieser smarte trick bei GF1 bis GF3 mit dxt1 funktionierte *hehe*Lies das Paper noch mal =)
An sich beschreibt das paper eine art Wavelet transformation, ein lowfrequenz bild mit einem highfrequenz anteil, seperat gespeichert und damit interpoliert man zwischen den lowfrequenz pixeln. gibt sehr viele moeglichkeiten wie das system ausserhalb seiner idealisierten testwelt "verkackt" *hehe*Wavelet? Nee. PVRTC tut im Wesentlichen das gleiche wie S3TC: Ein Signal mit hoher räumlicher Auflösung, aber geringer Quantisierung gibt die Interpolations-Gewichte zwischen zwei Signalen mit geringer räumlicher Auflösung, aber feiner Quantisierung an. Der Trick dabei ist, dass die Quantisierung des hochfrequenten Anteils an den Kontrast im Block angepasst wird. Somit wird der Rauschabstand zwar verkleinert, aber auch ausgenutzt dass unser Auge bei hohen Amplituden keine feine Quantisierung benötigt. Das wird bei JPEG auch genutzt. Dort werden bekanntlich die DCT-Koeffizienten in einer Zickzack-Linie ausgelesen und aufgereiht, und die hohen Frequenzen werden besonders grob quantisiert.
Packman speichert pro Block nur eine Farbe und das hochfrequente Signal moduliert lediglich die Helligkeit. (Aufgrund der Rechenweise mit RGB-Additionen stimmt das nicht ganz, es kann auch zur Farbtonänderung kommen, das ist allerdings nicht unbedingt gewollt.) Ein zweiter Trick bei Packman ist, dass bei der Helligkeitsänderung nicht Min und Max gespeichert werden, sondern dass ein Zeiger auf einen (im Decoder-Algo festverdrahteten) Tabelleneintrag gespeichert wird.
und wegen den 5bit/pixel/channel kann man sich smoothe bilder genau wie bei dxt schenken.Das ist übertrieben. Es werden ja noch zwei weitere Interpolationsfarben berechnet, mit mehr als fünf Bit. Lediglich bei Bildern mit reinen Farbtönen und sehr sanften, oder unbunten Helligkeitsverläufen könnte man vielleicht Nachteile bekommen. Selbst dann ist S3TC oder PVRTC in der Regel gut genug.
ich dachte das bezieht sich auf die interpolation fuer die farbpalette.
Er bezieht sich auf die bilineare Interpolation der beiden Referenzfarben, die bei S3TC ja im ganzen Block konstant sind. Die zwei zusätzlichen Zwischenfarben werden dann mit 8 Bit generiert.
vBulletin®, Copyright ©2000-2025, Jelsoft Enterprises Ltd.