Discussion :

[wiwaxia]

Noté dans l'un de tes derniers messages (#14):

Code :

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

1
2
3
        distance := round(sqrt((w-cl)*(w-cl) + (h-ct)*(h-ct)));
        phase := round(arctan((h-ct)/(w-cl)));
        RedGreenBlue(degrade.canvas.Pixels[phase,distance], r,g,b);

1°) Les fonctions discontinues (Round(.), Int(.), Trunc(.)) ne doivent pas intervenir en cours de calcul, mais seulement à fin du bloc d'instructions déterminant des valeurs entières (par exemple les composantes d'un pixel).

2°) Chercher la valeur entière d'une distance n'a guère de sens, et encore moins celle d'un angle exprimé en radians ! Tu trouveras dans ce dernier cas 0, 1, 2 ou 3 ...

3°) L'intervention de ces fonctions en calcul interne n'est probablement pas étrangère aux écarts de teinte que l'on observe ... Ces discontinuités non maîtrisables abîment inutilement le calcul, pourtant exécuté ici avec une précision record (2^-63, soit plus de 18 chiffres significatifs !).

[wiwaxia]

... Si tu voulais bien prendre la peine de t'attarder sur le fait que la fonction Arctan(y/x) ne peut être employée sans réserve, tu comprendrais que ce qui est proposé en est l'adaptation ...

... ne peut être employée sans réserve
Qu'est-ce que tu entends par là ?

D'un point de vue numérique, la fonction Arctan(u) doit être utilisée de préférence dans sa partie centrale (-1 <~ u <~ 1), où la pente est voisine de l'unité; d'où la partition du plan du repère (xOy) en 4 secteurs délimités par les deux bissectrices d'équation

y = ± x .

Le diverses expressions de l'angle polaire se retrouvent à partir de cas particuliers relativement simples, pour lesquels les résultats sont évidents.

1°) Cas où l'on a: Abs(y) > Abs(x) :
Les points (M₁, M'₁), symétriques par rapport à l'origine (O), déterminent le même angle avec le demi-axe correspondant, et ortienté dans le sens rétrograde; il vient:

(Oy, OM₁) = (Oy', OM'₁) = t₁ = Arctan(x₁/y₁)

et l'on obtient par conséquent:
a) pour y > 0 (secteur supérieur): (Ox, OM₁) = (Ox, Oy) + (Oy, OM₁) = Pi/2 - Arctan(x₁/y₁) ;
b) pour y < 0 (secteur inférieur): (Ox, OM'₁) = (Ox, Oy') + (Oy', OM'₁) = 3*Pi/2 - Arctan(x₁/y₁) .
L'angle est nul pour les points situés sur l'axe (y'y), ce qui donne:
(Ox, OM) = Pi/2 (pour y > 0) , ou 3*Pi/2 dans le cas contraire.

2°) Cas où l'on a: Abs(y) < Abs(x) :
Les points (M₂, M'₂), symétriques par rapport à l'origine (O), déterminent le même angle avec le demi-axe correspondant, et ortienté cette fois dans le sens direct; il vient:

(Ox, OM₂) = (Ox', OM'₂) = t₂ = Arctan(y₂/x₂)

et l'on obtient par conséquent:
a) pour x > 0 (secteur à droite): (Ox, OM₂) = Arctan(y₂/x₂) ;
b) pour x < 0 (secteur à gauche): (Ox, OM'₂) = (Ox, Ox') + (Ox', OM'₂) = Pi + Arctan(y₂/x₂) .
L'angle est nul pour les points situés sur l'axe (x'x), ce qui donne:
(Ox, OM) = 0 (pour x > 0) , ou Pi dans le cas contraire.

Remarquer le décalage angulaire d'un demi-tour (Pi radians) observé pour chaque couple de points.

# PS: J'ai dû rectifier un détail du texte source (#13), non dépourvu d'importance (lignes 23 à 27)

Code :

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

1
2
3
4
5
6
 ... / ...
              ELSE BEGIN
                     At:= ArcTan(x / y);
                     IF (y>0) THEN Arad:= H_Pi - At
                              ELSE Arad:= H3_Pi - At
                   END;

Comme quoi il faut toujours se relire

[Jipété]

1°) Les fonctions discontinues (Round(.), Int(.), Trunc(.)) ne doivent pas intervenir en cours de calcul, mais seulement à fin du bloc d'instructions déterminant des valeurs entières (par exemple les composantes d'un pixel).

2°) Chercher la valeur entière d'une distance n'a guère de sens, et encore moins celle d'un angle exprimé en radians ! Tu trouveras dans ce dernier cas 0, 1, 2 ou 3 ...

3°) L'intervention de ces fonctions en calcul interne n'est probablement pas étrangère aux écarts de teinte que l'on observe ... Ces discontinuités non maîtrisables abîment inutilement le calcul, pourtant exécuté ici avec une précision record (2^-63, soit plus de 18 chiffres significatifs !).

Concernant ces histoires de round qui te chiffonnent, je sais qu'il faut l'utiliser tout à la fin des calculs et c'est exactement ce que je fais !
J'ai traduit en langage Pascal la recette de cuisine fournie par Nebulix (

Pour chaque pixel de ton cercle, tu calcules un rayon R (distance au centre) et une phase P (angle du rayon = arc tangente(y/x). Dans ce pixel tu mets la couleur aux coordonnées P,R de ton rectangle.

), et tu noteras que pour accéder aux pixels d'un bitmap, que ça soit par la méthode lente de Canvas.Pixels[w,h] ou plus rapide en utilisant Scanline, il est toujours question d'integer à ce niveau-là, et c'est bien pour ça qu'il y a ces round, on ne peut pas y couper.
En récrivant d'une manière plus précise, on aurait ça :

Code pascal :

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

1
2
3
4
 // pour chaque pixel du cercle
        iDistance := round(sqrt((w-cl)*(w-cl) + (h-ct)*(h-ct))); // calcul du rayon R
        iPhase := round(arctan((h-ct)/(w-cl))); // calcul de la phase
        RedGreenBlue(degrade.canvas.Pixels[iPhase, iDistance], r,g,b); // récup couleur aux coordonnées dans le rectangle

- - -

Concernant le post suivant, tu es en train de nous dire que selon l'endroit où l'on se trouve dans le cercle il faudrait utiliser l'une des 4 formules ?
D'accord, admettons, mais alors, comment expliquer qu'avec une seule formule j'ai quand même la moitié de la surface qui est bonne ? J'aurais tendance à penser que 2 formules seraient suffisantes (sauf que je n'arrive pas à les mettre en forme pour que la rouge-jaune-verte s'affiche en haut)

Sinon, je n'ai pas été capable de faire la différence entre x1 et x2, et y1 et y2, résultat (sans traiter les cas "= 0", j'ai écrit ça ainsi, mais c'est pas terrible :

Code pascal :

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

