色空間とガンマ補正

ピクセル値は「明るさ」ではない

多くの人が暗黙に「ピクセルの 0〜255 は明るさに比例する」と考えますが、これは誤りです。sRGB をはじめとする一般的な画像フォーマットのピクセル値は、物理的な輝度（放射輝度）に比例しない非線形な符号として格納されています。値 128 は白（255）の物理的なちょうど半分の明るさではなく、実際には約 5 分の 1 程度の輝度しかありません。

この非線形性が「ガンマ」です。ガンマを正しく扱えるかどうかが、画像の合成・拡大縮小・ライティングが物理的に正しく見えるかを左右します。まず「なぜ非線形なのか」から押さえます。

ガンマの起源と知覚的な合理性

ガンマの直接の起源は CRT ディスプレイの物理特性です。CRT は入力電圧に対して輝度が 輝度 ∝ 電圧^γ（γ ≒ 2.2）のべき乗で応答しました。この非線形性を打ち消すため、カメラ側や信号側で逆のべき（約 1/2.2）をあらかじめ掛けておく——これが本来の「ガンマ補正」です。両者が打ち消し合って、全体として直線的な明るさが再現される、という発想でした。

CRT が消えた現在もガンマが残るのは、人間の視覚が明るさを対数的（べき乗的）に知覚するため、この符号化が都合よく効率的だからです。人間は暗部の微妙な差には敏感で、明部の差には鈍感です。8 ビットの限られた符号を輝度に線形に割り当てると、暗部に階調が足りずバンディング（縞）が出ます。ガンマ符号化は暗部に符号を厚く配分するので、同じ 8 ビットでも知覚的に均一な階調が得られます。

リニアとエンコード済みを区別する

議論を明確にするため、2 つの空間を厳密に分けます。

決定的な事実は、光の物理は加算的で線形だということです。2 つの光源が同じ面を照らせば、そこに届く放射輝度は単純な和になります。半透明のガラス越しに見える色は、背後の光と手前の光の線形な重み付き和です。ところが sRGB 値どうしを直接足したり平均したりすると、この線形性が崩れます。非線形符号の平均は、対応する光の量の平均には一致しないからです。

なぜ合成・フィルタは破綻するのか

具体例で破綻を見ます。純赤 (255,0,0) と純緑 (0,255,0) を 50:50 でアルファブレンドすることを考えます。素朴に sRGB 値を平均すると (128,128,0) になり、これは暗くくすんだオリーブ色です。しかし物理的には、赤の光と緑の光を等量重ねた中間色はもっと明るい黄土色になるべきです。差が出るのはブレンドをエンコード済み空間で行ったからです。

正しいアルファブレンド（不透明度 a で前景を背景に重ねる）:

  1. 前景・背景をそれぞれデガンマしてリニアへ:
       fg_lin = decode(fg_srgb)
       bg_lin = decode(bg_srgb)
  2. リニア空間で線形補間:
       out_lin = a・fg_lin + (1 - a)・bg_lin
  3. 表示・格納のためエンコードして戻す:
       out_srgb = encode(out_lin)

誤り（よくあるバグ）:
  out_srgb = a・fg_srgb + (1 - a)・bg_srgb   ← 暗部が沈み色がくすむ

同じ問題はあらゆる「複数ピクセルを混ぜる操作」に潜みます。画像の縮小（複数テクセルの平均）、ガウシアンぼかし（重み付き和）、アンチエイリアス（カバレッジに応じた混合）、ミップマップ生成——これらをエンコード済み空間で行うと、一様に暗く沈み、細い明線が痩せます。とくに白背景に黒文字を縮小すると、リニアで処理した場合よりエッジが太く滲んで見えます。すべて「非線形値を線形操作した」ことに由来します。

リニアワークフローという一貫した規律

個々のバグを潰すのではなく、パイプライン全体を一つの規律で貫くのがリニアワークフローです。原則は単純です。

入力（テクスチャ・素材）  ──decode──▶  [ すべての計算はリニア空間 ]  ──encode──▶  出力（画面・ファイル）
   sRGB / ガンマ符号                     ライティング・合成・フィルタ            sRGB / ガンマ符号

