ZFX + Developia

Titel ist Programm. Haben

SetSamplerState(n, ::D3DSAMP_SRGBTEXTURE, TRUE);

und

SetRenderState(::D3DRS_SRGBWRITEENABLE, TRUE);

Wirkung auf die automatische Mip-Map-Erzeugung oder muss ich mich selber um die sRGB-Korrektheit kümmern?

Gruß, Ky

Griff ins Klo wuerd ich sagen....der Treiber wird vorher nicht analysieren, welche Methode es denn sein koennte. Mit dem Format verbandelt ist die Information ja erst in D3D10. Wenn ich wetten müsste, dann ohne sRGB->linear per default und höchstens etwas anderes per "Application Profile".
Testprogramm verteilen und Ergebnisse sammeln gehen? ;)

Bäääh. Meine Hoffnung ist ja, dass das nicht mehr als ein popeliger Shader ist, der da abläuft – für den (bzw. die Textureinheiten und den Output Merger, die er nutzt) müsste sRGB-Korrektur ja auch aktiviert sein, wenn ich vorher die States gesetzt habe und die Chip-Entwickler wären schön blöd, wenn sie für die Mip-Erzeugung Extratransistoren verbauen würden statt die eh vorhandenen Textureinheiten und den Output Merger zu nutzen.

Habe auch schon gesucht und es gibt keine Infos. Mal im DirectX-Forum nachfragen.

Krishty hat geschrieben:bzw. die Textureinheiten und den Output Merger, die er nutzt müsste sRGB-Korrektur ja auch aktiviert sein, wenn ich vorher die States gesetzt habe

Bis zur HW schaffen es die States hoffentlich erst, wenn ein Drawcall folgt.
Woher willst Du wissen, welchen Sampler sie nehmen? Auf gut Glück Nr. 0 ? Oder bei allen das sRGB-Flag setzen? Und die lassen sRGB bestehen, löschen aber ein vorhandenes LOD-Bias ... usw, usw? Viel zu viel raten um ein Loch in der Spec :/

Krishty hat geschrieben:und die Chip-Entwickler wären schön blöd, wenn sie für die Mip-Erzeugung Extratransistoren verbauen würden statt die eh vorhandenen Textureinheiten und den Output Merger zu nutzen.

Hehe, am Ende werden alle HW-Probleme auf den Treiber abgewälzt, eben weil die Chip-Entwickler sparen wo sie koennen.

Krishty hat geschrieben:Habe auch schon gesucht und es gibt keine Infos. Mal im DirectX-Forum nachfragen.

Au ja, und dann erzaehlen sie wieder was von toter API. ( Oder halb-tot, wenn wir an Phone 7 denken...das koennte ein gutes Argument sein *g* )

Jörg hat geschrieben:Viel zu viel raten um ein Loch in der Spec :/

Hast du die vorliegen? Steht tatsächlich nichts darüber drin?

Jörg hat geschrieben:

Krishty hat geschrieben:Habe auch schon gesucht und es gibt keine Infos. Mal im DirectX-Forum nachfragen.

Au ja, und dann erzaehlen sie wieder was von toter API. ( Oder halb-tot, wenn wir an Phone 7 denken...das koennte ein gutes Argument sein *g* )

Sorgen macht mir bei denen nicht das Alter der API, sondern der Anspruch der Frage ;) Nein; bei meiner letzten D3D9-Frage hatten sie sich auch zu einer brauchbaren Antwort erbarmt. Mal gucken.

Rein prinzipiell: Kannst du nicht einfach alle Texturen in normalen linearen Farben auf die Graka laden? Mir fällt irgendwie grad kein Grund ein warum man eine sRGB Textur würde verwenden wollen.