1
2
3
4
5
6
7
8
        if abs(h-ct) > abs(w-cl) then begin
          if h-ct > 0 then phase := round(ToDegrees(Pi/2 - arctan((h-ct) / (w-cl))));
          if h-ct < 0 then phase := round(ToDegrees(3*Pi/2 - arctan((h-ct) / (w-cl))));
        end;
        if abs(h-ct) < abs(w-cl) then begin
          if w-cl > 0 then phase := round(ToDegrees(arctan((h-ct) / (w-cl))));
          if w-cl < 0 then phase := round(ToDegrees(Pi + arctan((h-ct) / (w-cl))));
        end;

Ce que les mathématiciens appellent y et x, moi je les appelle h(eight) et w(idth), et je rappelle que cl et ct sont les offsets pour le centre du cercle.



Pas glop...
À pluche,

[wiwaxia]

Je n'ai pas le temps de répondre.

Simplement, tâche de remplacer

Code :

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

Phase := arctan((h-ct)/(w-cl));

par

Code :

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

1
2
3
4
 
IF (w<cl) THEN Phase:= arctan((h-ct)/(w-cl)) + Pi
          ELSE IF (w>cl) THEN IF (h>ct) THEN Phase:= arctan((h-ct)/(w-cl))
                                        ELSE Phase:= arctan((h-ct)/(w-cl)) + 2*Pi;

Je n'ose même pas imaginer le cas (w=cl) - peut-être y a-t-il quelque part une instruction de sécurité ? Ou (cl) et (ct) sont-ils des semi-entiers ?
Pour le reste, on verra plus tard.

Ps: Un algorithme complet utilisant Arctan(y/x) serait de la forme:

Code :

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

1
2
3
4
5
6
7
 
IF (w=cl) THEN IF (h>ct) THEN Phase:= Pi/2
                         ELSE IF (h<ct) THEN Phase:= 3*Pi/2
                                        ELSE Phase:= 0  // Instruction de sécurité évitant le plantage
          ELSE IF (w<cl) THEN Phase:= arctan((h-ct)/(w-cl)) + Pi
                         ELSE IF (h>ct) THEN Phase:= arctan((h-ct)/(w-cl))
                                        ELSE Phase:= arctan((h-ct)/(w-cl)) + 2*Pi;

[Jipété]

Ou (cl) et (ct) sont-ils des semi-entiers ?

