Ton raisonnement sur les bits prouve une seule chose : pour l’affichage final, 8 bits par canal suffisent amplement.
Le problème c’est quand tu veux traiter une photo 8 bits et que le résultat final reste potable.
Cas d’école : photo sous-exposée, on veut augmenter la luminosité et le contrate.
Sur l’image de départ, supposons qu’aucun pixel n’a une valeur supérieure à 24 sur les 28 possibles.
On aura beau appliquer toutes les transformations qu’on veut afin d’étaler les valeurs sur tout le spectre des valeurs, il restera que seules 24 valeurs seront utilisées au total (sur 3 canaux, ça fait 4096 couleurs... ça fait peu).
Si on avait eu une photo en 16 bits, on aurait pu avoir un résultat final en qualité 8 bits.
Ce raisonnement est aussi utilisé pour l’audio, avec les cartes sons actuelles qui gèrent l’échantillonnage 24 bits à 192 kHz ou plus, là où le CD se contente de 16bits à 44,1 kHz.
[^] # Re: Euh...
Posté par Aldoo . En réponse au journal Suite de "Ce qui manque à GNU/LINUX........ Évalué à 9.
Le problème c’est quand tu veux traiter une photo 8 bits et que le résultat final reste potable.
Cas d’école : photo sous-exposée, on veut augmenter la luminosité et le contrate.
Sur l’image de départ, supposons qu’aucun pixel n’a une valeur supérieure à 24 sur les 28 possibles.
On aura beau appliquer toutes les transformations qu’on veut afin d’étaler les valeurs sur tout le spectre des valeurs, il restera que seules 24 valeurs seront utilisées au total (sur 3 canaux, ça fait 4096 couleurs... ça fait peu).
Si on avait eu une photo en 16 bits, on aurait pu avoir un résultat final en qualité 8 bits.
Ce raisonnement est aussi utilisé pour l’audio, avec les cartes sons actuelles qui gèrent l’échantillonnage 24 bits à 192 kHz ou plus, là où le CD se contente de 16bits à 44,1 kHz.