Discussion :

[Jipété]

Et donc voilà le rendu avec autant de points que nécessaire grâce à une matrice 1536x256 :



Et je me suis même permis le luxe d'éclaircir le bleu de la courbe sinusoïdale, comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
  for w := 0 to WIDTH_IMGS do begin
    ColorToRGB(MaLN[w,0], r,g,b);
    with bmpC.RawImage do begin
      rowC := pRGBquad(GetLineStart(255-b));//et pas 256-x sinon plantage avec F2-3-4
      rowC[w].rgbRed     :=063; // deux lignes en plus pour
      rowC[w].rgbGreen   :=127; // illuminer les points bleus
      rowC[w].rgbBlue    :=255;
      rowC := pRGBquad(GetLineStart(255-g));// recouvre le bleu
      rowC[w].rgbGreen   :=255;
      rowC := pRGBquad(GetLineStart(255-r));// rouge en bas recouvre les deux autres
      rowC[w].rgbRed     :=255;
      rowC := pRGBquad(GetLineStart(255));// ligne tout en bas de l'image
      rowC[w].rgbRed     :=0; // remplie avec les traits horizontaux, très moches
      rowC[w].rgbGreen   :=0;
      rowC[w].rgbBlue    :=0;
      rowC[w].rgbReserved:=255;
    end;
  end;

Bientôt le RYB…

[wiwaxia]

... Tu postes ça (que je ne comprends pas trop) :
W: Non. Les dimensions de la matrice et de l'image sont indépendantes de la subdivision opérée pour le calcul; pour chaque couleur, tu as 3 fois plus de points à porter que de barres verticales dans la palette.

Je te proposais une variante du code qui, au lieu de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

FOR x:= 0 TO (Largeur - 1) DO ...

comporterait les instructions:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
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;

Pour chaque valeur du compteur (j) seraient exécutées les actions suivantes:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
j = 0     <Tracé des points rouge , vert, bleu> <Trait vertical d'abscisse x = j MOD 3 = 0 >
j = 1     <Tracé des points rouge , vert, bleu> 
j = 2     <Tracé des points rouge , vert, bleu> 
j = 3     <Tracé des points rouge , vert, bleu> <Trait vertical d'abscisse x = j DIV 3 = 1 >
j = 4     <Tracé des points rouge , vert, bleu> 
j = 5     <Tracé des points rouge , vert, bleu> 
j = 6     <Tracé des points rouge , vert, bleu> <Trait vertical d'abscisse x = j DIV 3 = 2 >
j = 7     <Tracé des points rouge , vert, bleu> 
j = 8     <Tracé des points rouge , vert, bleu> 
j = 9     <Tracé des points rouge , vert, bleu> <Trait vertical d'abscisse x = j DIV 3 = 3 >
j = 10    <Tracé des points rouge , vert, bleu> 
j = 11    <Tracé des points rouge , vert, bleu> 
j = 12    <Tracé des points rouge , vert, bleu> <Trait vertical d'abscisse x = j DIV 3 = 4 >
... etc