Nein :( Meine User haben vorsintflutliche Hardware, und D3DFMT_A16B16G16R16 scheint nicht weit verbreitet zu sein (die GeForce 6800 z.B. scheitert). Und D3DFMT_A16B16G16R16F kann sowieso von fast keiner Karte gefiltert werden.

Ein zweiter Renderpfad für Karten, die sowohl sRGB-Writes als auch D3DFMT_A16B16G16R16 unterstützen, wäre mir den Aufwand nicht wert.

sRGB ist ein verbreitetes "Kompressionsverfahren". In 8bit Farbtiefe (pro Kanal) sieht sRGB weitaus besser aus als lineare Kodierung.

„verbreitet“ ist gut ;) Dass so ziemlich aller Content in sRGB vorliegt ist ja nicht einmal das Problem; irgendwann muss man seine Ressourcen ja hochladen und kann konvertieren. Übler ist, dass die sRGB-Kurve unten linear und darüber zur 2,4ten Potenz verläuft, man also die 8 Bits sRGB-Input nicht einmal sauber auf 16 Bits abgebildet kriegt :(

Ah ok, sry ich hab irgendwie grad nicht dran gedacht dass bei sRGB die Genauigkeit ja günstiger verteilt ist. Warum aber die automatische Generierung, kannst du die Mip-Maps nicht einfach vorberechnen?

dot hat geschrieben:Warum aber die automatische Generierung, kannst du die Mip-Maps nicht einfach vorberechnen?

Weil die Implementierung dann 22 Zeichen lang ist („D3DUSAGE_AUTOGENMIPMAP“), und nicht fünfzig Zeilen.

Zwischen D3DUSAGE_AUTOGENMIPMAP und Vorberechnen ist doch ein weitaus größerer Unterschied (semantischer Natur) als einfach der Implementierungsaufwand!? Texturen mit D3DUSAGE_AUTOGENMIPMAP sind verschiedensten Einschränkungen unterworfen und du kannst damit effektiv wohl auch nur einen einfachen 2x2 Box-Filter verwenden. Ich würd das nur verwenden wenn ichs brauch (z.B. für irgendwie dynamische Texturen wie z.B. Rendertargets).

dot hat geschrieben:Texturen mit D3DUSAGE_AUTOGENMIPMAP sind verschiedensten Einschränkungen unterworfen

Die sind aber nicht kritischer Natur – ich kann sie samplen, und mehr brauche ich nicht :)

dot hat geschrieben:und du kannst damit effektiv wohl auch nur einen einfachen 2x2 Box-Filter verwenden.

Das ist wiederum deshalb kein Problem, weil ich hier einen Texture Atlas habe und progressive Filter wie Lanczos da mit ihrem Bleeding mehr kaputtmachen als der klassische Box-Filter :/ Ich schramme mit den Mip-Levels generell schon immer knapp an spürbarer Bleeding-Kantenbildung vorbei – ein Filter mit mehr als 2×2 Samples fordert da so viele Kolleteralschäden als würden meine Texturen Hochzeitsgesellschaften zeigen.

Gerade für einen Atlas ist D3DUSAGE_AUTOGENMIPMAP doch total unbrauchbar weil früher oder später benachbarte Bilder ineinander geblurred werden!?

Ich kenne die Auslegung des Atlas aber (vorerst) nicht einmal. Es ist nicht mein Content; ich bin nur die arme Sau, die ihn rendern muss ;)

Ok, das ist auf gut deutsch Scheisse ;)

Krishty hat geschrieben:Titel ist Programm. Haben
SetSamplerState(n, ::D3DSAMP_SRGBTEXTURE, TRUE);
und
SetRenderState(::D3DRS_SRGBWRITEENABLE, TRUE);
Wirkung auf die automatische Mip-Map-Erzeugung oder muss ich mich selber um die sRGB-Korrektheit kümmern?

Ganz dumm gefragt, aber hast du es einfach einmal ausprobiert? Testtextur machen, einmal per Hand die Mipmap Gamma-korrekt berechnen; einmal auf die GPU als sRGB-Textur laden, mit DirectX berechnen und anzeigen lassen (einfach die Mipmapstufe samplen). Vergleichen. ????? Profit. Naja, halbwegs zumindest.

Um ehrlich zu sein vermute ich dass das nicht wirklich funktionieren wird. Zumindest seh ich in der D3D9 API keinen Weg um das wohldefiniert zu erledigen, denn das Flag da ist ein Sampler State und du hast keinen Einfluss drauf welchen Sampler die Graka zum Generieren der Mip-Maps verwendet...