C'est quoi un semi-entier ?
Non non, ce sont des entiers tout courts, ce sont les coordonnées du centre du cercle dans son container d'affichage.
Genre si le container fait 360x360, le centre est à 180,180 dans le container (un TImage en l'occurrence)
1^er essai avec

Code pascal :

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

1
2
3
4
IF (w<cl) THEN Phase := round(arctan((h-ct)/(w-cl)) + Pi)
ELSE 
IF (w>cl) THEN IF (h>ct) THEN Phase := round(arctan((h-ct)/(w-cl)) + Pi)
                         ELSE Phase := round(arctan((h-ct)/(w-cl)) + 2*Pi);

et bien obligé de mettre round.


Bon, je ne comprends pas ce code (en fait c'est tout le post que je ne comprends pas, désolé)

2^e essai avec (légèrement changé la mise en page)

Code pascal :

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

1
2
3
4
5
6
7
8
IF (w=cl) THEN IF (h>ct) THEN Phase:= round(Pi/2)
          ELSE IF (h<ct) THEN Phase:= round(3*Pi/2)
                         ELSE Phase:= 0  // Instruction de sécurité évitant le plantage
ELSE
IF (w<cl) THEN Phase:= round(arctan((h-ct)/(w-cl)) + Pi)
          ELSE IF (h>ct) THEN Phase:= round(arctan((h-ct)/(w-cl)))
                          // pourquoi n'a-t-on pas la même construction *ici* qu'aux lignes 2 et 3 ?
                         ELSE Phase:= round(arctan((h-ct)/(w-cl)) + 2*Pi);

+++
Bon, pour se détendre, voilà ce que j'ai vu en librairie cet après-midi,


et ce soir à la téloche :

RYB vaincra,

[wiwaxia]

C'est quoi un semi-entier ?

1/2, 3/2, 5/2 ... et plus généralement tout nombre de la forme N + 1/2 .

Code :

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

1
2
IF (w>cl) THEN IF (h>ct) THEN Phase := round(arctan((h-ct)/(w-cl)) + Pi)
                         ELSE Phase := round(arctan((h-ct)/(w-cl)) + 2*Pi);

et bien obligé de mettre round ...

C'est monstrueux ! La fonction Arctan(u) à priori exprimée en radians variant sur un tour de (0) à (2*Pi), son approximation entière ne pourrait prendre que 7 valeurs différentes (de 0 à 6).

Code :

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

1
2
3
4
5
6
7
8
IF (w=cl) THEN IF (h>ct) THEN Phase:= round(Pi/2)
          ELSE IF (h<ct) THEN Phase:= round(3*Pi/2)
                         ELSE Phase:= 0  // Instruction de sécurité évitant le plantage
ELSE
IF (w<cl) THEN Phase:= round(arctan((h-ct)/(w-cl)) + Pi)
          ELSE IF (h>ct) THEN Phase:= round(arctan((h-ct)/(w-cl)))
                          // pourquoi n'a-t-on pas la même construction *ici* qu'aux lignes 2 et 3 ?
                         ELSE Phase:= round(arctan((h-ct)/(w-cl)) + 2*Pi);

L'indentation est défectueuse et fausse complètement la présentation des alternatives ! Tu te montres pourtant très pointilleux sur ce sujet, d'habitude ...
Un bon sommeil réparateur, voilà ce qui s'impose.

[Jipété]

Bonjour,

1/2, 3/2, 5/2 ... et plus généralement tout nombre de la forme N + 1/2.

N + x/2 j'aurais dit, à la vue de tes exemples.
Maintenant, si tu regardes l'aide de ton Pascal, tu y liras (j'espère) qu'il y a une sacrée différence entre "/" et "div" :

• 3/2 donnera 1,5, comme à l'école, et ce 1,5 ne pourra être assigné qu'à une variable de type float (single, double, extended, real, etc.) ;
• 3 div 2 donnera 1, utile pour parcourir des tableaux indexés par des entiers et impossible de faire autrement, il n'existe pas de case à l'index [1.5, 3.14], .

L'indentation est défectueuse et fausse complètement la présentation des alternatives ! Tu te montres pourtant très pointilleux sur ce sujet, d'habitude ...
Un bon sommeil réparateur, voilà ce qui s'impose.

Peut-être. Sans doute. Mais à défaut de comprendre, elle m'a permis de voir des choses, grâce à l'alignement vertical du mot "Phase".

C'est monstrueux ! La fonction Arctan(u) à priori exprimée en radians variant sur un tour de (0) à (2*Pi), son approximation entière ne pourrait prendre que 7 valeurs différentes (de 0 à 6).

Mais bon sang de bois de bon Dieu de b..rdel à Q de chiotte, quand j'ai utilisé hier soir tes formules, j'ai complètement zappé ma trouvaille de la matinée, la fonction ToDegrees !
Et comme tu ne l'utilisais pas, paf !, dans le mur !

Avec ma nouvelle présentation toujours mal indentée,

Code pascal :

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

1
2
3
4
5
6
7
8
IF (w=cl) THEN IF (h>ct) THEN Phase:= round(Pi/2)
          ELSE IF (h<ct) THEN Phase:= round(3*Pi/2)
                         ELSE Phase:= 0  // Instruction de sécurité évitant le plantage
ELSE
IF (w<cl) THEN Phase:= round(ToDegrees(arctan((h-ct)/(w-cl)) + Pi))
          ELSE IF (h>ct) THEN Phase:= round(ToDegrees(arctan((h-ct)/(w-cl))))
          ELSE IF (h<ct) THEN Phase:= round(ToDegrees(arctan((h-ct)/(w-cl)) + 2*Pi))
                         ELSE Phase := 0;

j'arrive à... surprise !

Manque plus que

• tourner dans le bon sens
• faire sauter les petites imperfections (ça sent son +1 ou -1 mal géré, ça)
• aller de blanc à noir en passant par couleur, pour le moment c'est de blanc à couleur.

Allez, encore un effort, on devrait boucler dans une poignée d'heures.

[Jipété]

Ce que je ne comprends pas dans cette formule, c'est que concernant w<>cl, pour la partie gauche du cercle tu ne tries pas sur h>ct ou h<ct, mais pour la partie droite oui.
À moins que je ne me sois gourré, en rajoutant des begin...end; et des commentaires, ça ressemble à ça :

Code pascal :

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

1
2
3
4
5
6
7
8
9
...
ELSE 
begin
IF (w<cl) THEN Phase:= round(ToDegrees(-arctan((h-ct)/(w-cl)) + Pi)) // on est à gauche on ne trie pas sur h>ct ou h<ct
          ELSE // w>cl -- on est à droite, on trie -- why ?
               begin IF (h>ct) THEN Phase:= round(ToDegrees(-arctan((h-ct)/(w-cl)))) // en bas
                               ELSE Phase:= round(ToDegrees(-arctan((h-ct)/(w-cl)) + deuxfoispi)); // en haut
               end;
end;

Le problème, c'est que si je configure la partie droite comme pour la partie gauche, ça fonctionne mal.
Et si je la garde à l'identique, ça fonctionne mal aussi...

À noter : les "-arctan" pour passer les couleurs du bas en haut et lycée de Versailles.

À noter aussi que pour obtenir blanc->couleur->noir, il me faut tricher avec la distance, j'ai déplacé la tricherie un peu plus haut :

Code pascal :

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

1
2
        //distance := round(sqrt(somme_cotesaucarre));
        distance := round(sqrt(somme_cotesaucarre)*2); // :plusser: !

comme ça je récupère mes pixels comme suggéré par Nebulix : RedGreenBlue(map.canvas.Pixels[phase,distance], r,g,b);.
(On verra + tard pour le grand tour blanc (qui mesure 52 pixels d'épaisseur, soit (360 - 255) div 2, 360 le diamètre du cercle, 255 la hauteur (256 pour être précis) du rectangle des couleurs.)


---
EDIT : une piste :

Code pascal :

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

1
2
if phase > 360 then phase := phase - 360;//si ligne commentée, la moitié droite disparaît
RedGreenBlue(map.canvas.Pixels[phase,distance], r,g,b); // blanc à couleur

Et si je remplace la 1^re ligne par if phase < 0 then phase := phase + 360; (car j'avais remarqué des valeurs négatives dans les logs) alors c'est le quart supérieur qui n'est pas dessiné, du coup, en mettant les deux lignes j'ai tout (aux défauts près) :

Code pascal :

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

1
2
3
if phase < 0 then phase := phase + 360;
if phase > 360 then phase := phase - 360;
RedGreenBlue(map.canvas.Pixels[phase,distance], r,g,b);

Un truc cool serait d'avoir des valeurs directement correctes, histoire de s'affranchir de ces deux tests, parce que l'algo n'est vraiment pas rapide (environ 7 secondes pour rendre cette petite image, je n'ose imaginer avec des plus grandes...)

Une dernière info : un examen du cercle à la loupe montre que s'il y a un diamètre vertical rouge et un rayon horizontal blanc à droite (avec un défaut au bout), il n'y a pas de problème du côté gauche.

[wiwaxia]

Le vrai problème, c'est la méthode.

Il faut bien voir que la discrétisation des grandeurs, leur réduction à leur approximation entière entraîne une perte d'information sur la connaissance des teintes locales, et une dégradation irréversible des calculs et de la continuité des couleurs et des dessins.

Tu ne peux donc pas déduire les colorations du cercle chromatique de celles du rectangle. Les deux palettes, pour lesquelles interviennent 5 séries de variables entières - coordonnées (x, y) et composantes (r, v, b) de chaque pixel - doivent au contraire représenter la traduction graphique d'une unique fonction de deux variables, ne faisant intervenir des paramètres réels, sans dimension et si possible au plus égaux à l'unité.

a) Les deux variables à envisager sont ici une distance relative (L) comprise entre zéro et l'unité, et la teinte (T) qui varie entre 0 et 360°.

b) Il intervient par ailleurs deux constantes (L₁, L₂) vérifiant L₁ + L₂ = 1
ainsi que la loi de variation des couleurs à la frontière des deux domaines, sur laquelle la saturation prend sa valeur maximale (S = 1): cette loi s'exprime par la donnée de 3 fonctions variant sur le domaine [0 ; 1], dépendant de la teinte:

Rpal(t) , Vpal(t) , Bpal(t)

et qui représentent les intensités relatives de chaque couleur fondamentale pour la palette considérée.

c) Chaque pixel doit être initialement considéré comme un vecteur de [0 ; 1]³ à 3 composantes réelles comprises entre 0 et 1, ce qui revient à considérer les images comme des champs de vecteurs

C'est à la fin du calcul qu'apparaîtront les composantes (tant) attendues:

r = Round(255*Fr(M)) ; v = Round(255*Fv(M)) ; b = Round(255*Fb(M))

Je crois entendre un grand soupir de soulagement

1°) Cas de la palette rectangulaire: l'image est caractérisée par ses dimensions - largeur (La), hauteur (Ha) - la position de chaque pixel par ses coordonnées (Xm, Ym), qui vérifient:

0 <= Xm < La , 0 <= Ym < Ha

Une relation très simple intervient entre la teinte et l'abscisse: t = 360*Xm/(La - 1) ;
elle est nulle à la limite gauche de l'image (Xm = 0) et maximale à droite (Xm = La - 1) .

a) Dans la partie inférieure sombre, caractérisée par Ym < L₂*Ha , les composantes des couleurs sont proportionnelles à l'ordonnée du point considéré, soit en introduisant la valeur limite Lim = L₂*Ha

Fr(Xm, Ym) = (Ym/Lim)*Rpal(t) , Fv(Xm, Ym) = (Ym/Lim)*Vpal(t) , Fb(Xm, Ym) = (Ym/Lim)*Bpal(t) ;

ces trois égalités sont implicitement contenues dans la relation vectorielle:

Q(Xm, Ym) = (Ym/Lim).Q_ref

dans laquelle le vecteur de référence admet pour composantes: Q_ref = (Rpal(t) , Vpal(t) , Bpal(t)) .

b) Dans la partie supérieure claire (Ym >= Lim), les couleurs évoluent progressivement jusqu'au blanc (vecteur Q₁₁₁ = (1, 1, 1) par la relation linéaire:

Q(Xm, Ym) = (Ym - Lim)/(Ha - 1 - Lim)*Q₁₁₁ + (Ha - 1 -Ym)/(Ha - 1 - Lim)*Q_ref

qui se traduira par 3 relations équivalentes:

Fr(Xm, Ym) = (Ym - Lim)/(Ha - 1 - Lim) + (Ha - 1 -Ym)/(Ha - 1 - Lim)*Rpal(t)

Fv(Xm, Ym) = (Ym - Lim)/(Ha - 1 - Lim) + (Ha - 1 -Ym)/(Ha - 1 - Lim)*Vpal(t)

Fb(Xm, Ym) = (Ym - Lim)/(Ha - 1 - Lim) + (Ha - 1 -Ym)/(Ha - 1 - Lim)*Bpal(t)

2°) Cas de la palette circulaire: elle est caractérisée par le rayon maximal du cercle (Rmax) et les coordonnées de son centre:

Xc = (La - 1)/2 , Yc = (Ha - 1)/2 .

On peut à partir de ces données passer aux coordonnées relatives, qui donnent accès à l'angle polaire du vecteur (CM) ainsi qu'à sa norme (r):

Dx = Xm - Xc ; Dy = Ym - Yc ; r = (Dx² + Dy²)^1/2 ; A = ArgXY2(Dx, Dy) .

L'expression de la teinte est immédiate: T = 360*A/(2*Pi) = (180/Pi)*A .
L'influence de la distance (r) s'exprime comme dans le cas précédent par une fonction continue linéaire en 2 morceaux.

[Jipété]

Bonjour,

Pendant que tu rédigeais de ton côté, je relisais attentivement mon post et la lumière a jailli !

Ce qui mettait la pagaille au niveau de l'affichage, c'est que jusqu'à ce matin il n'y avait qu'un test sur le dépassement de Phase au-delà de 360 et qu'en rajoutant l'autre test sur les valeurs négatives, ça devenait presque bon, voir l'EDIT de mon post précédent.

Alors j'ai repris cette question de tri sur ct, j'ai viré ton test, ça donne ça :

Code pascal :

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

1
2
3
4
5
6
7
8
...
begin
IF (w<cl) THEN Phase:= round(ToDegrees(-arctan((h-ct)/(w-cl)) + Pi)) // on est à gauche -- ça c'est bon
          ELSE // w>cl -- on est à droite
{               IF (h>ct) THEN Phase:= round(ToDegrees(-arctan((h-ct)/(w-cl)) )) // on est à droite - en haut
                         ELSE Phase:= round(ToDegrees(-arctan((h-ct)/(w-cl)) + deuxfoispi)); // en bas }
               Phase:= round(ToDegrees(-arctan((h-ct)/(w-cl)) ))
end;

et ça donne ça :



Plus qu'à supprimer ce diamètre vertical rouge au centre.

Et si les couleurs ne sont pas exactement comme elles devraient être (comme tu l'as écrit), souviens-toi qu'en graphisme, un petit coup de flou arrange bien des choses (yakà voir les bombasses sur papier glacé, photoshopées à mort, )

Faudra que je retouche un poil les rouges parce que si dans le rectangle il est difficile de comparer celui de l'extrême-gauche avec celui de l'extrême-droite (mais où ai-je mis mon gilet ?), quand ils sont à touch-touch dans le cercle, on voit bien qu'ils ne vont pas ensemble. Ah oui, on est samedi, c'est jour de manif,

Je vais étudier ton long post à tête reposée, je ne doute pas qu'il soit plein de vérités (sauf pour le migrant de 5 ans), mais en attendant, ce que je vois, c'est que tu utilises quelque chose qui ne donnera pas un rendu plaisant

L'expression de la teinte est immédiate: T = 360*A/(2*Pi) = (180/Pi)*A .

, car pour arriver au rectangle sympa, il a fallu que je modifie certaines valeurs à la main !
Donc tout ton discours tombe à l'eau (

la teinte (T) qui varie entre 0 et 360°.

-- non, j'ai donné les valeurs au tout début de la discussion. Je te sens peiné, tu m'en vois navré) car il est inutilisable esthétiquement parlant.
As-tu regardé la couverture de Taschen postée hier soir ? Ce n'est pas un rouge 255,000,000 qui est utilisé, et heureusement.

PS : ta pièce jointe n'est pas valide,


EDIT : pour virer ce trait rouge, il suffit d'épurer encore un peu plus ton test, qui devient :

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
      if somme_cotesaucarre <= rayonaucarre then // on est "dans" le cercle
      begin
        distance := round(sqrt(somme_cotesaucarre)*2); // :plusser: !
 
        // test wiwaxia -- merci à lui
        IF w < cl THEN Phase:= round(ToDegrees(-arctan((h-ct)/(w-cl)) + Pi)) // on est à gauche
                  ELSE Phase:= round(ToDegrees(-arctan((h-ct)/(w-cl)))); // w>=cl -- on est à droite
 
        if phase < 0 then phase := phase + 360;
        if phase > 360 then phase := phase - 360;
        RedGreenBlue(map.canvas.Pixels[phase,distance], r,g,b); // Nebulix -- merci aussi à lui
 
        pb[w].rgbRed   := r;
        pb[w].rgbGreen := g;
        pb[w].rgbBlue  := b;
        pb[w].rgbReserved:= 255;
      end;

Et ça donne du bonheur :



Plus qu'à reprendre la map de couleurs pour le raccord des rouges, et le "blanc" du cercle. Stay tuned !

[Jipété]

Code pascal :

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

1
2
3
4
5
6
7
8
9
10
11
12
      if somme_cotesaucarre <= rayonaucarre then // on est "dans" le cercle
      begin
      //distance := round( sqrt(somme_cotesaucarre) );
      //distance := round( sqrt(somme_cotesaucarre) *2 );
        distance := round( sqrt(somme_cotesaucarre *2) ); // +10 000 !
 
        IF w < 0 THEN Phase:= round(ToDegrees(-arctan(h/w) + Pi)) // on est à gauche
                 ELSE Phase:= round(ToDegrees(-arctan(h/w))); // on est à droite
 
        if phase < 0   then phase := phase + 360;
        //if phase > 360 then phase := phase - 360;// inutile
        if phase = 360 then phase := 0;

Plus que l'adaptation des rouges, et l'optimisation (parce que là, 12 secondes, )

[wiwaxia]

Mon exposé précédent n'est pas terminé, mais il me reste peu à ajouter, et je le mettrai en rallonge.

Je tente de répondre pour le mieux à tes remarques, nombreuses et diverses, ce qui n'est pas facile ...

... PS : ta pièce jointe n'est pas valide,

Merci pour l'info: j'ai rectifié cela. Les images ont tendance à s'évaporer en ce moment, lors de l'envoi du message.

... Je vais étudier ton long post à tête reposée, je ne doute pas qu'il soit plein de vérités ... mais en attendant, ce que je vois, c'est que tu utilises quelque chose qui ne donnera pas un rendu plaisant ,
W: L'expression de la teinte est immédiate: T = 360*A/(2*Pi) = (180/Pi)*A .
car pour arriver au rectangle sympa, il a fallu que je modifie certaines valeurs à la main !
Donc tout ton discours tombe à l'eau
W: la teinte (T) qui varie entre 0 et 360°.
( -- non, j'ai donné les valeurs au tout début de la discussion. Je te sens peiné, tu m'en vois navré) car il est inutilisable esthétiquement parlant ...

J'ai retenu cet angle exprimé en degrés, et non un paramètre abstrait variant entre 0 et 1, parce que cela me paraissait pratique et tout à fait parlant. Tu avais exprimé une opinion semblable, m'avait-il semblé, au début de ce forum:

... alors voici d'abord une petite image RGB, avec à droite un dégradé classique généré par calcul, et à gauche en utilisant une conversion HSL_to_RGB pour avoir le cercle (c'est pratique, un cercle a 360° et le "H" de HSL travaille aussi sur 360°)  ...