... tous les essais RGB que j'ai faits depuis que j'ai le nez là-dessus (2016-17) se sont toujours basés sur du 768 de large (car 1536, faut des grands écrans, en dév ça va, dans la vraie vie c'est tendu).

À l'heure actuelle il y a 360 barres verticales, et il me semble que c'est pour simplifier la vie lors du passage au cercle ...

Pourquoi cette fixation sur une largeur donnée ?
Pourquoi 360 et non pas 400, alors que depuis la Révolution l'angle droit est divisé en 100 grades, et que l'on trouve dans la librairie Pascal les fonctions GradToRad(.) et RadToGrad(.) ?
Pourquoi s'encombrer d'une matrice à 1536 colonnes, alors que se limiter à 600 serait un compromis simple et raisonnable ? Les règles de trois ne sont-elles pas là pour réaliser les ajustements nécessaires ?

... car mine de rien, souviens-toi, j'étais parti d'une map de 24 couleurs, soit 24 barres verticales et ma foi, ça fonctionnait ...

De deux choses l'une: ou l'on regarde les fonctions couleur et discute de leurs éventuelles variantes - et tu ranges alors ta liste de 24 couleurs au placard,
ou bien tu t'en tiens à cette liste (option parfaitement légitime) et la présente discussion n'a plus d'objet.

Simplement l'une des deux options est en trop: les palettes découlent
- soit de la donnée de 3 fonctions couleur { R(x), V(x), B(x) },
- soit d'une liste de (N) couleurs que l'on peut exploiter d'une manière appropriée,
mais pas des deux à la fois !

... je suppose qu'on pourrait envisager de démarrer à 3 barres, une rouge une verte et une bleue et demander (gentiment !) aux fonctions de gradient de faire le boulot.

Ne s'agirait-il pas de ces gadgets qui viennent sporadiquement saloper tes palettes ? Tu as éludé plusieurs fois la question, ou tu t'es défaussé sur GIF, qui a bon dos ! #211
On n'a pas besoin de telles fonctions quand on peut calculer les couleurs locales en tout point !

Le problème de fond, c'est que l'algorithme dont on discute est incorporé à un programme meccano (comme tu l'a dit toi-même) comportant tout un lot d'options personnelles ou disponibles dans Free Pascal/Lazarus, dont tu ne parles pas (sans doute parce que tu les trouves évidentes ou indispensables), et qui se révèlent inutiles ou dommageables.
Le gros ennui est cela débouche sur des surprises, qui égarent la discussion dans tous les sens et amènent un lot croissant de nouvelles questions.
À ce rythme, je ne peux plus suivre. Et l'échange en fait aussi les frais, parce qu'il n' a pas été possible d'exprimer un début de réponse sur d'autres questions évoquées comme celle de la palette RJB.

[Jipété]

j'ai viré la matrice et j'utilise comme récepteur des calculs des fonctions un TBitmap, je commence à maîtriser le bestiau, et je vais m'en servir ensuite comme source pour l'affichage du dégradé de gauche (avec un autre bitmap), des courbes dessous (encore un), du dégradé blanc->couleur->noir non visible mais utilisant quand même un 3^e bitmap de travail, et enfin un 4^e pour dessiner le cercle, à partir du précédent.

Bien sûr j'ai suivi ma petite idée, on va voir pourquoi juste après ça :



L'image que vous voyez est une copie d'écran réduite au tiers (640 de large) du programme passé en plein écran avec toute la partie droite qui se redessine automatiquement (pour une largeur d'écran de 1920 px) et le boulot est fait, sur ma vieille machine de 10 ans d'âge et encore en 32 bits, en à peine plus d'une demi-seconde (53x msec).

On va dire que ça va.


Pour le reste, j'ai remarqué que tu avais mal réagi sur le fait que je parlais de la map, mais j'en parlais juste comme exemple de conteneur de données, pas plus.

Sinon, je persiste et signe pour dire que puisque de toute façon, les calculs finaux seront faits avec des entiers (par exemple, tous les panneaux d'adaptation [non visibles mais bien présents] de la partie droite de l'image ci-dessus sont pilotés, en termes de tailles, par des entiers -- pareil pour la hauteur et la largeur des courbes sinusoïdales), pourquoi se prendre la tête avec des valeurs comme ci ou comme ça, en simple ou double précision ou même quadruple avec 32 chiffres après la virgule si ça te chante, de toute façon ça va être raboté.

Le seul endroit où elles sont admissibles, pour moi, c'est lors du calcul des teintes et dans le traitement du cercle.

Mais pour la répartition des teintes, puisqu'on sait qu'on en aura 393 216 à caser dans une boîte rectangulaire, alors autant d'entrée de jeu fabriquer la dite boîte aux dimensions qui vont bien, les teintes y seront à l'aise et ça évitera de se prendre la tête avec des calculs dont les résultats à virgule, plus tard, ne serviront à rien.

Pourquoi s'encombrer d'une matrice à 1536 colonnes, alors que se limiter à 600 serait un compromis simple et raisonnable ? Les règles de trois ne sont-elles pas là pour réaliser les ajustements nécessaires ?

Parce que 1536 / 600 = 2,56, parfaitement incompatible avec une saine répartition des pixels dans une surface d'affichage. Tu m'aurais dit 768 ou 512, c'était jouable (768 c'est l'un de mes premiers progs).
Ici on a 360 à cause des cercles et des fonctions sinusoïdales, je viens de faire un essai avec 384, qui serait plus conforme (384 x 4 = 1536), ça fonctionne tout autant, un poil plus vite peut-être.

Simplement l'une des deux options est en trop: les palettes découlent
- soit de la donnée de 3 fonctions couleur { R(x), V(x), B(x) },
- soit d'une liste de (N) couleurs que l'on peut exploiter d'une manière appropriée,
mais pas des deux à la fois !

J'ai basculé vers les fonctions, il n'empêche que pour faire afficher le résultat des calculs des fonctions avec plein de chiffres après la virgule, tous plus précis les uns que les autres, il va falloir les raboter et comme à l'armée, je ne veux voir qu'une seule tête, .

tu t'es défaussé sur GIF, qui a bon dos ! #211

Là je ne suis pas content du tout, j'ai bien montré la différence dans une copie d'écran en bas de page, qui affiche un png parfaitement correct en haut et le même fichier une fois passé à la moulinette de génération de gif, qui le perturbe salement. Et je n'ai aucun contrôle sur les paramètres de conversion.

Le problème de fond, c'est que l'algorithme dont on discute est incorporé à un programme meccano (comme tu l'a dit toi-même) comportant tout un lot d'options personnelles ou disponibles dans Free Pascal/Lazarus, dont tu ne parles pas (sans doute parce que tu les trouves évidentes ou indispensables), et qui se révèlent inutiles ou dommageables.

Je ne vois pas de quoi tu parles…


Ne m'en veux pas, et on va continuer avec le jaune à la place du vert,
Demain.
Parce que là, j'en ai un peu assez, et j'ai encore du rangement à faire.

EDIT : j'ai passé la création du bitmap source (la "matrice") du mode matrice en x et y au mode scanline et accès par pointeurs, résultat un bête run tombe à environ 150 msec et le passage en plein écran à moins de 400.

[anapurna]

salut

quelque soit la façon dont tu prend le problème il va y avoir un moment ou cela coince
car les paramètres les échelles et les origines sont différentes

pour moi la meilleur des représentation du RGB est un cube de 255*255*255 soit 16581375 couleur possible

le cercle pose forcement une contrainte supplémentaire est une perte de nuance possible pour que tu puissent afficher toutes les nuance de ce CUBE il te faut un rayon d'environs 2298 pixels
car l'aire d'un cercle est PI*r^2
pour être exacte il te faudrait un rayon de 2297,3932160213100000000 ce que tu ne peut pas faire a l’écran

Pour les courbes : 255 de haut et 65025 pixel de long ce qui nous fait pour chaque courbe de couleur une base de 43350 ((65025/3)*2) pixel
plus tu réduit ses chiffres plus l'affichage seras moins "vrai"

depuis le début ce qui a été répété,il est important de différencier l'affichage du calcul

[Jipété]

quelque soit la façon dont tu prends le problème il va y avoir un moment où cela coince
car les paramètres, les échelles et les origines sont différentes

À qui parles-tu ? À wiwaxia ? À moi ?
On ne sait pas…

pour moi la meilleure des représentations du RGB est un cube de 255*255*255 soit 16581375 couleur possible

Faux. 256 possibilités par primaire, soit 256³ pour les 3, soit le classique 16 777 216 qu'on retrouve partout dans la littérature.

Et comment afficher un cube sur un écran plat ? Autant le mettre à plat tout de suite, comme avec les courbes droites.

(lire 256 512 768 1024 1280 1536)

il est important de différencier l'affichage du calcul

On est bien d'accord. La discussion porte surtout sur quoi afficher et pas trop sur comment.

[wiwaxia]

@ anapurna
Re-bonjour,

Tu mets le doigt sur deux faits essentiels:

... depuis le début ce qui a été répété, il est important de différencier l'affichage du calcul

En effet, tous les calculs intermédiaires doivent être faits à l'aide de réels exclusivement; peu importe leur format, des Single peuvent très bien suffire, et le recours à une précision de 32 chiffres serait franchement extravagant.
Le format Extended a été employé ici en partie par habitude, mais aussi à titre exploratoire, dans le cas de fonctions très proches de l'unité sur une partie de leur domaine.

Mais ce qui est en cause, c'est:
a) la dérive numérique résultant de l'intervention d'arrondis en interne, approximations qui n'ont aucune raison d'être et introduisent des écarts généralement faibles mais incontrôlables;
b) la possibilité d'adapter ce que l'on veut représenter à tout format d'image, et de se libérer du fétichisme arithmétique qui consiste à privilégier à tout prix des valeurs comme 360, ou l'un de ses multiples.

... quelle que soit la façon dont tu prends le problème il va y avoir un moment où cela coince car les paramètres les échelles et les origines sont différentes

pour moi la meilleur des représentation du RGB est un cube de 255*255*255 soit 16581375 couleur possible

le cercle pose forcément une contrainte supplémentaire est une perte de nuance possible pour que tu puissent afficher toutes les nuance de ce CUBE il te faut un rayon d'environs 2298 pixels ...

Tu as pressenti la difficulté de mettre en correspondance chaque point d'un volume (le cube de couleurs) avec celui d'une surface (l'image que l'on voudrait en donner): il est impossible de disposer les 256³ pixels sur un plan, en respectant l'évolution des teintes entre chaque point et ses plus proches voisins.
On pourrait d'ailleurs envisager un problème de même nature, mais numériquement accessible: (255) étant un multiple de (5), comment disposer dans une image rectangulaire ou carrée les 52³ = 140608 pixels de la forme (5*i, 5*j, 5*k) ? Il existe probablement plusieurs solutions, avec des effets de couleur sûrement inattendus.

Tout palette de dimension (1) ou (2) correspond à un graphe généralement situé à la surface du cube, ou une portion de cette dernière.
Le cercle chromatique complet résulte d'une bijection entre l'intérieur d'un cercle, et la surface du cube privée de l'origine.

On pourrait envisager une infinité de cercles chromatiques , incluant des couleurs moins fréquentes comme le gris ou le noir, à condition d'opérer sur un domaine sphérique de couleurs centré à l'origine, au lieu du cube.

[Jipété]

b) la possibilité d'adapter ce que l'on veut représenter à tout format d'image, et de se libérer du fétichisme arithmétique qui consiste à privilégier à tout prix des valeurs comme 360, ou l'un de ses multiples.

En ce qui me concerne, je privilégie des valeurs intelligentes histoire de speeder les calculs et c'est tout, mais sinon, j'ai bien laissé tes fonctions calculer en réels, juste qu'avec ma combine d'avoir une matrice de 1536, les règles de 3 en cas de tailles différentes pour l'affichage se font toutes seules par des appels système, et par exemple pour faire ce test j'ai ouvert le prog dans l'EDI, j'ai changé largeur et hauteur de l'image à 377 x 213 et c'est tout, je n'ai strictement touché à rien d'autre, j'ai appuyé sur F9 pour faire exécuter et voilà le résultat, simplement parfait :

[wiwaxia]

Copie d'écran au format GIF de trois versions (PNG, JPG, GIF) de la même image Bitmap (#211]

J'ai du mal à saisir la détérioration violente des couleurs originales résultant de la compression GIF (#210).

[Jipété]

Bonjour,

J'ai du mal à saisir la détérioration violente des couleurs originales résultant de la compression GIF (#210).

elle est pourtant bien connue, lire + bas…

Histoire de boucler cette affaire, quand j'ai vu arriver ton post, j'ai tout lâché et ai lancé mon Gimp pour faire une copie d'écran (mode "sélectionner une région") du bas du premier dégradé en remontant jusqu'au mot "Copie" en rouge.

L'image qui s'est affichée dans Gimp, sans rien toucher à un quelconque paramètre, je l'ai exportée une première fois au format png et on en a le résultat en haut, puis une seconde fois en gif, avec le résultat foireux (et bien visible dans les bleus) en bas.



Alors oui, un mauvais ouvrier a de mauvais outils, mais si c'était l'inverse ? Si les mauvais outils généraient de mauvais résultats laissant penser qu'il s'agit du mauvais travail d'un mauvais ouvrier ?

Ce que je sais du format gif, c'est qu'il n'est pas capable, par design, de rendre les 16 millions de couleurs :

Une image GIF peut contenir de 2 à 256 couleurs (2, 4, 8, 16, 32, 64, 128 ou 256) parmi 16.7 millions dans sa palette.

Alors je ne sais pas par quel miracle ça tombe en marche chez toi, mais àmha tu devrais aller brûler un cierge.

EDIT :
je me suis souvenu qu'un vieux shareware de PaintShopPro (sous XP) avait une option de comptage des couleurs, alors hop !, ni une ni deux, les fichiers dans l'outil, et le résultat est sans appel :

[wiwaxia]

Voici pour comparaison les palettes RVB obtenues à l'aides des fonctions de couleur (F1, F2, F3, F4), et de la fonction basique linéaire par morceaux (FL) - du bas vers le haut pour les palettes à une dimension, et du bord vers le centre dans le cas du cercle chromatique - les aires correspondantes sont égales, dans tous les cas.



Si pour les 4 premières les zones des couleurs primaires tendent à rétrécir, celles des couleurs secondaires (jaune, cyan, magenta) tendent à s'étaler - trop peut-être dans le cas de F3 et F4.
Même tendance observée dans le cas des 3 palettes monochromes représentées ci-dessous.



Répartition opposée par contre dans le dernier cas, où la forte concentration des couleurs secondaires redonne les raies brillantes que l'on cherchait à éviter.



Il est à partir de là possible de rechercher des fonctions plus appropriées, à partir des résultats obtenus.

[Jipété]

Voici pour comparaison les palettes RVB obtenues à l'aides des fonctions de couleur (F1, F2, F3, F4), et de la fonction basique linéaire par morceaux (FL) - du bas vers le haut pour les palettes à une dimension, et du bord vers le centre dans le cas du cercle chromatique - les aires correspondantes sont égales, dans tous les cas.

Si on n'a pas les mêmes bases, on ne va pas y arriver, c'est sûr !

J'ai comparé mes sorties avec les tiennes, il m'a fallu zapper celle d'en haut pour construire cette sortie :

et à partir de là on est conformes.

La mienne est construite, de haut en bas, avec F4 F3 F2 et F1, soit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
    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;

Ça, je l'ai publié, en temps et en heure, et voilà que je découvre maintenant une FL dont je n'ai pas la formule…

[wiwaxia]

Si on n'a pas les mêmes bases, on ne va pas y arriver, c'est sûr ! ...

Permuter les noms des fonctions n'est peut-être pas le meilleur moyen de faciliter les échanges ...

... et voilà que je découvre maintenant une FL dont je n'ai pas la formule … koi:

La dernière fonction, dixit wiwaxia

Voici pour comparaison les palettes RVB obtenues à l'aides des fonctions de couleur (F1, F2, F3, F4), et de la fonction basique linéaire par morceaux (FL) ...

est celle qu'utilise tout un chacun lorsqu'il a besoin d'une palette, et dont tu as reproduit cinq fois le graphe au cours des précédents échanges:

#114

#167

#213

#220

#225

J'étais en froit de penser que tu savais de quoi il retourne ...

[Jipété]

J'étais en droit de penser que tu savais de quoi il retourne ...

Jolies images, certes, mais toutes réalisées depuis des maps…

Je me doutais que c'était une histoire comme ça, et depuis ce matin j'étudie la formule "dents de scie" ou plutôt, j'essaye de la mettre en œuvre et si c'est facile avec une map, c'est une autre paire de manche quand il s'agit de l'insérer dans CalcMatrIm (qui n'a pas changé de nom, )

