24ビットの色深度では不十分ですか？

非常に柔らかいグラデーションでは、24ビットの色深度では色の遷移を見ることができるので十分ではないことに気付きました。これは、暗いシーンや夜空で最も飛び出します。

チャンネルごとに色深度を2バイトに変更しないのはなぜですか？それは多くの作業であり、多くのハードウェアを再調整する必要があることは知っていますが、少し面倒です。ハードウェアの技術が十分に成熟していないとは本当に思いません。

それで、なぜ誰もそれをしないのですか？

これが「The War Z」の写真です。ここで私が言っていることを見ることができます：

あなたは多かれ少なかれ自分で言いました：「私は知っています、それは多くの仕事であり、多くのハードウェアを交換しなければならないでしょう。」グラフィックスハードウェアの物事の終わりは実際には比較的単純ですが（高価な場合-すべてのテクスチャとフレームバッファーのサイズを2倍にすることは簡単ではありません）、より高い色深度の画像の「エコシステム」は単に配置されていませんLCD製造業者は1ピクセルあたり最大16ビットを取得しようとすることに焦点を当てていないため、これは誰にとっても価値のある支出になります（10BPPでは、RGB信号を32ビットチャネル）。

要するに、ほとんどの人がまだ利益が少なすぎると考えるものにとっては、あまりにも多くの作業です。それは「少し面倒」かもしれませんが、その面倒なレベルは非常にスリムであるため、画質の他の改善が優先されています。

うん、あなたはこれに気付く最初の人ではありません。:)今日の高いコントラスト比では、コンポーネントごとに8ビットでは、目に見えるバンディングのない滑らかなグラデーションを作成するには不十分です-ディザリングを使用しない限り。

ディスプレイでチャネルごとに8ビット以上を使用することは、ディスプレイメーカーによって「ディープカラー」と呼ばれます。鶏と卵の問題のため、あまり普及していません。ディープカラーディスプレイは、ディープカラーを出力できるビデオカードと、ディープカラーへのレンダリングをサポートするゲームエンジンがなければ役に立ちません。同様に、ディスプレイなしで濃い色をサポートするゲームエンジンやビデオカードには意味がありません。したがって、ハードウェアメーカーやゲーム開発者がこのテクノロジのサポートを追加するインセンティブはあまりありません。どちらの側からも、開発コストを正当化する市場がないからです。

また、8ビット精度が制限されているため、バンディングを修正する他の方法があります。前述したように、ゲームエンジンはディザリングを使用してバンディングを隠すことができます。

^{（ディザリングなしとディザリング付きの256色パレットの猫の写真。ウィキペディアのユーザーWapcapletによって作成され、CC-By-SA 3.0ライセンスの下で使用されます。）}

ピクセル値をフレームバッファに書き出す前に±0.5 / 255のわずかなディザを追加することは、滑らかなグラデーションのバンディングを隠すのに非常に効果的であり、本質的には気付かれません。HDRエンジンを使用している場合は、トーンマッピング段階でこれを行います。

最後に、他の人が指摘したように、テクスチャ圧縮は、8ビット精度よりも大きな画像のバンディングのようなアーティファクトの大きな原因になる可能性があります。これはその写真の空で起こっていることかもしれませんが、それを伝えるのは難しいですが、非常に多くのJPEG圧縮が行われているため、DXT圧縮によるアーチファクトはほとんど圧倒されています。

また、多くのLCDパネルはチャネルあたり8ビットでさえないことに注意してください。安価なものは、使用するビット数が少なく、さまざまなトリックを使用して隠そうとする傾向があります。たとえば、2つの隣接する色をすばやく切り替えて、中間の色を表します。http://www.anandtech.com/show/1557/3

http://msdn.microsoft.com/en-us/library/windows/desktop/jj635732%28v=vs.85%29.aspxで DXGIがチャネルごとに10ビットをサポートし、白色よりも明るい方法についての詳細があります。