eXile hat geschrieben:Ganz dumm gefragt, aber hast du es einfach einmal ausprobiert? Testtextur machen, einmal per Hand die Mipmap Gamma-korrekt berechnen;

Das zu implementieren will ich ja gerade vermeiden :) Wenn es erstmal drin ist, kann ich es entweder gleich wieder löschen weil es überflüssig ist oder gleich ganz auf automatische Mips verzichten.

Und ganz banal mit linearem Sampling an und aus zu testen ist natürlich auch keine Möglichkeit, weil dann direkt alles anders aussieht.

Es kotzt mich einfach an, dass sowas nirgends dokumentiert ist. Aber -- Jörg und dot -- die Argumentation, dass Sampler-States nicht zwangsweise mit Mip-Map-Erzeugung zu tun haben muss, ist schon ziemlich stichhaltig. Ich warte noch ein Bisschen ob Antwort von den D3D-Devs kommt und fange dann wohl oder übel an, es selber zu implementieren :?

Mal dumm gefragt: Welchen Sinn hat sRGB? Wenn ich den Artikel bei Wikipedia über sRGB lese, sehe ich bei sRGB überhaupt keinen Sinn...

sRGB wurde seinerzeit für die CRT-Monitore des Jahres 1996 entwickelt

Nunja, wir haben ja auch nicht erst 15 Jahre später.

Über geeignete RGB-Farbräume wird unter Anwendern häufig diskutiert. sRGB wird teils wegen seines kleinen Gamut kritisiert. Einige vom Auge sichtbare Farben, die etwa in CMYK noch darstellbar sind, sind hier nicht darstellbar.

Wozu also liegt der Sinn bei sRGB?

DomiOh hat geschrieben:Wozu also liegt der Sinn bei sRGB?

Beim Rendering brauche ich einen linearen Farbraum, wo ein doppelt so großer Farbwert die doppelte Lichtmenge bedeutet.

Das ist bei 8-Bit-pro-Farbe-Texturen aber nicht so. Der doppelte Farbwert bedeutet dabei so in etwa die vier- bis fünffache Lichtmenge, die das Auge erreicht, weil das Auge nichtlinear arbeitet.

Fast aller Content, den du siehst oder kriegst, liegt in einem nichtlinearen Farbraum vor. So ziemlich jede Textur, die du jemals geladen hast; jedes Bild, das du jemals auf deiner Festplatte hattest; dein Desktop inklusive dieser Website. Weil man sonst so ungefähr 18 Bits pro Kanal brauchen würde, um den Helligkeitsumfang mit derselben Qualität linear abzubilden.

sRGB hat zwar einige Schwächen, weil er aber der am weitesten verbreitete Farbraum ist, und noch dazu international standardisiert, unterstützen GPUs das Laden und Schreiben von sRGB in Hardware, und Windows sowie dein Monitor arbeiten bei der Bildanzeige in diesem Modus. Wann immer du also 24-Bit-RGB renderst: the data better be sRGB.

Such einfach mal nach HDR Rendering und Linear Space; das Thema ist eigentlich enorm umfangreich und es ist zu viel, um es hier zu erklären. :)

Wenn ich ein Bild male in Paint, auf einem Monitor der sRGB verwendet, dann liegt das resultierende Bild doch in einfachem, linearen RGB vor außer es würde extra umgerechnet!?

dot hat geschrieben:Wenn ich ein Bild male in Paint, auf einem Monitor der sRGB verwendet, dann liegt das resultierende Bild doch in einfachem, linearen RGB vor außer es würde extra umgerechnet!?

Nö. Du suchst die Farben, die du zum Malen benutzt, ja über die Farbtabelle aus. Und die wird in sRGB gerendert. Also muss auch das Bild woanders mit sRGB gerendert werden, damit es dort genauso aussieht wie in Paint. Darum ist alles, was du malst, sRGB. (Natürlich gesetzt dem Fall, du benutzt nicht nur Schwarz und Weiß ;) )