Pour le moment j'en suis là (juste le nécessaire) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
VAR
  ...
  Pi_sur_La: Real;
BEGIN
  Pi_sur_La := Pi / La;
  La1:= La - 1; Ha1:= Ha - 1;
 
  bmpS.BeginUpdate();
  FOR Ym:= 0 TO Ha1 DO begin
    rowS := pRGBquad(bmpS.RawImage.GetLineStart(Ym));
    FOR Xm:= 0 TO La1 DO BEGIN
      if fx = 5 then begin // demande de courbe linéaire 
      Phi := Pi_sur_La * Xm;
      FOR k := 1 TO 3 DO
        case k of
          1: r:=fx_jpt(Phi, fx);
//          2: g:=fx_jpt(Phi - Pi2sur3, fx);
  //        3: b:=fx_jpt(Phi - D_Pi2sur3, fx);
          2: g:=fx_jpt(Phi - D_Pi, fx);
          3: b:=fx_jpt(Phi - Pi, fx);
        end;
      end
      else begin // les 4 autres F1..F4
        Phi := (D_Pi * Xm) / La;
        FOR k := 1 TO 3 DO
          case k of
            1: r:=fx_jpt(Phi, fx);
            2: g:=fx_jpt(Phi - Pi2sur3, fx);
            3: b:=fx_jpt(Phi - D_Pi2sur3, fx);
          end;
      end;

