Discussion :

[Jipété]

Yop !

L'arrondi ne devrait intervenir que dans l'expression finale de l'indice:
idx:= Round(...)

J'en parle plus bas.

Je verrais plutôt:

Code :

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

idx := (distance / diam) + round(ToDegrees(Phase * rapport_diam_sur360));

qui ne compile pas car "/" est une division de réels, dont le résultat ne peut pas être accepté par l'integer idx.
De toute façon, j'ai fait des essais, je les ai posté, j'en ai parlé cet après-midi (suis-je lu ?), j'en reparle plus bas.

3°) La suite non plus ne m'inspire pas: je suppose que ToDegrees est une fonction de ton cru

Non !
J'en ai déjà parlé, elle vient de là :
https://stackoverflow.com/questions/...ans-to-degrees

L'expression se réduit donc à:

Code :

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

idx:= Distance*Phase/(2*Pi)

et comme je ne saurais infliger à quiconque des souffrances inutiles ,

Code :

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

idx:= Round(Distance*Phase/(2*Pi))

Magnifique :

Je ne fais en cela que reprendre la remarque pertinente d'anapurna

... il ne faut s'en servir que pour l'affichage tes calculs doivent être faits avec le plus de précision possible

et donc je reposte ce que j'ai déjà posté cet après-midi :

certaines choses qui pourraient sembler évidentes (EDIT de ce soir) en termes rabâchés de simplification des multiples round
en partant de ce code qui tourne à peu près rond

Code pascal :

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

1
2
3
4
//distance := round(sqrt(somme_cotesaucarre * 4));// plein de points blancs en périphérie
  distance := trunc(sqrt(somme_cotesaucarre*4)); // il n'y en a plus
  idx := (distance * diam) + round(ToDegrees(Phase * rapport_diam_sur360));
  pb[pos_px] := pxsourceQ[idx]; // génération du bitmap pixel à pixel

ne le sont pas du tout, au niveau du résultat (1 seul round final comme suggéré par wiwaxia [et j'aurais pu être d'accord] au lieu de 2 ou 1 round + 1 trunc) :

Code pascal :

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

1
2
3
4
5
  distances := sqrt(somme_cotesaucarre * 4);
//idx := round((distances * diam) + ToDegrees(Phase * rapport_diam_sur360)); // kc
// dessus ou dessous, c'est pareil, c'est kc
  idx := trunc((distances * diam) + ToDegrees(Phase * rapport_diam_sur360)); // kc
  pb[pos_px] := pxsourceQ[idx]; // génération du bitmap pixel à pixel

donnent un résultat catastrophique.

De toute façon, en réfléchissant un peu, la distance pourrait être la longueur de l'hypoténuse et, pour savoir si on est dans le cercle, sur la circonférence où à l'extérieur, toutes zones existant en pixels, on ne peut y aller qu'en integer ! Les demi-pas n'existent pas ici, on ne peut pas être entre deux pixels !

Et pareil pour l'idx.


---
Ceci étant dit, j'y ai repensé tout le repas, et je ne crois pas du tout au plan "le centre doit être matérialisé par un pixel", c'est juste pas possible, pour une raison très simple : le centre d'un cercle est une notion virtuelle qui n'a pas d'existence réelle. C'est juste l'endroit où se croisent à 90 ° deux droites d'épaisseur nulle.
Même le trou de la pointe du compas, du fait de son diamètre propre, va induire une erreur, erreur bien visible quand le centre est un pixel carré, parce que ce qui sépare le quadrant N-E du quadrant S-E c'est un rayon d'épaisseur nulle.
Si son épaisseur est de 1 pixel (égale au côté du carré central), de quelle couleur ce rayon va-t-il hériter ?

Quant au cercle résultant, ce ne sera plus un cercle mais un assemblage de 4 quadrants séparés par 4 rayons : je ne sais pas trop ce que ça donnera.
Vous avez des exemples de cercles avec un diamètre impair (2 rayons identiques = résultat toujours pair + 1 pour le centre) ?

[Jipété]

2°) L'expression n'est pas homogène:

Code :

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

idx := (distance * diam) + round(ToDegrees(Phase));

Peut-être, mais elle est efficace : si j'enlève * rapport_diam_sur360 au bout à droite et que je pars sur un cercle d'un diamètre de 168, je gagne l'image de gauche, pas très jolie ; si je conserve la formule à l'identique tout va bien :



Ce que j'aimerais bien comprendre, par contre, c'est pourquoi il me faut multiplier par 4 la valeur de l'hypoténuse distance := trunc(sqrt(somme_cotes_aucarre*4)); pour avoir un affichage correct (ci-dessus à droite), car sinon ça distance := trunc(sqrt(somme_cotes_aucarre)); donne ça :



C'est joli mais ce n'est pas exactement ce que je cherche...

[wiwaxia]

Tu ne comprends pas: il faut distinguer les grandeurs concernant les graphes et dont le calcul met en jeu des nombres réels, de leur représentation qui implique une distribution des couleurs sur des petits éléments finis du plan appelés pixels.

Un cercle centré en (100, 100) et passant par le point (200, 200) a pour rayon R = 100*2^1/2 = 141,421356... et non pas 141: introduire un arrondi à ce niveau est injustifié, et abîme les résultats ultérieurs. L'intérieur du même cercle est défini par OM² < (ou =) R² = 20000 , et non pas 19881.

Le centre d'une image carrée de dimensions (401x401) est exactement localisé en (200, 200); on trouve le même nombre de pixels de part et d'autre, au-dessus et au-dessous: 200 pour [0...199] et pour [201...400], et le tracé des médianes ne pose alors aucun problème, ce sont les droites d'équations (x = 200) et (y = 200).
Cela correspond à ce que j'avais proposé lors de la déclaration des types de variables tableau:

Code :

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

1
2
3
 TYPE TabP_1  = ARRAY[0..N1, 0..N2] OF Pixel;              // N1 et N2 librement choisis, indépendamment de la valeur de Dim_Pal
      TabP_2  = ARRAY[-N2..N2, -N2..N2] OF Pixel;          // Image carrée d'arête impaire (2*N2 + 1)
      Tab_24P = ARRAY[0..Dim_Pal - 1] OF Pixel;

Ce qu'il faut éviter, c'est le choix toujours mauvais d'un point de vue graphique entre (n) et (n + 1) pour représenter la valeur semi-entière (n + 1/2) ; l'erreur de tracé est alors maximale.

Ton obsession des entiers imprègne et inhibe toutes tes initiatives au niveau algorithmique: dans la relation entre les dimensions des images, comme dans le refus de tout procédé d'interpolation.
Exemple: au paramètre réel de teinte t = 18.24 correspond non pas la couleur C(18) placée au rang 18 = Round(t) de ta palette, mais la combinaison linéaire C(18.24) = 0.76*C(18) + 0.24*C(19) qui estompe les discontinuités de teinte.

Et je maintiens que la formule

Code :

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

idx := (distance * diam) + round(ToDegrees(Phase * rapport_diam_sur360));

