Récap. Ecrans et Espaces colorimétriques

[phil67]

Bonjour,
Quelqu'un saurait il compléter le tableau ci dessous ? Même partiellement ?
Ou bien existe il un fil sur ce sujet ?

Espace   Codage     Création   Nbr couleur          Génération Hardware correspondante
-------------------------------------------------------------------------------------
Naturel        ///         ///           2M couleur         Perception oeil humain
sRVB      3x8bits      1996        2,6M couleur         Ecran cathodique
Adobe RVB          1998                             Ecran LCD    (99 à 100% adobe depuis l'apparition des dalles IPS large gamut)
....
Prophoto                                             

Merci pour votre aimable collaboration.

[Verso92]

Il me semble que les espaces Adobe RVB et ProPhoto sont en 16 bits...
(à ma connaissance, il n'existe pas d'écran couvrant l'espace ProPhoto)

[pgrat]

Il me semble que les espaces Adobe RVB et ProPhoto sont en 16 bits...

Sûrement pas ! Adobe 98 est en 8 bits.

[Verso92]

Sûrement pas ! Adobe 98 est en 8 bits.

Au temps pour moi...
(j'ai sans doute été trompé par le fait qu'on voyait une différence entre 8 et 10 bits sur un écran WG sur la mire AMD dans l'espace Adobe RVB...)

[Pat20d]

Sûrement pas ! Adobe 98 est en 8 bits.

C'est vrai que dans les specs c'est en 8 bits.
Mais si par exemple dans ACR on spécifie la sortie (Paramètres du flux de production) en Adobe et 16 bits, on peut considérer qu'on a le choix ?
Dans le cas du dématriçage d'un fichier RAW ce cas là en tout cas.

[Jean Delmas]

Sûrement pas ! Adobe 98 est en 8 bits.

Mais si, le standard Adobe RGB (1998) repris par l'ICC et par l'ISO prévoit un encodage avec des nombres entiers de 8 ou 16 bits, et un encodage sur 32 bits en virgule flottante.

[pgrat]

J'ai vu cette info sur le site de l'ICC qui reste en contradiction avec les spécifications d'Adobe révisées en 2005 qui précise toujours un encodage en 24 bits.

[Verso92]

C'est vrai que dans les specs c'est en 8 bits.
Mais si par exemple dans ACR on spécifie la sortie (Paramètres du flux de production) en Adobe et 16 bits, on peut considérer qu'on a le choix ?
Dans le cas du dématriçage d'un fichier RAW ce cas là en tout cas.

Ne pas confondre la profondeur de codage d'une image et celle de l'espace couleur...

[phil67]

J'ai vu cette info sur le site de l'ICC qui reste en contradiction avec les spécifications d'Adobe révisées en 2005 qui précise toujours un encodage en 24 bits.

Encode en 24 bits (= 3 couleurs en 8 bits).

CE2 : 3 x 8 = ? ? ? ? ? ? ?    réponse = 24.

Mais cela ne complète toujours pas mon tableau !
Quelqu'un a t'il d'autres infos pour le compléter ?
Merci déjà pour ces premiers éléments de réponse.

[Verso92]

Encode en 24 bits (= 3 couleurs en 8 bits).

CE2 : 3 x 8 = ? ? ? ? ? ? ?    réponse = 24.

Avant de te moquer, relis mieux le post de pgrat...

J'ai vu cette info sur le site de l'ICC [Adobe RVB = 3 x 8 bits OU 3 x 16 bits, NDLR] qui reste en contradiction avec les spécifications d'Adobe révisées en 2005 qui précise toujours un encodage en 24 bits [3 x 8 bits, NDLR].

[Apo2935]

 [at]  phil67

A la vue de votre signature, (vous "semblez" être un "Professionnel du tirage"), je pense que vous devriez déjà savoir tout cela par coeur ...

Nul besoin de demander à des amateurs les réponses à ces questions.

Bonne journée

[Verso92]

J'ai vu cette info sur le site de l'ICC qui reste en contradiction avec les spécifications d'Adobe révisées en 2005 qui précise toujours un encodage en 24 bits.

Bon, j'ai quand même un peu de mal à suivre... dans le document Adobe que tu mets en lien, il semblerait justement qu'un encodage en (3 x) 16 bits soit prévu...

[Apo2935]

 [at]  verso

il y a un petit "8" en indice à coté des R, G , et B, et c'est indiqué également 24-Bit Adobe RGB

"Ne pas confondre la profondeur de codage d'une image et celle de l'espace couleur...", c'est bien exact, et la réponse est là (cf ci dessus)

... mais quelqu'un va surement me démontrer le contraire ...

... et de toutes les façons, je m'en fiche un peu, je n'utilise pas cet espace ridicule ...

[Pat20d]

Hum
Je veux bien que vous m'expliquiez.
Lors du dématricage,  ACR (par exemple) charge les données du RAW codées en 12, ou 14 bits par exemple et les traite dans son espace (Melissa) et en 16 bits ou plus ?

Lors de l'export vers PS par exemple on spécifie la profondeur du codage 8 ou 16 bits.

Que veut dire exactement pour vous dans ce contexte la différence entre la profondeur de codage de l'image et celle de l'espace couleur ?

[Verso92]

[at]  verso

il y a un petit "8" en indice à coté des R, G , et B, et c'est indiqué également 24-Bit Adobe RGB

Oui : la formule d'illustration est donnée pour un espace (3 x 8 =) 24 bits, d'où l'indice "8".
Mais as-tu lu la dernière phrase ?
Il est clairement indiqué que tu peux utiliser un nombre autre que N=8... à savoir, pour N=16, par exemple, la formule devient :

R'16 = Round (65535R')
G'16 = Round (65535G')
B'16 = Round (65535B')
(255 est remplacé par 2^16 - 1 = 65535)