et ça coince au niveau des courbes : je n'arrive pas à écarter correctement les 3 couleurs, un exemple :



Alors j'essaye, tout et n'importe quoi, +Pi ou -Pi, x 2 ou x 2 / 3, bref, ça finira bien par tomber en marche.

EDIT :
Tiens, ça va te plaire, trouvé à l'instant au CNRS, et je l'ai passée au colorpicker, le soi-disant vert a plus de bleu que de vert, d'où sa présence ici,

[wiwaxia]

Très belle l'image ... Il intervient probablement la racine cinquième de l'unité dans le plan complexe, en chaque point (x, y) duquel on associe z = x + i*y .

J'ai repris à fond l'expression des fonctions (F1 ... F4) dont le code, hâtivement rédigé, faisait désordre.
Il y a dans la foulée celle de la fonction définie par morceaux (FlinM); si cela peut te faire gagner du temps ...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
 
(*HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
 
 # Utilitaires
 
HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH*)
 
 PROCEDURE IncR(VAR u: Reel; v: Reel);
   VAR w: Reel;
   BEGIN
     w:= u + v; u:= w
   END;
 
 PROCEDURE Norme1_2(u, v: Reel; VAR N1, N2: Reel);
   VAR U2, V2: Reel;
   BEGIN
     U2:= Sqr(u); V2:= Sqr(v); N2:= U2 + V2; N1:= Sqrt(N2)
   END;
 