要点は「境界でのみ変換し、内部は一貫してリニアに保つ」ことです。実務では次の非対称性に注意します。

• アルベド（基本色）テクスチャは色なので sRGB 符号化されている。読み込み時にデガンマが必要。
• 法線マップ・粗さ・メタルネス・ハイトマップは色ではなくデータ（方向や係数）で、リニアに格納されている。これをデガンマしてはいけない。誤ってガンマを掛けると法線がねじれ陰影が壊れる。

HDR とトーンマッピング

リニア空間で物理的にライティングすると、値は 0〜1 に収まりません。太陽や光源のハイライトは 1.0 をはるかに超える放射輝度を持ちます。これが HDR（High Dynamic Range）レンダリングで、内部計算は上限のない浮動小数点で行います。問題は、この広いダイナミックレンジを、限られた表示レンジへどう写すかです。

トーンマッピングは HDR のリニア輝度を表示可能な範囲へ圧縮する非線形変換です。単純にクリップ（1.0 で頭打ち）すると、明るい部分がすべて真っ白に飛び、ハイライトのディテールが失われます。そこで、暗部・中間部の階調をできるだけ保ちつつ明部をなだらかに丸め込む曲線（Reinhard、ACES フィルミックなど）を使います。

HDR パイプラインの並び（順序が重要）:

  リニアHDR（範囲無制限, fp16）
    → トーンマッピング（レンジ圧縮, まだリニア寄りの表示リニア）
    → エンコード（sRGB や PQ で符号化）
    → 出力

  注意: トーンマッピングはエンコード（ガンマ）の前に行う。
        先にエンコードしてから圧縮すると輝度関係が崩れる。

ここで用語の混同に注意します。SDR 表示向けのトーンマッピングは「HDR で計算した結果を 8 ビット sRGB に収める」処理を指します。一方、HDR ディスプレイ（HDR10 など）へ出力する場合は、sRGB ではなく PQ（Perceptual Quantizer, SMPTE ST 2084） や HLG（Hybrid Log-Gamma） という別の伝達関数でエンコードします。PQ は絶対輝度（cd/m²、ニト）を最大 10000 ニトまで符号化する方式で、相対値だった sRGB とは設計思想が異なります。

色域はガンマとは別の軸

最後に、しばしばガンマと混同される「色域（gamut）」を切り分けます。ガンマ（伝達関数）は明るさの符号化方式であり、色域は表現できる色の範囲です。両者は直交する独立した概念です。

色域は、色度図の上で 3 つの原色（赤・緑・青の頂点）が作る三角形の面積として表されます。原色が飽和して外側にあるほど三角形は広く、鮮やかな色まで表現できます。

同じ (255,0,0) でも、それが sRGB の赤なのか Display P3 の赤なのかで、実際に発光する色は違います。したがって色は必ず色空間の指定（プロファイル）とセットで扱う必要があります。異なる色域の間で色を移すには、白色点を合わせたうえで原色の座標系を変換する行列演算（色域マッピング）が要り、送り先の三角形からはみ出す色は境界へ丸めます（ガマットマッピング）。この「符号化（ガンマ／PQ）」と「色域」を別々に指定する考え方は、資格試験でも実務でも取り違えやすい最重要ポイントです。

まとめ

• sRGB 等のピクセル値は輝度に比例しない**非線形符号（ガンマ）**で、暗部に階調を厚く配る知覚的効率のために存在する。
• 光の物理は線形なので、ブレンド・縮小・ぼかし・ライティングは必ずデガンマしてリニア空間で計算し、出力時に再エンコードする（リニアワークフロー）。
• 色テクスチャはデガンマが要るが、法線・粗さ等のデータテクスチャはリニア格納なのでデガンマしてはならない。中間バッファは高ビット深度で持つ。
• HDR は上限なしのリニアで計算し、トーンマッピングでレンジ圧縮してからエンコードする。HDR 表示は sRGB でなく PQ／HLG を使う。
• 色域（表現できる色の範囲）と伝達関数（明るさの符号化）は独立した別軸。色は必ずプロファイルとセットで扱う。