[Apo2935]

oui mais c'est pour la profondeur de codage d'une image uniquement et pas celle de l'espace couleur à l'origine

Question : mais qui utilise encore Adobe98 ? (ah oui : encore beaucoup trop de monde ... alors je sors ...)

[Verso92]

Hum
Je veux bien que vous m'expliquiez.
Lors du dématricage,  ACR (par exemple) charge les données du RAW codées en 12, ou 14 bits par exemple et les traite dans son espace (Melissa) et en 16 bits ou plus ?

Lors de l'export vers PS par exemple on spécifie la profondeur du codage 8 ou 16 bits.

Que veut dire exactement pour vous dans ce contexte la différence entre la profondeur de codage de l'image et celle de l'espace couleur ?

Tout le monde semble d'accord sur le fait que les couleurs sont calculées sur (3 x) 8 bits dans l'espace sRVB.
La conversion des couleurs dans cet espace sera donc faite sur une base de 255 valeurs (2^8) possibles pour chaque canal. Mais rien n'empêche (enfin, je crois) d'exporter une image en 3 x 16 bits en sRVB dans les logiciels... même si la solution ne semble pas optimale, un P/T supplémentaire sur une image en 3 x 16 bits sera moins destructeur qu'en 3 x 8 bits, même en sRVB.

[Nikojorj]

Ne pas confondre la profondeur de codage d'une image et celle de l'espace couleur...

