Questions pointues sur la gestion des couleurs (profils)

SimCI · Mars 06, 2011, 17:40:17

1) Lorsque l'on fait appel au gestionnaire de couleurs (ICM, ACM etc) :
la valeur finale (RGB) est-elle independante de la couleur des pixels voisins ?
(si "non", liens SVP)
(Le "dithering" de Photoshop est donc hors sujet).

2) Si 1) est vraie, alors peut-on creer une table de 16M de (0,0,0) a (255,255,255) vers (R_output,G_output,B_output)
et ne plus faire que de l'indexation ? (en 3x8 bits evidemment. Surtout valable pour les moniteurs)

3) Avec la puissance actuelle des cartes graphiques pourquoi ne deporte-t-on pas cette gestion vers les GPU,
ce qui reglerait bien des problemes de LUT et autres joyeusetes ?

Merci de vos contributions !

restoc · Mars 06, 2011, 18:15:04

Bonjour, si je ne m'abuse

Dans un profil Icm ou icc , le valeur des pixels de sortie est indépendante des pixels voisins. Il n'y a pas de matrice de calcul par voisinage qui viendrait fausser le calcul de valeur pur. A la différence des calculs de dématriçage.

La plupart des logiciels de visualisation 8 bits se contentent de charger la LUt 16 M de la CG avec une table calculée par eux.
Ls logiciels qui calculent en 16 bits, selon le type de CG vont soit lisser avant soit confier à la CG ( PS) qui selon son âge et sa qualité fait un lissage ou une bête troncature ou un calcul sommaire ou trés sophistiqué. Il n' ya pas de réponse unique. Certaines CG ont de plus en plus des tables 16 bits pour les images de synthèse type jeux. Certains moniteurs travaillant en 10, 12 bits ont leur propres Lut à bord.

CAlculer et Charger une table LUT ne demande que trés peu de puissance de calcul et charger une Lut ne prend que qqs millisecondes entre le processeur et la CG. C'est totalement transparent ( temps réel). Il n'y a pas besoin de puissance de calcul à ce niveau.

MAis ceci est déjà depuis longtemps totalement déporté dans les CG pour les images de synthèse qui en plus calculent et mélangent les textures et les couleurs, les profondeurs, les angles d'éclairement, les déplacements etc.
Les besoins des photographes son trés réduits par rapport aux jeux des gamins et bénéficient depuis dix ans des progrés des mômes !

janfi67 · Mars 06, 2011, 20:22:10

Citation de: SimCI le Mars 06, 2011, 17:40:17
la valeur finale (RGB) est-elle independante de la couleur des pixels voisins ?

oui

Citation de: SimCI le Mars 06, 2011, 17:40:17
peut-on creer une table de 16M de (0,0,0) a (255,255,255) vers (R_output,G_output,B_output)
et ne plus faire que de l'indexation ? (en 3x8 bits evidemment. Surtout valable pour les moniteurs)

Non, ce n'est pas si simple. La LUT est un moyen simple de gérer le gamma, mais un profil ICC pour écran permet aussi de passer d'un espace de couleur à un autre (l'espace source à l'espace écran dans ton exemple).

