Discussion :

[Jipété]

Bonsoir,

ce soir je ne code rien, je suis vanné.

Juste deux points à propos de ton post :

J'avais supprimé le (b), qui ne donne pas ce que tu attends (cyan au centre, très large, et bordé de bleu à droite).

Super, tu as supprimé un (b) dont je ne sais absolument pas d'où il sort !
EDIT : ok, j'ai compris, tu as supprimé du texte après que j'y aie répondu ! Comment puis-je m'y retrouver dans ce contexte de sables mouvants ?
Et au final tu as supprimé le (b) mais aussi le (a), sauf que tu as conservé son texte mais tu ne le dis pas ! Je ne peux pas m'y retrouver...
'fin bon, il reste translation de (1/2) période, donc égale à (1) à gauche ou à droite; mais ça me fait une belle jambe, je ne sais pas sur quoi il faut jouer pour faire cette translation, je crois l'avoir dit dans mon post de 18h44. /EDIT

Je prenais en exemple une branche montante du graphe ... un dessin livre immédiatement la réponse:
Pièce jointe 224621

Ben non, pas chez moi, car je suis toujours plein de questions, et si je comprends les x et y (indépendamment de l'épouvantable faute d'inattention), je ne sais toujours pas d'où sort ta courbe verte et pourquoi elle a cet aspect, ce profil, plutôt qu'un autre...
C'est ce que je faisais en 4e ou en 3e, je ne sais plus (et j'étais très bon) : le prof nous demandait de dessiner y = 5x² + 3x + 2 et je m'en débrouillais bien, je faisais de très jolies courbes. Là je n'ai pas ce y = ...

Et la question de la poule et de l'œuf est toujours sans réponse : le dégradé à l'origine de la courbe ou la courbe à l'origine du dégradé ?
Quand j'ai une jolie courbe sur l'écran de mon oscillo physique, c'est parce que j'ai accroché sa sonde à un générateur, tu vois ?

[wiwaxia]

1°) J'ai rectifié la réponse quelques minutes après, en m'apercevant que c'était une impasse; et comme tu as dû ouvrir la page du forum dès l'arrivée du courriel, celle-ci ne s'est pas renouvelée, et tu n'a pas été informé de la modification. C'était un mauvais choix, j'aurais dû t'avertir. Désolé.

2°) a) Tu peux garder la fonction telle qu'elle est donnée, avec les 3 relations données dans le précédent post.
Tu t'effraies inutilement du vocabulaire: effectuer une translation d'une demie-période, c'est remplacer F(r) par F(r + Pe/2), soit ici F(r + 1) puisque Pe = 2 . Les décalages précédents (de Pe/3 , soit 2/3) ne t'avaient causé aucun problème.
b) L'autre solution, encore plus brève, consiste changer l'expression de (w) en fonction de (t) par une modification minimale dans locCoef_C(Pilote, t); au lieu de

Code :

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

1
2
3
4
5
6
 
     IF t>1 THEN u:= t - 2
            ELSE IF t<-1 THEN u:= t + 2
                         ELSE u:= t;
     v:= Abs(u); w:= 2 - (3 * v); IF w>1 THEN w:= 1
                                         ELSE IF w<0 THEN w:= 0;

écrire

Code :

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

1
2
3
4
5
6
     IF t>1 THEN u:= t - 2
            ELSE IF t<-1 THEN u:= t + 2
                         ELSE u:= t;
     v:= Abs(u); w:= (3 * v) - 1; IF w>1 THEN w:= 1
                                         ELSE IF w<0 THEN w:= 0;

# J'ai rajouté des précisions dans le message qui suit

3°) L'autre obstacle, c'est le changement de variable découlant du renversement de l'image, au sujet duquel plus j'en dis, moins tu comprends ... Essayons un modèle plus simple (je suis obstiné).
La matrice et l'image sont constituées d'un ensemble de lignes que l'on peut indexer:
a) à partir de la ligne la plus basse: Y_image = 0, 1, 2, 3, ... , 9 (s'il y a en tout 10 lignes);
cet indice représente naturellement la hauteur d'un pixel par rapport au bord inférieur de l'image;
b) à partir le la ligne la plus haute: Y_matrice , qui peut prendre le même ensemble de valeurs;
cet indice représente la distance d'un pixel par rapport au bord supérieur de l'image.