... En fait, il "suffirait" de partir des points blancs en haut du rectangle et de tous les regrouper au centre du cercle pour de là, dessiner 360 arcs-de-cercle remplis chacun d'une couleur représentée par une "colonne" du rectangle ...

Cela appelle plusieurs réponses:
1°) Le choix de ce paramètre ne préjuge en rien des dimensions de l'image, qui peut présenter une largeur égale à 180, 256, 360 ou 667 pixels; une simple règle de trois conduira à la valeur correspondante de la teinte.

2°) Il m'est déjà arrivé de réaliser toutes sortes de palettes, et l'agrément des teintes observées est liée à la présence d'au moins une composante particulièrement forte (dépassant 230 env.): la lumière constitue donc un facteur déterminant.
S'il s'agit maintenant d'étendre le domaine de certaines nuances (l'orange, par exemple) au détriment d'autres moins appréciées (le cyan), il suffit de modifier en conséquence les fonctions de couleur - ce qui a été proposé par anapurna (#04) et moi-même (#15); il y a d'ailleurs une autre méthode que j'aurais voulu tester, mais je n'en ai pas eu le temps.

3°) Il apparaît un point plus ennuyeux: le projet de division du cercle en 360 secteurs identiques - qu'on en prenne 180 ou 240 ne change rien à l'affaire); un cercle de diamètre 400 pixels (par exemple) résultera de l'assemblage de 360 arcs longs d'environ 3.5 pixels: risque de crénelage des contours, de zébrures radiales dans les teintes.
Quant à transformer les colonnes du rectangle en rayons, cela produira un chevauchement qui ne laissera subsister que le dernier segment tracé. L'idée est justifiée mais irréalisable, parce que la transformation d'un rectangle en cercle ne conserve pas les longueurs.
Il faut renoncer aux listes de teintes, lourdes et partiellement incalculables, et envisager une fonction vectorielle à deux variables réelles du genre Pixel = F(x, y) = G(r, θ) .

4°) Toujours à propos de la discrétisation des angles:

... Mais bon sang de bois ****************** quand j'ai utilisé hier soir tes formules, j'ai complètement zappé ma trouvaille de la matinée, la fonction ToDegrees !
Et comme tu ne l'utilisais pas, paf !, dans le mur ! ...

Le filtre parental fait actuellement des siennes, je me demande bien pourquoi ...
Je me doutais bien que si ton programme fonctionne, c'est que tu avais codé des instructions apparentées à

Code :

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

Phase:= round(180/Pi*(arctan((h-ct)/(w-cl))))

J'ai réagi à l'énormité écrite.

... Et si les couleurs ne sont pas exactement comme elles devraient être (comme tu l'as écrit), souviens-toi qu'en graphisme, un petit coup de flou arrange bien des choses (yakà voir les bombasses sur papier glacé, photoshopées à mort, ) ... !

Je ressens cela comme une tricherie tout à fait scandaleuse !
Et le floutage des couleurs atténue les contrastes, et fait évoluer les teintes vers le gris: l'effet ne me paraît pas bénéfique.

... Plus qu'à supprimer ce diamètre vertical rouge au centre ...

Faudra que je retouche un poil les rouges parce que si dans le rectangle il est difficile de comparer celui de l'extrême-gauche avec celui de l'extrême-droite (mais où ai-je mis mon gilet ?), quand ils sont à touch-touch dans le cercle, on voit bien qu'ils ne vont pas ensemble ...
... car pour arriver au rectangle sympa, il a fallu que je modifie certaines valeurs à la main !
... pour virer ce trait rouge, il suffit d'épurer encore un peu plus ton test, qui devient :
... Plus qu'à reprendre la map de couleurs pour le raccord des rouges, et le "blanc" du cercle. Stay tuned !

Tu pourrais t'interroger sur la nécessité des retouches manuelles, et le défaut de rationalité qu'elles révèlent ... J'avoue que ta désinvolture algorithmique me laisse pantois.

Ce qui est étonnant, c'est que le programme fonctionne, malgré le traitement très rock'n roll que tu infliges à la fonction Arctan(y/x): il y a probablement en interne des balises de sécurité qui permettent de contourner la division par zéro.

Je viens de voir la dernière image: c'est pas mal, mais il faut mieux raccorder les teintes rouges des extrémités.

[Jipété]

J'ai retenu cet angle exprimé en degrés, et non un paramètre abstrait variant entre 0 et 1, parce que cela me paraissait pratique et tout à fait parlant. Tu avais exprimé une opinion semblable, m'avait-il semblé, au début de ce forum:

J'avais surtout dit que c'était une manière de faire. Une, parmi d'autres ! Et le cahier des charges ne l'imposait pas, d'autant plus qu'on se souvient que le rendu esthétique est plus que moyen, en suivant cette voie.

3°) Il apparaît un point plus ennuyeux: le projet de division du cercle en 360 secteurs identiques - qu'on en prenne 180 ou 240 ne change rien à l'affaire); un cercle de diamètre 400 pixels (par exemple) résultera de l'assemblage de 360 arcs longs d'environ 3.5 pixels: risque de crénelage des contours, de zébrures radiales dans les teintes.
Quant à transformer les colonnes du rectangle en rayons, cela produira un chevauchement qui ne laissera subsister que le dernier segment tracé. L'idée est justifiée mais irréalisable, parce que la transformation d'un rectangle en cercle ne conserve pas les longueurs.

Et pourtant, quand on regarde le résultat, je suis très satisfait, si si

Il faut renoncer aux listes de teintes, lourdes et partiellement incalculables, et envisager une fonction vectorielle à deux variables réelles du genre Pixel = F(x, y) = G(r, θ) .

Euh, oui, en français stp !
Que je ne sais même pas comment saisir ce caractère au bout de ta formule, et je ne me souviens pas de ce qui se cache dessous...

4°) Toujours à propos de la discrétisation des angles:

Je ressens cela comme une tricherie tout à fait scandaleuse !
Et le floutage des couleurs atténue les contrastes, et fait évoluer les teintes vers le gris: l'effet ne me paraît pas bénéfique.

Tu pourrais t'interroger sur la nécessité des retouches manuelles, et le défaut de rationalité qu'elles révèlent ... J'avoue que ta désinvolture algorithmique me laisse pantois.

