Keeping lighting calculations linear while using sRGB textures

この記事はまだ日本語では提供されていません。原文を表示しています。

article · en · 知識の基準日 2026-10-11 · 変更日 2026-10-11, リビジョン 1 · unreviewed

Trace colour values from texture storage through shading to display encoding, and distinguish colour maps from numerical data.

Follow the meaning of a value

An image can look correct in an image viewer yet produce incorrect lighting in a game. The stored channel value may be an encoded colour rather than an amount proportional to light. Lighting sums and weighted colour blends need linear-light values; changing exposure cannot generally repair arithmetic performed on encoded inputs. [1]

Treat each resource boundary as a contract: what do the bytes mean, what conversion occurs on read, and what does the next pass expect?

Distinguish colour from data

An sRGB texture format decodes colour channels when sampled. Its alpha channel is not given the same colour conversion. A normalized integer format and an sRGB format can store the same bytes while exposing different numerical values to shading. [2][3]

Base-colour images commonly need colour decoding. Roughness, masks, depth, and encoded normal components are numerical data and should follow their own declared representation. A file extension alone does not establish that meaning. Record both the authored encoding and the GPU view format.

Calculate a controlled example

Consider an illustrative neutral texel with stored sRGB value 0.5. Decoding the sRGB transfer function gives approximately 0.214 in linear light. Halving that light produces about 0.107; encoding the result back to sRGB gives approximately 0.361. These values are calculated from the transfer function, not measured display luminance. [2]

Build a test material that performs this operation with a constant multiplier. Compare its output with a precomputed reference patch. If the shader also decodes an automatically decoded texture, or the final pass encodes an already encoded result, the patches will diverge.

Audit the complete path

Start with unlit patches and disable artistic grading while testing. Inspect texture views, sampler results, intermediate targets, blending, and final output. Assign exactly one owner to each necessary conversion; a shader and an attachment format must not both perform the same encoding.

Next introduce two controlled lights and inspect their combined result before display conversion. Check mip generation separately, because correct sampling cannot repair incorrectly averaged source levels. Finally restore grading and verify UI colours through their actual compositing path.

Linear light describes arithmetic, while colour primaries define a gamut and floating-point storage defines a numerical representation. None alone guarantees the other two. An sRGB output conversion is also not a tone mapper for unrestricted HDR values.

Preserve diagnostic captures before and after output processing. When a material suddenly darkens after an import change, these captures help identify the first changed value instead of encouraging compensating edits across every material.

Sources

[1] The Importance of Being Linear — Larry Gritz and Eugene d’Eon, NVIDIA.
[2] EXT_texture_sRGB specification — Khronos OpenGL Registry.
[3] Data Conversion Rules — Microsoft.

範囲と根拠

Source-based synthesis; original illustrative examples; no experiment or benchmark claimed.

知識の基準日：2026-10-11。状態：unreviewed（レビュー記録なし） — 編集するとレビュー状態はリセットされます。本文は未検証の参考情報として扱い、出典を確認してください。

出典

帰属とライセンス

オリジナルの投稿： CC BY 4.0. リンク先の出典はそれぞれの権利を保持します。