Actualiser couleur de fond en fonction d'un contrôle "toupie"

[sTERZOCK]

Bonjour,
Dans l'exemple ci joint je désirerai que la zone colorée soit automatiquement mise à jour dès que l'on appuie sur les flèches + ou - des contrôles "toupies".
Bien qu'ayant tenté sans succès d'utiliser en VBA "Calculate" ou "Refresh" de la feuille ou "RefreshAll" du classeur, la mise à jour de la couleur témoin ne se fait qu'en sortant du contrôle par sélection d'une cellule...
J'ai essayé en créant une macro associée au contrôle ou en utilisant le code de la feuille 1 (clic droit sur l'onglet dela feuille et "Visualiser le code").

Quelqu'un saurait-il?
Merci

 

[Dranreb]

Re : Actualiser couleur de fond en fonction d'un contrôle "toupie"

Bonsoir.

…Si c'est pour manipuler des teintes super saturées …

Non pas du tout. les couleurs sombres sont seulement éclaircies pour être en conformité avec la réalité, mais pas plus fortes (j'aime pas "plus saturées": je raisonne toujours en terme de longueur du vecteur de teinte, que j'appelle la "Force").

- Quel est ton calcul de conversion 0-256 en 0-1000?

J'ai supposé que c'étaient des valeurs proportionnelles aux quantités de lumière réfléchies par des colorants, ce qui ça doit être obligatoirement le cas pour avoir le droit d'en additionner les différentes contributions comme vous le faisiez déjà sur ces chiffres là. J'ai donc simplement fait 1000 * les valeurs / 255. Si ç'avait été des valeurs fixées un peu au jugé visuel pour qu'elles correspondent, à l'écran, aux couleurs réelles, il aurait fallu prendre: Si Gris > GLimite alors (Gris * kEG1 + kEG2) ^ ExGamma sinon Gris * FLinéaire
(Gris étant la variable qui contient la valeur RGB de codage arbitraire complètement fausse des pixels, et le reste, des coefficients appropriés)
C'est ma fonction EnrgG du module CouleursCalculs

- Comment "extrais" tu un gris de même luminosité qu'une teinte?

C'est PdR * EngR + PdV * EngV + PdB * EngB, calcul effectué dans plusieurs procédures. Préfixes Pd: Poids, Eng: Énergie qui est peut être un terme malheureux mais qui marque qu'il s'agit d'une mesure linéaire de la quantité de lumière dans sa couleur primaire.

- La carte graphique interprète-t-elle directement les valeur 0-1000 alors qu'on utilise habituellement des valeurs RGB ou hexadécimales?

Ah non ! On lui soumet une valeur calculée qui tient compte du gamma pour que ce soit restitué de façon juste à l'écran.
C'est: Si Enrg > ELimite alors (Enrg ^ (1 / ExGamma) - kEG2) / kEG1 sinon Enrg / FLinéaire (Enrg étant la variable qui contient une quantité proportionnelle à l'intensité lumineuse réelle qu'on veut imposer à l'écran sur ce pixel)
C'est ma fonction GrisE du module CouleursCalculs.

Dernière nouvelle: le truc est fait à 95%. Les 3 noirs sont pris en compte. Ça travaillera partout avec les couleurs complémentaires en fait. Les 1ers essais indiquent que PdR marche aussi pour cyan, PdV pour magenta et PdB pour jaune. Simplement ce sont des poids d'assombrissement et plus d'éclaircissement. L'interpolation linéaire en faveur du minimum permis des pires taux entre ceux du mélange juste et ceux du gris de même luminosité donne des résultats très prometteurs.


Bonjour.

Comme le plus gros est fait, je le joins déjà dans son état actuel. Mais il reste plein de détails à peaufiner :
Inscrire la solution retenue dans la feuille quand on clique dessus dans l'Userform.
Prévoir de quoi rajouter une couleur dans une des listes (palette ou cibles), en supprimer une.
Recalculer des colonnes lors d'une modification (Les infos d'énergie du gris équivalent et du vecteur teinte vous intéresseraient elles aussi dans les cibles, ou au contraire même pas dans la palette. Je pourrais aussi apporter la reformulation de la teinte en terme de chaleur et gaieté)
Rendre plus précis et/ou paramétrables les critères de classement des mélanges pour bien restituer les 5 meilleurs.
Pour le fameux gris très clair, il propose 4 autres solutions parfaitement logiques mais carrément désopilantes. Et je sais (pour avoir eu du mal à faire en sorte qu'il affiche d'abord la seule raisonnable) que ce n'en est que le début d'une très longue collection.

 

[sTERZOCK]

Re : Actualiser couleur de fond en fonction d'un contrôle "toupie"

