Questions pointues sur la gestion des couleurs (profils)

[SimCI]

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]

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]

la valeur finale (RGB) est-elle independante de la couleur des pixels voisins ?

oui

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.

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]

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]

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 !

[Sansame]

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 ?

Non, le trio RGB obtenu par la conversion est exclusivement calculé à partir de la situation du seul pixel considéré dans l’espace de connexion des profils.
Mais votre question en soulève une plus générale : pourquoi les moteurs de conversion ne tiennent-ils pas compte de l’image ? Ils opèrent sur chaque pixel, l’un après l’autre, mais ils ne tiennent pas compte de l’image proprement dite, c’est à dire de sa structure colorimétrique ? L’exemple le plus évident, sur lequel pas mal de gens travaillent pour mettre au point ce que l’on appellera sans doute un jour les « smart color engines », concerne le concept de mode de rendu. Il est en effet absurde qu’un moteur de conversion accepte sans rechigner de convertir en mode de rendu perceptif les images qui ont pourtant toutes leurs couleurs à l’intérieur du gamut cible. Un smart color engine pourrait, après analyse de l’image, « choisir un mode de rendu optimal »....

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)

Un profil de sortie fait la relation, non pas entre un espace RGB d’entrée vers un espace RGB de sortie (car alors on aurait autant de profils que de couples d’espaces d’entrée-sortie) mais de l’espace de connexion des profils (l’espace absolu des couleurs) vers  l’espace RGB de l’appareil.
On peut parfaitement faire un profil sans vcgt, c’est à dire un profil faisant l’hypothèse que la LUT de la carte graphique est vierge de toute correction gamma. Certains l’ont même préconisé il y a qq années, prédisant ainsi la disparition de la balise vcgt, laquelle n’a pas été conçue par l’ICC mais par Apple ! (il me semble que ça a été le cas du défunt et regretté Fraser). Quand on fait ça, il faut bâtir un profil basé sur des tables bourrées de nombres (et non un simple profil matriciel comme la plupart des profils d’affichage) et espérer qu’on possède un écran de bonne qualité dont les courbes gamma natives sont proches de 2,2, car, sinon, les couleurs non gérées deviennent bizarres, et surtout, les gris deviennent colorés.

[SimCI]

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]

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]

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.

[Sansame]

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) ... 

Je suppose que vous parlez de conversion proprement dite, c’est à dire de l’opération exécutée par le moteur de conversion entre l’espace RGB1 d’entrée et l’espace RGB2 de sortie à partir de leurs deux profils ICC1 et ICC2.

Alors, on ne peut pas dire que, pour un pixel donné RGB, le moteur « calcule R2 à partir de R1 ». En effet, la conversion s’appuie sur l’espace pivot de connexion des profils qui est l’espace absolu de toutes les couleurs perceptibles, exprimées dans CIEXYZ ou CIELAB et jamais dans un espace RGB.

D’une certaine manière, on peut dire que, R2 étant calculé à partir de la couleur absolue donnée dans Lab par le profil ICC1 à partir de R1.G1.B1, il s’en suit que R2 est de fait « calculé à partir des trois composantes R1.G1.B1 ». Si, par exemple, on change la valeur de G1, cette modification va en général changer les valeurs des trois composantes R2.G2.B2 et pas seulement celle de G2.

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.

Si une image définie explicitement dans sRGB contient un pixel RGB (255.0.0) et qu’une application gérant les couleurs veut l’afficher, alors, elle va d’abord convertir le pixel dans le profil d’affichage (en calculant d’abord la situation absolue de la couleur sRGB dans Lab puis en calculant la situation de cette couleur absolue dans le profil d’affichage). Ce profil décrit le comportement de l’écran « tel qu’il est réglé actuellement » c’est à dire, entre autres, avec une carte graphique « telle qu’elle est paramétrée actuellement ». C'est le résultat de la conversion R2.G2.B2 qui sera injecté à l'entrée du dispositif d'affichage, c'est à dire à l'entrée de la carte graphique

Si, ce qui est aujourd’hui classique, l’espace d’affichage est sensiblement plus vaste que sRGB, alors la conversion donnera une composante R un peu inférieure à celle que la couleur avait dans sRGB (pourquoi pas 233). Mais les deux autres composantes G et B seront sans doute petites mais jamais nulles, car il n’y a aucune raison pour que la couleur résultant de la conversion soit située sur la primaire R de l’espace d’affichage. Si l’espace d’affichage est plus grand que sRGB, il est même impossible que la primaire de sRGB soit également celle de l’affichage.

[restoc]

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]

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]

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]

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]

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]

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 ...

