Note de ce sujet :
  • Moyenne : 0 (0 vote(s))
  • 1
  • 2
  • 3
  • 4
  • 5
Interet du 16 bits
#1
Bonsoir,

Utilisateur exclusif de Darktable windows depuis janvier (abandon de Lightroom). Je me suis installé Gimp 2.1 en vue d'abandonner aussi photoshop element. (et ne pas utiliser photoshop CS2 gratuit , oui je boycotte)
Depuis mes premiers pas avec Gimp qui permet de travailler en 8, 16 et 32 bits, je me pose cette question:
finalement, pourquoi m'acharner à developper en 16 bits alors que mon écran est en 8 bits si je ne m'abuse?.

Au passage un grand merci à darktable.fr et ses contributeurs géniaux !!
Répondre
#2
(04-10-18, 22:25)TheMrCzi a écrit : finalement, pourquoi m'acharner à developper en 16 bits alors que mon écran est en 8 bits si je ne m'abuse?.

Parce que ton écran n'affiche pas les données mais leur représentation. Ton écran est limité, mais ça ne limite pas pour autant les opérations que tu peux réaliser sur les données.

Ex : tu veux pousser la luminosité dans une zone sombre. Si tu es en 8 bits, tu as un risque de postériser (= créer des aplats au lieu d'avoir des transitions continues). Pourquoi ? Augmenter l'exposition, c'est une multiplication simple des valeurs RGB. Imagine que tu es en RGB 8 bits, dans une zone sombre où tu as une belle transition de pixels qui ont des valeurs RGB de 0 à 4 (sur une échelle de 255). Multiplie tes pixels par 2 :
  • les pixels qui étaient à 0 restent à 0
  • les pixels qui étaient à 1 passent à 2
  • les pixels qui étaient à 2 passent à 4
  • les pixels qui étaient à 3 passent à 6
  • les pixels qui étaient à 4 passent à 8.
Ça veut dire qu'à la fin, tu n'as aucun pixel à 1, 3, 5, 7. Donc tu as cassé ta transition tonale. Si tu multiplies par 3, tu sautes 2 valeurs sur 3, si tu multiplies par 4, tu sautes 3 valeurs sur 4 etc. Plus la correction est intense, plus ça fait mal.

Si tu travailles en 16 bits, il se passe la même chose. Sauf que, cette fois-ci, ta transition s'étale (à luminosité égale) entre 0 et 1028 (sur une échelle de 65535). Mais tu affiches du 8 bits, donc avant l'affichage, tu dois convertir tes données, par une simple règle de 3 : divise par 65535 puis multiplie par 255 et arrondis à l'entier le plus proche.

L'effet de la conversion 16 -> 8 bits avec arrondi est qu'on va lisser et « boucher » la cassure des transitions. Donc, une fois revenu en 8 bits, tu as un dégradé continu de 0 à 8, sans saut de valeur (= sans postériser).

Il faut vraiment distinguer, conceptuellement, la donnée (ce qui est enregistré dans le fichier numérique) de sa représentation (ce qu'on voit à l'écran). C'est un des rares cas où la philosophie trouve une application technologique directe.

Et on travaille toujours dans un espace plus précis que celui où l'on affiche, parce que certaines opérations mathématiques sur l'image vont dilater les erreurs d'arrondi et tout faire exploser. On ne réduit la précision qu'à la toute fin, quand on a finit les calculs, parce que c'est destructif (donc irréversible).
Aurélien, photographe portraitiste, spécialiste calcul.
Développeur de filmique, égaliseur de tons, balance couleur, etc.
darktable est mon métier, pensez à m'aider :
[Image: 2FAd4rc]
Répondre
#3
Thumbs Up 
(05-10-18, 00:41)aurelienpierre a écrit :
(04-10-18, 22:25)TheMrCzi a écrit : finalement, pourquoi m'acharner à developper en 16 bits alors que mon écran est en 8 bits si je ne m'abuse?.

Parce que ton écran n'affiche pas les données mais leur représentation. Ton écran est limité, mais ça ne limite pas pour autant les opérations que tu peux réaliser sur les données.

Ex : tu veux pousser la luminosité dans une zone sombre. Si tu es en 8 bits, tu as un risque de postériser (= créer des aplats au lieu d'avoir des transitions continues). Pourquoi ? Augmenter l'exposition, c'est une multiplication simple des valeurs RGB. Imagine que tu es en RGB 8 bits, dans une zone sombre où tu as une belle transition de pixels qui ont des valeurs RGB de 0 à 4 (sur une échelle de 255). Multiplie tes pixels par 2 :
  • les pixels qui étaient à 0 restent à 0
  • les pixels qui étaient à 1 passent à 2
  • les pixels qui étaient à 2 passent à 4
  • les pixels qui étaient à 3 passent à 6
  • les pixels qui étaient à 4 passent à 8.
Ça veut dire qu'à la fin, tu n'as aucun pixel à 1, 3, 5, 7. Donc tu as cassé ta transition tonale. Si tu multiplies par 3, tu sautes 2 valeurs sur 3, si tu multiplies par 4, tu sautes 3 valeurs sur 4 etc. Plus la correction est intense, plus ça fait mal.

Si tu travailles en 16 bits, il se passe la même chose. Sauf que, cette fois-ci, ta transition s'étale (à luminosité égale) entre 0 et 1028 (sur une échelle de 65535). Mais tu affiches du 8 bits, donc avant l'affichage, tu dois convertir tes données, par une simple règle de 3 : divise par 65535 puis multiplie par 255 et arrondis à l'entier le plus proche.

L'effet de la conversion 16 -> 8 bits avec arrondi est qu'on va lisser et « boucher » la cassure des transitions. Donc, une fois revenu en 8 bits, tu as un dégradé continu de 0 à 8, sans saut de valeur (= sans postériser).

Il faut vraiment distinguer, conceptuellement, la donnée (ce qui est enregistré dans le fichier numérique) de sa représentation (ce qu'on voit à l'écran). C'est un des rares cas où la philosophie trouve une application technologique directe.

Et on travaille toujours dans un espace plus précis que celui où l'on affiche, parce que certaines opérations mathématiques sur l'image vont dilater les erreurs d'arrondi et tout faire exploser. On ne réduit la précision qu'à la toute fin, quand on a finit les calculs, parce que c'est destructif (donc irréversible).

Je développe ma photo en 16 bits avec un aperçu un peu dégradé en 8bits...Si le 8 bits est si continu que cela au final de 0 à 8 sans postériser alors pourquoi charger la mule à 16 bits au départ à part pour se rassurer que l'on a un raw avec un bien meilleur potentiel?
Mais je vais me  repasser ta réponse et y réfléchir . Pas simple .
En tout cas,  Un grand merci pour cette réponse et chapeau bas pour tes passionnants articles  !!
Répondre
#4
(05-10-18, 05:58)TheMrCzi a écrit : Je développe ma photo en 16 bits avec un aperçu un peu dégradé en 8bits...Si le 8 bits est si continu que cela au final de 0 à 8 sans postériser alors pourquoi charger la mule à 16 bits au départ à part pour se rassurer que l'on a un raw avec un bien meilleur potentiel?

Relis calmement.

Le 8 bits n'est ni continu n'est ni discontinu. Ce sont certaines opérations mathématiques effectuées pendant la retouche (ici, j'ai pris l'exemple de la correction d'exposition) qui crééent de la discontinuité dans la représentation 8 bits de l'information (dans mon exemple, on a 1 valeur sur 2 qui n'est pas utilisée). Ces discontinuités seront moins marquées si on utilise plus de bits parce qu'on a beaucoup plus de valeurs disponibles (65535 au lieu de 255, donc on peut en perdre 1 sur 2 sans trop que ça se voit) et que la conversion ultérieure vers 8 bits va les lisser.

Donc on a besoin de faire le calcul sur 16 bits, mais on peut se contenter d'afficher sur 8 bits. Tout ça parce que, 8 ou 16 bits, on est toujours en nombre entier, donc à chaque calcul on arrondi à l'entier le plus proche. En 8 bits, l'arrondi induit une erreur maximale de 0,002. En 16 bits, on a une erreur maximale d'arrondi de 0,000008. Mais dans les deux cas, on a une erreur de calcul.

En gros, le 16 bits est un espace précis où certaines opérations mathématiques ont moins d'effet secondaires indésirables. Une fois que les opérations sont faites, on n'a plus forcément besoin de toute cette précision.

(05-10-18, 05:58)TheMrCzi a écrit : En tout cas,  Un grand merci pour cette réponse et chapeau bas pour tes passionnants articles  !!

Merci !
Aurélien, photographe portraitiste, spécialiste calcul.
Développeur de filmique, égaliseur de tons, balance couleur, etc.
darktable est mon métier, pensez à m'aider :
[Image: 2FAd4rc]
Répondre
#5
OK !!!

L’intérêt du 16 bits c'est au développement uniquement qu'on le trouve surtout si l'on pousse un peu fort les réglages: tout devient clair !

Encore merci pour ces explications
Répondre
#6
Oui c'est exactement cela! Comme le dit Aurélien ça peut faire une énorme différence dans les changement doux des tonalités (le fameux banding effect dans le ciel par exemple).
--
Pascal - GNU/Debian (sid) - version darktable git/master
http://photos.obry.net
Répondre


Atteindre :


Utilisateur(s) parcourant ce sujet : 1 visiteur(s)