Il faudrait une table pour chaque profil de départ (sRGV, aRVB, proPhoto... et il y en a beaucoup d'autres) et pour chaque espace une table par type de rendu (perceptuel, relatif, saturation, absolu). Et je en parle pas de la gestion du point blanc, ...

Le mécanisme de gestion des couleurs icc est beaucoup plus complexe que la simple gestion de la couleur des écrans. Il permet de passer de n'importe quel espace de couleur à un autre. Et ce n'est pas une simple table qui permet de le faire.

Citation de: SimCI le Mars 06, 2011, 17:40:17
pourquoi ne deporte-t-on pas cette gestion vers les GPU, ce qui reglerait bien des problemes de LUT et autres joyeusetes ?

Ça fait un bout de temps que les cartes graphiques gèrent les LUT. Leur faire gérer l'intégralité de la gestion de couleur? Pourquoi pas? Mais il ne suffira pas d'envoyer des pixels, il faudra aussi spécifier l'espace de couleur utilisé.

En ce moteur devra de toute façon être disponible pour le soft indépendamment de l'écran (impression, conversion d'un espace à l'autre, soft proofing...)

SimCI · Mars 07, 2011, 11:25:01

PS :
la LUT actuelle des cartes graphiques est formee de
3 tables de 256 valeurs qui ne regle que le probleme de la gamma et la TC
(le moniteur n'est corrige que pour le Noir et Blanc
c-a-d toutes les valeurs ou R_input=G_input=B_input)

LUT actuelle : 3x256 = 768 octets
R_output=R1D(R_input),
G_output=G1D(G_input),
B_output=B1D(B_input)

LUT "3D" :3x256*256*256 = 3x16M octets
R_output=R3D(R_input,G_input,B_input)
G_output=G3D(R_input,G_input,B_input)
B_output=B3D(R_input,G_input,B_input)

Cette table n'est a calculer (par la CPU) qu'une fois par couple d'ICC (ICC de depart,d'arrivee,type de rendu).
L'exemple type (hypothetique bien sur - car il faut le profil ecran) serait sRGB->profil moniteur
ce qui permettrait a toutes les applis (windows pour ne pas les nommer) non corrigees d'etre affichees correctement.
Le profil par defaut deviendrait sRGB au lieu du profil moniteur.

Les fenetres des applis avec gestion de couleur sont un autre probleme (gerees par l'appli).
De meme les LUT des moniteurs qui (a ma connaissance) ne sont pas 3D.

Y a-t-il des OS ou la question est mieux geree ?
Des idees sur la meilleure implantation de la gestion des couleurs (ecran)
- application
- OS
- carte graphique
- moniteur
- autre ?

Desole si mes propos sont un peu decousus - j'essaye de me faire une religion sur ce sujet.

restoc · Mars 07, 2011, 15:22:10

Ouh Là ! Sim CI,

C'est un peu mélangé tout çà.

Il y a confusion entre les LUTs, le 3D, les canaux, les ICC, l'OS, les applis.

Toutes les CG ont au moins 3* ( nbits ) RVB : soit en 3*8 bits ou 3*10 ou 3*12 voir 3*16 pour certains modèles pour la partie vidéo.
Par ex Une lut 16 M correspond à 256 au cube combinaisons et pas 3*256 au cube.
Il n'ya plus de GG Mono depuis belle lurette ( 25 ans ?).
Mais pour les toutes les cartes graphique modernes destinées aux jeux et synthèse 3D , en plus des 3 canaux RVB il y a des tables des canaux testures , rendering etc. Oublier pour la photo

L'OS tel que Windows se contente de charger la Lut avec un profil qui lui est indiqué par les applications gérant la couleur. Par défaut une lut linéaire 3*8 bits 0,0 - 1,1 etc 255,255 ( si non on ne verrait pas grand chose ou alors des choses trés bizarres) ou bien le profil issu d'une calibration avec sonde. C'est ce profil issu d'une calibration qui intégre directement les corrections de couleurs calculées pour un espace couleur srGB ou Argb,( de tC) de gamma et les derniers ajustements fins de luminosité /contraste.

LA LUT se contente d'être chargée par le profil d'un côté de la matrice de la table et les données RVB de l'autre. LA sortie est bien une sorte d'indexation directe ( valeur RVB ** valeur corrigée par le profil>> sorties RVB).

Ce sont les applications qui viennent dire à Windows ou linux ou MAc Os quel profil elles veulent imposer .

Un viel article de base par exemple : http://www.astrosurf.com/luxorion/rapport-gestion-couleur4.htm ou http://www.profil-couleur.com/

Bon courage !

SimCI · Mars 07, 2011, 18:35:47

Sansame : Tout a fait favorable aux "smart color engines" !
En ce qui concerne la LUT/vcgt, nous en avions deja discute et je pointais sur
http://www.freelists.org/post/argyllcms/Monitor-calibration,55

restoc :

si l'assertion 1) est vraie, alors toutes les conversions (en 8 bits/couleur en entree et sortie)
se resument a :

R_output=R3D(R_input,G_input,B_input)
G_output=G3D(R_input,G_input,B_input)
B_output=B3D(R_input,G_input,B_input)

R_input est ce que gere l'appli dans sa fenetre (c'est la couleur voulue exprimee dans son espace - par exemple sRGB,AdobeRGB...)
R_output est ce qui est envoye ultimement a l'ecran LCD apres moulinette CMM/"LUT CG"/"LUT moniteur"