Oui, et c'est la seule réponse sensée au débat du nombre de couleurs qui a détourné ce fil tel le terroriste tchétchène moyen!
Pour le reprendre au début, mieux vaut réviser les fondamentaux : la couleur que nous percevons (ou au moins la plupart d'entre nous...) est décrite par trois composantes, par exemple rouge/vert/bleu ou teinte/saturation/luminosité.
Ceci est relié au fait que nous ayons trois types de cônes dans la rétine, avec des sensibilités spectrales (aux couleurs) plus ou moins différentes, qq chose comme rouge/orange, orange/jaune/vert, et bleu.

Comme notre cerveau a tendance à séparer la luminosité d'une part et la couleur proprement dite (teinte et saturation) d'autre part, on se retrouve avec deux dimensions pour les couleurs elles-mêmes ce qui fait qu'on peut représenter les couleurs dans un plan avec deux axes, ça peut être magenta/vert et jaune/bleu (exemple des espaces codés en Lab où les espaces de travail RGB sont des espèces de quadrilatères déformés) ou cyan/rouge et violet/vert (exemple du xyY utilisé pour la plupart des diagrammes, où les espaces de travail RGB sont triangulaires) mais c'est comme on veut.
Un espace de couleur, c'est donc une partie de ce plan.

L'espace des couleurs visibles par l'œil humain standard est un fer à cheval dans le diagramme de chromaticité xyY tel que http://fr.wikipedia.org/wiki/CIE_XYZ#Nuancier_CIE_.281931.29 et les espaces de travail en rouge/vert/bleu=RGB tel que sRGB, AdobeRGB ou ProPhotoRGB y décrivent des triangles qui englobent plus ou moins ce fer à cheval.
En gros, on a des espaces RGB dont les primaires sont des couleurs visibles, qui peuvent donc physiquement décrire un moniteur qui fonctionne selon le même principe d'addition des couleurs rouge verte et bleue, c'est le cas de sRGB et AdobeRGB.
Mais comme dans ce cas, un triangle ne permet pas de décrire toutes les couleurs visibles et notamment les couleurs "pures" (monochromatiques, issues d'une seule longueur d'onde) qui forment le bord du fer à cheval, on a aussi créé des espaces triangulaires plus grands que le fer à cheval pour pouvoir englober celles-ci ; contre-coup, les primaires ne décrivent pas des couleurs visibles (elles sont à l'extérieur du fer à cheval), ce ne sont que des objets mathématiques créés pour les besoins de la cause, et il est donc a priori impossible de faire un écran qui englobe tout l'espace ProPhoto par exemple.

Tout ça pour dire, un espace de couleur c'est avant tout une forme, et on la décrit avec la précision qu'on veut, sachant que pour les espaces "physiques" comme sRGB ou AdobeRGB un codage avec des entiers 8 bits suffit pour être aussi discriminant que l'œil humain, alors que pour de plus gros espaces comme ProPhoto ça peut parfois être un peu trop juste.
Mais rien n'empêche d'avoir une infinité de couleurs en codant ces espaces finis avec des réels et pas des entiers!


Bon, et si vous trouvez ça compliqué, prenez un bon bouquin comme celui de Jean Delmas (ici présent merci à lui!) et ça y sera bien mieux expliqué.

[Pat20d]

OK j'ai compris, enfin je crois ... (et j'ai lu le livre à Jean  )

Mais il y a quand même quelque chose de nébuleux encore pour moi. Le dématriçage est effectué en interne ACR dans un espace a priori aussi grand que Prophoto donc au moins en 3x16 bits voire plus.
Cela voudrait dire qu'au moment de la conversion en Adobe, on tronque toutes les données en 8 bits avant d'appliquer la matrice de conversion, puis on repasse en 16 bits si on a demandé Adobe / 16 bits dans les options du flux de production ....
J'ai un gros doute là ?

[Nikojorj]

Cela voudrait dire qu'au moment de la conversion en Adobe, on tronque toutes les données en 8 bits avant d'appliquer la matrice de conversion, puis on repasse en 16 bits si on a demandé Adobe / 16 bits dans les options du flux de production ....

Non, au risque de me répéter , il n'y a pas de lien entre tel ou tel espace de couleur et tel ou tel codage.

[Pat20d]

Tu es en train de dire qu'on peut coder sur le nombre de bit qu'on veut une image décrite dans un espace colorimétrique ou un autre. C'est bien ce que fait ACR que la sortie soit en sRGB, Adobe, Prophoto au n'importe quel espace qu'il connait.

Eh bien je suis complètement d'accord 

[tenmangu81]

Tu es en train de dire qu'on peut coder sur le nombre de bit qu'on veut une image décrite dans un espace colorimétrique ou un autre. C'est bien ce que fait ACR que la sortie soit en sRGB, Adobe, Prophoto au n'importe quel espace qu'il connait.

Eh bien je suis complètement d'accord 

Dans le livre de Jean Delmas, il est dit (ou tout au moins c'est ce que j'ai compris) que tous les espaces couleurs sont codés sur 8 bits. Même le CIELab.
Mais lorsque l'espace est très grand (genre Prophoto, dont certains sommets du triangle sont en dehors du "spectrum locus", frontière du visible), il est presque indispensable, à moins de prendre de gros risques, de choisir une profondeur de couleur de 16 bits. En effet, lorsque les côtés du triangle sont grands, si on choisit une profondeur de 8 bits, il y aura de sacrés trous entre chacune des valeurs. Ces trous sont beaucoup moins importants lorsque l'espace est restreint, tel sRGB.

[Pat20d]

Dans le livre de Jean Delmas, il est dit (ou tout au moins c'est ce que j'ai compris) que tous les espaces couleurs sont codés sur 8 bits. Même le CIELab.

Je ne sais pas ou tu as lu ça, je veux bien que tu m'indique la page car j'ai probablement raté quelque chose. J'ai par contre lu page 135 que "les composantes utilisées pour définir une couleur dans un espace RGB pouvaient être exprimées par des nombres binaires de 8 ou 16 bits"

Ce que j'ai compris c'est que l'espace couleur de travail définit dans quelle "référence" les valeurs affectées à chacun des pixels se placent. Une même valeur des 3 composantes ne représentent pas la même couleur si l'on est dans l'espace Adobe ou sRGB ou Prophoto. Ceci étant, la profondeur d'échantillonnage peut être de 8 ou 16 bits et pourquoi pas 32 bits.

Mais lorsque l'espace est très grand (genre Prophoto, dont certains sommets du triangle sont en dehors du "spectrum locus", frontière du visible), il est presque indispensable, à moins de prendre de gros risques, de choisir une profondeur de couleur de 16 bits. En effet, lorsque les côtés du triangle sont grands, si on choisit une profondeur de 8 bits, il y aura de sacrés trous entre chacune des valeurs. Ces trous sont beaucoup moins importants lorsque l'espace est restreint, tel sRGB.

Et qu'est ce qui te fait croire que je pourrais penser le contraire ? 

[tenmangu81]

Je ne sais pas ou tu as lu ça, je veux bien que tu m'indique la page car j'ai probablement raté quelque chose. J'ai par contre lu page 135 que "les composantes utilisées pour définir une couleur dans un espace RGB pouvaient être exprimées par des nombres binaires de 8 ou 16 bits"

Ce que j'ai compris c'est que l'espace couleur de travail définit dans quelle "référence" les valeurs affectées à chacun des pixels se placent. Une même valeur des 3 composantes ne représentent pas la même couleur si l'on est dans l'espace Adobe ou sRGB ou Prophoto. Ceci étant, la profondeur d'échantillonnage peut être de 8 ou 16 bits et pourquoi pas 32 bits.
Et qu'est ce qui te fait croire que je pourrais penser le contraire ? 

C'est le problème de la quantification. Si tu lis la page 83, tu verras que les concepteurs de l'espace CIELab ont choisi des unités allant de -128 à +127 pour les échelles a* et b*. Quand tu choisis une profondeur de 16 bits, tu vois tout de suite que les 256 valeurs entières reportées sur les axes a* et b* sont insuffisantes. D'où la nécessité, j'imagine, de travailler en virgule flottante ?
Jean Delmas, s'il est là, pourrait nous éclaircir sur ce point.
En tout cas, le rouge est bien R=255 sur ta pipette Photoshop, même quand tu travailles en 16 bits.....

[Pat20d]

C'est le problème de la quantification. Si tu lis la page 83, tu verras que les concepteurs de l'espace CIELab ont choisi des unités allant de -128 à +127 pour les échelles a* et b*. Quand tu choisis une profondeur de 16 bits, tu vois tout de suite que les 256 valeurs entières reportées sur les axes a* et b* sont insuffisantes. D'où la nécessité, j'imagine, de travailler en virgule flottante ?
Jean Delmas, s'il est là, pourrait nous éclaircir sur ce point.

OK Vu, la page 53 est également très intéressante

En tout cas, le rouge est bien R=255 sur ta pipette Photoshop, même quand tu travailles en 16 bits.....

Oui mais c'est par "simplification" je pense. Il me semble avoir lu quelque part qu'effectivement ce 255 n'avait pas de réelle signification.

[Verso92]

En tout cas, le rouge est bien R=255 sur ta pipette Photoshop, même quand tu travailles en 16 bits.....

Comme Pat : l'échelle 0~255 a été conservée par simplification, histoire de garder les repères...

Il me semble avoir lu quelque part qu'effectivement ce 255 n'avait pas de réelle signification.

Le "255" correspond à 2^8 - 1 : c'est la valeur max atteignable avec une quantification sur 8 bits.

[Apo2935]

 [at]  tous

Un peu de révision ne fait pas de mal ...

Source : D. Margulis

en 8 bpc : de 0 à 100 en L et de -128 à +127 pour a et b avec 257 niveaux de gris

en 16 bpc : de 0 à 32768 en L et de -16384 à +16256 avec 65536 niveaux de gris
... bonnes révisions ...

[Verso92]

Un peu de révision ne fait pas de mal ...

en 8 bpc : de 0 à 100 en L et de -128 à +127 pour a et b avec 257 niveaux de gris

... bonnes révisions ...

Lire "256" niveaux de gris, bien sûr...

[Pat20d]

[..]
Comment peut-on simplement imaginer que la profondeur de quantification puisse être liée à la forme de l'espace?
[/i]

Ah je suis rassuré !! Je commençais à douter de moi 

[Verso92]

Une coquille peut toujours se glisser...
Après, si tu veux m'expliquer comment on peut sortir 257 valeurs différentes avec 8 bits, je suis prêt à lire ton explication.

Bon, à défaut d'avoir le Dan Margulis dans ma bibliothèque (nobody's perfect...), je suis quand même allé jeter un œil sur Wiki, par curiosité (pas forcément exempt d'inexactitudes ou de coquilles, mais la question n'est pas là...) :
Généralités
Spectrophotomètre pour mesurer la couleur d'une surface dans le système L*a*b*.

   La composante L* est la clarté, qui va de 0 (noir) à 100 (blanc).
   La composante a* représente une gamme de 600 niveaux sur un axe rouge (+299 valeur positive) → vert (-300 valeur négative) en passant par le gris (0).
   La composante b* représente une gamme de 600 niveaux sur un axe jaune (+299 valeur positive) → bleu (-300 valeur négative) en passant par le gris (0).

