Gammakorrigiertes MSAA - Was bewirkt es?

[puntarenas]

Wenn Du mal in das ControlPanel schaust, dann müsstest Du in den 3D-Einstellungen sehen, dass per Default "AntiAliasing Gamm-Korrektur" aktiviert ist. Den genauen Hintergrund möge Dir jemand anderes erklären, aber im Prinzip wird versucht, die durch das AA entstehenden zusätzlichen "Stufen" natürlicher zu gestalten, indem man mehr Farbwerte der Umgebung heran zieht (naiv formuliert).


"Natürlicher" wird da nichts gestaltet, es wird nur versucht, die Farbanpassung monitorverträglicher zu gestalten. Je nach Monitor erhält man mit oder ohne Gammakorrektur das bessere Ergebnis:

Gamma-corrected Anti-Aliasing

Dieses Feature wurde ebenfalls mit der GeForce7 eingeführt und allen Anti-Aliasing-Modi als zusätzliche Option zur Seite gestellt.

Diese Option ändert nur die Auswahl der Farbzwischenstufen, die in den Übergängen von Polygonkanten verwendet werden. Anti-Aliasing mit korrigiertem Gammawert ist sinnvoll, weil sich Monitore in der Darstellung von Farben und Helligkeit nicht linear verhalten und deswegen eine lineare Farbanpassung an Polygonkanten gar nicht ideal sein kann.

Mit gammakorrigiertem Anti-Aliasing sind die Polygonkanten etwas weniger sichtbar als ohne. Der Effekt hängt allerdings auch vom verwendeten Monitor und dessen Einstellungen (Helligkeit, Kontrast, usw.) ab.

Diese Option kostet überhaupt keine Leistung.Quelle: Nhancer Handbuch (http://www.nhancer.com/?dat=d_AA#gamma)

[Chris Lux]

Wenn Du mal in das ControlPanel schaust, dann müsstest Du in den 3D-Einstellungen sehen, dass per Default "AntiAliasing Gamm-Korrektur" aktiviert ist. Den genauen Hintergrund möge Dir jemand anderes erklären, aber im Prinzip wird versucht, die durch das AA entstehenden zusätzlichen "Stufen" natürlicher zu gestalten, indem man mehr Farbwerte der Umgebung heran zieht (naiv formuliert).
Falsch!

Du schreibst immer soviel von Gamma guuut, dass man glaube sollte du weisst was Gamma Korrektur ist.

Gamma korrektes AA ist folgendes. Vor dem Downsampling werden die Samples in den linearen Raum des Ausgabe transformiert. Bei nicht-gamma korrektem Downsampling wird die Korrektur erst nach dem Downsampling durchgeführt was andere/falsche Ergebnisse zur Folge hat.

Das ganze hat _gar_ nichts mit weiteren Umgebungswerten zu tun.

Edit: da war ich wohl etwas zu langsam.

[r@h]

"Natürlicher" wird da nichts gestaltet, es wird nur versucht, die Farbanpassung monitorverträglicher zu gestalten. Je nach Monitor erhält man mit oder ohne Gammakorrektur das bessere Ergebnis:

Quelle: Nhancer Handbuch (http://www.nhancer.com/?dat=d_AA#gamma)
Also ich halte es da eher mit Wiki:
http://de.wikipedia.org/wiki/Gamma-Korrektur

Gammakorrektur zur Wahrnehmungskorrektur [Bearbeiten]Eine Gammakorrektur wird in abbildenden Systemen benötigt, um das nichtlineare Helligkeitsempfinden des menschlichen Auges zu kompensieren. Das Auge reagiert beim Anstieg auf eine doppelte Helligkeit im physikalischen Sinne nicht zwangsläufig mit einer Verdopplung der Helligkeitsempfindung. Die empfundene Helligkeit H steigt in dunklen Bereichen steiler und in hellen weniger steil an. Dem menschlichen Auge kann man ein Gamma von ca. 0,3 bis 0,5 zuordnen. (Siehe auch Stevenssche Potenzfunktion.)

Die Intensitätswahrnehmung des menschlichen Sehens ist nicht linear. Abbildende Systeme sollen die menschlichen Sehgewohnheiten simulieren bzw. nachbilden, daher wird eine Korrektur notwendig, denn ein elektrischer Sensor (z. B. CCD-Chip) oder eine Elektronenstrahlröhre (siehe Fernseher) arbeiten hingegen annähernd linear.
Somit dient die Gamma-Korrektur die der menschlichen Wahrnehmung.
Die Farbwerte bei der "Treppen-Überbrückung" werden für das menschliche Auge 'natürlicher' oder auch verträglicher ausgewählt...


Razor

[Chris Lux]

Also ich halte es da eher mit Wiki:
http://de.wikipedia.org/wiki/Gamma-Korrektur
Somit dient die Gamma-Korrektur die der menschlichen Wahrnehmung.
Die Farbwerte bei der "Treppen-Überbrückung" werden für das menschliche Auge 'natürlicher' oder auch verträglicher ausgewählt...
lies mal genauer! du hast keine ahnung, erstens was gamma korrektur ist und zweitens von der menschlichen wahrnehmung. du reimst dir da nur was zusammen wie du es brauchst.

bei heutigen ausgabegeräten ist es nunmal so, dass sie ein nichtlineares verhalten haben. das heisst, man legt 0.5 als eingangssignal an, aber heraus kommt nicht die helligkeit 0.5 sondern was anderes. die gamma korrektur passt nun das eingangssignal so an, dass man in von dem linearen berechnungsraum in den nichtlinearen ausgaberaum kommt. soll heissen die 0.5 wird zu was anderem, was eben die 0.5 als ausgabe ergibt (mal naiv erklärt).

Hier nochmal deutlich für dich von Wikipedia, da du das ja schon selbst verlinkst:

Gamma compression, also known as gamma encoding, is used to encode linear luminance or RGB values into video signals or digital video file values; gamma expansion is the inverse, or decoding, process, and occurs largely in the nonlinearity of the electron-gun current–voltage curve in cathode ray tube (CRT) monitor systems, which acts as a kind of spontaneous decoder.

Ja... und falsch war es zudem.
in deiner welt vielleicht ;). hoffentlich merkst du langsam, dass du hier nur heisse luft von dir gibst zu themen, von denen du wenig bis (in diesem fall) keine ahnung hast. bitte stell dann die korrekturen nicht noch als falsch hin, was sie meist nicht sind. das thema ist ein extrem einfaches und muss nicht von dir flasch in den raum gestellt werden. leider hast du hier ein gefolge, was dir eine menge abnimmt und diese leute müssen die sachen nicht falsch mit sich nehmen.

nimm dir doch auch einfach mal etwas wissen von leuten hier im forum an (nicht nur von mir...).

[r@h]

(nicht nur von mir...).
Garantiert nicht von Dir... nicht zuletzt, weil Du mir vollkommen unsympathisch bist.
Vielleicht würden Deine geistigen Ergüsse (und mehr ist es nicht, was Du von Dir gibst) besser ankommen, formuliertest Du sie 'verträglicher'.

Also lies mein Zitat von Wiki einfach nochmal und versuche wenigstens zu verstehen...

Razor

[r@h]

Ach ja... noch etwas: ich habe wenigstens versucht, eine Erklärung für das "bessere AntiAliasing" zu finden und bin auch noch immer der Meinung, den richtigen Ansatz zu verfolgen. Von Dir ist - wie immer - NICHTS zum Thema gekommen.

Auch über diesen Punkt solltest Du vielleicht noch einmal nachdenken.

Razor

[DevilX]

@Chris irgendwie klingt deine letzte Erklärung etwas seltsam..
Das würde doch voraussetzten das die Graka das Ausgabegerät "kennt"??

So wie ich das sehe werden nur die Subpixel gamma korrigiert (die Gamma Korrektur an sich ist eine nicht Lineare Funktion), dadurch wird erreicht das z.b Kantenpixel die zu dunkel geworden sind sind heller werden und die "Pixelkannten" insgesamt sauberer wirken.
Das kann natürlich nur bei einem richtig eingestellten Monitor funktionieren..
ansonsten wird die Pixelkannte hell.
(das gleiche bei zu hellen Pixeln dann wird nach unten Korrigiert)

Oder geht es euch um Gamma Korrektur im allgemeinen?
Da geht es doch darum an das Helligkeitsempfinden des Menschlichen Auges anzupassen, welches nicht linear ist oder nicht?

P.S.
Hmm ein wenig Offtopic irgendwie ^^

[Chris Lux]

@Chris irgendwie klingt deine letzte Erklärung etwas seltsam..
Das würde doch voraussetzten das die Graka das Ausgabegerät "kennt"??
was meinst du warum man für bestimmte ausgabegeräte gammawerte kennt/angibt?

@razor: ob ich dir sympatisch bin oder nicht ist mir egal. die erklärung ist und bleibt richtig, auch wenn du das nicht einsehen willst. vielleicht denken nun mehrere leute mal nach wenn sie von dir ein gamma guuut lesen.

[Chris Lux]

Und wieder nichts verwertbares von Dir, lieber Chris.
Schade eigentlich... Deine Meinung ist die richtige, wie immer.
so lieber razor, nun zeige mir mal die verwertbaren sachen von dir. ich habe nur einen offensichtlichen fehler deinerseits korrigiert, mehr muss ich hier gar nicht (ich war ja nichtmal der einzige). du jedenfalls kommst dann immer mit der gleichen leier: alles falsch, und man bringt angeblich keine argumente. die argumente wurden im ersten und zweiten post dargelegt. es wurde gesagt was gammawert und gamme korrektur sind. du siehst nicht ein, dass deine bisherige vorstellung vollkommen falsch ist und spielst wieder den beleidigten.

sorry für OT, aber lauthals verbreiten von falschen fakten im 3d center forum finde ich einfach falsch, ach wenn viele razors meinung wertschätzen hat er einfach zu wenig ahnung von der materie. ich meinerseits versuche das jedesmal (an stellen wo ich es kann) klar zu stellen und werden in einer hartnäckigen regelmäßigkeit dafür angegriffen. auch wenn sich razor jetzt nur noch als gast hier rumtreibt finde ich das total falsch und werde ihn weiter korrigieren.


Und das nächste mal vielleicht doch etwas zum Thema, Chris?
mehr als die korrektur nicht ;). da kannst du dich wenden und keifen wie du willst ;) ausser du sagt mal zur abwechslung was richtiges.


edit: damit es nicht heisst ich gehe nicht darauf ein. nochmal die gamma kennlinie vieler geräte ist bekannt. viele sind auch hergestellt um der 2.2 linie zu entsprechen. mehr muss der treiber nicht wissen um die ausgabe zu linearisieren.

[Chris Lux]

ok, für razor eine quelle, der er vielleicht mehr glauben schenkt:

http://alt.3dcenter.org/artikel/multisampling_anti-aliasing/index6.php

die erklärung ist aber genau die gleiche wie meine.

ich hoffe das bringt noch ein wenig mehr licht ins dunkel.

[Tesseract]

Die Farbwerte bei der "Treppen-Überbrückung" werden für das menschliche Auge 'natürlicher' oder auch verträglicher ausgewählt...

oder auch nicht. AA-gamma-korrektur hat bei mir bis jetzt noch auf keinem meiner monitore das subjektiv bessere bild erzeugt.

[aths]

ok, für razor eine quelle, der er vielleicht mehr glauben schenkt:

http://alt.3dcenter.org/artikel/multisampling_anti-aliasing/index6.php