R3D(0,0,0) a R3D(255,255,255) , soit 256*256*256 =16M d'entrees.
De meme pour G3D et B3D, ce qui fait trois tables de 16M octets.
PS : le fait qu'on les appelle 3D rappelle que chaque canal de sortie depend de trois canaux d'entree R=f(R,G,B)
alors que les LUT classiques des cartes graphiques (en 8bits/couleur) sont du type R=f(R).
PPS : Je n'ai pas parle de cartes graphiques N&B, j'ai rappele que la calibration (sans utilisation de profil)
permet d'afficher correctement une image N&B avec la gamma et la TC choisies, le tout nativement.
Quand windows envoie (255,0,0) avec un rouge sense etre celui de sRGB, la carte transmettra par exemple (233,0,0)
ce qui sera "tres faux" sur un Wide Gamut. Avec une table 3D la carte transmettrait qqch du type (233,12,11), ce qui serait evidemment plus exact...

restoc · Mars 08, 2011, 14:23:19

SimCI,

Si on prend un écran avec une éléctronique de pilotage du rétroéclairage de 3*8 bits il ne peut reproduire , au mieux , que 3*8 bits soit 16 Mcouleurs max, quel que soit le nombre et la taille des Luts empilées ou combinées en amont et quels que soient la précision des calculs sur les espaces de couleur ou la précision des profils.

Un canal de huit bits juste avant d'attaquer le rétro éclairage, (donc aprés la sortie de la dernière Lut) ne fera que 8 bits et 256 valeurs max pour exprimer le résultat de tout ce qu'il y a en amont : valeur image corrigée du gamma de la TC et du calibrage de l'écran. Tout çà peut bien être calculé sur 32 bits par voie si on veut et être rangé ou manipulé dans des Luts 3D, à la sortie il n'y aura que 16 Mcouleurs max sur la dalle.

etc pour 10 ou 12 bits par voie, c'est l'éléctronique ( et ce qu'on appelle glabalement la "dalle" ) qui déterminent le max de couleurs affichables, transtitions comprises.

D'ailleurs je te cite :

"Quand windows envoie (255,0,0) avec un rouge sense etre celui de sRGB, la carte transmettra par exemple (233,0,0)
ce qui sera "tres faux" sur un Wide Gamut.
"Avec une table 3D la carte transmettrait qqch du type (233,12,11), ce qui serait evidemment plus exact... "
Cà fait toujours que 3* 256 valeurs !!!! Et ce n'est pas dû à la carte 3 D mais aux calculs du rouge corrigé par tout ce qui est en amont ( profil et espace couleur notamment). MAis forcément çà ne crée pas plus de couleurs malheureusement pour nous. !

Cdlt
Posté le: Mars 07, 2011, 16:45:04Posté par: Sansame

SimCI · Mars 08, 2011, 15:09:19

restoc :

Je ne comprends pas bien ton dernier message.
En 8bits/couleur on a bien 16M de valeurs possibles en entree (appli) et 16M de couleurs possibles sur la dalle.
C'est bien la-dessus que je me base.Il faut 3 octets (3x8bits) par couleur.

restoc · Mars 08, 2011, 21:18:43

SimCI

Oui 16 M OK, mais pas 3*16 M comme tu le disais plus haut. Je pense qu'on est d'accord sur le fond.
Nos chers fabricants d'écrans revendiqueraient d'ailleurs vite 48 M couleurs et pas 16 si c'était le cas et en profiteraient pour augmenter le prix. !!

chewan · Mars 08, 2011, 22:30:51

Bon alors d'un point de vue mathématique, on peut procéder à un passage d'un espace couleur à un autre avec une grande table si les valeurs d'entrées sont indexées et non continue.

Pour du 8 bits cela donne bien 3 tableau de 16 Mo chacun.

Mais...

1) Actuellement les accès mémoire sont plus lent que les calculs si les calculs sont simplifié...