(*HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
 
 P2 / Calcul de la matrice image
 
F1(x) = (2*Cos(x) + 1)/3
F2(x) = (8*Cos(x) + 4*Sin(x)2 + 1)/9
F3(x) = (128*Cos(x) + 64*Sin(x)2 + 16*Sin(x)4 + 7)/135
F4(t) = (1024*Cos(t) + 512*Sin(t)2 +128*Sin(t)4 + 64*Sin(t)6 + 29)/1053
 
Pour k = (1, 2, 3, 4) on a:
a) Fk(0) = Fk(2*Pi) = 1 ;
b) Fk(2*Pi/3) = Fk(-2*Pi/3) = Fk(4*Pi/3) = 0 .
 
HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH*)
 
 CONST D_Pi = 2 * Pi;    K3sPi = 3 / Pi;
       Pi1s3 = Pi / 3;   Pi5s3 = 5 * Pi1s3;
       Pi2s3 = D_Pi / 3; Pi4s3 = 2 * Pi2s3;
       Pzero: Pixel = (0, 0, 0);
 
(*HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
 
HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH*)
 
 FUNCTION FlinM(t: Reel): Byte;         // Fonction lin‚aire par morceaux
   VAR s, u, w: Reel; Test15, Test24: Bool;
   BEGIN
     s:= Abs(t);
     Test15:= ((s<Pi1s3) OR (s>Pi5s3));
     Test24:= ((Pi2s3<s) AND (s<Pi4s3));
     IF Test15 THEN w:= 1
               ELSE IF Test24 THEN w:= 0
                              ELSE IF (t<Pi) THEN BEGIN
                                                    u:= Pi2s3 - s;
                                                    w:= K3sPi * u
                                                  END
                                             ELSE BEGIN
                                                    u:= s - Pi4s3;
                                                    w:= K3sPi * u
                                                  END;
     Result:= Round(255 * w)
   END;
 
