(erledigt) HDR-Texturfilterung

[Krishty]

Hi,

Mal wieder eine Frage zu HDR-Rendering. Diesmal betrifft es die Texturfilterung: wie filtert man Texturen, die im Linear-Space vorliegen, korrekt?

Texturen, die mit Gammakorrektur vorliegen, werden zwischen den Texeln linear interpoliert. Werden sie nach dem Sampling im Shader in den Linear-Space konvertiert, wird diese Interpolation nichtlinear – beim Tonemapping wird das aber wieder ausgeglichen und der endgültige Helligkeitsverlauf ist wieder linear. Es sieht aus, wie man es gewohnt ist:

Textur mit Gamma

HDR-Texturen, die bereits im Linear-Space vorliegen, werden zwischen den Texeln ebenfalls linear interpoliert. Da sie aber im Shader nicht mehr nachkorrigiert werden müssen, ist der endgültige Helligkeitsverlauf nach Tonemapping nichtlinear, es bilden sich Blöcke:

Lineare Textur

Wie kann man Blockbildung bei Filterung von Texturen im Linear-Space vermeiden?

Gruß, Ky

[Jörg]

Ja, das ist komisch. Welches API verwendest Du (D3D9 oder 10) und welche Karte?
SRGB-Texturen sollten (sofern entweder der Renderstate oder das Format richtig gesetzt sind, vor dem Filtern linearisiert werden, bei DX9 darf es aber auch mal andersrum sein)...

[Schrompf]

Das ist mathematisch das korrekte Ergebnis... aber ich habe keine Ahnung, wie man dem beikommen könnte. Außer das Filtern selbst im PixelShader zu machen. Und das dürfte kaum erstrebenswert sein.

[Krishty]

Welches API verwendest Du (D3D9 oder 10) und welche Karte?

D3D11 mit SM 4.1 auf einer Radeon HD 4850.

Ja, das ist komisch. […] SRGB-Texturen sollten (sofern entweder der Renderstate oder das Format richtig gesetzt sind, vor dem Filtern linearisiert werden, bei DX9 darf es aber auch mal andersrum sein)...

Eigentlich ist es perfekt logisch, weil es sich nicht um sRGB-Texturen handelt (die werden für MDR- und HDR-Formate wie DXGI_FORMAT_R16G16B16A16_FLOAT nicht angeboten. In diesem Format sind auch die Texturen auf den beiden Screenshots).

Das ist mathematisch das korrekte Ergebnis... aber ich habe keine Ahnung, wie man dem beikommen könnte. Außer das Filtern selbst im PixelShader zu machen. Und das dürfte kaum erstrebenswert sein.

Ja, man müsste quasi das Ergebnis des Tonemappings schon beim Samplen der Texturen kennen … die Sache ist aber, dass das mit der zunehmenden Verbreitung von HDR immer relevanter werden müsste. Anisotropes Filtern z.B. wird auf linearen Texturen auch problematisch werden – ich habe es noch nicht testen können, aber es wird sicher eine Klasse hinter gammakorrigierten Texturen zurückbleiben … über Kurz oder Lang muss also eine Lösung her.