Bonjour Dranreb,
J'ai regardé avec intérêt ton excellent travail. Au niveau calculs, vitesse d'exécution rien à dire.
Il y a cependant un gros problème pour moi : c'est la dérive de toutes les teintes (palette et cible) vers le blanc et cela très (trop) nettement. On dirait que 10 à 20% de blanc ont été ajoutés dans toutes les teintes et de façon plus marquée avec les mélanges cibles.
Pour illustrer ma remarque je te retourne ton fichier auquel j'ai ajouté, dans les colonnes "Désignation", les "shapes" colorés (encore! ) des couleurs originales.
De plus j'ai encore raisonné en RGB car cela me donne des résultats très proches de la réalité industrielle tant pour les pigments de la palette (qui est une répartition type utilisée dans la peinture, la plasturgie etc...) que pour les teintes cibles. Les cibles que je t'ai proposées ont été prises dans le nuancier RAL, une des références en industrie. Les codes RGB indiqués, et que j’utilise, sont très très proches, à l'écran, des échantillons sur carton de ce nuancier, à la brillance ou matité près.
En d'autres termes, quelque soit le système de codage couleurs utilisé (RGB, YCMN, TSL....), les couleurs de la palette et des cibles doivent rester celles que je t'ai communiquées depuis le début. Un coloriste potentiel doit pouvoir s'y retrouver. Est ce possible avec ton approche?

PS :Les teintes affichées par le lien du nuancier RAL sortent plus claires et plus vives sur mon écran que celles affichées par Excel ou Java

 

[Dranreb]

Re : Actualiser couleur de fond en fonction d'un contrôle "toupie"

Si vous voulez direz par là que l'aspect des couleurs d'origine sur l'écran est celui des teintes à considérer, ça veut dire que les calculs que vous faisiez étaient faux. Ou alors vous utilisez un écran spécialement réglé, sans gamma. Ou alors il faudra qu'on m'explique comment ils pouvaient être justes. Pour retrouver ces couleurs à l'écran il suffit de convertir en 0-1000 les valeurs d'origine à l'aide de la fonction EnrgG. Elle est utilisable en formules de cellules de feuilles de calcul.

Je peux aussi rendre variable les deux paramètres qui définisse la fonction, et prévoir une page de réglage à l'aide d'un contrôle visuel.
En tout cas les calculs portent sur les valeurs 0 à 1000. Le rendu à l'écran n'a pas d'incidence sur eux.

 

[Modeste geedee]

Re : Actualiser couleur de fond en fonction d'un contrôle "toupie"

Bonsour®

Les cibles que je t'ai proposées ont été prises dans le nuancier RAL, une des références en industrie. Les codes RGB indiqués, et que j’utilise, sont très très proches, à l'écran, des échantillons sur carton de ce nuancier, à la brillance ou matité près.

hummm ...références ?
de nombreuses non concordances (18 sur 213 soit 8,45%) entre RAL-RGB et RAL-HEX

 

[Dranreb]

Re : Actualiser couleur de fond en fonction d'un contrôle "toupie"

Bonjour.

Ainsi donc le rendu à l'affichage à finalement quand même une plus grande importance que prévu pour le choix des valeurs qui définissent les couleurs. Il ne s'agit donc plus seulement de rectifier l'inconfort d'un affichage trop sombre de valeurs faibles obtenues par une autre voie que l'observation de l'écran, celle ci ayant bel et bien une incidence sur leur saisie. Il faut alors impérativement éviter de spécifier des quantités de lumières trop élevées à cause de cet inconfort, si on veut que les calculs des mélanges soient justes. C'est pourquoi une feuille de vérification de l'exposant gamma de votre écran ne sera pas superflue, avec à la clé un moyen d'en fixer un autre dans la programmation.

 

[sTERZOCK]

Re : Actualiser couleur de fond en fonction d'un contrôle "toupie"

Salut Modeste,
Ton souci d'exactitude n'a d'égal que ta perspicacité dans l'observation!... Ce sont deux grandes qualités.
Tu as raison il y a bien des erreurs dans la liste RGB/RAL du lien que j'ai donné. Mais après vérification j'en ai dénombré 9 au lieu de 18. (erreurs de frappe dans la liste etc..) ce qui est encore trop. La Deutsch Qualität n'est plus ce qu'elle était, tout fout le camp.
Néanmoins je maintiens que le nuancier RAL, au même titre que Pantone, AFNOR ou British Standard, est bien une référence dans le monde industriel. Les valeurs RGB sont données à titre d'illustration car les professionnels n'utilisent que le nuancier physique cartonné où toutes les teintes sont des échantillons de peinture réelle. Ils sont diffusés (vendus) après un contrôle statistique très strict des Deltas L*a*b* de chacune des teintes. On ne rigole pas outre Rhin.
L'utilisateur de ce nuancier peut l'utiliser directement pour contrôle visuel afin de juger de l'écart d'avec le contre typage (il faut être très soigneux) ou il enregistre les valeurs CIEL*a*b effectuées au spectrocolorimètre pour mesurer cet écart en Delta E (somme des carrés des deltas sur L, a, b). Dans la pratique il vaut mieux conjuguer les deux.

 

[sTERZOCK]

Re : Actualiser couleur de fond en fonction d'un contrôle "toupie"