est inhomogène, puisqu'elle prétend réaliser la somme d'une surface et d'un angle, ce qui n'a aucun sens .
La version corrigée est par contre plausible (ce qui ne veut pas dire: juste):

Code :

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

idx := (distance / diam) * round(ToDegrees(Phase * rapport_diam_sur360));

peu importe la nature de la division: il suffit de déclarer le résultat réel. La division euclidienne n'a pas sa place ici.

[Jipété]

Bonjour,

ce matin ça part fort.

La version corrigée est par contre plausible:

Code :

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

idx := (distance / diam) * round(ToDegrees(Phase * rapport_diam_sur360));

peu importe la nature de la division: il suffit de déclarer le résultat réel. La division euclidienne n'a pas sa place ici.

Ce que je considère complètement idiot et inapplicable pour la bonne et simple raison que idx est un index dans la matrice map, matrice qui ne peut être parcourue que par des entiers.
C'est bien joli les théories mais quand on les ramène à la pratique, on va dans le mur.

Le centre d'une image carrée de dimensions (401x401) est exactement localisé en (200, 200); on trouve le même nombre de pixels de part et d'autre, au-dessus et au-dessous: 200 pour [0...199] et pour [201...400], et le tracé des médianes ne pose alors aucun problème, ce sont les droites d'équations (x = 200) et (y = 200).

Oui, mais on les barbouille de quelles couleurs, tes droites ?
J'ai dessiné dans Gimp un carré de 101 x 101 et dans ce carré j'ai inscrit un cercle, donc de diamètre 101, et de rayon ?
50,5 ?
Et comment vas-tu faire si on te demande de colorier la moitié droite du cercle en bleu et l'autre moitié en jaune ? T'es mal, là, t'es très mal...
Ce que j'ai fait, c'est de dessiner un rectangle de 101x50 positionné sur le bord gauche du cercle et colorié en bleu, puis je l'ai dupliqué de l'autre côté, aligné à droite et rempli en jaune. On voit bien le diamètre vertical de 1 pixel, ce qui est stupide, un diamètre est une longueur, ce n'est pas un machin en 2D de 1x2R.


Ensuite je me suis amusé à dupliquer ce cercle, le désaturer, le pivoter de 90 °, jouer sur sa transparence, et on retrouve les deux droites dont j'ai parlé hier soir, qui existent ici et qui dans l'absolu n'ont pas d'épaisseur, et c'est ça qui te fout dedans.


Note : les images ont été agrandies x4 pour bien montrer le défaut.

Ce qu'il faut éviter, c'est le choix toujours mauvais d'un point de vue graphique entre (n) et (n + 1) pour représenter la valeur (n + 0.5) .

Et pourtant, au moment de poser les couleurs, il va bien falloir en passer par là...

En résumé, pour une fois c'est moi qui ai raison avec de la bête mathématique de niveau 6^e ou par là : la formule du diamètre c'est D = R x 2 donc obligatoirement un nombre pair.
Et ensuite on est bien obligé de s'accommoder de petits ajustements pour faire entrer dans une surface ronde des pixels carrés (niveau jardin d'enfants, là, vous savez, le seau avec un couvercle avec des trous de formes différentes et des objets à y faire passer ), en acceptant des défauts qu'il faut savoir minimiser (flou, antialiasing, etc.)


EDIT :

Ton obsession des entiers imprègne et inhibe toutes tes initiatives au niveau algorithmique: dans la relation entre les dimensions des images, comme dans le refus de tout procédé d'interpolation.

Relire la phrase juste précédente,

Exemple: au paramètre réel de teinte t = 18.24 correspond non pas la couleur C(18) placée au rang 18 = Round(t) de ta palette, mais la combinaison linéaire C(18.24) = 0.76*C(18) + 0.24*C(19) qui estompe les discontinuités de teinte.

Ah mais là je suis entièrement d'accord !
La question portait surtout sur quel pixel attribuer la couleur aussi difficilement calculée,

Pi si tu édites pendant que je te réponds, on va pas y arriver ! Je t'imaginais dans les bras de la charmante Morphée, moi,

[wiwaxia]

... Ce que je considère complètement idiot et inapplicable pour la bonne et simple raison que idx est un index dans la matrice map, matrice qui ne peut être parcourue que par des entiers.
C'est bien joli les théories mais quand on les ramène à la pratique, on va dans le mur ...

Le calcul concerne des réels, et on en tire l'indice à la fin

Code :

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

idx := Round((distance / diam) * (ToDegrees(Phase * rapport_diam_sur360)));

(sans revenir sur le contenu qu'il faudrait réexaminer).

... Oui, mais on les barbouille de quelles couleurs, tes droites ? ...

De la couleur de ton choix. L'important est qu'aucune approximation ne fausse leur emplacement.

... J'ai dessiné dans Gimp un carré de 101 x 101 et dans ce carré j'ai inscrit un cercle, donc de diamètre 101, et de rayon ?
50,5 ? ...

Le diamètre vaut (101 - 1) = 100; le rayon: 100/2 = 50 .
C'est le problème classique des piquets et des intervalles (niveau CM2⁺⁺), il suffit de compter les pixels
(0 = Xmin, 1, 2, 3 ... 49) ; 50 (position du centre); (51, 52, 53, ... 100 = Xmax)
Rayon = Xcen - Xmin = 50 - 0 = 50 = Xmax - Xcen = 100 - 50 = 50

Et pourtant, au moment de poser les couleurs, il va bien falloir en passer par là...

Si tu représente des aires, et non plus des frontières, il vaudra mieux dans ce cas prendre des dimensions paires: les coordonnées du centre seront alors semi-entières.
Pour un carré de côté 100, Xcen = Ycen = (100 - 1)/2 = 49.5 ; il ne faut surtout pas gâcher la suite en arrondissant à 50 ! Les aires présentent alors des intervalles égaux: (0, 1,, 2, ... , 49) et (50, 51, 52, ... 99) soit 50 pixels.

C'est bien joli les théories mais quand on les ramène à la pratique, on va dans le mur ...
... En résumé, pour une fois c'est moi qui ai raison avec de la bête mathématique de niveau 6e ou par là : la formule du diamètre c'est D = R x 2 donc obligatoirement un nombre pair.
Et ensuite on est bien obligé de s'accommoder de petits ajustements pour faire entrer dans une surface ronde des pixels carrés (niveau jardin d'enfants, là, vous savez, le seau avec un couvercle avec des trous de formes différentes et des objets à y faire passer ), en acceptant des défauts qu'il faut savoir minimiser (flou, antialiasing, etc.)

Tu confonds encore une fois données géométriques et localisation des pixels: D = 100.0 , R = 50.0 .
... Encore faut-il ne pas multiplier les prétextes de rafistolage en introduisant des discontinuités inutiles ... et personne ne rivalise avec autrui, tout le monde gagne à l'échange.

"La théorie est absurde sans la pratique et la pratique est aveugle sans la théorie."

[Jipété]