// F4(t) = (1024*Cos(t) + 512*Sin(t)2 +128*Sin(t)4 + 64*Sin(t)6 + 29)/1053
 
 FUNCTION F4(t: Reel): Byte;
   VAR Ct, St, St2, St4, St6, s, w: Reel;
   BEGIN
     SinCos(t, St, Ct);
     IF (Ct>-0.5) THEN BEGIN
                         St2:= Sqr(St);      St4:= Sqr(St2); St6:= St2 * St4;
                         s:= 29;             IncR(s,  64 * St6);
                         IncR(s, 128 * St4); IncR(s, 512 * St2);
                         IncR(s, 1024 * Ct); w:= s / 1053
                       END
                  ELSE w:= 0;
     Result:= Round(255 * w)
   END;
 
// F3(x) = (128*Cos(x) + 64*Sin(x)2 + 16*Sin(x)4 + 7)/135
 
 FUNCTION F3(t: Reel): Byte;
   VAR Ct, St, St2, St4, s, w: Reel;
   BEGIN
     SinCos(t, St, Ct);
     IF (Ct>-0.5) THEN BEGIN
                         St2:= Sqr(St);     St4:= Sqr(St2);
                         s:= 7;             IncR(s, 16 * St4);
                         IncR(s, 64 * St2); IncR(s, 128 * Ct);
                         w:= s / 135
                       END
                  ELSE w:= 0;
     Result:= Round(255 * w)
   END;
 
// F2(x) = (8*Cos(x) + 4*Sin(x)2 + 1)/9
 
 FUNCTION F2(t: Reel): Byte;
   VAR Ct, St, St2, s, w: Reel;
   BEGIN
     SinCos(t, St, Ct);
     IF (Ct>-0.5) THEN BEGIN
                         St2:= Sqr(St);
                         s:= 1;           IncR(s, 4 * St2);
                         IncR(s, 8 * Ct); w:= s / 9
                       END
                  ELSE w:= 0;
     Result:= Round(255 * w)
   END;
 
