|
|
lol.. quand on dit aux éléves que les espaces vectoriels, c'est pas juste des maths... car c'est ça, un profil colorimétrique... Juste un espace vectoriel! si tu sais ce qu'est une fonction de transfert et un espace vectoriel, tu sais comment fonctionne les espaces colorimétriques, c'est aussi simple que ça....
et du coup, tu sais que passer d'un profil à l'autre n'est pas une application bijective, c'est ça qui craint à fond! et donc, on peut toujours rêver de trouver une imprimante qui imprime ce qu'on voit à l'écran, l'espace de couleurs étant nettement plus étroit... |
|
|
|
|
|
|
 |
|
|
|
Citation de JJ :
Les mathématiques c'est beau comme de la poésie mais c'est souvent enseigné par des rustres !  |
|
oui.. si on expliqué juste aux éléves que ça a des applications pratiques, que ça parle et que ça vit, je suis sûre qu'il y aurait plus de matheux dans les classes....
Explications pour ceux qui n'ont pas assisté au cours étant jeunes (je suppose que vous savez comment fonctionne un écran):
Espace RVB et couleurs physiques:
un profil colorimétriques, c'est en gros une liste de couleurs affichable par un périphérique. Par exemple, en RVB 8bit, le codage se fait sur 256 niveaux par canal. soit 256 * 256 *26 possibilités, soit 16 777 216 nuances possibles.. pas une de plus... on admettra que pour la couleur "physique", il existe un nombre infinie de nuances...
en pratique, c'est déjà beaucoup plus que ce que peut différencier l'oeil humain. Il existe mathématiquement parlant une fonction qui associe une couleur "vue" (réelle) à une couleur codée.. ce sont 2 espaces vectoriels de dimensions différentes (l'une à une nombre infinie de couleurs, l'autre un nombre finie de grossos modo 16 millions de couleurs (en 8 bit)).
Codage des couleurs physiques:
Il existe un premier probléme qui se trouve être le passage d'un espace à l'autre... une couleur réel correspond à une couleur codée, mais une couleur codée pourrait correspondre à plusieurs couleurs réelles. L'application n'est pas bijective: ça veut dire qu'en clair, il est impossible de retrouver les couleurs d'origine à partir des couleurs "codées"... c'est logique, on a supprimé une partie de l'information.. c'est ce qui s'appelle l'entropie de l'information: à chaque transfert d'info, on en peut que détruire de l'info mais pas la retrouver (à méditer quand vous poussez la
Compression
...).
Probléme de reproduction des couleurs
Le probléme de profil d'écran, c'est pareil mais dans l'autre sens: on a un fichier avec des couleurs codée. le probléme, c'est que l'écran est une production humaine et que la perfection n'existe pas: un masque de pixel plus épais, un colorant légérement différent... Du coup, chaque écran est différent, et va afficher les couleurs codées de façon différente...
Exemple: si on code une couleur avec autant de rouge que de vert que de bleu, suivant la façon dont est fabriqué le masque de l'écran (la nuance du rouge, du vert et du bleu du filtre pour chaque pixels), la couleur affichée sera légérement différente.
En mesurant l'écart (avec une sonde) on peut le corriger: on applique alors une fonction de transfert entre les 2. La fonction de transfert est une application qui associe une couleur codée à une couleur corrigée. Encore une fois, on va perdre de l'info entre les deux: la conversion réduit l'espace de couleur (entropie de l'information).
Du coup, un bon écran, c'est celui qui a la gamme de couleur affichable la plus large possible.. un écran bas de gamme, mal fabriqué devra faire appelle à une fonction de transfert corrigeant plus fortement, donc détruisant un peu plus de donnée. L'espace couleur réduit l'espace colorimétrique final... ça justifie la mesure des magasines qui teste les écrans: ils publient une représnetation simplifiée sur 3 axes qui est censé représenter les couleurs existantes, et tracent la zone des couleurs reproductibles à l'écran. Plus la zone est large, meilleur est l'écran.
Le probléme des imprimantes:
Pour les imprimantes, c'est encore pire: alors qu'écran et appareil fonction sur le même principe (RVB) l'imprimant imprime en CMNJ... En utilisant pas les même couleurs de base, on ne peut pas obtenir les mêmes nuances... l'espace CMNJ est plus réduit que l'espace RVB... (je passe sur les différences lumiéres émises lumiéres réfléchies qui compliquent l'histoire).
Bref, tout ceci est une histoire de maths: il faut des algorythmes qui permettent de passer d'un espace à l'autre en perdant le moins d'infos possibles...
je sais pas si j'ai été clair, je m'embrouille un peu, mais en gros, c'est plus ou moins la base, après, le reste, c'est du détail de spécialiste (que je ne suis pas) |
|
|
|
|
|
|
|
|
Citation de Jerome :
Merci moumou....
Mais lors comment expliques-tu le fait qu'une même photo apparaisse différement sous fFirefox que sous Safari ou Explorer ?  |
|
rien de compliqué: la fonction de transfert (décodage) n'est pas la même... donc l'affichage n'a pas de raison d'être la même...
après, ça dépend de la cuisine interne du navigateur, qui utilise les profils à leur sauce...
en simplifiant, si tu n'as que 3 niveaux: un blanc oure , un noir et un gris neutre, et que manque de bol, la couleur que tu photograohie est gris foncé... l'un va peut être choisir de la représenter noir, l'autre gris moyen... ça dépend du code qui est derriére et qui sert de fonction de transfert |
|
|
|
|
| | |
J'en ai de bons souvenirs... mais quand j'ai employé ce mot en cours, en général j'ai des regards vides ou effrayés...
... à moins que tu puisses utiliser les fichiers .icc produits sous windows
