Colordepth 24 bits ne suffit pas?

J'ai remarqué que dans les dégradés très doux, la profondeur de couleur 24 bits n'est pas suffisante car vous pouvez voir les transitions de la couleur. Cela apparaît le plus dans les scènes sombres ou le ciel nocturne.

Pourquoi personne ne change-t-il la profondeur de couleur en deux octets par canal? Je sais que ce serait beaucoup de travail et que beaucoup de matériel devrait être remplacé, mais je trouve cela un peu ennuyeux. Je ne pense vraiment pas que la technologie du matériel ne soit pas suffisamment mature.

Alors pourquoi personne ne fait ça?

Voici une photo de "The War Z" où vous pouvez voir ce que je veux dire:

Vous l'avez plus ou moins dit vous-même: "Je sais, ce serait beaucoup de travail et beaucoup de matériel devrait être remplacé." Bien que la fin du matériel graphique soit en fait relativement simple (si elle coûte cher - doubler la taille de toutes les textures et tampons de cadre est loin d'être trivial), l '«écosystème» pour des images à plus grande profondeur de couleur n'est tout simplement pas en place pour le sorte de mesure qui en fait une dépense intéressante pour le compte de quiconque, car aucun fabricant d'écrans LCD ne se concentre sur la résolution de jusqu'à 16 bits par pixel (bien qu'il y ait eu des expériences à 10BPP, qui adaptent toujours un signal RVB dans un 32- canal de bits).

En bref, c'est tout simplement trop de travail pour ce que la plupart des gens considèrent comme un gain trop faible. C'est peut-être «un peu ennuyeux», mais ce niveau d'agacement est si mince que d'autres améliorations de la qualité d'image ont été prioritaires.

Oui, vous n'êtes pas la première personne à remarquer cela . :) Avec les taux de contraste élevés d'aujourd'hui, 8 bits par composant ne suffisent pas pour créer un dégradé fluide sans bandes visibles - sauf si le tramage est utilisé.

L'utilisation de plus de 8 bits par canal sur un écran est appelée « couleur profonde » par les fabricants d'écran. Ce n'est pas très répandu à cause d'un problème de poulet et d'oeuf. Un écran couleur profond est inutile sans une carte vidéo qui peut produire des couleurs profondes et un moteur de jeu qui prend en charge le rendu en couleurs profondes. De même, il n'y a aucun intérêt dans un moteur de jeu ou une carte vidéo qui prend en charge les couleurs profondes sans affichage. Il n'y a donc pas beaucoup d'incitation pour les fabricants de matériel et les développeurs de jeux à ajouter un support pour cette technologie, car de chaque côté, il n'y a pas de marché pour justifier le coût du développement.

En outre, il existe d'autres façons de corriger les bandes en raison de la précision limitée à 8 bits. Comme je l'ai mentionné précédemment, les moteurs de jeu peuvent utiliser le tramage pour masquer les bandes.

^{(Image d'un chat avec une palette de 256 couleurs, sans et avec tramage. Créé par l'utilisateur de Wikipedia Wapcaplet , utilisé sous la licence CC-By-SA 3.0 .)}

L'ajout d'un léger tramage de ± 0,5 / 255 avant d'écrire la valeur de pixel dans le tampon d'image est extrêmement efficace pour masquer les bandes sur des dégradés lisses et essentiellement imperceptibles. Si vous êtes dans un moteur HDR, vous le faites lors de l'étape de tonemapping.

Enfin, comme d'autres l'ont noté, la compression de texture peut être une plus grande source d'artefacts de type bande dans l'image que la précision à 8 bits. C'est peut-être ce qui se passe avec le ciel dans cette image, bien que ce soit difficile à dire - il y a tellement de compression JPEG que tous les artefacts dus à la compression DXT sont à peu près submergés.

Il convient également de noter que de nombreux panneaux LCD ne sont même pas 8 bits par canal. Les moins chers ont tendance à utiliser moins de bits et à utiliser diverses astuces pour essayer de le cacher. Par exemple, ils peuvent basculer rapidement entre deux couleurs adjacentes pour représenter celle entre les deux. http://www.anandtech.com/show/1557/3

Il y a quelques détails sur la façon dont DXGI prend en charge 10 bits par canal et plus lumineux que les couleurs blanches sur http://msdn.microsoft.com/en-us/library/windows/desktop/jj635732%28v=vs.85%29.aspx

D3D prend également en charge plus de 8 bits par canal depuis des années. Rien n'empêche un développeur de faire un tramage de 16 bits par canal à 8 bits s'il pense que c'est une bonne idée.

Bien sûr, cela n'aidera pas beaucoup si les données source (texture, etc.) ne sont que de 8 bits (ou plus probablement DXT1, qui est en fait 5-6-5 bits par canal). Je crois que c'est ce qui se passe avec le ciel dans cette capture d'écran (un flou gaussien de 8 bpp le rend beaucoup plus fluide pour moi), mais il est difficile d'être certain.

La réponse de Steven Stadnicki est correcte - les jeux utilisent rarement des textures de plus haute précision car ils nécessitent trop de mémoire de texture, et par conséquent trop de bande passante mémoire lors de l'échantillonnage de la texture dans un pixel shader. Cependant, il existe des solutions qui ne nécessitent pas de grandes textures. (Je posterais ceci en tant que commentaire, mais c'est trop long.)