// F1(x) = (2*Cos(x) + 1)/3
 
 FUNCTION F1(t: Reel): Byte;
   VAR Ct, St, s, w: Reel;
   BEGIN
     SinCos(t, St, Ct);
     IF (Ct>-0.5) THEN BEGIN
                         s:= 1; IncR(s, 2 * Ct);
                         w:= s / 3
                       END
                  ELSE w:= 0;
     Result:= Round(255 * w)
   END;

[Jipété]

Il intervient probablement la racine cinquième de l'unité dans le plan complexe, en chaque point (x, y) duquel on associe z = x + i*y .

Oh ben surement ! Le gamin de 5 ans en est tellement satisfait qu'il est parti se suicider à coups de figues molles, comme on dit en Corse,

J'ai repris à fond l'expression des fonctions (F1 ... F4) dont le code, hâtivement rédigé, faisait désordre.

Et cela m'aura obligé à créer une nouvelle unité pour y ranger tout ça dedans.
Bah, c'est pas plus mal, ça va alléger l'unité principale.

J'avais écrit des trucs, mais je m'étais fait un nœud dans la tête et j'ai trouvé, alors j'ai tout viré j'avais trop honte,

Merci,

[Jipété]

Alors quand même, testons cette fonction linéaire avec morceaux, et ça donne ça :



Peut-être pas la plus belle, mais en tout ça la plus rapide : 100 msec de moins que ses copines.

Bon, y a pas encore d'images RYB, même si l'accès est possible (et testé), parce que pour le moment c'est passablement moche…
Faudra que je compare avec mes vieux premiers essais.

Et sinon, j'ai retrouvé ça au fond d'un disque, provenance totalement inconnue :



Bon dimanche, si on ne se reparle pas d'ici là.

[Jipété]

Ola !

Hier, quand tu as posté ta refonte des fonctions, je me suis tellement concentré là-dessus que j'en ai zappé ce sur quoi j'étais en train de bosser : la même idée que toi, que tu as réalisée avec tes "morceaux" quand moi, j'avais fait une recherche sur "équation dent de scie" qui m'a amené sur cette page (cliquer sur Solution puis encore sur le solution qui s'affiche pour accéder au pdf d'une page) où j'ai découvert l’équation f(x) = arcsin(sinπx) / π qui m'a d'abord provoqué des sueurs froides car écrit comme ça, pour moi il y a deux options, du coup : arcsin(sin(pi)*x) / pi ou arcsin(sin(pi*x)) / pi.

Bah, je me suis dit que ça serait vite testé, si c'est pas l'une c'est l'autre et en effet c'est la seconde version qui serait correcte.

Je le mets au conditionnel car une fois tout ça mis en place,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
function normalize(n: Real): Real; 
begin
  n := n + 0.5; // passer de -0.5..+0.5 à 0..1
  n := n * 3;   // pour pouvoir raboter le haut et le bas
  if n > 2 then n := 2; // rabotage du haut
  if n < 1 then n := 1; // rabotage du bas
  Result := n - 1; // passer de 1..2 à 0..1
end;
 
// JP(t) = ArcSin(Sin(Pi*t)) / Pi
FUNCTION JP(t: Real): Byte;          // Fonction linéaire 
  BEGIN
    Result:= Round(255 * normalize(arcsin(sin(pi*t)) / pi))
  END;

et l'appel dans CalcMatrIm :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
      if fx = 5 then begin // détection de la fonction JP
        Phi := Pi_sur_La * Xm;
        FOR k := 1 TO 3 DO
          case k of 
            1: r:=fx_jpt(Phi + (Pi/6), fx);
            2: g:=fx_jpt(Phi + (Pi/6) - 2/3, fx);
            3: b:=fx_jpt(Phi + (Pi/6) + 2/3, fx);
          end;
      end
      else begin  // fonctions WWX (fx 0..4 pour F1..4 + FLinM)
        Phi := (D_Pi * Xm) / La;
        FOR k := 1 TO 3 DO
          case k of
            1: r:=fx_jpt(Phi, fx);
            2: g:=fx_jpt(Phi - Pi2sur3, fx);
            3: b:=fx_jpt(Phi - D_Pi2sur3, fx);
          end;
      end;

