3DCenter-Filter-Tester

[Spasstiger]

Es geht um den relativ neuen 3DCenter Filter Tester von Coda in der 3DTools-Rubrik: 3DCenter Filter Tester (http://www.3dcenter.org/3dtools/filter-tester).

Hier ein kurzes Video: http://uploaded.to/file/2thqfy
Ist es normal, dass der 3DCenter Filter Tester eine derart starke Flimmerneigung zeigt? Die Einstellungen waren wie folgt:

http://www.abload.de/thumb/3dcfiltertestervose.jpg (http://www.abload.de/image.php?img=3dcfiltertestervose.jpg)

16:1 TMU-AF mit einer Radeon HD 2900 Pro auf der linken Seite und 32:1 "optimales" ALU-AF auf der rechten Seite. Mir kommt das Flimmern der ALU-Variante viel zu stark vor und das Flimmern der TMU-Variante eigentlich auch. Hier die Textur: http://uploaded.to/file/otmfzm.

[mapel110]

Ist hier auch mit einer Geforce ziemlich ähnlich. Das soll wohl so sein.

[Coda]

Wenn die Mipmaps scheiße sind, dann kann der Filter noch so gut sein. Und die scheinen hier augenscheinlich das Problem zu sein, da das Flimmern weiter hinten auftritt.

Ich probier das mal zu beheben.

[Coda]

Die Textur hat erst gar keine Mipmaps. Topic closed.

[Spasstiger]

Achso, die Mipmaps müssen in der Texturdatei vorhanden sein? Ich dachte, die werden von der Grafikkarte generiert. :freak:
Hier mit Mipmaps, ist tatsächlich gleich viel besser:

http://www.abload.de/thumb/3dcfiltertestersbkq.jpg (http://www.abload.de/image.php?img=3dcfiltertestersbkq.jpg)

Und ich hatte schon den Verdacht, es könnte Point-Sampling-AF sein. :redface:
Hier die Textur mit Mimaps: http://uploaded.to/file/99ujrv.

[Coda]

Achso, die Mipmaps müssen in der Texturdatei vorhanden sein? Ich dachte, die werden von der Grafikkarte generiert.
Nö, bei D3D10 muss man das explizit selber machen wenn man will.

Allerdings ist gescheites Downsampling ziemlich teuer. Das speichern von so einer 1024x1024-Textur mit dem NVIDIA-Plugin und Mips dauert gefühlt 20s.

Das kann man natürlich in der Qualität nicht online machen.

[Spasstiger]

Die Textur hat 2048x2048 Pixel. Mit Paint.net dauert es knapp 10 Sekunden bis die DDS-Datei inkl. Bitmaps generiert ist. Das wäre online natürlich nicht akkzeptabel, vor allem nicht bei Spielen, die Streaming verwenden.

Hier mal eine Gallerie von 1xAF bis 512xAF:

1xAF, 2xAF, 4xAF, 8xAF

http://www.abload.de/thumb/1_1pprc.png (http://www.abload.de/image.php?img=1_1pprc.png) http://www.abload.de/thumb/2_10qos.png (http://www.abload.de/image.php?img=2_10qos.png) http://www.abload.de/thumb/4_1etwx.png (http://www.abload.de/image.php?img=4_1etwx.png) http://www.abload.de/thumb/8_1uq2w.png (http://www.abload.de/image.php?img=8_1uq2w.png)

16xAF, 32xAF, 64xAF, 128xAF

http://www.abload.de/thumb/16_1kq00.png (http://www.abload.de/image.php?img=16_1kq00.png) http://www.abload.de/thumb/32_18qh2.png (http://www.abload.de/image.php?img=32_18qh2.png) http://www.abload.de/thumb/64_1px61.png (http://www.abload.de/image.php?img=64_1px61.png) http://www.abload.de/thumb/128_1bzff.png (http://www.abload.de/image.php?img=128_1bzff.png)

256xAF, 512xAF

http://www.abload.de/thumb/256_18x5b.png (http://www.abload.de/image.php?img=256_18x5b.png) http://www.abload.de/thumb/512_18z6t.png (http://www.abload.de/image.php?img=512_18z6t.png)

Es ist verständlich, dass das TMU-Rendering bei 16:1 AF stagniert. Bei noch höheren AF-Graden passt die Kosten-Nutzen-Rechnung mehr, denn man sieht quasi keinen Unterschied mehr. Erst als Differenzbild zeigen sich die Unterschiede. Man hat mehr davon, wenn man erstmal vom Flimmer-AF weg zum "perfekten" 16:1-AF kommt. Das steigert die Bildqualität deutlich mehr als flimmerndes 32:1 AF. ;)

[Coda]

Das habe ich auch schon früher mal geschrieben ;)

Aber ich sehe da auch ohne Differenzbild einen Unterschied. Allerdings solltest du auch mal versuchen eine Textur mit höherem Kontrast mit Linien in Richtung Horizont zu verwenden. Da sieht man es sehr viel deutlicher.

[Spasstiger]

Zwischen 16:1 AF und 512:1 AF ist natürlich ein Unterschied zu sehen, aber ich hab oben in erster Linie an 32:1 AF vs. 16:1 AF gedacht. Und bei diesem Vergleich muss man die Unterschiede auf den Screenshots echt mit der Lupe suchen. TMUs, die 512:1 AF beherrschen, werden wir wohl nicht so schnell sehen. ;)
Eine andere Textur werde ich mal ausprobieren, aber ich denke, dass meine Textur schon recht typisch für ein Spiel ist. Synthetische Texturen wie z.B. Schachbrettmuster sind ja eher die Ausnahme.

/EDIT: Hier ist der Unterschied zwischen 16:1 AF und 32:1 AF tatsächlich ziemlich groß:

http://www.abload.de/thumb/16xaf_1n9uy.png (http://www.abload.de/image.php?img=16xaf_1n9uy.png) http://www.abload.de/thumb/32xaf_1syuj.png (http://www.abload.de/image.php?img=32xaf_1syuj.png)

[Coda]

Wobei das eigentlich kein Problem mehr sein sollte für die Logik, da die Gradientenberechnung zumindest bei ATI eh nicht mehr verbessert werden kann. Doppelt so viele Loops und fertig.

Da sind eher Performanceüberlegungen im Weg.

[_DrillSarge]I[]

Zwischen 16:1 AF und 512:1 AF ist natürlich ein Unterschied zu sehen, aber ich hab oben in erster Linie an 32:1 AF vs. 16:1 AF gedacht. Und bei diesem Vergleich muss man die Unterschiede auf den Screenshots echt mit der Lupe suchen.
kommt auf den content an ;).
-> 16 vs 32x
(jpeg sollte hier ausreichen um was zu erkennen ;))

http://www.abload.de/thumb/155ei.jpg (http://www.abload.de/image.php?img=155ei.jpg)

http://www.abload.de/thumb/2h263.jpg (http://www.abload.de/image.php?img=2h263.jpg)

übrigens würde ich zum generieren von mips den ati compressonator nehmen. selbst bei 2048^2 texturen dauert das gefühlte 0 sekunden. (solange man keine texturkompression appliziert ;))

[Spasstiger]

