マルチサンプルレンダリングバッファを使用してFBOに描画し、サンプルを解決するためにテクスチャを使用して別のFBOにブリットし、テクスチャを読み取ってバックバッファに描画しながら後処理シェーディングを実行するレンダリングシステムがあります( FBOインデックス0)。
ここで、正しいsRGB出力を取得したいと思います...問題は、OS XとWindowsで実行したときのプログラムの動作がかなり一貫していないことです。これは、マシンによっても異なります。IntelHDを搭載したWindowsの場合3000は、sRGB非線形性を適用しませんが、NvidiaGTX670を搭載した他のマシンでは適用します。OSXのIntelHD3000でも、それが適用されます。
したがって、これはおそらくGL_FRAMEBUFFER_SRGB
、プログラムの適切なポイントで有効化状態を設定していないことを意味します。ただし、いつ有効にする必要があるかを実際に教えてくれるチュートリアルは見つからないようです。彼らは、それが非常に簡単で、パフォーマンスコストがかからないと言っているだけです。
現在、テクスチャをロードしていないので、まだ色の線形化を処理する必要はありません。
プログラムに線形カラー値を単純に吐き出さないようにするには、行をコメントアウトするだけですglDisable(GL_FRAMEBUFFER_SRGB)
。これは、この設定がパイプライン全体で有効になっていることを意味し、実際にはすべてのフレームで冗長に強制的に戻します。
これが正しいかどうかはわかりません。それは確かに色に非線形化を適用しますが、これが2回適用されているかどうかはわかりません(これは悪いことです)。最初のFBOにレンダリングするときにガンマを適用できます。私が最初のFBOを2番目のFBOにブリットしたときにそれを行うことができました。なぜだめですか?
これまで、最終フレームのスクリーンショットを撮り、生のピクセルカラー値をプログラムで設定したカラーと比較しました。
入力色をRGB(1,2,3)に設定すると、出力はRGB(13,22,28)になります。
これは、ローエンドでの色の圧縮が非常に多いように思われ、ガンマが複数回適用されているかどうかを疑問視するようになります。
sRGBの式を調べたところ、線形1 / 255、2 / 255、および3/255が実際にsRGB 13 / 255、22 / 255にマップされるため、変換が1回だけ適用されるように見えることを確認できます。方程式を使用して28/255 1.055*C^(1/2.4)+0.055
。これらの低いカラー値の展開が非常に大きいことを考えると、sRGBカラー変換が複数回適用されているかどうかは明らかです。
ですから、私はまだ正しいことを決めていません。最終的glEnable(GL_FRAMEBUFFER_SRGB)
なフレームバッファ値にのみ適用されます。この場合、GL initルーチン中にこれを設定するだけで、今後は忘れることができますか?