die erklärung ist aber genau die gleiche wie meine.

ich hoffe das bringt noch ein wenig mehr licht ins dunkel.Das Bild da ist bereits für einen Gamma-Wert von 2,2 korrekt. Ansonsten wären die Innenflächen dunkler.

Das Problem ist beim Beispiel 4x AA schwarz auf weiß: Man hat die Stufen 0%, 25%, 50%, 75% (und 100%, bzw. ein Pixel daneben wieder 0%.)

Bei linearem Downfiltering erscheinen die Helligkeiten 0%, 5%, 22% und 53%. Man muss es vor dem Downsampling adjustieren, und nach dem Downsampling zurück auf auf 0%, 53%, 72%, 88%, damit es mit der nichtlinearen Monitorwiedergabe 0%, 25%, 50%, 75% ergibt.

Sofern die Ingame-Gammakorrektur nicht sehr hoch aufgedreht ist, liefert gammaadjustiertes Downsampling die gleichmäßigeren Treppenzwischenstufen.

[Tesseract]

Sofern die Ingame-Gammakorrektur nicht sehr hoch aufgedreht ist, liefert gammaadjustiertes Downsampling die gleichmäßigeren Treppenzwischenstufen.

was ist "nicht sehr hoch"? auf defaulteinstellungen sind sie zwischenstufen ohne gammakorrektur viel gleichmäßiger. für eine homogene verteilung der zwischenstufen bei AA-gammakorrektor "on" muss ich das vollbild-gamma hier im treiber von 50%(default) auf etwa 30% runterdrehen wärend es ohne AA-gamma-korrektor be 50% +-5 gut hinkommt.

[aths]

Wir müssen uns auf Begriffe einigen. Mit Gammakorrektur ist in der Regel gemeint, das fertige Bild zu korrigieren. Dabei sollte man davon ausgehen, dass der Monitor eine sRGB-Kennlinie hat, also grob Gamma 2,2 entspricht. Setzt man Gamma auf 1,0 heißt das (verwirrenderweise), dass tatsächlich 2,2 zum Einsatz kommt (also korrekt für sRGB ist.)

Stellt man Gamma auf 2,2, wird tatsächlich nicht 2,2, sondern 1/2,2 appliziert. Somit wird die Ausgabe linear gemacht (0,5 entspricht 50% Grau.) Das ist allerdings nicht erwünscht, da man ja sRGB wiedergeben will.

Was im Treiber 50% heißt hängt meiner Erfahrung nach stark von der Treiberversion ab. Gamma-Werte in Prozent ergeben wenig Sinn.

Die Korrektur beim Antialiasing würde ich Gamma-Adjustierung nennen. Beim Downsampling wird nicht mehr so getan als wäre die Ausgabe linear, sondern als entspräche sie 2,2 (also sRGB.) Eigentlich müsste man das bei Texturfilterung auch machen. Ab Direct3D 10 ist die Fähigkeit dazu Plficht, allerdings weiß ich nicht ob das auch ein Spiel nutzt.

[iltis2k]

Also Aths ist ja hier wohl einer der mit am meisten Ahnung von AA und AF hat, meiner Meinung nach. Was jetzt nicht heißen soll das er zwingend immer recht hat aber...
Besonders das entspricht doch dem was Razor sagt:
Was im Treiber 50% heißt hängt meiner Erfahrung nach stark von der Treiberversion ab. Gamma-Werte in Prozent ergeben wenig Sinn.
Ich empfinde Razor schon als kompetent, auch wenn er bestimmt auch mal Fehler macht. Aber ich denke das er garnicht mal so falsch liegt. Lasse mich aber wirklich gerne eines besseren belehren, dazu möchte ich dann aber auch mal gerne Fakten sehen.

[Chris Lux]

Also Aths ist ja hier wohl einer der mit am meisten Ahnung von AA und AF hat, meiner Meinung nach. Was jetzt nicht heißen soll das er zwingend immer recht hat aber...
Besonders das entspricht doch dem was Razor sagt:

Ich empfinde Razor schon als kompetent, auch wenn er bestimmt auch mal Fehler macht. Aber ich denke das er garnicht mal so falsch liegt. Lasse mich aber wirklich gerne eines besseren belehren, dazu möchte ich dann aber auch mal gerne Fakten sehen.
hier geht es nur nicht um die aussagen razors zu seinen subjektiven beobachtungen bei verschiedenen treiberrevisionen. hier ging es darum, dass er eine total falsche erklärung zu gamma korrektur und gamma-korrektem AA gegeben hat.

aths hat ja nun ganz klar erklärt wie as funktioniert und jeder kann es mit razors aussage im ersten post vergleichen.

[Chris Lux]

Die Korrektur beim Antialiasing würde ich Gamma-Adjustierung nennen. Beim Downsampling wird nicht mehr so getan als wäre die Ausgabe linear, sondern als entspräche sie 2,2 (also sRGB.) Eigentlich müsste man das bei Texturfilterung auch machen. Ab Direct3D 10 ist die Fähigkeit dazu Plficht, allerdings weiß ich nicht ob das auch ein Spiel nutzt.
ist es mitlerweise so, dass nvidia oder ati die gamma einstellungen des user nutzen oder immer noch einen festen gamma wert von 2.2 für das korrigierte AA?

[aths]

ist es mitlerweise so, dass nvidia oder ati die gamma einstellungen des user nutzen oder immer noch einen festen gamma wert von 2.2 für das korrigierte AA?2,2 ist das Maß der Dinge und wird meines Wissens genutzt, obwohl 2,0 minimal einfacher zu implementieren wäre. Damit läuft es so ab:

- Subsample-Farbe pro Kanal (von 0,0 bis 1,0 gerechnet) ^ 2,2
- Alle Subsample-Farben linear mischen
- Endfarbe pro Kanal ^ (1/(2,2))
- 8-Bit-Endfarbe anhand der Gamma-Lookup-Table kanalweise mit einem 10-Bit-Wert ersetzen

Man kann mit der Gamma-LUT eine Gamma-Korrektur erzeugen, aber auch jede andere nichtlineare Verzerrung. Da jeder vernünftiger Content auf sRGB ausgelegt ist, ist Gamma 2,2 beim Downsampling das die beste Lösung. Wie gesagt werden Texturen leider noch so gefiltert als würden sie im linearen Raum vorliegen und nicht in sRGB.

[Chris Lux]

Da jeder vernünftiger Content auf sRGB ausgelegt ist, ist Gamma 2,2 beim Downsampling das die beste Lösung. Wie gesagt werden Texturen leider noch so gefiltert als würden sie im linearen Raum vorliegen und nicht in sRGB.
Hmm, was meinst du mit auf sRGB ausgelegt? Ich weiss von noch keinen Spiel bspw. die Texturen als sRGB mitbringt...

[Coda]

Ist sRGB nicht der normale Displaystandard bei 6500K?

[aths]

Hmm, was meinst du mit auf sRGB ausgelegt? Ich weiss von noch keinen Spiel bspw. die Texturen als sRGB mitbringt...Praktisch alle Spiele nutzen für Bildtexturen (Fototexturen oder gezeichnete Texturen) den sRGB-Farbraum.

Ist sRGB nicht der normale Displaystandard bei 6500K?sRGB geht von einem Weißpunkt von 6500 K aus. Die meisten Displays bieten eine sRGB-Einstellung, die in der Regel genutzt werden sollte (ich glaube, optimiert für ein Zimmer bei Tageslichteinfall.)

[Chris Lux]

Praktisch alle Spiele nutzen für Bildtexturen (Fototexturen oder gezeichnete Texturen) den sRGB-Farbraum.
sRGB ist doch ein nicht linearer Farbraum? Aber erst kürzlich wurde es möglich sRGB Texturen oder Framebuffer zu nutzen. Meinst du, dass der Content in sRGB vorliegt, aber genutzt wird er auf den normalen linearen RGB Raum reduziert?

[aths]

sRGB ist doch ein nicht linearer Farbraum? Aber erst kürzlich wurde es möglich sRGB Texturen oder Framebuffer zu nutzen. Meinst du, dass der Content in sRGB vorliegt, aber genutzt wird er auf den normalen linearen RGB Raum reduziert?Die Bildfarben sind für sRGB gedacht, werden aber in der Regel so verrechnet als würden die Farben linear kodiert vorliegen.

[Chris Lux]

Die Bildfarben sind für sRGB gedacht, werden aber in der Regel so verrechnet als würden die Farben linear kodiert vorliegen.
hmm, aber dann ist doch jeder gewinn durch die nicht lineare codierung dahin, oder? dann ist ja alles wieder im normalen linearen RGB farbraum, wenn ich das richtig verstehe.

edit: eigentlich jede image lib, mit der ich zu tun hatte gibt ja nur standard RGB aus.

[Coda]

Es ist zwar linear kodiert, aber beschreibt eine nichtlineare "Kurve". D.h. beim Filtern muss man zuerst auf linear umrechnen, dann filtern und danach wieder zurückrechnen. Eigentlich.

Wenn man unter D3D sRGB-Filterung aktiviert wird aber irgendwie alles viel dunkler. Den Effekt konnte ich mir bisher auch nicht erklären.

[Chris Lux]

Es ist zwar linear kodiert, aber beschreibt eine nichtlineare "Kurve". D.h. beim Filtern muss man zuerst auf linear umrechnen, dann filtern und danach wieder zurückrechnen. Eigentlich.

Wenn man unter D3D sRGB-Filterung aktiviert wird aber irgendwie alles viel dunkler. Den Effekt konnte ich mir bisher auch nicht erklären.
ah ok. jetzt wird es klarer.

aber enthalten jpegs etc. wenigstens ein flag, in welchem farbraum sie vorliegen. denn sonst hat man ja immer falsche ergebnisse. wie gesagt, da ja alles linear gerechet wird auf der grafikkarte (filter, shader).

das alles dunkler wird hätte ich erwartet, denn die nicht lineare codierung bietet ja mehr informationen für dunklere werte.

[Coda]

Wenn du an einem normalen Monitor Texturen erstellst dann sind sie immer sRGB (oder nahe dran) weil man ja eine nichtlineare Ausgabe hat beim Display.

das alles dunkler wird hätte ich erwartet, denn die nicht lineare codierung bietet ja mehr informationen für dunklere werte.
Es sollte nach dem Filtern ja wieder zurückgerechnet werden. Wenn man 4x0,5 sampled und die mit Gammakorrektur filtert sollte trotzdem 0,5 rauskommen. Aber evtl. ist das der Punkt an dem ich falsch liege und man soll das selber machen ganz am Ende, weil sonst ja auch das Blending usw. wieder nicht stimmt.

[Xmas]

"Gamma-korrigiertes" AA ist eigentlich der falsche Begriff, man sollte von sRGB-korrektem Downsampling reden. Es geht lediglich darum dass man sRGB-Multisamples eben nicht linear filtern darf, sondern erst mal in lRGB konvertieren muss, dann Filtern, und schließlich wieder zurück in sRGB. Die Gamma-Kurve des Monitors spielt hier erst mal gar keine Rolle.

Das Problem ist nur dass viele Spiele(r) Gamma-Korrektur dazu missbrauchen dunkle Stellen aufzuhellen und somit die Ausgabekette nicht mehr auf sRGB kalibriert ist, was das sRGB-korrekte AA dann schlechter aussehen lässt.

