HDRはどのように機能しますか？

HDRとは何か、どのように機能するかを理解しようとしています。

私は基本的な概念を理解しており、D3D / hlslを使用してどのように実装されるかについて少し理解しています。

しかし、まだかなり霧がかかっています。

地球のテクスチャと、星として機能する頂点の小さなポイントリストで球体をレンダリングするとします。これをHDRでどのようにレンダリングしますか。

以下に、私が混乱しているいくつかのことを示します。

• シェーダーでは値が[0、255]に制限され、[0、1]に固定されるため、テクスチャに基本的な画像形式だけを使用することはできません。バックバッファについても同じことが言えます。フォーマットは浮動小数点フォーマットである必要がありますか？

• 関係する他のステップは何ですか？確かに、浮動小数点形式を使用してレンダーターゲットにレンダーし、後処理としてブルームを適用する以上のことが必要ですか？（出力はとにかく8bppになると考えています）

基本的に、HDRの手順は何ですか？どのように機能しますか？このプロセス以外に、プロセスを説明する優れた論文や記事を見つけることはできないようですが、基本を少し読み飛ばしているようで、混乱を招きます。

HDR技術を使用すると、従来の照明/テクスチャよりも画面上で表示できるよりも詳細な範囲をシミュレートできます。さまざまな量の光にさらされたときの目の動きと比較できます-光量が多すぎると目が光を落とすので、物が見える範囲にあります。十分な光がない場合、虹彩がさらに開くので、詳細を見ることができます。

この画像の右側はHDRを使用しています。色の範囲をより活用し、暗い部分はより暗く、明るい部分はより明るくなります。これに対して、画像の左側は少し平らに見えます。

基本的な手順は次のとおりです。

1. モデル上の他の浮動小数点テクスチャや、1.0fを超える明るさのライトを使用して、シーンを浮動小数点テクスチャ（A16B16G16R16Fなどの形式）にレンダリングします。

2. このテクスチャを表示するには、表示可能な色の範囲を画面に表示可能なものに変換する必要があります。このプロセスはトーンマッピングと呼ばれ 、さまざまなトーンマッピング式を使用してさまざまな効果を得ることができます。モニターは浮動小数点テクスチャに保存できる色や発光の全範囲を表示できないため、これは必須です（可能な場合はクールですが、目もくらむような危険もあります）。

3. ブルームなどのエフェクトを追加して、レンダリングされたものの発光の違いをさらに誇張します。ブルームは、浮動小数点バッファーから計算され、トーンマッピングされたイメージと組み合わされます。

役立つことを願っています

技術的には、HDRは単に、グラフィックに可能な範囲を広げることを意味します。通常、赤、緑、青のチャネルの離散値は256に制限されています。つまり、2つのアイテムがあり、一方が他方の2倍の明るさで、3番目が最初の10,000倍明るい場合、同じシーンで3つすべてを正しく表現する方法-明るいオブジェクトを最初のオブジェクトよりも256倍だけ明るくするか、両方の鈍いオブジェクトを完全に黒にして（コントラストを失って）明るいオブジェクトを無限に明るくします。それら両方より。

これは、赤/緑/青の値に浮動小数点値を使用することで簡単に修正できますが、チャンネルごとに固定数の離散値のみを処理するグラフィックデバイス（例：256）でそれを表示する方法の問題があります。したがって、問題の2番目の部分は、浮動小数点値を制限された範囲にマップする方法です。簡単な解決策は、すべての値を比例的に離散範囲にスケーリングすることですが、これは、1つの非常に明るいピクセルが画面の残りを黒くするなどを意味します。これにアプローチする方法の例のリンク。

一般に、新しい形式で保存する必要があるのはテクスチャではありません。照明が適用されたときに、より大きな値に対応できるようにする必要があります。もちろん、テクスチャに焼き付けられた光源がある場合-例えば。星空の背景-より高い解像度のフォーマットが必要な場合があります。または、シェーダーにそのようなマテリアルの値をレンダリングする時間に合わせてスケールさせるだけです。

コンピュータは伝統的に、画面上の各ピクセルをメモリ内の24ビットのみとして表しています。赤は8、緑は8、青は8です。これは、追加しても人間が気付かないほどの十分なビットであり、8ビットバイトはマイクロプロセッサにとって非常に便利です。

8ビットはほぼ十分な精度ですが 画像表示する、画像を計算するには十分な精度ではありません。画像の計算中のさまざまな時点で、少なくとも32ビットの精度が必要です。

これが、ピクセルシェーダーが8ビット精度の画像にレンダリングする場合でも、32ビット精度で色を計算する理由です。そうしないと、たとえば、 8ビット値を1000で除算するとゼロになるため、値を1000で除算してから1000で乗算することはできません。

リアルタイム3Dグラフィックスでは、可能な限り最後の瞬間まですべてのグラフィックスを8ビット以上の精度で維持する傾向があり、そのとき、8ビット以上の赤は8ビットにダウンサンプリングされ、緑や青についても同様です。

HDRは、8ビット精度よりも高い画像にレンダリングする行為を指します。現代のテレビビデオゲームでは、16ビット精度が標準であり、これは今後数年のビデオゲームでは「十分な」可能性があります。

私がHDRの鍵だと思う1つの側面は、モニターガンマの正しい適用です。

表示しているモニターは、入力ピクセルの関数として光を生成します。値が255のピクセルは、値が1のピクセルよりも（およそ）255倍多くの光を生成すると予想されるかもしれません。そうではありません。標準のモニターガンマ2.3では、255 ^ 2.3倍の明るさ、つまり約340000になります。

コンテンツを作成するすべての人（カメラメーカー）がこれを知っているか、または（デザイナーの場合）あなたは暗黙のうちにそれを補います。

ビットマップをレンダリングするだけであれば（ほとんどの場合）、これで十分ですが、3Dシーンでテクスチャとして使用する場合は別の話になります。ライトとの相互作用を正しくモデル化する場合は、レンダリングパイプライン全体で線形ライト計算を使用する必要があります。これの意味は

• ガンマのテクスチャを修正する

• すべてを線形光でレンダリングします（光の高ダイナミックレンジのために多くの精度が必要な場合）。

• 画像を画面に表示する前に、最後にモニターの逆ガンマ変換を適用します。

既存のアートワーク、ライトなどを使用して既存のシーンにこの変更を行う場合、非線形ライトでレンダリングするときに見栄えがよくなるように選択されているため、多くのライトの強度とテクスチャを修正する必要があります。したがって、「オン」にして、すべてがそのように良く見えることを期待できる機能ではありません。