Hm, Paint.net komprimiert bei mir gleich, deshalb dauert es auch so lange. Aber schöne Bilder, hier sieht man den Unterschied zwischen 16:1 AF und 32:1 AF sehr deutlich. Aber an 32:1 AF sollte man zumindest bei AMD erst denken, wenn man endlich 16:1 AF ohne Unterabtastung anbietet. ;)

[_DrillSarge]I[]

Hm, Paint.net komprimiert bei mir gleich, deshalb dauert es auch so lange.
naja, im compressonator dauert das generieren der mips + komprimieren der textur inkl aller mips im dxt5-format (ja, ja bringt in diesem fall nix ;)). auch nur ne sekunde länger.
€: grad geschaut, paint.net ist echt arschlahm :usad:

@filtertester: ein button für einen screenshot der aktuellen ansicht wäre nicht schlecht. das jetzige screenshot-menü ist dafür zu "umständlich".

[Coda]

Da (http://www.3dcenter.org/download/3dcenter-filter-tester)

[_DrillSarge]I[]

ging ja fix. thx (y)

[Popeljoe]

Öhm: bin ich blind oder ist von dem Tool auf der Hauptseite Nichts zu lesen gewesen? :usad:
So ein kleines bischen Werbung kann man dafür doch machen.

[Spasstiger]

Afaik kommt noch ein ausführlicher AF-Artikel, in dem das Tool auch genauer erklärt wird.

[Coda]

Wenn ich mal Zeit dafür finde.

[Popeljoe]

Afaik kommt noch ein ausführlicher AF-Artikel, in dem das Tool auch genauer erklärt wird.
Hurra! :up:
Wenn ich mal Zeit dafür finde.
:usad: Och menno!

Das nennt man dann wohl Wechselbad der Gefühle... :freak:

[Coda]

Nein, Wechselbad der Verpflichtungen.

Aber wer was wissen will kann mich ja auch direkt fragen. Kurz mal antworten ist viel einfacher als einen ganzen Artikel zu schreiben.

[aths]

Wie wäre es mit einem AF-Füllraten-Test? Das Tool rendert Texturen einstellbar mit 1x - 16x AF (in Einerschritten, falls die Hardware auch Nichtzweierpotenzen unterstützt) in verschiedenen Winkeln rendern, zum Beispiel 0-89° in 1°-Schritten und die Füllrate messen. Dabei wüsste man dann, wie viele Samples zum Beispiel bei 16x AF wirklich genutzt werden und inwieweit winkelabhängig der echte genutzte AF-Grad reduziert wird.

Das Tool rendert also ein Quadrat und nimmt als Texturkoordinate auf der einen Achse 0-1, auf der anderen je nach Einstellung 0-1, 0-2, 0-3 und so weiter.

Um die Limitierung in den ROPs zu umgehen, müsste das Tool Multitexturing unterstützen.

[Coda]

Man kann nur, 1x, 2x, 4x, 8x und 16x einstellen per API.

Das hab ich mir auch schon alles mal überlegt, aber derzeit einfach keine Zeit dafür.

[aths]

Um diese AF-Füllraten-Applikation bettle ich seit Jahren jeden an, der in D3D ein Quad mit Multitexturing erzeugen kann.

Xmas' AF-Tunnel ist noch heute die Errungenschaft zur AF-Beurteilung und wird international genutzt. Wir brauchen heute aber mehr, da die GPU-Entwickler auf die Idee der Unterfilterung gekommen sind.

[Coda]

Du hast völlig recht, ich werde das auch noch machen. Muss ich mir halt mal 3 Tage komplett freinehmen.

[_DrillSarge]I[]

das tool will irgendwie nicht
http://666kb.com/i/befsq99js8yy2hvm7.png
(xp sp3, intel gma, neuster treiber und dx-runtime)
die besagte dll gibts auch nicht im system32-verzeihnis.
?

[mapel110]

Das Tool ist DX10-Only. ;)

[Sephiroth]

