Quelle précision (moitié, flottant, double, etc.) suffit pour une classe de couleur?

En lisant la façon dont les applications en temps réel gèrent les couleurs sous OpneGL, j'ai remarqué que certains exemples implémentaient Color en tant que collection de 4 floats, tandis que d'autres en utilisaient 4 doubles. J'ai même vu quelques exemples de compression de sommets dans le domaine du développement de jeux qui préconisaient d'enregistrer les couleurs comme 4 short.

Tout cela m'a donné envie d'en savoir plus: quelle est la précision limite que OpenGl (ou les matériels) gère pour les couleurs? Plus important encore, quelles sont les limites de précision au-dessus desquelles les différences de couleur deviennent impossibles à remarquer?

J'ai l'impression qu'apprendre plus à ce sujet m'aiderait à mieux réfléchir et à décider comment implémenter une classe de couleur pour différentes applications et différents scénarios (par exemple, faire des choix entre mémoire, vitesse et variété de couleurs).

Merci pour vos idées à ce sujet.

Les couleurs affichées sur votre écran ou enregistrées dans des formats de fichier d'image standard utilisent 8 bits par composant. Donc, pour stocker ces couleurs, il suffit d'utiliser quatre octets ( unsigned char). Ces couleurs utilisent généralement l' espace colorimétrique sRGB , qui comprend une transformation "gamma" non linéaire qui redistribue la précision pour la rendre un peu plus uniforme sur le plan perceptuel, de sorte qu'il est en fait assez proche de la limite de la précision avec laquelle les humains peuvent déjà percevoir les différences de couleur. (Cependant, la gamme sRGB n'est qu'un sous-ensemble de toutes les couleurs physiquement perceptibles. Les gammes plus larges nécessitent plus de bits.)

Cependant, si vous générez ou traitez des couleurs dans un logiciel graphique (et pas seulement en les chargeant / les stockant), il y a plusieurs raisons pour lesquelles vous voudrez peut-être utiliser plus de précision.

• Les opérations sur les couleurs, telles que le réglage de la luminosité et du contraste, le mélange alpha, la correction gamma, etc. ont toutes tendance à perdre en précision. Vous souhaiterez peut-être stocker les couleurs en 16 bits ou plus en interne pour vous donner plus de marge de précision. Sinon, un arrondi répété à 8 bits après chaque opération peut entraîner une perte progressive de qualité.
• De même, lorsque vous travaillez avec des couleurs linéaires (pas les couleurs codées gamma sRGB) pour l'éclairage mathématique, une précision supplémentaire est nécessaire pour vous assurer d'avoir une précision suffisante lorsque vous vous convertissez finalement en sRGB.
• Il peut être plus rapide et plus pratique de travailler avec des couleurs à virgule flottante au lieu de couleurs entières. Cela est particulièrement vrai sur les GPU, où les instructions mathématiques entières n'ont qu'une fraction du débit des instructions flottantes. Mais même sur les processeurs, il est certainement plus facile et probablement plus rapide de convertir les couleurs en flottant, d'effectuer un tas d'opérations, puis de reconvertir en entier, plutôt que d'essayer de tout faire avec des mathématiques à virgule fixe.
• Si vous effectuez un rendu HDR, vous aurez besoin de plus de 8 bits de précision pour gérer la gamme de couleurs et la plage d'intensité plus larges. Les nouveaux écrans HDR qui commencent à peine à sortir acceptent des images avec 10 ou 12 bits par composant.

L'utilisation doublepour les couleurs est une exagération massive, mais l'utilisation floatpour la représentation interne des couleurs est courante pour toutes les raisons ci-dessus. Lorsque vous travaillez avec des GPU, half(float 16 bits) est également courant, car ils prennent en charge ce format dans le matériel.