Alors qu'il existe effectivement des modèles absolus (genre CIE LAB, etc.), où un n-uplet (en général un triplet) correspond à une couleur unique, ce n'est pas le cas du modèle de couleur RGB. Ce modèle est relatif à un certain contexte (l'espace de couleur), à savoir ses 3 couleurs primaires (oui "rouge", "vert" et "bleu", mais quels sont-ils? Les primaires de sRGB ou d'adobeRGB ne sont pas les mêmes rouges, verts et bleus par exemple!), de même que ses courbes de réponses/fonctions de transfert (comment on associe un chiffre, le long d'un des axes de couleurs, à une luminance, donc une couleur? On pensera de suite à la correction gamma bien que ce soit un cas simple; sRGB par exemple ne suit pas exactement une courbe gamma, même si souvent certains vont l'approximer avec une courbe de gamma 2.2). On va aussi définir le point blanc et le point noir.
Ce "contexte" est défini dans un profil de couleur (un petit fichier qui peut être à part, ou bien en métadonnées d'une image par exemple).
En gros, si on te donne une couleur (r1, g1, b1), ça ne veut rien dire sans l'espace de couleur associé. Alors bien sûr, si on te donne (255, 0, 0), c'est le rouge le plus vif de ton espace (si on est en espace entier sur 8-bit). Bon déjà, aparté: c'est même pas forcément vrai! Tu pourrais tout à fait avoir un profil qui redéfinit les composantes. J'en ai un sur mon disque par exemple qui fait une rotation des composantes, ce qui fait qu'avec ce profil, cette couleur serait en fait la couleur la plus verte, et non rouge! Mais bon, c'est un profil de test (ça permet de rapidement tester si mon code de conversion de couleur n'est pas complètement cassé: si mon rouge est vert, alors c'est bon, je suis dans la bonne direction! Ahahah! 🤣) et évidemment en général, on ne va pas utiliser ce type de profil. Prenons le cas normal donc: c'est bel et bien le rouge le plus rouge. Ben oui, sauf que le rouge le plus rouge dans l'espace sRGB n'est pas le rouge le plus rouge de l'espace adobeRGB (je l'ai dit plus haut). Ainsi sRGB(255, 0, 0) ≈ adobeRGB(219, 0, 0). Si tu passes juste le triplet d'un espace à l'autre sans convertir, tu verras immédiatement qu'il y a un problème!
Ajoute à cela que ton écran lui n'est ni en sRGB, ni en adobeRGB. Il est en ce que le hasard de sa réalité matériel lui permet, et c'est pour ça qu'on va calibrer son écran (avec une sonde colorimétrique ou un spectrophotomètre) pour créer son profil de couleur propre. C'est ce qui nous permet d'afficher une couleur comme elle devrait l'être. Ainsi si tu as un écran à gamut large et que tu veux un rouge sRGB(255, 0, 0), t'as pas intérêt à lui donner les chiffres (255, 0, 0). C'est le bon moyen pour avoir des couleurs pêtantes à l'écran. Et c'est d'ailleurs la raison pour laquelle tu vois plein de gens se plaindre sur divers forums sur le web que leur super écran Wide Gamut super cher affiche que des couleurs sur-saturées. C'est parce que la plupart des logiciels ne gèrent pas la couleur et passent des chiffres RGB vers l'écran sans jamais rien convertir.
Donc pour répondre à ta question:
Il doit me manquer une subtilité, parce que je ne vois pas la difficulté posée par la capture d'une couleur à l'écran. Si on récupère une couleur donnée, GIMP ne peut-il pas simplement calculer la couleur qui, si elle était posée dans l'image courante
Ben justement, si on n'a pas ce contexte, à savoir le profil de couleur de l'écran: non, on ne peut pas!
Comme je viens de le montrer, si l'OS me donne des couleurs RGB sans un profil de couleur, ça peut être "n'importe quelle couleur". Même sans avoir de profil extrême (comme le profil de test qui fait une rotation des canaux), va changer le profil (sans convertir les valeurs) entre un espace de couleur large et un espace étroit et tu verras une différence de couleur évidente. Au cas où je suis pas clair, je parle pas de différences subtiles, mais vraiment de couleurs évidemment différentes à l'œil nu.
demander au serveur X ou au compositeur Wayland d'envoyer la couleur précédemment récupérée ?
C'est là où le bât blesse. Donner le triplet de chiffres n'est pas assez. Avec X, on peut récupérer n'importe quel pixel de l'écran, puis on peut demander le profil de l'écran. Donc on a bien toutes les informations pour convertir dans un autre espace.
Avec Wayland, puisque le but est de cacher les informations des autres applications mais aussi système à l'application appelante, on peut seulement demander à un "portail" de faire une capture ou de "piquer" une couleur, puis le logiciel passe la main et attend. Enfin on a une réponse. Mais on ne sait pas du tout ce qui s'est passé entretemps.
Dans le cas de capture d'écran, on ne sait pas si on a une capture d'un seul écran, partiel ou total, ou de plusieurs, ni duquel. Dans le cas d'un prélèvement de couleur, on ne sait pas de quel pixel (c'est à dire quelle coordonnées) de quel écran on a pris la couleur.
D'ailleurs on ne sait même pas s'il y a un seul écran ou plusieurs branché sur cette machine (ou zéro)! Et on ne peut pas le savoir. On n'a tout simplement aucune information sur les écrans, ni leurs dimensions, et bien entendu il est donc impossible de demander leur profil de couleur au système. C'est le principe en fait.
La solution est donc soit que le portail donne le profil de couleur de l'écran (ce qui pose un problème pour les captures multi-écran re-composées en une image unique, notons), soit qu'il convertisse dans un espace connu (si possible bien sûr suffisamment grand pour englober l'ensemble des couleurs visibles) ou un modèle absolu. Mais si il te dit "tiens c'est du RGB" mais sans te dire lequel, ni te donner la possibilité d'avoir cette réponse par d'autres moyens. Alors il t'a juste donné des nombres sans trop de sens.
Notons que — aux dernières nouvelles — Wayland ne permet de toutes façon pas la gestion de couleur tout court (pas de calibration d'écran possible sous Wayland), alors bon... c'est la première étape déjà! La second étape sera d'avoir les APIs pour récupérer l'information adéquate.
Bon dans le cas "général", ça reste acceptable, parce que le grand public va de toutes façon pas calibrer leur écran ni travailler avec des images avec un profil autre que sRGB. Dans ce contexte, on va prendre un triplet en supposant que c'est du sRGB sur l'écran, l'utiliser comme tel sur une image qui va supposer de même et qui sera affichée sur le même écran, toujours en supposant que l'écran est sRGB. En gros, tout est absolument erroné, mais on s'en fiche car on propage la même erreur partout.
Mais si on veut travailler les couleurs dans un contexte professionnel, on va calibrer son écran, possiblement utiliser des profils de couleur autre que sRGB sur ses images, etc. On veut pas juste copier des chiffres d'un espace de couleur à l'autre en espérant que tout ira pour le mieux.
Pour info, voilà la demande de fonctionnalité où je demande que le portail Freedesktop de prélèvement de couleur gère les couleurs. La conclusion de la discussion à ce stade est que:
L'interface actuelle devrait rester telle quel au niveau interface, sauf qu'elle devrait être documenté comme retournant uniquement du sRGB; puis les diverses implémentations de ce portail (KDE, GNOME, etc.) devraient donc être changée pour convertir en et retourner uniquement du sRGB. Ainsi toute application qui ne souhaite pas gérer les couleurs continuera d'utiliser ce portail (ils perdent les couleurs hors-gamut, mais c'est acceptable dans un usage basique et au moins les couleurs à l'intérieur de cet espace deviendraient juste).
Il faudrait faire une nouvelle interface qui convertirait et retournerait les couleurs dans un espace connu et plus grand. Le contributeur qui a répondu proposait PQ/Rec2020 (l'espace de couleur UHDTV).
En tous cas, c'est pour l'instant là où on en est au niveau discussion, mais rien n'est implémenté (des infos que j'ai) et pour l'instant l'interface actuelle retourne simplement une couleur dont on ne connaît pas l'espace de couleur associé. Ce n'est pas acceptable dans un usage sérieux de travail de la couleur.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Gestion des couleurs et capture
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.34 est sorti. Évalué à 10.
Alors qu'il existe effectivement des modèles absolus (genre CIE LAB, etc.), où un n-uplet (en général un triplet) correspond à une couleur unique, ce n'est pas le cas du modèle de couleur RGB. Ce modèle est relatif à un certain contexte (l'espace de couleur), à savoir ses 3 couleurs primaires (oui "rouge", "vert" et "bleu", mais quels sont-ils? Les primaires de sRGB ou d'adobeRGB ne sont pas les mêmes rouges, verts et bleus par exemple!), de même que ses courbes de réponses/fonctions de transfert (comment on associe un chiffre, le long d'un des axes de couleurs, à une luminance, donc une couleur? On pensera de suite à la correction gamma bien que ce soit un cas simple; sRGB par exemple ne suit pas exactement une courbe gamma, même si souvent certains vont l'approximer avec une courbe de gamma 2.2). On va aussi définir le point blanc et le point noir.
Ce "contexte" est défini dans un profil de couleur (un petit fichier qui peut être à part, ou bien en métadonnées d'une image par exemple).
En gros, si on te donne une couleur
(r1, g1, b1), ça ne veut rien dire sans l'espace de couleur associé. Alors bien sûr, si on te donne(255, 0, 0), c'est le rouge le plus vif de ton espace (si on est en espace entier sur 8-bit). Bon déjà, aparté: c'est même pas forcément vrai! Tu pourrais tout à fait avoir un profil qui redéfinit les composantes. J'en ai un sur mon disque par exemple qui fait une rotation des composantes, ce qui fait qu'avec ce profil, cette couleur serait en fait la couleur la plus verte, et non rouge! Mais bon, c'est un profil de test (ça permet de rapidement tester si mon code de conversion de couleur n'est pas complètement cassé: si mon rouge est vert, alors c'est bon, je suis dans la bonne direction! Ahahah! 🤣) et évidemment en général, on ne va pas utiliser ce type de profil. Prenons le cas normal donc: c'est bel et bien le rouge le plus rouge. Ben oui, sauf que le rouge le plus rouge dans l'espace sRGB n'est pas le rouge le plus rouge de l'espace adobeRGB (je l'ai dit plus haut). AinsisRGB(255, 0, 0) ≈ adobeRGB(219, 0, 0). Si tu passes juste le triplet d'un espace à l'autre sans convertir, tu verras immédiatement qu'il y a un problème!Ajoute à cela que ton écran lui n'est ni en sRGB, ni en adobeRGB. Il est en ce que le hasard de sa réalité matériel lui permet, et c'est pour ça qu'on va calibrer son écran (avec une sonde colorimétrique ou un spectrophotomètre) pour créer son profil de couleur propre. C'est ce qui nous permet d'afficher une couleur comme elle devrait l'être. Ainsi si tu as un écran à gamut large et que tu veux un rouge
sRGB(255, 0, 0), t'as pas intérêt à lui donner les chiffres(255, 0, 0). C'est le bon moyen pour avoir des couleurs pêtantes à l'écran. Et c'est d'ailleurs la raison pour laquelle tu vois plein de gens se plaindre sur divers forums sur le web que leur super écran Wide Gamut super cher affiche que des couleurs sur-saturées. C'est parce que la plupart des logiciels ne gèrent pas la couleur et passent des chiffres RGB vers l'écran sans jamais rien convertir.Donc pour répondre à ta question:
Ben justement, si on n'a pas ce contexte, à savoir le profil de couleur de l'écran: non, on ne peut pas!
Comme je viens de le montrer, si l'OS me donne des couleurs RGB sans un profil de couleur, ça peut être "n'importe quelle couleur". Même sans avoir de profil extrême (comme le profil de test qui fait une rotation des canaux), va changer le profil (sans convertir les valeurs) entre un espace de couleur large et un espace étroit et tu verras une différence de couleur évidente. Au cas où je suis pas clair, je parle pas de différences subtiles, mais vraiment de couleurs évidemment différentes à l'œil nu.
C'est là où le bât blesse. Donner le triplet de chiffres n'est pas assez. Avec X, on peut récupérer n'importe quel pixel de l'écran, puis on peut demander le profil de l'écran. Donc on a bien toutes les informations pour convertir dans un autre espace.
Avec Wayland, puisque le but est de cacher les informations des autres applications mais aussi système à l'application appelante, on peut seulement demander à un "portail" de faire une capture ou de "piquer" une couleur, puis le logiciel passe la main et attend. Enfin on a une réponse. Mais on ne sait pas du tout ce qui s'est passé entretemps.
Dans le cas de capture d'écran, on ne sait pas si on a une capture d'un seul écran, partiel ou total, ou de plusieurs, ni duquel. Dans le cas d'un prélèvement de couleur, on ne sait pas de quel pixel (c'est à dire quelle coordonnées) de quel écran on a pris la couleur.
D'ailleurs on ne sait même pas s'il y a un seul écran ou plusieurs branché sur cette machine (ou zéro)! Et on ne peut pas le savoir. On n'a tout simplement aucune information sur les écrans, ni leurs dimensions, et bien entendu il est donc impossible de demander leur profil de couleur au système. C'est le principe en fait.
La solution est donc soit que le portail donne le profil de couleur de l'écran (ce qui pose un problème pour les captures multi-écran re-composées en une image unique, notons), soit qu'il convertisse dans un espace connu (si possible bien sûr suffisamment grand pour englober l'ensemble des couleurs visibles) ou un modèle absolu. Mais si il te dit "tiens c'est du RGB" mais sans te dire lequel, ni te donner la possibilité d'avoir cette réponse par d'autres moyens. Alors il t'a juste donné des nombres sans trop de sens.
Notons que — aux dernières nouvelles — Wayland ne permet de toutes façon pas la gestion de couleur tout court (pas de calibration d'écran possible sous Wayland), alors bon... c'est la première étape déjà! La second étape sera d'avoir les APIs pour récupérer l'information adéquate.
Bon dans le cas "général", ça reste acceptable, parce que le grand public va de toutes façon pas calibrer leur écran ni travailler avec des images avec un profil autre que sRGB. Dans ce contexte, on va prendre un triplet en supposant que c'est du sRGB sur l'écran, l'utiliser comme tel sur une image qui va supposer de même et qui sera affichée sur le même écran, toujours en supposant que l'écran est sRGB. En gros, tout est absolument erroné, mais on s'en fiche car on propage la même erreur partout.
Mais si on veut travailler les couleurs dans un contexte professionnel, on va calibrer son écran, possiblement utiliser des profils de couleur autre que sRGB sur ses images, etc. On veut pas juste copier des chiffres d'un espace de couleur à l'autre en espérant que tout ira pour le mieux.
Pour info, voilà la demande de fonctionnalité où je demande que le portail Freedesktop de prélèvement de couleur gère les couleurs. La conclusion de la discussion à ce stade est que:
En tous cas, c'est pour l'instant là où on en est au niveau discussion, mais rien n'est implémenté (des infos que j'ai) et pour l'instant l'interface actuelle retourne simplement une couleur dont on ne connaît pas l'espace de couleur associé. Ce n'est pas acceptable dans un usage sérieux de travail de la couleur.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]