2) C'est pénible, car il faut calculer la table pour chaque changement d'espace source/cible, la recopier c'est une perte de temps.

3) Mine de rien la mémoire est couteuse.

4) Cela ne marche plus pour des valeurs continues ou des grands espace de codages(16 bits)...
Imaginer par exemple pour des valeurs codées en 10 bits par composante, cela donne une taille de table de: 3 * 2ˆ30 octet soit 3 Giga de mémoire....

Pour des composantes en 16 bits en entrées et sortie la table vaut: 2 * 3 * 2ˆ48 = 6 * 65536 Giga de mémoire....

C'est pour cela (entre autre) que l'on utilise pas cette méthode, mais que l'on passe par des calculs...

Microsoft(et oui) à publié d'intéressant article de vulgarisation sur les méthode de calculs pour les espaces de couleurs.
Cela dit, ce qui est compliqué n'est pas vraiment la conversion en elle même, mais comment calculer les transition entre espace de couleurs(comment calculer les matrice de conversion.)

SimCI · Mars 08, 2011, 23:21:05

chewan :

- temps d'acces memoire / pixel / temps de caclul par le CMM pour chaque pixel : des donnees precises ?
- pour windows cette table est calculee pendant le boot et reste valide tout le temps (ex : le moniteur est "calibre" en sRGB)
- pour windows la memoire video est abondante (les applis 3D et PS+LR sont hors concours) je n'en connais pas beaucoup a moins de 512M
- ce fil ne concerne que le 3x8bits -> 3x8bits, qui, jusqu'a preuve du contraire, concerne 99% des PCs "win->LCD"

La methode du "paresseux" pour obtenir cette table :

