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.