Homeworld résout ce problème en encodant l'image du ciel en dégradés de sommets . Cette technique fonctionne très bien pour les grandes images à basse fréquence (c'est-à-dire les dégradés lisses) - comme le ciel - où la texture couvre un grand nombre de pixels dans le jeu.

Une autre solution possible consiste à appliquer la normalisation de l'histogramme à votre image du ciel. Si les données de texture se trouvent dans une plage de valeurs étroite, comme un ciel nocturne sombre, la plupart des bits de chaque canal de couleur ne contiennent aucune donnée utile. Au lieu de cela, procédez comme suit:

• Créez la texture d'origine dans un format 16 bits, comme un TIFF 16 bits.
• Lorsque vous préparez vos textures pour le moteur de jeu, recherchez le pixel le plus sombre présent dans l'image et suivez-le en tant que décalage. Supposons que cette valeur de pixel soit 0,1 dans une plage possible de 0-1.
• Ensuite, trouvez le pixel le plus clair et soustrayez le pixel le plus sombre pour obtenir la plage de valeurs dans l'image. Donc, si le pixel le plus lumineux est encore assez sombre - disons 0,35 - la plage n'est que de 0,35 à 0,1 = 0,25. Seulement 25% de la plage de valeurs est présente dans l'image.
• Générez votre texture de jeu compressée DXT / BC . Soustrayez la valeur la plus sombre de chaque pixel et multipliez-la pour utiliser toute la gamme de couleurs. Dans l'exemple de calcul, nous soustrayons notre valeur sombre de 0,1 et, comme seulement 25% de la plage de valeurs disponibles est présente, nous multiplions chaque valeur de pixel par 4x pour créer la texture dans le jeu. Assurez-vous de faire tout cela avant de quantifier votre image source 16 bits jusqu'à l'entrée 8bpp du compresseur DXT. L'image de sortie utilisera désormais toute la plage de valeurs prise en charge par le format en jeu. Nous allouons tous nos bits pour représenter les valeurs réellement présentes dans l'image.
• Stockez le décalage de la valeur sombre (0,1) et la plage (0,25) dans les métadonnées quelque part. Passez-les en tant qu'entrées à votre pixel shader.
• Dans le code pixel shader, échantillonnez votre texture déplacée et étendue, convertissez-la en une valeur flottante, puis effectuez une multiplication / addition pour restaurer la valeur de couleur d'origine. En d'autres termes, multipliez par 0,25 et ajoutez 0,1 pour restaurer la valeur stockée dans l'image source.

Assurez-vous que le code du shader est gamma correct . Si vous faites des calculs (éclairage et post-traitement) sur des échantillons de texture qui ne sont pas convertis de l'espace colorimétrique sRGB en espace linéaire, vous verrez des artefacts de bande comme celui que vous décrivez. La correction gamma a été créée pour atténuer ce type de problème en allouant plus de bits aux valeurs sombres où vos yeux sont plus sensibles aux changements de valeur. Mais vous pouvez facilement casser des choses si vous ne tenez pas compte de la correction gamma lors du calcul, par exemple, de l'éclairage, de l'exposition ou des effets post-traitement. La FAQ Gamma est utile.

24 bits n'est pas tout à fait suffisant, mais il est beaucoup plus fréquent que de tels problèmes soient causés par des algorithmes de compression d'image, un alias ou d'autres artefacts numériques. N'oubliez pas non plus le rôle de la technologie d'affichage - quelles que soient les entrées numériques, l'affichage peut ne pas produire les étapes appropriées en termes de luminosité réelle.