On observera dans une colonne donnée (d'indice x) les valeurs suivantes, qui vérifient: Y_image + Y_matrice = C^te = 9 :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
Yimage          Ymatrice
   9                  0           Première ligne (haut)        
   8                  1                   
   7                  2                   
   6                  3                   
   5                  4                   
   4                  5                   
   3                  6                   
   2                  7                   
   1                  8                   
   0                  9           Dernière ligne (bas)

On repère la position de tout pixel par la valeur du premier indice (Y_image), qu'il appartienne au dégradé ou à l'un des graphes; mais la couleur doit être affectée à l'élément correspondant de la matrice, sur la ligne de rang (Y_matrice); d'où l'instruction décisive de la forme:

Code :

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

Ma[x, 9 - Yimage):= Px

.
Si tu as compris cela, le reste viendra de soi. Les bornes à considérer ne sont que des ajustements secondaires.

[wiwaxia]

Bonjour,

L'image que tu as postée le 07/11/2016 à 18H42

représente correctement (même si sa programmation était à reprendre) le lien entre l'évolution des teintes et la variation des coefficients de couleur dans le cas (g = 1). On y trouve de plus le dégradé (RYGCBMR) que tu recherche.
La fonction de base w = f(t), dont le nouveau code vient d'être donné, est représentée par le graphe rouge; elle est toujours paire (f(-t₁) = f(t₁) et présente encore un palier horizontal centré en (t = 0); mais l'ordonnée de celui-ci est nulle.

Il faut associer les couleurs aux décalages suivants:
Rouge (3) _ _ _ w = f(t) _ _ _ _ _ pas décalage
Vert _ (2) _ _ _ w = f(t - 2/3) _ _ décalage vers la droite de (1/3) de période
Bleu _ (1) _ _ _ w = f(t + 2/3) _ _ décalage vers la gauche de (1/3) de période
... ce qu'on retrouve pratiquement au niveau des instructions déjà examinées:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
PROCEDURE CalcMat_Im01
 ... 
         s:= locCoef_C(Pilote, r);     y:= Round(K1 * s); Ma[x, (H1-y)]:= Cro;
         s:= locCoef_C(Pilote, r - h); y:= Round(K1 * s); Ma[x, (H1-y)]:= Cve;
         s:= locCoef_C(Pilote, r + h); y:= Round(K1 * s); Ma[x, ((H1-y)]:= Cbl;
 ...
PROCEDURE CalcMat_Im02
 ...
           s:= locCoef_C(Pilote, r);        Px[3]:= Round(m * s);
           s:= locCoef_C(Pilote, r - h);    Px[2]:= Round(m * s);
           s:= locCoef_C(Pilote, r + h);    Px[1]:= Round(m * s);
       FOR y:= K1 TO H1 DO Ma[x, H1 - y]:= Px;
 ...

[Jipété]

Salut,

# J'ai rajouté des précisions dans le message qui suit

avec une magnifique faute d'inattention qui m'a failli faire passer l'ordi par la fenêtre, suivi d'un AVC, mais je me suis repris et j'ai réfléchi...

Code pascal :

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

1
2
3
           s:= locCoef_C(Pilote, r);        Px[3]:= Round(m * s);
           s:= locCoef_C(Pilote, r - h);    Px[2]:= Round(m * s);
           s:= locCoef_C(Pilote, r + h);    Px[1]:= Round(m * s);

Code pascal :

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

1
2
3
           s:= locCoef_C(Pilote, r);        Px[1]:= Round(m * s);
           s:= locCoef_C(Pilote, r - h);    Px[2]:= Round(m * s);
           s:= locCoef_C(Pilote, r + h);    Px[3]:= Round(m * s);

et après cette dernière correction, j'ai l'honneur, la joie et le plaisir de t'annoncer que le dégradé et le graphique sont enfin en phase !
Et ce, quel que soit le pilote,
Et avec un magnifique dégradé RYGCBMR, trop top !

Un grand, un énorme merci pour ta patience et ta pédagogie (même si je sais que je serai incapable de la transmettre à quelqu'un d'autre, hélas...), me reste plus qu'à nettoyer mon code, bien le commenter, renommer le plus possible tes t, u, v, w etc. en vrais noms de variables, et mon bonheur sera total !

Ah non, reste un point : tu devais me parler de la lumière visible...
Si ma mémoire est bonne, la principale différence entre nos dégradés et celui de la LV, c'est que nous passons du rouge au jaune quand la LV passe par une étape orange, et nous avons du cyan entre le vert et le bleu quand il me semble qu'il n'existe pas en LV, et où on trouve un violet proche de mais pas identique à notre magenta.

Une idée là-dessus (mais prends ton temps, on n'est pas aux pièces, )
Tiens, je ne sais pas si tu connais, si "non", ton bonheur sera complet, lol !

Bonne journée, merci encore

[wiwaxia]

Là, cela commence à devenir flippant

avec une magnifique faute d'inattention qui m'a failli faire passer l'ordi par la fenêtre, suivi d'un AVC, mais je me suis repris et j'ai réfléchi...

Je ne saurais endosser la responsabilité d'une erreur ayant pu conduire à la défenestration de ton matériel, et à une attaque cérébrale: la séquence donnée

Code :

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

1
2
3
           s:= locCoef_C(Pilote, r);        Px[3]:= Round(m * s);
           s:= locCoef_C(Pilote, r - h);    Px[2]:= Round(m * s);
           s:= locCoef_C(Pilote, r + h);    Px[1]:= Round(m * s);

était intentionnelle, mûrement réfléchie et plusieurs fois vérifiée (d'où le style lourd et répétitif des indications). Et j'ai attendu d'être remis du coup de pompe d'hier pour reprendre les données.

Je ne sais pas ce que tu as fait par ailleurs, et loin de moi l'idée de jouer les trouble-fête; mais s'il n'y a eu qu'une modification partielle, c'est que le programme contient deux erreurs qui se compensent - et d'autant plus facilement que les graphes comportent des segments rectilignes (si g = 1).

Crée une image pour (g = 5), par exemple, en respirant profondément et sans angoisse , et envoie le résultat: je saurai que tu n'es pas pas parti aux urgences, et ton PC se trouve toujours sur ton bureau.
Et bravo si ça marche !

[Jipété]

Je ne sais pas ce que tu as fait par ailleurs, et loin de moi l'idée de jouer les trouble-fête; mais s'il n'y a eu qu'une modification partielle, c'est que le programme contient deux erreurs qui se compensent - et d'autant plus facilement que les graphes comportent des segments rectilignes (si g = 1).

Mais rien !
J'étais en train de me battre avec ton post de cette nuit quand l'autre est arrivé, du coup je l'ai mis en service avec tes deux modifs et celle de la veille v:= Abs(u); w:= (3 * v) - 1; IF w>1 THEN w:= 1 et c'est tout !
J'ai exécuté, j'ai constaté l'inversion de pixels que j'ai remontée ici aussitôt et pas plus !
Tous mes essais suivants sont basés sur l'appel de la procédure où je modifie le n° du pilote et rien d'autre.

Crée une image pour (g = 5), par exemple, en respirant profondément et sans angoisse , et envoie le résultat: je saurai que tu n'es pas pas parti aux urgences, et ton PC se trouve toujours sur ton bureau.
Et bravo si ça marche !

La voilà :



avec son code dans locCoef_C, jamais touché : 5: begin u:= Sqr(1 - w); locCoef_C:= Sqrt(1 - u); end;

[wiwaxia]

Félicitations pour ta ténacité ! La persévérance finit par payer ... et j'étais agacé de ce qu'une jonction ne puisse être complètement établie entre deux programmes, de langages très proches.
Je reprendrai plus tard sur des sujets annexes.

[Jipété]

Félicitations pour ta ténacité ! La persévérance finit par payer ... et j'étais agacé de ce qu'une jonction ne puisse être complètement établie entre deux programmes, de langages très proches.

Merci, mais c'est grâce à toi : me suis dit que vu les efforts que tu déployais, je ne pouvais faire moins que de tenter d'arriver au bout (et c'est vrai que ce matin, avant ton message de vers 10h, j'ai failli jeter l'éponge, mais ce message était la solution )

Ce qui veut dire, au final, que tu valides ma correction des pixels ? Cool !

Je reprendrai plus tard sur des sujets annexes.

You're welcome, et fortement attendu,
D'autant plus que le facteur est passé, et sans ma commande -- j'sais pas c'qu'ils fichent...

Mais relâche cet aprème.

[wiwaxia]

Il intervient finalement, pour la réalisation de dégradés sur les 3 couleurs fondamentales, 2 types de fonctions paires, linéaires par morceaux et utilisées sur le domaine [-1 ; +1] ; le code de ces fonctions (ici notées w = f(t)), ne diffère que par une courte instruction concernant l'équation des parties inclinées:
a) celle pour laquelle f(0) = 0 , et admettant pour équation w = 3*|t| - 1 lorsque (0 < w < 1); le centre du dégradé est alors occupé par une couleur secondaire (jaune, pourpre, cyan);
b) celle pour laquelle f(0) = 1 , et admettant pour équation w = 2 - 3*|t| lorsque (0 < w < 1); on trouve alors au centre l'une des trois couleurs primaires (rouge, vert, bleu).
Il est donc très facile de passer de l'une à l'autre par programmation.
La permutation des indices (r, v, b) permet d'obtenir dans chaque cas l'une des 3! = 6 combinaisons possibles.

J'ai regardé ce que pouvait donner la superposition horizontale de dégradés correspondant à diverses valeurs de (g), comme tu l'avais fait sur quelques exemples; visuellement, le résultat est un peu décevant.

_

Le paramètre (g) est ici fonction exponentielle de (y), et varie de (10^-2) à (10⁺²) du bas vers le haut de l'image; la fonction f(t) est directement reliée à la couleur centrale (vert), et l'on a f(0) = 0 pour la première image, et f(0) = 1 pour la seconde. Le décalage habituel de (+-2/3) est appliqué aux autres couleurs.

On peut aussi chercher à repérer (si elle existe) la valeur de (g) conduisant à la meilleure équirépartition des diverses teintes; dans les images suivantes, (g) dépend linéairement de (y) et varie de (0.5) à (3.5); l'abscisse est divisée en douzièmes de période, et chaque teinte devrait en occuper deux, en moyenne.
a) f(0) = 0 pour le vert:

b) f(0) = 1 pour le vert:

La valeur optimale paraît être de l'ordre de 2.0 - résultat imprécis, en l'absence de frontières nettement discernables.

[Jipété]

Bonjour,

Ouh lala, joli travail !
Je n'en vois absolument plus l'intérêt, en ce qui me concerne, mais joli travail quand même.

--snip-- Il est donc très facile de passer de l'une à l'autre par programmation. --snip--

De mon côté, je fais le ménage, je renomme les variables (tiens ! par quoi pourrais-je bien remplacer "CcG" qui n'est vraiment pas parlant ?), je supprime des longueurs, au détriment de la lisibilité, je te l'accorde, mais je pensais que le compilateur le ferait de lui-même dans notre dos et non, car je me suis rendu compte que je gagnais des millisecondes par ci par là avec ce genre de manips.
Exemple dans coef_C, où l'on trouve v:= Abs(u); w:= (3 * v) - 1; IF w>1 THEN w:= 1 et que j'ai remplacé par w:= (3 * Abs(u)) - 1; IF w>1 THEN w:= 1 : une opération en moins = une milliseconde (à la louche) gagnée !
Et des millisecondes, à notre époque, c'est énorme !

Autre chose qui m'a considérablement surpris : au lieu de déclarer la matrice statique avec taille imposée par la constante, je l'ai déclarée dynamique avec dimensions imposées par le bitmap cible, résultat 1- il m'a fallu tricher : SetLength(Matrix, Larg_Image+1, Haut_Image); //+1 car x du graphique arrive à 1536... que je ne m'explique pas bien, d'ailleurs ; Mais si pas +1 alors violation d'accès
2- ça double (ouais ouais, ça double !) le temps d'exécution de la procédure de dessin, comme si le compilateur rajoutait, dans ce cas, une séquence d'initialisation (remplissage avec des zéros ou autre ?)
Bref, retour en arrière et array statique, dommage.

Et sinon, des nouvelles de la lumière visible ?
Bon dimanche,

[wiwaxia]

Bonsoir,

# Je redoutais une réaction allergique à toutes ces austères remarques ...

Il est donc très facile de passer de l'une à l'autre par programmation.

C'est cependant de l'humour tout à fait involontaire; je rappelais qu'il suffisait de remplacer un courte instruction par une autre, aussi brève - ce que tu as d'ailleurs fait toi-même.
On peut de plus avoir l'une ou l'autre en liant l'option à la parité d'une variable 'Pilote':

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 Coef_C(Pil: Byte; t: Reel): Reel;
   VAR u, v, w: Reel;
   BEGIN
     IF t>1 THEN u:= t - 2
            ELSE IF t<-1 THEN u:= t + 2
                         ELSE u:= t;Il
     v:= Abs(u);
     IF Odd(Pil) THEN w:= 2 - (3 * v)
                 ELSE w:= (3 * v) - 1;
     IF w>1 THEN w:= 1
            ELSE IF w<0 THEN w:= 0;
     Coef_C:= CcG(g, w)
   END;

#

par quoi pourrais-je bien remplacer "CcG" qui n'est vraiment pas parlant ?),

Fonction Cefficient couleur dépendant du paramètre G: j'étais pressé de coder, et j'ai pris ce qui m'est venu en tête pour minimiser l'effort de mémoire. Il s'agit en fait d'un facteur de correction non linéaire Fcnl(g, w). Un certain recul permet de meilleurs choix.

#

Autre chose qui m'a considérablement surpris : au lieu de déclarer la matrice statique avec taille imposée par la constante, je l'ai déclarée dynamique avec dimensions imposées par le bitmap cible, résultat 1- il m'a fallu tricher : SetLength(Matrix, Larg_Image+1, Haut_Image); //+1 car x du graphique arrive à 1536... que je ne m'explique pas bien, d'ailleurs ; Mais si pas +1 alors violation d'accès

Nous avons déjà évoqué le choix du premier indice (0 ou 1) - une instruction inappropriée ne traînerait-elle pas dans tes programmes ? D'autre part, tu as fait le choix du "sur mesure", les dimensions de la variable matrice coïncidant avec celles du corps de l'image Bitmap; alors qu'en ce qui me concerne, elle les dépasse largement (Max1 = Max2 = 2000) - trop, sans doute ... Tu peux donc rencontrer plus souvent des problèmes de transgression de limite.
Attention aux fonctions discontinues: Int(1535.999) = 1535 ; Int(1536.000) = 1536 . C'est la petite surprise qui peut surgir en fin de boucle !

#

je supprime des longueurs, au détriment de la lisibilité, je te l'accorde, ... car je me suis rendu compte que je gagnais des millisecondes par ci par là avec ce genre de manips.... une opération en moins = une milliseconde (à la louche) gagnée !

Je veux bien, mais est-ce vraiment indispensable ? Le délai de calcul n'est pas très long.

D'abord ne pourrais-tu pas injecter directement les valeurs calculées dans la matrice image de la variable 'bmp' ?
Le tableau de pixels de type défini ARRAY[0..Max1, 0..Max2] OF Pixel permettait de faire le lien entre nos deux algorithmes, et de centrer l'échange sur le codage des dégradés ... Il n'est peut-être plus indispensable.

De plus compte tenu du nombre très élevé d'éléments à déterminer, le recours aux pointeurs ne permettrait-il pas de réduire substantiellement le temps d'exécution ? Un tableau de pointeurs , par exemple ? Je ne suis pas familier de ce procédé, et je reprendrai peut-être plus tard en ce sens la programmation des sujets actuels.
Question à creuser dans des cours de Pascal; l il y en a d'excellents sur ce site. Consulter aussi dans cette discussion, l'intervention de souviron34 (11/06/2016, 18h29).

J'avais tenu à faire le tour de la question avant de passer à la lumière visible, question sur laquelle tu désires apparemment recevoir quelques éclaircissements

# Au passage, un lien vers un site présentant un grand nombre d'algorithmes, en tous langages. Tu auras de quoi t'occuper.

[Jipété]

Bonjour,

Je veux bien, mais est-ce vraiment indispensable ? Le délai de calcul n'est pas très long.

1- pour le fun -- c'est comme ça que je "m'approprie" un code, pour bien le maîtriser ensuite ;
2- quelques millisecondes sur une petite image peuvent se transformer en secondes sur une grosse !

D'abord ne pourrais-tu pas injecter directement les valeurs calculées dans la matrice image de la variable 'bmp' ?
Le tableau de pixels de type défini ARRAY[0..Max1, 0..Max2] OF Pixel permettait de faire le lien entre nos deux algorithmes, et de centrer l'échange sur le codage des dégradés ... Il n'est peut-être plus indispensable.

J'y ai déjà songé, mais j'ai tellement de trucs à gérer...

De plus compte tenu du nombre très élevé d'éléments à déterminer, le recours aux pointeurs ne permettrait-il pas de réduire substantiellement le temps d'exécution ? Un tableau de pointeurs , par exemple ? Je ne suis pas familier de ce procédé, et je reprendrai peut-être plus tard en ce sens la programmation des sujets actuels.
Question à creuser dans des cours de Pascal; l il y en a d'excellents sur ce site. Consulter aussi dans cette discussion, l'intervention de souviron34 (11/06/2016, 18h29).

Les pointeurs, j'y ai songé également, c'est dans la pile avec le reste (et j'attends toujours mon colis, qui va changer le cours de ma vie pendant une à deux semaines [ou plus...])
Très bien, l'explication de Souvi (on voit toujours les mêmes sur ces forums, -- tiens, j'ai noté que tu avais remarqué FleurEnPlastique ! ) -- et au final on ne sait pas si l'OP s'en est sorti avec sa question du balayage en diagonale... Ah, l'impolitesse...

J'avais tenu à faire le tour de la question avant de passer à la lumière visible, question sur laquelle tu désires apparemment recevoir quelques éclaircissements

Et ce qui me pose le plus gros problème, c'est la manière de rendre les couleurs (je m'exprime mal, mais tu vas voir) car, par exemple sur cette page bien documentée, il y a un tableau en bas et tout en bas en cliquant sur "Spectre électromagnétique en détail [afficher]" on en voit un autre, et les couleurs ne sont pas les mêmes entre ces deux tableaux ! Pour moi la question est simple : où est la Vérité ?
Pour le moment j'en suis là; mais c'est une interprétation toute personnelle :

# Au passage, un lien vers un site présentant un grand nombre d'algorithmes, en tous langages. Tu auras de quoi t'occuper.

Je bookmarke, on ne sait jamais.

Merci pour tout ce qui précède, et très bonne journée,

EDIT :
Arggggh, tu me refais le coup d'éditer ton message de la nuit après ma réponse du matin,

#
Nous avons déjà évoqué le choix du premier indice (0 ou 1) - une instruction inappropriée ne traînerait-elle pas dans tes programmes ? D'autre part, tu as fait le choix du "sur mesure", les dimensions de la variable matrice coïncidant avec celles du corps de l'image Bitmap; alors qu'en ce qui me concerne, elle les dépasse largement (Max1 = Max2 = 2000) - trop, sans doute ... Tu peux donc rencontrer plus souvent des problèmes de transgression de limite.
Attention aux fonctions discontinues: Int(1535.999) = 1535 ; Int(1536.000) = 1536 . C'est la petite surprise qui peut surgir en fin de boucle !

Mes programmes
Attention aux fonctions discontinues: Int(1535.999) = 1535
Ça doit être ça, l'embrouille : round(1535.5xx); --> 1536
À l'occasion j'essayerai avec un trunc(1535.5xx);

[souviron34]

Salut à tous..

Je reviens après quelques mois de semi-absence et je me vois cité

J'essaierais de remonter la discussion pour remonter le code (à moins que sympathiquement vous ne fournissiez la version actuelle ) et faire la traduction avec les pointeurs ... Ca devrait sans doute, d'après ce que je comprend, accélérer pas mal..


Juste un petit point :

Attention aux fonctions discontinues: Int(1535.999) = 1535
Ça doit être ça, l'embrouille : round(1535.5xx); --> 1536
À l'occasion j'essayerai avec un trunc(1535.5xx);

En général, on fait :

int (valeur+0.50).

(de 1535.50000000000 à 1536.499999999 => 1536)
(de -1536.500000000000 à -1535.49999999999 => -1536)

[wiwaxia]

Bonjour,

C'est vraiment sympa de vouloir t'impliquer dans la rédaction de la version 'pointeurs' du programme. J'envoie au plus vite le fichier source et l'unité qui lui est associée, en version simplifiée (il y a pas mal d'options en chantier, que je vais tenter d'élaguer).

Cordialement, W.

[Jipété]

Messieurs bonjour,

En général, on fait :

int (valeur+0.50).

(de 1535.50000000000 à 1536.499999999 => 1536)
(de -1536.500000000000 à -1535.49999999999 => -1536)

Oui mais ici la valeur négative ne nous intéresse pas car il est juste question de remplir la matrice, de 0 à Length-1.

J'ai rajouté une petite fonction de log juste après le calcul de x qui, je le rappelle, fonctionne comme ça :

Code pascal :

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

1
2
3
    FOR k:= -Lim TO Lim DO BEGIN  // Lim = 5000
      r:= k / Lim;
      x:= Round(((r+1) * Larg_Image) / 2); // Inc(x); // position horizontale, si Inc(x) présent, 1re colonne moisie

et ça donne ces valeurs (à gauche le x "rounded", à droite la formule sans le "round") (j'abrège, il n'y a que le début et la fin) :

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
0    0 
0    0.153599999999983
0    0.307199999999966
0    0.460800000000035
1    0.614400000000018
1534 1534.464
1535 1534.6176
1535 1534.7712
1535 1534.9248
1535 1535.0784
1535 1535.232
1535 1535.3856
1536 1535.5392
1536 1535.6928
1536 1535.8464
1536 1536

Si j'enlève le +1 au "r" c'est crash sur Access Violation , par contre, en conservant ce +1 mais en faisant Larg_Image-1 ça fonctionne :

Code :

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

1
2
3
4
5
6
7
8
9
10
0    0
0    0.153499999999983
0    0.306999999999966
0    0.460500000000035
1    0.614000000000018
1534 1534.386
1535 1534.5395
1535 1534.693
1535 1534.8465
1535 1535

et je ne vais pas taper dans ce 1536 situé, si les choses sont bien faites, en dehors de la matrice.
Je rappelle que 1536 est la largeur du bitmap de travail intermédiaire, avant l'assignation à l'objet d'affichage.

Je n'ai pas remarqué de différences en termes de rendu des couleurs, dégradé comme graphique.

[tbc92]

Si je vois bien, ta boucle va s'exécuter 10000 fois ( 5000+5000), alors que ton image fait 1536 colonnes. Chaque colonne va donc être coloriée 6 voire 7 fois.

Tu peux diviser tes temps de traitement par 6 en faisant :

Code :

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

1
2
3
 
For x = 0 to Larg_Image-1              // Ainsi x varie de 0 à 1535 ... c'est à dire pointe directement sur l'indice de la colonne qu'on va traiter .
     r = x/(Larg_Image-1) *2-1         // Ainsi r varie entre -1 et 1 comme dans ta version , donc en principe rien à changer dans le reste du code.

[wiwaxia]

Si je vois bien, ta boucle va s'exécuter 10000 fois ( 5000+5000), alors que ton image fait 1536 colonnes. Chaque colonne va donc être coloriée 6 voire 7 fois

Si la tangente des graphes devient verticale, le tracé n'est plus continu et comporte des pointillés.
Ceci dit, on peut reconsidérer la valeur choisie pour la constante (Lim), et la relier aux dimensions de l'image; c'est une modification secondaire.

Tu peux diviser tes temps de traitement par 6

Là, c'est trop faible et le tracé sera altéré. Il faut une estimation de la longueur totale du graphe.

[Jipété]

Là, c'est trop faible et le tracé sera altéré. Il faut une estimation de la longueur totale du graphe.

Tutafait ! Tu m'as pris de court pendant que je bricolais une image, "un bon dessin valant mieux qu'un long discours", c'est bien connu :



En haut la boucle optimisée de tbc92, temps d'exécution global de la création + affichage du dessin : 24 millisec.
En bas la boucle "laborieuse" (arf !) de wiwaxia, temps d'exéc 25 millisec.
Attention, pour bien montrer les détails, l'image est fortement agrandie et l'immense trait vert au milieu a été considérablement élagué.

[tbc92]

Visiblement, je n'avais rien compris, et je n'ai toujours rien compris.
Ce n'est pas grave

[anapurna]

salut

comme le dis Tbc92 ta boucle est bien trop longue pourquoi ne pas mettre 100000

en fait tu parcours la largeur de ton image et tu cherche a définir le y de chaque couleur pour un x défini
je me suis permis de cherche les valeur que donnerai les différente variables selon 3 valeur bien connue
- 5000, 0 et + 5000

Code :

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

1
2
3
4
 
      r:= k / Lim; //  -1 | 0 | 1                                                 // le r est donc entre -1 et 1 
      s:= (r + 1) * (La - 1); //  0 | Largeur | 2 * Largeur           // le s entre 0 et 2 fois la largeur 
      x:= Round(s / 2); // Inc(x); //   0 | Largeur Div 2 | largeur// le x entre 0 est largeur

je suppose donc quand connaissant la fonction inverse on devrais pouvoir retrouver nos éléments
PS je pencherai donc pour une fonction sinusoïdale ce qui implique une période de 360°
on retrouve ici le principe de l'onde ce qui est bien notre cas pour de la lumière ou couleur