D3Dは、長年にわたってチャネルごとに8ビット以上もサポートしています。開発者がチャネルごとに16ビットから8ビットにディザリングを行うのを止めるのは、彼らがそれが良い考えだと思うなら、何もありません。

もちろん、ソースデータ（テクスチャなど）が8ビット（またはより可能性の高いDXT1、実質的にチャネルあたり5-6-5ビット）である場合、これはあまり役に立ちません。そのスクリーンショットでは空がどうなっていると思います（8 bppのガウスぼかしにより、よりスムーズになります）が、確実ではありません。

Steven Stadnickiの答えは正解です。ゲームはテクスチャメモリーを大量に必要とし、ピクセルシェーダーでテクスチャをサンプリングするときにメモリ帯域幅を過度に必要とするため、高精度のテクスチャを使用することはめったにありません。ただし、大きなテクスチャを必要としないソリューションがあります。（これをコメントとして投稿しますが、長すぎます。）

Homeworld は、空の画像を頂点の勾配としてエンコードすることでこの問題を解決します。この手法は、テクスチャが膨大な数のゲーム内ピクセルをカバーする、空のような大きな低周波画像（つまり、滑らかなグラデーション）に最適です。

別の可能な解決策は、空の画像にヒストグラムの正規化を適用することです。テクスチャデータが暗い夜空のような狭い値の範囲内にある場合、各カラーチャネルのほとんどのビットは有用なデータを運んでいません。代わりに、これを行います：

• 16ビットTIFFのような16ビット形式で元のテクスチャを作成します。
• ゲームエンジン用のテクスチャを準備するときは、画像内に存在する最も暗いピクセルを見つけ、これをオフセットとして追跡します。このピクセル値は、0-1の可能な範囲で0.1としましょう。
• 次に、最も明るいピクセルを見つけ、最も暗いピクセルを減算して、画像内の値の範囲を取得します。したがって、最も明るいピクセルがまだかなり暗い場合（0.35など）、範囲は0.35-0.1 = 0.25だけです。画像には値の範囲の25％しかありません。
• DXT / BCで圧縮されたゲーム内テクスチャを生成します。すべてのピクセルから最も暗い値を減算し、乗算して色範囲全体を使用します。計算例では、暗い値0.1を減算し、使用可能な値の範囲の25％しか存在しないため、すべてのピクセル値に4xを乗算してゲーム内テクスチャを作成します。16ビットソースイメージをDXTコンプレッサーへの8bpp入力に量子化する前に、これらすべてを必ず行ってください。出力画像は、ゲーム内フォーマットでサポートされている値の範囲全体を利用します。画像に実際に存在する値を表すために、すべてのビットを割り当てています。
• 暗い値のオフセット（0.1）と範囲（0.25）をメタデータのどこかに保存します。これらを入力としてピクセルシェーダーに渡します。
• ピクセルシェーダーコードで、シフトした拡張テクスチャをサンプリングし、それを浮動小数点値に変換してから、乗算/加算を実行して元の色値を復元します。つまり、0.25を掛けて0.1を加算すると、ソースイメージに保存されている値が復元されます。

シェーダーコードが正しいガンマであることを確認してください。sRGB色空間から線形空間に変換されないテクスチャサンプルで数学（ライティングと後処理）を行うと、説明したようなバンディングアーティファクトが表示されます。ガンマ補正は、目が値の変化に敏感な暗い値により多くのビットを割り当てることにより、この種の問題を軽減するために作成されました。ただし、たとえば、照明、露出、後処理FXなどの計算時にガンマ補正を考慮しないと、簡単に問題を解決できます。ガンマよくある質問は便利です。

24ビットでは十分ではありませんが、このような問題が画像圧縮アルゴリズム、エイリアシング、またはその他のデジタルアーティファクトによって引き起こされることは、より一般的です。また、ディスプレイ技術の役割を見落とさないでください。デジタル入力が何であっても、ディスプレイは実際の明るさで適切なステップを生成しない場合があります。