Es sollte nach dem Filtern ja wieder zurückgerechnet werden. Wenn man 4x0,5 sampled und die mit Gammakorrektur filtert sollte trotzdem 0,5 rauskommen. Aber evtl. ist das der Punkt an dem ich falsch liege und man soll das selber machen ganz am Ende, weil sonst ja auch das Blending usw. wieder nicht stimmt.
Ja, genau da liegst du falsch. Der Sinn ist ja dass man im Shader ausschließlich mit linearen Farbwerten rechnet, während man die sRGB-Codierung als eine Art Kompression nutzt, um auch mit 8 Bits pro Kanal vernünftig Bilder darstellen zu können. Man sollte also nicht nur vor dem Filtern von sRGB nach lRGB konvertieren, sondern auch beim Lesen aus dem Framebuffer sowie umgekehrt beim Schreiben in den Framebuffer (bei Fixed-Point-Formaten weniger als 16 Bits pro Kanal).

[Coda]

Ist irgendwie dokumentiert wie die GPUs in von sRGB in lRGB umrechnen?

[Xmas]

Die Konvertierungsformeln gibt es hier (http://en.wikipedia.org/wiki/SRGB), GPUs nutzen allerdings vereinfachte Methoden: http://forum.beyond3d.com/showthread.php?p=1190888

Ich weiß nicht ob DX10 eine erforderliche Genauigkeit spezifiziert.

[Chris Lux]

Die Konvertierungsformeln gibt es hier (http://en.wikipedia.org/wiki/SRGB), GPUs nutzen allerdings vereinfachte Methoden: http://forum.beyond3d.com/showthread.php?p=1190888

Ich weiß nicht ob DX10 eine erforderliche Genauigkeit spezifiziert.
das ganze gilt ja nur für 'gamma korrektes' AA. sonst glaub ich macht keine GPU und kein treiber irgendwas mit den daten die er als texturen serviert bekommt. ausser man nimmt explizit sRGB texturen (http://www.opengl.org/registry/specs/EXT/texture_sRGB.txt) und framebuffer (http://www.opengl.org/registry/specs/EXT/framebuffer_sRGB.txt). oder liege ich da falsch?

Ist irgendwie dokumentiert wie die GPUs in von sRGB in lRGB umrechnen?
in den beiden extension spec, die ich oben verlinkt habe.

[Xmas]

das ganze gilt ja nur für 'gamma korrektes' AA. sonst glaub ich macht keine GPU und kein treiber irgendwas mit den daten die er als texturen serviert bekommt. ausser man nimmt explizit sRGB texturen (http://www.opengl.org/registry/specs/EXT/texture_sRGB.txt) und framebuffer (http://www.opengl.org/registry/specs/EXT/framebuffer_sRGB.txt). oder liege ich da falsch?
Ja, man muss natürlich sRGB-Formate wählen.

[Chris Lux]

Ja, man muss natürlich sRGB-Formate wählen.
und das glaube ich eben nicht, dass es schon von der masse der spiele genutzt wird. seit welchem tech-level war das ganze denn in D3D enthalten?

[Xmas]

und das glaube ich eben nicht, dass es schon von der masse der spiele genutzt wird. seit welchem tech-level war das ganze denn in D3D enthalten?
Mit DX9. Ich weiß nicht welche Spiele explizit sRGB verwenden, wahrscheinlich nur wenige. Ich weiß allerdings auch nicht worauf du hinauswillst.

[Chris Lux]

Mit DX9. Ich weiß nicht welche Spiele explizit sRGB verwenden, wahrscheinlich nur wenige. Ich weiß allerdings auch nicht worauf du hinauswillst.
nix bestimmtes ;). mich hätte es nur gewundert, wenn das in der breite schon verwendet wird. ich wollte das nur für mich wissen...

@aths:
aber zum content, hast du vielleicht ein spiele beispiel, wo ich mir die texturen mal ansehen kann? mich interessiert das sehr.

[Coda]

Du brauchst dir doch nur irgend eine Textur eines x-beliebigen Spiels ansehen. Es ist alles sRGB ;)

[aths]

@aths:
aber zum content, hast du vielleicht ein spiele beispiel, wo ich mir die texturen mal ansehen kann? mich interessiert das sehr.Na praktisch alle Texturen in Spielen sehen extrahiert so aus wie sie auf dem Bildschirm aussehen. Extraktionsprogramme gibts für einige Spiele, unter anderem WC3.

[Chris Lux]

jetzt bin ich wieder verwirrt, sorry ;)

also: in spielen werden normale bitmaps oder jpegs als texturen benutzt. diese werden ohne irgendwelche linearisierungen benutzt (shader etc.). das fertige bild wird dann gamma korrigiert und dargestellt.

aber wenn nun nun sRGB daten aus den texturen kommen und ich sie bei mir einfach so darstelle geht das doch auch alles durch die gamma korrektur der ausgabe. also an welcher stelle kommt die linearisierung mit sRGB bilder und texturen ins spiel. ich habe mal meinen image viewer (basierend auf DevIL und/oder freeImage) rausgekramt und ich mache an keiner stelle eine linearisierung und die libs geben mir auch kein flag ob der content nun lRGB oder sRGB ist. wenn ich sie aber einfach darstelle sehen sie aus wie in jedem anderen programm.

an welcher stelle kommt nun der nicht lineare farbraum zum tragen? was mir unklar ist, weil ja die gamma korrektur am ende noch kommt.

[Coda]

Also ganz von vorne.


Jeder Bildschirm hat eine nichtlineare Ausgabekurve, d.h. bei einem Wert von 0,5 ist die ausgegebene Leuchtkraft nicht 50% sondern eher 20%. Das ist begründet dadurch, dass ein Mensch dunkle Farbwerte besser unterscheiden kann.

Bei Windows ist das normal Gamma 2,2 was weitgehend sRGB entspricht
http://www.xsi-blog.com/userContent/hbardak/colorspaces/srgb-graph.png
Wenn ich jetzt im Photoshop eine Textur erstelle ist diese dadurch natürlich automatisch sRGB, weil der Künstler das Bild ja auf einem sRGB-Ausgabegerät erstellt
Wenn man nun im Spiel hergeht und einfach Werte dieser Textur linear miteinander verrechnet kommen falsche Ergebnisse zustande.

Am Grenzfall kann man es einfach erklären: Du hast schwarz (0,0) und weiß (1,0). Die korrekte Mischfarbe ist aber nicht 0,5 sondern ~0,21 nach Gammakorrektur, da die Ausgabekurve ja nicht linear ist.

Einfach sehen kann man das an Farbverläufen: http://scanline.ca/gradients/
Deshalb muss man diese sRGB-Texturen jetzt hernehmen und bevor man irgend etwas mit ihnen macht diese in den linearen Farbraum umrechnen. Dann kann man damit mathematisch korrekt Blending, Filterung usw. machen. Beim schreiben in den Framebuffer findet dann wieder die "Kompression" in das sRGB-Format statt dass dunklen Farbwerten mehr Präzision gibt.


Ich hoffe ich habe jetzt nirgends einen Fehler gemacht. Korrigiert mich bitte.

[Chris Lux]

Also ganz von vorne.


Jeder Bildschirm hat eine nichtlineare Ausgabekurve, d.h. bei einem Wert von 0,5 ist die ausgegebene Leuchtkraft nicht 50% sondern eher 20%. Das ist begründet dadurch, dass ein Mensch dunkle Farbwerte besser unterscheiden kann.

Bei Windows ist das normal Gamma 2,2 was weitgehend sRGB entspricht
http://www.xsi-blog.com/userContent/hbardak/colorspaces/srgb-graph.png
Wenn ich jetzt im Photoshop eine Textur erstelle ist diese dadurch natürlich automatisch sRGB, weil der Künstler das Bild ja auf einem sRGB-Ausgabegerät erstellt
Wenn man nun im Spiel hergeht und einfach Werte dieser Textur linear miteinander verrechnet kommen falsche Ergebnisse zustande.

Am Grenzfall kann man es einfach erklären: Du hast schwarz (0,0) und weiß (1,0). Die korrekte Mischfarbe ist aber nicht 0,5 sondern ~0,21 nach Gammakorrektur, da die Ausgabekurve ja nicht linear ist.

Einfach sehen kann man das an Farbverläufen: http://scanline.ca/gradients/


ok, hier gehe ich weitgehend mit. aber für die ausgabe wird doch standardmäßig eine gamma korrektur gemacht. also wenn ich so eine textur in photoshop erstelle ist die lRGB, was durch die gamma korrektur auf meinen nicht lineare ausgabe gebracht wird. also müsste ich schon explizit eine sRGB textur erstellen, die von photoshop für die darstellung wärend der bearbeitung auf lRGB gebracht wird, was dann wieder per gamma korrektur für meinen CRT umgerechnet wird.

das ist genau der punkt wo ich gerade hänge. alles was ich in photoshop erstelle ist doch lRGB, wenn ich es nicht explizit anders will. korrigiert mich an der stelle, wenn ich da falsch liege.



Deshalb muss man diese sRGB-Texturen jetzt hernehmen und bevor man irgend etwas mit ihnen macht diese in den linearen Farbraum umrechnen. Dann kann man damit mathematisch korrekt Blending, Filterung usw. machen. Beim schreiben in den Framebuffer findet dann wieder die "Kompression" in das sRGB-Format statt dass dunklen Farbwerten mehr Präzision gibt.


ok, wie ich oben geschrieben habe muss ich das alles explizit machen per spezielle texture und framebuffer formate. also wenn ich ein jpeg lade und es als texture darstelle darstelle sieht das doch genauso aus wie das was ich vorher in photoshop erstellt habe. das ganze habe ich mit einem gradienten getestet.

worauf ich hinaus will ist, dass man eine explizite nicht lineare pipeline braucht, wenn man nicht lineare sRGB texturen nutzt (von der erstellung bis zur darstellung).

edit:
habe gerade nochmal nachgesehn: es stimmt, dass alles was aus photoshop kommt default sRGB ist. aber wenn es dann per image lib geladen wird ist es lRGB.

[Coda]

ok, hier gehe ich weitgehend mit. aber für die ausgabe wird doch standardmäßig eine gamma korrektur gemacht. also wenn ich so eine textur in photoshop erstelle ist die lRGB, was durch die gamma korrektur auf meinen nicht lineare ausgabe gebracht wird. also müsste ich schon explizit eine sRGB textur erstellen, die von photoshop für die darstellung wärend der bearbeitung auf lRGB gebracht wird, was dann wieder per gamma korrektur für meinen CRT umgerechnet wird.
Nein eben nicht. Das was du erstellst ist sRGB, denn ein Wert von 0,5 entspricht ja nicht der Ausgabe 0,5 sondern der Ausgabe 0,21. lRGB müsste diesen Wert aber als 0,21 angeben, weil das ist was wir letztendes sehen.

Alles was du an einem normalen Monitor erstellst ist sRGB. Das Thema ist aber wirklich schwierig weil vieles ineinander spielt.

[Chris Lux]

ok, also keine default gamma korrektur bei der ausgabe, wusste ich nicht.

aber bspw. OpenGL arbeitet doch per default in einem linearen farbraum. zeichne ich damit nun eine rampe von 0 nach 1 erscheint die aber korrekt. also passiert hier doch eine korrektur?

nehme ich meine rampe aus photoshop erstellt erscheint die auch korrekt, was heisst keine korrektur.

irgendwie finde ich zu dem thema nichts aussagekräftiges.

[Coda]

Du bringst mich grad selber draus. Vielleicht können uns die anderen ja weiterhelfen bei der Verwirrung.

Es hat aber imho etwas damit zu tun, dass das Auge einen wirklich physikalisch linearen Farbverlauf eben nicht linear wahrnimmt und deshalb das Monitor-Gamma automatisch korrigiert. Wenn man mit den Werten rechnet ist die sRGB-Form aber falsch.

[Mr. Lolman]

Das menschliche Auge hat ein Gamma von 0.3 bis 0.5. Eingebürgert hat sich ein Wert von ~0.45 Um den Monitor darauf zu kalibrieren braucht man den Kehrwert also ~2.2.

Bei einem Gamma 2,2 kalibriertem Monitor braucht man 0,5 nicht mehr nachkalibrieren, da 0,5 ohnehin schon als 0,73 dargestellt wird, weswegen idF Gamma 2,2 korrigiertes MSAA kontraproduktiv wirken würde und 0,5 schon als deutlich zu helles 0,86 dargestellt würde.

Nun ist mein Monitor in der Arbeit aber mit Gamma ~1.75 kalibriert - was imo die Farben nicht so ausbleicht und dem MAC-Standard von 1,8 nahekommt. D.h. man müsste idF für ein korrektes 50% Grauempfinden 0,5 mit 1 plus der Differenz der Kehrwerte von 2,2 und 1,75 multiplizieren.

Zumindest NVs gammakorrigiertes AA (Ati hab ich nicht in der Arbeit ;)) wird mit 1,8 korrigiert was bei 50% Grau und nen auf 1,75 kalibrierten Monitor ein Helligkeit von ~0,8 ergibt, was zwar schon etwas heller als die gewünschten 0,73 ist, aber - wegen der Nichtlinearität des Helligkeitsempfindens - besser als 0,67 bei nicht korrigiertem AA.