I[;7682833']das tool will irgendwie nicht
http://666kb.com/i/befsq99js8yy2hvm7.png
(xp sp3, intel gma, neuster treiber und dx-runtime)
die besagte dll gibts auch nicht im system32-verzeihnis.
?
System-Voraussetzungen: Vor dem Download bitte beachten

Eine Direct3D 10 fähige Grafikkarte (Radeon HD 2000 oder höher, GeForce 8 oder höher, andere ungetestet)
Unterstützt werden Windows Vista und 7.


http://www.3dcenter.org/3dtools/filter-tester

[Coda]

I[;7682833']das tool will irgendwie nicht
http://666kb.com/i/befsq99js8yy2hvm7.png
(xp sp3, intel gma, neuster treiber und dx-runtime)
die besagte dll gibts auch nicht im system32-verzeihnis.
?
Na was wird D3D10.dll wohl sein *facepalm* ;D

[_DrillSarge]I[]

Das Tool ist DX10-Only. ;)
System-Voraussetzungen: Vor dem Download bitte beachten

Eine Direct3D 10 fähige Grafikkarte (Radeon HD 2000 oder höher, GeForce 8 oder höher, andere ungetestet)
Unterstützt werden Windows Vista und 7.


http://www.3dcenter.org/3dtools/filter-tester
Na was wird D3D10.dll wohl sein *facepalm* ;D
ja :redface:
hatte nicht bedacht, dass es d3d10 braucht. :sneak:

[Coda]

Ich hab in den Filter-Tester mal kurz Gamma-Correction eingebaut: Das bisschen Rest-Flimmern scheint leider doch relativ unbeeindruckt davon zu sein.

[Gipsel]

Das würdest Du nicht sehen.

Edit @Coda:
Wenn Du mal unerwartet etwas mehr Zeit hast, kannst Du ja noch mal mit einer nicht-äquidistanten Verteilung der Taps entlang der line of anisotropy und/oder verschiedenen Gewichten experimentieren, um die Übergange zwischen den Anisostufen zu glätten. Da haben wir ja irgendwie vor zweieinhalb Jahren schonmal drüber geredet.
Intel beschreibt in ihren Dokumenten dass sie die "Randsamples" anders Gewichten was anscheinend das Flimmern verringert. Wenn ich nur Zeit hätte könnte ich noch einiges untersuchen in diese Richtung.

[Coda]

Wie wär's wenn ich euch einfach den Source gebe?

Wobei mir die LoA-Berechnung bissel peinlich ist, die wäre sicher optimierbarer :D

[Coda]

https://github.com/Novum/3dcfiltertester

Bitteschön

[Coda]

Müsstest du im Moment kompilieren, ich hatte noch keine Zeit.

Edit: https://axelgneiting.de/files/3DCenterFilterTesterSetup.exe Release 1.2

Ich hab D3DX rausgeschmissen, es lädt nur noch dds die die GPU auch unterstützt. Also kein RGB, nur RGBA, DXT1, DXT5 etc.

[Gipsel]

Bei NVIDIA HQ seh ich aber definitiv nichts mehr was es von meiner Referenz unterscheiden würde.Dann müssen wir wohl die Referenz besser machen! Hast Du schon mal über alternative, also bessere Rekonstruktionsfilter (Lanczos oder sowas) nachgedacht? :smile:

Zu Deiner Frage wegen irgendwelcher Register bezüglich TMUs bei GCN: Also selbst in der Registerdoku für die X.org-Entwickler (http://www.x.org/docs/AMD/CIK_3D_registers_v2.pdf) (wo mehr drin steht als in der ISA-Doku, allerdings vieles praktisch nicht erklärt, SI-Version hier (http://www.x.org/docs/AMD/SI_3D_registers.pdf)) findet sich dazu nichts. Das einzige sind ein paar ominöse Felder in den Sampler- bzw. Image-Deskriptoren. In letztererem findet sich ein kleines Bitfeld namens Performance modulation (perf_mod), was angeblich bestimmte Einträge der Sampler-Deskriptoren skaliert (wie die aufgebaut sind, steht auch in der ISA-Doku). Dies wären perf_Z, perf_MIP, aniso_bias sowie lod_bias_sec. Was diese "perf"-Werte tun, keine Ahnung, der aniso-Bias (ist ein u1.5-Wert, also 6 Bit, immer positiv) verringert vermutlich die AF-Tap-Anzahl, ohne das LOD anzufassen (also unterfiltert), aber was der "secondary" LOD-Bias-Wert da genau tut (den normalen LOD-Bias gibt es in den Samplern ja auch noch) darfst Du mich nicht fragen. Eventuell ist der nur dazu da, daß der Treiber das Feld unabhängig vom Entwickler gewünschten Wert initialisieren kann und der dann immer additiv wirkt. Außerdem gibt es da noch ein Bit mit der Bezeichnung "FILTER_PREC[ision]_FIX", ebenfalls ohne jegliche Beschreibung (default angeblich aus und das Bit steht in der ISA-Doku als "unused" drin :rolleyes:). Wenn man entweder den ISA-Code des Shaders patchen oder auch die Deskriptoren direkt im Speicher modifizieren würde, könnte man die Werte im Prinzip ändern und sehen, was passiert.

[Coda]

Dann müssen wir wohl die Referenz besser machen! Hast Du schon mal über alternative, also bessere Rekonstruktionsfilter (Lanczos oder sowas) nachgedacht? :smile:
Hast doch den Source-Code. Ich hab gerade andere Probleme mit 4 Buchstaben ;)

Zu Deiner Frage wegen irgendwelcher Register bezüglich TMUs bei GCN: Also selbst in der Registerdoku für die X.org-Entwickler (http://www.x.org/docs/AMD/CIK_3D_registers_v2.pdf) (wo mehr drin steht als in der ISA-Doku, allerdings vieles praktisch nicht erklärt, SI-Version hier (http://www.x.org/docs/AMD/SI_3D_registers.pdf)) findet sich dazu nichts. Das einzige sind ein paar ominöse Felder in den Sampler- bzw. Image-Deskriptoren. In letztererem findet sich ein kleines Bitfeld namens Performance modulation (perf_mod), was angeblich bestimmte Einträge der Sampler-Deskriptoren skaliert (wie die aufgebaut sind, steht auch in der ISA-Doku). Dies wären perf_Z, perf_MIP, aniso_bias sowie lod_bias_sec. Was diese "perf"-Werte tun, keine Ahnung, der aniso-Bias (ist ein u1.5-Wert, also 6 Bit, immer positiv) verringert vermutlich die AF-Tap-Anzahl, ohne das LOD anzufassen (also unterfiltert), aber was der "secondary" LOD-Bias-Wert da genau tut (den normalen LOD-Bias gibt es in den Samplern ja auch noch) darfst Du mich nicht fragen. Eventuell ist der nur dazu da, daß der Treiber das Feld unabhängig vom Entwickler gewünschten Wert initialisieren kann und der dann immer additiv wirkt. Außerdem gibt es da noch ein Bit mit der Bezeichnung "FILTER_PREC[ision]_FIX", ebenfalls ohne jegliche Beschreibung (default angeblich aus und das Bit steht in der ISA-Doku als "unused" drin :rolleyes:). Wenn man entweder den ISA-Code des Shaders patchen oder auch die Deskriptoren direkt im Speicher modifizieren würde, könnte man die Werte im Prinzip ändern und sehen, was passiert.
Ich hab aber das AF-Cheat-Register nie gesehen. Und das gibt es definitiv, weil Quality sichtbar schlechter filtert als High Quality.

Der Instruction wird das wohl nicht übergeben. Dann müssten sie ja die Shader neu kompilieren jedes Mal. Das glaube ich nicht.

[Gipsel]

Hast doch den Source-Code. Ich hab gerade andere Probleme mit 4 Buchstaben ;)


Ich hab aber das AF-Cheat-Register nie gesehen. Und das gibt es definitiv, weil Quality sichtbar schlechter filtert als High Quality.

Der Instruction wird das wohl nicht übergeben. Dann müssten sie ja die Shader neu kompilieren jedes Mal. Das glaube ich nicht.
Wenn nur der Resource- bzw. Sampler-Descriptor anders initialisiert wird (mit diesem perf_mod, aniso_bias oder filter_prec_fix und Konsorten), bleibt der Shader vollkommen unverändert.

Und zum Code, ich habe das gestern Abend bei mir mal zum Laufen bekommen. Ein paar minimale Änderungen waren nötig, damit VS2010 (neuere Lizenz habe ich nicht, arbeitet ja nicht jeder in der Branche, kommt noch aus meiner Uni-Zeit über MSDNAA) den Build hinbekommen hat. Am längsten hat eigentlich gedauert, das blöde .NET framework 4.5 und das Windows8 SDK zu installieren (gibt ja offenbar kein DX-SDK mehr), sowie die wxwidgets zu bauen. Also wenn mir ab sofort mal wirklich langweilig wird, spiele ich mal ein wenig damit rum.
Rein spaßenshalber habe ich mir heute kurz mal an einem einfachen 1D-Beispiel angesehen, wie gut der Lanczos-Filter beim Unterdrücken von Moirees beim Runterrechnen der MipMaps wäre (gegenüber einem simplen Box-Filter). Das ist teilweise schon ziemlich beeindruckend besser. Wenn man nicht nur die MipMaps so filtert sondern den auch zur Rekonstruktion benutzt, verschwindet vielleicht auch noch das Restflimmern (vor allem aber vermutlich das ganze Moiree-Geraffel im Hintergrund beim Checkerboard). Aber das ist ja erstmal keine Option für GPUs, ist doch etwas aufwendiger als die linearen Interpolationen. Aber als Demonstration, was mit mehr Aufwand möglich wäre, ist das vielleicht ganz nett (und die ALUs bekommen was zu tun mit den ganzen sinus-Funktionen).

edit:
hochfrequentes Signal, schwarz sind die Originalsamples
"Mip1" hat halbe Auflösung, "Mip2" wiederum die Hälfte von Mip1
In Mip2 paßt die Grundfrequenz des Signals nicht mehr rein, bei einem Filter mit entsprechender Tiefpaßfilterung nach Nyquist sollte also nichts mehr übrig bleiben. Der Box-Filter tut dies nicht und produziert über Aliasing nette Moirees, der Lanczos ist beinahe perfekt.

http://abload.de/img/filterprk6u.png

Und für einen Rekonstruktionsfilter bei AF funktioniert das praktisch genauso. Moirees müßten recht effektiv unterdrückt werden ohne die Schärfe negativ zu beeinflussen. Man muß nur das Filter-Window entsprechend setzen und benötigt somit ein paar mehr Samples außerhalb des eigentlichen Pixel-Footprints (Filter-Kernel ist mindestens doppelt so groß wie Pixel-Footprint, ansonsten klappt das ja nicht mit der Moiree-Unterdrückung). Da wäre es interessant zu sehen, wie sich das genau verhält.

[aths]

Dann müssen wir wohl die Referenz besser machen! Hast Du schon mal über alternative, also bessere Rekonstruktionsfilter (Lanczos oder sowas) nachgedacht? :smile:Lanczos ist nicht per se besser. Lanczos behält mehr Schärfe beim Vergrößern bei.

[Coda]

Ich bin übrigens auch schon lange zum Schluss gekommen, dass es einen besseren Filter als Point Samples braucht.

Aber um das wirklich richtig zu machen müsste man eigentlich auch über den Pixel hinaus filtern. Und zwar nicht nur entlang der LOA sondern auch seitlich.

[Gipsel]

Lanczos ist nicht per se besser. Lanczos behält mehr Schärfe beim Vergrößern bei.
Ich bin übrigens auch schon lange zum Schluss gekommen, dass es einen besseren Filter als Point Samples braucht.

Aber um das wirklich richtig zu machen müsste man eigentlich auch über den Pixel hinaus filtern. Und zwar nicht nur entlang der LOA sondern auch seitlich.
Also, ich habe eben gerade mal den Lanczos (mit a=2, wie im Beispiel oben) eingebaut. Nur 1D entlang der LoA. Aber natürlich impliziert das, daß man da über den eigentlichen Pixel hinausfiltert, der Filterkernel ist halt größer als bei dem einfachen AF. Schärfer wird es nicht wirklich, das Flimmern wird vielleicht minimal schwächer, aber die Moirees im Hintergrund bei höheren AF-Leveln werden recht gut unterdrückt. Genau dafür ist der ja auch da. Mit einem 2D-Lanczos verschwinden die Moirees vermutlich komplett und auch das Flimmern könnte noch weiter abnehmen.

Video gibt es hier (http://www.file-upload.net/download-8164863/1D-Lanczos_AF.zip.html) (relativ klein).

Anfang ist 1x mit dem normalen ("perfect") Algo und dann Schritt für Schritt auf 16x hoch, dann den Lanczos-Filter reingehauen und schrittweise wieder zurück auf 1x. Links im Splitscreen ist ein Fermi mit AF auf HQ im Treiber.

Das bringt übrigens meine olle GT425M in dem Rechner hier schon ganz schön in die Knie bei Vollbild, 2D Lanczos schafft die wohl nicht mehr im Vollbild :freak:.

Edit:
Ach ja, die einzelnen Samples sind immer noch trilineare Samples, das habe ich nicht geändert. Das ist 1:1 übernommen. Insofern nimmt er auch für 1x den Lanczos-Filter. Der Unterschied sieht dann so aus (mal größerer Screenshot mitsamt Teil des Desktops):

http://abload.de/img/af_perfect_1xa9shh.png
http://abload.de/img/af_lanczos_1x0ls6l.png

Man sieht schon, daß das etwas ruhiger aussieht, selbst ohne AF.

Ein Video mit der ground2-Textur 16xAF und dem Vergleich zwischen der Referenzimplementation und dem zusätzlichen Lanczos-Filter lade ich gerade hoch. Da sieht man schon, daß das Flimmern abnimmt.

Edit:
Hier noch das Video mit der ground2-Textur (http://www.file-upload.net/download-8165017/Reference-Lanczos.zip.html). Bei etwa 4 Sekunden wird auf den Lanczos-Filter umgeschaltet. Ist 16xAF, links wieder Fermi mit HQ-AF.

[Coda]

Ohne AF nimmt er doch immer nur ein Sample? Das kapier ich jetzt gerade nicht. Wie willst du da einen anderen Filterkernel anwenden?

[Gipsel]

Ohne AF nimmt er doch immer nur ein Sample? Das kapier ich jetzt gerade nicht. Wie willst du da einen anderen Filterkernel anwenden?Na, ich wollte nicht zu viel ändern, daß sind nur ein paar zusätzliche Zeilen im Pixelshader, das meiste wird unverändert weiterbenutzt. Das führt dazu, daß er auch bei 1x mit dem Lanczos-Rekonstruktion-Filterkernel da drüber geht. Er nimmt dann insgesamt 4 Samples entlang der LoA (die gibt es ja trotzdem, auch wenn die Anisotropie <2 ist), die Breite des Kernels sind ja +-2 (das ist das a=2, was ich erwähnt hatte, a=3 unterdrückt die höheren Frequenzen noch etwas besser), er nimmt also generell 4mal so viel Samples. Eigentlich wäre es das beste, das direkt mit point-Samples (oder maximal mit bilinearen Samples zu machen, wenn man Aufwand im Shader sparen will). Die trilinearen Samples sind da etwas verschwendet und machen es vermutlich nicht wirklich besser.

[Coda]

Ich nehm keine trilinearen Samples, es sind immer nur bilineare. Deshalb läuft er ja zweimal über die LoA (einal für jede Mip) und rechnet die beiden Resultate am Ende zusammen.

Die bilineare Logik wollte ich mir sparen. Wenn man wirklich point samples nimmt dann wird's natürlich echt interessant wie man die am besten verteilen würde um ein Ergebnis möglichst nahe von Lanczos zu bekommen.

In der Magnification wird man aber wohl immer auf normales Trilinear zurückfallen wollen.

[Gipsel]

Ich nehm keine trilinearen Samples, es sind immer nur bilineare. Deshalb läuft er ja zweimal über die LoA (einal für jede Mip) und rechnet die beiden Resultate am Ende zusammen.Schon klar, habe ich doch gesehen. Und ich nehme einfach die von Deinem Code zusammengerechneten Samples (also lerp(mip1, mip2, trilinear_lerp_factor)), aber eben davon 4 Stück entlang der LoA (weil es ja nur 1D ist, nimmt er immer die LoA-Richtung, auch wenn es für 1x nicht wirklich soo viel Sinn macht). Im Prinzip vergrößere ich, wenn der filter_mode auf 3.0 steht, einfach nur n, um den größeren Footprint des Lanczos-Filters abzubilden (der Abstand der Samples bleibt identisch) und gewichte dann die Samples anders entsprechend des Filter-Windows. Die ganze Schleife mit dem nehmen der Samples steht noch praktisch genau so da. Die Magnification habe ich gar nicht angefaßt und das andere ist nur eine Zeile vor dem Addieren zur color_sum, die das mit den Gewichten macht.
if(filter_mode == 3.0f) color_temp=color_temp*lanc((i-n*0.5f+0.5f)/n*4.0f, 2.0f, 0.5f);
color_sum+=color_temp;
}
float4 filterResult;
if(filter_mode == 3.0f) filterResult = (color_sum * 4.0f / n);
else filterResult = color_sum / n;

lanc(x, a ,a_inv) berechnet die Gewichte für den Lanczos-Filter, die Koordinate x ist der Einfachheit halber auf 1 normiert, a ist die Breite des Lanczos-Filter, hier 2. Mehr ist das nicht.

Ach ja, hier noch das Video mit der ground2-Textur (http://www.file-upload.net/download-8165017/Reference-Lanczos.zip.html). Bei etwa 4 Sekunden wird auf den Lanczos-Filter umgeschaltet. Ist 16xAF, links wieder Fermi mit HQ-AF. Ich sehe da eine Abhnahme des Flimmerns ohne sichtbaren Schärfeverlust. Geht bestimmt noch besser, wenn man etwas mehr Aufwand betreibt.

[Coda]

Ach so machst du das. Ich dachte da eigentlich an bisschen was intelligenteres das nicht einfach so mit Samples um sich wirft.

Was man ja eigentlich machen will einen verzerrten 2D-Laczos (in Form eines Ellipsoids) abzutasten. Und das dann noch möglichst schlau indem man eine Convulution macht mit Samples aus den Mips.

[Gipsel]

Ach so machst du das. Ich dachte da eigentlich an bisschen was intelligenteres das nicht einfach so mit Samples um sich wirft.

Was man ja eigentlich machen will einen verzerrten 2D-Laczos (in Form eines Ellipsoids) abzutasten. Und das dann noch möglichst intelligent indem man eine Convulution macht mit Samples aus den Mips.
Daß das (bisher?) nur 1D ist, war gleich mein Statement zum Anfang oben:
Also, ich habe eben gerade mal den Lanczos (mit a=2, wie im Beispiel oben) eingebaut. Nur 1D entlang der LoA.Und wenn man das nur so 1D macht, kommt man an bi- bzw. trilinearen Samples nicht vorbei, wenn man kein Pointsampling quer zur LoA machen will. ;)

Und das war ja nur mal so kurz eben, und für den geringen Aufwand kann sich das ruhigere Filterresultat bei gleicher Schärfe und weniger Moiree schon sehen lassen meiner Meinung nach. Nenn es proof of concept: es geht noch besser! :wink:

Edit:
Ach ja, die Mips nehme ich schon, ich rekonstruiere das nicht aus der Basemap (da wäre das Resultat zwar am besten, man benötigt aber irgendwann irsinnig viele Samples). Man braucht nur ein 2D Lanczos daraus stricken. Wenn man das in die beiden Richtungen mit unterschiedlich breiten Fenstern sampelt (entsprechend den Gradienten) ergibt sich automatisch eine Ellipse als Filterkernel. Also entlang der LoA den Sampleabstand, wie Du ihn auch nimmst, nur mit bilinearen Samples und quer dazu nimmt man 4 Samples (das praktische Minimum mit einem Lanczos der Breite 2), wäre nur die doppelte bilineare Sampleanzahl wie jetzt.

[Coda]

Jup, kein Vorwurf. Ich würde nur gerne mal sehen was gehen würde wenn man trotzdem nur 64 bilineare Samples hat gegenüber der derzeitigen Standard-Praxis. Aber da müsste ich mal eine Woche darüber nachdenken in Ruhe.

[Gipsel]

Ach, und hierzu nochmal:
Lanczos ist nicht per se besser. Lanczos behält mehr Schärfe beim Vergrößern bei.Du kannst beides damit machen, Vergrößern und Verkleinern. Zum Verkleinern muß man ja auch entsprechend Filtern, damit man die höheren Frequenzen unterdrückt, damit keine Moires auftreten. Die typisch benutzen Box-Filter sind da deutlich suboptimal. Lanczos ist ja praktisch der theoretisch ideale Sinc-Filter (mit unendlich großem Filterkernel, also praktisch nicht nutzbar) der auf ein ebenfalls Sinc-Fenster beschränkt wird. Der ist ziemlich gut dafür, Moires beim Verkleinern zu unterdrücken. Das sieht man sehr gut am 1D-Beispiel im Spoiler (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=9953366#post9953366) und auch in dem Video aus dem Filtertester mit dem Schachbrettmuster (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=9953722#post9953722).

[Skysnake]

Du mit deinen Bäumen ständig. Was hat das mit dem AF zu tun? Die Bäume sehen jetzt so aus wie bei Nvidia. Da haben sie wohl ein Bug gefixt. Das ist eine Pflichtaufgabe und kein Extralob wert.
Also, ich habe eben gerade mal den Lanczos (mit a=2, wie im Beispiel oben) eingebaut. Nur 1D entlang der LoA. Aber natürlich impliziert das, daß man da über den eigentlichen Pixel hinausfiltert, der Filterkernel ist halt größer als bei dem einfachen AF. Schärfer wird es nicht wirklich, das Flimmern wird vielleicht minimal schwächer, aber die Moirees im Hintergrund bei höheren AF-Leveln werden recht gut unterdrückt. Genau dafür ist der ja auch da. Mit einem 2D-Lanczos verschwinden die Moirees vermutlich komplett und auch das Flimmern könnte noch weiter abnehmen.


Anfang ist 1x mit dem normalen ("perfect") Algo und dann Schritt für Schritt auf 16x hoch, dann den Lanczos-Filter reingehauen und schrittweise wieder zurück auf 1x. Links im Splitscreen ist ein Fermi mit AF auf HQ im Treiber.

Das bringt übrigens meine olle GT425M in dem Rechner hier schon ganz schön in die Knie bei Vollbild, 2D Lanczos schafft die wohl nicht mehr im Vollbild :freak:.

Edit:
Ach ja, die einzelnen Samples sind immer noch trilineare Samples, das habe ich nicht geändert. Das ist 1:1 übernommen. Insofern nimmt er auch für 1x den Lanczos-Filter. Der Unterschied sieht dann so aus (mal größerer Screenshot mitsamt Teil des Desktops):

Man sieht schon, daß das etwas ruhiger aussieht, selbst ohne AF.

Ein Video mit der ground2-Textur 16xAF und dem Vergleich zwischen der Referenzimplementation und dem zusätzlichen Lanczos-Filter lade ich gerade hoch. Da sieht man schon, daß das Flimmern abnimmt.

Edit:
Hier noch das Video mit der ground2-Textur (http://www.file-upload.net/download-8165017/Reference-Lanczos.zip.html). Bei etwa 4 Sekunden wird auf den Lanczos-Filter umgeschaltet. Ist 16xAF, links wieder Fermi mit HQ-AF.
Wau Gipsel, das sieht wirklich deutlich besser aus :up:

2D Sollte aber wirklichwohl noch einen leicht besseren Effekt bringen, viel wirds aber denke ich nicht mehr sein. Vor allem beim restlichen Flimmern kann ich es mir kaum noch vorstellen, dass das noch was bringt.

EDIT:
Mit der Grastextur bin ich nicht so wirklich zufrieden/überzeugt. Ich seh da eigentlich keinen wirklichen Unterschied :(

Es ist aber auch schwer zu vergleichen, weil die Strukturen nicht Symmetrisch auf beiden Seiten sind. Könntest du das eventuell mit der Textur so fixen, das es an der Senkrechten Gespiegelt wird???

Das würde den Vergleich meiner Meinung nach einfacher machen.

[aths]

Ach, und hierzu nochmal:
Du kannst beides damit machen, Vergrößern und Verkleinern. Zum Verkleinern muß man ja auch entsprechend Filtern, damit man die höheren Frequenzen unterdrückt, damit keine Moires auftreten. Die typisch benutzen Box-Filter sind da deutlich suboptimal. Lanczos ist ja praktisch der theoretisch ideale Sinc-Filter (mit unendlich großem Filterkernel, also praktisch nicht nutzbar) der auf ein ebenfalls Sinc-Fenster beschränkt wird. Der ist ziemlich gut dafür, Moires beim Verkleinern zu unterdrücken. Das sieht man sehr gut am 1D-Beispiel im Spoiler (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=9953366#post9953366) und auch in dem Video aus dem Filtertester mit dem Schachbrettmuster (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=9953722#post9953722).
Die Sinc-Funktion zur Signalrekonstruktion ist für ein kontinuierliches Signal gedacht. Das bietet eine Textur so von vornherein nicht. Egal ob man sie als Kachelmuster von Farbquadraten betrachtet oder als mathematische Farbpunkte, das Signal hat Sprünge oder Knicke. Sinc funktioniert auf Texturen nur dann näherungsweise gut, wenn die räumliche Signalauflösung das Nyquist-Kriterium deutlich übertrifft.

Generell steht man vor dem folgenden Problem: Wann löst man Details noch auf? Man könnte ja einfach bevor ein Pixelschachbrettmuster zu flimmern anfängt, deren Mischfarbe anzeigen. Das wirkt für heutige Augen unscharf, da die Detaildarstellung längst nicht die Pixeldichte ausnutzt. Dabei müsste noch berücksichtigt werden, dass schwachkontrastige Texturen natürlich generell weniger flimmern, weshalb man sie nicht so stark überfiltern braucht.

Das Problem bei Computergrafik ist imo nach wie vor, dass Vordergrund-Texturen oft nicht pixelscharf sind, während Hintergrund-Texturen knackscharf wirken. Hätte man eine gleichmäßige Schärfeverteilung über das gesamte Bild, wäre der Eindruck deutlich realistischer.

[Gipsel]

Die Sinc-Funktion zur Signalrekonstruktion ist für ein kontinuierliches Signal gedacht. Das bietet eine Textur so von vornherein nicht.Ich habe doch geschrieben, daß man für Sinc praktisch die komplette (sogar unendlich ausgedehnte) Textur benötigt, was es unpraktisch macht. Nehme ich ja auch gar nicht, sondern den Lanczos-Filter, der ein Sinc ist, was ein Fenster besitzt (also den betrachteten Bereich einschränkt), was ebenfalls wieder eine Sinc-Funktion ist. Durch das sanfte Auslaufen umgeht man die Artefakte einer abgeschnittenen Sinc-Funktion (also die Faltung von Sinc mit Box).
Egal ob man sie als Kachelmuster von Farbquadraten betrachtet oder als mathematische Farbpunkte, das Signal hat Sprünge oder Knicke. Sinc funktioniert auf Texturen nur dann näherungsweise gut, wenn die räumliche Signalauflösung das Nyquist-Kriterium deutlich übertrifft.Hast Du Dir mal die Grafik im Spoiler angesehen? Oder die Videos? Das funktioniert auch praktisch ganz gut. Vielleicht nicht immer perfekt (filtert ja auch nur in eine Richtung so, die andere ist immer noch "konventionell" und kann leichte Artefakte produzieren), aber besser als die normalen Filter. Man kann natürlich nur Frequenzen unterdrücken, die in den Filterkernel passen. Aber da der +-2 Pixel groß ist (bei mir, kann man auch noch größer machen zur noch besseren Unterdrückung hoher Frequenzen) und man MipMaps ja typischerweise immer einen Faktor 2 skaliert, funktioniert das solange gut, solange die Basetextur nicht schon Moires drin hat (dann hat man immer verloren, weil man nicht weiß, ja nicht wissen kann, was echt ist und was nicht) bzw. die MipMaps entsprechend gefiltert sind (z.B. über Lanczos-Downsampling), daß diese ebenfalls keine zeigen.
Generell steht man vor dem folgenden Problem: Wann löst man Details noch auf? Man könnte ja einfach bevor ein Pixelschachbrettmuster zu flimmern anfängt, deren Mischfarbe anzeigen. Das wirkt für heutige Augen unscharf, da die Detaildarstellung längst nicht die Pixeldichte ausnutzt.Hmm. Also ich sehe nicht, daß meine Lösung unschärfer wird, es flimmert nur weniger und die Moires werden unterdrückt. Also jetzt mal ganz praktisch. Der Signalverlauf wird besser rekonstruiert und Moiree-Muster besser vermieden, so daß das auf dem Bildschirm landende Ergebnis auch weniger von periodischen Änderungen der Samplepositionen (wie das in Bewegung passiert, temporales Moiree!) abhängig ist => weniger Flimmern. Bei dem Video mit der ground2- Textur ist das wunderbar zu sehen.

====================

@Skysnake:
Also ich sehe das eindeutig mit der ground2-Textur. Da gibt es mehrere flimmrige Bereiche, (sowohl rechts als auch links, hat etwa gleiche Qualität; Das Flimmern ist praktisch eine Art Muster, was nicht mit der Textur mitlaufen will und sozusagen über die Textur gleitet [aber ortsfest am Bildschirm ist]. Ist wie gesagt ein Aliasing-Effekt mit den periodischen Änderungen der Samplepositionen), wenn man sich auf einen in der rechten Hälfte konzentriert, sieht man sehr deutlich, daß das Flimmern nach etwa 4s im Video fast vollständig verschwindet (ist ja erst 1D, deswegen wohl nicht komplett). Die linke Hälfte ändert sich natürlich nicht.
Und was ändern kann ich auch nicht, bin ab heute im WE und nicht zu Hause.

[Coda]

Wau Gipsel, das sieht wirklich deutlich besser aus :up:

2D Sollte aber wirklichwohl noch einen leicht besseren Effekt bringen, viel wirds aber denke ich nicht mehr sein. Vor allem beim restlichen Flimmern kann ich es mir kaum noch vorstellen, dass das noch was bringt.

EDIT:
Mit der Grastextur bin ich nicht so wirklich zufrieden/überzeugt. Ich seh da eigentlich keinen wirklichen Unterschied :(

Es ist aber auch schwer zu vergleichen, weil die Strukturen nicht Symmetrisch auf beiden Seiten sind. Könntest du das eventuell mit der Textur so fixen, das es an der Senkrechten Gespiegelt wird???

Das würde den Vergleich meiner Meinung nach einfacher machen.
Dir ist schon klar, dass er nur bisschen den Shader verändert hat? Wieso fragst du das nicht mich?

[Skysnake]

Ja, aber man muss sich die Zeit für nehmen, und die scheinst du gerade nicht zu haben, und wenn er eh dran sitzt, kann ers doch gern machen oder nicht ;)

Wenn du Zeit und Lust hast, mach, mir ist das egal, wers macht.

[Gipsel]

Das Problem bei Computergrafik ist imo nach wie vor, dass Vordergrund-Texturen oft nicht pixelscharf sind, während Hintergrund-Texturen knackscharf wirken. Hätte man eine gleichmäßige Schärfeverteilung über das gesamte Bild, wäre der Eindruck deutlich realistischer.Okay, dann baue ich vielleicht nächste Woche auch noch irgendwas für die Magnification rein. Erfordert dann ein paar mehr Umstellungen als nur zwei Zeilen, da man das wohl besser mit Point-Samples macht. Und irgendwie muß ich dann wohl auch einen 2D-Filter bauen, wenn man nicht nur in eine Richtung schärfen will.

Edit: Hmm, so richtig klar ist aber nicht, was man da genau machen will. Mit einer Box-Vergrößerung + linearer Interpolation dazwischen bleibt ein Schachbrettmuster zwar scharf, echte Texturen werden jedoch blockig. Ergo ist das wohl kaum vollständig lösbar. Man könnte über Lanczos-Upsampling (oder bikubische Splines, oder was auch immer) nachdenken, aber wirklich schärfer (im Sinne von mehr Information) kann das ja auch nicht werden, vermutlich sieht es nur etwas besser (natürlicher) aus. Ergo: man braucht eine höher aufgelöste BaseMap :).

[Coda]

Es wäre mal interessant herauszufinden was die Offline-Renderer eigentlich benutzen.

[Gipsel]

Es wäre mal interessant herauszufinden was die Offline-Renderer eigentlich benutzen.Die schlagen das Problem mit stochastischem Supersampling tot? Bzw. benutzen die gar keine Texturierung im eigentlichen Sinne (REYES und Konsorten), edit: also eine, wo man die im Echtzeitbereich übliche Filterung durchführt. Das wird denke ich mit dem Aliasingproblem und den Mikroplygonen zusammen erledigt (habe da aber keine wirkliche Ahnung).

[boxleitnerb]

Bei Gipsel's Video mit der ground2-Textur sieht man die Verbesserung ab 4s beim ALU-Rendering klar.

[Gipsel]

Bei Gipsel's Video mit der ground2-Textur sieht man die Verbesserung ab 4s beim ALU-Rendering klar.
Also erkennst Du keine vergrößerte Unschärfe? Für meine Laienaugen verschwindet eigentlich nur das Flimmern (na ja fast, an ein oder zwei Pixeln flimmert es noch minimal, da bräuchte es wohl eine noch etwas aufwändigere Lösung), der Rest, also die Schärfe sieht für mich ziemlich genau so aus.

edit: Weil es schon mal in der Diskussion aufkam, betrachtet auf einem 46" Sony-TV (Displaymode 1080p60, die Bild"verbesserer" sollten aus gewesen sein), hab mir das auf meinem HTPC angesehen (und auch aufgenommen wegen der nV-Grafik).

[Gipsel]

Die Geschichte mit den Filtergewichten (auch kombiniert mit anderer Anordnung der Samples) war ja schon vor 2 Jahren hier im 3DC im Gespräch. Intel gibt den äußersten Samples angeblich etwas weniger Gewicht als den inneren, um Flimmerneigung zu reduzieren. Wie funktioniert das überhaupt?

Das Problem ist ganz allgemein, daß in der MipMapstufe, aus der die einzelnen Samples kommen, Ortsfrequenzen (also wie schnell ändert sich der Bildinhalt von einem Texel zum nächsten) enthalten sein können, die nicht mehr auf dem Bildschirm dargestellt werden können (zwei Peaks müssen mehr als 2 Pixel auseinanderliegen, sonst kommt es zu Aliasing und damit Moiree-Effekten). Beim Texturfiltern will man also eigentlich eine Filterung der Ortsfrequenzen in der Textur (der gesampelten MipMap) durchführen, höhere Frequenzen, als auf dem Bildschirm darstellbar sind, sollten möglichst vollständig entfernt werden. Der Texturfilter sollte also die Funktion eines Tiefpasses erfüllen.
Ein einfache Mittelung aller Samples, die in den Pixel fallen (Boxfilter), erfüllt diese Bedingung nicht. Die Eigenschaften des Filters im Ortsraum (also wo die Samples genommen werden) und im Frequenzraum (wo man die höheren Frequenzen beschneiden will) ist über eine Fouriertransformation verknüpft. Es läßt sich leicht zeigen, daß ein Boxfilter eben kein guter Tiefpaß ist, seine Fouriertrafo zeigt ein Hüllkurve, die sich sinc-Funktion nennt und auch bei höheren Frequenzen Ungleich Null ist, was sich dann in häßlichen Moiree-Mustern äußert. Man will eigentlich einen Box-Filter im Frequenzraum haben (und nicht im Ortsraum), niedrige Frequenzen (um 0) sollen ungeändert erhalten bleiben, während ab einer Grenzfrequenz (das, was gerade noch darstellbar ist) alles rigoros auf Null geprügelt wird. Nun ist im Frequenzraum zu filtern schlecht möglich, wenn man diskrete Samples im Ortsraum hat, aber man kann natürlich einen Box-Filter fouriertransformieren und sehen, wie der dann im Ortsraum aussehen muß. Und wie wir bereits wissen, kommt da die Sinc-Funktion raus. Die ist also theoretisch die beste Filterfunktion für unsere Samples und entfernt perfekt jegliche höhere Frequenzen. Dummerweise erstreckt sich die Sinc-Funktion bis ins Unendliche und man bräuchte ein unendliche Abfolge an Samples, die man entsprechend wichten müßte. Geht also nicht. Man kann die natürlich irgendwo abschneiden, was die Faltung eines (breiteren) Box-Filters mit der Sinc-Funktion wäre, aber hier gibt es dann oft Artefakte (hauptsächlich Ringing wegen des abrupten Abschneidens).

Was ist eine mögliche Lösung? Man schneidet die nicht einfach ab, sondern läßt sie sanft ausklingen. Dafür gibt es mehrere Möglichkeiten, eine bewährte ist die Multiplikation mit einer zweiten Sinc-Funktion anderer Breite, vorzugsweise ein ganzzahliges Vielfaches, dies gibt der "a"-Parameter an. Je größer a, desto mehr Oszillationen der Sinc-Funktion nimmt man mit und desto näher ist man am idealen Filter, benötigt aber auch mehr und mehr Samples dafür. Praktisch bewährt haben sich Werte von zwei oder drei. Das Resultat nennt sich Lanczos-Filter.

Wie sieht das jetzt praktisch aus mit den Gewichten bei diesem Filter? Um Signal mit höheren Frequenzen als der halben Pixelfrequenz (Nyquist-Grenze) zu erkennen und zu entfernen, reicht es nicht aus, nur die Samples innerhalb eines Pixels zu betrachten. Die besseren Filter nehmen also auch Samples außerhalb des eigentlichen Pixels. Der Effekt ist nicht durch eine Art Supersampling mit einfach mehr Samples zu erreichen, die zusätzlichen Samples mit besseren Filtern werden ausschließlich außerhalb des Pixels genommen. Die Samplepositionen innerhalb des Pixels sind (zumindest bei meiner Variante) absolut identisch. Zur Verdeutlichung mal eine Abbildung mit dem Vergleich der Samplepositionen und entsprechenden Gewichte für 4xAF:

http://abload.de/img/filter_gewichteiosre.png

Die Gewichte nehmen also nach außen zum Pixel hin ab und erreichen in der Mitte des Nachbarpixels sogar negative Werte. Die dortigen Samples werden also vom Farbwert abgezogen. Dies wirkt einem Blurring entgegen, wie es zum Beispiel auftritt, wenn man die Gewichte rein positiv läßt und es nur sanft ausklingen läßt, z.B. mit einer Gaußfunktion oder Ähnlichem. Die negativen Gewichte erhalten einen möglichst "boxigen" Charakter des Filters im Frequenzraum, beschneiden also nicht schon (oder nur sehr wenig) die Frequenzen, die gerade noch so darstellbar sind, und unterdrücken weiterhin sehr gut die höheren Frequenzen (die zu Moirees führen würden).

edit:
http://abload.de/img/filter_weightskguic.png
edit2:

allerdings nur für den einfachen Fall, daß die beiden Gradienten senkrecht aufeinander stehen (ansonsten verzerrt sich das noch zusätzlich)
Alle Beispiele sind für eine Anisotropie von genau 4 angegeben, deswegen ergibt das längliche Footprints im Texelspace. Die zwei Paare dünner Linien geben den Pixel an, für den gesampelt wird.

http://abload.de/img/filter_biafeaju5.png
http://abload.de/img/filter_tentafx9jjw.png
http://abload.de/img/filter_2d_slanczos7ojg5.png
http://abload.de/img/filter_2dlanczos_ac3hpjl7.png

[-/\-CruNcher-/\-]

Wie sieht es eigentlich mit Intels Fortschritt aus, solten die nicht jetzt einen Adaptive Lanczos4 Filter in Hardware haben (seit Sandy Bridge) der Video DSP part kann den jedenfalls nutzen zum Scaling ?

@Gipsel
Dein Ergebniss im Alu Rendering sieht auf jedenfall in Motion stabilier aus als im TMU Rendering wie schon andere bestätigt haben :)

genau ab der 4 sekunde sehr stabil im forderen Berreich genau 2 hotspot zonen werden hier eliminiert (ground2), den Schärfeverlust in diesem Synthetischen test würde ich als sehr marginal bis nicht sichtbar einstuffen :)

Ein leichtes pulsieren ist auch beim Alu Rendering noch wahrzunehmen aber das ist so gering das würde kein Otto normal sehen bei der Wahrnehmung bin ich mir nicht sicher ;)

Problem ist natürlich das das Video ansich in der Auflößung überall nochmal Hardware scaled wird aber auch im Window erkennt man den Puls (Frequenz) unterschied noch sehr gut.

@Coda
Wieso gibts für den tester kein Fullscreen Mode ?

PS: Mein Visual Cortex ist trainiert für temporal Motion artifacts

[Gipsel]

Wie sieht es eigentlich mit Intels Fortschritt aus, solten die nicht jetzt einen Adaptive Lanczos4 Filter in Hardware haben (seit Sandy Bridge) der Video DSP part kann den jedenfalls nutzen zum Scaling ?Das Skalieren bei der Ausgabe hilft dir aber nicht beim Texturieren. Zwei völlig verschiedene Baustellen.
@Gipsel
Dein Ergebniss im Alu Rendering sieht auf jedenfall in Motion stabilier aus als im TMU Rendering wie schon andere bestätigt haben :)

genau ab der 4 sekunde sehr stabil im forderen Berreich genau 2 hotspot zonen werden hier eliminiert (ground2), den Schärfeverlust in diesem Synthetischen test würde ich als sehr marginal bis nicht sichtbar einstuffen :)