Le floutage c'est comme tout : faut pas en abuser, juste un soupçon, avec parcimonie, et c'est bon.
D'ailleurs si je me souviens bien, le rectangle est flouté car au départ il est fabriqué à partir de 24 colonnes de couleurs indépendantes (voir la map dans le 1^er post).

Ce qui est étonnant, c'est que le programme fonctionne, malgré le traitement très rock'n roll que tu infliges à la fonction Arctan(y/x): il y a probablement en interne des balises de sécurité qui permettent de contourner la division par zéro.

1) l'informatique c'est parfois magique ;
2) concernant les balises de sécurité, je n'en connais pas et je n'y crois pas, c'est juste que nulle part je ne fais de division dont le diviseur pourrait être à zéro et pi valà !

Je viens de voir la dernière image: c'est pas mal, mais il faut mieux raccorder les teintes rouges des extrémités.

Merci.
Les raccords, c'est prévu depuis ce matin, je l'écris à chaque fois ! Tu radotes,

Bon, allez, vous allez tomber par terre en lisant les commentaires au bas du code :

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
29
30
31
32
33
34
35
  aBmp.BeginUpdate();
  pxsource := pRGBTriple(map.RawImage.GetLineStart(0)); // pointeur pour accès ultra-rapide
  for h := -radius to radius do begin
    h_aucarre := h*h;
    pb := pRGBQuad(aBmp.RawImage.GetLineStart(h+ct));
    for w := -radius to radius do begin
      somme_cotesaucarre := w*w + h_aucarre;
      if somme_cotesaucarre <= rayonaucarre then // on est "dans" le cercle
      begin
        //distance := round(sqrt(somme_cotesaucarre));
        //distance := round(sqrt(somme_cotesaucarre)*2);
        distance := round(sqrt(somme_cotesaucarre*2));
 
        IF w < 0 THEN Phase:= round(ToDegrees(-arctan(h/w) + Pi)) // on est à gauche
                 ELSE Phase:= round(ToDegrees(-arctan(h/w))); // on est à droite
 
        //if phase < 0   then phase := phase + 360;// inutile
        //if phase > 360 then phase := phase - 360;// inutile
        //if phase = 360 then phase := 0;// inutile
 
{       RedGreenBlue(map.canvas.Pixels[phase,distance], r,g,b); // 12 secondes.........
        pb[w+cl].rgbtRed   := r;
        pb[w+cl].rgbtGreen := g;
        pb[w+cl].rgbtBlue  := b;       
        pb[w+cl].rgbReserved:=255;   }
 
        idx := (distance * 360) + phase; // --> une fraction de seconde <--
        pb[w+cl].rgbRed   := pxsource[idx].rgbtRed;
        pb[w+cl].rgbGreen := pxsource[idx].rgbtGreen;
        pb[w+cl].rgbBlue  := pxsource[idx].rgbtBlue;
        pb[w+cl].rgbReserved:=255;
      end;
    end;
  end;
  aBmp.EndUpdate();

Résultat :



Oui, je sais, faut retoucher les rouges, et peut-être un chouchouille à la jonction des verts -- dans la map, pas dans le cercle,


EDIT : y a pas d'mal à s'faire du bien, hein,

[Jipété]

concernant les balises de sécurité, je n'en connais pas et je n'y crois pas, c'est juste que nulle part je ne fais de division dont le diviseur pourrait être à zéro et pi valà !

J'ai dit une bêtise en fin de journée, à propos de la non-survenue d'une erreur sur division par zéro : il y a un cas où ça se produit, et ce qui est curieux, c'est que ça ne remonte pas d'erreur :
puisque w varie de -rayon à +rayon, il va fatalement y avoir un moment où w = 0 et là, c'est la section ELSE de la formule qui s'applique :

Code pascal :

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

1
2
        IF w < 0 THEN Phase:= round(ToDegrees(-arctan(h/w) + Pi)) // on est à gauche
                 ELSE Phase:= round(ToDegrees(-arctan(h/w))); // on est à droite

Et quand on est au centre du cercle, c'est carrément -arctan( 0/0 ) ! Je ne sais pas pourquoi la machine n'explose pas...

---
Et sinon, en changeant le diamètre du cercle, c'est la misère, exemple avec 240 :
que je conserve 360 dans la formule idx := (distance * 360) + phase; :

ou que je lui applique une règle de 3 :

ça n'est pas glorieux.

Et avec 410, ça aurait pu être bon mais voilà les artefacts, on est près du bord droit, juste au-dessus du diamètre horizontal :


Je ne dois pas appliquer la règle de 3 comme il faut, mais je ne vois pas trop où ni comment...

C'est dommage parce que j'ai corrigé le raccord des rouges et c'est bien, c'est très bien :

[wiwaxia]

Elles sont très bien ces palettes, qu'a tu à leur reprocher ?

Le raccord des tons est parfait.

W:Il faut renoncer aux listes de teintes, lourdes et partiellement incalculables, et envisager une fonction vectorielle à deux variables réelles du genre Pixel = F(x, y) = G(r, θ) .

... Euh, oui, en français stp !
Que je ne sais même pas comment saisir ce caractère au bout de ta formule, et je ne me souviens pas de ce qui se cache dessous ...

Effectivement, je me suis mal exprimé en voulant faire vite.
L'équation Pixel = F(x, y) est du type de celle que tu utilises sur la palette rectangulaire lorsque tu exprimes les composantes du pixel en fonction de ses coordonnées cartésiennes.
Pixel = G(r, θ) est l'équation utilisée dans la palette circulaire; les composantes des couleurs (r, v, b) dépendent alors de la distance (r = CM),du point considéré au centre de l'image, et de l'angle polaire θ ("thêta") - la phase dont tu as parlé.

W: Ce qui est étonnant, c'est que le programme fonctionne, malgré le traitement très rock'n roll que tu infliges à la fonction Arctan(y/x): il y a probablement en interne des balises de sécurité qui permettent de contourner la division par zéro.
... 1) l'informatique c'est parfois magique ;
2) concernant les balises de sécurité, je n'en connais pas et je n'y crois pas, c'est juste que nulle part je ne fais de division dont le diviseur pourrait être à zéro et pi valà !

Ces instructions existent vraiment, j'en ai mis une dans la fonction que je t'ai proposée: ArgXY2(0, 0) retourne la valeur zéro, alors que ArgXY2(x, y) n'est pas définie à l'origine.
La fonction du Pascal Arctan2(y, x) a un comportement similaire; cela évite le plantage très déplaisant du programme.

L'expression que tu as citée (arctan((h-ct)/(w-cl)) sans te soucier du cas particulier (w = cl) m'a donné des sueurs froides ... Mais enfin l'essentiel, c'est que tu aies obtenu un résultat.

Voici ce que j'ai commencé à obtenir, par l'algorithme sur lequel je reviendrai. La bande cyan paraît beaucoup trop importante; il faut voir ce que ça donne dans un cercle.

[Jipété]

Bonjour,

Elles sont très bien ces palettes, qu'as-tu à leur reprocher ?