Höher als mit 1,75 - 1,8 würd ich einen TFT aber ohnehin nicht betreiben wollen, da einerseits die Grauauflösung im dunklen Bereich ohnehin stark zu wünschen übrig lässt und andererseits bei Spielen die Rundungsfehler beim 32bit Rendering umso deutlicher würden.

Ausgehend davon, dass die meisten TFTs wohl ohnehin mit 1,75-1,8 betrieben werden würd ich den IHVs vorschlagen ihr AA mit ~1,25 zu korrigieren, anstatt mit 1,8, was, neben korrektem Grauempfinden von 0,73, auch den Vorteil hätte, dass mit Blooming, Overbrightlighting bei entsprechenden Kanten die AA-Zwischenstufen nicht so schnell ins Weissse absaufen würden.

[Xmas]

Der Standard-Farbraum in Windows ist sRGB. Hat man also einen Monitor mit sRGB-Ausgabekurve und lässt die Farbkorrektureinstellungen der Grafikkarte unberührt, so werden die Farben genau so dargestellt wie sie sollten. Dies bedeutet dass der sRGB-Wert 0,5 tatsächlich als 21.4% der eingestellten Helligkeit des Monitors dargestellt wird. Das ist so gewünscht weil wir im dunklen Bereich Unterschiede viel besser wahrnehmen.

Filtern (oder sonstige Berechnungen) sollte man allerdings im linearen Farbraum. Denn wenn man ein Schachbrettmuster mit sRGB 0,0 und sRGB 1,0 darstellt, ist die durchschnittliche Helligkeit über die Fläche des Monitors 50%, während ein einfarbiges Rechteck mit sRGB 0,5 ja nur auf 21,4% kommen würde. Deswegen muss beim Filtern von sRGB 0,0 und sRGB 1,0 nicht 0,5 sondern 0,735 herauskommen, was 50% Helligkeit entspricht.


Mr Lolman,
Diese Vorschläge halte ich nicht für sinnvoll. Die Berechnung des Bildes, wozu auch AA-Downsampling gehört, sollte völlig unabhängig vom Ausgabegerät erfolgen. Man muss sich dazu lediglich auf einen Standard-Farbraum festlegen und bei der Ausgabe entsprechend kalibriert umwandeln. sRGB ist eine gute Wahl für diesen Standard-Farbraum weil es sich an der menschlichen Wahrnehmung orientiert und somit effizientes Speichern von Farben mit lediglich 8 Bit pro Kanal erlaubt. Außerdem wird die Konvertierung zwischen lRGB und sRGB mittlerweile von Hardware unterstützt.

[Mr. Lolman]

Xmas,
das Problem am gammakorrigiertem AA ist ja, dass es die Zwischenstufen ausgehend von Gamma 1.0 korrigiert (bei NV mit nem Exponenten von 0,55) Nun hat aber kein Monitor einen Standardgammawert von 1,0 sondern eher 1,7-1,9. Und genau aufgrunddessen werden die Zwischenstufen bei gammakorrigiertem AA im Durchschnitt als zu hell empfunden.

Daja die Gammakorrektur beim AA-Downsampling ohnehin schon das subjektive Empfinden des Betrachters berücksichtigt, wärs imo nur korrekt auch den durchschnittlichen Gammawert des Ausgabegeräts auch zu berücksichtigen.


Grundsätzliches:

x) 21% Grau wird man nie tatsächlich am Monitor sehen, weil die Monitore alle ein Gamma deutlich >1,0 verwenden. Bei nem (standard)-Monitorgamma von ~1,75 sieht man also eher ~41%.

x) sRGB ist imo wegen der zu geringen Grünauflösung suboptimal, da der Mensch gerade im Bereich von ~480 bis ~580 nm Farbunterschiede am Besten auflösen kann (deshalb verwendete man zu 16bit Zeiten damals auch RGB565).

x) Bei dunklen Bereichen kann das Auge zwar Helligkeitsunterschiede besser auflösen, dafür Farbunterschiede schlechter. Korrigiert man das Monitorgamma auf 2,2 ist bei sRGB sowohl Helligkeit als auch Farbe in dunklen Bereichen zu schlecht aufgelöst und entsprechendes Banding erkennbar. => Für 24bit sRGB ist ein Gamma von 2,2 aufgrund einer Helligkeitsauflösung von bloß 8bit imo unsinnig.

[Coda]

x) 21% Grau wird man nie tatsächlich am Monitor sehen, weil die Monitore alle ein Gamma deutlich >1,0 verwenden. Bei nem (standard)-Monitorgamma von ~1,75 sieht man also eher ~41%.
Das stimmt absolut nicht. Meine Monitore sind im Auslieferungszustand fast exakt Gamma 2,2.

Und ich würde mal sagen dass das auf 90% der Geräte zutrifft, wenn nicht alle.

[V2.0]

Erstmal muss man sehen was der Gammawert eigentlich ist. Er teilt dem Ausgabegerät die Intensität mit die benötigt wird um eine bestimmte Helligkeit zu erreichen. Monitore meist mit einem Gamma von 2.2 in der Windowswelt und 1.8 bei Mäcs. Die 1.8 findet man übrigens auch bei den Druckern, weshalb man früher ja oftmals Mäcs für Druckvorstufenerstellung verwendete.

Nun ist sRGB in der Windowswelt die kleisnte gemeinsame Nenner zwischen den verfügbaren Ein- und Ausgabegeräten, aber durch eine Änderung des Farbprofils ist es möglich von diesem Nenner abzuweichen. Sei es adobeRGB oder Pantone. Würde nun die interne AA Gammakorrektur nicht lRGB ansetzen, sondern einen auf sRGB optimierten Faktor, wäre die Funktion in anderen Farbräumen weniger sinnvoll zu nutzen.

Auch wenn der Gammawert des Ausgabegerätes meist 2.2 sein wird (oder sollte), kann man dies aber nicht vorrausetzen. Im Gegensatz zu gewöhnlichen TFT-Monitoren bieten Grafiker-TFTs z.B. auch eine präzisere Einstellung des Weißpunkts über die Farbkanäle an. Anstelle von 50, 100 oder 256 einstellbaren Stufen pro Farbkanal lassen Grafikerdisplays mit 10, 12 oder 14-Bit-LUT bis zu 16.384 Abstufungen zu und ermöglichen so einen anderen Farbbereich und damit eine andere Anforderung an den Gammawert.

[Coda]

Ich sprach ja auch vom Auslieferungszustand.

Aber ich stimme Lolman insofern zu dass man das komplette AA-Downsampling besser selber macht und dann auch Kontrolle über die Gammakorrektur hat.

[Xmas]

Xmas,
das Problem am gammakorrigiertem AA ist ja, dass es die Zwischenstufen ausgehend von Gamma 1.0 korrigiert (bei NV mit nem Exponenten von 0,55) Nun hat aber kein Monitor einen Standardgammawert von 1,0 sondern eher 1,7-1,9. Und genau aufgrunddessen werden die Zwischenstufen bei gammakorrigiertem AA im Durchschnitt als zu hell empfunden.
Wenn man die Ausgabekette auf sRGB kalibriert wird überhaupt nichts als zu hell empfunden.

Daja die Gammakorrektur beim AA-Downsampling ohnehin schon das subjektive Empfinden des Betrachters berücksichtigt, wärs imo nur korrekt auch den durchschnittlichen Gammawert des Ausgabegeräts auch zu berücksichtigen.
Nochmal, das ist keine Gammakorrektur sondern eine Linearisierung von Farbwerten von sRGB zu lRGB und zurück. Berechnungen mit Farben, also auch Downsampling, sollten im linearen Farbraum erfolgen. Das ist völlig unabhängig vom subjektiven Empfinden und auch vom Ausgabegerät. Der Framebuffer ist in Windows per Definition sRGB.

x) 21% Grau wird man nie tatsächlich am Monitor sehen, weil die Monitore alle ein Gamma deutlich >1,0 verwenden. Bei nem (standard)-Monitorgamma von ~1,75 sieht man also eher ~41%.
Ein Monitor mit sRGB-Darstellung (~ Gamma 2,2) wird 21% Grau darstellen wenn er als Eingabewert 0,5 bekommt. Ich weiß nicht wie du auf 41% kommst, denn 0,5 ^1.75 sind ~ 30%.

x) sRGB ist imo wegen der zu geringen Grünauflösung suboptimal, da der Mensch gerade im Bereich von ~480 bis ~580 nm Farbunterschiede am Besten auflösen kann (deshalb verwendete man zu 16bit Zeiten damals auch RGB565).
sRGB sagt überhaupt nichts über die Auflösung der einzelnen Komponenten aus.

x) Bei dunklen Bereichen kann das Auge zwar Helligkeitsunterschiede besser auflösen, dafür Farbunterschiede schlechter. Korrigiert man das Monitorgamma auf 2,2 ist bei sRGB sowohl Helligkeit als auch Farbe in dunklen Bereichen zu schlecht aufgelöst und entsprechendes Banding erkennbar. => Für 24bit sRGB ist ein Gamma von 2,2 aufgrund einer Helligkeitsauflösung von bloß 8bit imo unsinnig.
Du solltest dich wirklich etwas genauer mit sRGB befassen.

[aths]

ok, also keine default gamma korrektur bei der ausgabe, wusste ich nicht.

aber bspw. OpenGL arbeitet doch per default in einem linearen farbraum. zeichne ich damit nun eine rampe von 0 nach 1 erscheint die aber korrekt. also passiert hier doch eine korrektur?

nehme ich meine rampe aus photoshop erstellt erscheint die auch korrekt, was heisst keine korrektur.