Bonjour Dranreb,
Que de chemin parcouru depuis ma première demande concernant un simple contrôle toupie! On arrive dans les hautes sphères de la gestion des couleurs à l'écran. Je me sens tout petit auprès de grands spécialistes.

Si vous voulez direz par là que l'aspect des couleurs d'origine sur l'écran est celui des teintes à considérer, ça veut dire que les calculs que vous faisiez étaient faux. Ou alors vous utilisez un écran spécialement réglé, sans gamma.

Pourtant tout est relativement clair dans ma tête quant à mon objectif. Je dois mal m'exprimer. Je pars de deux éléments de base NON CALCULES : une palette pigmentaire et une liste de cibles à reproduire à partir de cette palette.
Le code RGB me convient parfaitement quant à la reproduction de ces teintes. C'est peut être une faute, une hérésie du point de vue d'un photographe numérique ou d'un expert coloriste écran, mais c'est suffisant pour mes besoins. En tout état de cause ces couleurs de base (palette et cibles) ne doivent pas bouger sous risque d'être inutilisables pour moi. Vois le blanchiment de la palette après "traitement" dans le fichier ci joint. J'y ai mis le delta des TSL avant et après. Les différences sont trop importantes en luminance.
J'utilise l'écran tout à fait ordinaire d'un Acer Aspire Z5751 (gamma à 2,313476532 pour préconisé à 2,3135!... et veux rester dans un domaine d'équipement le plus large possible pour simuler cette synthèse soustractive... à l'écran. J'ai déjà expérimenté ce type d'exercice de contre typage en Flash (langage Action Script 2) à la satisfaction de tous. Les fonctionnalités y étaient moins nombreuses, telle que la correction automatique (avec solution exacte ou approchée au plus près) que je voudrais y apporter tout en migrant vers Java.
Si je récapitule :
Simulation des couleurs palette et cibles en RGB ---> satisfaisant
Calcul des solutions exactes ---> déjà acquis
Recherche des pigments candidats ---> acquis (grâce à toi - combinaison 2 à 2 avec tri des résultats cohérents et permis)
Calcul des résultats approchés au plus près ---> en cours d'exploration. Avec l'algorithme itératif du type solveur Excel GRG2 on a d'excellents résultats, même avec des valeurs RGB (As-tu vérifier avec l'un des premiers fichiers que je t'ai envoyés). Je vais essayé de m'en inspirer.

Pour terminer, je voudrais revenir sur la calibration de l'écran. On voit bien en entrant dans un magasin de TV que tous les écrans qui affichent pourtant le même programme ont des rendus couleurs différents. Ça n'empêche pas de s'en servir à moins d'être un puriste hyper exigeant. Dans mon cas une différence de rendu entre écrans ne me gêne pas trop (enfin, il ne faut pas exagérer) car dans le cas d'un contre typage on raisonne d'abord par différence visuelle. Dans mon programme la teinte cible et l'essai en cours sont côte à côte et observés dans les conditions (dans la mesure du possible) les plus proches des recommandations de la CIE. La palette, la cible (appelé aussi type ou témoin), l'essai de contre typage sont affichés sur le même appareil. Donc s'il peut y avoir de légers écarts de rendu d'un écran à l'autre, les écarts relatifs des teintes restent les même sur tous les appareils.
Le but de mon objectif est de privilégier le raisonnement du coloriste pour arriver au contre typage parfait avec 4 pigments (dont 1 blanc et 1 noir)

Dranreb, je te remercie de t'être intéressé à ma demande et de m'avoir éclairé sur de nombreux points. Même si certaines réponses ont été un peu trop en pointe, elles m'ont franchement intéressé.
Tu as déjà beaucoup fait, passé beaucoup de temps et ne voudrais plus en abusé.
Je te tiendrai informé.

 

[Modeste geedee]

Re : Actualiser couleur de fond en fonction d'un contrôle "toupie"

Bonsour®

Néanmoins je maintiens que le nuancier RAL, au même titre que Pantone, AFNOR ou British Standard, est bien une référence dans le monde industriel. Les valeurs RGB sont données à titre d'illustration car les professionnels n'utilisent que le nuancier physique cartonné où toutes les teintes sont des échantillons de peinture réelle. Ils sont diffusés (vendus) après un contrôle statistique très strict des Deltas L*a*b* de chacune des teintes. On ne rigole pas outre Rhin.
L'utilisateur de ce nuancier peut l'utiliser directement pour contrôle visuel afin de juger de l'écart d'avec le contre typage (il faut être très soigneux) ou il enregistre les valeurs CIEL*a*b effectuées au spectrocolorimètre pour mesurer cet écart en Delta E (somme des carrés des deltas sur L, a, b). Dans la pratique il vaut mieux conjuguer les deux.

c'est en effet ce que Dranreb s'évertue a te faire saisir ...
il me semble utopique de vouloir utiliser VBA et RGB pour afficher une équivalence directe CIE L*a*b
Peut-être en effectuant un étalonnage spécifique du moniteur utilisé ???
Quid de la portabilité et de la possibilité d'étalonnage ...