Rien à celle de droite, c'est le but recherché.
Mais si tu ne remarques pas à gauche qu'il manque toutes les teintes sombres, il va te falloir consulter en urgence, ou faire réviser ton écran,

Merci pour les explications sur la phase, je verrai ça.
EDIT : j'ai vu, mais ça ne me dit pas comment l'utiliser (j'en vois au fond qui se poussent du coude en rigolant et en me montrant du doigt "rhôôô le boulet". Ben oui...) /EDIT

La fonction du Pascal Arctan2(y, x) a un comportement similaire; cela évite le plantage très déplaisant du programme.

Jamais constaté de plantage. Et tu as des similitudes qui me laissent pantois, de bon matin :

Code pascal :

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

1
2
3
4
5
        distance := round(sqrt(somme_cotesaucarre*2));
//      IF w < 0 THEN Phase:= round(ToDegrees(-arctan(h/w) + Pi)) // on est à gauche
  //             ELSE Phase:= round(ToDegrees(-arctan(h/w))); // on est à droite
        IF w < 0 THEN Phase:= round(ToDegrees(-arctan2(h,w) + Pi)) // on est à gauche
                 ELSE Phase:= round(ToDegrees(-arctan2(h,w))); // on est à droite

Et si j'enlève la fonction de conversion ToDegrees j'obtiens un magnifique cercle rouge dégradé de blanc à noir.

Voici ce que j'ai commencé à obtenir, par l'algorithme sur lequel je reviendrai. La bande cyan paraît beaucoup trop importante; il faut voir ce que ça donne dans un cercle.

Pas mieux, après conversion linéaire (merci Gimp ) de ton 300x300 vers mon 360x256 nécessaire :

D'où la mise en place d'une map, permettant des retouches à la mano sur la zone en défaut,
Map dont la hauteur est fixée à 256 car en mettre moins ferait sauter des valeurs et en mettre plus en doublerait certaines : restons simples.
Faites-moi penser à fournir la nouvelle, bricolée hier soir.

---
Pour l'heure, je voudrais m'affranchir de la contrainte (que tu avais à peine soulevée) de la dimension du cercle, bloquée à l'heure actuelle à un diamètre de 360 pixels, surement lié à la largeur du rectangle des colonnes de couleurs, soit 360 pixels aussi, par construction.

Faut que je réfléchisse très fort ! (mais je ne sais pas dans quelle direction... )

[wiwaxia]

... Mais si tu ne remarques pas à gauche qu'il manque toutes les teintes sombres, il va te falloir consulter en urgence, ou faire réviser ton écran, ...

Je l'avais effectivement bien vu, et je parlais uniquement de la répartition des teintes.
Ce serait encore mieux à droite si tu pouvais restreindre le domaine des teintes sombres; mais là, c'est une affaire de goût personnel.

... Et tu as des similitudes qui me laissent pantois, de bon matin :

Code pascal :

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

1
2
3
4
5
        distance := round(sqrt(somme_cotesaucarre*2));
//      IF w < 0 THEN Phase:= round(ToDegrees(-arctan(h/w) + Pi)) // on est à gauche
  //             ELSE Phase:= round(ToDegrees(-arctan(h/w))); // on est à droite
        IF w < 0 THEN Phase:= round(ToDegrees(-arctan2(h,w) + Pi)) // on est à gauche
                 ELSE Phase:= round(ToDegrees(-arctan2(h,w))); // on est à droite

Il y a eu mélange des deux fonctions ... En serais-je la cause ?
Tu as le choix entre trois options:
a) employer la fonction que j'ai proposée: ArgXY2(x, y) dont les valeurs se situent sur le domaine semi-ouvert [0 ; 2*Pi[ ;
b) employer la fonction standard Arctan2(y, x) dont les valeurs appartiennent au semi-ouvert centré sur zéro [-Pi ; +Pi[ ;
on se ramène alors au cas précédent par les instructions supplémentaires:

Code :

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

1
2
Arad:= Arctan2(y, x); 
IF (Arad<0) THEN BEGIN A1:= Arad + Pi; Arad:= A1 END;

c) recourir à la fonction paléolithique Arctan(y/x) assortie de la casuistique déjà décrite (#24)

Code :

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

1
2
3
4
5
6
    IF (x=0) THEN IF (y>0) THEN Phase:= Pi/2
                           ELSE IF (y<0) THEN Phase:= 3*Pi/2
                                         ELSE Phase:= 0  // Échappatoire évitant le plantage
             ELSE IF (x<0) THEN Phase:= arctan(y/x) + Pi
                           ELSE IF (y>x) THEN Phase:= arctan(y/x)
                                         ELSE Phase:= arctan(y/x) + 2*Pi;

... Et si j'enlève la fonction de conversion ToDegrees j'obtiens un magnifique cercle rouge dégradé de blanc à noir ...

Je crois, pour l'avoir expérimenté, que la fonction ToDegree(.) effectue la conversion des angles exprimés en radians à leur valeur en degrés.
Curieusement, je me suis aperçu que l'appel de cette fonction ralentit l'exécution du calcul; il est plus rapide, une fois déclarée la constante Rad_Deg = 180/Pi de faire

Code :

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

Arad:= Arctan2(y, x); Adeg:= Rad_Deg * Arad

que d'appeler

Code :

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

Adeg:= ToDegree(Arctan2(y, x))

Question de distance algorithmique, trop rarement évoquée, et qui avait été discutée il y a quelques années.

Zapper cette fonction revient à limiter la phase à 6°, donc à rester dans le rouge.

... Pas mieux, après conversion linéaire (merci Gimp ) de ton 300x300 vers mon 360x256 nécessaire ...

Je comprends mieux le problème: les couleurs sont à leur place, mais il faut absolument atténuer le cyan pur en (0, m, m), avec m < 255 . Cela doit pouvoir se programmer, sans retouches manuelles - j'ai une petite idée là-dessus, sans garantie de résultat satisfaisant.

... Pour l'heure, je voudrais m'affranchir de la contrainte (que tu avais à peine soulevée) de la dimension du cercle, bloquée à l'heure actuelle à un diamètre de 360 pixels, surement lié à la largeur du rectangle des colonnes de couleurs, soit 360 pixels aussi, par construction.

Faut que je réfléchisse très fort ! (mais je ne sais pas dans quelle direction... )

Cela ne pose aucune difficulté dès qu'on s'affranchit de l'esclavage des nombres entiers, et qu'on travaille sur les réels. Cela correspond à la fin du programme encours, et que je termine aussi vite que possible.

[wiwaxia]

... Pour l'heure, je voudrais m'affranchir de la contrainte (que tu avais à peine soulevée) de la dimension du cercle, bloquée à l'heure actuelle à un diamètre de 360 pixels, surement lié à la largeur du rectangle des colonnes de couleurs, soit 360 pixels aussi, par construction.

Faut que je réfléchisse très fort ! (mais je ne sais pas dans quelle direction... )

1°) Tu choisis deux constantes (R1, R2) vérifiant 0 < R1 < R2 < 1
par exemple: R1 = 0.65 et R2 = 0.96.
Le rayon du cercle chromatique est Rmax = R2 * Min(Larg_Image, Haut_Image) ,
celui de la zone claire: Rlim = R1 * Min(Larg_Image, Haut_Image) .

2°) (d) représentant la distance d'un point quelconque (M) au centre (C) du cercle:
d = ((x - Xc)² + (y - Yc)²)^1/2 ,
on envisage la distance relative r = d / Min(Larg_Image, Haut_Image) , par définition inférieure à l'unité ;
et de même l'intensité relative d'une composante de couleur (Comp = r, v ou b, < 256) dépendant de la phase considérée:
Ic = Comp / 255 .