irgendwie finde ich zu dem thema nichts aussagekräftiges.Bei OpenGL wird linear interpoliert und nichtlinear ausgegeben. Man hat dann eben keinen gleichmäßigen Verlauf bei sRGB-Darstellung.

In Photoshop kannst du folgendes probieren: Ein Bild erstellen mit pixelweisem Schwarz-Weiß-Schachbrettmuster. Dann hau einen starken Unschärfefilter rüber und vergleiche das Ergebnis mit dem Original aus etwas Abstand. Wirken beide gleichhell? Welchen RGB-Wert hat das stark unscharf gemachte Bild?

[aths]

x) sRGB ist imo wegen der zu geringen Grünauflösung suboptimal, da der Mensch gerade im Bereich von ~480 bis ~580 nm Farbunterschiede am Besten auflösen kann (deshalb verwendete man zu 16bit Zeiten damals auch RGB565). 565 nahm man, weil Grün die hellste Grundfarbe ist und der Mensch mehr Helligkeiten als Farbstufen unterscheiden kann.

Der Grünbereich ist bei sRGB begrenzt. Vergleichbare Probleme haben aber alle RGB-basierende XYZ-Systeme. Man kann Farben nur in Intensitäten größer Null darstellen. Um bestimmte Grüntöne in RGB darzustellen, müsste man zum Beispiel negatives Rot zumischen.

Mit drei Komponenten (XYZ) sind prinzipiell alle Farben darstellbar (wenn auch nicht immer in korrekter Wellenlänge) aber durch die Begrenzung von 0..1 liefert das kein RGB-System vollständig. Gerade weil der Bereich von Grün bei sRGB eingeschränkt ist, ist die Auflösung (innerhalb des vergleichsweise kleinen) Bereiches größer als zum Beispiel bei Adobe-RGB mit 8 Bit pro Komponente.

[Chris Lux]

Bei OpenGL wird linear interpoliert und nichtlinear ausgegeben. Man hat dann eben keinen gleichmäßigen Verlauf bei sRGB-Darstellung.
warum hat man da keinen gleichmaessigen verlauf? das ist doch der sinn der ganzen uebung. man will dem ausgabe geraet daten liefern, die in seinem nativen farbraum liegen.

In Photoshop kannst du folgendes probieren: Ein Bild erstellen mit pixelweisem Schwarz-Weiß-Schachbrettmuster. Dann hau einen starken Unschärfefilter rüber und vergleiche das Ergebnis mit dem Original aus etwas Abstand. Wirken beide gleichhell? Welchen RGB-Wert hat das stark unscharf gemachte Bild?

ok, sie wirken nicht gleich hell. das geblurte bild hat den wert 127.

OpenGL nutzt lRGB fuer alle berechnungen. der framebuffer ist auch lRGB. in ihn werden die ergebnisse der berechnungen nur eingetragen.
dann passiert irgendwann eine gamma korrektur, sonst wuerden wir falsche ergebnisse sehen.

ich habe mal NeHe lesson 46 hergenommen und dort folgende aenderungen gemacht um mal mit einem sRGB framebuffer zu spielen:

ARB_Multisample.cpp

int iAttributes[] =
{
[...]
WGL_FRAMEBUFFER_SRGB_CAPABLE_EXT, GL_TRUE,
0,0
};


Lesson46.cpp

glEnable(GL_FRAMEBUFFER_SRGB_EXT);

GLboolean srgb_fb = false;
glGetBooleanv(GL_FRAMEBUFFER_SRGB_EXT, &srgb_fb);

std::cout << "sRGB capable framebuffer: " << bool(srgb_fb) << std::endl;


das ergebnis sieht vollkommen falsch aus, weil nun sRGB werte nochmals durch die gamma korrektur gehen, was fuer mich den sinn dieser extension in frage stellt.

ich frage mich gerade folgendes: jpegs sind im sRGB farbraum. wenn ich sie mittels einer image lib einlese erhalte ich das bild im lRGB farbraum. ich kann die selben daten per OpenGL darstellen und per GUI toolkit und beidesmal sieht das bild wie in photoshop aus. das ganze verwirrt mich extremst. das die standard pipeline wie sie bei OpenGL vorhanden ist (alles linear mit finaler gamma korrektur) war mir bisher immer total einleuchtend.

[Coda]

ich frage mich gerade folgendes: jpegs sind im sRGB farbraum. wenn ich sie mittels einer image lib einlese erhalte ich das bild im lRGB farbraum.
Nein. Du erhälst sRGB.

[Mr. Lolman]

Das stimmt absolut nicht. Meine Monitore sind im Auslieferungszustand fast exakt Gamma 2,2.


Ok. Dann hab ich mich von der Benq FP93 Serie irritieren lassen. Denn da haben 2 unterschiedliche Modelle default jew. 1,75.

Xmas und aths: Ihr habt recht. :redface:

[Chris Lux]

Nein. Du erhälst sRGB.
ok.

dann aber die frage wieso sieht das bild richtig aus, wenn ich es als textur in OpenGL nutze wo ja nachher noch die gamma korrektur kommt?

ich glaube wir drehen uns gerade im kreis.

[aths]

warum hat man da keinen gleichmaessigen verlauf? das ist doch der sinn der ganzen uebung. man will dem ausgabe geraet daten liefern, die in seinem nativen farbraum liegen.Man hat keinen gleichmäßigen Verlauf weil man früher die Transistoren nicht aufwenden wollte, die Werte für die Berechnungen anzupassen. Dazu müsste man ja die Eingabe-Werte erst mal in den linearen Raum bringen und bräuchte intern eine höhere Rechengenauigkeit um Colorbanding zu vermeiden, und müsste vor der Ausgabe erneut umrechnen (was allerdings nicht mehr so aufwändig wäre.)

Beim Texturfiltern müssten pro Bi-Sample alle vier Inputs linearisiert werden. Das könnte man mit linearer Interpolation machen, für die man für bestimmte Stützstellen die korrekten Werte vorberechnet. Im besten Fall also ein LERP pro Farbkanal extra. Bei drei Farbkanälen und vier Texeln kommt da was zusammen.

Aus meiner Sicht hätte man ganz schnell trotzdem sRGB-korrekte Texturfilterung einführen sollen. Sonst hat man unter anderem auch falsche MIP-Maps (in der Autogenerierung.)

ok, sie wirken nicht gleich hell. das geblurte bild hat den wert 127.Der korrekte Wert wäre 186. Mich regt das total auf, dass übliche Malprogramme auch intern mit 8 Bit rechnen und das auch noch linear. Der soll gefälligt alle Farben linearisieren und intern mit 32 Bit rechnen.

OpenGL nutzt lRGB fuer alle berechnungen. der framebuffer ist auch lRGB. in ihn werden die ergebnisse der berechnungen nur eingetragen.
dann passiert irgendwann eine gamma korrektur, sonst wuerden wir falsche ergebnisse sehen.Nein. OpenGL nimmt einfach die Werte entgegen und tut so als sei das bereits linear. Der Framebuffer wird aber so ausgegeben als handle es sich um sRGB-Farbe. Wenn man Texturen filtert ohne hohe Frequenzen in allzuhohen Amplituden zu haben, ist das Ergebnis auch leidlich korrekt. Denn für geringe Helligkeitsabstände ist eine lineare Interpolation eine ausreichend gute Näherung.

Gamma-Korrektur mit unterschiedlichen Werten pro Farbkanal ist übrigens eine ganz gute Methode, um grob Farbverfälschungen zu beseitigen: Man klickt im Bild auf eine Stelle die grau werden soll und berechnet das erforderliche Gamma pro RGB-Komponente damit diese Farbe grau wird (also RGB in gleichen Anteilen vorkommt) und wendet das auf das gesamte Bild an.


ich frage mich gerade folgendes: jpegs sind im sRGB farbraum. wenn ich sie mittels einer image lib einlese erhalte ich das bild im lRGB farbraum. ich kann die selben daten per OpenGL darstellen und per GUI toolkit und beidesmal sieht das bild wie in photoshop aus. das ganze verwirrt mich extremst. das die standard pipeline wie sie bei OpenGL vorhanden ist (alles linear mit finaler gamma korrektur) war mir bisher immer total einleuchtend.Die finale Gammakorrektur ist als Option gedacht, um die Monitorausgabe grob zu kalibrieren falls das Gerät nicht schon auf 2,2 gestellt ist. Tatsächlich wird Gamma-Korrektur oft genutzt, um zu dunkle Bereiche aufzuhellen.

Aber das ist nicht die einzige Stelle wo bei der Bildwiedergabe total geschlampt wird. Zum Beispiel nutzt digital kodiertes Video keine Werte von 0..255 sondern von ungefähr 16..235. Fast alle VOLLKOMMEN HIRNTOTEN Programme geben aber die Daten so aus als sei 0 Schwarz. Folge: Schwarz wird Grau. Seit Jahren leben die Anwender damit, dass Filme (auch DVDs) mit zu geringem Kontrast wiedergegeben werden, als wäre der Schwarzwert von preiswerten TFTs nicht schon Kompromisslösung genug. Wieso kam keiner der Programmierer auf die Idee, den Schwarzpunkt bei Videowiedergabe auf 16 zu setzen bzw. mit intelligenten Verfahren das optimale Schwarz-Level zu finden?

[Coda]

Ok. Dann hab ich mich von der Benq FP93 Serie irritieren lassen. Denn da haben 2 unterschiedliche Modelle default jew. 1,75.
Wirklich sehr seltsam. Sicher dass die nicht für Macintosh gedacht sind?

Aber das ist nicht die einzige Stelle wo bei der Bildwiedergabe total geschlampt wird. Zum Beispiel nutzt digital kodiertes Video keine Werte von 0..255 sondern von ungefähr 16..235. Fast alle VOLLKOMMEN HIRNTOTEN Programme geben aber die Daten so aus als sei 0 Schwarz. Folge: Schwarz wird Grau. Seit Jahren leben die Anwender damit, dass Filme (auch DVDs) mit zu geringem Kontrast wiedergegeben werden, als wäre der Schwarzwert von preiswerten TFTs nicht schon Kompromisslösung genug. Wieso kam keiner der Programmierer auf die Idee, den Schwarzpunkt bei Videowiedergabe auf 16 zu setzen bzw. mit intelligenten Verfahren das optimale Schwarz-Level zu finden?
Darüber rege ich mich auch regelmäßig auf.

[Chris Lux]

Der korrekte Wert wäre 186. Mich regt das total auf, dass übliche Malprogramme auch intern mit 8 Bit rechnen und das auch noch linear. Der soll gefälligt alle Farben linearisieren und intern mit 32 Bit rechnen.

das war photoshop ;)

ich schlaf glaube ich erstmal über das ganze.

es will mir einfach nicht in den kopf. ich zeichne eine normale rampe von 0 auf 1 mittels OpenGL. in der mitte kommt linear interpoliert 0.5 raus. nun sagst du es wird nicht linear, unter der annahme dass sRGB im frame buffer steht, ausgegeben. also sollte in der mitte der rampe ~0.2 erscheinen. aber es ist eine saubere rampe... ist das ein wahrnehmungseffekt oder passiert da doch noch was.

dann mein experiment mit einem expliziten sRGB framebuffer. die werte der farbrampen des ursprungsprogramms werden nun wirklich als sRGB abgelegt. nun stimmt ja die annahme, dass sRGB im framebuffer steht. warum also sieht das total ausgewaschen aus?

ich frage mich gerade ehrlich was sich seit x jahren da rechne. denn ich ging immer von einem linearen farbraum aus, der für die ausgabe angepasst wird um richtige farben und gradienten zu erhalten.