(0 = Xmin, 1, 2, 3 ... 49) ; 50 (position du centre); (51, 52, 53, ... 100 = Xmax)

Quand on compte sur ses doigts, OK.
Mais là on compte des vrais pixels, de 0 à 49 ça fait 50 pixels, de 51 à 100 ça fait aussi 50 pixels, et entre les deux le centre fait 1 pixel et ton diamètre en pixels devient 50+50+1, tourne vire tu n'y couperas pas.

idx := Round((distance / diam) * (ToDegrees(Phase * rapport_diam_sur360)));

J'ai essayé avec Trunc au lieu de Round, avec et sans * rapport_diam_sur360, en remplaçant la multiplication par une addition (tu as parfois posté ça), j'ai même tenté de remplacer diam par rayon, dans tous les cas c'est ce genre d'image, à quelques variations près.
Ce truc m'épuise.

... Oui, mais on les barbouille de quelles couleurs, tes droites ? ...

De la couleur de ton choix. L'important est qu'aucune approximation ne fausse leur emplacement.

Le problème c'est le centre (encore une fois !)...
Car ces droites sont en fait des diamètres, qui n'est jamais que la somme de 2 rayons sauf qu'avec ton diamètre impair, ou bien le centre n'est jamais rempli, ou bien il l'est deux fois. Ça tombe bien, dans les deux cas il doit être blanc.
Mais pour les couleurs elles-mêmes, euh, une moyenne entre la fin de la couleur d'avant (en tournant dans le sens inverse dadm) et le début de la couleur d'après ?
Je ne vois absolument pas comment faire. Et ça sert à quoi de se décarcasser à faire une map la plus esthétique possible s'il faut rajouter au cercle des couleurs qui ne s'y trouvent pas !

Pour s'affranchir de ce centre problématique tout en conservant un diamètre pair, il suffit de dire que le centre est fait avec les 4 pixels du centre géométrique et là, tout s'arrange.
Le centre du cercle, point immatériel, est localisé à la croisée de ces 4 pixels :

Code :

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

1
2
3
4
5
                     |
pixel en haut à gche | pixel en haut à drte
---------------------C----------------------
pixel en bas  à gche | pixel en  bas à drte
                     |

