Pour les mathématiques de shader, pourquoi le RVB linéaire devrait-il conserver la gamme de sRGB?

sRGB est souvent contrasté avec «RVB linéaire».

• Les images sont stockées sur disque et transmises à des affichages en sRGB, qui est à peu près uniforme en termes d'intensité perceptuelle.
• Les mathématiques de shader sont effectuées en RVB linéaire, qui est physiquement uniforme en intensité.
• La correction gamma peut être appliquée pour convertir entre les deux.

Maintenant, sRGB a une norme qui spécifie colorimétriquement sa gamme, indiquant exactement où se trouvent le rouge, le vert, le bleu et le blanc purs. Mais il n'y a pas de norme correspondante pour juste "RVB linéaire". Tout triangle sur un diagramme de chromaticité pourrait être considéré comme linéaire, et, en effet, il existe plusieurs gammes bien connues:

En pratique, lorsque nous disons «RVB linéaire», nous voulons dire «sRGB sans la correction gamma». (C'est implicitement ce que nous faisons lorsque nous appliquons la correction gamma sRGB comme dernière étape de post-traitement, mais ignorons les espaces colorimétriques pour le reste du pipeline de rendu.)

Mais pourquoi cette gamme RVB est -elle la bonne à utiliser pour les calculs d'interpolation et d'éclairage? Cela semble arbitraire. Si quoi que ce soit, ne voudrions-nous pas utiliser la gamme la plus large possible pour les calculs internes, puis découper ou mettre à l'échelle les couleurs dans la gamme du périphérique de sortie à la toute fin?

Est-ce que l'éclairage RVB sera approximatif, peu importe quoi, donc peu importe la gamme que nous choisissons, et nous pouvons aussi bien choisir celle la plus proche de ce que l'écran prend en charge nativement? Est-ce simplement de la négligence? Ou est-ce que les calculs dans ces différentes gammes donnent en fait exactement les mêmes résultats?

Il faut éviter de parler de RVB linéaire car il ne vous dit rien sur les caractéristiques intrinsèques de l'espace colorimétrique RVB, c'est-à-dire les fonctions de transfert des composants primaires, des points blancs et des composants de couleur. Il y a quelques années, en supposant que le sRGB était moyen mais de nos jours avec DCI-P3 et BT.2020 étant très courant, il doit être exclu.

La gamme idéale pour le rendu est celle qui minimisera les erreurs par rapport à une référence du monde réel ou plus commodément un rendu spectral de vérité au sol. Le premier point à retenir de cette phrase est que les différents espaces de couleurs RVB ne sont pas équivalents et ne produiront pas de résultats similaires.

On pourrait penser que l'exécution de deux rendus avec les mêmes couleurs de base, mais l'un où ils sont encodés avec sRGB / BT.709 et l'autre où ils sont encodés avec DCI-P3, puis en convertissant les deux images résultantes en par exemple ACES2065-1, donne les mêmes images mais ce n'est pas le cas. Certaines opérations mathématiques en raison de la nature de l'algèbre linéaire et des matrices dépendent des primaires d'espace colorimétrique RVB données, c'est-à-dire de la base des espaces chromatiques. Les mêmes opérations effectuées dans différents espaces colorimétriques RVB produiront différentes valeurs de tristimulus une fois reconverties en espace colorimétrique CIE XYZ. Par exemple, les opérations de multiplication, de division et de puissance dépendent des couleurs primaires RVB, tandis que l'addition et la soustraction ne le sont pas.

Cette image illustre l'effet de la multiplication de différentes couleurs par elles-mêmes dans différents espaces de couleurs RVB: les couleurs résultantes sont différentes. Les différents échantillons sont générés comme suit: 3 valeurs aléatoires de l'espace colorimétrique sRGB sont sélectionnées et converties en trois espaces colorimétriques RVB étudiés, elles sont exponentiées, reconverties en espace colorimétrique sRGB, tracées dans le diagramme de chromaticité CIE 1931 à gauche et affichées sous forme d'échantillons sur le droite.

Tests et recherches menés par Ward et Eydelberg-Vileshin (2002) , Langlands et Mansencal (2014) et Mansencal (2014) ont montré que les gammes avec des primaires les plus proches du locus spectral, c'est-à-dire des primaires spectralement nettes, tendent à minimiser les erreurs par rapport au sol spectral la vérité rend.

Voici une image que j'ai récemment rendue avec Mitsuba pour revalider nos résultats avec Anders:

Ce sont des rendus de la même scène en utilisant les primaires BT.709 (première rangée), 47 bacs spectraux (deuxième rangée), les primaires BT.2020 (troisième rangée), les spectres moins BT.709 les primaires montrent les résidus (quatrième rangée), spectral moins BT .2020 primaires rend les résidus (cinquième rangée). La dernière rangée présente des images composites assemblées avec trois bandes verticales des rendus primaires primaires BT.709, spectraux et BT.2020. L'éclairage direct a tendance à correspondre entre les rendus. Les zones qui montrent l'effet de multiples rebonds lumineux, c'est-à-dire le plafond, dans les rendus primaires BT.709 et BT.2020 ont tendance à présenter une saturation accrue, en particulier dans les rendus primaires BT.709 ou une légère perte d'énergie, en particulier dans le BT Rendu .2020. À l'exclusion des valeurs aberrantes, par exemple, la source de lumière visible, le RMSE avec le rendu spectral est de 0,0083 et0,0116 pour respectivement les primaires BT.2020 et les primaires BT.709.

Maintenant, cela ne signifie pas qu'ils fonctionneront toujours mieux, et on pourrait être en mesure de produire des exemples qui présenteront un biais vers BT.709 / sRGB. Le principal point à retenir est que les rendus RVB ne peuvent pas correspondre aux rendus spectraux et que les gammes larges et nettes ont tendance à mieux fonctionner. Quant au choix d'un espace colorimétrique de rendu, j'en choisirais un avec une large gamme qui englobe la gamme de pointeurs et DCI-P3, BT.2020 ou ACEScg sont d'excellents candidats pour cela.

En pratique, lorsque nous disons «RVB linéaire», nous voulons dire «sRGB sans la correction gamma».

Il serait plus juste de dire qu'il y a "l'espace colorimétrique sRGB" et "l'espace colorimétrique sRGB linéarisé", avec la définition de spécification sRGB la conversion de l'un à l'autre.

Oui, il existe une infinité d'espaces colorimétriques "RVB linéaire". Mais la chose que tous ces espaces de couleurs "RVB linéaire" ont en commun, c'est qu'ils sont linéaires . Cela signifie que, si vous doublez la valeur d'un composant, vous doublez l'intensité de la lumière que le composant représente. C'est essentiellement ce que signifie être "linéaire": il y a une correspondance linéaire entre les valeurs de couleur et l'intensité résultante de cette couleur de lumière.

Ceci est important car les équations d'éclairage ne fonctionnent pas si les valeurs de couleur ne correspondent pas linéairement aux intensités lumineuses. Mais les équations ne se soucient pas qui colorspace linéaire vous utilisez; il vous suffit d'en choisir un.

Ainsi, l'espace colorimétrique sRGB linéarisé n'est pas plus correct qu'un espace colorimétrique Adobe RGB linéarisé ou un espace colorimétrique SWOP CMYK linéarisé. Ce qui compte, c'est précisément deux choses:

1. L'espace colorimétrique représente une cartographie linéaire des valeurs aux intensités lumineuses.
2. L'espace colorimétrique choisi est systématiquement utilisé dans l'équation d'éclairage. Autrement dit, toutes les couleurs utilisées dans l'équation d'éclairage proviennent du même espace colorimétrique (linéaire).

Est-ce que l'éclairage RVB sera approximatif, peu importe quoi, donc peu importe la gamme que nous choisissons, et nous pouvons aussi bien choisir celle la plus proche de ce que l'écran prend en charge nativement?

Cela, et le fait que la conversion sRGB est intégrée au matériel de nos jours, alors que la conversion d'autres espaces colorimétriques ne l'est pas souvent. Donc, si vous souhaitez utiliser l'espace colorimétrique Adobe RVB linéarisé, vous devez faire beaucoup de travail dans vos shaders pour linéariser les valeurs de texel et effectuer correctement une interpolation bilinéaire / trilinéaire (ce qui doit être fait après la linéarisation) avant de pouvoir même appliquer les à l'équation d'éclairage. Ensuite, vous devez effectuer la conversion d'Adobe RGB linéarisé en sRGB linéarisé, afin de pouvoir écrire sur une image de tampon d'image sRGB pour l'affichage.

Ou vous pouvez simplement utiliser sRGB linéarisé partout et avoir des performances. Ce dernier a tendance à l'emporter.

Il y a deux côtés pour expliquer pourquoi le sRGB en particulier. Pour les images d'entrée non HDR, il est supposé que celles-ci doivent être supposées être compressées en sRGB (si cette affirmation est exacte est une autre histoire). Par conséquent, avant de pouvoir effectuer une opération mathématique linéaire sur eux, vous devez les décompresser du sRGB. Il est également possible qu'une image ait été capturée et compressée en une représentation différente qui n'est pas sRGB, auquel cas vous devez décompresser cette représentation spécifique. Dans tous les cas, l'encodage implique une certaine gamme de couleurs que l'image d'entrée n'échappera jamais (car les images stockées sRGB sont généralement tronquées à 8 bits par canal), mais vos calculs de shader n'ont pas à rester dans cette gamme après l'entrée l'image est décompressée. Mais à la fin, vous devez considérer l'affichage.

Si vous avez une image et qu'il est temps de l'afficher, vous l'encodez dans une représentation requise par le périphérique d'affichage. Les CRT ont choisi sRGB, puis les LCD ont émulé cela, donc la compression sRGB pour l'affichage du moniteur a été le choix commun au cours des dernières décennies, et cela a limité la sortie pour qu'elle reste dans la gamme sRGB, sinon un écrêtage se produira. Les écrans plus larges n'ont pas à s'en tenir à cette gamme exacte.

(Je pense que la base de l'affirmation selon laquelle les images créées par l'homme sont codées sRGB est parce que ces images étaient supposées avoir été créées sur des écrans sRGB)

Alors maintenant, vous pouvez probablement mieux comprendre pourquoi le sRGB en particulier a été pris en charge dans le matériel pour l'entrée mathématique des shaders et l'affichage des images. C'est le cas commun. De plus, il a de bons avantages pour réduire les artefacts de bandes de couleurs perceptuelles, c'est donc un bon moyen de compresser les couleurs en 8 bits et de les garder plausibles pour les humains.

Si vous autorisez des valeurs en dehors de la plage de 0..1, même avec les primaires assez limitées de sRGB, vous pouvez toujours traiter la gamme visuelle humaine entière. Donc, pour stocker des valeurs de couleur de lumière à virgule flottante, les primaires que vous utilisez ne devraient pas trop avoir d'importance. Cependant, faire n'importe quel type de calcul multiplicatif devient un peu génial, car les coordonnées arbitraires des primaires agissent comme le «pivot» de mise à l'échelle. Les primaires sRGB sont généralement utilisées parce que traditionnellement vos données d'entrée sont encodées sRGB et que l'affichage de sortie est sRGB ou rec709 ... Avec rec2020, la moitié de cela a changé, mais pour l'instant, la plupart de vos données d'entrée sont toujours probablement encodées sRGB, donc en utilisant les mêmes primaires que votre stockage ne sont que l'option la plus simple.