Les composantes a* et b* sont le plus souvent notées par une valeur de +127 à -128 comportant ainsi 256 niveaux permettant d'être codé en 8 bits en base hexadécimal pour être corrélé avec le système RVB informatique (ou +10899 / -12451 en 16 bits).

http://fr.wikipedia.org/wiki/CIE_Lab

[Jean Delmas]

Une coquille peut toujours se glisser...
Après, si tu veux m'expliquer comment on peut sortir 257 valeurs différentes avec 8 bits, je suis prêt à lire ton explication.

Bonjour à Verso92, à Apo2935 et à tous et toutes.

Il y avait longtemps que je n'avais pas entendu parler de Dan Margulis. Je ne suis pas chez moi pour relire la page citée par Apo2935 mais je suppose qu'il s'agit du fameux bouquin consacré à Lab : « LAB Color: The Canyon Conundrum and Other Adventures in the Most Powerful Colorspace ».

A la question souvent posée par ses collègues à l'époque de la parution de ce livre et reprise ici par Apo2935 « Margulis raconte-t-il des conneries ? » je crois que l'on peut répondre oui, ça lui arrive. Ceci dit, je pense que l'erreur de « poteaux et d'intervalles » relevée  par verso92 est, comme il en avance lui-même l'hypothèse, une simple coquille.