[aths]

das war photoshop ;)

ich schlaf glaube ich erstmal über das ganze.

es will mir einfach nicht in den kopf. ich zeichne eine normale rampe von 0 auf 1 mittels OpenGL. in der mitte kommt linear interpoliert 0.5 raus. nun sagst du es wird nicht linear, unter der annahme dass sRGB im frame buffer steht, ausgegeben. also sollte in der mitte der rampe ~0.2 erscheinen. aber es ist eine saubere rampe... ist das ein wahrnehmungseffekt oder passiert da doch noch was.In der Mitte des Verlaufes ("Rampe" ist im Deutschen was anderes) steht rechnerisch 0,5 (also in 8 Bit 127 oder 128.) Auf dem Bildschirm wirkt das aber wie ungefähr 20% Grau, jedenfalls wenn er für sRGB kalibriert ist.

dann mein experiment mit einem expliziten sRGB framebuffer. die werte der farbrampen des ursprungsprogramms werden nun wirklich als sRGB abgelegt. nun stimmt ja die annahme, dass sRGB im framebuffer steht. warum also sieht das total ausgewaschen aus?Es könnte sein dass einfach noch mal ^(1/2,2) gerechnet wird (8 Bit als 0..1 betrachtet.) Dann ergibt 0,5 (also 127 bzw. 128) auch 50% Grau.

Genau das wollen wir aber nicht haben. Wir wollen ja sRGB auf dem Bildschirm. Ein Input-Wert von 127 oder 128 soll für das Verrechnen als ca. 20% Grau interpretiert werden. Mischt man 0 und 255 zu gleichen Anteilen, soll das Ergebnis nicht 127 oder 128 sein, sondern 186. Denn das sieht in sRGB aus wie 50% Grau.

ich frage mich gerade ehrlich was sich seit x jahren da rechne. denn ich ging immer von einem linearen farbraum aus, der für die ausgabe angepasst wird um richtige farben und gradienten zu erhalten.Direkt an den Ecken passt es ja auch. Bei Spielen wird der größte Anteil an der Beleuchtung mit Lightmaps gemacht, da ist die interpolierte Vertexfarbe fürs Shading nicht so wichtig.

[V2.0]

Ein ganz guter Linnk um das Fehlverhalten von PS zu verstehen : http://www.colorneg.de/gamma_ps.html

[Chris Lux]

In der Mitte des Verlaufes ("Rampe" ist im Deutschen was anderes) steht rechnerisch 0,5 (also in 8 Bit 127 oder 128.) Auf dem Bildschirm wirkt das aber wie ungefähr 20% Grau, jedenfalls wenn er für sRGB kalibriert ist.

ja genau das passiert ja nicht, das sage ich ja die ganze zeit. es erscheint 50% grau, wie eigentlich erwartet.


Es könnte sein dass einfach noch mal ^(1/2,2) gerechnet wird (8 Bit als 0..1 betrachtet.) Dann ergibt 0,5 (also 127 bzw. 128) auch 50% Grau.

genau das ist ja meine vermutung, wie ich schon mehrmals gesagt habe:
es wird im linearen raum gerechnet und dann eine gamma korrektur (^(1/2.2)) durchgeführt.

Genau das wollen wir aber nicht haben. Wir wollen ja sRGB auf dem Bildschirm. Ein Input-Wert von 127 oder 128 soll für das Verrechnen als ca. 20% Grau interpretiert werden. Mischt man 0 und 255 zu gleichen Anteilen, soll das Ergebnis nicht 127 oder 128 sein, sondern 186. Denn das sieht in sRGB aus wie 50% Grau.
stimmt! ich glaube das ist der knackpunkt, mit einem srgb render target muss man naürlich auch srgb kodierte werte schreiben. also muss man die srgb korrekte interpolation oder umwandlung selbst machen.


bleibt trotzdem, dass bei normaler OpenGL nutzung am ende eine gamma korrektur steht, um den linearen RGB farbraum auf den ausgabefarbraum zu bringen.

edit:

bleibt weiterhin, warum jpegs als texturen korrekt aussehen. die werte sind sRGB, also sollte ja die rampe/der verlauf als jpeg unter OpenGL dann falsch aussehen, was er nicht tut. kann es wirklich nicht sein, dass beim auslesen der bilddaten (DevIL, FreeImage) eine konvertierung zu lRGB stattfindet?

zwar nicht ganz das thema hier, aber interessanter thread:
http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=241697

[Xmas]

warum hat man da keinen gleichmaessigen verlauf? das ist doch der sinn der ganzen uebung. man will dem ausgabe geraet daten liefern, die in seinem nativen farbraum liegen.
Hauptsächlich liegt der Sinn darin, Speicherplatz zu sparen. Denn im linearen Farbraum bräuchte man deutlich mehr Bits um sichtbares Banding zu vermeiden.

OpenGL nutzt lRGB fuer alle berechnungen. der framebuffer ist auch lRGB. in ihn werden die ergebnisse der berechnungen nur eingetragen.
dann passiert irgendwann eine gamma korrektur, sonst wuerden wir falsche ergebnisse sehen.
Genau genommen schert sich OpenGL (ohne die sRGB-Extensions) gar nicht um den Farbraum und verhält sich so als ob Texturen und Framebuffer linear vorlägen. Das ist aber bei Farben sehr selten der Fall. Der Framebuffer wird in der Regel nicht linear ausgegeben.

es will mir einfach nicht in den kopf. ich zeichne eine normale rampe von 0 auf 1 mittels OpenGL. in der mitte kommt linear interpoliert 0.5 raus. nun sagst du es wird nicht linear, unter der annahme dass sRGB im frame buffer steht, ausgegeben. also sollte in der mitte der rampe ~0.2 erscheinen. aber es ist eine saubere rampe... ist das ein wahrnehmungseffekt oder passiert da doch noch was.

dann mein experiment mit einem expliziten sRGB framebuffer. die werte der farbrampen des ursprungsprogramms werden nun wirklich als sRGB abgelegt. nun stimmt ja die annahme, dass sRGB im framebuffer steht. warum also sieht das total ausgewaschen aus?

ich frage mich gerade ehrlich was sich seit x jahren da rechne. denn ich ging immer von einem linearen farbraum aus, der für die ausgabe angepasst wird um richtige farben und gradienten zu erhalten.
Ja, das ist ein Wahrnehmungseffekt, denn unsere Wahrnehmung ist nichtlinear. 50% Grau, also halbe maximale Lichtintensität des Monitors, wird nicht als Mitte zwischen Schwarz und 100% Lichtintensität wahrgenommen, sondern deutlich heller. Ein tatsächlich linearer Gradient, also mit linear steigender Photonenzahl, wird nicht als linear wahrgenommen.

[Chris Lux]

Genau genommen schert sich OpenGL (ohne die sRGB-Extensions) gar nicht um den Farbraum und verhält sich so als ob Texturen und Framebuffer linear vorlägen. Das ist aber bei Farben sehr selten der Fall. Der Framebuffer wird in der Regel nicht linear ausgegeben.
ja das ist ja alles kein problem. mich interessiert nur, was nicht linear ausgeben heisst. ist es im endeffekt die vermutete gamma korrektur vor der ausgabe, also beim scan out?

wenn opengl alles linear mach (was es ja tut) und bilder einfach als linear annimmt, warum sehen dann screenshots, die als jpeg gespeichert sind in bildbetrachtern oder eben photoshop korrekt aus? denn dieses sind ja lRGB werte, die an die image lib übergeben werden, die sicher davon ausgeht, dass es sRGB werte sind.

es ist echt seltsam, dass es zu dem thema so wenig literatur gibt. selbst im OpenGL forum rät man viel was das angeht. sehr unbefriedigend das ganze.

[Xmas]

ja das ist ja alles kein problem. mich interessiert nur, was nicht linear ausgeben heisst. ist es im endeffekt die vermutete gamma korrektur vor der ausgabe, also beim scan out?
Nicht linear ausgeben heißt, dass die Werte die im Framebuffer stehen nicht proportional zur tatsächlich ausgegebenen Pixelhelligkeit sind. Windows definiert den Framebuffer als sRGB, was heißt dass die Ausgabekette so kalibriert werden sollte dass ein Wert von 0,5 im Framebuffer in 21% der eingestellten Maximalhelligkeit des Monitors resultiert.

Die Ausgabekette ist hier die Kombination der Wiedergabekurve des Monitors und der Farbkorrektur der Grafikkarte. Wenn ein Monitor bereits eine sRGB-Wiedergabekurve hat, dann sollte die Farbkorrektur der Grafikkarte genau gar nichts tun. Deswegen ist die Standardeinstellung auch "Gamma 1,0".

wenn opengl alles linear mach (was es ja tut) und bilder einfach als linear annimmt, warum sehen dann screenshots, die als jpeg gespeichert sind in bildbetrachtern oder eben photoshop korrekt aus? denn dieses sind ja lRGB werte, die an die image lib übergeben werden, die sicher davon ausgeht, dass es sRGB werte sind.
Die Bilddaten liegen als sRGB vor. Der Framebuffer ist sRGB. Wenn du nun die Farbwerte einfach unverändert in den Framebuffer schreibst, wird es natürlich auch korrekt ausgegeben.

Erst wenn mit den Werten gerechnet wird bemerkt man, dass dies im sRGB-Farbraum falsch ist. Eben wie das Beispiel mit dem Schachbrettmuster: einheitlich sRGB 0,5 ist viel dunkler als abwechselnd 1 und 0.

[Chris Lux]

Die Bilddaten liegen als sRGB vor. Der Framebuffer ist sRGB. Wenn du nun die Farbwerte einfach unverändert in den Framebuffer schreibst, wird es natürlich auch korrekt ausgegeben.

der framebuffer ist eben nicht sRGB, wenn nicht explizit per extension so eingerichtet. genau das ist ja mein problem, es werden per default lRGB werte geschrieben und die müssen irgendwann/irgendwo halt umgerechnet werden. und genau da ist mein problem, wenn sRGB daten (jpegs) als lineare werte ausgegeben werden.

edit:
http://en.wikipedia.org/wiki/Gamma_correction#Methods_to_perform_display_gamma_correction_in_computing

hier steht, das die DACs die gamma korrektur machen. was aber für mich bedeutet, dass alles linear im framebuffer steht. also werden die jpegs in den linearen farbraum umgewandelt. gibt es denn wirklich überhaupt keine referenzen zu dem thema. ich such mir hier den wolf und vieles widerspricht sich dann.

[Coda]

der framebuffer ist eben nicht sRGB
Er ist sRGB. sRGB bedeutet nur dass die Werte ohne irgendwelche Korrektur dort landen. Das ist schon seit den ersten Grafikkarten so.

In der Extension steht "Conventionally, OpenGL assumes framebuffer color components are stored in a linear color space." - Das ist aber falsch.

Die Extension zielt darauf ab, dass man im Shader mit linearen Werten rechnet und bevor es im Framebuffer landet korrigiert wird. Genau umgekehrt wie bei der sRGB-Textur-Extension eben.

hier steht, das die DACs die gamma korrektur machen.
Die Standard-Korrekturkurve der DACs ist linear. D.h. es wird nichts geändert. Die Ausgabekurve des Monitors ist nicht linear.

Es widerspricht sich nichts. Man braucht nur ein Weilchen ;)

[Mr. Lolman]

Wirklich sehr seltsam. Sicher dass die nicht für Macintosh gedacht sind?