3°) On peut alors envisager une fonction affine en deux morceaux Jc = F(r, Ic):
a) dans la zone claire (r < R1): Jc = 1 - (1 - Ic)*r/R1 , qui donne
# pour r = 0 , Jc = 1 (valeur maximale au centre);
# pour r = R1 , Jc = 1 - (1 - Ic) = Ic ;
b) dans la zone sombre (R1 < r < R2): Jc = Ic*(1 - (r - R1)/(R2 - R1)), qui donne maintenant:
# pour r = R1: Jc = Ic*(1 - 0) = Ic (il y a bien continuité en ce point);
# pour r = R2: Jc = Ic*(1 - 1) = 0 (c'est le bord du cercle chromatique).

Il ne reste plus qu'à calculer la composante correspondante de la couleur locale, en utilisant (enfin !) la fonction d'arrondi (juste récompense du programmeur persévérant):
C(x, y) = Round(255 * Jc) .

[Jipété]

Curieusement, je me suis aperçu que l'appel de cette fonction [ToDegrees] ralentit l'exécution du calcul; il est plus rapide, une fois déclarée la constante Rad_Deg = 180/Pi de faire

Code :

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

Arad:= Arctan2(y, x); Adeg:= Rad_Deg * Arad

que d'appeler

Code :

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

Adeg:= ToDegrees(Arctan2(y, x))

Alors ça, ça m'épate (de mouche !), pour la bonne et simple raison que ta manip est strictement la même que la ToDegrees que j'utilise :

Code pascal :

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

1
2
3
4
function ToDegrees(radians: double): double; inline;
begin
  result := radians * 57.2957795130823; // radians * (180.0 / Math.PI)
end;

D'ailleurs je l'ai mise en place, ta manip, sans noter de différence particulière.
Avec la paléolithique arctan, puisque la moderne arctan2 n'est capable que de me générer des ballons de plage...

Tiens, à ce propos, en suivant le lien vers les sources Lazarus de arctan2, on tombe sur

Code pascal :

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

1
2
{ calculates arctan(y/x) and returns an angle in the correct quadrant }
function arctan2(y,x : float) : float;

Tiens tiens...
Hélas, en allant voir plus profond, ça cause en protopaléolithique archaïque, et pour moi, là, laisse tomber :

Code pascal :

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

1
2
3
4
5
6
7
8
9
{$ASMMODE ATT}
{$define FPC_MATH_HAS_ARCTAN2}
function arctan2(y,x : float) : float;assembler;
  asm
     fldt y
     fldt x
     fpatan
     fwait
  end;

Strictement rien compris à l'autre post, où tu me cites quand j'interroge sur les dimensions de l'objet cible et que tu nous réponds avec un discours ciblant la modification du rendu blanc/noir (que je reconnais, que j'admets, que je vais étudier [dès que j'aurai compris pourquoi tu nous parles d'un point quelconque (M) dont il n'est plus du tout question après.])

1°) Tu choisis deux constantes (R1, R2) vérifiant 0 < R1 < R2 < 1
par exemple: R1 = 0.65 et R2 = 0.96.

Et à ce propos, pourquoi 0,65 et 0.96 ? Complètement arbitraires ou tu as une petite idée derrière la tête ?

Ah, j'allais oublier : deux cadeaux, découverts lors de manips pour avancer dans le redimensionnement :

Mettre la souris sur l'image, son nom donnera une indication.

Mince, j'espérais ne pas dépasser les deux pages, mais c'est mort, on dirait.

[wiwaxia]

Alors ça, ça m'épate, pour la bonne et simple raison que ta manip est strictement la même que la ToDegrees que j'utilise :

Code pascal :

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

1
2
3
4
function ToDegrees(radians: double): double; inline;
begin
  result := radians * 57.2957795130823; // radians * (180.0 / Math.PI)
end;

D'ailleurs je l'ai mise en place, ta manip, sans noter de différence particulière ...

J'ai effectivement confondu ta fonction avec RadToDeg(.)

Code :

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

function RadToDeg(Radians: Extended): Extended;  { Degrees := Radians * 180 / PI }

disponible dans Virtual Pascal (et probablement Free P.), dont je n'avais qu'un lointain souvenir et dans un contexte très particulier - celui de fonctions emboîtées. J'ai trouvé ici le même temps d'exécution (environ 22 ns).

... Avec la paléolithique arctan ...

Je ne sais pas quel est le statut exact de cette fonction; Virtual Pascal ne connaît officiellement que Arctan2(., .)

Code :

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

1
2
3
  	{ ArcTan2 calculates ArcTan(Y/X), and returns an angle in the correct quadrant.
    		IN: |Y| < 2^64, |X| < 2^64, X <> 0   OUT: [-PI..PI] radians }
function ArcTan2(Y, X: Extended): Extended;

J'ai l'impression qu'il intervient pour cette fonction (et quelques autres) une tolérance du logiciel pour quelques instructions du Turbo Pascal; il faudrait demander aux spécialistes.
Il me revient à l'instant que j'ai dû demander, lors de l'installation, la compatibilité avec les anciennes versions du Pascal.

Ici la fonction ne retourne apparemment que les angles de l'intervalle [-Pi/2 ; +Pi/2]; il serait intéressant de voir comment tu l'as utilisée.
C'est une fonction standard (voir plus haut), et ses variations ont été vérifiées dans un tableau (#19).

... Strictement rien compris à l'autre post, où tu me cites quand j'interroge sur les dimensions de l'objet cible et que tu nous réponds avec un discours ciblant la modification du rendu blanc/noir (que je reconnais, que j'admets, que je vais étudier [dès que j'aurai compris pourquoi tu nous parles d'un point quelconque (M) dont il n'est plus du tout question après.]) ...

(M) est un point quelconque de la portion de plan couvert par l'image, qui peut se trouver à l'intérieur du petit cercle (CM < Rlim), à l'intérieur seulement du grand cercle (Rlim <= CM < Rmax) ou en dehors de ce dernier (Rmax <= CM).
Les lois de variation des couleurs ne sont pas les mêmes suivant le domaine envisagé:

région claire / région sombre / fond de l'extérieur

... Et à ce propos, pourquoi 0,65 et 0.96 ? Complètement arbitraires ou tu as une petite idée derrière la tête ? ...

Ce sont des exemples, rien de plus. Cela signifie que le diamètre du cercle chromatique vaut 96 % de la plus petite des dimensions de l'image.

... deux cadeaux, découverts lors de manips pour avancer dans le redimensionnement ...

J'aime bien ces images. La deuxième est une représentation graphique de l'argument d'un point du plan complexe z = x + i.y .