Margulis est un expert Photoshop qui s'est jadis élevé avec un superbe courage contre quelques évidences pourtant attestées par la science colorimétrique. Il s'est par exemple opposé à la résolution tonale de 16 bits dont il jugeait qu'elle produisait des images moins belles que sa concurrente de 8 bits... Cette curieuse position le conduisait bien entendu à s'opposer à l'espace ProPhoto RGB (Ah bon, ça vous rappelle quelque chose ?).

A l'époque, les polémiques ont été nombreuses et pittoresques. On peut sans doute en retrouver des traces dans les archives Google. Si ma mémoire ne me trahit pas, le très regretté Bruce Fraser s'était attaché le premier à démonter l'alchimie farfelue de Margulis. Pour nous faire sourire le visage, et même plus, il nous reste aujourd'hui, fort  heureusement, la page que le rigoureux Bruce Lindbloom a toujours maintenue sur son excellent site et qui s'intitule « Dan Margulis' 16-bit Challenge: What's behind the controversy? »  http://www.brucelindbloom.com/index.html?DanMargulis.html

[Jean Delmas]

En tout cas, le rouge est bien R=255 sur ta pipette Photoshop, même quand tu travailles en 16 bits.....

Les interfaces de la plupart des logiciels de traitement d'image, par conservatisme hérité du temps ou la résolution tonale de 8 bits s'imposait partout, affichent les valeurs des composantes colorimétriques (RGB, XYZ, Lab...) sous forme de nombres entiers pouvant prendre 256 valeurs de 0 à 255.