Wüsst ich jetzt nicht. Ich habs sowohl auf nem BenQ FP93GX+ als auch auf einem FP93GS getestet. Auch im Pradforum schrauben die anscheinend das GraKagamma auf 0.7 runter um optimale Farbdarstellung zu bekommen.

0.7 ist mir aber schon zu dunkel. Ich nehm 0.75. Ausgehend von nem Defaultgamma von 1.75-1.8 kommt man damit auf die gewünschten 2.1-2.2.

[Xmas]

der framebuffer ist eben nicht sRGB, wenn nicht explizit per extension so eingerichtet.
Der Framebuffer ist aus der Sicht von Windows immer sRGB und wird entsprechend ausgegeben. OpenGL ist nicht für die Ausgabe des Bildes auf den Bildschirm zuständig.

In der Extension steht "Conventionally, OpenGL assumes framebuffer color components are stored in a linear color space." - Das ist aber falsch.
Das ist schon richtig so wie es da steht. OpenGL nimmt an dass die Farben – oder welche Werte auch immer – linear sind und führt deshalb auch keine Farbraumkonvertierung durch solange man sie nicht explizit anfordert. OpenGL ist aber nur für die Berechnung des Bildes zuständig, nicht für die Ausgabe. Bei der Ausgabe wird der Framebufferinhalt als sRGB uminterpretiert.

(Genau genommen ist es natürlich andersrum: Farbraumkonvertierung wäre früher viel zu teuer gewesen, deshalb war man dazu gezwungen die Farben linear zu interpretieren.)

[Coda]

Das ist schon richtig so wie es da steht. OpenGL nimmt an dass die Farben – oder welche Werte auch immer – linear sind und führt deshalb auch keine Farbraumkonvertierung durch solange man sie nicht explizit anfordert. OpenGL ist aber nur für die Berechnung des Bildes zuständig, nicht für die Ausgabe. Bei der Ausgabe wird der Framebufferinhalt als sRGB uminterpretiert.
Ich meinte damit, dass die Annahme falsch ist.

[Chris Lux]

Das ist schon richtig so wie es da steht. OpenGL nimmt an dass die Farben – oder welche Werte auch immer – linear sind und führt deshalb auch keine Farbraumkonvertierung durch solange man sie nicht explizit anfordert. OpenGL ist aber nur für die Berechnung des Bildes zuständig, nicht für die Ausgabe. Bei der Ausgabe wird der Framebufferinhalt als sRGB uminterpretiert.

(Genau genommen ist es natürlich andersrum: Farbraumkonvertierung wäre früher viel zu teuer gewesen, deshalb war man dazu gezwungen die Farben linear zu interpretieren.)

Ok experiment dazu:
http://skhisma.net/pix/srgb_test.png

bei dem srgb teil ist richtig in der mitte der wert 187, aber die rampe sieht für meine begriffe nicht richtig aus. die srgb ausgabe der eigentlich linearen rampe sieht kontinuierlicher aus (wahrnehmung). also das was meineigentlich möchte oder?

also wenn ich nun ein srgb render target habe, wie im zweiten fall, was ist der nutzen? meinen crt (sony FW900) kann ich auf srgb ausgabe stellen, aber das ändert an der erscheinung der rampe wenig.

[Xmas]

Ich meinte damit, dass die Annahme falsch ist.
Ok, missverstanden. Dennoch ist die Annahme in manchen Fällen auch richtig. Wenn man beispielsweise einen Float-Framebuffer verwendet gibt es ja keinen Grund für sRGB.


Ok experiment dazu:
http://skhisma.net/pix/srgb_test.png

bei dem srgb teil ist richtig in der mitte der wert 187, aber die rampe sieht für meine begriffe nicht richtig aus. die srgb ausgabe der eigentlich linearen rampe sieht kontinuierlicher aus (wahrnehmung). also das was meineigentlich möchte oder?
Beim Rendern werden optische Vorgänge simuliert. Wenn ich eine 50% durchlässige Glasscheibe darstellen will, dann muss das durchgelassene Licht die halbe tatsächliche Intensität haben, nicht die als "halb so hell" wahrgenommene Intensität.

Bei einem idealen und richtig kalibrierten Monitor hat bei der oberen Rampe die Mitte exakt die halbe messbare Helligkeit wie die rechte Seite. Der Intensitätsverlauf ist linear – wir nehmen ihn nur nicht so wahr.

[Coda]

Ja, aber was bringt dann diese Extension? Das verstehe ich jetzt auch nicht so richtig.

[Chris Lux]

Ok, missverstanden. Dennoch ist die Annahme in manchen Fällen auch richtig. Wenn man beispielsweise einen Float-Framebuffer verwendet gibt es ja keinen Grund für sRGB.
ja aber einen float framebuffer kann man ja nicht direkt darstellen, also muss der ja auch wieder in ein 8bit render target umgewandelt werden. also hier werden die linearen float farbwerte in lineare 8bit werte umgewandelt (ja ich weiss, dass die fp darstellung eine nicht lineare verteilung hat, aber die fp werte werden linear genutzt).

Beim Rendern werden optische Vorgänge simuliert. Wenn ich eine 50% durchlässige Glasscheibe darstellen will, dann muss das durchgelassene Licht die halbe tatsächliche Intensität haben, nicht die als "halb so hell" wahrgenommene Intensität.

Bei einem idealen und richtig kalibrierten Monitor hat bei der oberen Rampe die Mitte exakt die halbe messbare Helligkeit wie die rechte Seite. Der Intensitätsverlauf ist linear – wir nehmen ihn nur nicht so wahr.
ok, dann würden aber 'korrekt' gerenderte bilder ausgewaschen und blass aussehen. sehe ich das richtig?

irgendwie interessant das ganze, nur auch sehr schwierig. weil man immer umdenken muss. ich will 50% grau ausgeben, muss aber was bei 85% ausgeben um die 50% zu erhalten, was dann auch noch heller wirkt als das was ich haben wollte ;). puh.

[Xmas]

Ja, aber was bringt dann diese Extension? Das verstehe ich jetzt auch nicht so richtig.
Die "traditionelle" Pipeline sähe etwa so aus:
Textur mit sRGB-Farbdaten -> Texturfilter -> Combiner/Shader -> Blending <-> Framebuffer -> sRGB-Bildschirmausgabe

Die "ideale" Pipeline, die mit den Extensions ermöglicht wird sieht so aus:
sRGB-Textur -> Linearisierung -> Texturfilter -> Shader -> Blending <-> (De-)Linearisierung <-> sRGB-Framebuffer -> sRGB-Bildschirmausgabe

Solange Texturfilter, Shader und Blending nichts tun, sind die Ergebnisse in beiden Fällen identisch. Aber sobald man mit sRGB-Farbwerten rechnet, kommen falsche Ergebnisse heraus. Die sRGB-Extensions ermöglichen, dass Farben als sRGB gespeichert, aber als lRGB verarbeitet werden.

ja aber einen float framebuffer kann man ja nicht direkt darstellen, also muss der ja auch wieder in ein 8bit render target umgewandelt werden. also hier werden die linearen float farbwerte in lineare 8bit werte umgewandelt (ja ich weiss, dass die fp darstellung eine nicht lineare verteilung hat, aber die fp werte werden linear genutzt).
Natürlich sollte man die lRGB-Float-Werte für die Bildschirmausgabe in sRGB-Fixed-Werte umwandeln.

ok, dann würden aber 'korrekt' gerenderte bilder ausgewaschen und blass aussehen. sehe ich das richtig?
Nein, korrekt gerenderte Bilder sehen realistisch aus. ;)

[Chris Lux]

Die "traditionelle" Pipeline sähe etwa so aus:
Textur mit sRGB-Farbdaten -> Texturfilter -> Combiner/Shader -> Blending <-> Framebuffer -> sRGB-Bildschirmausgabe

Die "ideale" Pipeline, die mit den Extensions ermöglicht wird sieht so aus:
sRGB-Textur -> Linearisierung -> Texturfilter -> Shader -> Blending <-> (De-)Linearisierung <-> sRGB-Framebuffer -> sRGB-Bildschirmausgabe

srgb ausgabe heisst also einfach nur die rohen werte ausgeben. da srgb werte ja einer gamma=2.2 komprimierung entsprechen und die ausgabe mit gamma=1/2.2 expandiert?

edit: also genau wie hier im unteren teil angezeigt...
http://en.wikipedia.org/wiki/Image:Gamma_on_TV.png

die srgb_texture extension legt leider nicht fest ob srgb->lrgb konvertierung vor oder nach dem filtern passieren muss, also nutzlos das ganze.

[Xmas]

die srgb_texture extension legt leider nicht fest ob srgb->lrgb konvertierung vor oder nach dem filtern passieren muss, also nutzlos das ganze.
Nutzlos wird es damit nicht, nach dem Filtern zu linearisieren ist immer noch besser als gar nicht zu linearisieren. Außerdem konvertieren alle DX10-Grafikkarten vor dem Filtern.

[aths]

Ok experiment dazu:
http://skhisma.net/pix/srgb_test.png

bei dem srgb teil ist richtig in der mitte der wert 187, aber die rampe sieht für meine begriffe nicht richtig aus. die srgb ausgabe der eigentlich linearen rampe sieht kontinuierlicher aus (wahrnehmung). also das was meineigentlich möchte oder?

also wenn ich nun ein srgb render target habe, wie im zweiten fall, was ist der nutzen? meinen crt (sony FW900) kann ich auf srgb ausgabe stellen, aber das ändert an der erscheinung der rampe wenig.Wenn ich Gamma so einstelle dass 186 wirklich wie 50% Grau aussieht, wirkt der erste Verlauf (nicht "Rampe"!) für mich besser. Beim zweiten Verlauf verschwinden der linkte Teil komplett im Schwarz (etwa ein Fünftel.)

[aths]

Das Bild da ist bereits für einen Gamma-Wert von 2,2 korrekt. Ansonsten wären die Innenflächen dunkler.Übrigens ein Irrtum von mir. Das Bild wäre korrekt wenn die Wiedergabe linear wäre. Eine sRGB-Version des Musters findet sich im aTuner.

[V2.0]

Ist das ein Grund warum gammakorrigiertes MSAA oftmals Artefakte an dünnen Linien erzeugt, die einen harten Kontrast zur Umgebung aufweisen ?

[Chris Lux]

Übrigens ein Irrtum von mir. Das Bild wäre korrekt wenn die Wiedergabe linear wäre. Eine sRGB-Version des Musters findet sich im aTuner.
hab mal fix hier am laptop dein atuner muster genutzt für die gamma einstellung (hier 0.65, dann sind die farben in den blöcken gleich). die verläufe die du da zeichnest sind dann aber kein srgb, weil sie wie bei mir der untere verlauf (;)) das schwarz absäuft.

[aths]

Ist das ein Grund warum gammakorrigiertes MSAA oftmals Artefakte an dünnen Linien erzeugt, die einen harten Kontrast zur Umgebung aufweisen ?Zwar wird mit der Gamma-Funktion korrigiert, aber es wird (ausgehend von sRGB-Wiedergabe) kein Gammawert korrigiert. Ich stimme Xmas zu dass man eher "für sRGB korrektes Downfiltering" sagen sollte. (Das ist noch ungenau genug, da man mit Gamma 2,2 sRGB nur annähert.)

Das für sRGB korrekte Downfiltering verbessert die Darstellung dünner Linien. Jedenfalls sofern der Monitor einigermaßen auf sRGB kalibriert ist.

