Les transformations entre la plupart des modèles de couleur sont bien bijectives. De même que les transformations entre espaces de couleur (si on travaille en flottant). Il s'agit de bête calcul de matrice ×ばつ3 dans un sens, et son inverse dans l'autre.
Vous remarquerez d'ailleurs que tous ces modèles ont 3 axes, ce n'est pas un hasard. Les recherches ont simplement montré que l'on peut reproduire l'ensemble des couleurs avec 3 primaires. Le "jeu" est donc simplement de choisir des primaires/axes appropriées et c'est la raison principale pour laquelle il existe divers modèles et divers espaces.
Il y eut ainsi le moment où on a essayé de faire des modèles plus proches de "comment l'humain perçoit les couleurs", ce qui a donné les HSV et HSL. Mais on s'est rendu compte que ces modèles n'étaient pas si bons mathématiquement (même s'ils restent utilisés et sont intéressants, notamment quelques outils colorimétriques dans GIMP se basent sur ces modèles, en terme d'UX).
Les gens ont alors cherché à voir les couleurs en 2D, ce qui a donné le modèle xyY, qui permet le fameux diagramme en fer à cheval où on représente les espaces de couleurs, en ignorant l'axe Y. En effet dans ce modèle, on représente entièrement les teintes (c'est à dire la perception des couleurs telles qu'on les nomme) sur un plan avec les axes xy, et l'axe Y ne représente que la luminance sans impacter la perception de teinte. On peut ainsi s'imaginer les "variations" d'une même couleur où on ne change que la luminance sur l'axe perpendiculaire au papier/à l'écran. Ce modèle a d'ailleurs quelques propriétés intéressantes, comme le fait que tout mélange de 2 couleurs se trouve sur le segment entre les 2 points. C'est pourquoi on arrive à représenter tout espace de couleur comme un triangle sur le plan 2D xy.
Mais ce type de modèle a aussi des problèmes, par exemple la non-uniformité perceptuelle (certaines couleurs très proches sur ce modèle ont l'air très différentes alors que sur d'autres zones, des couleurs éloignées ont l'air identiques). Les gens ont alors essayé de faire des modèles perceptuellement uniformes (ou presque), ce qui a donné les CIELAB et surtout CIELUV.
Et ainsi de suite. Mais le fait est qu'hormis la création de modèle pour satisfaire des buts/usages particuliers, les couleurs sont entièrement et très aisément transformables d'un modèle à l'autre.
La raison pour laquelle il pourra y avoir une très légère différence du résultat dans un A/R entre 2 modèles serait l'imprécision mathématique d'un processeur. Mais bon, si on ne fait qu'un A/R, la perte est probablement trop minime pour s'en préoccuper (ce serait moins le cas si on code ça sur 8-bit, ce pourquoi notamment il est conseillé de travailler en flottant de nos jours pour le travail graphique). Hormis ce point de limitation technique, si, mathématiquement les transformations sont théoriquement bijectives, sans perte, hormis si on décidait d'écrêter en dehors de [0; 1], c'est à dire hors du gamut d'un espace de couleur. Sauf que justement l'un des autres grands avantages du travail en flottant est qu'on évite d'écrêter lors d'étapes intermédiaires permettant réellement de travailler presque sans perte, et en plus très simplement (calcul de multiplication de matrice basique, niveau lycée).
Ensuite quand je disais dans mon paragraphe d'intro que c'est vrai pour "la plupart des modèles de couleur", c'est parce que certains modèles sont basés sur des logiques physiques différentes. Je parle de CMYK. Un passage RGB🔄CMYK n'est effectivement pas bijectif (il n'est pas impossible de tomber sur des valeurs assez différentes lors d'un A/R entre les 2 modèles).
Et sans compter les "couleurs" de type "couleurs métalliques" ou "couleurs fluorescentes", etc. Bien sûr, selon une théorie de couleur pure, on ne considérerait peut-être pas cela comme une couleur, mais un humain considérera bien un bleu et un bleu métal comme 2 couleurs différentes (même si ça pourrait être considéré exactement le même bleu selon d'autres critères). Et là même en CMYK, on ne les représente pas. En général, c'est là où on utilise les "spot colors" qui sont encore un autre modèle, en général sur une base de catalogues.
Mais hormis ce type de transformation et autres exceptions particulières, les transformations entre la plupart des autres modèles sont bien bijectives et se font par de très simples opérations mathématiques. 😄
Ces derniers mois, j'ai donné des conférences sur le traitement d'image et de manière générale sur les sciences des couleurs dans une école d'ingénieur des Mines (Saint Étienne) et dans un IUT (Valence). Bien sûr, dans le temps d'une conférence (2H, bien qu'aux Mines, on a aussi eu des ateliers, donc ce fut même un séminaire d'une journée complète avec conf + atelier sur le traitement d'image avec GEGL), ce n'est qu'un survol très rapide des nombreux concepts. Quiconque croit pouvoir comprendre la problématique de la couleur en informatique en quelques heures se méprend totalement. Cela fait des années que je travaille en plein dedans et je découvre encore des choses, il m'arrive encore de finalement comprendre des trucs (alors que je n'avais même pas réalisé que je n'avais pas compris avant!), etc. D'ailleurs puisque j'ai écrit ce commentaire presque de tête, il n'est pas impossible que quelques erreurs s'y soient glissées. Cela ne fait que démontrer d'autant plus la complexité du sujet (un "classique" quand je lis un texte sur la théorie de la couleur est de comprendre sur le coup et de me dire "ah bah oui", puis d'avoir complètement perdu la logique une semaine après, si je ne l'ai pas relu ou appliqué dans du code entretemps).
Quand on regarde l'historique des logiciels de graphisme, on se rend d'ailleurs compte que l'ensemble de l'industrie a fait erreurs sur erreurs pendant des décennies sur le sujet de la couleur et essaie de les réparer progressivement (parfois en faisant de nouvelles erreurs ironiquement!).
Je parle bien de gros noms de l'industrie qui ont multiplié des bourdes sur les dernières décennies (et encore très récemment; ce ne sont pas forcément toutes de vieilles histoires).
Et en recherche c'est pareil, les chercheurs ont l'air de se tirer la bourre. Quand on discute avec certains ou qu'on lit certains textes de référence, il n'est pas rare que ça commence en gros par "tout le monde a tort, sauf moi!" Et nous, on navigue dedans.
Donc oui, c'est pas facile. Quiconque est intéressé par une conf sur ce sujet dans une université/école/entreprise peut me contacter d'ailleurs. Maintenant que j'ai commencé à en faire quelques unes, je me dis que c'est un sujet intéressant à expliquer et discuter. Donc je suis partant.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Fonctions non bijectives
Posté par Jehan (site web personnel, Mastodon) . En réponse au message De la gestion de couleurs. Évalué à 7.
Les transformations entre la plupart des modèles de couleur sont bien bijectives. De même que les transformations entre espaces de couleur (si on travaille en flottant). Il s'agit de bête calcul de matrice ×ばつ3 dans un sens, et son inverse dans l'autre.
Vous remarquerez d'ailleurs que tous ces modèles ont 3 axes, ce n'est pas un hasard. Les recherches ont simplement montré que l'on peut reproduire l'ensemble des couleurs avec 3 primaires. Le "jeu" est donc simplement de choisir des primaires/axes appropriées et c'est la raison principale pour laquelle il existe divers modèles et divers espaces.
Il y eut ainsi le moment où on a essayé de faire des modèles plus proches de "comment l'humain perçoit les couleurs", ce qui a donné les HSV et HSL. Mais on s'est rendu compte que ces modèles n'étaient pas si bons mathématiquement (même s'ils restent utilisés et sont intéressants, notamment quelques outils colorimétriques dans GIMP se basent sur ces modèles, en terme d'UX).
Les gens ont alors cherché à voir les couleurs en 2D, ce qui a donné le modèle xyY, qui permet le fameux diagramme en fer à cheval où on représente les espaces de couleurs, en ignorant l'axe Y. En effet dans ce modèle, on représente entièrement les teintes (c'est à dire la perception des couleurs telles qu'on les nomme) sur un plan avec les axes xy, et l'axe Y ne représente que la luminance sans impacter la perception de teinte. On peut ainsi s'imaginer les "variations" d'une même couleur où on ne change que la luminance sur l'axe perpendiculaire au papier/à l'écran. Ce modèle a d'ailleurs quelques propriétés intéressantes, comme le fait que tout mélange de 2 couleurs se trouve sur le segment entre les 2 points. C'est pourquoi on arrive à représenter tout espace de couleur comme un triangle sur le plan 2D xy.
Mais ce type de modèle a aussi des problèmes, par exemple la non-uniformité perceptuelle (certaines couleurs très proches sur ce modèle ont l'air très différentes alors que sur d'autres zones, des couleurs éloignées ont l'air identiques). Les gens ont alors essayé de faire des modèles perceptuellement uniformes (ou presque), ce qui a donné les CIELAB et surtout CIELUV.
Et ainsi de suite. Mais le fait est qu'hormis la création de modèle pour satisfaire des buts/usages particuliers, les couleurs sont entièrement et très aisément transformables d'un modèle à l'autre.
La raison pour laquelle il pourra y avoir une très légère différence du résultat dans un A/R entre 2 modèles serait l'imprécision mathématique d'un processeur. Mais bon, si on ne fait qu'un A/R, la perte est probablement trop minime pour s'en préoccuper (ce serait moins le cas si on code ça sur 8-bit, ce pourquoi notamment il est conseillé de travailler en flottant de nos jours pour le travail graphique). Hormis ce point de limitation technique, si, mathématiquement les transformations sont théoriquement bijectives, sans perte, hormis si on décidait d'écrêter en dehors de
[0; 1], c'est à dire hors du gamut d'un espace de couleur. Sauf que justement l'un des autres grands avantages du travail en flottant est qu'on évite d'écrêter lors d'étapes intermédiaires permettant réellement de travailler presque sans perte, et en plus très simplement (calcul de multiplication de matrice basique, niveau lycée).Ensuite quand je disais dans mon paragraphe d'intro que c'est vrai pour "la plupart des modèles de couleur", c'est parce que certains modèles sont basés sur des logiques physiques différentes. Je parle de CMYK. Un passage RGB🔄CMYK n'est effectivement pas bijectif (il n'est pas impossible de tomber sur des valeurs assez différentes lors d'un A/R entre les 2 modèles).
Et sans compter les "couleurs" de type "couleurs métalliques" ou "couleurs fluorescentes", etc. Bien sûr, selon une théorie de couleur pure, on ne considérerait peut-être pas cela comme une couleur, mais un humain considérera bien un bleu et un bleu métal comme 2 couleurs différentes (même si ça pourrait être considéré exactement le même bleu selon d'autres critères). Et là même en CMYK, on ne les représente pas. En général, c'est là où on utilise les "spot colors" qui sont encore un autre modèle, en général sur une base de catalogues.
Mais hormis ce type de transformation et autres exceptions particulières, les transformations entre la plupart des autres modèles sont bien bijectives et se font par de très simples opérations mathématiques. 😄
Ces derniers mois, j'ai donné des conférences sur le traitement d'image et de manière générale sur les sciences des couleurs dans une école d'ingénieur des Mines (Saint Étienne) et dans un IUT (Valence). Bien sûr, dans le temps d'une conférence (2H, bien qu'aux Mines, on a aussi eu des ateliers, donc ce fut même un séminaire d'une journée complète avec conf + atelier sur le traitement d'image avec GEGL), ce n'est qu'un survol très rapide des nombreux concepts. Quiconque croit pouvoir comprendre la problématique de la couleur en informatique en quelques heures se méprend totalement. Cela fait des années que je travaille en plein dedans et je découvre encore des choses, il m'arrive encore de finalement comprendre des trucs (alors que je n'avais même pas réalisé que je n'avais pas compris avant!), etc. D'ailleurs puisque j'ai écrit ce commentaire presque de tête, il n'est pas impossible que quelques erreurs s'y soient glissées. Cela ne fait que démontrer d'autant plus la complexité du sujet (un "classique" quand je lis un texte sur la théorie de la couleur est de comprendre sur le coup et de me dire "ah bah oui", puis d'avoir complètement perdu la logique une semaine après, si je ne l'ai pas relu ou appliqué dans du code entretemps).
Quand on regarde l'historique des logiciels de graphisme, on se rend d'ailleurs compte que l'ensemble de l'industrie a fait erreurs sur erreurs pendant des décennies sur le sujet de la couleur et essaie de les réparer progressivement (parfois en faisant de nouvelles erreurs ironiquement!).
Je parle bien de gros noms de l'industrie qui ont multiplié des bourdes sur les dernières décennies (et encore très récemment; ce ne sont pas forcément toutes de vieilles histoires).
Et en recherche c'est pareil, les chercheurs ont l'air de se tirer la bourre. Quand on discute avec certains ou qu'on lit certains textes de référence, il n'est pas rare que ça commence en gros par "tout le monde a tort, sauf moi!" Et nous, on navigue dedans.
Donc oui, c'est pas facile. Quiconque est intéressé par une conf sur ce sujet dans une université/école/entreprise peut me contacter d'ailleurs. Maintenant que j'ai commencé à en faire quelques unes, je me dis que c'est un sujet intéressant à expliquer et discuter. Donc je suis partant.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]