Quand la profondeur de couleur de couleur est de 16 bits, cette méthode est évidemment fausse. Les interfaces devraient en toute rigueur afficher des nombres entiers variant de 0 à 65535. Ainsi, on ne peut pas afficher une composante comprises, par exemple, entre 0 et 1 (c'est-à-dire, sur 16 bits, entre 0 et 255) alors que cette profondeur de couleur le permet parfaitement. Mais connaitre précisément une valeur de composante comptée finement de 0 à 65535 est rarement utile. On sait bien que c'est à cause du supplément de « solidité » qu'elle donne aux images face aux mauvais traitement de post-production qu'on leur fait subir, et non à cause du nombre de nuances qu'elle permet de coder, que la résolution tonale de 16 bits est utile.

Pour Lab, qu'il faut TOUJOURS employer avec une résolution de 16 bits (voire en virgule flottante sur 32 bits comme le fait le moteur de calcul interne de Photoshop), la résolution de 8 bits paraissait jadis pourtant suffisante car l'échelle de 256 valeurs pour L* était réputée être un peu plus fine que ce que permet la perception visuelle. C'était une erreur. Le volume de couleurs « imaginaires » codées dans Lab à l'intérieur de ses limites standardisées (-128, +127) pour a* et b*, et (0, 255) pour L* est énorme. La capacité de codage de Lab est ainsi bien plus gravement gaspillée  dans des zones de couleurs sans signification que celle de ProPhoto RGB. L'inconvénient bien connu aujourd'hui de la profondeur de 8 bits avec ProPhoto RGB est ainsi encore plus grand avec Lab.

[...] lorsque l'espace est très grand (genre Prophoto, dont certains sommets du triangle sont en dehors du "spectrum locus", frontière du visible), il est presque indispensable, à moins de prendre de gros risques, de choisir une profondeur de couleur de 16 bits. En effet, lorsque les côtés du triangle sont grands, si on choisit une profondeur de 8 bits, il y aura de sacrés trous entre chacune des valeurs. Ces trous sont beaucoup moins importants lorsque l'espace est restreint, tel sRGB.

C'est exactement ça.

[tenmangu81]

Merci M. Delmas !!

[JP64]

2^8 = 256 plus le zéro cela fait 257 valeurs différentes,   mais en informatique le premier bit représente le signe  soit pour un octet 127 valeurs positives et 128 valeurs négatives.    127 + 128 plus le zéro cela fait 256 valeurs différentes

[Pascal Méheut]

2^8 = 256 plus le zéro cela fait 257 valeurs différentes,   mais en informatique le premier bit représente le signe  soit pour un octet 127 valeurs positives et 128 valeurs négatives.    127 + 128 plus le zéro cela fait 256 valeurs différentes

2^8 plus le zéro en informatique n'a jamais fait 257 valeur puisque sur 8 bits, on compte de 0 à 2^8  - 1 soit 255... Donc 256 valeurs.
Utiliser un bit pour représenter le signe n'est pas systématique. Par ex, on code les caractères sur 8 bits donc 256 possibles et on n'utilise pas la notion de signe. Idem pour les types "unsigned char", "byte" et autre suivant les langages.

[Verso92]

2^8 = 256 plus le zéro cela fait 257 valeurs différentes [...]

Arghhh... mais c'est pas possible !!!
2^8, cela fait exactement 256 valeurs différentes (de 0 à 255*) !
*ou de -128 à +127 en "signé", ce qui fait toujours 256 valeurs, bien sûr...

[Verso92]

*ou de -128 à +127 en "signé", ce qui fait toujours 256 valeurs, bien sûr...

Et le "0" fait partie intégrante des 256 valeurs : "00000000" très précisément en "signé" en code complément à 2...
(voir tableau ci-dessus)

[Pat20d]

[..]
127 + 128 plus le zéro cela fait 256 valeurs différentes

Tout juste sauf que 127 + 128 = 255
Plus le Zéro ==> 256 valeurs 

[JP64]

OK,  en fin l'unanimité sur un fil de CI.
Tout le monde peut se tromper, comme disait le hérisson en descendant de la brosse à chaussures !