HTML, couleurs, et mythes

Le 21/02/12 04:54, PiLS a écrit :

Pour en finir avec le mythe selon lequel les couleurs HTML sont mal
définies, et sont intrinsèquement incompatibles avec l'affichage de
photos selon un profil défini:
proposition de 1996 http://www.w3.org/Graphics/Color/sRGB
inclusion dès le standard HTML 3.2 (potentiellement plus tôt, il me
manque juste les références):
http://www.w3.org/TR/REC-html32.html
(on notera: "colors are given in the sRGB color space as hexadecimal
numbers (e.g. COLOR="#C0FFC0"), or as one of 16 widely understood
color names", suivi de la liste desdites 16 couleurs et leur traduction
en hexa dans l'espace sRGB.

Certains écrits ici suggèrent que le "color-management" du navigateur
passe outre le profil du moniteur local (avec des arguments basés sur
le gamut du moniteur). C'est précisément le contraire. Un navigateur
qui respecte les profils va précisément traduire le profil de l'image
dans le profil du moniteur. C'est le but. Sur un système cohérent, et
qui respecte le profil sRGB implicite en HTML, le résultat est une
couleur unique pour un même "code HTML" dans le texte et un "code HTML"
sur un JPEG proprement défini.
Point barre.

Le problème, c'est que le sRGB n'a jamais été reconnu par quelques
companies, dont Adobe et Apple, qui le considéraient (non sans raison)
comme un putsch de HP et MS sur le web.

C'est un peu excessif comme façon de dire, car depuis que je connais PS,
cad depuis la version 6 qui incorporait la gestion de couleurs, on peut
très bien utiliser sRGB comme espace de couleurs et comme profil pour
les images. AdobeRGB est simplement plus étendu (et photoRGB aussi).
Quand au système macOS , il assure depuis longtemps que la gestion des
couleurs soit homogène pour les différentes applications...Sans
oblitérer totalement la possibilité qu'une application donnée y aille de
sa propre solution, ce qui tend effectivement à foutre le souk avec des
applications tierces.

Apple n'approuvant que les Putsch maison, et ayant à cette époque la
mainmise sur les "créas", le standard a fait marche arrière, pour le
pire et pour le pire (non, pas de typo). Pas de standard donc, et on
reste dans l'incertitude jusqu'au standard CSS3 (peut-être...)
pour espérer "progresser" jusqu'à il y a 16 ans. Vive le progrès!

Bises à tous

Je trouve particulierement interessant ceci : (qui représente et
explique bien mon souci récent).

Image in sRGB, and system has a monitor/output device ICC profile

In this scenario, the image has been run through a transform that
consists of the input device ICC profile, and the sRGB ICC profile, or
it was created using devices that conform to sRGB. Because the system
has an ICC profile for the output device, the image can be converted to
the output device's color space and imaged. The resulting image will be
consistent across devices, and will be very close to the original in
appearance.

Tout ceci se passe au niveau de l'interprétation par le browser, qui
n'est pas spécifique à un système.
L'apparence est "proche" d'un moniteur à l'autre, d'un système à
l'autre, ce qui implique, comme les moniteurs sont différents, que la
valeur html soit altérée. En général, pour une photo on cherche plutôt
le rendu visuel que des valeurs fixes en html...Sauf a regarder les
photos avec la pipette et un clavier braille. Mais parfois on cherche à
restituer une valeur spécifique, sans vouloir se limiter au "web-safe".

Enfin, je te remercie pour cette page car débutante dans le web, d'une
certaine manière (le design), je n'ai jamais vu passer des indications
de couleur dans les css telles que décrites dans l'article. Dans le cas
de couleurs de logo, peut-être qu'il serait sain de donner la propriété
"absolute" en png. En jpg, je ne vois pas trop l'équivalent, pourtant
c'est interessant à comprendre si on veut par exemple fondre une image
dans un arrière plan.

Page bookmarquée à méditer.

Noëlle Adam

Le 21/02/2012 10:57, YouDontNeedToKnowButItsNoëlle a écrit :

l'autre, ce qui implique, comme les moniteurs sont différents, que la
valeur html soit altérée.

mais non. C'est l'aspect de l'affichage qui est altéré, pas le contenu
du fichier! tu verras une différence si tu photographie l'écran, pas
si tu utilise la pipette

jdd

PiLS a écrit :

Certains écrits ici suggèrent que le "color-management" du navigateur
passe outre le profil du moniteur local (avec des arguments basés sur
le gamut du moniteur). C'est précisément le contraire. Un navigateur
qui respecte les profils va précisément traduire le profil de l'image
dans le profil du moniteur. C'est le but. Sur un système cohérent, et
qui respecte le profil sRGB implicite en HTML, le résultat est une
couleur unique pour un même "code HTML" dans le texte et un "code HTML"
sur un JPEG proprement défini.
Point barre.

Laisse «certains» reprendre la plume et revenir à la réalité des choses.

D'abord, il n'existe pas à l'heure actuelle de «système cohérent
qui respecte le profil sRGB implicite en HTML». Il existe tout au plus
des navigateurs qui tiennent compte des profils intégrés aux images, et
seulement aux images.

Les autres composantes RVB de couleur (textes, fonds de blocs, bordures,
etc.) et les RVB des images sans profil sont envoyées telles quelles au
moniteur. Par définition même, elles sont affichées avec le profil
**réel** du moniteur. Il ne faut pas confondre ce profil avec ce qu'on a
pu construire lors d'une opération d'étalonnage ou avec le profil
d'usine intégré au moniteur, lesquels ne constituent que des
approximations de ce profil réel.

Ce profil réel est voisin du sRGB pour la plupart des moniteurs à petit
gamut (pas trop petit, tout de même, si on pense aux écrans de
portable). Dans ce cas, l'affichage n'est pas trop loin des couleurs
idéales qu'on aurait eues avec le sRGB. Pas trop loin, mais les écarts
sont décelables et parfois gênants, n'est-ce pas ?

Quand il y a un profil dans l'image, on ne «traduit [pas vraiment] le
profil de l'image dans le profil du moniteur». Ça se passe en deux temps :
(1) on traduit les RVB de l'image en couleurs exactes Lab avec le profil
de l'image (il faut savoir qu'un profil ICC est un dictionnaire qui
permet de passer de composantes RVB aux couleurs exactes Lab ou vice-versa)
(2) côté moniteur, avec le profil d'icelui, on traduit les Lab en de
nouveaux RVB à envoyer au moniteur pour que celui-ci affiche les bonnes
couleurs.