C c'est le centre du cercle, œuf corse, et de l'assemblage de ces 4 pixels (à l'angle droit de chaque quadrant) et les pointillés matérialisent les frontières des pixels.
Il devient très facile de balayer de hd à rayon, de hg à -rayon, de bg à -rayon et de bd à rayon.

Ça, ça me plait

[Jipété]

J'ai pu simplifier un peu et pour faire des tests ça va être plus facile.
Plus de notion de distance, plus que la ligne idx :

Code :

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

idx := trunc(sqrt(somme_cotes_aucarre)) * diam_fois2 + trunc(ToDegrees(Phase * rapport_diam_sur360));

très joli, très classique.
Petite tentative rapide :

Code :

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

idx := trunc(sqrt(somme_cotes_aucarre)) * diam_fois2 + trunc(ToDegrees(Phase));

et paf !, le ballon de plage et ses couleurs chatoyantes, -- on oublie.

On relit attentivement la nouvelle ligne idx et on constate la présence de 2 trunc, alors on tente (soyons fous !)

Code :

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

idx := trunc( (sqrt(somme_cotes_aucarre) * diam_fois2) + ToDegrees(Phase * rapport_diam_sur360) );

affiche un grand n'importe quoi.


Donc on oublie aussi et on aura une ligne idx avec 2 trunc.

---
Il y a cependant une chose qui me chiffonne au plus haut point :
si je m'appuie sur ce croquis trouvé sur le web (ne sais plus où, pas le temps de chercher),
croquis


j'en déduis que ce que j'appelais "distance" n'est ni plus ni moins qu'une hypoténuse (dernière version : distance := trunc(sqrt(somme_cotes_aucarre));, soit un… rayon !

Du coup ça simplifie le bazar, qui devient

Code :

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

idx := (rayon * diam_fois2) + trunc(ToDegrees(Phase * rapport_diam_sur360));

mais c'est la misère (marre de faire des copies d'écran).

Ce qui laisserait supposer que trunc(sqrt(somme_cotes_aucarre)) * diam_fois2 est une valeur qui évolue au cours du parcours des boucles h et w.
Comment cela est-il possible ?

[wiwaxia]

Commentaire rapide: ne disposerais-tu pas dans Free Pascal de la fonction Hypothenuse(x, y) = (x² + y²)^1/2 ? Cela pourrait alléger ton code.

Voici un extrait de l'unité Math de Virtual Pascal:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
function Hypot(X, Y: Extended): Extended;        { Sqrt(X**2 + Y**2) }
begin
  X := Abs(X);
  Y := Abs(Y);
  if X > Y then
    Result := X*Sqrt(1+Sqr(y/x))
  else if X = 0 then
    Result := Y
  else
    Result := Y*Sqrt(1+Sqr(x/y))
end;

Je reprendrai plus tard.
Tu parais sur la bonne voie !

[wiwaxia]

Quand on compte sur ses doigts, OK.
Mais là on compte des vrais pixels, de 0 à 49 ça fait 50 pixels, de 51 à 100 ça fait aussi 50 pixels, et entre les deux le centre fait 1 pixel et ton diamètre en pixels devient 50+50+1, tourne vire tu n'y couperas pas ...

N pixels consécutifs déterminent (N - 1) intervalles,
donc le diamètre vaut 50 + 50 + 1 - 1 = 100 pixels.

On en revient au problème des piquets et des intervalles

Je te l'avais déjà signalé: le bon outil, c'est une variable tableau de type ARRAY[-N2..N2, -N2..N2] OF Pixel

Exemple simple: pour lequel la constante (N2) vaut (2), d'où une image carrée de dimensions (5x5) pixels, correspondant à un diamètre de 5 - 1 = 4 pixels:

La fonction Arctan(y/x) n'est pas définie au niveau du pixel central, mais c'est sans importance puisque la distance calculée y est nulle: la couleur correspondante est donc le blanc (255, 255,255).

[Jipété]

... d'où une image carrée de dimensions (5x5) pixels, correspondant à un diamètre de 5 - 1 = 4 pixels:

Très joli ton croquis, mais encore une fois, ça ne peut pas le faire...

Si les carrés vieux-rose symbolisent des pixels, il est absolument impossible que tu positionnes tes 3 petites croix de la ligne "0" au milieu de pixels : un pixel n'est pas divisible, à notre niveau. C'est une entité entière et insécable (un atome au sens grec ancien), on peut avoir 1 (ou plus) pixel, on ne peut pas avoir de demi-pixel.
Il faut imaginer les pixels comme des pyramides de Khéops vues d'un satellite, et si tu tires une flèche dessus, elle va fatalement tomber le long d'un des 4 côtés jusqu'au sol.

Donc tes 3 petites croix tu ne peux pas les mettre sur le croquis comme ça : il te faut les aligner sur des frontières entre pixels.

Commentaire rapide: ne disposerais-tu pas dans Free Pascal de la fonction Hypothenuse(x, y) = (x² + y²)^1/2 ? Cela pourrait alléger ton code.

Voici un extrait de l'unité Math de Virtual Pascal:

Je ne sais pas, et pourquoi faire ? D'une part si ça existait je l'appellerais en une ligne, d'autre part je trouve le code de la fonction que tu proposes bien compliqué juste pour calculer ça, en une ligne aussi : hypoténuse := sqrt( (x*x) + (y*y) ); puisque hyp² = x² + y².
Mais j'aurais surtout bien aimé une réponse à ma question (suis-je vraiment lu ?) à propos du fait que l'hypoténuse sur le croquis est un rayon du cercle dans lequel s'inscrit le triangle-rectangle et malgré ça, sa valeur varie...

D'ailleurs, pour ne pas mourir idiot, j'ai mis un TMemo sur la fiche pour logger comme ça : memo1.Lines.Add(inttostr(trunc(sqrt(somme_cotes_aucarre)))); juste avant la ligne idx := ... et avec l'image en cours (diam 168 px), je récupère 22130 lignes où je vois la valeur évoluer de 83 à 0 et retour. Tu parles d'un cercle !
EDIT :
En relisant ce qui précède (car, oui, vraiment, ça me turlupine), je me demande si mon triangle rectangle ne serait pas, par hasard, positionné autrement que comme sur le croquis déjà posté, mais je n'arrive pas à voir comment.

Tu parais sur la bonne voie !

Je vais rester là où je suis, ça fonctionne bien ainsi.
Il restera à voir cette histoire de gradient pour le cercle trop lumineux à mi-distance entre le blanc et le noir (selon la taille de la "boule de billard" il se voit plus ou moins bien), juste après ça :

Catastrophe, il vient de me tomber une urgence absolue et ultra prioritaire, qui va consister à créer un petit prog pour mettre, à partir de 4 dossiers parent, dans des sous-dossiers enfant (à créer au fur et à mesure à raison de 50 fichiers par dossier, au-delà c'est ingérable pour la consultation), un certain nombre de fichiers, nombre qui s'élève à presque 600 000…

Je reviens dans deux jours, soyez sages,

[wiwaxia]

... Pour s'affranchir de ce centre problématique tout en conservant un diamètre pair, il suffit de dire que le centre est fait avec les 4 pixels du centre géométrique et là, tout s'arrange.
Le centre du cercle, point immatériel, est localisé à la croisée de ces 4 pixels :

Code :

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

1
2
3
4
5
                     |
pixel en haut à gche | pixel en haut à drte
---------------------C----------------------
pixel en bas  à gche | pixel en  bas à drte
                     |

C c'est le centre du cercle, œuf corse, et de l'assemblage de ces 4 pixels (à l'angle droit de chaque quadrant) et les pointillés matérialisent les frontières des pixels.
Il devient très facile de balayer de hd à rayon, de hg à -rayon, de bg à -rayon et de bd à rayon.

Ça, ça me plait

Alors tant mieux, parce que la position du centre n'a vraiment rien de problématique: lorsque les dimensions sont paires, les coordonnées sont des semi-entiers, et le point envisagé n'est pas correctement représentable, de même que les axes du repère orthonormé dont il se trouve à l'intersection - ce qui est ici sans importance, parce qu'on n'en a pas besoin.

Il faut alors déclarer le type de variable le plus approprié, qui est dans ce cas

Code :

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

ARRAY[0..(2*N2 - 1), 0..(2*N2 - 1)] OF Pixel

dans le cas d'une image carrée de dimensions (2*N2) pixels; et
les coordonnées (Xc, Yc) du centre ont pour valeur commune le réel: Xc = N2 - 0.5 .

On représente ci-dessous le cas d'une image d'arête 20 pixels, pour laquelle Xc = Yc = 9.5 ; on a inventorié les cases dont les centres (P) se situent à l'intérieur d'un cercle de rayon (7) et vérifient la condition:

CP <= 7 ;

Une calculette détermine rapidement les pixels limites; les 8 centres les plus proches de la circonférence de rayon (CM = 7) se situent à la distance

6.964 = (2.5² + 6.5²)^1/2 .

il n'y a aucun point sur le cercle envisagé, parce qu'il n'existe aucun triplet pythagoricien du type (i, j, 14); mais cela n'intervient pas dans la représentation de la zone circulaire.

PS: Notepad++ est vraiment épatant !

[wiwaxia]

... Je ne sais pas, et pourquoi faire ? D'une part si ça existait je l'appellerais en une ligne ...

Tu ne connais apparemment pas tous les trésors de Free Pascal

... d'autre part je trouve le code de la fonction que tu proposes bien compliqué juste pour calculer ça, en une ligne aussi : hypoténuse := sqrt( (x*x) + (y*y) ); puisque hyp² = x² + y² ...

L'algorithme n'est pas de moi, et il est fort probable qu'on le retrouve dans la version de Free P.; j'ai été aussi surpris, mais il est sans doute plus efficace que ce que l'on code ordinairement.
Je crois que la racine carrée du réel (s) s'obtient comme limite de la suite alternée vérifiant la relation de récurrence

u_n+1 = (u_n + s/u_n)/2

(ou d'une suite apparentée, de convergence encore plus rapide), et que le procédé est particulièrement efficace pour s < 2 .
Il faudrait demander à un spécialiste.

... Suis-je vraiment lu ? ...

Oui, mais répondre à toutes tes questions demande du temps

... Mais j'aurais surtout bien aimé une réponse à ma question ... à propos du fait que l'hypoténuse sur le croquis est un rayon du cercle dans lequel s'inscrit le triangle-rectangle et malgré ça, sa valeur varie...
... / ... En relisant ce qui précède (car, oui, vraiment, ça me turlupine), je me demande si mon triangle rectangle ne serait pas, par hasard, positionné autrement que comme sur le croquis déjà posté, mais je n'arrive pas à voir comment ...

1°) L'expression de la distance (CM):

CM = r = ((X_M - X_C)² + (Y_M - Y_C)²)^1/2

découle du théorème de Pythagore.
2°) Le point (M) parcourant toutes les lignes (ou les colonnes) de l'image, il n'est pas étonnant que la distance qui le sépare du centre (C) varie au cours de l'exécution de la double boucle. Peut-être imagines-tu une rotation de (M) autour de (C): il n'en est rien.

[Jipété]

Bonsoir,

je prends 5 minutes (je suis salement coincé avec mon autre truc urgentissime, alors…)

Tu nous as fait un joli croquis, merci, mais tu nous expliques des choses que tout le monde connaît (sauf qu'effectivement, on dirait que FreePascal s'est pris la tête pour extraire la racine carré et c'est peut-être ça qui fait la différence, enfin, moi j'utilise sqrt sans savoir ce qui se cache dessous : est-ce que tu conduis ta voiture comme un vieil hippie américain en mode hot-rod sans capot ?), genre le carré de l'hyp. est égal à la somme des carrés des 2 autres côtés, ça fait plus de 50 ans que je la connais par cœur,

Donc je reste sur ma faim concernant cette variation de la valeur de l'hypoténuse, et pour faire avancer les choses, j'ai loggé plus précisément, 3 lignes à chaque avancée dans la boucle, voici les premières et plus bas ce qu'on trouve au milieu du fichier.
Tout ça a été loggé ainsi (c'est moi qui rajoute les sauts de ligne après coup, et les commentaires) :

Code :

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

1
2
3
4
5
memo1.Lines.Add( inttostr( trunc(sqrt( somme_cotes_aucarre )) ) );
memo1.Lines.Add( floattostr( sqrt( somme_cotes_aucarre ) ) );
memo1.Lines.Add( inttostr( somme_cotes_aucarre ) ); // l'hypoténuse au carré
// juste avant la ligne 
idx := trunc(sqrt(somme_cotes_aucarre)) * diam_fois2 + trunc(ToDegrees(Phase * rapport_diam_sur360));

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
83
83.86298349093
7033 // l'hypoténuse au carré
 
83
83.7257427557379
7010 // l'hypoténuse au carré
 
83
83.6002392341075
6989 // l'hypoténuse au carré
 
83
83.4865258589672
6970 // l'hypoténuse au carré
 
 
4
4
16 // l'hypoténuse au carré
 
3
3
9 // l'hypoténuse au carré
 
2
2
4 // l'hypoténuse au carré
 
1
1
1 // l'hypoténuse au carré
 
0
0
0 // l'hypoténuse au carré
// et on repart dans l'autre sens
1
1
1 // l'hypoténuse au carré
 
2
2
4 // l'hypoténuse au carré

On notera que sur la première ligne on lit 83 parce que c'est trunc(83.86...) qui est utilisé ; avec round on aurait eu 84 et plein d'artefacts colorés à la circonférence du cercle,

Donc je repose ma question : comment est-il possible que l'hypoténuse évolue de 83 à 0 et retour à 83, pour un cercle de diamètre 168 et donc de rayon 84.

Tiens, pour la collec' (à peine retouchée, ce qu'on voit en gris était en vert sombre et peu saturé à l'origine [gag ? Clin d'œil ?]) :

[Jipété]

Bonjour,

la nuit portant conseil, elle m'a soufflé de synthétiser mes logs en folie d'hier ainsi, et limité au quadrant N-E, ça suffira pour se rendre compte que la somme des carrés de ce que je suppose être 2 côtés d'un triangle-rectangle ne doivent pas l'être puisqu'on voit bien que ça évolue, avec cette ligne :

Code pascal :

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

1
2
if (w > 0) and (h > 0) then
memo1.Lines.Add(Format('w:%3d w^2:%4d | h:%2d h^2:%4d | w^2+h^2:%5d  sqrt(w^2+h^2):%.3f',[w, w*w, h, h_aucarre, somme_cotes_aucarre, sqrt(somme_cotes_aucarre)]));

Sortie (qui fait 5449 lignes, ligne du milieu = 2725)

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
début
w:  1 w^2:   1 | h: 1 h^2:   1 | w^2+h^2:    2  sqrt(w^2+h^2):1.414
w:  2 w^2:   4 | h: 1 h^2:   1 | w^2+h^2:    5  sqrt(w^2+h^2):2.236
w:  3 w^2:   9 | h: 1 h^2:   1 | w^2+h^2:   10  sqrt(w^2+h^2):3.162
...
milieu, dessous 2724 2725 2726
w: 47 w^2:2209 | h:34 h^2:1156 | w^2+h^2: 3365  sqrt(w^2+h^2):58.009
w: 48 w^2:2304 | h:34 h^2:1156 | w^2+h^2: 3460  sqrt(w^2+h^2):58.822
w: 49 w^2:2401 | h:34 h^2:1156 | w^2+h^2: 3557  sqrt(w^2+h^2):59.641
et dessous de 2751 à 2756
w: 74 w^2:5476 | h:34 h^2:1156 | w^2+h^2: 6632  sqrt(w^2+h^2):81.437
w: 75 w^2:5625 | h:34 h^2:1156 | w^2+h^2: 6781  sqrt(w^2+h^2):82.347
w: 76 w^2:5776 | h:34 h^2:1156 | w^2+h^2: 6932  sqrt(w^2+h^2):83.259
w:  1 w^2:   1 | h:35 h^2:1225 | w^2+h^2: 1226  sqrt(w^2+h^2):35.014
w:  2 w^2:   4 | h:35 h^2:1225 | w^2+h^2: 1229  sqrt(w^2+h^2):35.057
w:  3 w^2:   9 | h:35 h^2:1225 | w^2+h^2: 1234  sqrt(w^2+h^2):35.128
...
fin
w: 10 w^2: 100 | h:83 h^2:6889 | w^2+h^2: 6989  sqrt(w^2+h^2):83.600
w: 11 w^2: 121 | h:83 h^2:6889 | w^2+h^2: 7010  sqrt(w^2+h^2):83.726
w: 12 w^2: 144 | h:83 h^2:6889 | w^2+h^2: 7033  sqrt(w^2+h^2):83.863

Pour savoir si j'étais dans le, sur le ou hors du cercle, j'avais fouillé le web, je vous livre mes notes :

Code pascal :

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

1
2
3
4
5
6
// http://www.digitalcoding.com/tutorials/delphi/Four-color-circular-gradient.html
        { Fill area by drawing lines }
        Image1.Canvas.MoveTo(Xo,Yo); // centre
        Image1.Canvas.LineTo(
            Xo+Round(Radius*Sin(R*(Pi/180))),
            Yo-Round(Radius*Cos(R*(Pi/180)))); // point sur la circonférence

Code pascal :

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
// https://stackoverflow.com/questions/1201200/fast-algorithm-for-drawing-filled-circles  
procedure TForm1.Button4Click(Sender: TObject);
var 
  x, y, r, {ox, oy,} hauteur: integer;
  cl, ct: integer; // cl centre left, ct centre top
  aBmp:TBitmap;
begin
  r  := 30;
  cl := 60;
  ct := 70;
  aBmp:=TBitmap.Create;
  with aBmp do begin PixelFormat:=pf24bit; Width := 120; Height:=110; end;
  for x := -r to r do begin // parcours horizontal
    hauteur := round(sqrt(r*r -x*x));
    for y := -hauteur to hauteur do
      aBmp.Canvas.Pixels[x+cl, y+ct] := clRed;
  end;
 
{  for x := -r to r do  // parcours horizontal
    for y := -r to r do
      //if (x*x + y*y) <= r*r // un poil plus petit
      //if (x*x + y*y) < (r*r)+r // un poil plus grand, et plus lisse
      if (x*x+y*y > r*r - r) and (x*x+y*y < r*r + r) // juste la circonférence, taille identique à dessus
        then aBmp.Canvas.Pixels[cl+x, ct+y] := clLime;     }
  //aBmp.SaveToFile(chemin+'aBmpcirclelime3.bmp');
  img.Picture.Bitmap.Assign(aBmp);
  aBmp.Free;
end;

Code pascal :

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

1
2
3
4
https://stackoverflow.com/questions/14487322/get-all-pixel-array-inside-circle
You are looking for the following set of pixels:
  P[x,y] = (x-m1)^2 + (y-m2)^2 <= r^2
with r being the radius of your circle and (m1, m2) the center.

Maintenant, est-ce que ça vaut la peine de se prendre la tête puisque au bout du compte, l'affichage est plaisant (à l'exception du cercle central trop brillant sur lequel on reviendra dans quelques jours) ?