je n'arrive pas exactement au même résultat que toi :
voici le magnifique rendu de ta fonction par morceaux,


et voilà à quoi j'arrive avec ma fonction trigonométrique


Tout est correct mais je ne suis pas proportionnel à la fenêtre, comme toi.

Tu verrais ce qu'il faut retoucher dans

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
1: r:=fx_jpt(Phi + (Pi/6), fx);
2: g:=fx_jpt(Phi + (Pi/6) - 2/3, fx);
3: b:=fx_jpt(Phi + (Pi/6) + 2/3, fx);

pour arriver au but ?


Une autre question : pourquoi, dans ta nouvelle version des fonctions F1..4 as-tu viré la trigo, remplacée par de l'arithmétique hermétique ?
Merci,

Ah, au passage, ta fonction incR peut se simplifier ainsi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

PROCEDURE IncR(VAR u:Real; v:Real); BEGIN u:= u+v; END;

it works !

[wiwaxia]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
            2: g:=fx_jpt(Phi + (Pi/6) - 2/3, fx);
            3: b:=fx_jpt(Phi + (Pi/6) + 2/3, fx);

Ces instructions sont anormales: il est rare que (Pi) s'ajoute à un rationnel.

Tu devrais avoir une expression du genre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
            2: g:=fx_jpt(Phi + (Pi/6) - 2/3*Pi, fx);
            3: b:=fx_jpt(Phi + (Pi/6) + 2/3*Pi, fx);

Une autre question : pourquoi, dans ta nouvelle version des fonctions F1..4 as-tu viré la trigo, remplacée par de l'arithmétique hermétique ?

L'algorithme appelle les fonctions Cos(.) et Sin(.), quelle que soit la version qui a été donnée; la suite du calcul a été rendue plus systématique.

Ah, au passage, ta fonction incR peut se simplifier ainsi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

PROCEDURE IncR(VAR u:Real; v:Real); BEGIN u:= u+v;END;

Je sais, mais je ne laisse pas au processeur le soin de mémoriser un résultat intermédiaire; et cela ne vaudrait plus la peine d'écrire une procédure aussi courte.
Ce sujet pourrait être longuement discuté.

[Jipété]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
            2: g:=fx_jpt(Phi + (Pi/6) - 2/3, fx);
            3: b:=fx_jpt(Phi + (Pi/6) + 2/3, fx);

Ces instructions sont anormales: il est rare que (Pi) s'ajoute à un rationnel.

Tu devrais avoir une expression du genre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
            2: g:=fx_jpt(Phi + (Pi/6) - 2/3*Pi, fx);
            3: b:=fx_jpt(Phi + (Pi/6) + 2/3*Pi, fx);

Bon, j'ai fait un simple copier/coller de ta formule, comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
            1: r:=fx_jpt(Phi +(Pi/6), fx);
            //2: g:=fx_jpt(Phi +(Pi/6) - 2/3, fx);
            //3: b:=fx_jpt(Phi +(Pi/6) + 2/3, fx);
            2: g:=fx_jpt(Phi + (Pi/6) - 2/3*Pi, fx);
            3: b:=fx_jpt(Phi + (Pi/6) + 2/3*Pi, fx);

et voilà ce que ça donne…

Je sais, mais je ne laisse pas au processeur le soin de mémoriser un résultat intermédiaire; et cela ne vaudrait plus la peine d'écrire une procédure aussi courte.
Ce sujet pourrait être longuement discuté.

Même pas en deux mots ?
Pour assouvir ma curiosité sérieusement titillée, avec ta réponse.

[Jipété]

Un truc qui me démangeait, depuis deux jours, car ces traits brillants sont déprimants (oui, je sais, palette = toutes les couleurs donc, bon...)

Alors comme les dégradés sont obligatoirement compressés (sinon il faudrait une image de 1536 px de large), je me suis bricolé un petit zoom, genre le truc va récupérer la zone de couleurs délimitée en haut par le curseur et va la recopier en bas en l'étirant à sa vraie taille, démonstration :
au clic sur la c-à-c, le panneau avec le curseur et l'image de zoom s'affichent :


curseur à gauche toute (dit-il fort en levant le poing gauche, )


curseur à peu près au centre (pour ne pas prendre de risques, et on voit bien que le violent trait cyan s'est bien estompé)


curseur à droite mais pas complètement (faut pas déc..ner non plus, )


Et voili et voilou, demain la suite du RYB (rjb pour les francophones )