Passer d'un rendu RGB par calculs à un rendu RYB par une table
Citation:
Retour aux équations :
Moi, j'ai besoin de comprendre, et avec mes faibles moyens je ne vois aucune logique dans ce qui précède et que je reprends ci-dessous :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1: w := ( 2*Cost + 1)/ 3;
2: w := ( 8*Cost + 4*Sint*Sint + 1)/ 9;
3: w := (128*Cost + 64*Sint*Sint + 16*Sint*Sint*Sint*Sint + 7)/135;
128 c'est 27 et le 7 on le retrouve avant la parenthèse fermante, tout comme la 1re ligne où 2 c'est 21 qu'on retrouve au même endroit.
Mais 8 c'est 23 et si je mets un 3 au lieu du 1 dans la parenthèse de la 2e ligne c'est la cata.
Mauvais plan.
Tout au bout, 1re ligne 3 c'est 31, dessous 9 c'est 32 mais 135 c'est rien, ou plutôt 33*5, rien à voir avec les deux précédents.
À partir de ces informations, il m'est impossible d'envisager d'écrire une 4e ligne, à part
4: w := (256*Cost + je_sais_pas_quoi)/34*?
Au milieu, 4 c'est 22, 64 c'est 26, dois-je inventer un 210*Sint*Sint ?
De toute façon, je ne saurai pas quoi mettre après.
Ne perd pas ton temps à ce genre de conjectures tout à fait infondées; la détermination des coefficients est basée sur l'utilisation des développements limités des fonctions Sin(x) et Cos(x) au voisinage de zéro (formules de Taylor-Young).
Je vois que tu te mets à coder d'une façon plus claire :plusser: ; devant tant de bonne volonté, je te donne l'expression de la dernière fonction, que je n'ai pas eu le temps d'insérer dans le programme:
F4(t) = (1024*Cos(t) + 512*Sin(t)2 +128*Sin(t)4 + 64*Sin(t)6 + 29)/1053
qui doit vérifier: F(0)= 1 et F(2*Pi/3) = 0 .
Si tu pouvais éviter de commettre des inconguïtés comme
Code:
w := (128*Cost + 64*Sint*Sint + 16*Sint*Sint*Sint*Sint + 7)/135;
:aie: ce serait presque parfait !
Allez, un petit effort, il suffit de poser:
Code:
Sint2 = Sqr(Sint); Sint4:= Sqr(Sint2); Sint6:= Sint2 * Sint4;
Passer d'un rendu RGB par calculs à un rendu RYB par une table
Citation:
Envoyé par
Jipété
... Merci pour la formule, je l'ai mise en œuvre en une poignée de secondes :
Code:
1
2
3
4
5
6
7
|
CASE idx OF
1: w := ( 2*Cost + 1)/3;
2: w := ( 8*Cost + 4*Sint2 + 1)/9;
3: w := ( 128*Cost + 64*Sint2 + 16*Sint4 + 7)/135;
4: w := (1024*Cost + 512*Sint2 +128*Sint4 + 64*Sint6 + 29)/1053;
END; |
C'est beau, c'est propre, et c'est totalement incompréhensible pour moi, un véritable charabia dans une langue étrangère, désolé …
Si Honorin des Meldeuzes, membre du Conseil d'Administration d'une prestigieuse entreprise honore de sa présence l'une des séances de ce Conseil, et si aucun autre participant ne relève des mêmes initiales, alors le (ou la) secrétaire de séance pourra annoter HdM les interventions du quidam en question, sans risque de méprise ou d'ambiguïté.
De même si le calcul d'une expression ne met en cause que la fonction Cos(t), ainsi que les puissances paires de Sin(t), alors ce n'est peut-être pas exiger un courage héroiïque que d'inviter à prendre la notation (Cost, Sint2, Sint4 ... etc).
Et comme tu es parti sur une bonne idée, voici une variante adaptable à toutes les fonctions:
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| CASE idx OF 1: BEGIN
s:= 1; IncR(s, 2*Cost )
w:= s/3
END;
2: BEGIN
s:= 1; IncR(s, 8*Cost), IncR(s, 4*Sint2);
w:= s/9
END;
3: BEGIN
s:= 7; IncR(s, 128*Cost); IncR(s, 64*Sint2); IncR(s, 16*Sint4);
w:= s/135
END;
4: BEGIN
s:= 29; Inc(s, 1024*Cost); Inc(s, 512*Sint2); Inc(s, 128*Sint4); Inc(s, 64*Sint6);
w:= s/1053
END END; |
Citation:
Envoyé par
Jipété
... Ce qui me fait peur (ce n'est pas la première fois que je lis ça sous ta plume), c'est l'expression ... / ...
C'est moi qui dois vérifier ?
Bon, allez, courage, calculons :
-- avec t = 0
cos(0) = 1 , *1024 = 1024
sin(0) = 0 donc 0 + 0 + 0 + 29 = 29
1024 + 29 = 1053 / 1053 = 1, on est bon avec t à 0
-- avec t = 2*Pi/3 = 2,0944
cos(2.0944) = 0.999332 , * 1024 = 1023.316
sin(2.0944) = 0.036546 , sqr = 0.00133561 , *512 = 0.68383232
sqr * sqr * 128 = 0.000228333
sqr * sqr * sqr * 64 = 0.0000001524821
les 4 résultats précédents + 29 = 1053.00006 et ça, / 1053 = 1.00000000.... , on n'est pas bon, :P
Une idée ?
Donc, quand tu écris "qui doit vérifier", il faut que je lise, que je comprenne "dont le boulot va être de faire ..."
Mais je ne sais pas à quoi ça peut bien me servir, hélas …
1°) Tu n'a pas compris: ce sont les fonctions citées qui doivent présenter certaines propriétés, et tu n'es pas une fonction. :D .
On te propose un ensemble de fonctions, qui vérifient à priori (sauf erreur de donnée)
G(0) = 1 et G(2*Pi/3) = 0 .
C'était pour t'aider à te familiariser avec ces objets que je rappelais leurs propriétés.
Les relations sont exactes; c'est évident dans le cas de (t) nul, et aussi pour la valeur suivante pour laquelle on a:
Sint = 31/2/2 ; Sint2 = (31/2/2)2 = 3/4 ; Sint4 = (3/4)2 = 9/16 ; Sint6 = (3/4)3 = 27/64 ;
w = (-1024/2 + 512*3/4 +128*9/16 + 64*27/64 + 29)/1053 = (-512 + 384 + 72 + 27 + 29)/1053 = 0;
2°) Les écarts observés doivent rester de l'ordre de la précision assurée par le processeur ("epsilon machine"= 2-63 ~ 1E-19 pour le Pascal), soit 18 ou 19 chiffres (en tenant compte du cumul des arrondis).
C'est donc gâcher le calcul que de se limiter timidement, comme tu l'as fait, à 5 ou 6 chiffres significatifs.
Il fallait prendre soit les relations rigoureuses (voir plus haut), soit sin(120°) ~ 0,8660254037844386468 .
Ma calculatrice, qui travaille sur 14 chiffres, donne
W1 = W2 = W3 = 0 mais W4 = -1.5E-14 , ce qui reste cependant tout à fait acceptable.
Citation:
Envoyé par
Jipété
... Et qu'est-ce qu'on fait de ces 3 corrections pifométriques ?
Code:
1
2
3
4
5
| case k of
1: r:=round(fx_jpt(Phi - Alpha, courbe) * 0.95);
2: g:=round(fx_jpt(Phi - Alpha, courbe) * 0.9);
3: b:=round(fx_jpt(Phi - Alpha, courbe) * 0.85);
end; |
Aucun avis, ces variantes relèvent d'un choix personnel.
L'idée d'un palette dont les nuances dépendent de 3 paramètres pourrait être étudiée, mais cela fait une digression supplémentaire qu'il vaudrait mieux étudier sur un autre forum; et les fonctions à plateau employées ici me paraissent peu adaptées.
Citation:
Envoyé par
Jipété
C'est une suite de fonctions quasi-constantes au voisinage de l'origine, à l'ordre (2n) près (voir #199)
Ce sont des développements à l'ordre 0, 2, 4, 6 (d'après le plus fort exposant du terme en sintn).
PS: certaines de tes palettes apparaissent contaminées par des stries verticales: n'aurais-tu pas encore logé un tableau de 24 couleurs à l'intérieur de ton algorithme ? Cela n'aurait ici aucune raison d'être !
Passer d'un rendu RGB par calculs à un rendu RYB par une table
Citation:
Envoyé par
Jipété
... Parce que sinon, dans trois mois on est encore là, sans voir le bout du tunnel, or j'aimerais bien faire un peu avancer le RYB en cercle ! ...
Tu as toi-même orienté l'échange vers les dégradés (noir/couleur/blanc), puis vers la palette complète (RVB) (168)- le fil commun étant l'évitement de raies anormalement brillantes. Je trouvais le chemin un peu long, mais instructif.
Citation:
Envoyé par
Jipété
... Là, je suis en train de me battre avec ta matrice qui, si elle fonctionne bien (je vais conserver la fonction "1", la plus simple), est épouvantablement lente à la peinture des pixels ...
La fonction F1 produit les couleurs intermédiaires les plus moches, et ne donne pas l'orangé que tu recherchais !
Tu devrais garder l'une des deux fonctions suivantes (F2 ou F3).
La lenteur de l'exécution, dont tu as déjà parlé, m'intrigue un peu ... Comment Free Pascal et Lazarus peuvent-ils apparaître aussi poussifs ? Tu devrais en parler à des intervenants qui connaissent bien ces logiciels.
2 pièce(s) jointe(s)
Passer d'un rendu RGB par calculs à un rendu RYB par une table
Citation:
Envoyé par
Jipété
... Et entre F1 et F2 on ne pourrait pas en glisser une, maintenant que ma mécanique est super bien rodée, juste pour voir ? ...
Non malheureusement, car il n'y a pas de nombre pair entre (2) et (4):
F1(t) ~ 1 - K1*t2
F2(t) ~ 1 - K2*t4
Je te laisse admirer les délais d'exécution dans la barre de titre, 20 fois plus vite que l'ancienne méthode, crois-moi que quand tu tiens la souris, ça change la vie !
Citation:
Envoyé par
Jipété
... Bon, tout ça grâce à toi ...
Ravi que cela ait pu t'apporter quelque chose. Tu m'as fait découvrir la soustraction entre deux images bitmap, et conduit à écrire de nouveaux codes (qui n'ont pas tous été postés sur le forum).
Un doute horrible persiste: toutes les palettes présentent des stries verticales :weird:
Est-ce résultat d'une hallucination, ou aurais-tu inséré dans ton algorithme le tableau des 24 couleurs ? Les fonctions dont tu disposes ici le rendent inutile, et les discontinuités de teinte (que l'oeil perçoit toujours) abîment la palette.
... Et en y regardant de près, il y a des détails vraiment compromettants:
3 pièce(s) jointe(s)
Passer d'un rendu RGB par calculs à un rendu RYB par une table
Citation:
Envoyé par
Jipété
... Donc je te rassure, les 4 images indépendantes sont parfaites ...
Il n'y a que la foi qui sauve ...
Citation:
Envoyé par
Jipété
... Comme je l'avais répété au moins 255 fois, j'ai eu peur d'un débordement de byte et ne l'ai donc pas dit cette fois-ci : ces défauts sont liés à la compression gif, assez violente en termes de destruction des originaux ...
J'avais déjà constaté que certains procédés de compression altèrent la qualité des couleurs, mais de là à inverser l'ordre de luminosité des bandes ...
Et ne consentant à croire qu'après avoir vu, comme l'apôtre Thomas, j'ai créé pour comparaison les versions png, gif et jpg du même original au format Bitmap:
# PNG
Pièce jointe 475324
# JPG
Pièce jointe 475317
# GIF
Pièce jointe 475320
Aucune trace des précédentes dégradations. J'ai l'impression que tu lances un processus inutilement lourd et compliqué, que tu maîtrises mal, ou qu'il intervient une ancienne procédure que tu n'as pas mise à jour.
Citation:
Envoyé par
Jipété
... 'fin bon, si ce n'est pas possible, on ne va pas encore se prendre la tête, on l'a assez fait comme ça. :mouarf:
Il y a une autre possibilité, mais qui n'est pas encore au point ...
Citation:
Envoyé par
Jipété
... et après, le passage en RYB ...
Là aussi, pas de promesse inconsidérée ... On en entend suffisamment à la télé :D
1 pièce(s) jointe(s)
Passer d'un rendu RGB par calculs à un rendu RYB par une table
Mais non, il ne manque aucune donnée ! Tu confonds les fonctions utilisées, fonctions réelles de variables réelles définissant la répartition des couleurs dans le plan, avec la représentation de leur graphe par un nombre fini de pixels ... En multipliant le nombre de points par deux ou par trois, tu obtiendrais une représentation quasi-continue.
J'ai déjà signalé (#139) la séparation qui doit intervenir entre l'objet mathématique étudié, défini par des fonctions sur un domaine fixe, et l'image que l'on veut en donner, et dont les dimensions sont arbitraires.
Voir les deux images quasiment identiques du même objet, de dimensions 400x400 et 401x401.
Je ne peux pas poursuivre :D
1 pièce(s) jointe(s)
Passer d'un rendu RGB par calculs à un rendu RYB par une table
Citation:
Envoyé par
Jipété
... Peut-être une piste :
Concernant cette histoire de courbes en pointillés, j'ai l'explication (mais pas la solution).
D'abord une image, qui montre bien ce qui se passe (me suis amusé à cliquer sur les 4 fonctions sans effacer la précédente) :
la loupe permet de bien voir ce que pointe la souris et, oui,
il manque des données !
Alors je suis allé dans la procédure de création de la matrice et j'ai loggé tout ce qui se passait, qui confirme l'image.
Tout petit résumé :
Code:
1
2
3
4
| w: 000 h: 000 r: 255 g: 000 b: 000
...
w: 000 h: 255 r: 255 g: 000 b: 000
w: 001 h: 000 r: 255 g: 003 b: 000 colonne suivante |
et c'est comme ça partout. w(idth) c'est ton Xm et h(eight) ton Ym.
Par exemple, le point montré par le hotspot de la souris est environ à 50,50, donc
Code:
1
2
3
4
5
6
7
| w: 050 h: 049 r: 194 g: 143 b: 000
w: 050 h: 050 r: 194 g: 143 b: 000
w: 050 h: 051 r: 194 g: 143 b: 000
...
w: 051 h: 049 r: 192 g: 146 b: 000
w: 051 h: 050 r: 192 g: 146 b: 000
w: 051 h: 051 r: 192 g: 146 b: 000 |
et on voit bien que le rouge perd 2 et que le vert gagne 3, :koi:
Il faut savoir que les valeurs r,g,b sont utilisées comme ordonnées pour colorier les points des courbes ...
Et il n'y a pas de
Trunc !
... mais ça n'explique pas pourquoi il manque des données … :P
Les pointillés n'ont rien de gênant, ni d'inesthétique: les graphes obtenus représentent correctement les variations conjointes des fonctions étudiées.
Leur présence vient du couplage du tracé des points des 3 courbes avec celui des traits verticaux constituant la palette, et de l'exécution de la boucle
Code:
FOR x:= 0 TO (Largeur - 1) DO ...
L'inconvénient du procédé est de conduire à une densité linéïque de points variable, d'autant plus faible que la pente moyenne de la portion de graphe envisagée est plus forte: d = (1 + p2)-1/2 .
Par exemple dans le cas de ton exemple, d = 0.365 : elle est par conséquent trois fois plus faible que sur un segment horizontal;
Pour obtenir une représentation quasi continue des courbes, il eût suffi de programmer une boucle au moins 3 fois plus longue:
Code:
1
2
3
4
5
6
| CONST F = 3; // ou 5,7 ... mais pas un nombre pair !
FOR j:= 0 TO (F*Largeur - 1) DO
BEGIN
<Tracé des points des 3 courbes>
IF (j MOD F=0) THEN <Tracé du trait vertical de la palette>
END; |
Les données ne sont donc en rien lacunaires: c'est le traitement graphique qui est en cause, et que l'on peut modifier.
Et l'argument selon lequel la matrice est trop petite ne tient pas:
Citation:
Envoyé par
Jipété
... parce que quand je fais cracher dans un log les données au fur et à mesure qu'elles sont générées par tes fonctions, il en manque !
Mais la raison est très simple, ta matrice est trop petite ...
Une matrice plus grande, mais de même rapport (H/L), montrerait les mêmes dentelles.
PS: Au fait, par quelles instructions consultes-tu les journaux (les logs, c'est bien cela ?) et retrouves-tu l'ensemble des valeurs affectées aux variables (w, h ... etc) ?