Tu ne connais apparemment pas tous les trésors de Free Pascal

On ne peut pas tout connaître,

Et donc c'est disponible aussi sous Lazarus (qui se contente pour l'essentiel d'aller piocher dans FP), du coup je me suis livré à cette comparaison, en reprenant mon code de logging limité au quadrant N-E :

Code pascal :

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

1
2
3
4
5
6
7
hypotfp := hypot(w,h);
if (w > 0) and (h > 0) then begin
  memo1.Lines.Add(Format('hypot(w^2+h^2):%2.3f  sqrt(w^2+h^2):%2.3f',[hypotfp, sqrt(somme_cotes_aucarre)]));
  s1 := Format('%2.3f',[hypotfp]);
  s2 := Format('%2.3f',[sqrt(somme_cotes_aucarre)]);
  if s1 <> s2 then memo1.Lines.Add('***'); // pour repérer facilement les lignes différentes
end;

Ça m'a sorti un fichier de 5449 lignes dont 8 seulement sont différentes à 1/1000^e près (parce que j'ai limité la sortie à 3 décimales) :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
   1 hypot(w^2+h^2): 1.414  sqrt(w^2+h^2): 1.414
   2 hypot(w^2+h^2): 2.236  sqrt(w^2+h^2): 2.236
....
 911 hypot(w^2+h^2):81.743  sqrt(w^2+h^2):81.744