Ein leichtes pulsieren ist auch beim Alu Rendering noch wahrzunehmen aber das ist so gering das würde kein Otto normal sehen bei der Wahrnehmung bin ich mir nicht sicher ;)Wie gesagt, vielleicht bastle ich diese Woche noch eine vollständige Lösung ein, bisher ist es ja nur die Sparversion, die nur in eine Richtung (entlang der Line of Anisotropy, also der längeren Achse des Pixelfootprints) den Lanczos-Filter anwendet, so ein Bild ist aber eine zweidimensionale Angelegenheit. Man will also eigentlich in beide Richtungen den besseren Filter anwenden.
Problem ist natürlich das das Video ansich in der Auflößung überall nochmal Hardware scaled wird aber auch im Window erkennt man den Puls (Frequenz) unterschied noch sehr gut.:confused:
Stell den Videoplayer auf 100% Skalierung und es gibt ein 1:1 Pixel-Mapping. Optimalerweise sollte Deine Refresh-Rate noch ein Vielfaches von 30Hz sein (das Video hat 30fps) und irgendwelche Zwischenbildinterpolationen (wenn Du es Dir am Fernseher ansiehst oder so) aus sein. Oder wovon redest Du?

============================

@Coda:
Ich habe übrigens nochmal kurz über diesen 2D-Filter nachgedacht. Relativ einfach geht der nur, wenn man weiterhin direkt bi-/ bzw. trilinieare Samples nimmt und die (und ein paar außenrum) dann nur selber etwas anders verrechnet.
Wenn man es wirklich richtig machen will, muß man Pointsamples aus der entsprechenden MipMap nehmen und für jedes Sample den Abstand zur jeweiligen Achse des Footprints ausrechnen. Aber man benötigt dann nicht soo viele Samples mehr, als jetzt auch schon. Für Anisotropy 4 wären es (für die "biLanczos" Variante) ~64 point samples (genau kann man das nicht sagen, da es auch etwas von der Orientierung des Footprints abhängt, das wird ziemlich kompliziert und damit langsam im Pixelshader), ~128 point samples für eine linear_mip_biLanczos-Variante oder wie auch immer man die nennen will (triLanczos wäre wohl wenig sinnvoll). Die momentane 1D-Lanczos-Variante mit den trilinearen Samples nimmt ja im Prinzip auch schon 128 point samples (16 trilineare) pro Pixel, normales tri-AF allerdings nur 4*8=32.

Edit:
Mal ein Update zu den Magnification Filtern:

http://abload.de/img/mag_filter2kpum5.gif

Ist zwar nur eine 256-Farben-Palette im gif, aber man sieht schon, worauf es hinausläuft. Habe ein wenig mit verschiedenen Filterkernelformen rumgespielt. Rund ist schon am besten, quadratische bzw. allgemein eckige Kernel produzieren haufenweise Artefakte (der dort als "square" bezeichnete hat schon abgerundete Ecken, damit es nicht ganz zu übel wird). Die Dinger arbeiten übrigens mit Pointsamples (16 Stück für alle Lanczos-Varianten, die unterscheiden sich nur in der Wichtung) und sollten sich relativ leicht auf die AF-Filter mit dan elliptischem Footprint übertragen lassen. Die kommen dann irgendwann später noch (plus Tent und wide Tent filter für's AF, werden eine Menge Fallunterscheidungen :freak:).