Archiv verlassen und diese Seite im Standarddesign anzeigen : Framebuffer: RGB oder sRGB?
Mir ist nicht ganz klar, ob der Framebuffer RGB- oder sRGB-Werte speichert.
Normale 32-Bit-Texturen werden vermutlich sRGB-kodiert vorliegen. Werden die linearisiert bevor gefiltert wird?
Wenn das nicht getan wird, wird falsch gefiltert (und falsch gemippt.) Wenn das getan wird, muss aber für die Framebuffer-Darstellung zurückgerechnet werden.
Öhm der Framebuffer speichert ganz normal RGBA, sRGB ist doch was ganz neues und steht nur als spezielles Texturformat zur Verfügung.
Demirug
2005-01-16, 21:30:48
Das ganze ist relative heftig.
Texturen:
Bisher war es den Karten eigentlich egal wie die Texturen gespeichert sind sie gingen davon aus das sie linear sind. Seit DX9 gibt es aber jetzt pro Sampler ein Flag mit dem man kontrolieren kann ob eine Umwandlung von sRGB in den linearen Farbraum vorgenommen werden soll. Dieses Flag darf aber von der Hardware ignoriert werden. Damit man weiss ob sie es tut kann man für jedes Textureformat abfragen ob das Flag berücksichtigt wird oder nicht.
Die Umwandlung ist an einer von 3 Stellen erlaubt.
- Direkt an den Texturedaten im Videospeicher.
- Beim Einladen vor dem Filtern.
- Nach dem Filtern.
Render Targets:
Hier gilt ähnliches wie bei den Texturen. Vor DX9 wird immer das was aus der Pipeline kommt direkt gespeichert. Seit DX9 kann nun auch beim schreiben kontrolliert werden ob eine Umwandlung durchgeführt werden soll. Auch hier gilt wieder das man vorher feststellen muss welche Formate dies unterstützen.
Dabei wird gewünscht das die Umrechnung nach dem Alphablending durchgeführt wird. Es ist allerdings auch nicht verboten dies im Pixelshader oder direkt danach zu erledigen.
Framebuffer:
Dieser speichert normalerweise Werte im linearen Farbraum. Man kann im Pixelshader eine Umrechnung vornehmen. Allerdings funktioniert dann das Alphablending nicht mehr richtig.
Öhm der Framebuffer speichert ganz normal RGBA, sRGB ist doch was ganz neues und steht nur als spezielles Texturformat zur Verfügung.Wenn der Framebuffer lineares RGB speichert, müssten die Werte vor der Ausgabe umgerechnet werden, damit sie für eine Gamma-Korrektur von 1,0 (also gar keiner Gamma-Korrektur) richtig (mit implizierter 2,2-Charakteristik) angezeigt werden.
sRGB ist aber nicht "ganz neu" :)
Texturen:
Bisher war es den Karten eigentlich egal wie die Texturen gespeichert sind sie gingen davon aus das sie linear sind.Das hatte ich befürchtet.
Framebuffer:
Dieser speichert normalerweise Werte im linearen Farbraum. Man kann im Pixelshader eine Umrechnung vornehmen. Allerdings funktioniert dann das Alphablending nicht mehr richtig.Eben. Allerdings verschenkt man Auflösung im wichtigen (dunklen) Bereich, wenn linear in RGB gespeichert wird.
Demirug
2005-01-16, 23:22:50
Eben. Allerdings verschenkt man Auflösung im wichtigen (dunklen) Bereich, wenn linear in RGB gespeichert wird.
Ja, aber versuche mal ein Spiel vernüpftig ohne Alphablendig zu programmiereen. Dann müsste man Textur/RT Ping-Pong spielen. Keine gute Idee bei all den Nachteilen.
Es gibt ja einige Methode die Auflösung des Farbraums zu erweitern aber alle haben Nachteile. Bei den meisten verliert man das AA.
Ja, aber versuche mal ein Spiel vernüpftig ohne Alphablendig zu programmiereen. Dann müsste man Textur/RT Ping-Pong spielen. Keine gute Idee bei all den Nachteilen.
Es gibt ja einige Methode die Auflösung des Farbraums zu erweitern aber alle haben Nachteile. Bei den meisten verliert man das AA.Mein Vorschlag ist natürlich, einen FP16-Framebuffer zu nehmen – jedoch gleichzeitig auch AA zu ermöglichen :)
Der Alphablender müsste ansonsten die sRGB-De- und Re-Konvertierung vornehmen.
Demirug
2005-01-16, 23:52:08
Mein Vorschlag ist natürlich, einen FP16-Framebuffer zu nehmen – jedoch gleichzeitig auch AA zu ermöglichen :)
Dafür müssten die Karten aber entweder FP16 als Framebuffer Format anbieten oder endlich mal Render Targets mit AA anbieten.
Der Alphablender müsste ansonsten die sRGB-De- und Re-Konvertierung vornehmen.
Das ist ja auch von MS so gewüscht aber eben keine Plicht.
Die Umwandlung ist an einer von 3 Stellen erlaubt.
- Direkt an den Texturedaten im Videospeicher.
- Beim Einladen vor dem Filtern.
- Nach dem Filtern.
Ich gehe doch davon aus dass WGF2.0 nur noch das zweite erlaubt.
Dieser speichert normalerweise Werte im linearen Farbraum. Man kann im Pixelshader eine Umrechnung vornehmen. Allerdings funktioniert dann das Alphablending nicht mehr richtig.
Das würde ich so nicht sagen. "Normalerweise" speichert der Framebuffer irgendeinen Mischmasch aus sRGB-Texturdaten, die im Pixelshader linear verrechnet wurden, weil sich kaum ein Spiel darum kümmert welcher Farbraum benutzt wird. Deswegen kann es sich ATI ja auch erlauben, beim AA davon auszugehen dass sRGB-Werte im Framebuffer stehen. Inkonsequenterweise ist das Alpha-Blending aber linear...
Warum unterscheidest du hier zwischen Render Target und Framebuffer?
Eigentlich gibt es nur zwei "korrekte" Wege. Entweder Farbdaten als sRGB speichern und dann bei jedem Lese-/Schreibvorgang konvertieren (Filtern, Alpha-Blending, AA-Downsampling. Oder Farbdaten linear speichern und nichts konvertieren - aber mindestens mit FP16.
Wenn der Framebuffer lineares RGB speichert, müssten die Werte vor der Ausgabe umgerechnet werden, damit sie für eine Gamma-Korrektur von 1,0 (also gar keiner Gamma-Korrektur) richtig (mit implizierter 2,2-Charakteristik) angezeigt werden.Mmm ja logisch, aber das macht doch der RAMDAC. Gespeichert wird RGB...
Uhm. Irgendwie komm ich mir grad ziemlich doof vor. sRGB bedeutet doch dass man zusätzlich nen Exponenten im Framebuffer speichern würde?
Das ist aber definitiv nicht so...
EDIT: Ah, ich hab das mit RGBE verwechselt :rolleyes:
Demirug
2005-01-17, 06:28:33
Das würde ich so nicht sagen. "Normalerweise" speichert der Framebuffer irgendeinen Mischmasch aus sRGB-Texturdaten, die im Pixelshader linear verrechnet wurden, weil sich kaum ein Spiel darum kümmert welcher Farbraum benutzt wird. Deswegen kann es sich ATI ja auch erlauben, beim AA davon auszugehen dass sRGB-Werte im Framebuffer stehen. Inkonsequenterweise ist das Alpha-Blending aber linear...
Warum unterscheidest du hier zwischen Render Target und Framebuffer?
Die Unterscheidung macht MS also muss ich sie auch machen.
Die Unterscheidung macht MS also muss ich sie auch machen.
Hm, wieso? D3DRS_SRGBWRITEENABLE gilt doch wenn das Zielformat sRGB Writes unterstützt, egal ob Framebuffer oder nicht.
Demirug
2005-01-17, 15:12:32
Hm, wieso? D3DRS_SRGBWRITEENABLE gilt doch wenn das Zielformat sRGB Writes unterstützt, egal ob Framebuffer oder nicht.
Bei dem ganzen Gamma Zeug wird aber explizit angegeben das wenn man in den Framebuffer sRGB schreiben möchte man dazu den Pixelshader bemühen soll.
Applications can gamma-correct the colors written into the frame buffer using pixel shader instructions. The linearization should be applied only to the RGB channels and not to the alpha channel.
Ich werde am besten mal ausprobieren was mein NV40 und der Refrast zu dem Thema SRGB Write in den Framebuffer sagt.
zeckensack
2005-01-17, 19:13:43
Eigentlich gibt es nur zwei "korrekte" Wege. Entweder Farbdaten als sRGB speichern und dann bei jedem Lese-/Schreibvorgang konvertieren (Filtern, Alpha-Blending, AA-Downsampling. Oder Farbdaten linear speichern und nichts konvertieren - aber mindestens mit FP16.Ich bin bekanntermaßen ein Freund der zweiten Variante. Hatten wir ja schon bei diversen Gelegenheiten.
Ich bin mal wieder nicht davon überzeugt, dass dafür 8bpc nicht ausreichen sollen.
http://img60.exs.cx/img60/7733/linear3ls.th.png (http://img60.exs.cx/my.php?loc=img60&image=linear3ls.png)
Siehst du da irgendwo Banding, wenn du dein Desktop-Gamma linearisierst? Also ich nicht ...
Siehst du da irgendwo Banding, wenn du dein Desktop-Gamma linearisierst? Also ich nicht ...Bei solch (räumlich) kleinen Farbverläufen kaum. Bei größeren Farbverläufen wird die Banding-Gefahr größer.
Das kannst du auch bis 1600 breit treiben und wirst kein Banding sehen...
Das kannst du auch bis 1600 breit treiben und wirst kein Banding sehen...Der Mensch kann Millionen Helligkeitsstufen unterscheiden. Selbst wenn es nur tausende wären: 256 linear abgestufte Graustufen auf einen genügend großen Bereich ausgedehnt führt zwangsläufig zu Banding.
Der Mensch kann Millionen Helligkeitsstufen unterscheiden. Selbst wenn es nur tausende wären: 256 linear abgestufte Graustufen auf einen genügend großen Bereich ausgedehnt führt zwangsläufig zu Banding.
Millionen? Tausende?
Hast du dafür irgendwo nen Link?
Afaik sind ~40 Graustufen.
Also alles was gut is aber ich erkenne auf voller 1600er Monitorbreite bei einem 0-255 Graustufenverlauf keinerlei Banding.
Ist auch relativ logisch. Wenn man bei einem z.B. 512 pixel breiten kein Banding sieht dann sieht man auch bei 1600 keins, denk mal drüber nach.
Millionen? Tausende?
Hast du dafür irgendwo nen Link?
Afaik sind ~40 Graustufen.Einen Link habe ich nicht. Das habe ich vor vielen Jahren, noch zu Ost-Zeiten, in einem Buch in einer Bibliothek gelesen.
40 Graustufen sind klar zu wenig. VGA erlaubt 64 Abstufungen (6 Bit pro RGB-Kanal) und das ist sehr deutlich zu sehen.
Also alles was gut is aber ich erkenne auf voller 1600er Monitorbreite bei einem 0-255 Graustufenverlauf keinerlei Banding.
Ist auch relativ logisch. Wenn man bei einem z.B. 512 pixel breiten kein Banding sieht dann sieht man auch bei 1600 keins, denk mal drüber nach.*Denk denk* Ich komme zur Konklusion, dass das 512-er Beispiel für die Breite von 1600 Pixeln nicht besonders aussagekräftig ist.
Bei der Gesamtbreite von 512 hast du pro Stufe 2 Pixel Breite. Die räumliche Auflösung ist recht gering, da laufen die Stufen dann ineinander über. Der Mensch erkennt Details auf größeren Flächen besser.
Das wird auch in der Optik ausgenutzt, z. B. bei astronomischen Fernrohren. Manchmal geht man über die maximale sinnvolle Vergrößerung. Das Bild wird dunkler und flauer und löst eigentlich keine neuen Details mehr auf, doch dank der gewonnenen Fläche kann man kleine Details besser erkennen.
Für das Auflösungsvermögen von Fernrohren wird meistens als Kritierum herangezogen, wie weit zwei gerade noch trennbare gleichhelle Sterne auseinander stehen müssen. Auf dem Mond erkannte ich jedoch noch Krater, für die ich spürbar höher auflösen müsste (dank Kenntnis der Kratergröße und Abstand Erde-Mond ließ sich das in ein Winkelmaß umrechnen) – in der Fläche ist es nun mal anders.
Ab 6 Pixel Breite pro Stufe sehe ich auf meinem TFT sehr gut das Banding. Auch auf dem CRT (gerade getestet) – die Gesamtbreite ist dabei unter 1600 für den kompletten Farbverlauf.
zeckensack
2005-01-17, 23:37:37
Hmmm ...
Bei 300% Zoom (vernünftige Browser bieten diese Option) wird Banding im dunkelsten Bereich tatsächlich sichtbar, wenn man Gamma aufdreht.
Hmmm, hmmm, hmmm. Punkt für XMas.
Btw, ich entschuldige mich dafür dass das Bild gedithert ist. Da hat GIMP wohl mehr gemacht als ich eigentlich wollte.
Ich bin bekanntermaßen ein Freund der zweiten Variante. Hatten wir ja schon bei diversen Gelegenheiten.
Ich bin mal wieder nicht davon überzeugt, dass dafür 8bpc nicht ausreichen sollen.
http://img60.exs.cx/img60/7733/linear3ls.th.png (http://img60.exs.cx/my.php?loc=img60&image=linear3ls.png)
Siehst du da irgendwo Banding, wenn du dein Desktop-Gamma linearisierst? Also ich nicht ...
Schön, ein geditherter Farbverlauf. Bei Standard-Gamma (also so dass sich eine Gamma-2,2-Charakteristik ergibt) sehe ich hier kein Banding. Linearisiere ich allerdings, dann sehe ich im dunklen Bereich noch Banding - trotz Dithering.
Von Dithering halte ich allerdings nicht viel. Hier mal ein Beispiel ohne Dithering, 3 lineare Farbverläufe (0-63, 0-127, 0-255) mit Kalibirierungshilfe.
Bild (http://www.xm45.de/Bilder/greyscale.png)
Als Alternative für FP16 würde mir noch RGBE sinnvoll erscheinen.
Für einen linearen Framebuffer (unabhängig vom Format) müsste ATI aber auch das "gamma-korrigierte" AA im CP abschaltbar machen.
Übrigens, auf meinem Notebook-Display sah ich gleich Banding. Unzureichende Farbauflösung eben.
Ich muss echt blind sein. Aber bei meinem kalibrierten Monitor kann ich bei bestem Willen kein Banding sehen.
Edit: Ach Photoshop Dithert auch... doofe Sache woher bekomm ich jetzt nen "richtiges" Bild, das von XMas ist down ;)
Aber mal ernsthaft: Bei normalen Gammawerten sollte man wirklich nichts erkennen können was FP16 rechtfertigt.
Tesseract
2005-01-18, 00:28:24
mein monitor ist mit einem gamma von ~1,65-1,75 linear und dann sehe ich am ditherbild schräges banding sowie einen leichten... dither eben ;)
und am justierbild gerades banding (größe 1:1)
kann ich daraus jetzt irgendeine erkenntnis gewinnen? :D
zeckensack
2005-01-18, 00:39:56
Aber mal ernsthaft: Bei normalen Gammawerten sollte man wirklich nichts erkennen können was FP16 rechtfertigt."Normale" Gammawerte sind pöse, weil nicht linear. Alles was linear sein sollte (Blending, Texturfilter, Farbinterpolation, pipapo) ist dann ebenfalls krumm.
Das zu beheben ist ja gerade der Sinn von sRGB. Der Punkt ist, dass man sich sRGB und den ganzen (Hardware-)Aufwand an die Backe schmieren kann, wenn man mit der Gammarampe den Framebuffer linearisiert. Dem steht allerdings die zu geringe Auflösung im Dunkelbereich von linearen 8bpc im Wege, die wir gerade eben nachgewiesen haben.
Ja, da is wohl noch viel zu tun in dieser Richtung. Wir sollten uns lineare Augen einbauen lassen ;)
zeckensack
2005-01-18, 01:04:50
Ja, da is wohl noch viel zu tun in dieser Richtung. Wir sollten uns lineare Augen einbauen lassen ;):conf2:
Das hat doch mit den Augen nichts zu tun. Es ist wurscht ob die Augen linear sind oder nicht, Menschen haben Hirne um sowas zu kompensieren :ugly:
Doppelter Wert im Framebuffer muss doppelte (physikalische, messbare) Helligkeit ergeben, sonst läuft was falsch. Und es läuft nunmal traditionell sehr falsch.
Naja der Mensch sieht eben nicht linear, das ist doch das "Problem" an der Sache.
Naja der Mensch sieht eben nicht linear, das ist doch das "Problem" an der Sache.Das Problem ist die ungleiche Verteilung des Quantisierungsrauschen bei linear gespeicherten Werten. Gerade bei MUL-Operationen haben wir schnell kleine Werte und müssen auch die kleinen Werte immer auf das nächstliegende Bit runden. Da setzt sRGB an. sRGB ist aber lediglich zur Speicherung gedacht, die Operationen müssen höher aufgelöst erfolgen, und natürlich linear. Absolute Fehler wie Quantisierungsrauschen auf linear gestaffelte Werte beeinträchtigen kleine Werte (dunkle Farben) besonders stark.
Aber mal ernsthaft: Bei normalen Gammawerten sollte man wirklich nichts erkennen können was FP16 rechtfertigt.Bei mir ists Wurscht, ob Gamma-Charakteristik von 2,2 (Windows-Standard) oder 1,0 (linear) immer sehe ich hier oder dort ein Banding, wenn die 256 Stufen auf 5 (besser 6) Pixel pro Stufe ausgedeht werden.
zeckensack
2005-01-18, 01:24:57
Naja der Mensch sieht eben nicht linear, das ist doch das "Problem" an der Sache.Nein, eben nicht.
Wenn du zwei identische Lampen aus gleicher Entfernung auf die gleiche Tapete leuchten lässt, dann ist das reflektierte Licht doppelt so stark wie bei nur einer Lampe. Das ist die physikalische Realität, und die gilt es zu simulieren, egal ob das für's Auge nun auch exakt doppelt so hell aussieht.
Nein, eben nicht.
Wenn du zwei identische Lampen aus gleicher Entfernung auf die gleiche Tapete leuchten lässt, dann ist das reflektierte Licht doppelt so stark wie bei nur einer Lampe. Das ist die physikalische Realität, und die gilt es zu simulieren, egal ob das für's Auge nun auch exakt doppelt so hell aussieht.Genau. sRGB ist ein günstiges Format zur Speicherung, nicht zur (linearen) Verarbeitung.
vBulletin®, Copyright ©2000-2025, Jelsoft Enterprises Ltd.