1729 hypot(w^2+h^2):81.743  sqrt(w^2+h^2):81.744
1812 hypot(w^2+h^2):83.935  sqrt(w^2+h^2):83.934
2523 hypot(w^2+h^2):83.935  sqrt(w^2+h^2):83.934
5344 hypot(w^2+h^2):83.935  sqrt(w^2+h^2):83.934
5365 hypot(w^2+h^2):81.743  sqrt(w^2+h^2):81.744
5408 hypot(w^2+h^2):81.743  sqrt(w^2+h^2):81.744
5419 hypot(w^2+h^2):83.935  sqrt(w^2+h^2):83.934
....
5449 hypot(w^2+h^2):83.863  sqrt(w^2+h^2):83.863

Tu crois que ça pourrait faire dévier une Ariane 5,  ?

[wiwaxia]

... (sauf qu'effectivement, on dirait que Free Pascal s'est pris la tête pour extraire la racine carré et c'est peut-être ça qui fait la différence, enfin, moi j'utilise sqrt sans savoir ce qui se cache dessous ... genre le carré de l'hyp. est égal à la somme des carrés des 2 autres côtés ...

Je n'ai fait que te signaler une fonction disponible dans les bibliothèques de Free (et Virtual) Pascal; leur contenu algorithmique est ici anecdotique.
Les expressions en cause:

h = (x² + y²)^1/2 = │x│*(1 + (y/x)²)^1/2= │y│*(1 + (x/y)²)^1/2

sont rigoureusement identiques, et j'ai tenté de justifier la préférence donnée aux deux dernières.

... ça fait plus de 50 ans que je la connais par cœur, ...

Nul ne contexte la validité mathématique de cette formule, mais l'ancienneté d'une habitude ne constitue en rien une justification.
Ce qui est en cause, c'est l'opportunité algorithmique d'une expression.

... Tu nous as fait un joli croquis, merci ...

Je n'ai fait que répondre à ta demande expresse:

... En relisant ce qui précède (car, oui, vraiment, ça me turlupine), je me demande si mon triangle rectangle ne serait pas, par hasard, positionné autrement que comme sur le croquis déjà posté, mais je n'arrive pas à voir comment ...

... mais tu nous expliques des choses que tout le monde connaît ...

Les notions en cause sont établies depuis 4 à 25 siècles, et je ne vais pas réinventer les mathématiques ! Et de ces notions apparemment triviales, tu ne sais pas faire un bon usage ...

... Donc je reste sur ma faim concernant cette variation de la valeur de l'hypoténuse ... / ... Donc je repose ma question : comment est-il possible que l'hypoténuse évolue de 83 à 0 et retour à 83, pour un cercle de diamètre 168 et donc de rayon 84 ...

Il faut te secouer, et faire l'effort de sortir des faux problèmes dans lesquels tu t'enfermes. Nul ne peut le faire à ta place .
Et comme la nuit ne t'a pas apporté les lumières espérées ...

... la nuit portant conseil, elle m'a soufflé de synthétiser mes logs en folie d'hier ainsi, et limité au quadrant N-E, ça suffira pour se rendre compte que la somme des carrés de ce que je suppose être 2 côtés d'un triangle-rectangle ne doivent pas l'être puisqu'on voit bien que ça évolue, avec cette ligne ...

... je reviens sur cette question pour la dernière fois.
Le balayage ligne par ligne de l'image carrée résulte des deux boucles imbriquées

Code :

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

1
2
FOR y:= Min TO Max DO
  FOR x:= Min TO Max DO 

et la distance du point considéré au centre de l'image admet pour expression:

CM = d = ((X_M - X_C)² + (Y_M - Y_C)²)^1/2 .

(Y_M) demeure constant le long d'une ligne, et l'autre terme de la somme vérifie:

(X_M - X_C)² >= 0

si le centre présente des coordonnées entières.
Il vient par conséquent: d >= ((Y_M - Y_C)²)^1/2 = │Y_M - Y_C│ = d_min
De sorte que le long de chaque ligne, (d) présente un minimum lorsque le point est à la verticale du centre (X_M = X_C);
ce minimum est nul (d_min = 0) sur la ligne contenant le centre (Y_M = Y_C), à l'endroit où les deux points coïncident (X_M = X_C).

... Maintenant, est-ce que ça vaut la peine de se prendre la tête ...

Non, l'artillerie lourde de Lazarus ne t'aidera pas à comprendre des notions élémentaires que tu pourrais tout aussi bien tester en Turbo Pascal.

Ça m'a sorti un fichier de 5449 lignes dont 8 seulement sont différentes à 1/1000e près (parce que j'ai limité la sortie à 3 décimales) ...