[Sansame]

...passer par une table est très intéressant, sinon à coup sur la table ne sera pas en mémoire cache...

Je rajoute ici une petite couche sur ce qu’est une « table » au sens de la conversion colorimétrique telle qu’elle est standardisée par l’ICC. Mais je ne suis pas certaine d’être dans le sujet, car j’ai eu un peu de mal à suivre les dernières interventions. Mais bon...

Une conversion basée sur une seule table imposerait qu’on ait un profil pour chaque couple source-destination (par exemple, un profil d’imprimante pour les images sRGB et un autre pour les images ProPhoto RGB).

C’est la raison pour laquelle on utilise deux tables. La première, dans le profil source, permet de passer de l’espace source à l’espace de connexion des profils. La seconde, dans le profil de destination, permet de passer de l’espace de connexion des profils à l’espace de destination.

En réalité, il existe bien des profils permettant de passer directement d’un espace à un autre à partir d’une seule et même « table » sans donc passer par l’espace absolu pivot. On les appelle « Device Link Profiles » mais ils ne sont pas courants (Photoshop ne sait les exploiter que depuis peu). Ce sont des profils construits par certains imprimeurs qui cherchent à optimiser leur consommation d’encres. En France, Alwan est spécialiste de cette technique et le logiciel ColorThink Pro permet de fabriquer un tel profil à partir des deux profils source et destination.

Mais la vie du développeur de moteur de conversion ou de logiciel de "profilage" est rendue plus difficile encore par le fait que, derrière le simple mot « table/LUT » l’ICC cache une réalité mathématique assez baroque et variable selon le profil. La « table » d’un profil, pour un mode de rendu donné, est en effet constituée de plusieurs éléments qui peuvent être des courbes, des matrices de conversion et des tables multidimensionnelles...

Dans le cas classique le plus simple d’un profil matriciel d’appareil RVB (écran, scanner...) le profil permet de passer de l’espace de connexion XYZ à l’espace RVB en appliquant d’abord une matrice 3x3 puis une série de 3 courbes monodimensionnelles (« gamma ») à chaque canal RVB.

Dans le cas plus complexe d’un profil de sortie à plus de trois canaux (par exemple CMJN) le passage de XYZ à CMJN peut dérouler les étapes suivantes : jeu de 3 courbes + matrice 3x4 + autre jeu de 3 courbes + table multidimensionnelle CLUT + jeu de 4 courbes d’appareil (une par canal de sortie). Le plus classique se limitant à : 3 courbes + CLUT+ 4 courbes d’appareils.

Quant à l’aspect numérique de cette affaire, puisque ce fil semble focalisé sur les questions de précision, voici les principales caractéristiques des nombres du profil :

- Eléments de la matrice : 32 bits avec signe.
- Points des courbes : 16 bits sans signe.
- Eléments de la CLUT : 8 bits/16 bits sans signe.

[chewan]

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]

Merci a tous de vos contributions.

[Sansame]

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)

Plus paresseux encore : cette image est assez casse pieds à fabriquer mais l'inimitable et indispensable Bruce Lindbloom s'est chargé de la produire pour nous sous le nom de "An RGB Image Containing All Possible Colors". Elle est téléchargeable ici et est utile pour mettre en lumière les pertes d'information induites par les conversions colorimétriques :

http://www.brucelindbloom.com/index.html?RGB16Million.html

[restoc]

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 ? .

[Sansame]

Restoc :

Quand on regarde d’un peu près les formules permettant de calculer L*, a* et b* à partir de X, Y et Z, on voit que la limite inférieure de a* est -431 (valeur obtenue quand le rapport Y/Yblanc est égal à 1 et que X est nul). De la même manière, on peut montrer que la limite supérieure de b* est 172. Les valeurs maximale de a* et minimale de b* sont d’autre part tellement hénaurmes en valeur absolues qu’elle n’ont aucune signification physique. Donc, si on accordait au « cube Lab » ses dimensions maximales, il aurait un volume colossal qui gaspillerait 99% de ses capacités de codage dans des « couleurs imaginaires » sans aucun sens physique.

Nos standardisateurs éclairés prirent donc la décision de limiter a* et b* dans l’intervalle [-128, +127]. Ce n’est donc pas une initiative d’Adobe mais des auteurs de normes (dans lesquelles Adobe est assez impliqué, mais bon). Cette limite est par exemple explicitement fixée par la norme de fichiers TIFF et par les standards ICC/ISO de gestion des couleurs.

