Archiv verlassen und diese Seite im Standarddesign anzeigen : Farb-Subsampling
Ich hab mal einige Experimente durchgeführt. Hintergrund sind Überlegungen, bei Texturen Platz zu sparen. Erste Idee ist ja, einfach nur gering aufgelöste Texturen zu nehmen, und zweite, an der Farbinformation zu sparen. Doch wir wollen ja alle maximales Texturdetails, und wenn möglich, kein Banding durch 16 Bit. Als Beispiel dient uns zunächst folgende Blüte:
http://www.aths.de/files/subsampling/Lagos03w.jpg
Überlegung: Bei RGB die RB-Werte nur halb so hoch aufzulösen wie G. Um die Ergebnisse besser sichtbar zu machen, hab ich aber gleich mal pro 8x8-Tile nur einmal RB (und zwar den Mittelwert des Tiles) aber pro Pixel G gespeichert.
http://www.aths.de/files/subsampling/Bild1.jpg
Nun, da hat man jetzt natürlich eine Kachelstruktur. Die bekommt man einigermaßen weg, wenn die RB-Kanäle bilinear gefiltert werden:
http://www.aths.de/files/subsampling/Bild2.jpg
Doch damit wird das gesamte Bild auch schön hässlich unscharf. Lassen wir das mit der Filterung mal, und nehmen lieber ein anderes Farbmodell. Und zwar YCbCr. Y (Helligkeit) wird voll aufgelöst, CbCr (Farbanteil) nur pro 8x8-Kachel mit einem einzigen Wert:
http://www.aths.de/files/subsampling/Bild3.jpg
Erstaunlich, nicht wahr? Treiben wir das höher, auf 16x16:
http://www.aths.de/files/subsampling/Bild4.jpg
Aha, nun haben wir "endlich" doch unsere sichtbaren Kacheln. Versuchen wir es trotz zu befürchtender Unschärfe mit bilinearer Filterung des CbCr-Anteils:
http://www.aths.de/files/subsampling/Bild5.jpg
Das Ergebnis ist duchaus akzeptabel, wenn man bedenkt, dass nur alle 256 Pixel eine Farbe gespeichert wird, und lediglich die Helligkeit pixelgenau aufgelöst wurde.
Muh-sagt-die-Kuh
2005-03-27, 13:39:10
Ich hab mal einige Experimente durchgeführt. Hintergrund sind Überlegungen, bei Texturen Platz zu sparen. Erste Idee ist ja, einfach nur gering aufgelöste Texturen zu nehmen, und zweite, an der Farbinformation zu sparen. Doch wir wollen ja alle maximales Texturdetails, und wenn möglich, kein Banding durch 16 Bit. Als Beispiel dient uns zunächst folgende Blüte:
Überlegung: Bei RGB die RB-Werte nur halb so hoch aufzulösen wie G. Um die Ergebnisse besser sichtbar zu machen, hab ich aber gleich mal pro 8x8-Tile nur einmal RB (und zwar den Mittelwert des Tiles) aber pro Pixel G gespeichert.RBG ist für Farb-Subsampling völlig unbrauchbar, da jeder Kanal Farb- und Helligkeitsinformationen enthält.Lassen wir das mit der Filterung mal, und nehmen lieber ein anderes Farbmodell. Und zwar YCbCr. Y (Helligkeit) wird voll aufgelöst, CbCr (Farbanteil) nur pro 8x8-Kachel mit einem einzigen Wert.
Das Ergebnis ist duchaus akzeptabel, wenn man bedenkt, dass nur alle 256 Pixel eine Farbe gespeichert wird, und lediglich die Helligkeit pixelgenau aufgelöst wurde.In der korrekten Notation ist das 8:1:0 Farbsubsampling.....eine, meiner Meinung nach, recht heftige Unterabtastung.
In der Welt der digitalen Videospeicherung wird meist 4:2:0 (z.B. DVD) oder 4:1:1 (DV) eingesetzt, das ist so in etwa die Grenze die das menschliche Auge noch ohne Nachbearbeitung als fehlerfrei wahrnimmt. Profi-Formate arbeiten entweder ohne Subsampling (4:4:4) oder mit 4:2:2 Subsampling.
Angaben zum Speicherplatzverbrauch deiner Testbilder wären noch interessant, ebenso die Verträglichkeit mit gebräuchlichen Kompressionsmethoden wie DXT1.
RBG ist für Farb-Subsampling völlig unbrauchbar, da jeder Kanal Farb- und Helligkeitsinformationen enthält.In der korrekten Notation ist das 8:1:0 Farbsubsampling.....eine, meiner Meinung nach, recht heftige Unterabtastung.
In der Welt der digitalen Videospeicherung wird meist 4:2:0 (z.B. DVD) oder 4:1:1 (DV) eingesetzt, das ist so in etwa die Grenze die das menschliche Auge noch ohne Nachbearbeitung als fehlerfrei wahrnimmt. Profi-Formate arbeiten entweder ohne Subsampling (4:4:4) oder mit 4:2:2 Subsampling.Selbst Profi-Video (also digitales Video in Studio-Qualität) subsampelt die Farbe im Verhältnis 1:2. JFIF Jpeg speichert pro 2x2-Tile nur eine Farbe. Also scheint Farbsubsampling allgemein akzeptiert. Ich bin der Meinung, dass das man das noch weiter treiben kann – für mittlere Qualität bei JPEG wären 4x4-Tiles für Farbe noch völlig ok – wenn man denn die Farbinformation interpoliert, um die bekannte JPEG-Blockartefakte zu minimieren.
Angaben zum Speicherplatzverbrauch deiner Testbilder wären noch interessant, ebenso die Verträglichkeit mit gebräuchlichen Kompressionsmethoden wie DXT1.Ich rechne Y, Cb und Cr mit jeweils 8 Bit. Das heißt, pro Pixel 8 Bit Helligkeit und pro Tile noch mal 16 Bit für die Farbe.
S3TC ist vom Format her kaum noch verbesserbar. Man hat zwei große Vorteile: Völlig unabhängige Tiles, und auch noch kleine Tiles. Und S3TC erreicht eine Datenrate von 4 Bit pro Texel, das ist sehr gut. Simon Fenney (von PowerVR) empfiehlt in einem Paper, die Farbinformation bei Texturinformationen zu interpolieren. Das vermeidet die Blockartefakte, aber bei 4 Bit pro Texel ist sein Verfahren insgesamt kaum besser als S3TC. Seine Version mit 2 Bit pro Texel ist nur in Ausnahmefällen zu gebrauchen.
Simon Fenney empfiehlt eine niederfrequente Information für die "Basis" und ein hochfrequentes, aber mit geringer Präzision aufgelöstes Modulationssignal zwischen hellster und dunkelster Farbe. S3TC funktioniert ähnlich, aber ohne die niederfrequente Information bilinear zu filtern.
Ich denke man scheute bisher die Schaltkreise zur YCbCr->RGB Umwandlung. Das ganze wäre schon sinnvoll.
Man könnte ja auch noch die Helligkeit interpolieren ala DXT. Könntest du noch nen Bild machen wo das gemacht wird? Also Helligkeit nur mit einem viertel Auflösung.
Ich denke man scheute bisher die Schaltkreise zur YCbCr->RGB Umwandlung. Das ganze wäre schon sinnvoll.
Man könnte ja auch noch die Helligkeit interpolieren ala DXT. Könntest du noch nen Bild machen wo das gemacht wird? Also Helligkeit nur mit einem viertel Auflösung.Das größere Problem sehe ich in der Speicherung der Farbe. Die bräuchte man pro "Ecke" des Tiles, um die Farbe dann bilinear interpolieren zu können. Damit wären die Tiles nicht mehr völlig unabhängig dekomprimierbar. So oder so kommt man nicht deutlich unter 4 Bit pro Texel. Dafür müsste man schon die Tiles vergrößern. Das ist aber machbar, weil YCbCr, wie man sieht, generell auch mit größeren Tiles noch ganz gut arbeitet (jedenfalls bei Fotos, es lassen sich auch Bildinhalte finden wo es nicht so gut ist.) Doch je größer die Tiles, desto aufwändiger die Dekomprimierung, und desto größere Anforderungen an den Cache.
Eine Idee die ich habe, ist, pro Ecke nicht nur Farbe, sondern auch Helligkeit zu speichern, um den groben Farb- und Helligkeitsverlauf zu haben. Darauf aufbauend kann das hochfrequente Signal besonders grob aufgelöst sein. Man sollte zudem nichtlineare Quantisierung erwägen. Doch das alles kostet Schaltkreise.
DXT speichert doch auch eine Farbe pro Ecke.
Ich denke man scheute bisher die Schaltkreise zur YCbCr->RGB Umwandlung. Das ganze wäre schon sinnvoll.
Man könnte ja auch noch die Helligkeit interpolieren ala DXT. Könntest du noch nen Bild machen wo das gemacht wird? Also Helligkeit nur mit einem viertel Auflösung.Die Interpolation wird natürlich schon länger in der TMU gemacht, die Farbraumumwandlung im Pixelshader. HW-Kosten fallen da kaum an.
Texturdekompression sollte man wirklich nicht in den PixelShader verlagern. Dann braucht man wieder für jedes Texturformat verschiedene Shader. Nicht gut.
Wobei es mit SM 3.0 und Static Branching wohl nicht ganz so schlimm wäre.
DXT speichert doch auch eine Farbe pro Ecke.Nee, zwei Farben pro Tile.
Die Interpolation wird natürlich schon länger in der TMU gemacht, die Farbraumumwandlung im Pixelshader. HW-Kosten fallen da kaum an.Drei mal DP3. Sind selbst beim NV40 3 Takte. Sofern man eine zusätzliche Textur hat, die 2x trilineares AF bekommt, können die Kosten natürlich versteckt werden.
Mr. Lolman
2005-03-27, 18:48:09
Angaben zum Speicherplatzverbrauch deiner Testbilder wären noch interessant, ebenso die Verträglichkeit mit gebräuchlichen Kompressionsmethoden wie DXT1.
Naja wenn man die 16x16 Tiles von CbCr jew unkomprimiert in ne 8bit Textur speichert (bei einem Verhältnis 1:16 sind die Texturen eh schon fast zu klein zum komprimieren und brauchen ohnehin noch kaum Platz) und y in der vollen Auflösung in ne weitere 8bit Textur speichert, reichen ~34% der Originalgrösse, wovon 33.33% für die Helligkeit draufgehen und 0.26% für die Farbinformationen [2*((100/3)/256) + (100/3) = ~33.6]
Blöderweise müsste man, damit sich das im Vergleich zur DXT Kompression lohnt, auch die Lightmaps komprimieren, was einem zumindest bei rot und blau die Textur total zamhaut...
Aber:
Nehmen wir 6 512x512 Texturen à 1MB für ne Skybox. Folgende Möglichkeiten tun sich da auf:
1. Original unkomprimiert = 6MB (1MB x6)
http://img200.exs.cx/img200/879/skyday0306rt1lg.png (http://www.imageshack.us)
2. DXT1 komprimiert = 768kB (128kB x6)
http://img200.exs.cx/img200/1593/skyday0306rtdxt12te.png (http://www.imageshack.us)
3. YCbCr (16:2:0) = 1548kB ((256kB (512x512 8bit Lightmap) + 2x1kB (Cb,Cr) x6)
http://img200.exs.cx/img200/3102/skyday0306rtycbcr4uj.png (http://www.imageshack.us)
Man braucht bei unkomprimiertem YCbCr (16:2:0) zwar doppelt soviel Platz wie mit DXT Komprimierung, hat aber auch die bessere BQ. Nun kann man natürlich jew. 2 Lightmaps zusammenfassen und als eine DXT5 in den Green/Alpha Channel speichern:
4: YCbCr (16:2:0), Y-DXT5(G): 780kB (3x256kB+6x2kB)
http://img193.exs.cx/img193/6351/skyday0306rtycbcrdxt1g8al.png (http://www.imageshack.us)
Natürlich kann man das noch weiter optimieren und den bei ner Skybbox normalerweise nicht sichtbaren Boden als R oder B mit ner anderen Textur (bspw Decke) als G in ne DXT1 Textur knallen, und nochmal 128kB sparen und somit weniger verbrauchen als beim DX1 verfahren, aber jetzt wirds schon ;)
Qualitativ würd ich die Verfahren so reihen: 1-3-4-2, zumindest ergibt das mein Vergleich mit HL² Texturen.
Wenn man halt harte Farbwechsel hat ist die Methode überfordert. DXT funktioniert halt fast immer.
Wenn man halt harte Farbwechsel hat ist die Methode überfordert. DXT funktioniert halt fast immer.Ja, S3TC ist eine erstaunlich gute Methode, trotz der ziemlich simplen Speicherung. Die S3TC-Komprimierung zu optimieren würde vielleicht mehr bringen, als sich neue TC-Speicherverfahren ausdenken. Trotzdem werde ich im Laufe der nächsten Zeit versuchen, auf YCbCr-Basis mir eine TC zu überlegen.
Mr. Lolman
2005-03-27, 20:42:35
Wenn man halt harte Farbwechsel hat ist die Methode überfordert. DXT funktioniert halt fast immer.
Jupp.
unkomprimiert:
http://img193.exs.cx/img193/1851/stepanel5ablud8ov.jpg (http://www.imageshack.us)
YCbCr (16:2:0):
http://img130.exs.cx/img130/4476/stepanel5abluycbcr8gb.jpg (http://www.imageshack.us)
Hast du eigentlich das Program von aths?
Mr. Lolman
2005-03-27, 21:03:01
Hast du eigentlich das Program von aths?
Hm? Die Bilder hab ich mit Photoshop gebastelt...
Mit 4:2:0 (bzw. 4:1:1 :|) siehts eigentlich ganz ok aus:
http://img57.exs.cx/img57/3302/stepanel5abluycbcr40pf.jpg (http://www.imageshack.us)
Mit 4:2:0 (bzw. 4:1:1 :|) siehts eigentlich ganz ok aus:
/edit: Im direkten Vergleich doch nicht wirklich. Man bräuchte halt ein Tool welches den mittleren Kontrast bei Farbübergängen misst und anhand des Ergebnisses entscheidet, ob ne YCbCr Kompression überhaupt lohnen würde. Um die Fehlerquote zu minimieren müsste man eigentlich jede Textur in min 4 Tiles aufspalten und den Kontrastwert für jedes einzelne Tile bestimmen. Ob sich da der Aufwand noch lohnt? (Nochdazu wo die Skyboxtextur oben, DXT1 schon übel mitspielt, und die DXT Qualität im Durchschnitt eher besser ist)
Man bräuchte halt ein Tool welches den mittleren Kontrast bei Farbübergängen misstDas sollte auch der Artist noch hinbekommen ;)
Äh wie konvertierst du in Photoshop was in YCbCr?
Hast du eigentlich das Program von aths?Das bezweifel ich :) Mein Programm hierzu ist eine Erweiterung zu einem anderen meiner Programme, wobei einiges noch fehlerhaft implementiert ist. Wenn ich das gefixt habe (sind mehrere Bugs) kann ich das Teil mal zum DL zur Verfügung stellen. Dann wird hoffentlich auch S3TC vollständig funzen (beim Runden auf 5:6:5 der Ref-Farben ist noch ein Fehler drin.)
Mr. Lolman
2005-03-27, 21:29:02
Äh wie konvertierst du in Photoshop was in YCbCr?
Lab Color :redface:
Hm? Die Bilder hab ich mit Photoshop gebastelt...
Mit 4:2:0 (bzw. 4:1:1 :|) sieht eigentlich ganz ok aus:
http://img57.exs.cx/img57/3302/stepanel5abluycbcr40pf.jpg (http://www.imageshack.us)
/edit: Im direkten Vergleich doch nicht wirklich. Man bräuchte halt ein Tool welches den mittleren Kontrast bei Farbübergängen misst und anhand des Ergebnisses entscheidet, ob ne YCbCr Kompression überhauupt lohnen würde. Um die Fehlerquote zu minimieren müsste man eigentlich jede Textur in min 4 Tiles aufspalten und den Kontrastwert für jedes einzelne Tile bestimmen. Ob sich da der Aufwand noch lohnt? (Nochdazu wo die Skyboxtextur oben, DXT1 schon übel mitspielt, und die DXT Qualität im Durchschnitt eher besser ist)Es wäre technisch natürlich möglich, pro Tile zu gucken ob DXT1 oder eine andere Methode. Allerdings müsste dazu pro Tile auch der Typ gespeichert werden. DXT1 lässt da kein Bit ungenutzt. Jede beliebige Bitfolge von 64 Bit kann als gültige DXT-Kachel interpretiert werden. Und das Texturformat kann man in DX nur pro Textur setzen. Da bräuchte man also einen extra-Typ, der das Mischen von Tiles erlaubt.
Nun sollten alle Tiles die gleiche Größe aufweisen. Wenn man mit YCbCr spielt, bleibt es bei 4x4 Texeln und 4 Bit pro Texel – man müsste dann "nur" eben deutlich besser als DXT1 sein – aber bei ansonsten weiterhin voneinander unabhängigen Tiles ist das schwierig. Bei solchen kleinen Farbtupfern wie in deinem Bild lohnt Color Subsampling natürlich nicht.
Mr. Lolman
2005-03-27, 21:58:08
Hm, na so hab ich das garnicht gemeint. Denn auch der mittlere Kontrast (der Farbübergänge) ist doch recht niedrig, wenn das Bild fast einfärbig ist, wie bei meinem Letzten. Da könnte der Algorithmus, schon mal falsch entscheiden (ob nun Colorsub oder doch DXT). Deswegen war mein Vorschlag, den Wert nicht 1x übers ganze Bild zu bestimmen sondern insgesamt gleich min 4x (von 4 verschiedenen Kacheln halt)
Wenn dann die Differenz zw. den Ergebnissen einen gewissen Wert nicht überschreitet, sollte Colorsub anwerndbar sein.
Oder muss man den Kontrast gar pixelweise bestimmen?
/edit: Ich gehe davon aus, dass dein Proggi Colorsubsampling für Texturen von 3D-Apps forcieren können wird, und spreche gerade mögliche Implementations Schwierigkeiten an. :D
Hm, na so hab ich das garnicht gemeint. Denn auch der mittlere Kontrast (der Farbübergänge) ist doch recht niedrig, wenn das Bild fast einfärbig ist, wie bei meinem Letzten. Da könnte der Algorithmus, schon mal falsch entscheiden (ob nun Colorsub oder doch DXT). Deswegen war mein Vorschlag, den Wert nicht 1x übers ganze Bild zu bestimmen sondern insgesamt gleich min 4x (von 4 verschiedenen Kacheln halt)
Wenn dann die Differenz zw. den Ergebnissen einen gewissen Wert nicht überschreitet, sollte Colorsub anwerndbar sein.
Oder muss man den Kontrast gar pixelweise bestimmen?Mein Ansatz ist, die RGB-Differenzen auszuwerten und den durchschnittlichen Fehler pro Texel zu berechnen. Im Moment wichte ich die RGB-Werte nach ihrem Einfluss auf die Helligkeit. Aber das ist auch noch falsch, da ich die eigentlich im sRGB-Raum vorliegenden Werte erst mal nach echtes lineares RGB überführen müsste. Das jedoch kostet Leistung. Werde ich trotzdem noch einbauen.
/edit: Ich gehe davon aus, dass dein Proggi Colorsubsampling für Texturen von 3D-Apps forcieren können wird, und spreche gerade mögliche Implementations Schwierigkeiten an. :DNee. Ich experimentiere gerade herum, um ein Gefühl zu kriegen, in welche Richtung mal weitere Untersuchungen anstellen könnte, wenn ich "mein" Diplomarbeits-Thema schreiben darf. Eigentlich soll Texturfilterung das Hauptthema sein, was jedoch zugunsten von Textur-Speicherung etwas in den Hintergrund tritt. Zur Speicherung zählt auch Komprimierung. Da möchte ich entweder eine bessere Methode als DXT anbieten, oder aber ausführen, warum man insgesamt kaum was besseres als DXT1 haben kann.
Apropos Mipmapping. Das ist natürlich auch ein Problem oder?
Apropos Mipmapping. Das ist natürlich auch ein Problem oder?Wieso? Jede Textur wird zunächst unkomprimiert gespeichert. Dann wird jede MIP getrennt komprimiert.
edit: Natürlich ist die dann komprimierte MIP nicht identisch mit der "echten", also per 2x2-Blockfilter generierten MIP. Das Problem sehe ich aber bei jedem TC-Verfahren.
Naja bei 16x16 blöcken hast du Probleme mit der minimalen Mip Size.
Naja bei 16x16 blöcken hast du Probleme mit der minimalen Mip Size.Na die MIPs können dann ja unkomprimiert gespeichert werden. Größere Tiles als 8x8 halte ich für unrealisierbar bei heutiger Technik.
Demirug
2005-03-27, 23:06:14
Was hast du eigentlich immer mit deinem 2x2 Box Filter als echten Filter für Mipmaps?
Den nimmt man nur weil er eben schön schnell ist. Wenn man Mipmaps vorberechnet sollte man was ordentliches benutzten. Und bei Normalmaps dann auch mit renormalisierung arbeiten.
Mr. Lolman
2005-03-27, 23:09:28
Zur Speicherung zählt auch Komprimierung. Da möchte ich entweder eine bessere Methode als DXT anbieten, oder aber ausführen, warum man insgesamt kaum was besseres als DXT1 haben kann.
Wie wärs mit irgendwas JPG artigem?
Demirug
2005-03-27, 23:15:24
Wie wärs mit irgendwas JPG artigem?
Für Texturen ganz schlecht. Da braucht man Blöcke fester Größe und Kompression.
Wie wärs mit irgendwas JPG artigem?Zu aufwändig. Sowas mit DCT-Koeffizienten für den Low-Frequency-Anteil hatte ich mal überlegt (plus den hochfrequenten Anteil voller Auflösung, aber geringer Quantisierung, vielleicht auch nichtlinear gespeichert.) Das wird aber alles zu aufwändig, und deutlich unter 4 bpp wird man kaum kommen.
Was hast du eigentlich immer mit deinem 2x2 Box Filter als echten Filter für Mipmaps?
Den nimmt man nur weil er eben schön schnell ist. Wenn man Mipmaps vorberechnet sollte man was ordentliches benutzten. Und bei Normalmaps dann auch mit renormalisierung arbeiten.Normalmaps werde ich wahrscheinlich gar nicht betrachten.
Was für einen Filter würdest du denn für gute MIP-Map-Generierung bei Farb-Texturen vorschlagen?
Demirug
2005-03-27, 23:41:54
Normalmaps werde ich wahrscheinlich gar nicht betrachten.
Was für einen Filter würdest du denn für gute MIP-Map-Generierung bei Farb-Texturen vorschlagen?
Triangle ist recht gut. Aber auf jeden Fall jede Mipmap aus der Basismipmap erzeugen und nicht aus der nächst größeren. Den sonst reicht man die Rundungsfehler nach unten durch.
Triangle ist recht gut. Aber auf jeden Fall jede Mipmap aus der Basismipmap erzeugen und nicht aus der nächst größeren. Den sonst reicht man die Rundungsfehler nach unten durch.Wegen dem Rundungsfehler bin ich eigentlich Fan von Fast-Tri.
Was heißt jetzt "Triangle" bei dir?
Was ändert Fast-Tri daran wenn die Mipmaps Rundungsfehler haben? :|
Was ändert Fast-Tri daran wenn die Mipmaps Rundungsfehler haben? :|Die MIPs werden alle aus der Basemap erstellt. Weil man bei Fast-Tri nur aus der hoch aufgelösten MIPs der beiden eigentlichen MIPs filtert, hat man bei vernünftiger Implementierung im Vergleich zum normalen TF weniger Fehler.
Klar, man hat eine Mip weniger Fehler, aber das reißt's auch nicht raus.
Klar, man hat eine Mip weniger Fehler, aber das reißt's auch nicht raus.Es ist bei entsprechender Implementierung aber schneller als herkömmliches tri, und als Bonus noch ein wenig genauer. Mit zwei bilinearen TMUs wäre man natürlich noch etwas flexibler. So oder so, ich hätte gern single clock trilinear filtering pro Pipe.
Demirug, was meinst du mit "Triangle" bezüglich MIP-Map-Erstellung?
Darum ging's doch aber grad gar nicht ;)
Schon klar, dass single cycle Tri schön wäre...
Demirug
2005-03-28, 12:40:45
aths, einen ganz normalen Triangle/Tent Filter.
aths, einen ganz normalen Triangle/Tent Filter.Etwas genauer bitte :) Kannst du nicht einfach mal die Wichtungsmatrix aufschreiben?
Demirug
2005-03-28, 22:36:03
Etwas genauer bitte :) Kannst du nicht einfach mal die Wichtungsmatrix aufschreiben?
Sag mal stellst du dich absichtlich dumm?
Der Tentfilter ist wie der Boxfilter ein Basisfilter. Eine Wichtungsmatrix kann man dafür nicht benutzen weil er für variable Filterkernels ausgelegt ist. Der bilineare Filter ist eine Spezialform des Tentfilters für einen 2*2 Filterkernel. Ich hoffe jetzt ist dir klar welchen Filter ich meine. Ansonsten -> google.
Sag mal stellst du dich absichtlich dumm?Nein. Aber wenn du Mitte-betont filterst, musst du auch den Kernel größer machen. So oder so, mit deinem Tent bekommst du doch nicht das korrekte Integral heraus. Da müssen alle Texel gleichgewichtet mit einfließen.
Gasat222
2005-03-29, 16:01:24
Für Texturen ganz schlecht. Da braucht man Blöcke fester Größe und Kompression.
TREC hatte sowas. Das war die Textur-Kompression für Talisman von M$. Hab zuhause noch ein DOC + HTML darüber. Kompressionsrate angeblich bis ~10x. TREC benutzte feste 8x8-Blöcke. Ich weiß allerdings nicht mehr, ob die Kompression fest war, oder variabel.
Was haltet ihr eigentlich von dieser russischen Texture-Kompression, die schon seit ein paar Jahren rumgeistert?
Link: http://graphics.cs.msu.ru/en/research/texture/index.html
+ pdf einer alten(?) Version von '99:
http://graphics.cs.msu.ru/en/publications/text/Pereberin_1999.pdf
Demirug
2005-03-29, 16:14:44
Nein. Aber wenn du Mitte-betont filterst, musst du auch den Kernel größer machen. So oder so, mit deinem Tent bekommst du doch nicht das korrekte Integral heraus. Da müssen alle Texel gleichgewichtet mit einfließen.
Für einen größeren Filterkernel musst du natürlich entsprechend mehr Tents benutzen und diese dann auch übereinader schichten. Primär spielt das alles aber nur eine Rolle für "non pow of 2" Texturen.
Für einen größeren Filterkernel musst du natürlich entsprechend mehr Tents benutzen und diese dann auch übereinader schichten. Primär spielt das alles aber nur eine Rolle für "non pow of 2" Texturen.... das ist alles so herrlich unspezifisch, dass mir das bislang nicht weiterhilft. Non-power-of-two-Texturen zu mippen sollte ebenfalls mit ganz normalen Flächenintegralen möglich sein, wobei natürlich die Randtexel immer entsprechend ihrem Flächenanteil einfließen.
Phantom1
2005-04-20, 16:33:14
Hi,
interessantes Thema. Mit Texturcompression kenne ich mich zwar nicht so aus, aber für das einfache chromasubsampling hab ich vor einiger Zeit mal ein kleines Programm geschrieben, naja vieleicht kanns ja jemand gebrauchen: rgb2yuv.zip (http://www.members.aol.com/jasonvoorhees2k/rgb2yuv.zip)
mfg
Phantom1
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.