Une chose de plus qui ne colle pas ... La vérification de deux procédés de calcul (il n'est pas déshonorant de le faire) doit normalement conduire à la coïncidence sur 18 chiffres.

... Tu crois que ça pourrait faire dévier une Ariane 5  ?

La preuve est donnée dans l'aveu que tu viens de faire ... Si les ingénieurs ne résistent pas à la tentation de fourrer quelques arrondis ou parties entières là où il ne le faut pas ...

[Jipété]

Catastrophe, il vient de me tomber une urgence absolue et ultra prioritaire, qui va consister à créer un petit prog pour mettre, à partir de 4 dossiers parent, dans des sous-dossiers enfant (à créer au fur et à mesure à raison de 50 fichiers par dossier, au-delà c'est ingérable pour la consultation), un certain nombre de fichiers, nombre qui s'élève à presque 600 000…

Je reviens dans deux jours, soyez sages,

Terminé (un poil plus long que prévu, rien n'est jamais simple), mais là je suis claqué, or il me faut l'esprit bien limpide pour clarifier cette histoire d'hypoténuse.

Et après on passe aux gradients pour éliminer la brillance centrale, et voilà !

[wiwaxia]

Avec toutes les énormités que tu ré-itères, et qui découlent du même blocage, , le pêcheur de perles dont tu me contrains d'assumer le travail va bientôt réclamer l'application de la loi sur les 35 heures !

... je ne crois pas du tout au plan "le centre doit être matérialisé par un pixel", c'est juste pas possible, pour une raison très simple : le centre d'un cercle est une notion virtuelle qui n'a pas d'existence réelle. C'est juste l'endroit où se croisent à 90 ° deux droites d'épaisseur nulle.
Même le trou de la pointe du compas, du fait de son diamètre propre, va induire une erreur, erreur bien visible quand le centre est un pixel carré, parce que ce qui sépare le quadrant N-E du quadrant S-E c'est un rayon d'épaisseur nulle.
Si son épaisseur est de 1 pixel (égale au côté du carré central), de quelle couleur ce rayon va-t-il hériter ? ...

Représenter un point par un pixel ou une droite par une rangée de pixels n'est pas plus absurde que de tracer une droite au stylo sur une feuille de papier, ou d'y matérialiser un point à l'aide la pointe d'un compas: quelle que soit la finesse de l'outil employé, toute trace visible sur le papier est de toutes façons infiniment plus large qu'une droite ou un point, dont la largeur propre (ou le diamètre) sont par définition nuls.

... Quant au cercle résultant, ce ne sera plus un cercle mais un assemblage de 4 quadrants séparés par 4 rayons : je ne sais pas trop ce que ça donnera ...

Reprenons le cercle de rayon entier (R), passant par les centres des quatre pixels de coordonnées:

(X_C - R, Y_C), (X_C + R, Y_C), (X_C, Y_C - R), (X_C, Y_C + R) ;

a) l'intérieur du cercle sera représenté par l'ensemble des pixels vérifiant (x - X_C)² + (y - Y_C)² < R² (ou éventuellement <= R²) ;
b) les diamètres parallèles aux axes (si l'on tient à les faire apparaître) sont dans ce cas correctement représentables, et répondent aux équations:
x = X_C et y = Y_C .

... Vous avez des exemples de cercles avec un diamètre impair (2 rayons identiques = résultat toujours pair + 1 pour le centre) ?

Par exemple l'ensemble des pixels vérifiant (x - 100.3)² + (y - 150.6)² < 35.5² ,

ce qui conduit à un diamètre horizontal:
D_h = (100.3 + 35.5) - (100.3 - 35.5) = 71
ou pour les arithmomaniaques : D_h = Round(100.3 + 35.5) - Round(100.3 - 35.5) = 136 - 65 = 71 ;
mais il faut renoncer ici à la représentation exacte du centre et des diamètres précédents.

"Madame, ne mégotez pas !" a sorti un jour François Mitterrand à Margaret Thatcher (devinez dans quelle discussion ... ) - ce décompte de pixels, auquel tu t'accroches avec encore plus d'âpreté qu'un Premier Ministre anglais aux subsides européens, perd toute pertinence pour un cercle quelconque de caractéristiques réelles (R, X_C, Y_C), et de diamètre suffisamment important pour que l'oeil ne perçoive pas les irrégularités de bord liées à l'intervention des arrondis.

Très joli ton croquis, mais encore une fois, ça ne peut pas le faire ...

Si les carrés vieux-rose symbolisent des pixels, il est absolument impossible que tu positionnes tes 3 petites croix de la ligne "0" au milieu de pixels : un pixel n'est pas divisible, à notre niveau. C'est une entité entière et insécable (un atome au sens grec ancien), on peut avoir 1 (ou plus) pixel, on ne peut pas avoir de demi-pixel.
Il faut imaginer les pixels comme des pyramides de Khéops vues d'un satellite, et si tu tires une flèche dessus, elle va fatalement tomber le long d'un des 4 côtés jusqu'au sol.

Donc tes 3 petites croix tu ne peux pas les mettre sur le croquis comme ça : il te faut les aligner sur des frontières entre pixels

Les pixels ne sont pas des obstacles durs qui dévieraient certaines données numériques, à l'instar des pavés bombés d'une rue ancienne, qui conduisent les gouttes de pluie vers les bordures; et l'on pourrait retourner la comparaison matérielle que tu en donnes en arguant:
a) qu'un point quelconque des arêtes pourrait convenir, et non pas seulement d'un des quatre sommets;
b) que cela ne saurait favoriser un sommet donné au dépens des trois autres;
c) qu'une pyramide en creux concentrerait les données incidentes en son point le plus bas, à la verticale du centre de la base.

Les pixels résultent de la partition inéluctable du plan de l'écran en un nombre fini d'éléments de couleur, et en cela tu as raison de parler d'atomes; mais il faut les associer à un ensemble continu, le plan de R² orienté par un repère orthonormé (xOy), d'une manière qui soit conforme à deux contraintes:
a) le regard caractérise la position de toute tache de couleur, pour peu que son contour (circulaire, elliptique, carré) présente un minimum de régularité (2 axes de symétrie) en l'assimilant par réflexe à celle de son centre;
b) la couleur de l'image représente selon une échelle conventionnelle les variations d'une fonction F(x, y) des points du plan, et la teinte nécessairement fixe à l'intérieur d'un pixel correspond à la valeur moyenne de cette fonction à l'intérieur du carré correspondant; et il se trouve que cette valeur est très proche de la valeur locale de la fonction au centre du domaine:

Moyenne(F(x, y), (X_C - a/2 < x < X_C + a/2), (Y_C - a/2 < y < Y_C + a/2)) ~ F(X_C, Y_C)

Pour ces deux raisons, le pixel est associé à son point central et non à l'un de ses sommets, ce qui contredirait la symétrie locale ; il en irait de même avec des pixels triangulaires en arrangement hexagonal compact.

[Jipété]

Bonjour,

J'ai décidé que je n'allais pas perdre mon temps à essayer de comprendre où se cache un bug, si au bout du compte je ne le vois pas.

À l'heure actuelle tout fonctionne bien sauf cette histoire de cercle trop lumineux au milieu de la zone colorée, là où les couleurs sont les plus intenses, à rayon div 2 à la louche, je dirais. J'ai déjà pu reprendre ça un peu, en jouant avec le "L" de la décomposition en HSL des 24 couleurs, résultat un léger mieux, mais ce qui me tracasse surtout, c'est la "présence" de la (trop grande) zone blanche partant du centre.
Que le centre soit blanc, ok, c'est normal, ça a été codé ainsi ; qu'il le soit autant que ce qu'on voit, avec cette espèce de gris sale, je trouve ça désagréable.