Quelles sont les conséquences de ce coup de guillotine donné à certaines protubérances de la patate perceptible de l’espace Lab ? Les verts, violets et orangés vraiment extrèmement très saturés ne peuvent pas être codés dans Lab. Et quels sont les inconvénients de cette conséquence ? Aucun.

Je ne me souvenais pas que Lindbloom avait parlé de cette limitation. Mais je me souviens bien de la manière dont il triture la fameuse image « contenant toutes les couleurs codables sur un octet par couche RVB » et qui aboutit à cette fameuse catastrophe pleine de trous ! Un numéro d’illusionniste assez rigolo que j’ai relu ce matin avec plaisir quand j’ai cherché le lien que j’ai donné ci-dessus.

[restoc]

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.

[Sansame]

Restoc :

J’ai vu ces critiques de l’espace Lab. Pour s’en consoler on peut d’abord se taper le bouquin (assez délirant) de Dan Margulis entièrement consacré aux vertus de Lab, modèle qui, selon lui, les a toutes. 

Plus sérieusement, Lab a des défauts, mais je vois mal ces défauts justifier aujourd’hui qu’on utilise autre chose. C'est vrai qu'il n’est pas aussi uniforme qu’on le dit. Les « cercles » d’égales différences sont de déplorables ellipses dans xyY mais ils sont aussi des ellipses dans Lab, certes moins aplaties, mais elles seraient des cercles parfaits si Lab représentait correctement les différences de couleurs.

Et puis, il y a cette galère de la « dérive pourpre des bleus » dont les américains sont assez friands. Cette anomalie de Lab est visible si on considère ce modèle, non pas en coordonnées cartésiennes L*a*b*, mais en coordonnées polaires (cylindriques) L*, chroma et teinte. C’est l’espace  CIELCh.

Dans ce mode de représentation, la teinte est mesurée par l’angle entre d’une part le « demi plan vertical » passant par l’axe vertical L* et le point de couleur considéré et, d’autre part, le plan vertical passant par l’axe horizontal a*. Ca parait un peu compliqué mais quand on fait un dessin, c’est limpide.

Dans ce mode, tous les points d’un demi plan vertical passant par l’axe vertical des L* représentent théoriquement des couleurs qui ont la même teinte. Par exemple, l'angle de teinte 180° correspond théoriquement à la teinte verte. Or, l’examen de ces couleurs montre que ce n’est pas le cas. Les teintes d’un même plan varient légèrement quand on s’éloigne ou quand on se rapproche de l’axe vertical L*.

Conséquence sur les profils d’impression
 
Si une couleur est non-imprimable, hors du gamut cible, elle va être remplacée par une couleur moins saturée, plus proche de l’axe vertical L* (choisie par exemple sur la limite du gamut si on a opté pour le mode de rendu colorimétrie relative). Or, le moteur de conversion va choisir cette couleur dans l’espace de connexion des profils Lab pour avoir la même teinte absolue, c’est à dire dans le même plan vertical passant par l’axe vertical L*. Manque de pot, on a vu plus haut que la teinte n’est pas constante dans ce plan...

Il se trouve que les écarts de teintes dans le plan vertical sont particulièrement significatifs pour les plans mono-teinte qui « devraient être bleus ». En gros, quand on se déplace dans un plan vertical bleu, de la périphérie de Lab vers l’axe L*, la teinte commence d’abord à se décaler vers le pourpre puis elle revient vers le bleu, pour être conforme au bleu nominal à proximité de l’axe L*.

La solution ? Il faudrait changer l’espace de connexion des profils ICC et adopter un espace de type Lab mais dont les plans verticaux passant par l’axe vertical L* soient de teinte absolument constante (on doit adopter ici la définition de la teinte perçue telle qu’elle a été fixée par Munsell).

Quelqu’un l’a-t-il fait ? Oui, Bruce Lindbloom, encore lui !  (il appelle ce « nouveau Lab » un peu improprement Uniform Perceptual Lab). Son profil peut être téléchargé ici :
http://www.brucelindbloom.com/downloads/CIELab_to_UPLab.icc.zip

Quelqu’un a-t-il remplacé Lab par ce nouvel espace dans son moteur de conversion ? Oui, Marti Maria, dans son logiciel LittleCMS. Il semble en effet que ce logiciel remplace Lab par le Lab de Lindbloom quand il fait du gamut mapping avec des tables A2B0 et B2A0 c’est à dire les tables du mode Perception dans les profils d’impression...

Ceci dit, adopter une méthode contraire à l’ICC me parait aujourd’hui bien risqué, pour un bénéfice dont je ne suis pas certaine qu’il dépasse la marge d’incertitude normale d’un profil...

[restoc]

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