creer une image non compressee 24bits de 16M pixels de couleur variant de (0,0,0) a (255,255,255)
lui "assigner" le profil sRGB dans Photoshop (donc pas de modif des valeurs)
la "convertir" dans le profil ecran (eh oui) (profil ecran realise sans LUT sinon pb - c'est possible avec certains softs (reset de LUT et "profile only"))
recuperer la table (non compressee en jpeg !!) - voila ! (evidemment il faut savoir gerer les tableaux [][][])

SimCI · Mars 08, 2011, 23:32:27

J'ai pas reussi a modifier a temps :
remplacer
- pour windows cette table -est- calculee pendant le boot
par
- pour windows cette table -serait- calculee pendant le boot

chewan · Mars 09, 2011, 00:19:40

Je comprend pas trop le but....

Tu est au courant que tout ces calculs sont déja réalisé par les logiciels/OS ?

Sinon concernant les questions techniques, c'est très dépendant du processeur et des images, sur des images avec des aplats, passer par une table est très intéressant, sinon à coup sur la table ne sera pas en mémoire cache et les délais peuvent varier de 50 à 200 instructions suivant les architecture, c'est pour cela que on passe par les calculs, si je me trompe guère, un pentium de type "core" peut calculer un polynôme du 8 ième degré le temps d'un accès mémoire...

Mais cela dit ces calculs sont disponible aussi sous forme soit de librairie(moteur de gestion de couleurs libre, soit on passe par les routines intrinsèques des compilo), c'est très rare de passer en assembleur.

Mais sinon tu peut passer par open-GL pour une pas si mauvaise approximation en temps réel calculé par le gpu.

Mais encore une fois, je ne comprend pas ton objectif ? Tu ne trouve pas d'outils te convenant ?

SimCI · Mars 09, 2011, 18:07:46

chewan ,

but du jeu :

Connaitre l'"etat de l'art" pour differents OS que je ne connais pas,
voir si qqn a implemente qqch de similaire (Nvidia avait publie un papier pour les applis 3D)
probablement avec OpenGL.
Ou un calcul non tabule par OpenGL.

Imaginer ce que serait la chaine de gestion de couleurs la plus claire pour les OS a venir (appli->CG->LCD, nbits/pixel),
brainstorming quoi ! (je crois qu'il y a une traduction francaise...)

Merci pour les estimations de temps CPU ! Bonne matiere a reflexion ...

chewan · Mars 09, 2011, 20:38:07

Citation de: SimCI le Mars 09, 2011, 18:07:46
chewan ,

but du jeu :

Connaitre l'"etat de l'art" pour differents OS que je ne connais pas,
voir si qqn a implemente qqch de similaire (Nvidia avait publie un papier pour les applis 3D)
probablement avec OpenGL.
Ou un calcul non tabule par OpenGL.

Imaginer ce que serait la chaine de gestion de couleurs la plus claire pour les OS a venir (appli->CG->LCD, nbits/pixel),
brainstorming quoi ! (je crois qu'il y a une traduction francaise...)

Merci pour les estimations de temps CPU ! Bonne matiere a reflexion ...

Si tu lis l'anglais tu peut trouver des mines d'informations sur le sujet via un simple google...

Ensuite je dirais que si tu veut amener ta pierre à l'édifice de l'état de l'art en la matière, il faudra commencer par un master... (Un niveau bachelor suffit pour la réalisation).

SimCI · Mars 09, 2011, 22:23:47

Merci a tous de vos contributions.

restoc · Mars 10, 2011, 15:27:04

Merci Sansame ,

Ce cher Bruce a pensé à tout y compris a vérifier ce qu'on perd en passant en Lab dans PS . Cette limitation -127 + 127 est elle toujours vraie dans PS4 ou 5 ? .

restoc · Mars 10, 2011, 21:00:20

Merci Sansame,

Question subsidiaire qui taraude tous vos lecteurs :

Un outil de calibrage qui utiliserait le Lab pur pour ses calculs ( une sonde écran ou un spectrocolrimètre d'imprimante) serait il en mesure de calibrer précisément, sans dominante ou sans trous ?
Je pense à un spectro populaire ( que j'ai eu la mauvaise idée d'acheter évidemment ) dont les utilisateurs US font remarquer que sans bidouillage à la main du profil, le Lab intoduit ( naturellement selon eux) des décalages magentas, ou autres anomalies.

Merci d'avance.

restoc · Mars 11, 2011, 08:16:55

Un grand merci Sansame,
Un point trés complet et toujours tellement facile à lire.
Je vais tenter d'introduire le " nouveau Lab" sur un fichier de mesure dont je suis trés sûr pour voir si çà tend à corriger le décalage trop visible du profil specto . Cà va occuper un Week end pluvieux !

Je déduis de votre dernière phrase que l'espoir d'une chaîne parfaitement calibrée laisse une part à la chance ou à la patte d'un artiste de la calib.

PAr ailleurs j'ai observé que les logiciels PS, Qimage, CNX 2, donnent des résultats de proofing différents. Ils utilisent donc a priori des calculs différents ou appliquent
De mes observations Qimage, PS (4 dans mon cas) et l'outil de proofing de Datacolor donnent des résultats quasi identiques (le décalage vers le magenta est le même) y compris en bord de Gamut. Par contre CNx 2 lui recentre vers les verts !

Si on ne peut même pas faire confiance aux outils de proofing des garnds constrcteurs ...

cordialement

MAis les uns et les autre ne sont pas plus faux

janfi67 · Mars 11, 2011, 08:55:52

Thread intéressant.

Jusqu'en 2008 (au moins), Qimage utilisait littleCMS color engine de Marti Maria.

Je ne sais pas pour les versions suivantes, mais c'est facile à vérifier dans les propriétés de lcms.dll si elle existe toujours.

restoc · Mars 11, 2011, 11:49:32

merci Jeanfi67,

Intéressant, J'ai la dernière version de QI ultimate ( publiée hier !) et je trouve une lcms2.dll. De fait , je n'ai jamais eu à me plaindre du proofing de qimage sauf qu'il nest pas trés ergonomique lorsqu'on veut comparer différents profils en toggle rapide.

Je vais essayer de poser la question à Mike pour voir ce qu'il y a de différent entre la version 2008 et la dernière.

restoc · Mars 11, 2011, 11:57:48

Pour info, site de Littlecms ,

http://www.littlecms.com/

Manu_14 · Mars 11, 2011, 13:38:03

Merci Sansame pour ces explications étayées et limpides (comme d'hab...).

Manu