J'ai tenté d'intervenir sur les paramètres de la boîte noire DrawMultiGradient mais c'est loin d'être évident et ça ne produit pas les résultats escomptés…

J'ai alors tenté une autre approche, en partant de mes 24 triplets RGB et en les injectant dans un tableur puis en lui demandant gentiment de me dessiner un diagramme, car je sentais qu'il pouvait y avoir des blagues de ce côté-là, qu'un rendu visuel permettrait de saisir.
Et donc ça donne ça, avec à gauche les colonnes R, G et B où certaines cellules sont colorées en orange (1^re édition), en bleu (2^e), en jaune (3^e) et en gris pour la dernière :



et toutes ces valeurs reportées dans l'outil Lazarus de dessin me donnent ce joli cercle :



Joli mais pas parfait car je considère que de 8 h à 4 h (la partie basse, donc) la zone blanche est trop grande.
C'est la partie matérialisée par le rectangle bleu clair sous le diagramme.

Est-ce que quelqu'un aurait une idée des points sur lesquels il faudrait agir ? Lesquels monter, lesquels descendre, car par exemple à 6 h on voit bien beaucoup de blanc avant d'arriver au bleu, or ça correspond à la colonne 18 où le bleu est à 225 et le rouge et le vert à 53 et 65, donc un blanc très bleu et ce n'est pas ce qu'on voit.
J'en suis là, alors merci par avance des retours…

On remarquera que certaines couleurs sur le diagramme ne sont pas au top (rouge en haut à gauche, vert en bas à droite), j'ai reporté ces corrections à plus tard car ça n'impacte pas trop la vision globale du cercle.

[wiwaxia]

Le seul moyen de s'affranchir des problèmes de couplage des dimensions de deux images (ou d'une image et d'un objet géométrique), c'est la séparation totale des deux sortes de calculs concernant:
a) l'objet géométrique étudié, que l'on veut représenter, et
b) l'image que l'on souhaite obtenir.

# Les caractéristiques de l'objet seront définies à l'aide de grandeurs réelles, qui conduiront au calcul de coordonnées réelles (x, y) généralement comprises entre zéro et l'unité - sans exclure à priori d'autres domaines plus pratiques dans certains cas, comme par exemple [-1 ; +1]: c'est une affaire d'opportunité.
Si l'intervention des nombres entiers est possible et légitime (comme lors de l'emploi d'une palette de N pixels), il ne faut en aucun cas en créer de nouveaux comme intermédiaires de calcul; l'usage des arrondis, à ce stade, doit être proscrit.

# La synthèse de l'image aux dimensions choisies résultera naturellement du balayage de tous ses pixels, et de la détermination de la couleur correspondante par l'intermédiaire des fonctions réelles de variables réelles établies auparavant.

(Xm, Ym)_{(coordonnées du pixel dans l'image)} ───> (x, y)_{(coordonnées réelles)} ───> Pixel = F(x, y)_{(valeur de la couleur locale)} ───> Tableau[Xm, Ym]:= Pixel

Exemple: les coordonnées (Xc, Yc) des centres des cercles figurant dans les images ci-dessous sont des nombres réels, de même que leur rayon (R2):

Code :

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

1
2
3
4
5
Ce = 0.500; R1 = 0.277;
t = k*(2*Pi/7); k = {0, 1, 2 ... 6}
Xc = Ce + R1*Cos(t); 
Yc = Ce + R1*Sin(t); 
R2 = 0.490 - R1 = 0.213;

Les images carrées ont pour dimensions (400x400) et (401x401):

_

Dans les zones de recouvrement mutuel des cercles, les composantes des couleurs s'additionnent (modulo 256); l'effet visuel est cependant décevant.

Le résultat essentiel est ici l'indépendance des dimensions de l'image vis à vis de celles de l'objet, qui s'inscrit dans un carré de côté 1.

[wiwaxia]

Tu as livré un document intéressant, susceptible de conduire à un traitement global de ta palette.

J'ai alors tenté une autre approche, en partant de mes 24 triplets RGB et en les injectant dans un tableur puis en lui demandant gentiment de me dessiner un diagramme, car je sentais qu'il pouvait y avoir des blagues de ce côté-là, qu'un rendu visuel permettrait de saisir.
Et donc ça donne ça, avec à gauche les colonnes R, G et B où certaines cellules sont colorées en orange (1^re édition), en bleu (2^e), en jaune (3^e) et en gris pour la dernière :

Que le blanc s'étende plus ou moins loin à partir du centre selon la direction envisagée, c'est inévitable compte tenu de ce que la sensibilité de la rétine varie dans un rapport de 1 à 10 selon la couleur de la composante envisagée; en témoigne l'expression de la luminance relative:

Y = 0.2126R + 0.7152G + 0.0722B .

Tu pourrais envisager une modification progressive des teintes par atténuation (ou exaltation) des pics vert et bleu, à l'aide de deux tableaux indépendants,
- l'un pour le vert (Cv[i]) présentant un maximum au 11^me terme, correspondant à un angle de 165 ° = 360*11/24 ;
- l'autre pour le bleu (Cv[i]) présentant un maximum au 18^me terme, correspondant à un angle de 270 ° = 360*18/24 .

Il interviendrait dans les deux séquences le même type de loi sinusoïdale

Cv[i] = 1 + Kv*Cos(360°*(i - 11)/24) = 1 + Kv*Cos(Pi*(i - 11)/12) <= 1 + Kv (valeur maximale correspondant à i = 11) ;

Cb[i] = 1 + Kb*Cos(360°*(i - 18)/24) = 1 + Kb*Cos(Pi*(i - 18)/12) <= 1 + Kb (valeur maximale correspondant à i = 18) .

permettant de calculer les nouvelles valeurs (Jv, Jb) des composantes du vert et du bleu en fonction des anciennes, par un simple produit terme à terme:
Jv[i] = Iv[i] * Cv[i] = Iv[i] * (1 + Kv*Cos(Pi*(i - 11)/12)) ;
Jb[i] = Ib[i] * Cb[i] = Ib[i] * (1 + Kb*Cos(Pi*(i - 18)/12)) .

Il te faut faire une série d'essais sur les deux coefficients indépendants (Kv, Kb) afin de parvenir au résultat optimal; la solution est purement pratique, et liée à l'appréciation de chacun.

Les rapports sont bornés supérieurement, et doivent vérifier:
# pour le vert: 1 + Kv <= 255/227 d'où: Kv <= 28/227 = 0.1233 ;
# pour le bleu: 1 + Kb <= 255/225 d'où: Kb <= 30/225 = 0.1333 .
Une valeur négative (pour le vert ?) n'est pas exclue.

Je dois stopper là; les calculs sont à vérifier.