Bien évidemment, la 2ème étape ne marche que si le «profil du moniteur»
encodé quelque part dans la machine est une bonne approximation du
profil réel : il faut avoir étalonné sérieusement son moniteur.

charles

Charles Vassallo <cv@waou.fr> nous a dit:

PiLS a écrit :

Certains écrits ici suggèrent que le "color-management" du navigateur
passe outre le profil du moniteur local (avec des arguments basés sur
le gamut du moniteur). C'est précisément le contraire. Un navigateur
qui respecte les profils va précisément traduire le profil de l'image
dans le profil du moniteur. C'est le but. Sur un système cohérent, et
qui respecte le profil sRGB implicite en HTML, le résultat est une
couleur unique pour un même "code HTML" dans le texte et un "code HTML"
sur un JPEG proprement défini.
Point barre.

Laisse «certains» reprendre la plume et revenir à la réalité des choses.

D'abord, il n'existe pas à l'heure actuelle de «système cohérent
qui respecte le profil sRGB implicite en HTML». Il existe tout au plus
des navigateurs qui tiennent compte des profils intégrés aux images, et
seulement aux images.

C'est vrai en ce qui concerne les navigateurs et c'est bien le problème
que je souligne.

Les autres composantes RVB de couleur (textes, fonds de blocs, bordures,
etc.) et les RVB des images sans profil sont envoyées telles quelles au
moniteur. Par définition même, elles sont affichées avec le profil
**réel** du moniteur. Il ne faut pas confondre ce profil avec ce qu'on a
pu construire lors d'une opération d'étalonnage ou avec le profil
d'usine intégré au moniteur, lesquels ne constituent que des
approximations de ce profil réel.

Ben voyons. Il n'y a RIEN qui est envoyé tel quel au moniteur. Sauf
dans le cas dúne console série, qui est tombée en désuétude quelquepart
entre le Jurassique et ma date de naissance.

Ce profil réel est voisin du sRGB pour la plupart des moniteurs à petit
gamut (pas trop petit, tout de même, si on pense aux écrans de
portable). Dans ce cas, l'affichage n'est pas trop loin des couleurs
idéales qu'on aurait eues avec le sRGB. Pas trop loin, mais les écarts
sont décelables et parfois gênants, n'est-ce pas ?

Vrai mais rien à voir avec la discussion actuelle.

Quand il y a un profil dans l'image, on ne «traduit [pas vraiment] le
profil de l'image dans le profil du moniteur».

Bien sur que si.

Ça se passe en deux temps :
(1) on traduit les RVB de l'image en couleurs exactes Lab avec le profil
de l'image (il faut savoir qu'un profil ICC est un dictionnaire qui
permet de passer de composantes RVB aux couleurs exactes Lab ou vice-versa)
(2) côté moniteur, avec le profil d'icelui, on traduit les Lab en de
nouveaux RVB à envoyer au moniteur pour que celui-ci affiche les bonnes
couleurs.

C'est une définition du profil "pour les nuls" mais c'est plus ou
moins l'idée.
On traduit donc le profil de l'image dans le profil du moniteur; tu
parles de "côté moniteur" bien que ce soit en fait l'OS (le moniteur
n'y est pour rien, le pauvre), et si le fichier .icc de référence est
plus ou mois assimilable à un dictionnaire classique, le profil
inclus, lui, ne l'est pas. Pour utiliser la même comparaison que
toi, c'est une collection de références à un dico commun.

--
PiLS

YouDontNeedToKnowButItsNoëlle <FautLaDemander@simple.org> nous a dit:

Le 21/02/12 04:54, PiLS a écrit :

Pour en finir avec le mythe selon lequel les couleurs HTML sont mal
définies, et sont intrinsèquement incompatibles avec l'affichage de
photos selon un profil défini:
proposition de 1996 http://www.w3.org/Graphics/Color/sRGB
inclusion dès le standard HTML 3.2 (potentiellement plus tôt, il me
manque juste les références):
http://www.w3.org/TR/REC-html32.html
(on notera: "colors are given in the sRGB color space as hexadecimal
numbers (e.g. COLOR="#C0FFC0"), or as one of 16 widely understood
color names", suivi de la liste desdites 16 couleurs et leur traduction
en hexa dans l'espace sRGB.

Certains écrits ici suggèrent que le "color-management" du navigateur
passe outre le profil du moniteur local (avec des arguments basés sur
le gamut du moniteur). C'est précisément le contraire. Un navigateur
qui respecte les profils va précisément traduire le profil de l'image
dans le profil du moniteur. C'est le but. Sur un système cohérent, et
qui respecte le profil sRGB implicite en HTML, le résultat est une
couleur unique pour un même "code HTML" dans le texte et un "code HTML"
sur un JPEG proprement défini.
Point barre.

Le problème, c'est que le sRGB n'a jamais été reconnu par quelques
companies, dont Adobe et Apple, qui le considéraient (non sans raison)
comme un putsch de HP et MS sur le web.

C'est un peu excessif comme façon de dire, car depuis que je connais PS,
cad depuis la version 6 qui incorporait la gestion de couleurs, on peut
très bien utiliser sRGB comme espace de couleurs et comme profil pour
les images. AdobeRGB est simplement plus étendu (et photoRGB aussi).

Et AppleRGB aussi; il y a des tas d'espaces de couleur plus complets
et/ou fidèles que sRGB. sRGB est plus ou moins ouvertement basé sur
le VGA MSWindows d'antan, et était, lors de sa proposition jointe par
HP et MS, probablement une tentative de "putsch" sur le web.

Quand au système macOS , il assure depuis longtemps que la gestion des
couleurs soit homogène pour les différentes applications...

Très bien

Sans
oblitérer totalement la possibilité qu'une application donnée y aille de
sa propre solution, ce qui tend effectivement à foutre le souk avec des
applications tierces.

Et c'est là que le bât blesse; on est bien d'accord.

Apple n'approuvant que les Putsch maison, et ayant à cette époque la
mainmise sur les "créas", le standard a fait marche arrière, pour le
pire et pour le pire (non, pas de typo). Pas de standard donc, et on
reste dans l'incertitude jusqu'au standard CSS3 (peut-être...)
pour espérer "progresser" jusqu'à il y a 16 ans. Vive le progrès!

Bises à tous

Je trouve particulierement interessant ceci : (qui représente et
explique bien mon souci récent).

Image in sRGB, and system has a monitor/output device ICC profile

In this scenario, the image has been run through a transform that
consists of the input device ICC profile, and the sRGB ICC profile, or
it was created using devices that conform to sRGB. Because the system
has an ICC profile for the output device, the image can be converted to
the output device's color space and imaged. The resulting image will be
consistent across devices, and will be very close to the original in
appearance.

Tout ceci se passe au niveau de l'interprétation par le browser, qui
n'est pas spécifique à un système.

Oui. Mais si. Un navigateur qui parle directement au moniteur, je
demande à voir.

L'apparence est "proche" d'un moniteur à l'autre, d'un système à
l'autre, ce qui implique, comme les moniteurs sont différents, que la
valeur html soit altérée. En général, pour une photo on cherche plutôt
le rendu visuel que des valeurs fixes en html...Sauf a regarder les
photos avec la pipette et un clavier braille. Mais parfois on cherche à
restituer une valeur spécifique, sans vouloir se limiter au "web-safe".

Ce n'est pas un problème quand on travaille en sRGB, mais pour des
nuances subtiles en cyan qui ne sortent qu'en AdobeRGB (simple exemple)
je suis d'accord, on est coincés.

Bises
--
PiLS

PiLS a écrit :

Ben voyons. Il n'y a RIEN qui est envoyé tel quel au moniteur. Sauf
dans le cas dúne console série, qui est tombée en désuétude quelquepart
entre le Jurassique et ma date de naissance.

J'aurais cru que tu comprenais à demi-mot. Erreur de ma part.

> Ce profil réel est voisin du sRGB pour la plupart des moniteurs à petit
> gamut (pas trop petit, tout de même, si on pense aux écrans de
> portable). Dans ce cas, l'affichage n'est pas trop loin des couleurs
> idéales qu'on aurait eues avec le sRGB. Pas trop loin, mais les écarts
> sont décelables et parfois gênants, n'est-ce pas ?

Vrai mais rien à voir avec la discussion actuelle.

Bin si, justement. C'est précisément ça qui fait que Noëlle a du mal a
marier les RVB de son image (en sRGB) aux RVB de son code HTML sur sa
chaîne graphique dument étalonnée

charles