hab mal fix hier am laptop dein atuner muster genutzt für die gamma einstellung (hier 0.65, dann sind die farben in den blöcken gleich). die verläufe die du da zeichnest sind dann aber kein srgb, weil sie wie bei mir der untere verlauf (;)) das schwarz absäuft.Die Verläufe in der Mitte geben die Werte von 0..255 linear wieder und sollen vor allem helfen, den Schwarzpunkt einzustellen. Bei sRGB-Wiedergabe sehen sie nicht linear aus, das ist richtig. Dafür ist das Muster links unten gedacht. Es bietet allerdings nur grobe Anhaltspunkte, konkret werden damit lediglich zwei Stützstellen abgegelichen. Die Wahrscheinlichkeit, dass die gesamte Gammakurve einigermaßen stimmt ist hoch, aber exakt ist das Verfahren nicht.

[Chris Lux]

Die Verläufe in der Mitte geben die Werte von 0..255 linear wieder und sollen vor allem helfen, den Schwarzpunkt einzustellen. Bei sRGB-Wiedergabe sehen sie nicht linear aus, das ist richtig.
;)

aber der srgb verlauf in meinem beispiel sieht für mich aber auch nicht linear aus. da ist im unteren drittel ein viel zu starker anstieg.

[V2.0]

Das für sRGB korrekte Downfiltering verbessert die Darstellung dünner Linien. Jedenfalls sofern der Monitor einigermaßen auf sRGB kalibriert ist.

Natürlich, da es die Übergänge "weicher" macht. Ich dachte mehr an die typische Stromleitung auf die MSAA appliziert wird. Dort entstehen ja öfters mal "Löcher in der Leitung" weil das Ergebnis der Gammakorrektur allen Schwarzanteil entfernt. Ohne Gammakorrektur sieht man das, nach meinen Erfahrungen bzw. meinem Empfinden, die aber keinen Anspruch auf Vollständigkeit haben, seltener.

[Chris Lux]

Die "traditionelle" Pipeline sähe etwa so aus:
Textur mit sRGB-Farbdaten -> Texturfilter -> Combiner/Shader -> Blending <-> Framebuffer -> sRGB-Bildschirmausgabe

Die "ideale" Pipeline, die mit den Extensions ermöglicht wird sieht so aus:
sRGB-Textur -> Linearisierung -> Texturfilter -> Shader -> Blending <-> (De-)Linearisierung <-> sRGB-Framebuffer -> sRGB-Bildschirmausgabe

Solange Texturfilter, Shader und Blending nichts tun, sind die Ergebnisse in beiden Fällen identisch. Aber sobald man mit sRGB-Farbwerten rechnet, kommen falsche Ergebnisse heraus. Die sRGB-Extensions ermöglichen, dass Farben als sRGB gespeichert, aber als lRGB verarbeitet werden.

Nein, korrekt gerenderte Bilder sehen realistisch aus. ;)

ok, es laesst mich nicht in ruhe:

ich habe meinen crt mit atuner auf srgb ausgabe kalibriert und folgendes kan dabei heraus:

http://skhisma.net/pix/srgb_output.png

man kann nun klar erkennen, dass die verlaufe mit dem srgb framebuffer wieder richtig erscheinen sowie auch der obere verlauf aus meinem bereits geposteten bild.

also haben wir bisher doch keine srgb ausgabe, denn sonst wuerde alles andere so finster aussehen wie auf dem screenshot zu sehen ist.

hier nochmal, wie es ohne die srgb kalibrierung aussieht mit einem srgb framebuffer:

http://skhisma.net/pix/srgb_default_output.png

[aths]

Natürlich, da es die Übergänge "weicher" macht. Ich dachte mehr an die typische Stromleitung auf die MSAA appliziert wird. Dort entstehen ja öfters mal "Löcher in der Leitung" weil das Ergebnis der Gammakorrektur allen Schwarzanteil entfernt. Ohne Gammakorrektur sieht man das, nach meinen Erfahrungen bzw. meinem Empfinden, die aber keinen Anspruch auf Vollständigkeit haben, seltener.Wo wird "aller" (?) "Schwarzanteil" (?) entfernt?

[aths]

ok, es laesst mich nicht in ruhe:

ich habe meinen crt mit atuner auf srgb ausgabe kalibriert und folgendes kan dabei heraus:

http://skhisma.net/pix/srgb_output.png

man kann nun klar erkennen, dass die verlaufe mit dem srgb framebuffer wieder richtig erscheinen sowie auch der obere verlauf aus meinem bereits geposteten bild.

also haben wir bisher doch keine srgb ausgabe, denn sonst wuerde alles andere so finster aussehen wie auf dem screenshot zu sehen ist.Die Gamma-Korrektur von 0,45 vom aTuner wird nicht mitfotografiert beim Screenshot.

hier nochmal, wie es ohne die srgb kalibrierung aussieht mit einem srgb framebuffer:

http://skhisma.net/pix/srgb_default_output.pngDa verstehe ich auch nicht, worauf du hinauswillst.

[Chris Lux]

Die Gamma-Korrektur von 0,45 vom aTuner wird nicht mitfotografiert beim Screenshot.
deshalb habe ich screenshot mit photoshop dann mit der gamma 0.45 entsprechenden kurve bearbeitet. was du da siehst ist das was ich mittels des atuners am bildschirm sah.

Da verstehe ich auch nicht, worauf du hinauswillst.
das ist das bild, wie es ohne sie srgb kalibrierung aussieht. xmas sagte, dass immer srgb ausgegeben wird. warum erscheinen dann sachen aus einem expliziten srgb framebuffer erst korrekt, wenn wirklich die ausgabe srgb kalibriert ist. dann erscheint aber der rest total falsch. IMO kann das nur bedeuten, dass wir sonst keine srgb ausgabe haben.

ich beziehe mich auf dieses posting:
Die "traditionelle" Pipeline sähe etwa so aus:
Textur mit sRGB-Farbdaten -> Texturfilter -> Combiner/Shader -> Blending <-> Framebuffer -> sRGB-Bildschirmausgabe

Die "ideale" Pipeline, die mit den Extensions ermöglicht wird sieht so aus:
sRGB-Textur -> Linearisierung -> Texturfilter -> Shader -> Blending <-> (De-)Linearisierung <-> sRGB-Framebuffer -> sRGB-Bildschirmausgabe

Solange Texturfilter, Shader und Blending nichts tun, sind die Ergebnisse in beiden Fällen identisch. Aber sobald man mit sRGB-Farbwerten rechnet, kommen falsche Ergebnisse heraus. Die sRGB-Extensions ermöglichen, dass Farben als sRGB gespeichert, aber als lRGB verarbeitet werden.

[Xmas]

deshalb habe ich screenshot mit photoshop dann mit der gamma 0.45 entsprechenden kurve bearbeitet. was du da siehst ist das was ich mittels des atuners am bildschirm sah.
Was für einen Monitor hast du, der eine lineare Wiedergabekurve hat? Oder warum bezeichnest du Gamme 0.45 als "sRGB-kalibriert"?

[Chris Lux]

Was für einen Monitor hast du, der eine lineare Wiedergabekurve hat? Oder warum bezeichnest du Gamme 0.45 als "sRGB-kalibriert"?
es ist ein sony fw900.

ich bezeichne gamma 0.45 als srgb kalibriert, weil dann die srgb-testmuster im nhancer aussen und innen gleich hell erscheinen. und wie du an dem bild sehen kannst erscheinen dann auch alle farbverlaeufe korrekt, wenn diese mittels eines srgb framebuffers ausgegeben wurden (schwarz-weiss und die farbigen).

so wie du es beschrieben hats kann es imo nicht sein, denn wenn wir srgb ausgabe haetten muessten ja die testmuster und farbverlaeufe bei gamma 1.0 korrekt erscheinen. allein schon, dass es einen unterschied in der ausgabe bei einem srgb framebuffer und einem normalen framebuffer gibt sagt ja, dass hier etwas anders sein muss.

ich will einfach nur verstehen was hier passiert.

[Xmas]

und wie du an dem bild sehen kannst erscheinen dann auch alle farbverlaeufe korrekt
Woran genau machst du das fest? Ein linearer Farbverlauf (also linear ansteigende Photonenzahl) wird nicht als "linear" wahrgenommen.

allein schon, dass es einen unterschied in der ausgabe bei einem srgb framebuffer und einem normalen framebuffer gibt sagt ja, dass hier etwas anders sein muss.
Der Unterschied liegt beim Schreiben in den Framebuffer vor, nicht bei der Ausgabe. Wenn du explizit einen sRGB-Framebuffer anforderst werden lineare Farbwerte aus dem Shader in sRGB-Farbwerte umgewandelt und dann in den Framebuffer geschrieben. Ansonsten werden die Werte unverändert übernommen.

[aths]

es ist ein sony fw900.

ich bezeichne gamma 0.45 als srgb kalibriert, weil dann die srgb-testmuster im nhancer aussen und innen gleich hell erscheinen.Wo findet man da das Testmuster?

[Chris Lux]

Wo findet man da das Testmuster?
sorry, sorry, ganz böser vertipper. ich meinte natürlich die atuner testmuster wie sie auf den screenshots zu sehen sind.

[V2.0]

Das obere sieht für mich viel zu dunkel aus.

[Xmas]

sorry, sorry, ganz böser vertipper. ich meinte natürlich die atuner testmuster wie sie auf den screenshots zu sehen sind.
Auf dem unteren Screenshot ist das Muster korrekt für sRGB (die Farben in der Mitte haben den Wert 186), auf dem oberen Screenshot ist es etwa linear (132 in der Mitte).

[Chris Lux]

Auf dem unteren Screenshot ist das Muster korrekt für sRGB (die Farben in der Mitte haben den Wert 186), auf dem oberen Screenshot ist es etwa linear (132 in der Mitte).
ja ;)

wie gesagt, den oberen habe ich mit photoshop angepasst, da man die gamma korrektur nicht auf einem screenshot festhalten kann. am bildschirm erschien das bild wie oben. so, dass eben der wert 186 genauso hell erscheint wie das schachbrettmuster. und das passiert eben bei einem gamma wert von 0.45.

[Xmas]

am bildschirm erschien das bild wie oben. so, dass eben der wert 186 genauso hell erscheint wie das schachbrettmuster. und das passiert eben bei einem gamma wert von 0.45.
Ich weiß wirklich nicht was du an deinem Monitor eingestellt hast, aber bei mir (und auf mindestens 10 anderen Monitoren) sieht das untere Bild mit Gamma 1,0 annähernd richtig aus. Beim oberen sind die inneren Quadrate viel dunkler als das Schachbrettmuster außen herum.

[Chris Lux]

Ich weiß wirklich nicht was du an deinem Monitor eingestellt hast, aber bei mir (und auf mindestens 10 anderen Monitoren) sieht das untere Bild mit Gamma 1,0 annähernd richtig aus. Beim oberen sind die inneren Quadrate viel dunkler als das Schachbrettmuster außen herum.
ich habe es gerade auf 5 verschiedenen röhrenmonitoren angesehen und dort passt es (2 weitere fw900, einem weiteren sony und einem iiyama). auf tfts ist es wie du es beschrieben hast.

[Coda]

http://www.valvesoftware.com/publications/2008/GDC2008_PostProcessingInTheOrangeBox.pdf

Ist mir gerade in die Hände gefallen zu dem Thema.