Ich habe schon Google bemüht, allerdings wird meine Suche immer als „linear texture filtering“ misinterpretiert, weil die Ähnlichkeit eben zu groß ist :(

[Jörg]

Ah du konvertierst _im_ Shader nach, das hab ich ueberlesen, und damit ist ja alles korrekt(bzw. so wie dargestellt).
Warum konvertierst Du nicht die Texturen vorher (die LDRs) ? Dann erhaeltst Du bei beiden das gleiche Ergebnis (im Einklang mit den Methoden zum Alphablenden im linearen Space), sparst den Shader-Befehl und kannst evtl. dein Tonemapping mit einer nachgeschalteten Gamma-Korrektur in den Griff bekommen?

[Krishty]

Warum konvertierst Du nicht die Texturen vorher (die LDRs) ?

Wie meinen? Die Texturen offline in den Linear-Space konvertieren? Dann kommt dabei die Blockbildung von Screenshot zwei raus.

[Jörg]

Ja freilich, aber dann waeren beide Faelle identisch im Ergebnis (ist ja auch was...). Wie gesagt, was "richtig" und "falsch" ist, kann man nicht so einfach sagen (ganz aus der Luft gegriffen sind ja die Annahmen von DX und OpenGL bezueglich "erst linearisieren, dann filtern" nicht).

[Krishty]

Okay, aber welche Möglichkeiten - abgesehen von Supersampling und einem 2x2er-Gauss über jede Textur - gibt es, um mit linearen Texturen die gleiche befriedigende Bildqualität zu erreichen wie mit konventionellen Texturen bei LDR-Rendering?

Antialiasing hat ja genau das gleiche Problem ... aber es ist lösbar, indem man die Samples erst nach dem Tonemapping auflöst. Beim Texture-Filtering findet diese Auflösung der einzelnen Samples aber schon beim Laden statt ...

[Jörg]

Wie du sagst, SuperSampling der Texturen (sprich einfach ne hoehere Aufloesung bereitstellen, richtig kritisch wird es ja nur bei extremen Unterschieden der Pixel) ist wohl der Standardweg. Jede Engine, die heute was auf sich haelt, bietet Streaming (oder aufloesungsflexible prozedurale Generierung) von Texturen, so nach dem Motto: Wenn es stoert, kommt ein Texturelevel mehr dazu.
Wie sehr macht sich der Unterschied denn in einer echten Umgebung bemerkbar?

[Krishty]

Wie du sagst, SuperSampling der Texturen (sprich einfach ne hoehere Aufloesung bereitstellen, richtig kritisch wird es ja nur bei extremen Unterschieden der Pixel) ist wohl der Standardweg. Jede Engine, die heute was auf sich haelt, bietet Streaming (oder aufloesungsflexible prozedurale Generierung) von Texturen, so nach dem Motto: Wenn es stoert, kommt ein Texturelevel mehr dazu.

Mehr Texel sind ja auch nicht zwingend besser, denn der Mag-Filter wird genauso sperrige Ergebnisse erzeugen wie der Min-Filter (es ist zwar nicht mehr blockig, aber es flimmert mehr (okay, wenn man sich so manche Engine anschaut, stört das wohl keine Sau außer mir)). Andersrum, man muss die Auflösung beibehalten und den Inhalt der Textur eine Stufe runterschalten, damit er niederfrequenter wird.

Wie sehr macht sich der Unterschied denn in einer echten Umgebung bemerkbar?

Das interessiert mich auch brennend, sobald ich (heute abend) an ein fähiges System komme, teste ich das.

[Krishty]

Voilà l´sRGB:

Et linéaire:

Die Textur habe ich auf die Schnelle aus dem Internet geklaut, skaliert (kubisch von 1029×1000 auf 1024×1024) und einen leichten Blur drübergejagt (Gauss von 0,7 Pixel, weil die Kanten beim Original geschärft waren), sie ist also garnicht mal sooo hochfrequent …

… beim Großteil der Textur ist der Unterschied tatsächlich verschwindend gering (und das Ausschwimmen der hellen Bereiche fällt kaum auf), trotzdem sehen die Konturen bei der linearen Version aus wie Point-Filtering.

Ich kam leider noch nicht dazu, Mip-Mapping zu implementieren, lasst also die Ränder der Kugel unbeachtet!

Und hier nochmal die ungnädigere 512×512-Version, sRGB:

Und linear:

Da kommt es dann aber wirklich durch, da wird das Bleeding der hellen Flächen auch langsam zum Problem.

[Zudomon]

Also um ehrlich zu sein, so extrem finde ich das nicht, als das ich dafür extra Rechenzeit wie etwa eigenes Filtern in kauf nehmen würde. ;)
Aber vielleicht könntest du ja mal Differenzbilder hochladen.

[Schrompf]

Jupp, ich sehe da auch keinen Unterschied, der es nach meinem Empfinden wert wäre, dafür Fillrate zu opfern. Aber ich erinnere mich, dass Du da etwas anspruchsvoller bist :-)

[Krishty]

Aber vielleicht könntest du ja mal Differenzbilder hochladen.

Beide Bilder in Tabs öffnen, ein Tab markieren und dann mit den Pfeiltasten hin- und herswitchen, meine Güte ;)

Aber nagut, weil ihr es seid, 1024²

und 512²

Habe einfach beide Bilder im Gimp eingefügt und als Blend-Methode „Difference“ ausgewählt – ich hoffe, das war richtig.

Bis zu Helligkeitssprüngen von rund 50% ist wirklich kaum etwas erkennbar … darüber geht es aber dann in Richtung Point-Filtering.

[Jörg]

Danke für die Arbeit, aber ich könnte damit leben :) Sieht bei weitem nicht so grässlich aus wie die Laborbeispiele ...

[Krishty]

Okay, wenn ihr da geschlossen keinen Handlungsbedarf seht, sollte ich es wohl dabei belassen … jedenfalls wieder mal danke für die Beratung :)

[Zudomon]

Aber vielleicht könntest du ja mal Differenzbilder hochladen.

Beide Bilder in Tabs öffnen, ein Tab markieren und dann mit den Pfeiltasten hin- und herswitchen, meine Güte ;)

Das ist mir schon klar, aber so ein Differenzbild ist meiner Meinung nach Aussagekräftiger.

Aber auch hier muss ich sagen, der Unterschied ist garnicht so extrem groß.
Kannst dir das ja auf deine ToDo Liste an letzter Stelle schreiben. :D