Eben, sie wird in sRGB gerendert, die Transformation von linear nach sRGB erledigt aber das Anzeigesystem, die Farbwerte an sich müssen also linear vorliegen. Ich male also nach dem was ich in sRGB sehe aber die Farbwerte in den Buffern sind trotzdem linear!?

dot hat geschrieben:Eben, sie wird in sRGB gerendert, die Transformation von linear nach sRGB erledigt aber das Anzeigesystem

Umgekehrt. Sie liegen nichtlinear als sRGB vor (Gamma = ca. 2,2; "250" erscheint doppelt so hell wie "125") und die Transformation zu linearen Werten (Gamma = 1.0; 300 cd÷m² auf deinem Bildschirm für "250" werden als doppelt so hell empfunden wie 60 cd÷m² für "125" (Zahlen geraten)) erledigt das Anzeigesystem.

Kann es sein, dass du „linear“ falsch verstehst? Das ist, wo Gamma 1 ist und die doppelte Größe die doppelte Lichtmenge bedeutet – also nicht sRGB, wo Gamma im Schnitt 2,2 ist und die doppelte Größe die doppelte wahrgenommene Helligkeit bedeutet. :)

Wir kriegen die Daten mit Gamma von durchschnittlich 2,2 rein (z.B. als Texturen von Photoshop), rendern mit Gamma = 1,0 (im linearen Farbraum), geben sie mit Gamma = ca. 2,2 an den Anzeigentreiber weiter, Farbprofil und Hardware wandeln das in Leuchtdichten von Gamma = 1,0 um, und die nimmt unser Auge dann wieder mit einem Gamma von irgendwo zwischen 1 und 3 (je nach Beleuchtungssituation) wahr.

Man kann den letzten Absatz von Krishty sogar noch allgemeiner fassen: Du hast eine Eingabedatei In mit Farbprofil A und ein Ausgabegerät Out mit Farbprofil B. Um In also farbtreu anzeigen zu lassen, macht man:
Out = B · A^-1 · In

Kann es aber sein, dass das zuweisen eines Farbprofils an einen Grafikkartenausgang ziemlich eingeschränkt ist? So weit ich weiß, kann man nur für jeden RGB-Kanal einzeln eine 256 Einträge große Tabelle festlegen, aber es gibt keine ganze 256³ Einträge große Tabelle. Schnelles Nachrechnen ergibt für letztere eine Größe von 48 MiB.

Ach, du hast natürlich recht, ich hab mich verwirren lassen ;)

eXile hat geschrieben:Kann es aber sein, dass das zuweisen eines Farbprofils an einen Grafikkartenausgang ziemlich eingeschränkt ist? So weit ich weiß, kann man nur für jeden RGB-Kanal einzeln eine 256 Einträge große Tabelle festlegen, aber es gibt keine ganze 256³ Einträge große Tabelle.

iirc sinds zumindest mit DXGI mittlerweile 1024 Einträge (Bildschirme unterstützen oft schon 10bit) pro Kanal , aber ja, kein vollständiger RGB Würfel, wenn man an Alignment und so denkt müsste man für den vermutlich sogar 64MB veranschlagen...

http://en.wikipedia.org/wiki/Windows_Color_System hat geschrieben:The color processing pipeline allows device developers to add their own gamut mapping algorithm into the pipeline to customize the color response of the device.

Der Artikel sagt explizit, dass LCDs unterstützt werden – fragt mich aber nicht, wie das mit der GPU und der horrenden Bilddatenmenge gehen soll. Ich kann mir auch sehr gut vorstellen, dass die Daten zu XYZ und wieder zurück konvertiert werden, wo Tonkorrekturen weitaus einfacher möglich sind. Ist dann zwar immernoch kein vollständiger Farbwürfel, aber man kommt schon näher dran.

Oder benutzt man ICC-Profile?

http://en.wikipedia.org/wiki/ICC_profile hat geschrieben:Profiles describe the color attributes of a particular device or viewing requirement by defining a mapping between the device source or target color space and a profile connection space (PCS). This PCS is either CIELAB (L*a*b*) or CIEXYZ. Mappings may be specified using tables, to which interpolation is applied, or through a series of parameters for transformations.