Garder les calculs d'éclairage linéaires avec des textures sRGB

Suivre la signification d'une valeur

Une image peut paraître correcte dans un visionneur et pourtant produire un éclairage erroné dans un jeu. La valeur de canal stockée peut être une couleur encodée, et non une quantité proportionnelle à la lumière. Les sommes d'éclairage et les mélanges pondérés de couleurs exigent des valeurs en lumière linéaire ; modifier l'exposition ne permet généralement pas de corriger des calculs effectués sur des entrées encodées. [1]

Traitez chaque frontière entre ressources comme un contrat : que signifient les octets, quelle conversion a lieu à la lecture, et qu'attend la passe suivante ?

Distinguer la couleur des données

Un format de texture sRGB décode les canaux de couleur lors de l'échantillonnage. Le canal alpha, lui, ne subit pas la même conversion de couleur. Un format entier normalisé et un format sRGB peuvent stocker les mêmes octets tout en exposant au shading des valeurs numériques différentes. [2][3]

Les images de couleur de base nécessitent généralement un décodage de couleur. La rugosité, les masques, la profondeur et les composantes de normales encodées sont des données numériques et doivent suivre leur propre représentation déclarée. L'extension d'un fichier ne suffit pas à établir cette signification. Consignez à la fois l'encodage d'origine et le format de vue côté GPU.

Calculer un exemple contrôlé

Prenons, à titre d'illustration, un texel neutre dont la valeur sRGB stockée est 0,5. Le décodage par la fonction de transfert sRGB donne environ 0,214 en lumière linéaire. Réduire cette lumière de moitié donne environ 0,107 ; réencoder le résultat en sRGB donne environ 0,361. Ces valeurs sont calculées à partir de la fonction de transfert et ne correspondent pas à une luminance d'affichage mesurée. [2]

Construisez un matériau de test qui effectue cette opération avec un multiplicateur constant. Comparez sa sortie à une plage de référence précalculée. Si le shader décode en plus une texture déjà décodée automatiquement, ou si la passe finale encode un résultat déjà encodé, les plages divergeront.

Auditer l'ensemble du parcours

Commencez par des plages non éclairées et désactivez l'étalonnage artistique pendant les tests. Inspectez les vues de texture, les résultats d'échantillonnage, les cibles intermédiaires, le blending et la sortie finale. Attribuez un seul responsable à chaque conversion nécessaire : un shader et un format d'attachement ne doivent pas effectuer tous deux le même encodage.

Introduisez ensuite deux lumières contrôlées et inspectez leur résultat combiné avant la conversion pour l'affichage. Vérifiez la génération des mips séparément, car un échantillonnage correct ne peut pas réparer des niveaux sources moyennés de façon incorrecte. Enfin, rétablissez l'étalonnage et vérifiez les couleurs de l'interface via leur chemin de composition réel.

Ne pas confondre des concepts voisins

La lumière linéaire décrit un mode de calcul, tandis que les primaires de couleur définissent un gamut et que le stockage en virgule flottante définit une représentation numérique. Aucun de ces éléments ne garantit à lui seul les deux autres. De même, une conversion de sortie sRGB n'est pas un opérateur de tone mapping pour des valeurs HDR non bornées.

Conservez des captures de diagnostic avant et après le traitement de sortie. Lorsqu'un matériau s'assombrit soudainement après une modification d'import, ces captures aident à identifier la première valeur modifiée, plutôt que d'encourager des corrections compensatoires sur chaque matériau.

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.