# Gnral Dveloppement > Algorithme & Mathmatiques > Traitement d'images >  Uniformisation de couleurs dans un dgrad : comment faire ?

## Jipt

Bonjour,

Le traitement mathmatique des couleurs n'tant pas trop ma tasse de th, j'ai besoin d'un petit coup de pouce pour (essayer de) convertir l'image colore ci-dessous en une autre image colore qui se comporterait comme l'image en niveaux de gris, qui est bien lisse et uniforme, avec un dgrad bien rgulier.


L'image en couleur est construite  partir d'un algo classique d'arc-en-ciel de gauche  droite mtin de dgrad de haut en bas, le tout  base des couleurs R,G,B pures de 0  255 (source).
Le dgrad gris c'est l'image en couleur trafique par The Gimp  qui j'ai demand une dsaturation et qui m'a propos 3 options, celle qu'on voit c'est le choix _Lightness_ dont l'aide me dit :



> The graylevel will be calculated as
> Lightness = ½ × (max(R,G,B) + min(R,G,B))


Alors dans ma tentative de traitement j'ai bien extrait les composantes H,S,L de l'image et j'ai appliqu cette formule  L avant de rencoder pour affichage, mais a me donne une image psychdlique dont on dirait qu'elle a t peinte sous acide en coutant Jerry Garcia...  ::wow:: 
J'ai tent de rajouter une option de balayage vertical avec formule * h/(Height-1) ("h" c'est le compteur de boucle pour le balayage vertical) mais pas mieux...  ::(: 

J'en suis l, alors si quelqu'un a une ide, je la lirai avec grand plaisir (pour peu qu'elle soit crite avec des mots simples  ::mrgreen:: ).

Merci,

----------


## anapurna

salut 

pourquoi appliquer cette formule a L ? 
il te donne la formule pour trouver le L a partir du RGB  
Soit ta valeur RGB X 




> R'= R/255
> G' = G/255
> B' = B/255
> 
> Cmax := max(R',G',B')
> Cmin := min(R',G',B')
> Delta := Cmax-Cmin


Pour trouver H (la teinte):



> Si  delta = 0  alors H = 0
> si Cmax = R' alors H = 60 *(((G'-B')/Delta) mod 6) // cas du rouge
> si Cmax = G' alors H = 60 *(((B'-R')/Delta)+2) // cas du vert
> si Cmax = B' alors H = 60 *(((R'-G')/Delta)+4) // cas du vert


Pour le ligtness (ou luminance ...tu connais la formule mais bon je la redonne)



> L= (Cmax+Cmin)/2


pour trouver S (saturation)



> Si  delta = 0  alors S = 0
> sinon S = delta/(1-Abs(2*L-1))


pour faire l'inverse 

il te faut calculer quelque lments 




> C  = ((1-Abs(2*L-1))*S  // valeur dtermin par la saturation 
> X  = C*(1-abs(((H/60) mod 2) -1) // valeur dfini par la teinte  
> m = L - C/2  // valeur dfini par la  luminance





> si H est entre 0 et 60 Alors Col' =[C,X,0]
> si H est entre 60 et 120 Alors Col' =[X,C,0]
> si H est entre 120 et 180 Alors Col' =[0,C,X]
> si H est entre 180 et 240 Alors Col' =[0,X,C]
> si H est entre 240 et 300 Alors Col' =[X,0,C]
> si H est entre 240 et 300 Alors Col' =[C,0,X]


on replace tout 




> COLRGB =  RGB((Col'[0]+m)*255,(Col'[1]+m)*255,(Col'[2]+m)*255);

----------


## Jipt

Salut salut (mais tu es partout  ::mouarf:: )




> pourquoi appliquer cette formule  L ?


Parce que je n'avais pas d'autre ide, et que j'tais loin de pouvoir envisager les calculs que tu as posts...




> il te faut calculer quelque lments


Et c'est l que a se complique :



> X = C*(1-abs(((H/60) mod 2) -1) // valeur dfinie par la teinte


Cette cochonnerie de Lazarus ne sait pas appliquer "mod" sur des float, et je n'arrive pas  trouver l'quivalent pour des float... Et tu sais ce que c'est que l'aide de Lazarus : il te faut connatre le mot pour esprer de l'aide dessus, le serpent qui se mord la queue...
Bref, je suis coinc l, en plus j'ai du mal  dcoder ce que tu veux, il y a une parenthse ouvrante de trop (ou une fermante absente : auquel cas, o serait-elle ?)




> si H est entre 0 et 60 Alors Col' =[C,X,0]


Et Col' pour toi c'est quoi ? Une Array[0..2] de byte ?

Merci,

----------


## anapurna

salut 

si tu fait une division entire au lieu d'une division cela marchera peut tre mieux 


> abs(((H DIV 60) mod 2)


sinon un tableau d'entier pour la question sur le tableau

----------


## anapurna

salut 

il y a plus simple ^^
unit graphutil.pp  voir ici

----------


## Jipt

> salut 
> 
> il y a plus simple ^^
> unit graphutil.pp  voir ici


Ben non, parce qu'il faut modifier L, sinon on se retrouve avec l'image d'origine (test ce matin)

Mais sinon on approche :


Comme a jusqu'au bout  droite. C'est un joli rouge  ::lol:: 

La question est : est-ce que j'ai bien fait (je ne mets que la partie balayage horizontal) :


```

```


Et ce qui me fait peur c'est de travailler avec des integer quand H,S et L sont des float : je vais perdre la prcision des float...

----------


## Jipt

J'ai rajout une ligne de log pour essayer de comprendre :


```

```

 
et voil ce que j'ai relev ( 393xxx lignes,quand mme !) :


```

```

Du dbut  la fin X est  0, c'est pas top je crois !

 X := round(C*(1-Abs((round(H) div 60) mod 2)-1)); 

Entre les round et les div, je sens bien que a nous fout dedans...

----------


## anapurna

salut 

effectivement tu perd de la prcision 
par contre je ne vois pas ce qui tempche d'utiliser les fonction prdfinie dans graphutil
il existe suffisament de fonction pour le faire voir par l 
sinon pour pas trop perdre tu peut peut etre multiplier par 100 

pour trouver le mod d'un nombre c'est assez simple 



> amod := Avalue - round(Avalue / adiv) ;

----------


## Jipt

> salut 
> 
> effectivement tu perds de la prcision 
> par contre je ne vois pas ce qui tempche d'utiliser les fonctions prdfinies dans graphutil


Je te l'ai dit tout--l'heure, a ne va pas me faire varier L... Rflchis : si pour tous les points de l'image, 1 par 1, je les convertis de RGB en HSL puis de HSL en RGB a m'avance  quoi ?
Il *faut* une intervention mathmatique entre les deux conversions mais je ne sais pas laquelle...




> pour trouver le mod d'un nombre c'est assez simple


Rsultat image noire rouge  blanc comme tout--l'heure (erreur de commentaires mal mis/mal enlevs), car tu ne m'as toujours pas dit o tait l'erreur avec les parenthses, que je t'ai signale : une en trop ou une en moins, et o ?



> X := C*(1-abs(((H/60) mod 2) -1); // valeur définie par la teinte


Compte : 4 ouvrantes et 3 fermantes, a ne peut pas aller !

----------


## anapurna

Salut 




> X := C*(1-abs(((H/60) mod 2) -1)); // valeur dfinie par la teinte


oups j'ai oubli la dernire parenthse


PS : le simple fait de dcrmenter ou incrmenter L devrais suffire non ? 
Il faut que tu borne simplement ta valeur entre o et 100 
la luminance et la saturation sont des pourcentage

----------


## Jipt

> Salut 
> 
> 
> 
> oups j'ai oubli la dernire parenthse


 ::ptdr:: 

Mais sinon, toujours cette double image rouge d'un bout  l'autre et c'est tout...

D'ailleurs, tiens, pour changer a : 
L := (MaxValue([rgbRed,rgbGreen,rgbBlue]) + MinValue([rgbRed,rgbGreen,rgbBlue])) * 0.25; // 2 fois l'img divisée par 2 avec 0.5 (qui est le standard) 

On n'est pas loin, mais on n'y est pas...




> PS : le simple fait de dcrmenter ou incrmenter L devrait suffire non ?


Non, il faut rcuprer H et le faire dgrader (de haut en bas) et corriger (par le L calcul), au fur et  mesure de l'avancement horizontal. Enfin, c'est comme a que je vois la chose.

Bon, j'ai faim  ::mrgreen:: 

Bon app,  pluche ou  demain...

----------


## Jipt

> pour trouver le mod d'un nombre c'est assez simple
> 
> 
> 
> 
>  Envoy par anapurna
> 
> 
> amod := Avalue - round(Avalue / adiv) ;


T'es sr de a ? Parce que j'ai vrifi et c'est un poil plus compliqu (pour les float ; pas vrifi pour les integer) : aMod := aValue - (Trunc(aValue / aDiv)) * aDiv;

```

```

 



> il te faut calculer quelque lments 
> 
> 
> 
> 
>  Envoy par anapurna
> 
> 
> C = ((1-Abs(2*L-1))*S // valeur dtermine par la saturation
> ...


Elles sortent d'o, ces formules ?
Et tu es sr de ton coup, pour la 3e ligne ? Parce que par exemple, selon comment on met les parenthses


```

```

Bon, j'ai tout repris ligne  ligne, j'avais d louper une parenthse, maintenant je n'ai mme plus de dgrad uniforme  ::aie::  :

Et c'est comme a jusqu'au bord droit... Tu noteras que tout en haut et au milieu il y a une ligne d'une autre couleur.

Un truc que je ne comprends pas dans ton premier post, c'est tout ce dveloppement pour extraire HSL alors que j'ai une fonction pour le faire, relis mon code, au dbut il y a 

```

```

Alors pourquoi le refaire ?
Car je rcupre des pRGBQuad (ss pour "source", on ne s'occupe pas du 4e octet pour la transparence) et ma fonction extrait tout bien, plus qu' retravailler et c'est l que je coince.

Bon, la nuit porte conseil, comme dit le proverbe  ::):

----------


## anapurna

salut 

ah oui pour le amod j'ai oublier de multiplier par le diviseur 

les formule sont celle qui permet de passer du RGB au HSL et vis et versa => donc normalement sans modification de la couleur 
toutes ces formules sont dispo sur wiki  vers le bas de page

----------


## Jipt

Yep !



> toutes ces formules sont dispo sur wiki  vers le bas de page


ah oui, je les ai souvent vues, moi j'ai utilis celles qu'on trouve ici, bien sympathiques aussi.

Ceci tant dit, je crois que ma demande est irralisable... J'ai fait des tests, ce matin : j'ai gnr une image d'arc-en-ciel uniforme sans dgrads de blanc vers noir et une autre image noir et blanc de dgrad de blanc vers noir, je les ai mises ensemble comme 2 calques dans Gimp et j'ai essay toutes les possibilits de fusion de calques sans arriver  ce que je cherche.

J'en conclus que ce n'est pas possible, alors on ne va pas se prendre la tte plus que a... Faut savoir laisser tomber, des fois.

Merci pour le temps que tu y as pass.

----------


## tbc92

On peut reprendre au tout dbut ?

Pour obtenir le dgrad en question, on te dit : L =  ( max ( R,G,B) + min ( R,G,B)  ) /2 
Cette formule est embtante,car elle combine les composantes RGB, et les composantes HSL

Si tu veux utiliser cette transformation, en travaillant avec les composantes RGB uniquement, a donne :
x = ( max ( R,G,B) + min ( R,G,B)  ) /2 
R = x
G = x
B = x
Je ne suis pas tout  fait sr que ce soit exactement a, mais la diffrence ne sera pas visible  l'oeil nu.


Et si tu veux travailler avec les composantes HSL uniquement, a donne :
L = inchang
S = 0
H = ce que tu veux ; quand S vaut 0, H n'a pas d'effet.

----------


## Jipt

> On peut reprendre au tout dbut ?
> 
> Pour obtenir le dgrad en question, on te dit : L =  ( max ( R,G,B) + min ( R,G,B)  ) /2 
> Cette formule est embtante,car elle combine les composantes RGB, et les composantes HSL
> 
> Si tu veux utiliser cette transformation, en travaillant avec les composantes RGB uniquement, a donne :
> x = ( max ( R,G,B) + min ( R,G,B)  ) /2 
> R = x
> G = x
> ...


En utilisant cette formule, je gagne un trs joli, trs doux et trs dlicat dgrad de... gris  ::mouarf:: 
C'est le mme en couleurs que j'aurais voulu mais, comme je le disais ce matin, je crois bien que ce n'est pas possible.

Par ailleurs, quand tu dis "_Cette formule est embtante, car elle combine les composantes RGB, et les composantes HSL_", je ne vois pas o c'est embtant, dans la mesure o les composantes HSL sont extraites par calcul des composantes RGB : je dirais que c'est la mme chose prsente autrement.

'fin bon, de toute faon, ce que j'avais bien not ce matin, c'est qu'en travaillant avec H,S,L, je me suis rendu compte qu'en fixant L  0.5 par ex. pendant tout le processus (just 4 tests), le dgrad n'tait pas parfait : prsence d'artefacts dans les premires et dernires lignes, ce qui me fait supposer que jouer uniquement avec L ne serait pas suffisant.

Cette image est dforme pour bien faire apparatre les dfauts : suppression de la partie intermdiaire, compression de la largeur et tirement de la hauteur.
Et en fait l'algo pour cette image est tout bte : je rcupre H,S,L, je n'applique aucun traitement, je me contente de fixer L  0.5 je fais rencoder et afficher et voil.

C'est pour a que je lche l'affaire ( moins que quelqu'un ait la formule mathmatique de la mort qui tue  ::mrgreen:: ).

----------


## tbc92

Adaptons un tout petit peu, pour avoir un dgrad de rouge par exemple : (Dgrad entre blanc et rouge)


```

```

A vrifier selon les outils, mais je pense que la valeur 255 est la bonne.   ( si besoin, pour le vrifier, affiche les valeurs R , G et B qui correspondent  la couleur Blanc)

Tu peux aussi t'amuser en testant a  (dgrad entre rouge et vert) :


```

```

----------


## anapurna

salut 

pour viter les dbordement tu peut utiliser un min normalement ce n'est pas possible dans le cas present mais 
cela est toujours bon de borner pour le jour ou on modifie son code et pour la division par deux prfre un DIV il te donneras un entier plutt 



```
x = Min( (max ( R,G,B) + min ( R,G,B) ) DIV 2 ,255)
```

----------


## Jipt

> pour viter les dbordement tu peut utiliser un min normalement ce n'est pas possible dans le cas present mais 
> cela est toujours bon de borner pour le jour ou on modifie son code


Bah, ce n'est pas a qui tait utilis lors de la gnration des artefacts : juste la rcupration sans modif de H et S, et passage de L  0.5.




> Adaptons un tout petit peu, pour avoir un dgrad de rouge par exemple : (Dgrad entre blanc et rouge)
> 
> Tu peux aussi t'amuser en testant a  (dgrad entre rouge et vert)


Oui, c'est gentil  toi mais je connais ces manips, ce n'es pas le dgrad d'une couleur qui m'intresse, c'est le dgrad de toute l'image. Tu me diras que l'image n'est jamais qu'une suite de colonnes, chacune avec sa couleur, dgrade de blanc vers noir, je sais bien et c'est pour a que j'essayais de jouer sur le L, sans bons rsultats.

Je reste persuad que ce que nous voyons dans l'arc-en-ciel dgrad du 1er post et qui me dplat (d'o cette discussion) est en fait impossible  annuler, et ces effets visuels dsagrables sont juste normaux.
D'ailleurs en faisant des copies d'cran de zones "moches" (le triangle bleu fonc, la croix au milieu du jaune, par ex.) et en zoomant, l'effet "moche" n'est plus du tout visible.

----------


## anapurna

salut 

si je comprend bien tu veut soit augmenter la luminosit soit le contraste sur toutes l'image donc le paramtre ne dois pas varier d'un pixel a l'autre 

dans ce cas tu peut appliquer ces formules  

pour claircir 
//Luminosit :
R := round(R * ( 1 + intens / 100));
G := round(G * ( 1 + intens / 100));
B := round(B * ( 1 + intens / 100));

pour foncer
//Contraste:
R := round(R + intens / 100 * (R-127));
G := round(G + intens / 100 * (G-127));
B := round(B + intens / 100 * (B-127));


n'oublie pas le min pour borner a 255 
et le max pour borner a 0 


```
Max(0,min(mavaleur,255))
```

----------


## Jipt

> salut 
> 
> si je comprend bien [...]


Perdu !

Ou alors c'est moi qui me suis mal exprim (pourtant, il me semblait qu'avec les 2 images du premier post c'tait clair, mais faut croire que non...)

Bon, j'ai trafiqu a :



C'est extrait du grand dgrad,  gauche j'ai comprim le bout rcupr (256 -> 128),  droite c'est le mme bout, je l'ai grave tir (256 -> 1024), et qu'est-ce qu'on voit ?
 gauche un triangle magenta et dans une moindre mesure un triangle cyan, d'accord ?
H bien c'est a que je voulais faire disparatre, sauf que ce n'est pas possible, car c'est ni plus ni moins la construction de l'image, colonne par colonne, qui est comme a.

Et  droite on voit assez bien un trait lumineux qui parcourt l'image au milieu, horizontalement, surtout dans les zones claires (quasiment invisible dans le bleu fonc).
H bien, tu sais quoi ? Tu prends un colorpicker et tu constateras que ce trait n'existe pas, c'est juste une *illusion d'optique*.
Et s'il n'existe pas, comment le faire disparatre, mmmh ?  ::ptdr:: 

Je t'ai dit de laisser tomber !  ::mrgreen::

----------


## anapurna

salut 

ah oui je vois le problme ... pour bien faire il faut t'appuyer sur les pixel alentour et appliquer une correction selon la valeur trouv
c'est plus un filtre qu'autre chose que tu veut mettre en place

salut

regarde ici si l'un des filtre ne correspondrais pas a ce que tu veut faire ?

----------


## Jipt

Salut salut,



> regarde ici si l'un des filtres ne correspondrait pas  ce que tu veux faire ?


J'ai regard ton lien, toutes les pages, si si ! et tu veux que je te dise mon sentiment profond, face  ce genre de document prvu pour proposer des comparaisons ? On ne peut rien comparer !

Car pour comparer il faut avoir les choses  comparer visibles en mme temps et l, ce n'est pas du tout le cas  ::aie:: 
Alors oui, tu peux comparer diffrents rglages d'un filtre, mais comparer les filtres entre eux est impossible, donc je passe mon chemin,  moins de tout refaire, et je n'ai pas envie de passer deux jours  faire de la pao pour au final me rendre compte que, de toute faon, il n'y a pas de solution  ma question, comme je m'vertue  l'crire depuis hier ou avant-hier.

Le dfaut qu'on voit c'est un effet visuel, une illusion d'optique, *il n'y a pas de dfaut*.

Et tiens, un exemple de document o l'on peut comparer diffrentes options (a concerne le choix de l'option d'interpolation en cas de resize d'une image [et malheureusement, je dcouvre  l'instant que le document a t rcemment converti en pdf, donc tu chercheras l'image 12 en page 9 {z'avaient vraiment pas besoin de faire a...  ::roll:: }]).
Quant au reste du document, je n'y comprends absolument rien,  ::mouarf::

----------


## wiwaxia

Bonjour,  ::D: 

Cet change livre plein d'informations intressantes, mais je trouve qu'il n'a pas apport de rponse claire  la demande initiale.




> ... Le traitement mathmatique des couleurs n'tant pas trop ma tasse de th, j'ai besoin d'un petit coup de pouce pour (essayer de) convertir l'image colore ci-dessous en une autre image colore qui se comporterait comme l'image en niveaux de gris, qui est bien lisse et uniforme, avec un dgrad bien rgulier ...


Transformer une image colore en une autre ne comportant que des niveaux de gris ... / *Texte supprim - Passage hors-sujet* / ...




> ... Alors dans ma tentative de traitement j'ai bien extrait les composantes H,S,L de l'image et j'ai appliqu cette formule  L avant de rencoder pour affichage, mais a me donne une image psychdlique dont on dirait qu'elle a t peinte sous acide en coutant Jerry Garcia... 
> J'ai tent de rajouter une option de balayage vertical avec formule * h/(Height-1) ("h" c'est le compteur de boucle pour le balayage vertical) mais pas mieux...


L, j'aurais t curieux de voir le rsultat. J'ai effectivement vu des choses surprenantes quand par exemple l'une des composantes (r, v, b) reoit une valeur dpassant 255.

PS: Les illusions observes sur les images numriques ont toujours une explication au niveau de l'algorithme; quand il s'agit de l'arc-en-ciel, ou de tout dgrad entre 2 couleurs, cela vient gnralement d'un paramtrage beaucoup trop fruste des composantes (r, v, b) = F(t), qui utilise des fonctions affines par morceaux: l'oeuil, qui peroit toujours un ensemble de pixels voisins, dtecte inconsciemment la brusque disparition de l'une des composantes. Un bidouillage avec Paint ne dtectera rien; c'est en rentrant dans l'algorithme dfinissant la fonction F(t) que vous trouverez l'explication.

----------


## Jipt

> Cet change livre plein d'informations intressantes, mais je trouve qu'il n'a pas apport de rponse claire  la demande initiale.


*la demande initiale tait une erreur*




> Envoy par Jipt
> 
> 
> ... (essayer de) convertir l'image colore ci-dessous en *une autre image colore* qui se comporterait *comme* l'image en niveaux de gris
> 
> 
> Transformer une image colore en une autre ne comportant que des niveaux de gris ...


Mais tu as vu/lu a o, toi ?




> L, j'aurais t curieux de voir le rsultat. Il apparat des choses surprenantes quand par exemple l'une des composantes (r, v, b) reoit (accidentellement) une valeur dpassant 255.


Too late, je l'ai vire...

----------


## wiwaxia

> Et  droite on voit assez bien un trait lumineux qui parcourt l'image au milieu, horizontalement, surtout dans les zones claires (quasiment invisible dans le bleu fonc).
> H bien, tu sais quoi ? Tu prends un colorpicker et tu constateras que ce trait n'existe pas, c'est juste une *illusion d'optique*.
> *Et s'il n'existe pas, comment le faire disparatre, mmmh ?*


En utilisant des fonctions continument drivables, c.a.d. dont le graphe ne prsente pas de rupture de pente (ou, si l'on veut, de point anguleux). Voir le prcdent message, qui n'tait pas compltement  ct de la plaque. ::aie:: 
Et en effectuant tous les calculs intermdiaires sur des rels.

----------


## Jipt

> En utilisant des fonctions continument drivables, c.a.d. dont le graphe ne prsente pas de rupture de pente (ou, si l'on veut, de point anguleux)...


Ben dis donc, heureusement que j'avais prcis a, dans le post d'origine :



> Le traitement mathmatique des couleurs n'tant pas trop ma tasse de th [...], si quelqu'un a une ide, je la lirai avec grand plaisir (pour peu qu'elle soit crite avec des *mots simples* ).


Comment veux-tu que je traduise des _fonctions  continument drivables_ en lignes genre for i := 0 to qqqchse-1 do if blabla then machin else bidule ? J'en suis parfaitement incapable.
 ::ptdr::   ::ptdr::   ::ptdr:: 

Tiens, cadeau, comme je mets plein de code pourri en commentaires, ben j'ai dcomment, juste pour toi !

----------


## wiwaxia

Cool Raoul !  ::lol::  Je serais constern d'apprendre qu'un minent expert de l'quipe a t frapp d'AVC lors de la rception de l'un de mes messages ... Et si, pour ma part, il m'tait arriv un coup de sang  chaque notion inconnue aborde sur ce forum, je me serais retrouv depuis longtemps en fauteuil roulant, avec interdiction absolue de consulter un clbre site pour Programmeurs & IT Pro.

Les nombreuses franges colores qu'on observe dans l'image jointe dcoulent de la discontinuit qui accompagne immanquablement le dpassement de la limite (255); ainsi dans l'extrait ci-dessous:

la coloration dcoule essentiellement des instructions: b = 0 ; v = 255 ; r = Round(F(x, y)) ,
et ds que le dernier terme dpasse (256*k - 1) la couleur change sans transition du jaune au vert.
Il intervient d'ailleurs d'autres termes semblables, car l'observation de l'image sous fort grossissement fait apparatre d'autres rseaux de franges, plus discrets.
Il y a aussi deux lignes fantmes verticales, situes au tiers  partir de chaque extrmit, et probablement dues  des ruptures de p/ houl, je ne vais pas ramener le mot qui fche.

En change de bons procds - et bien que je ne sois pas tout  fait convaincu de ton entire bienveillance - voici quelques images retrouves dans mes archives. Cordialement, W.

----------


## Jipt

> Cool Raoul !  Je serais constern d'apprendre qu'un minent expert de l'quipe a t frapp d'AVC lors de la rception de l'un de mes messages...


Oh, tu sais, expert de rien du tout si ce n'est de l'augmentation automatique du compteur de points  chaque message, truc dbile s'il en est...




> Les nombreuses franges colores qu'on observe dans l'image jointe dcoulent de la discontinuit qui accompagne immanquablement le dpassement de la limite (255); ainsi dans l'extrait ci-dessous:
> 
> la coloration dcoule essentiellement des instructions: b = 0 ; v = 255 ; r = Round(F(x, y)) ,
> et ds que le dernier terme dpasse (256*k - 1) la couleur change sans transition du jaune au vert.
> Il intervient d'ailleurs d'autres termes semblables, car l'observation de l'image sous fort grossissement fait apparatre d'autres rseaux de franges, plus discrets.


Citation intressante, dont j'avais dj vcu les effets lors d'erreurs de codage, et dont je vais me permettre de la rapprocher d'un truc que tu as post puis supprim (mais pourquoi ? C'tait intressant -- et comme je reois par mail les infos de mise  jour de certains sujets o je suis abonn, avec le texte post !, profitons-en et j'en fais profiter la communaut) :



> PS: Les illusions observes sur les images numriques ont toujours une explication au niveau de l'algorithme; quand il s'agit de l'arc-en-ciel, ou de tout dgrad entre 2 couleurs, cela vient gnralement d'un paramtrage beaucoup trop fruste des composantes (r, v, b) = F(t), qui utilise des fonctions affines par morceaux: l'oeuil, qui peroit toujours un ensemble de pixels voisins, dtecte inconsciemment la brusque disparition de l'une des composantes. Un bidouillage avec Paint ne dtectera rien; c'est en rentrant dans l'algorithme dfinissant la fonction F(t) que vous trouverez l'explication.


En ce qui concerne mon arc-en-ciel (algo d'origine dans le 1er post, auquel j'ai rajout le dgrad vertical), c'est tout simple et il n'y a qu'une couleur qui change  la fois par pas de 1 et avec contrle du dbordement, en gros c'est a :
 (source wikipdia mais je n'ai pas not l'url, dsol).

Hier j'ai essay un truc mais c'est moche : je suis parti de l'ide que si j'ai du rouge  bloc (255,0,0), il n'y a, d'un point de vue hardware (et en considrant un bon vieux moniteur cathodique muni de ses 3 canons  lectrons c'est plus parlant), qu'un seul canal activ ; si maintenant je fais "monter" le vert pour aller vers le jaune, quand celui-ci sera bien brillant (255,255,0) j'aurai 2 sources d'clairage  bloc, donc (en gros) 2 fois plus de lumire, donc le jaune sera 2 fois plus lumineux que le rouge ou le vert tout seul.

J'ai donc tent de baisser le rouge quand le vert monte, histoire d'avoir toujours R+V+B = 255 max, rsultat, au croisement (127,127,0) j'ai un jaunasse tout moche et terne et pisseux.
Conclusion : on ne peut pas viter de monter  2 fois 255 pour avoir les couleurs complmentaires, et donc 2 fois plus d'clairage sur la dalle, et voil.
Bah...




> En change de bons procds - et bien que je ne sois pas tout  fait convaincu de ton entire bienveillance - voici quelques images retrouves dans mes archives. Cordialement, W.


Rh, tu me prtes des intentions impures ! Merci pour tes images, certaines me donnent envie de ressortir un vinyle de Jimi ou peut-tre mme de l'Airplane lors des concerts au Fillmore, bon sang, o j'ai mis mon buvard,  ::ptdr:: 

Bon dimanche,

----------


## wiwaxia

Bonsoir,  ::D: 

De nombreux sujets ont t abords, et les commenter tous serait trop long - en une fois tout au moins. Mais comme je m'intresse  l'imagerie numrique, je rpondrai sur deux points.

# A propos du spectre des couleurs fondamentales, que tu as donn et qui figure dans un article de Wikipdia - *Teinte Saturation Valeur*: j'avais dj eu l'occasion de programmer cette construction en utilisant une fonction linaire par morceaux, de priode gale  2 et dfinie sur le domaine [-1 ; 1]; rien de nouveau en soi, par rapport  ce qui est reprsent sur le schma.



Je voulais signaler que l'on n'est nullement tenu de s'en tenir  la fonction linaire u(t) lorsqu'elle varie entre (0) et (1); son remplacement par v = u2 , v = u4 ou v = 1 - (1 - u2)1/2

  

"aplatit" les graphes correspondants sur l'axe horizontal (auxquels ils se raccordent dsormais tangentiellement), et restreint encore plus les domaines des couleurs secondaires (cyan, jaune et magenta).
Le recours  des fonctions telles que v = u1/2  ou v = (1 - (1 - u)2)1/2

 

pour lesquelles la variation au voisinage de zro est beaucoup plus rapide (il y a maintenant des tangentes verticales aux points de raccordement), largit au contraire les domaines de ces couleurs.
On obtient dans l'avant-dernier cas une rpartition plus quilibre des teintes qu'avec la fonction linaire.
Le recours  la racine carre (v = u1/2) constitue ainsi une solution pratique, lorsqu'un dgrad de couleurs s'avre ncessaire (pour reprsenter par exemple les variations d'une fonction F(x, y)).
Il faudrait cependant disposer d'une famille de fonctions, pour voir quelle est la plus approprie pour la rpartition des couleurs - mais on entre videmment l dans un domaine subjectif; il s'agit pour l'essentiel de s'loigner au plus vite de la rgion des teintes sombres et indiscernables ( Max(r, v, b) <= 150 env.) On m'a rapport que la NASA r-hausse les teintes de ses photos par l'emploi d'une fonction logarithmique, mais je n'ai pas trouv de lien  ce sujet.

# Au sujet du dgrad ralis entre deux couleurs arbitraires: une simple combinaison linaire conduit gnralement  des rsultats dcevants, la coloration de la zone mdiane apparaissant sombre et assez laide. Une solution pas (trop) complique consiste  faire intervenir la moyenne des indices maximaux de chacune des couleurs initiales: 
Mcmax = (1 - x)*Max(r1, v1, b1) + x*Max(r2, v2, b2) ,
toujours suprieure  la valeur maximale des indices moyens: Max(r, v, b), et  multiplier chacun de ces indices:
c = (1 - x)*c1 * x*c2 (c = r, v ou b)
par le rapport q = Mcmax / Max(r, v, b) suprieur  l'unit, pour obtenir lle nouvel indice de couleur: c' = q * c .
La zone mdiane n'apparat jamais plus sombre, dans ces conditions. Cependant la prsence frquente d'une brusque rupture de pente peut produire une variation trop brutale de la teinte.

 

Le calcul, cod en Pascal, se lit sans difficult (j'espre).


```

```


Je dcouvre en relisant ce texte mon penchant spontan pour les solutions compliques; des formules telles que: 
c = ((c1n)*(1 - x) + (c2n)*x)1/n - avec n = 2 ou 4  , ou mieux encore:
c = c1 + (c2 - c1)*x + |c2 - c1|*g*x*(1 - x) [ avec 0 < g <=1 ] peuvent convenir.

# Un article intressant sur la *Couleur*, donnant des indications sur les domaines de longueur d'onde, et la sensibilit de la rtine humaine.

----------


## Jipt

Salut bonsoir,

trs jolies images, intressantes explications, mais (malheureusement pour moi) nous ne sommes pas du mme monde : je suis totalement hermtique (et crois bien que je le regrette)  des notions qui te semblent parfaitement videntes.

Par exemple, quand tu cris 


> Le recours  la racine carre (v = u1/2) constitue ainsi une solution pratique, lorsqu'un dgrad de couleurs s'avre ncessaire (pour reprsenter par exemple les variations d'une fonction F(x, y)).


 je me demande comment ton cerveau fait pour sortir des trucs pareils, que je suis parfaitement incapable de conceptualiser, imaginer, mettre en code...

Exactement comme si je m'asseyais devant un piano et que j'appuie sur une touche, n'importe laquelle (en plus, avec moi, n'importe quelle touche appuye gnrera une infme bouillie sonore, n'est pas Keith Jarrett qui veut, hein) : il y a plein de gens qui sauront exactement sur quelle touche appuyer ensuite pour que l'ensemble soit harmonieux alors que moi, tu reviens trois jours plus tard je suis toujours devant le clavier  me demander celle que je vais choisir.
Tu vois le truc ?

Revenons  nos moutons : j'ai bien aim ces graphiques sous les dgrads, qui reprsentent comment les r g et b sont trafiqus par les fonctions, et je me suis dit que si j'essayais une bte fonction sinusodale a pourrait peut-tre faire quelque chose d'intressant.
Mais je suis totalement incapable de passer du mot "sinusodale"  quelque chose  insrer entre begin et end;.
Voil mon gros, mon norme souci dans ce domaine.

Ah oui, j'ai furet sur le web, mais je ne dois pas utiliser les bons mots-cl, rsultat je rentre bredouille.  ::cry:: 

Et quand tu donnes une fonction en Pascal (qui se lit trs bien), je ne sais pas comment la mettre en uvre ; c'est bte, hein...

----------


## wiwaxia

Salut,  ::D: 

Je suis un peu dcontenanc, parce que depuis le dbut de ces changes:
a) tu parles de Lazarus et de l'une de ses units (GraphUtil), ce qui implique la matrise de Free Pascal;
b) tu livres un bloc d'instructions en Pascal, discutable mais cohrent; 
c) tu as cr 3 fichiers de dgrad de teintes - peut-tre en utilisant Gimp - et l'une de ces images (la bleue) implique l'intervention d'une fonction de 2 variables (couleur = f(x), intensit = g(y)): cela suppose une certaine exprience en programmation.

Nous avons tous des bagages trs diffrents en maths et en informatique, et ces deux matires prsentent une telle diversit que l'on peut se retrouver totalement dmuni sur un sujet particulier ... d'o l'intrt des changes sur le Forum !

La premire srie d'images provenait d'un ancien programme de synthse de fichiers Bitmap en Turbo Pascal, sur mon cher et vieux PC quip de Windows XP; la deuxime d'une seconde version plus maniable, crite en Virtual Pascal et excute sur portable sous Windows 7. 
Quant au graphisme 3D, j'utilise POV-Ray (bonne occasion de manier le C++); les calculs sont excuts en Pascal, de mme que l'criture des scripts. Les moyens employs sont donc trs loin du High Tech dernier cri ... Mais la programmation est pour moi une priorit, et la configuration et la matrise des logiciels exigeant beaucoup de temps, je m'en tiens,  ce qui marche et donne les rsultats attendus.




> ... je suis totalement hermtique (et crois bien que je le regrette)  des notions qui te semblent parfaitement videntes.
> Par exemple, quand tu cris .../...
> je me demande comment ton cerveau fait pour sortir des trucs pareils, que je suis parfaitement incapable de conceptualiser, imaginer, mettre en code...
> ... Mais je suis totalement incapable de passer du mot "sinusodale"  quelque chose  insrer entre begin et end;.
> Voil mon gros, mon norme souci dans ce domaine.


Simple question de familiarit avec un algorithme particulier; une fois la premire variante obtenue, toutes les autres paraissent videntes! Ton blocage vient aussi du bloc d'instructions effroyablement compliqu destin au calcul des pixels, et pratiquement impossible  modifier.

Lazarus dispose de moyens puissants, et doit te permettre d'atteindre n'importe quel pixel de coordonnes (x, y) d'une image - tu le connais mieux que moi.
Si l'on dispose d'une fonction priodique u(t) variant entre (0) et (1) - peu importe que la priode (Pe) soit prise gale 2 ou 360 - les indices de couleur dcoulent des instructions:


```

```

Le remplacement de (u) par (u1/2) dcoule alors de l'insertion d'une nouvelle instruction;


```

```


Je peux donner le code comment de la fonction u(t), si cela t'intresse.




> ... j'ai furet sur le web ... je rentre bredouille.


J'ai vrifi les liens, qui paraissent fonctionner.

----------


## Jipt

Bonjour bonjour,



> Ton blocage vient aussi du bloc d'instructions effroyablement compliqu destin au calcul des pixels, et pratiquement impossible  modifier.


De quel bloc d'instructions parles-tu ?




> c) tu as cr 3 fichiers de dgrad de teintes - peut-tre en utilisant Gimp - et l'une de ces images (la bleue) implique l'intervention d'une fonction de 2 variables (couleur = f(x), intensit = g(y)): cela suppose une certaine exprience en programmation.


Pas une des images fournies n'a ncessit Gimp (sauf aprs gnration, si je voulais agrandir ou rduire ou zoomer sur une partie pour des besoins d'illustration du texte).
Tout a t fait avec des formules trouves ici et l et que j'ai adaptes  ma sauce, au pif, en modifiant un paramtre dans un sens puis dans l'autre et en notant ce qui se passait, jusqu' trouver une logique.
Ben oui, je fonctionne  l'envers,  ::mouarf:: 




> Je peux donner le code comment de la fonction u(t), si cela t'intresse.


Grandement ! Mme pas t'imagines  quel point a m'intresse mais je n'osais pas le demander, d'autant plus que, comme dit hier,
1- je n'aurais jamais eu l'ide d'utiliser quelque part la fonction u(t) ;
2- pourquoi u(t) et pas u(t*2) ou u(t/2) ou n'importe quoi d'autre ? Il y a des gens qui en auront une "vision" et qui sauront o ils vont, hlas pas moi dans ce domaine.
C'est comme a.
Mais je me dbrouille avec ce que je sais faire.




> Envoy par jipt
> 
> ... j'ai furet sur le web ... je rentre bredouille.
> 
> 
> J'ai vrifi les liens, qui paraissent fonctionner.


Je ne parlais pas de tes liens (que j'ai suivis), je parlais de mots-cl utiliss pour mes recherches en esprant tomber sur des bouts de code exploitables (et c'est comme a que je suis tomb sur l'arc-en-ciel du dbut,  qui j'ai d'ailleurs propos une microscopique correction, qu'on trouve dans les discussions aprs l'article, tout en bas)

----------


## wiwaxia

Salut,  ::D: 

1)


> De quel bloc d'instructions parles-tu ?


Du sous-programme post le 24/10/2016  17h58


```

```

Il y a des erreurs manifestes (sans doute rectifies depuis longtemps) - un lapsus a rendu toutes les conditions toujours fausses; il fallait crire:


```

```

L'appel de ScanLine est sans doute une bonne ide, mais la finalit de la conversion (RGB/HSL/RGB) m'chappe totalement: l'inversion des fonctions Max() et Min() conduit  un bourbier algorithmique (la preuve plus haut !). La recherche d'un dgrad  luminosit (L) constante pouvait s'exprimer en fin de calcul, par introduction d'un facteur correctif.
Mais ce qui plombe vritablement ton algorithme, c'est l'*embotement de fonctions discontinues* (dont tu es apparemment coutumier) qui rend les calculs inintelligibles et incontrlables. Exemples:


```
 C := round((1-Abs(2*L-1))*S);     X := round(C*(1-Abs((round(H) div 60) mod 2)-1));
```

 ::calim2::  5 fonctions: l, je cale !
Composer plusieurs fonctions selon le schma y = H(G(F(x))) est trs discutable (c'est un point de programmation que d'autres pourraient commenter beaucoup mieux que moi), et  pratiquer avec mesure et discernement; cela parat plus rapide, mais l'absence de tout terme intermdiaire rend pratiquement impossible l'analyse du code lorsque les fonctions employes cumulent les singularits.

2) 


> Tout a t fait avec des formules trouves ici et l et que j'ai adaptes  ma sauce, au pif, en modifiant un paramtre dans un sens puis dans l'autre et en notant ce qui se passait, jusqu' trouver une logique.


Le procd des essais/erreurs entrane gnralement une norme dperdition de temps et d'nergie; et cumuler des lignes de code tires de diffrentes sources constitue un bon moyen de tourner en bourrique  ::aie::  compte tenu de la diversit des notations, des conventions et des types de solutions ... sans mme parler des erreurs qui peuvent mailler les textes.
La comprhension vient quand on est capable de r-crire des instructions, avec une notation personnelle. 

3) Soit dans ce qui suit une fonction relle d'une variable relle (t), initialement dfinie sur [-1; +1], domaine choisi pour sa simplicit; si l'on doit plus loin envisager une construction circulaire, le passage  un angle est immdiatement possible, par les relations:
Ad = 180* t (en degrs) ou Ar = Pi * t (en radians), qui permettent de couvrir un tour entier.
Il s'agit d'une fonction paire, priodique et de priode gale  (2); son graphe comporte entre autres un segment inclin passant par les points A(1/3 ; 1) et B(2/3 ; 0) et situ sur la droite d'quation: y = 2 - (3*t) .

a) Priodicit: la fonction recherche tant associe  une premire couleur (par ex. le vert), il en interviendra deux autres dont les graphes sont horizontalement dcals du prcdent d'un tiers de priode (soit 2/3); d'o un dbordement de part et d'autre du domaine initial, puisqu'il faudra envisager des abscisses vrifiant:
t1 <= 1 + 2/3 = 5/3 et t >= -1 - 2/3 = -5/3 .
On procdera donc  un premier changement de variable (t -> u):


```

```

b) Parit: la fonction tant symtrique, et invariante par changement du signe de la variable ( F(-a) = F(a) ), on posera (second changement):


```
     v:= Abs(u);
```

c) crtage: la fonction variant entre zro et l'unit, on supprimera tout ce qui sort de [0 ; 1] par les instructions conditionnelles:


```

```

D'o le codage de la fonction "coefficient de couleur":


```

```

En commentaires, les variantes non-linaires dont il a dj t question.

J'espre que tous ces longs calculs n'ont traumatis personne.  ::massacre::

----------


## Jipt

Bonsoir,

et merci de tant te dcarcasser  ::ccool:: 




> Si l'on dispose d'une fonction priodique u(t) variant entre (0) et (1) - peu importe que la priode (Pe) soit prise gale 2 ou 360 - les indices de couleur dcoulent des instructions:
> 
> 
> ```
> 
> ```
> 
> Je peux donner le code comment de la fonction u(t), si cela t'intresse.


Et je conclus de ton post d'aujourd'hui 


> D'o le codage de la fonction "coefficient de couleur":


que cette fonction coef_C(t: real); est la fonction u(t) telle qu'on la voit en action dans ton code cit ci-dessus.

J'ai donc adapt le premier code, rajout ta fonction, insr a dans ma moulinette  base de Scanline et rsultat, un magnifique dgrad vert  noir. C'est  a que tu pensais ?

Mon bout de code (certaines lettres sont doubles car dj utilises ailleurs.) :


```

```

Et un Pe  2 donne un dgrad vert-jaune-orange-rouge-magenta, il n'y a pas de bleu pur ni de cyan :

----------


## wiwaxia

J'ai comme l'impression qu'il manque la moiti gauche de l'intervalle: les coefficients de couleur qui se succdent de gauche  droite sur le spectre prennent schmatiquement les valeurs suivantes:


```

```

Je me suis mal exprim; j'aurais d crire:



> Si l'on dispose d'une fonction priodique u(t) variant entre (0) et (1) *sur un domaine de largeur gale  sa priode* - peu importe que la priode (Pe) soit prise gale 2 ou 360


Le spectre complet devrait rapparatre  peu de frais en codant:


```

```

Ce rafistolage ne devrait pas planter l'excution.
La fonction Coef_C(.) tant donne, sa priode vaut 2; ce n'est pas une option  mettre en constante.

----------


## Jipt

> La fonction Coeff_C(.) tant donne, sa priode vaut 2; ce n'est pas une option  mettre en constante.


Sans doute, mais c'est la phrase suivante qui m'a induit en erreur (je l'ai certainement mal interprte) :



> Si l'on dispose d'une fonction priodique u(t) variant entre (0) et (1) - *peu importe que la priode (Pe) soit prise gale 2 ou 360*





> Le spectre complet devrait rapparatre  peu de frais en codant:
> [...code...]
> Ce rafistolage ne devrait pas planter l'excution.


a ne plante pas, il y a mme un joli dgrad, mais on n'y retrouve pas la progression rencontre habituellement.  ::koi:: 



 titre de comparaison, je me suis inspir tout rcemment de ce sujet crit en DotNet et que j'ai adapt  ma sauce, ce qui donne :


```

```

Ce qui me permet, en changeant 1 seul chiffre (le nombre de sections : de 8  1 de haut en bas), d'obtenir a (montage avec Gimp de 8 images les unes sur les autres) :
 (revoir les commentaires dans le code pour les glissements de couleurs.)

J'avoue humblement que s'il faut trifouiller pour adapter les couleurs, par exemple, j'aurai moins de mal avec ma construction qu'avec la tienne, dans laquelle je n'ai pas encore capt o il fallait mettre les mains...

----------


## wiwaxia

::yaisse::  La fonction Coef_C(.) est enfin compltement raccorde  tes propres algorithmes, les teintes s'y succdant dans le mme ordre que dans le premier exemple que j'avais donn.
  
Pour retrouver *l'image visible* dans Wikipdia, dans laquelle les couleurs fondamentales s'y succdent dans l'ordre inverse et le vert est dcal d'un sixime de priode, il doit suffire:
a) d'changer les termes relatifs au bleu et au rouge ...


```

```

b) ...et d'imposer aux fonctions une translation de (*2*/6) vers la gauche; 


```
   t:= (2*s) - (2/3);  // t= (2*s) - 1 + 2/6 = (2*s) - 4/6
```

Pas mal, la seconde image.

----------


## Jipt

> b) ...et d'imposer aux fonctions une translation de (1/6) vers la gauche;


*2/6* ! si on veut vraiment tre en phase avec "mon" (en fait celui de wikipdia) croquis sur fond gris o le rouge commence  255 quand les 2 autres sont  0 (sinon on commence avec du magenta) :





> Pas mal, la seconde image.


Merci  ::D: 
Pas mal, ton cours : avec ces dernires explications (la translation), je pense que je devrais y arriver.  ::ccool:: 
EDIT : 
dans ta fonction coef_C, tu as propos des variantes  base de racine carre et autres traficotages ; voil ce que a donne, histoire de pouvoir comparer (les images de haut en bas dans le mme ordre que dans le code) :


Dernire question, si je peux me permettre d'abuser : ces fameux "croquis" o l'on voit la variation des valeurs des couleurs (particulirement les tiens de l'autre jour, avec des courbes au lieu d'angles), comment les dessiner ?

Excellente journe,

----------


## wiwaxia

> *2/6* ! ... sinon on commence avec du magenta


Exact: un sixime de priode = (1/6)*2 = 2/6 = 1/3 . Je rectifie le texte.

Tu matrises dsormais les variantes de la fonction Coef_C. 
Le montage que je dcouvre  l'instant serait encore plus dmonstratif si tu inversais l'ordre des 4 premires bandes.  ::mrgreen::  Je suis mesquin.

Je reviendrai plus tard sur le trac des courbes.

PS: Il y a encore mieux pour modifier les tendues relatives des couleurs: remplacer (w) par la fonction homographique u = (g*w)/(1 + (g-1)*w) , en prenant:
g = 2n, avec (n) entier situ dans [-5 ; +5]. 
Les graphes sont pour (g) diffrent de (1) des portions d'hyperboles quilatres passant par les points (0, 0) et (1 , 1); l'observation du faisceau de courbes sur une calculatrice permet de comprendre ce qui se passe.

----------


## Jipt

> Tu matrises dsormais les variantes de la fonction Coef_C. 
> Le montage que je dcouvre  l'instant serait encore plus dmonstratif si tu inversais l'ordre des 4 premires bandes.  Je suis mesquin.


Non ! Tu es taquin  ::P: 
L'inversion, comme a ? (30 secondes avec Gimp) :

Le bleu me fait penser  l'tambot d'un navire "de ligne" du XVIIIe sicle,  ::mrgreen:: 




> Je reviendrai plus tard sur le trac des courbes.


Dacodac...




> PS: Il y a encore mieux pour modifier les tendues relatives des couleurs: remplacer (w) par la fonction homographique u = (g*w)/(1 + (g-1)*w) , en prenant:
> g = 2n, avec (n) entier situ dans [-5 ; +5]. 
> Les graphes sont pour (g) diffrent de (1) des portions d'hyperboles quilatres passant par les points (0, 0) et (1 , 1); l'observation du faisceau de courbes sur une calculatrice permet de comprendre ce qui se passe.


Encore du boulot !  ::ptdr:: 

EDIT :



> [...] remplacer (w) par la fonction homographique u = (g*w)/(1 + (g-1)*w) [...]


Je ne vois pas *o*, et je ne vois pas *comment*...

J'ai bien sr cherch "fonction homographique", me suis retrouv sur une page Wikipdia o j'avoue humblement (mais je l'ai dj dit au tout dbut de ce fil) n'avoir *rien* compris...
C'est pas ma tasse de th, c'est comm' a...
/EDIT
---

De mon ct, j'ai optimis le plus possible (vir tous les float, real et autres, remplacs par des integer et bytes : ben oui, au final un TColor est plein de bytes et c'est tout), ton code s'excute en 55 millisecondes et le mien en... 26 !
 ::yaisse:: 

Et voil comment :


```

```


Et si on voit le bout du tunnel de tout a, je te propose ensuite de rflchir  la reprsentation des couleurs de la lumire visible (si c'est un peu ta partie) parce qu'en tapant juste "lumire visible" et en regardant les images remontes par google, on peut admirer tout et n'importe quoi...  ::aie::

----------


## wiwaxia

> Je reviendrai plus tard sur le trac des courbes.


Chose promise, chose de. Et comme les options s'accumulent, les programmes s'allongent et je vais tre bientt confront  un dcalage gnant.

Les calculs sont faits sur une matrice occupant 12 millions d'octets, et susceptible de mmoriser 4 mgapixels (j'ai eu la main lourde). Elle est dfinie et initialise dans une unit rserve que le Turbo Pascal serait videmment incapable de compiler:


```

```

Cette variable devient incontournable ds qu'il s'agit de tracer des graphiques ou des nuages de points,  l'aide de Virtual Pascal.
Le calcul des pixels (au dpart tous noirs - 0, 0, 0) s"effectue en deux temps:
a) le trac des graphes dans la partie infrieure de l'image (procdure CalcMat_Im01));
b) le badigeonnage de la partie suprieure, avec les teintes attendues (procdure CalcMat_Im02).

Pour les courbes le nombre total de points (2*Lim + 1) doit tre suffisamment lev, afin de conduire  un trac continu; l'apparition d'un pointill n"est pas vitable dans le cas prsent, lorsque la tangente devient verticale.



```

```

Avec les outils dont tu disposes, tu dois certainement trouver l'quivalent de la matrice en question (une variable TBitmap, peut-tre ?).




> ... Encore du boulot !  ...


Mais non, mais non,  ::furieux::  juste un petit bricolage install en fin de codage de la fonction Coef_C(Pilote, t), avec un paramtre d'option (variable 'Pilote'):


```

```

C'est encore en chantier, et tu complteras sans difficult le bloc d'instructions.




> ... J'ai bien sr cherch "fonction homographique", me suis retrouv sur une page Wikipdia o j'avoue humblement n'avoir rien compris...


L'article cit est l'exemple typique de rponse inutilement complique, de nature  donner des sueurs froides  tout lecteur dsireux de se rafrachir la mmoire.
Il fallait s'en tenir aux deux premires lignes, et  la formule donne:
_En mathmatiques, une fonction homographique est une fonction qui peut tre reprsente sous la forme d'un quotient de deux fonctions affines ... 
f(x) = (a*x + b)/(c*x + d)_ 
Elle est dans le cas prsent exprime sous la forme: CcG = (g1*w1)/(1 + (g1-1)*w1) , dans laquelle (w1) croorespond  la variable (x);
on a bien sr: a = g1 , b = 0 , c = (g1-1) , d = 1 .

Un aide-mmoire niveau bac t'aurait t plus utile. On en trouve sur la Toile, mais parfois de qualit douteuse (c'est le gros problme). 
Il ne faut pas ngliger les ressources du site - voir *ici*, mais je ne sais si cela te convient.
Je dois m'arrter l pour l'instant. Bon courage.

----------


## Jipt

Salut,

Merci de ta grande implication, le problme c'est que tu es rest dans ton monde et que moi, j'ai atteint mes limites face  tes codes auxquels je ne comprends absolument rien, que je ne sais pas comment mettre en uvre et qu'au final je ne sais pas ce qu'il faut en attendre...

Plus le fait que a ne compile jamais du premier coup et qu'il faut donc adapter, mais dans quelle direction ?
Quand par exemple tu cris FOR x:= 1 TO La DO il me faut convertir x en _integer_ (sinon a ne compile pas) quand tu le dclarais en _real_, mais est-ce que a ne va pas impacter des calculs ailleurs ?
Pareil pour ton "_La_", puis il me faut deviner ce qui se cache sous ton _Couleur_P_, supposer des trucs et des machins et tenter (sans aucune ide du rsultat) de remplacer tes lignes Ma[x, y+m]:= Couleur_P(Cbl) par Px[3]:= Cbl; Ma[round(x), round(y)+m]:= Px;, est-ce que c'est juste, est-ce que c'est faux ? Aucune ide mais, en cascade et au final je me retrouve avec une magnifique image noire...
Pas vraiment le but recherch...

Quant  ton rajout du _pilote_ (dont je n'ai pas le moindre ide d' quoi il peut bien servir et dont tu ne me dis rien), ben lui aussi il me balance de magnifiques images noires...

Bref, ce soir, tout a n'est pas glorieux...




> Un aide-mmoire niveau bac t'aurait t plus utile.


Non, il m'aurait fait perdre mon temps : les maths m'ont fait dcrocher de la scolarit aux alentours de la 1re, entre l'adolescence qui me faisait bouillonner le sang et les sens et l'abstraction de plus en plus avre de l'algbre alors que je me dbrouillais trs bien avec Pythagore, bon, je ne vais pas raconter ma vie, juste que ce soir je n'ai pas progress d'un centimtre.

Quand tu dis, en bleu, 


> _En mathmatiques, une fonction homographique est une fonction qui peut tre reprsente sous la forme d'un quotient de deux fonctions affines ..._


je vais tre honnte, a me fait une belle jambe !, parce que 1- je ne me souviens absolument pas de ce qu'est une fonction affine, et 2- si je m'en souvenais, pourquoi diviser l'une par l'autre ? Pourquoi ne pas les multiplier, ou les soustraire, etc. ? Pas la moindre ide, pas la moindre vision.
C'est comme en cuisine : il y a des gens ils lisent une recette (200 g de ceci, 30 cl de cela) et ils savent ce que a va donner une fois ralise, le got, tout a, alors que moi, mme avec la photo je n'en ai pas la moindre ide.
Ben en math c'est pareil : je n'ai pas la moindre ide de l o je vais.

Cet aprs-midi je suis tomb sur un bout de tuto qui dessinait une courbe sinusodale ; pour bien l'apprhender, la saisir, pour en avoir une "vision", il a fallu que je lui change des valeurs, une  la fois, dans un sens ou dans l'autre, et je l'ai enfin capte. Tu vois le truc ?

Mais si a t'emm..., pas de souci, on laisse tomber.

----------


## wiwaxia

Z_32 = type LongInt - entier sign cod sur 32 bits. Le lapsus m'est revenu en tte ce matin, mais tu avais dj rpondu.
(x) et (y) sont des compteurs, donc ncessairement de type entier, comme ce qui s'y rattache (La, Ha).
L'emploi d'un entier long permet d'viter les ventuels dbordements d'intervalle qui pourraient rsulter d'un calcul ultrieur (par ex. celui du nombre de pixels (Np = La * Ha).

Le type Integer est un survivant de la prhistoire, et peut dpendre (entre autres) de la machine; 
http://wiki.freepascal.org/Integer/fr
_La taille d'un entier dpend de la machine pour laquel le compilateur gnre le code (32 bit ou 64 bit), du type de compilateur (16 bits, 32 bits ou 64 bits) et des paramtres passs au compilateur dans certains cas._
http://wiki.freepascal.org/Variables_and_Data_Types/fr
_Le type integer peut contenir des entiers de -32768  32767. C'est une plage signe qui peut tre contenue dans un un mot de 16 bits, c'est un hritage de l'poque o les CPU 16 bits taient communes._

Si tu y tiens absolument, il vaut mieux lui prfrer le type *SmallInt*, bien dfini.

(La) et (Ha) sont les variables locales destines  recevoir les valeurs de (Larg_Image) et (Haut_Image) - largeur et hauteur de l'image; la notation n'est pas quelconque.
(Couleur_P(.)) est ncessairement de type Pixel, comme chacun des lments de la matrice; cette fonction tant dfinie dans une unit, donc invisible, j'ai repris la procdure concerne selon une variante plus lourde,mais plus comprhensible:


```

```

La permutation du bleu et du rouge vient de ce que dans un fichier Bitmap les indices sont noncs dans l'ordre (b, v, r).
L'insertion de (y+m) en ordonne permet d'amnager une bande noire de (m-1) liges sous les graphiques.

(Pilote) est un paramtre de choix de fonction, cela se voit dans les instructions conditionnelles:


```

```

Pour un premier essai rudimentaire, tu peux ventuellement lui affecter une valeur constante, et de mme pour le paramtre (g).

Les piges ne manquent pas, mais tu es jusque l parvenu  adapter les blocs d'instructions; il n'y a aucune raison pour que cela ne continue pas. 
Je poursuivrai plus tard.

----------


## Jipt

> Les piges ne manquent pas, mais tu es jusque l parvenu  adapter les blocs d'instructions; il n'y a aucune raison pour que cela ne continue pas.


Oui, h bien l, je suis face  un mur, une muraille insurmontable, pour le moment :




> ```
> 
> ```


a, a compile parce que c'est en constantes, mais le temps que a m'a pris pour raliser que a me faisait planter plus loin, je t'explique pas !

Mais bon, pour faire court et simple, 


```

```

dans ce bout de procdure c'est compil OK mais Access Violation  ::aie::   l'excution sur la premire ligne. Or c'est typiquement le genre de construction que tu utilises. Donc l, je suis un peu comme une poule qui aurait trouv un couteau, tu vois ?...

J'ai bien sr essay directement PixelNoir := (0,0,0); mais a ne compile pas (_Syntax error, ")" expected but "," found_ avec le curseur qui clignote aprs le 1er 0 -- je ne vois pas pourquoi...), pas plus que  PixelNoir := [0,0,0]; (_Incompatible types: got "Set Of Byte" expected "Pixel"_ -- a semble logique, donc c'est l'autre criture qui serait bonne, la premire, avec les parenthses, mais elle est refuse et si je mets  PixelNoir := (0); comme suggr c'est direct _Incompatible types: got "ShortInt" expected "Pixel"_ , donc vlo dans la campagne cet aprme...)

----------


## wiwaxia

Rien de tel qu'une bonne promenade pour s'arer les mninges.



```

```

C'est lourd et rptitif, mais il n'y a eu aucun incident lors de la compilation et du lancement du programme en version modifie.

De mme l'affectation d'une valeur fixe  une autre variable du mme type:


```

```

quivaut  une dclaration en constante


```

```

Il faut rappeler le type d'une variable compose pour la dclarer en constante: il s'agit alors de variables initialises.
http://pascal.developpez.com/cours/c...?page=pg_Array (fin du chapitre)
http://pascal.developpez.com/cours/c...pg_Const#LXXXI

Cela doit passer aussi en Free Pascal. Je ne vois pas ce qui peut bloquer ... mais il s'agit de ton programme; je ne propose que quelques pices dtaches, et cela fonctionnait jusqu' prsent.

# Ta phobie des maths est proprement sidrante: d'une part tu cris un programme viable de 51 lignes (hier, 12h03) dont - cerise sur le gteau - tu dtermines le temps d'excution  ::yaisse:: , d'autre part une ligne de dfinition te fais promptement dtaler, au point d'oublier la rponse qui venait ensuite !  ::help:: 
Il s'agit moins de la mconnaissance d'un domaine, que d'un rflexe d'aversion acquis au cours des tudes.
J'ai rencontr cette attitude chez quelques tudiants post-bac; il est difficile de s'en dfaire, mais ce n'est pas insurmontable. 

J'ai retenu deux sites aprs un parcours sur la Toile, concernant les formulaires de Mathmatiques:
■ un ensemble de formulaires tous niveaux, de la 6me  la Terminale
http://www.mathovore.fr/maths-formulaire
■ un kit de survie, un peu hard d'aprs ce que j'ai vu (pour Indiana Jones  la sortie du lyce):
http://www.xm1math.net/terminale_s/kit_term_s.pdf
Le mieux serait que tu ailles en bibliothque pour lire "les Maths pour les nuls", avant de l'acqurir ventuellement en librairie. Les livres de cette collection sont trs bien rdigs, dans un style clair et vivant.

# Pour cette question, c'est NON d'office -  moins que la rponse soit explicitement donne sur un site, ou qu'un autre participant fournisse des informations prcises sur le sujet -



> ... Et si on voit le bout du tunnel de tout a, je te propose ensuite de rflchir  la reprsentation des couleurs de la lumire visible ...


parce que cela demande une incursion dans des domaines difficiles et trs spcialiss:
- l'tude de la lumire mise par les crans;
- la sensibilit spectrale de la rtine humaine.
Il faudrait disposer d'une liste exprimentale de couleurs monochromatiques - donc de quadruplets (longueur d'onde, r, v, b) sur le domaine du visible (400  800 nm) pour construire les 3 fonctions appropries: r = F(Lo), v = G(Lo), b = H(Lo) .
Les schmas abondent sur la toile, mais rien ne garantit que la teinte soit correctement rendue au voisinage du point considr.

----------


## Jipt

'soir !

J'aime bien quand les choses sont synchro, dans ce monde de fous, a me remet de bonne humeur  :8-): 

Au moment o je termine mon montage avec Gimp, le ding-dong de ma messagerie m'annonce un nouveau mail, et c'est ton post ! Tu tombes bien !

Je m'en suis sorti de ce *$#!@! de bug de mes deux, tu sais o il tait planqu, l'animal ? Dans un dpassement de capacit, solution Tab_Pix = ARRAY[1..Dim_Max, 1..(Dim_Max *div 2*)] OF Pixel; le temps que a m'a cot, mme pas je te raconte.

Par contre, du coup, je peux te montrer a, que je viens de dmouler  l'instant, mais faudra que tu m'expliques :


EDIT : correction, suite  relecture attentive du code de Im02 (m'tais gourr quelque part) : voil une nouvelle image o l'on note, avec une loupe, une 1re bande verticale  gauche toute pleine de points de couleurs.
 /EDIT

en haut un a-e-c tout bte que je suppose tre la source pour construire les graphiques (tu ne m'as toujours rien expliqu de ce ct-l...), en dessous l'utilisation de la proc CalcMat_Im01  qui je passe l'a-e-c et tout en bas la CalcMat_Im02  qui blabla, qui est vraiment bizarre (les sparations, ce sont les deux bandes gris fonc).
La 01 on dirait qu'il ne lui manque pas grand chose, mais je ne sais pas encore quoi, plus les couleurs qui ne sont pas  leurs bonnes places mais a, a sera vite rgl...
EDIT : non, je n'arrive pas  rgler "vite" ce pb de couleurs avec Im01... /EDIT




> # Ta phobie des maths est proprement sidrante: d'une part tu cris un programme viable de 51 lignes (hier, 12h03) dont - cerise sur le gteau - tu dtermines le temps d'excution, d'autre part une ligne de dfinition te fais promptement dtaler, au point d'oublier la rponse qui venait ensuite !


Mais le temps d'excution il est document sur des milliers de sites, y a pas  se prendre la tte et  rinventer la roue, c'est tout simple !




> Le mieux serait que tu ailles en bibliothque pour lire "les Maths pour les nuls", avant de l'acqurir ventuellement en librairie. Les livres de cette collection sont trs bien rdigs, dans un style clair et vivant.


Plus le temps, l : je pense recevoir demain ou courant de la semaine un module lectronique qui va d'abord me faire sortir le fer  souder, et me faire chauffer le clavier ensuite : il s'agit d'un convertisseur USB -> DMX pour mon fiston qui bricole dans la lumire (tiens donc !), un domaine passionnant...




> # Pour cette question, c'est NON d'office -  moins que la rponse soit explicitement fournie sur un site, ou qu'un autre participant fournisse des informations prcises sur le sujet


En fait, je n'ai qu'une question toute bte, mais qui m'empche de dormir : tape donc, comme je te l'ai suggr, "lumire visible" et contente-toi de regarder les images, tu y verras des disparits de l'une  l'autre qui font que si je voulais faire la mme chose, je ne sais pas du tout laquelle choisir comme modle, d'une part, mais d'autre part il y a une constante qui me surprend : c'est pourquoi le rouge est plus large que les autres couleurs, dans leurs images  la noix ?
Je dis " la noix" parce que certains reprsentent l'infrarouge en allant vers le noir quand d'autres vont vers le blanc, et pareil du ct de l'ultra-violet (quand il y est : certains l'omettent)  ::koi:: 

Bon, je vais maintenant lire attentivement ce que tu m'as rpondu, mais je voulais te faire dcouvrir l'avancement du schmilblik !  ::mrgreen::

----------


## wiwaxia

Salut,  ::): 

Je rponds sur quelques points.

1) Premire image:

Tout se passe comme si au lieu d'crire


```

```

tu avais mis


```

```

Il y a eu dpassement d'intervalle, et intervention du reste modulaire - que tu l'aies intentionnellement programm, ou que le logiciel s'en soit implicitement charg (auquel cas il est vraiment sympa !).
De plus les deux parties du spectre sont dcales horizontalement de (1/6) de priode, en haut centr sur le cyan (ton modle), en bas sur le vert (le mien): il y a eu soit un mlange (peu probable) de formules, soit une discontinuit (encore un modulo sournois !) ...

La partie graphique prsente aussi un dcalage vertical analogue (sans mme parler des fonctions Coef_C(.), qui semblent se rduire  une constante (Coef_C(x) = 0 ou 1 ?); on ne voit aucun segment inclin, comme si tu avais impos le choix dichotomique:


```
       IF u>0 THEN u:= 1 ELSE u:=0
```

Les termes (x) et (y) sont-ils bien indpendants ? S'agit-il bien de variables locales ? Parce que les deux parties de l'image relvent de deux procdures diffrentes ... C'est assez intrigant.

2) Seconde image: 
Les couleurs ont ici t dcales horizontalement, mais surtout le palier maximal a disparu, comme si tu avais cod, pour l'crtage de la fonction: 


```
  IF u>1 THEN u:= 0   // au lieu de u:= 1
```

Quand aux graphiques ... ils sont peut-tre cachs par le spectre (bien mal nomm dans le cas prsent), que tu n'as pas propuls dans la partie suprieure de l'image; n'aurais-tu pas crit:


```
FOR y:= 1 TO K1 DO
```

au lieu de:


```
FOR y:= K1 TO Ha DO
```

Je ne suis malheureusement pas dou de vision extra-lucide.
Pourquoi le raccordement pose-t-il autant de difficults ? Un appel direct de ta variable "bmp" devrait te permettre de te passer de la matrice de pixels. 

3)  La recherche sur "lumire visible" conduit  des trouvailles intressantes; je les commenterai plus tard.

----------


## Jipt

Yep !



> Je rponds sur quelques points.


Moi aussi ! 
On y va :




> Tout se passe comme si au lieu d'crire --snip-- tu avais mis --snip--


Je serais alors vraiment tortur du bulbe,  ::mouarf:: 
Dj que j'ai un mal de chien  comprendre, si en plus je me mets  improviser, on n'est pas rendu !

La seule chose qui m'a pos souci, c'est ton erreur de dclaration du type Z32 qui m'a oblig, au dbut,  planter des round(variable_type_Z32) un peu partout, et lors de la correction j'ai oubli d'enlever certains round().
Je viens d'enlever les derniers, c'est toujours aussi moche, je te fais grce de l'image, il y a plus joli plus bas...




> ```
>        IF u>0 THEN u:= 1 ELSE u:=0
> ```


a sort d'o, a ? Pas trouv in the code...




> Les termes (x) et (y) sont-ils bien indpendants ? S'agit-il bien de variables locales ? Parce que les deux parties de l'image relvent de deux procdures diffrentes ... C'est assez intrigant.


Tutafait... Tutafait... Tutafait... Tutafait... 




> Je ne suis malheureusement pas dou de vision extra-lucide.


Rh, mais t'es mal quip,  ::ptdr::   ::ptdr::   ::ptdr:: 




> La recherche sur "lumire visible" conduit  des trouvailles intressantes; je les commenterai plus tard.


Ah ah !...

Bon,  moi ; voil o j'en suis :


il me reste  tester avec des images moins uniformes, je bricolerai  partir de "_l'tambot du navire de ligne_" (la Poste est passe et mon colis n'est pas l...)

Pour arriver  cette magnifique image, il aura suffi de a,  qui je passe un a-e-c en source et un bte TBitmap en destination, qui sera recopi dans un TImage :



```

```



Et pour en revenir aux maths, indpendamment du fait que je connais la collec' "pour les nuls" (j'ai "Les rseaux pour..." achet dbut 2000), voil ce  quoi je suis arriv en partant d'un tuto trouv l (page 21), que j'ai adapt  ma manire : les curseurs permettent de jouer avec l'amplitude du "signal" (on dirait l'cran d'un oscillo, hein !), son offset, et la frquence de balayage. 
Je suis assez content :


Mais encore une fois, j'ai suivi un de tes liens, je vois toutes ces belles formules mais je n'ai aucune ide de laquelle je devrais utiliser si je devais en utiliser une, et je ne sais pas comment la mettre en uvre dans Lazarus.
Pour cette image c'est le tuto qui m'a pris par la main et m'a mis sur la voie.

Bonne journe,

----------


## wiwaxia

> La seule chose qui m'a pos souci, c'est ton erreur de dclaration du type Z32 qui m'a oblig, au dbut,  planter des round(variable_type_Z32) un peu partout, et lors de la correction j'ai oubli d'enlever certains round().
> Je viens d'enlever les derniers, c'est toujours aussi moche, je te fais grce de l'image, il y a plus joli plus bas...


Dsol que cette faute d'inattention ait produit tant de dgts !




> Bon,  moi ; voil o j'en suis : ...


 ::yaisse2::  Enfin les bonnes fonctions ! C'est un bon redmarrage. 




> ... il me reste  tester avec des images moins uniformes, je bricolerai  partir de "l'tambot du navire de ligne" ...


C'est le moment d'introduire, dans la version initiale du programme, la fonction simplifie suivante  ::evilred::  (les prcdentes constituent un ensemble un peu artificiel):


```

```

Il ne devrait pas y avoir de problme, car cela passe en compilation ... mais une erreur est toujours possible. Dans le doute, contacte-moi avant de torpiller ton algorithme.
La fonction CcG(.) est paramtre par un rel (g), dont la valeur est pour l'instant passe en constante, pour faire simple.
Il s'agit d'un faisceau de courbes passant par les points (0,0) et (1,1); le cas (g = 1) redonne le segment rectiligne (CcG(w) = 1); le graphe se bombe vers le haut pour (g > 1), vers le bas dans le cas contraire (g < 1).
La meilleure rpartition des 6 teintes est obtenue pour (g ~ 2.50) - affaire d'apprciation personnelle.
Et pour retrouver ton profil de bateau, utilise une suite gomtrique comme
g = 3k (k variant de -4  +4) , ou
g = 2k (k variant de -7  +7) .

----------


## Jipt

lol ! Tu me refais le coup d'hier, le "ding-dong" au moment o je termine ma capture d'cran  !



> Dsol que cette faute d'inattention ait produit tant de dgts !


Bah, c'est comme en bagnole, tu changes de radio de station, hop !, 3 morts  ::aie:: 




> Enfin les bonnes fonctions ! C'est un bon redmarrage.


Attends ! Attends ! Regarde : aprs avoir corrig les derniers round(), et m'tre bien battu avec le fait que sous Linux les couleurs ne sont pas (il me semble) au mme endroit que sous Windows, 
tada ! :


Le dernier point qui me chiffonnait, j'ai mis ta ligne en commentaire et la mienne dessous :


```

```

Ta Coef_C s'appelle ici iCoef_C3, c'est mes bidouilles ("i" comme "inline" pour speeder, 3 = num de version, quand je fais des modifs -- mais au final, la 3 ressemble  la 0)

Et une fois ce Ma rempli, plus qu' l'afficher :


```

```


Allez, je vais voir ce que tu viens de m'apporter...

----------


## wiwaxia

::lol::  a se prcise ... C'est maintenant ton graphique qui recouvre le spectre:


```
K1:= Round(0.9 * Ha);
```

Non, trop haut ! Il me semble avoir crit:


```
K1:= Round(0.45 * Ha); dec(K1);
```



```
; dec(K1);
```

Quelle importance ? Un ligne de plus ou de moins ... ce n'est pas la place qui fait dfaut.



```

```

Il y a (2 * Lim + 1) points; l'numration k = {-5000 , -4999 , -4998 , ... , -2 , -1 , *0 (valeur centrale)* , 1 , 2 , ... , 4999 , 5000} fournit (2*5000 + 1) = 10001 valeurs diffrentes.

----------


## Jipt

> le gros obstacle, ce sera le passage de (g) en variable globale, en faisant intervenir une fonction de 2 variables: CcG2(g, w); on verra comment faire le moment venu.


Non, a ne sera pas le plus compliqu, il suffira de passer un record qui emballera les deux variables et hop !

Ce qui m'embte en ce moment, c'est que je n'arrive plus  retrouver mon profil de bateau pour tester ma fonction d'analyse car, au final, ces trois traits RGB, je leur vois une utilit dans un sens ou dans un autre :
- ou bien ils sont la reprsentation d'une cration graphique ex nihilo (les profils de bateau par ex.) ;
- ou bien on calcule (dessine) les graphiques puis on fait dessiner une reprsentation esthtique (l'a-e-c par ex.) du croquis.

Pour le moment je fonctionne dans le 1er mode (j'ai russi  faire cracher autre chose que l'a-e-c classique  coef_C) :


Mais on dirait qu'il reste des bugs ou autres cochonneries : les lignes horizontales du haut et du bas ne sont pas terribles...




> ```
> K1:= Round(0.9 * Ha);
> ```
> 
> Non, trop haut ! Il me semble avoir crit:
> 
> 
> ```
> K1:= Round(0.45 * Ha); dec(K1);
> ```


Vi, et moi j'ai crit :


```

```

Dit plus clairement, avec 0.45 les traits n'occupent que la moiti suprieure de l'image destine  les afficher...




> 


Ah, on a des observateurs discrets !
Coucou, toi  ::coucou::

----------


## wiwaxia

L, je dois m'absenter - alors rapidement:
1) Les belles fonctions d'avant, continues et linaires par morceaux, sont devenues discontinues et leur priode a t divise par 2: il faut renverser le second arc curviligne pour qu'il devienne descendant, et tout rentrera dans l'ordre.
2) Je ne comprends pas tes hsitations: 1 <= y <= 0.45*Ha pour les graphiques , 0.55*Ha <= y <= Ha pour le dgrad.
Comme pour un mur d'immeuble: les tags au rez-de-chausse, la belle peinture au-dessus.

----------


## Jipt

Bonsoir,




> 1) Les belles fonctions d'avant, continues et linaires par morceaux, sont devenues discontinues et leur priode a t divise par 2: il faut renverser le second arc curviligne pour qu'il devienne descendant, et tout rentrera dans l'ordre.


Dit comme a, a a l'air tout simple, on verra quand j'aurai rgl ce que je vais balancer dessous...




> 2) Je ne comprends pas tes hsitations: 1 <= y <= 0.45*Ha pour les graphiques , 0.55*Ha <= y <= Ha pour le dgrad.
> Comme pour un mur d'immeuble: les tags au rez-de-chausse, la belle peinture au-dessus.


En l'espce c'est l'inverse, les tags en hauteur et la belle peinture  porte de main, enfin, c'est le code qui le fait.

Bon, on pourrait croire, en regardant cette image (un peu rduite), que a y est :
 mais que nenni !

D'abord, faut savoir que pour avoir les bonnes couleurs dans le dgrad j'ai souffert le martyre (si si !, foetus, le martyre !),  tel point que si quelqu'un veut mettre les mains dans la proc Im02 il a intrt  s'armer de patience et de courage, et  bien lire les commentaires :


```

```

Le "- 1;" en commentaire (lignes 8, 9, 10) dans le calcul de "r" par rapport  l'original, c'est pour commencer le dgrad  rouge, et je n'ai pas trouv d'autre manire de faire.
Ah, wiwaxia, tu noteras que j'ai "remont" les calculs de "s" dans la boucle avec "x", pas la peine de faire ces calculs pendant la "descente" avec "y".

Sa copine :


```

```


Je pense avoir russi  identifier les pixels Px[idx] dans la matrice Ma, mais il reste un souci, un gros souci, car en zoomant trs fort et en regardant en bas  gauche du dgrad on trouve a :
  ::aie::   ::aie::   ::aie:: 

En gnral, ce genre de choses je l'ai (souvent) constat quand on n'est pas dans le bitmap, la matrice, l'image, bref quand on tape ailleurs que l o il faudrait, pour l'affichage.

Regardez bien les commentaires dans le code post plus haut, selon comment on dmarre le balayage, la 1re colonne est d'un beau rouge franc et massif  255 (sauf le bas,  ::evilred:: ) ou d'un rouge-marron  128 : l, on n'est pas dans le buffer !
C'est ce groupe de pixels au bas de la colonne qui me cre un souci car on est cens balayer de K1  Ha, Ha tant la hauteur de l'image que je passe  la procdure... Mystre, l, car un coup de log montre que la boucle descend bien jusqu' 256 (hauteur de l'image-cible).


Et en parlant de boucle et de log, un autre mystre : si j'active le log (dans un bte mmo sur la fiche), j'ai systmatiquement droit  la 1re colonne pleine de caca-boudin, voir ci-contre.

 En gnral, quand je loggue, je me contente de recopier des donnes, pas de les traficoter ; alors elle sort d'o cette colonne toute moisie dont il me suffit de mettre la ligne de log en commentaire pour qu'elle disparaisse ! Encore un truc de fou...


J'en suis l.

----------


## Jipt

Yep !



> Je t'avais dit de faire des *interpolations linaires* entre 2 couleurs, sur les 3 composantes (rouge, bleu, verte)


Des quoi ? Te rappelle que je suis nul en math et que ces mots ne m'inspirant aucune vision, je suis incapable de coder ce qui se cache dessous...

Donc je te remercie pour ton code, que j'ai traduit en Pascal et que je vais mettre l-dessous pour en faire profiter la communaut :


```

```

Pas la peine de mettre une copie d'cran, c'est un a-e-c comme les autres, rouge-jaune-vert-cyan-bleu-magenta-rouge.

Pour le mettre en uvre j'ai utilis un TImage de 768 x 256 avec la proprit Stretch bascule  True.




> Et les calculs donnent du BGR et non pas du RGB


 ::koi::  ils s'affichent, comme dit plus haut, trs bien et trs correctement dans Linux... 

Mais 38 millisecondes en moyenne  ::aie:: , contre 26 avec Scanline  ::ccool::

----------


## wiwaxia

Bonsoir,  ::D: 

J'ai t surpris de lire les instructions:


```

```

C'est embtant pour une matrice de type Tab_Pix = ARRAY[*1..Dim_Max*, 1..Dim_Max] OF Pixel ... Ne resterait-il pas des pixels non initialiss ?
Et quel sont d'ailleurs les indices du premier pixel dans la variable 'bmp' traite par la procdure de Lazarus ? (0, 0) ou (1, 1)?




> ... mais il reste un souci, un gros souci, car en zoomant trs fort et en regardant en bas  gauche du dgrad on trouve a :


Et on voit bien plus surprenant en modifiant le contraste ... cela vaut le dtour (je n'ai aucune explication  ce sujet ... des soupons seulement).

@ *foetus*



> Je t'avais dit de faire des interpolations linaires entre 2 couleurs, sur les 3 composantes (rouge, bleu, verte)


C'est bien ce dont il tait initialement question,  ::):  les graphes des coefficients parlent d'eux-mme (voir la dernire image complte produite par *Jipt*).




> Et il faut corriger le problme des approximations des flottants (la division par 3, ce n'est pas mchant: on va avoir soit 0 soit 1 soit 2 lignes non prises en compte)


L'emploi des rels dans les calculs intermdiaires supprime toute drive, dans le cas des combinaisons linaires de pixels .

----------


## wiwaxia

L'image comportant une couleur dont l'indice dpend de l'abscisse (x) du pixel, on s'affranchira des donnes entires en recourant  une fonction relle d'une variable relle u(t) telle que (t) et (u) appartiennent au domaine [0 ; 1]; il suffira d'crire;


```

```

Tant que la fonction u(t) est *continue*, il n'apparat pas d'effets indsirables sur l'image.
C'est du moins comme cela que je vois la chose.

----------


## Jipt

Bonjour !

TERMIN, en ce qui concerne les bugs d'affichage,  ::ccool:: 

Ce qui m'a mis la puce  l'oreille (sale bte !), c'est de *voir* a 



> C'est embtant pour une matrice de type Tab_Pix = ARRAY[*1..Dim_Max*, 1..Dim_Max] OF Pixel ... Ne resterait-il pas des pixels non initialiss ?


Indpendamment du fait que j'avais dit, il y a quelques jours, qu'il me fallait diviser par 2 ce que j'appelle la hauteur car sinon j'avais des bugs incomprhensibles de plantage avant mme d'atteindre les instructions (plantage sur le begin : jamais vu avant ici !), la solution m'a saut  la figure en *voyant* ton code ci-dessus : bon sang mais c'est bien sr !


```
Tab_Pix = ARRAY[0..Dim_Max-1, 0..(Dim_Max div 2)-1] OF Pixel;
```

Et voil ! (comme disent les Amricains [si si !, j'vous jure !]) :

 (image lgrement rduite)

Il restait une dernire blagounette planque au tout dbut de la ligne rouge du graphique, o son premier point n'tait pas un rouge franc du collier mais encore un truc moisi, avec le mme problme de dmarrage du balayage horizontal en retard. Solution dans Im01 (grce  un coup de log pour voir les nombres) : x:= Round(s / 2)-1;  inc(x); et bingo !





> Et quel sont d'ailleurs les indices du premier pixel dans la variable 'bmp' traite par la procdure de Lazarus ? (0, 0) ou (1, 1)?


(0, 0)

Me reste plus qu' mettre tout a au propre, et passer  la phase 2 : dessiner les graphiques en fonction des infos analyses dans le dgrad (a, a commence  venir) ou, mieux, dessiner un dgrad en fonction de graphiques crs soit par les maths (ae ae ae), soit  la souris en bougeant des points sur des droites R G B...

Mais tout a va dpendre du colis que j'attends...





> Et on voit bien plus surprenant en modifiant le contraste


Attention ! Peut-tre des artefacts inclus dans l'image poste et lis  la compression jpg, je l'ai dj vcu. T'aurais d poster une copie d'cran...

Pour finir l-dessus, voil ce que je voyais hier soir  pas d'heure en faisant afficher une matrice remplie de noir (c'est le coin infrieur gauche zoom  mort) :
 Bonne journe,  ::coucou::

----------


## tbc92

Interpolation linaire : 
comprendre ces 2 mots, ou ne pas les comprendre, ce n'est pas des maths mais du franais. 
Linaire : a veut dire qu'on trace une Ligne ... et plus prcisment une ligne DROITE.
Interpolation : l'tymologie du mot n'est pas flagrante, mais le prfixe inter est clair : il signifie ENTRE.

Une interpolation linaire , c'est quoi : on a 2 points A et B dessins sur une feuille de papier,  on dessine la ligne droite qui relie nos 2 points, et l'interpolation linaire, c'est l'ensemble des points entre A et B.
De la mme faon extrapolation linaire, ce sont les points de cette droite AB, mais qui sont  l'extrieur du segment AB (quand on rallonge la droite)

----------


## Jipt

> Interpolation linaire : 
> comprendre ces 2 mots, ou ne pas les comprendre, *ce n'est pas des maths mais du franais*.


C'est ce que j'ai pass mon temps  rabcher  mes gamins, mais je constate que a fonctionne tant qu'on n'a pas besoin du dictionnaire, genre les problmes de plombier avec la baignoire qui se remplit d'un ct et se vide de l'autre.
Mais "interpolation", si dj t'as du mal  comprendre le mot, automatiquement quand tu le vois dans une phrase tu zappes -- enfin, moi !




> Moi, *je vois* 1 grosse cou^lle dans le potage , mais chacun son point de vue.


Tu as tout dit, et je le mets en gras, car moi je ne vois rien...
Question de points de vue, de la mme manire que je vois des fautes d'orthographe horribles l o d'autres ne voient rien et cliquent allgrement sur "Envoyer la rponse".

C'est comm' a, ainsi vont le monde et la vie.

Merci pour les explications,

----------


## wiwaxia

> Et ouais  Parce que je vois tous les calculs fait  base de racine carre, de nombre magique (1,45), de fonctions mathmatiques (2.5*W1 / (1 + 1.5*W1)) juste pour faire 1 ligne droite (et ceci pendant des jours et des jours) ...


La dernire fonction propose (F(g, w) = g*w/(1 + (g-1)*w) ) s'loigne progressivement du segment de droite ( F(1, w) = w ) et permet de modifier plus facilement les tendues des diverses teintes(1).

       

Tu as toi-mme vaguement voqu ce procd



> Si tu veux un autre arc-en-ciel, tu changes les couleurs et/ ou les parties de ton dgrad.
> Aprs, cela peut tre tendu (?) ... ou peut-tre des *dgrads avec lesquels des interpolations linaires ne suffissent pas*.


sans proposer d'ailleurs quelqu'exemple que ce soit (on aurait t intress).

Si tu t'tais donn la peine de consulter les pages prcdentes, cela t'aurait vit de revenir  des points dj largement voqus et de conduire les changes  l'enlisement (je m'abstiendrai d'ajouter: dans le potage  ::aie::  , parce qu'en bonne compagnie, il faut savoir se tenir).

Quand le dbat se met  tourner en rond, cela conduit  cela: 






> Une extrapolation intervient lorsqu'on ne peut pas relier tous les points par des lignes droites sans qu'il y ait des cassures.
> Donc, on calcule une fonction mathmatique qui va passer proche de tous les points.


L'extrapolation consiste  prolonger une relation linaire (ventuellement approche) *en dehors* ou * la limite* de son domaine de dfinition, c.a.d. de l'intervalle o la grandeur considre est (numriquement ou physiquement) accessible.
Exemple: quand (x) tend vers zro, sin(x)/x ~ 1 - u/6 , en posant u = x2 .
*tbc92* a dit l'essentiel  ce sujet:



> De la mme faon extrapolation linaire, ce sont les points de cette droite AB, mais qui sont  l'extrieur du segment AB (quand on rallonge la droite)


Il n'est pas interdit de consulter un dictionnaire.

(1) @ *Jipt* : un beau profil de bateau en perspective, avec cette srie de dgrads pour g = (0.0256 , 0.064 , 0.16 , 0.4 , 2.5 , 6 , 16 , 40)
- aprs coup, cela aurait t mieux avec des valeurs plus rapproches.

----------


## Jipt

Bonsoir,

je reviens 30 secondes sur un point qui me rend perplexe : sur tes images le graphique est en bas et le dgrad en haut, et chez moi c'est l'inverse  ::koi:: 

Je viens encore de relire attentivement tes proc's CalcMat_Im01 et CalcMat_Im02 (publies dans ce post) et de les comparer avec les miennes, au niveau du calcul de K1 elles sont rigoureusement identiques...
Une ide du pourquoi du comment de cette inversion de rendu ?
Et j'ai test sous Windows, le problme est identique, c'est donc bien li  *mon* code.

Merci (je verrai le reste plus tard)...

----------


## wiwaxia

> ... je reviens 30 secondes sur un point qui me rend perplexe : sur tes images le graphique est en bas et le dgrad en haut, et chez moi c'est l'inverse  ...


En effet, je l'avais dj constat sur quelques unes de tes images



mais n'avais pas cru devoir intervenir sur ce qui me paraissait un point secondaire, dans la mesure o tout tait visible et cohrent ...

Et cela ramne  une question que j'ai failli poser  la suite d'une autre:



```
Et quel sont d'ailleurs les indices du premier pixel dans la variable 'bmp' traitée par la procédure de Lazarus ? (0, 0) ou (1, 1)?
```

 savoir: o se trouve le premier pixel (0, 0) ?  gauche en bas ou en haut ? Dans ce dernier cas, ne verrait-on pas l'image renverse ?
Pour le dgrad rien de chang, mais les graphes, par contre, ne correspondent plus aux maximums des couleurs principales.

Essaye de rajouter le trac en blanc d'un trait oblique dans _CalcMat_Im02_ en rajoutant aprs le trac du dgrad (cela viendra par-dessus), donc aprs les instructions:


```

```

le groupe suivant:


```

```

Je n'aime pas ce style, mais c'est du provisoire. Il faut une image suffisamment haute (Ha >= La / 4).

----------


## Jipt

> Je n'aime pas ce style, mais c'est du provisoire. Il faut une image suffisamment haute (Ha >= La / 4).


Bah, pourquoi pas, pour *voir* o on en est ?

Code remis en page pour une meilleure lisibilit et donc une meilleure comprhension :


```

```

Oui, je pinaille,  ::P: 




> Pour le dgrad rien de chang, mais les graphes, par contre, ne correspondent plus aux maximums des couleurs principales


Peut-tre que je les ai adapts pour les faire rentrer l o ils devaient aller ?...
Mais je ne vois pas en quoi le fait de croiser les trois couleurs et leurs pixels les auraient fait passer de bas en haut, et le dgrad de haut en bas  ::koi:: 
D'autant plus que pour m'viter des sacs de nuds, j'ai toujours travaill avec une seule proc  la fois (d'o ma mprise  un moment et ce remplacement erron de 0.45 par 0.9, rapidement annul)





> o se trouve le premier pixel (0, 0) ?  gauche en bas ou en haut ? Dans ce dernier cas, ne verrait-on pas l'image renverse ?


 mon avis il est en haut  gauche. D'ailleurs, dans un autre projet, j'avais not a, concernant le bitmap de travail :


```

```




> Et cela ramne  une question que j'ai failli poser  la suite d'une autre:
> 
> 
> 
> ```
> Et quel sont d'ailleurs les indices du premier pixel dans la variable 'bmp' traitée par la procédure de Lazarus ? (0, 0) ou (1, 1)?
> ```


Question  laquelle j'avais rpondu mais effectivement elle est incomplte, donc ma rponse aussi  ::mrgreen::  -- Bon, c'est rpondu compltement plus haut.

Allez, les images parce que, oui, t'en as deux pour le prix d'une ! La seconde, je me suis content de gnrer un dgrad noir-->gris pour voir dans quel sens la chose voluait, bas sur Px[1]:= x div 6; Px[2]:= x div 6; Px[3]:= x div 6; et l'on voit (devine, plutt) que le noir dmarre en haut  gauche :

----------


## wiwaxia

Bonjour,  ::D: 




> O se trouve le premier pixel (0, 0) ?


 La rponse est dsormais sans appel



> mon avis il est en haut  gauche. 
> 
>   ------------------------
>   |0,0           1535,0  |
>   |                      |
>   |                      |
>   |0,255         1535,255|
>   ------------------------


Le logiciel te fournit les images la tte en bas, le systme de coordonnes utilises (x, y) est semblable  celui de l'cran-texte:


```

```

Tu n'y peux probablement rien,  moins qu' il n'existe une option de renversement des coordonnes dans Lazarus ou Free Pascal - il te va falloir plonger hroquement dans les _User Guide_.

Si, comme Saint Thomas, tu doutais encore du fait, tu peux toujours:
a) coder un faisceau de droites, en rajoutant les instructions:


```

```

b) Remplacer tout le contenu de l'image par le dgrad de ton choix, en codant:


```

```

La procdure _CalcMat_Im01_ sera devenue inutile, puisque le dgrad aura tout recouvert. Tu obtiens au passage un fond d'cran reposant (il y bien d'autres variantes).

# Pour que tout rentre dans l'ordre, il faut installer la rustine suivante dans chacune des procdures (_CalcMat_Im01_ , _CalcMat_Im0_):
a) en dbut de bloc:


```

```

b) et en modifiant chaque appel de la matrice:


```

```

Cela devrait marcher. Montre-moi les images.

PS: Je viens de voir que sur les images apparat la premire bissectrice du repre (y = x) au lieu de la droite suggre, 
d'quation: y = 1 + Round(x / 4); est-ce voulu ?

----------


## Jipt

Bonjour,



> PS: Je viens de voir que sur les images apparat la premire bissectrice du repre (y = x) au lieu de la droite suggre, 
> d'quation: y = 1 + Round(x / 4); est-ce voulu ?


 ::koi::  Une bissectrice ce n'est pas une droite ?  ::koi:: 

Mais ne tergiversons plus !
Tu voulais de l'image ? En v'l 3 avec, de haut en bas, le dgrad standard puis l'application du pilote 9 avec g = 2.5 et en bas g = 40.


J'ai souffert mais on n'a rien sans rien, hein !

Mes corrections et remarques par rapport  tes suggestions :

- dans Im02 :       H1 := Ha; // + 1;  // enlever le +1 sinon 1<sup>re</sup> ligne noire; 
- dans Im01 :       H1 := Ha; dec(H1); // recopié depuis Im02, mais on est très bas --> suppr "m" dans  dec(H1, m).
et surtout, surtout !, puisqu'on renverse l'image, "tout ce qui montait doit descendre et tout ce qui descendait doit monter !" -- je fais l rfrence aux 3 lignes colores, et donc, plutt que ton Ma[x, H1 - y]:= Couleur_P(...), j'utilise Ma[x, (H1 div 2)+y]:= Cxx; (oui, j'ai conserv les Cxx, plus "parlants" pour moi).

Et j'ai termin par une dernire retouche au mode d'affichage proprement dit (que j'avais d poster, donc s'il y en a qui suivent depuis le dbut, a leur vitera de s'arracher les cheveux) : 


```

```


Voil.
La prise de tte, maintenant, va tre d'avoir une belle image sous Windows sans casser celle sous Linux, parce qu'un test rapide me montre cette horreur :


Mais il suffit de remplir la matrice de noir avant d'appeler les fonctions de dessins, ouf !, avec a :


```

```


La dernire petite diffrence entre mes images et les tiennes, c'est le positionnement en hauteur du graphique par rapport au bas de l'image.
Bah, a n'est pas bien important, ce dtail.
EDIT : suffit de faire Ma[x, ((H1+m) div 2)+y]:= Cxx; /EDIT

Un grand, un norme merci pour tout a  ::ccool:: 

Cependant, aprs avoir post puis relu et *regard attentivement*, je constate la chose suivante sur l'image du bas, celle avec g = 40, c'est qu'on a une norme plage jaune alors qu'en examinant les graphiques le vert ne "dcolle" que trs tard, suivi d'une chute ultra-rapide du rouge : cet norme aplat jaune m'intrigue, et mmes remarques pour les aplats cyan et magenta...
Une ide ?

----------


## wiwaxia

::yaisse2::  a prend forme ! Tu as fait du bon boulot.

Mais  ::mrgreen::  Les zones vertes de plus en plus troites sont lies  des valeurs croissantes de (g), et  des courbes "gondoles" vers le haut: or c'est prcisment le contraire que l'on voit.  ::mouarf:: 

D'aprs ce que tu m'indiques, les teintes correspondent  g = { 1 , 2.5 , 40 } , et les graphes  g = { 1 , 1/2.5 , 1/40 } .
Regarde bien la 3me:  ::weird::  il y a un dtail qui n'est pas logique ...

Je m'absente jusqu'en soire.

----------


## Jipt

> Regarde bien la 3me:  il y a un dtail qui n'est pas logique ...


J'ai TOUT repris  zro (ouais, ch'suis un grand malade,  ::ptdr:: )

Et j'ai dcid d'aller vers *tes* couleurs plutt que de tout trafiquer pour essayer d'obtenir un dgrad rouge-jaune-vert-cyan-bleu-magenta. On verra plus tard.
Du coup, j'y suis arriv.

J'ai repris du dbut (posts 42 et 44), sans toucher  rien (ou le moins possible) :



```
      Tab_Pix = ARRAY[1..Dim_Max, 1..(Dim_Max div 2)] OF Pixel;
```

si pas "*div 2*", *AV*  l'excution.

Mise en place des modifs pour inversion haut-bas (post 66) :


Problmes :
- la premire colonne de l'image globale n'est pas bonne ; certainement lie au fait que tu commences toutes tes boucles de balayage  1, moi on m'a appris  commencer  0 et jusqu' Largeur-1.
- en ayant tout invers, la couleur au dbut qui "montait" se retrouve  "descendre"...

D'o modification de deux lignes de Im02 :


```

```


et l, aprs une dernire modif, on se retrouve avec la mme image que dans le post 30  ::yaisse:: 



```

```


Et voil, a le fait :


 gauche en haut, identique au post 30 et dessous avec le pilote  9 et g  40
 droite en haut pilote  1 et dessous  3, on a des beaux profils de bateaux  ::ccool:: 

en incruste (zoom  donf') les artefacts lis sans doute aux arrondis des reals. Attention, l'image verte en bas  gauche et la rose en haut n'ont pas de dfauts, elles sont l pour faire la comparaison avec leurs collgues de droite.
Ce truc va m'nerver, particulirement la ligne noire au-dessus d'en haut  droite.

Le problme c'est qu'on ne peut  peu prs toucher  rien, a fait vraiment penser  un chteau de cartes...

C'est quoi la taille de l'objet que tu utilises pour afficher ?

----------


## wiwaxia

Impeccable !  ::chin::  Les images (2, 3, 4, 5) sont russies, dans le mesure o les teintes s'accordent aux courbes reprsentes dessous.
Cependant (  ::ptdr::   je vais tout gcher !) la premire prsente un inversion de la palette, le rouge devant se situer  droite, et le bleu  gauche ... Il devrait tre facile de remdier  cela.

Venons-en aux observations.

1) 


> J'ai repris du dbut (posts 42 et 44), sans toucher  rien (ou le moins possible) :
> Code pascal : 
> 
> 
> ```
>  Tab_Pix = ARRAY[1..Dim_Max, 1..(Dim_Max div 2)] OF Pixel;
> ```
> 
> si pas *"div 2", AV*  l'excution.


Je n'ai pas compris ce que signifiait l'abrviation ...
Et aussi pourquoi tu ne reportais pas le calcul de la seconde dimension dans la dtermination pralable des constantes, en posant:


```

```

ce qui peut faciliter des modifications ultrieures; mais c'est un dtail, et chacun voit midi  sa porte.

2) 


> Problmes :
> - la premire colonne de l'image globale n'est pas bonne ; *certainement lie au fait que tu commences toutes tes boucles de balayage  1*, moi on m'a appris  commencer  0 et jusqu' Largeur-1   ...


Le choix de commencer un comptage  zro ou un est une affaire d'opportunit (cela risque d'en irriter plus d'un)  ::furieux:: 
a) la boucle  

```
For x:= 0 TO (Nmax - 1)
```

s'apparente troitement au reste de la division euclidienne (x = k MOD Nmax), et s'impose ds que l'on doit tracer un repre, un cadre ou une grille et reprsenter des traits rgulirement espacs (par ex. pour x (ou y) = 0, 100, 200, ... etc);
b) la boucle  

```
For x:= 1 TO Nmax
```

correspond  la manire naturelle de compter (1 pour la premire colonne, 2 pour la suivante ... ) et s'utilise spontanment pour la ralisation d'un dgrad; je n'ai d'ailleurs pas le choix, le lien entre la matrice et l'image Bitmap tant gr par l'unit dont la programmation est trs lourde (je n'ai aucune envie d'y revenir !).
Il va de soi qu'il faut adapter en consquence la dfinition des paramtres qui viennent ensuite:


```

```

et qu'une erreur pourra conduire  des surprises aux extrmits de l'intervalle, comme tu l'as toi-mme constat:.



> Le problme c'est qu'on ne peut  peu prs toucher  rien, a fait vraiment penser  un chteau de cartes...


Une concision excessive du programme, la raret des variables intermdiaires contribuent  la difficult des corrections - allusion perfide  ::mrgreen::  aux appels & fonctions embotes.
Idem pour le renversement de l'image de haut en bas, auquel tu as vaguement fait allusion:


```
     H1:= Ha;// + 1; pourquoi +1 ? On va tre plus grand que la hauteur ...
```

La permutation des lignes rsulte alors des instructions:


```

```

C'est peut-tre la cause de la ligne noire indsirable prsente dans les images (1) et (3).

3) Restons zen  ce propos.  ::zen:: 



> Ce truc va m'nerver, particulirement la ligne noire au-dessus d'en haut  droite.


Il y a un moyen simple de vrifier que la ligne suprieure a chapp au coloriage: initialiser l'image en gris uniforme (au lieu du noir), cette teinte diffrant nettement de toutes celle de la palette, par un codage du genre


```

```

On doit retrouver cette couleur sur la ligne du haut.

4) Il ne faut pas accuser les _real_ de tous les maux (il me semble avoir dj lu cet argument):



> en incruste (zoom  donf') les artefacts lis sans doute aux arrondis des reals


La drive des calculs intermdiaires (ils ne comportent pas beaucoup d'tapes) reste de l'ordre de (2-63), soit environ (10 -19) si l'on emploie des _extended_ en Pascal, tandis que la discrtisation des couleurs entrane une erreur d'arrondi d'au moins (0.5/255)~2E-3; un abme de *16 ordres de grandeur* spare donc les deux seuils, et la drive due aux rels est (sauf cas trs singulier) ngligeable.

5) Au sujet des bateaux



> ...  droite en haut pilote  1 et dessous  3, on a des beaux profils de bateaux ...


je pensais  la remarque pertinente que tu avais faite au sujet d'une srie de palettes superposes (le 05/11/2016, 13h03):



> ... Le bleu me fait penser  l'tambot d'un navire "de ligne" du XVIIIe sicle ...


6) 


> C'est quoi la taille de l'objet que tu utilises pour afficher ?


J'emploie Irfan View pour voir les images Bitmap, modifier les dimensions et le format; Paint peut ventuellement servir  rajouter du texte. C'est trs artisanal.
Si tu fais allusion au fichier '.exe', sa grande taille est essentiellement due  la prsence de la matrice (3*20002 = 12 Mo), qui excde largement celle de l'image. Je l'ai programme en pensant au cas limite d'un fond d'cran,  et il faudra que je reprenne cela.

# Je ne suis pas curieux, mais j'aime bien savoir:  ::mrgreen:: 
 propos du chronomtrage de l'excution d'un programme (06/11/2016, 19h55)



> ... Mais le temps d'excution il est document sur des milliers de sites, y a pas  se prendre la tte et  rinventer la roue, c'est tout simple ! ...


Quels sites as-tu consults ?

----------


## Jipt

Bonjour,





> la premire prsente une inversion de la palette, le rouge devant se situer  droite, et le bleu  gauche ... Il devrait tre facile de remdier  cela.


"La premire", celle qui est toute seule ? On s'en fiche, comme not dessous j'ai bien trouv des problmes, que j'ai corrigs, ce qui m'a permis ensuite de gnrer la grande image aux quatre variations.

1) l'abrviation AV signifie Access Violation, qu'on rencontre en C, qui est parfois traduite en SIGSEGV (Segmentation Fault) et qui signifie toujours la mme chose : (tentative d') accs  une zone mmoire non alloue/n'appartenant pas au programme.




> Et aussi pourquoi tu ne reportais pas le calcul de la seconde dimension dans la dtermination pralable des constantes


Flemme, et je voulais intervenir le moins possible dans ton code puisque je reprenais tout  la base. Modif prvue,  terme, quand tout le reste sera oprationnel...





> 3) Il y a un moyen simple de vrifier que la ligne suprieure a chapp au coloriage : initialiser l'image en gris uniforme (au lieu du noir), cette teinte diffrant nettement de toutes celle de la palette...
> On doit retrouver cette couleur sur la ligne du haut.


a m'nerve l'informatique, a m'nerve : il suffit que je fasse ce que tu dis (sauf que j'ai mis un gris  128 au lieu de 180) pour que le problme disparaisse : plus de lignes moisies... a m'nerve !

Mais a ne fait pas disparatre le dfaut de la 1re colonne du graphique (ici pilote mode 3, image trafique pour ne montrer que les parties significatives) :


Ce qui le fait disparatre, c'est de commenter la seconde instruction, l dans Im01, pour commencer 1 point plus  gauche :


```

```

Test avec pilote en modes 0, 3, 5, 9 avec g=40 et OK dans ces 4 cas !  ::ccool:: 




> 6) Si tu fais allusion au fichier '.exe', sa grande taille est essentiellement due  la prsence de la matrice (3*20002 = 12 Mo), qui excde largement celle de l'image. Je l'ai programme en pensant au cas limite d'un fond d'cran,  et il faudra que je reprenne cela.


La matrice est incluse dans l'exe ? Mais comment c'est possible un truc pareil ? 
Quand tu dclares un objet d'une taille dmente, c'est  l'excution que le prog en mmoire va prendre de la place, pas  la compilation -- ou alors quelque chose m'chappe grandement !
Sinon, je faisais allusion  l'objet utilis pour afficher l'image (dans mon cas avec Lazarus j'utilise un composant TImage pos sur la fiche et donc affichage du rsultat ds le clic sur un bouton, mais d'aprs ce que je lis tu te contentes de gnrer un fichier visualis ensuite avec un outil extrieur, c'est lourd !)

- pour le temps d'excution, je viens de taper delphi mesurer temps d'excution et aprs tu as l'embarras du choix. Je ne te donne pas mon code, c'est du Linux pur et dur.

Voil pour les rponses. Maintenant, avanons :
ci-dessous un dgrad RYGCBMR comme j'aime  l'appeler (voir plus bas dans les bouts de code joints les commentaires pour passer d'un dgrad  l'autre). Il est classique et trs joli en mode pilote 0, l je suis en pilote 9 g=40, j'ose esprer que les couleurs du dgrad sont justes, mais ce qui ne l'est pas ce sont les couleurs du graphique (ou alors c'est l'inverse ?) : 



Je ne te fais pas l'affront de coller une image du mode 0, c'est classique de chez classique le rouge dmarre  255, le bleu reste  0 et le vert dmarre  0 pour monter (NOTE : pour *discuter*, j'utilise la notation mathmatique 0,0 en bas  gauche mme si je sais bien que dans l'objet Image sous Linux le 0,0 est en haut  gauche).
Mais ce sont des droites.
Sur cette image, si le dgrad est correct, il faudrait que le vert, dmarrant  0, monte trs vite pour avoir du jaune au dbut et se stabilise en haut, ce qui n'est pas le cas, et pareil pour les autres : le rouge devrait rester en haut et descendre trs vite  la fin de son 1er parcours, et pareil pour la suite...
Et je ne sais pas o mettre les mains l-dedans sans casser tout le reste :


```

```



Ensuite j'ai un cadeau pour toi, dans Im02 une acclration d'environ 3 fois du temps d'excution (sur ma machine), mais je te conseille d'examiner le code avec le lien "dans une fentre  part", a sera plus confortable.
Tu noteras au milieu la ligne "optimisation" car, oui, je me suis rendu compte qu'un calcul tait effectu de haut en bas pour rien  chaque avancement du pointeur de colonne, quand une fois suffisait (puisqu'on n'a pas de dgrad haut-bas) :


```

```


C'est tout pour le moment (je ne sais pas ce qui se passe avec mon colis, toujours pas reu, mais du coup on a du bol pour l'avancement ici...)

----------


## wiwaxia

1)



> a m'nerve l'informatique, a m'nerve


Tu as probablement dans le mme dossier des versions diffrentes de procdures trs proches, et tu ne sais plus lesquelles sont les bonnes ... Il faut regrouper celles devenues inutiles, ou donner des noms appropris.
C'est pour moi vital, quand un programme se construit en parallle avec son unit: j'archive par scurit les anciennes versions, mais prends soin de les noter: Prog_00.pas, Prog_01.pas, Unite_00.pas, Unite_01.pas, etc ; sinon cela peut devenir inextricable.

2) 


> La matrice est incluse dans l'exe ?


Bonne remarque. J'ai confondu avec le message de compilation: _12084412 big data_ .

3) Le code, aprs lecture , parat correct et les couleurs et les courbes de l'image sont correctement places; cependant mais *elles diffrent par la valeur du paramtre (g)* (g>>1 pour le dgrad, g<<1 pour les graphes) - je crois que cela s'est dj produit. 
Or la fonction Ccg est appele deux fois, pour l'ordonne des graphes et la teinte locale du dgrad. Selon les versions suggres, ou bien:
a) la valeur de (g) est choisie en constante interne, et tu appelles la fonction d'une variable Ccg(w) (ou autre chose, peu importe ...): par d'erreur possible;
b) la valeur de (g) est celle d'une seconde variable, et tu dois retrouver la *mme instruction* CcG(40, w) .
Il est bien probable qu'il y ait pour les graphiques: CcG(0.025, w) .

4) Merci pour cette version plus rapide, qui vite bien des rptitions inutiles. Les variantes se sont succd  un tel rythme (il y a d'autres projets, en parallle) que cela m'a chapp.

----------


## Jipt

> 1) Tu as probablement dans le mme dossier des versions diffrentes de procdures trs proches, et tu ne sais plus lesquelles sont les bonnes ... Il faut regrouper celles devenues inutiles, ou donner des noms appropris.


J'utilise des procdures diffrentes, toutes dans la mme unit, mais je m'y retrouve : ce qu'il y a de sympa avec Delphi, Lazarus et peut-tre d'autres EDI, c'est la manire d'inclure des procdures (ou fonctions) dans des procdures (ou fonctions) :


```

```

Avec cette construction, subproc n'est connue *que* de mainproc et de rien d'autre, donc pas de risque d'erreur possible.

Pour enfoncer le clou, j'ai renomm ma proc Coef_C en locCoef_C, loc pour dire "local" et j'ai inclus la sous-proc CcG dans locCoef_C.
locCoef_C n'est appel que par Im01 et Im02, ces deux-l tant incluses dans une nouvelle proc appele par un clic sur un bouton qui passe le pilote et le bitmap de rception des calculs.
Code complet en fin de post.




> 3) Or la fonction Ccg est appele deux fois, pour l'ordonne des graphes et la teinte locale du dgrad. Selon les versions suggres, ou bien:
> a) la valeur de (g) est choisie en constante interne, et tu appelles la fonction d'une variable Ccg(w) (ou autre chose, peu importe ...): par d'erreur possible;
> b) la valeur de (g) est celle d'une seconde variable, et tu dois retrouver la *mme instruction* CcG(40, w) .
> Il est bien probable qu'il y ait pour les graphiques: CcG(0.025, w) .


Rien compris... Ce que je veux dire, c'est que je ne vois pas comment c'est possible.
En plus, *peu importe l'option choisie* dans le case Pil of :


```

```

j'ai *toujours la mme image* fausse au niveau du graphique, trs bizarre  ::koi:: 



Aurais-je mal mis en uvre cette histoire de CcG ?
Le code complet (juste vir l'optimisation, puisque tu es d'accord) de la proc, o tu verras que je force *g* au dbut de locCoef_C :


```

```


et comment l'appeler :


```

```

----------


## wiwaxia

# Intervertir les contenus les lignes (42) et (43):


```

```

pour obtenir:


```

```

et utiliser la fonction CcG(g, w).

# Lignes (52), (71) et (72): RAS


```

```

# Ligne (58)  corriger: 


```

```

la fonction est dfinie sur [-1 ; +1]


```

```

# Lignes (83), (94)  (96): l, je suis largu


```

```

Cela n'irait-il pas mieux en crivant (de tte):


```

```

La symtrie des branches d'hyperbole conserve leur forme au cours de leur renversement, d'o l'apparente correspondance entre (g) et (1/g).

----------


## Jipt

> # Intervertir les contenus les lignes (42) et (43):
> 
> 
> ```
> 
> ```
> 
> pour obtenir:
> 
> ...


Intervertir juste la mise en commentaire avec "*//*" suffit. 
Bon, a n'a peut-tre aucun rapport avec le fait que mes courbes sont fausses, et a ne s'arrange pas, lire dessous :




> # Ligne (58)  corriger: 
> 
> 
> ```
> 
> ```
> 
> la fonction est dfinie sur [-1 ; +1]
> 
> ...


Moi je veux bien (quoique... on dirait que tu as zapp le commentaire sur la ligne qui prcdait ma note "_pour dgrad RYGCBMR_" -- je te le remets : "_supprimer -1 fin de ligne intervient sur la couleur_") car d'une part je perds mon dgrad RYGCBMR, et d'autre part *les graphiques* ne sont de toute faon *pas en accord avec le dgrad*...  ::aie:: 


Une autre ide ?




> # Lignes (83), (94)  (96): l, je suis largu
> 
> 
> ```
> 
> ```


Meuh non, c'est juste que tu as oubli que le "0" tant "en haut" pour moi, il me faut "descendre" dans la matrice d'au moins Ha div 2 ( la louche) pour atteindre le dbut de la zone des graphiques,  ::P: ...

----------


## Jipt

Bon, j'arrive  unifier dgrad et graphique dans *ton* mode de couleurs (avec ce "-1"  l'endroit qui va bien) :



mais impossible d'avoir des graphiques cohrents quand j'enlve le "-1" pour avoir *mon* dgrad RYGCBMR  ::cry:: 

Ce qui prouve au moins *une* chose : c'est que je n'ai *rien compris* (je m'en doutais un peu, note bien...)

----------


## wiwaxia

> c'est juste que tu as oubli que le "0" tant "en haut" pour moi, il me faut "descendre" dans la matrice


Pour une *courbe ascendante*, (yancien) compt  partir du bas *augmente* donc (ynouveau) compt  partie de la limite suprieure *diminue*; le renversement de l'image doit conduire ainsi  une expression du type: (ynouveau) = Cte - (yancien) .
Autre faon de voir: les ordonnes positives dfinies  partir des limites extrmes (basse et haute) vrifient:
(yancien) + (ynouveau) = Cte = 0 + (Ha - 1)  (dans le cas particulier des extrmits)
en laissant de ct le dcalage (m), qui vient en second lieu.
Un simple dessin rend ces rsultats vidents - et permet de soulager l'effort de rflexion lors de l'criture du code.

Ton dernier message me parvient  l'instant; il ne sert  rien de jeter le manche aprs la cogne. Essaie toutes les modifications proposes, et renvoie les rsultats (image et code). Cela ne devrait pas dclencher de dbut d'incendie  ::aie:: 

PS_1: Je viens de regarder la dernire image de prs (j'ai un peu de mal  suivre), et  ::yaisse::  tout est dsormais cohrent.
De quoi te plains-tu ? Il n'y a plus qu'une translation horizontale  effectuer sur les fonctions pour retrouver "ton" dgrad (RYGCBMR).
Translation de (1/2) priode, donc gale  (1)  gauche ou  droite.

----------


## anapurna

salut 

il y a quand meme une erreur dant ton programme 
Ta matrice image est de 1...X et tes boucles commence  zero pour palier  ce probleme il te suffit de faire un decalage de 1 




```

```

----------


## Jipt

> Ton dernier message me parvient  l'instant; il ne sert  rien de jeter le manche aprs la cogne. Essaie toutes les modifications proposes, et renvoie les rsultats (image et code). Cela ne devrait pas dclencher de dbut d'incendie


Les modifications proposes dans ton post de Marignan (15h15,  ::ptdr:: ) ? Mais elles ont t essayes dans mes deux rponses suivantes, et tu vois bien que ce n'est pas brillant...




> Pour une *courbe ascendante*, (yancien) compt  partir du bas *augmente* donc (ynouveau) compt  partie de la limite suprieure *diminue*; le renversement de l'image doit conduire ainsi  une expression du type: (ynouveau) = Cte - (yancien).


Tu parles de *courbe ascendante*, OK, mais elle sort d'o ?
J'avais dj pos ce genre de question, mais elle a fini  la trappe, alors same player shoots again :
est-ce que le graphique est cens reprsenter une analyse du dgrad (auquel cas merci de me dire comment le construire) ou au contraire nous avons une information  faire afficher, genre for i := 1 to Image.Width-1 do Image[i] := offset + round(amplitude * sin(2 * pi * i / fréquence));, et le dgrad s'appuiera l-dessus pour se dessiner (aprs la courbe !) ?

Cette formule, c'est avec elle que j'ai dessin l'cran d'oscilloscope post il y a quelques jours, a m'a pris une poigne d'heures pour y arriver ; ici a fait des jours qu'on y est et l je suis face  un mur puisque j'ai deux procdures (Im01 et Im02) dont je ne sais pas comment elles s'articulent entre elles, donc bon voil, quoi...




> PS_1: Je viens de regarder la dernire image de prs (j'ai un peu de mal  suivre), et tout est dsormais cohrent.


Oui, c'est bien ce que je disais mais a concerne *tes* couleurs.




> De quoi te plains-tu ? Il n'y a plus qu'une translation horizontale  effectuer sur les fonctions pour retrouver "ton" dgrad (RYGCBMR).
> 
> PS_2: ... et en plus, veinard, il y a plusieurs solutions, dont une ultra simple et sans calcul:
> a) translation de (1/2) priode, donc gale  (1)  gauche ou  droite;
> b) permutation des couleurs, donc des indices (1, 2, 3) - je te laisse deviner laquelle ....


a) sans doute oui, en regardant bien l'image, mais je n'arrive pas  trouver o se cache ta fucking priode  ::furax:: 
On m'a toujours dit qu'il fallait bien nommer ses variables alors, face  ton avalanche de r, k, s, x etc., je suis mal, je suis trs mal... 
Tu as vu comment j'ai not les trois variables de ma sinusode qq lignes plus haut ? 
Alors quand j'essaye au pif, j'arrive  compresser le graphique,  le dplacer un peu vers la droite, mais en rgle gnrale c'est plutt Access Violation quand je sors de la matrice  ::aie:: .
b) permutation, j'y ai pass des heures et non, a ne le fait pas... Je n'y crois pas, tant qu'on ne m'aura pas montr que c'est possible. 
Exemple avec cet essai :


Le vert devrait tre monter trs vite ds le dbut (pour avoir du jaune) et rester haut jusqu' la fin du cyan, h bien, avec les courbes qu'on a (descente du rouge, monte du bleu, etc.), tu peux permuter tout ce que tu veux tu n'y arriveras pas.
Val...





> salut 
> 
> il y a quand meme une erreur dant ton programme 
> Ta matrice image est de 1...X et tes boucles commence  zero pour palier  ce probleme il te suffit de faire un decalage de 1


Euh, a a t corrig pour le dgrad : FOR x:= 0 TO La-1 DO begin, plus qu' le faire pour le graphique mais l, c'est un tel brouillard...

----------


## wiwaxia

Les boucles sont correctement crites, et suivent la convention :
x (ou y) variant de (ou compris entre) 0  (La - 1) ou (Ha - 1).
Il suffit de reprendre les bornes de dfinition de la matrice;


```
  Tab_Pix = ARRAY[0..Dim_Max-1, 0..(Dim_Max div 2)-1] OF Pixel;
```

le seul changement important concerne la valeur minimale (0) si les dimensions de l'image sont infrieures aux valeurs limites.
J'avais supprim le (b), qui ne donne pas ce que tu attends (cyan au centre, trs large, et bord de bleu  droite).

 partie de la mme fonction CcG(g, w), tu peux obtenir un nouveau dgrad en codant:



```

```

Le spectre ne change pas d'aspect par renversement, mais pour les graphes il faut oprer le changement d'ordonne dj dcrit: Ynou = Cte - Yanc .




> Tu parles de courbe ascendante, OK, mais elle sort d'o ?


Je prenais en exemple une branche montante du graphe ... un dessin livre immdiatement la rponse:
quand on se dplace sur le graphe de (M) vers (M'), Yanc (ordonne du point sur l'cran, dfinie depuis la base de l'image) augmente, Ynou (rang de la ligne compte depuis le haut) diminue et leur somme reste constante.
Si tu as compris cela, c'est l'essentiel, la valeur de la constante est accessoire.

----------


## Jipt

Bonsoir,

ce soir je ne code rien, je suis vann. 

Juste deux points  propos de ton post :



> J'avais supprim le (b), qui ne donne pas ce que tu attends (cyan au centre, trs large, et bord de bleu  droite).


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




> Je prenais en exemple une branche montante du graphe ... un dessin livre immdiatement la rponse:
> Pice jointe 224621


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

Et la question de la poule et de l'uf est toujours sans rponse : le dgrad  l'origine de la courbe ou la courbe  l'origine du dgrad ?
Quand j'ai une jolie  courbe sur l'cran de mon oscillo physique, c'est parce que j'ai accroch sa sonde  un gnrateur, tu vois ?

----------


## wiwaxia

1) J'ai rectifi la rponse quelques minutes aprs, en m'apercevant que c'tait une impasse; et comme tu as d ouvrir la page du forum ds l'arrive du courriel, celle-ci ne s'est pas renouvele, et tu n'a pas t inform de la modification. C'tait un mauvais choix, j'aurais d t'avertir. Dsol.

2) a) Tu peux garder la fonction telle qu'elle est donne, avec les 3 relations donnes dans le prcdent post.
Tu t'effraies inutilement du vocabulaire: effectuer une translation d'une demie-priode, c'est remplacer F(r) par F(r + Pe/2), soit ici F(r + 1) puisque Pe = 2 . Les dcalages prcdents (de Pe/3 , soit 2/3) ne t'avaient caus aucun problme.
b) L'autre solution, encore plus brve, consiste changer l'expression de (w) en fonction de (t) par une modification minimale dans locCoef_C(Pilote, t); au lieu de  


```

```

crire


```

```

# J'ai rajout des prcisions dans le message qui suit

3) L'autre obstacle, c'est le changement de variable dcoulant du renversement de l'image, au sujet duquel plus j'en dis, moins tu comprends ... Essayons un modle plus simple (je suis obstin).
La matrice et l'image sont constitues d'un ensemble de lignes que l'on peut indexer:
a)  partir de la ligne la plus basse: Yimage = 0, 1, 2, 3, ... , 9 (s'il y a en tout 10 lignes);
cet indice reprsente naturellement la hauteur d'un pixel par rapport au bord infrieur de l'image;
b)  partir le la ligne la plus haute: Ymatrice , qui peut prendre le mme ensemble de valeurs;
cet indice reprsente la distance d'un pixel par rapport au bord suprieur de l'image.

On observera dans une colonne donne (d'indice x) les valeurs suivantes, qui vrifient: Yimage + Ymatrice = Cte = 9 :


```

```

On repre la position de tout pixel par la valeur du premier indice (Yimage), qu'il appartienne au dgrad ou  l'un des graphes; mais la couleur doit tre affecte  l'lment correspondant de la matrice, sur la ligne de rang (Ymatrice); d'o l'instruction dcisive de la forme: 


```
Ma[x, 9 - Yimage):= Px
```

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

----------


## wiwaxia

Bonjour,  ::D: 

L'image que tu as poste le 07/11/2016  18H42

reprsente correctement (mme si sa programmation tait  reprendre) le lien entre l'volution des teintes et la variation des coefficients de couleur dans le cas (g = 1). On y trouve de plus le dgrad (RYGCBMR) que tu recherche.
La fonction de base w = f(t), dont le nouveau code vient d'tre donn, est reprsente par le graphe rouge; elle est toujours paire (f(-t1) = f(t1) et prsente encore un palier horizontal centr en (t = 0); mais l'ordonne de celui-ci est nulle.

Il faut associer les couleurs aux dcalages suivants:
Rouge (3) _ _ _ w = f(t) _ _ _ _ _ pas dcalage
Vert _ (2) _ _ _ w = f(t - 2/3) _ _ dcalage vers la droite de (1/3) de priode
Bleu _ (1) _ _ _ w = f(t + 2/3) _ _ dcalage vers la gauche de (1/3) de priode
... ce qu'on retrouve pratiquement au niveau des instructions dj examines:


```

```

----------


## Jipt

Salut,



> # J'ai rajout des prcisions dans le message qui suit


avec une magnifique faute d'inattention qui m'a failli faire passer l'ordi par la fentre, suivi d'un AVC, mais je me suis repris et j'ai rflchi...




> ```
> 
> ```




```

```


et aprs cette dernire correction, j'ai l'honneur, la joie et le plaisir de t'annoncer que le dgrad et le graphique sont *enfin en phase* !
Et ce, quel que soit le pilote,  ::yaisse:: 
Et avec un magnifique dgrad RYGCBMR, trop top !

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

Ah non, reste un point : tu devais me parler de la lumire visible... 
Si ma mmoire est bonne, la principale diffrence entre nos dgrads et celui de la LV, c'est que nous passons du rouge au jaune quand la LV passe par une tape orange, et nous avons du cyan entre le vert et le bleu quand il me semble qu'il n'existe pas en LV, et o on trouve un violet proche de mais pas identique  notre magenta.

Une ide l-dessus (mais prends ton temps, on n'est pas aux pices,  ::mouarf:: )
Tiens, je ne sais pas si tu connais, si "non", ton bonheur sera complet, lol !

Bonne journe, merci encore  ::ccool::

----------


## wiwaxia

L, cela commence  devenir flippant  ::calim2:: 



> avec une magnifique faute d'inattention qui m'a failli faire passer l'ordi par la fentre, suivi d'un AVC, mais je me suis repris et j'ai rflchi...


Je ne saurais endosser la responsabilit d'une erreur ayant pu conduire  la dfenestration de ton matriel, et  une attaque crbrale: la squence donne


```

```

tait intentionnelle, mrement rflchie et plusieurs fois vrifie (d'o le style lourd et rptitif des indications). Et j'ai attendu d'tre remis du coup de pompe d'hier pour reprendre les donnes.

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

Cre une image pour (g = 5), par exemple, en respirant profondment et sans angoisse  ::arf::  , et envoie le rsultat: je saurai que tu n'es pas pas parti aux urgences, et ton PC se trouve toujours sur ton bureau.
Et bravo si a marche !  ::lol::

----------


## Jipt

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


Mais rien !
J'tais en train de me battre avec ton post de cette nuit quand l'autre est arriv, du coup je l'ai mis en service avec tes deux modifs et celle de la veille      v:= Abs(u); w:= (3 * v) - 1; IF w>1 THEN w:= 1 et c'est tout !
J'ai excut, j'ai constat l'inversion de pixels que j'ai remonte ici aussitt et pas plus !
Tous mes essais suivants sont bass sur l'appel de la procdure o je modifie le n du pilote et rien d'autre.




> Cre une image pour (g = 5), par exemple, en respirant profondment et sans angoisse  , et envoie le rsultat: je saurai que tu n'es pas pas parti aux urgences, et ton PC se trouve toujours sur ton bureau.
> Et bravo si a marche !


La voil :



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

----------


## wiwaxia

Flicitations pour ta tnacit !  ::bravo::  La persvrance finit par payer ... et j'tais agac de ce qu'une jonction ne puisse tre  compltement tablie entre deux programmes, de langages trs proches.
Je reprendrai plus tard sur des sujets annexes.

----------


## Jipt

> Flicitations pour ta tnacit !  La persvrance finit par payer ... et j'tais agac de ce qu'une jonction ne puisse tre  compltement tablie entre deux programmes, de langages trs proches.


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

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




> Je reprendrai plus tard sur des sujets annexes.


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

Mais relche cet aprme.

----------


## wiwaxia

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

J'ai regard ce que pouvait donner la superposition horizontale de dgrads correspondant  diverses valeurs de (g), comme tu l'avais fait sur quelques exemples; visuellement, le rsultat est un peu dcevant.

 _ 

Le paramtre (g) est ici fonction exponentielle de (y), et varie de (10-2)  (10+2) du bas vers le haut de l'image; la fonction f(t) est directement relie  la couleur centrale (vert), et l'on a f(0) = 0 pour la premire image, et f(0) = 1 pour la seconde. Le dcalage habituel de (+-2/3) est appliqu aux autres couleurs.

On peut aussi chercher  reprer (si elle existe) la valeur de (g) conduisant  la meilleure quirpartition des diverses teintes; dans les images suivantes, (g) dpend linairement de (y)  et varie de (0.5)  (3.5); l'abscisse est divise en douzimes de priode, et chaque teinte devrait en occuper deux, en moyenne. 
a) f(0) = 0 pour le vert:

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

La valeur optimale parat tre de l'ordre de 2.0 - rsultat imprcis, en l'absence de frontires nettement discernables.

----------


## Jipt

Bonjour,

Ouh lala, joli travail !
Je n'en vois absolument plus l'intrt, en ce qui *me* concerne, mais joli travail quand mme.
 :+1: 




> --snip-- Il est donc *trs facile* de passer de l'une  l'autre par programmation. --snip--


 ::rire::   ::marteau::   ::wow::   ::cfou::   ::lefou::   ::fou::   ::koi:: 

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

Autre chose qui m'a considrablement surpris : au lieu de dclarer la matrice statique avec taille impose par la constante, je l'ai dclare dynamique avec dimensions imposes par le bitmap cible, rsultat 1- il m'a fallu tricher : SetLength(Matrix, Larg_Image*+1*, Haut_Image); //*+1* car x du graphique arrive  1536... que je ne m'explique pas bien, d'ailleurs ; Mais si pas *+1* alors violation d'accs  ::aie:: 
2- a double (ouais ouais, a double !) le temps d'excution de la procdure de dessin, comme si le compilateur rajoutait, dans ce cas, une squence d'initialisation (remplissage avec des zros ou autre ?)
Bref, retour en arrire et array statique, dommage.

Et sinon, des nouvelles de la lumire visible ?
Bon dimanche,

----------


## wiwaxia

Bonsoir,  ::D: 

# Je redoutais une raction allergique  toutes ces austres remarques ...



> Il est donc *trs facile* de passer de l'une  l'autre par programmation.


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


```

```

# 


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


Fonction *C*efficient *c*ouleur dpendant du paramtre *G*: j'tais press de coder, et j'ai pris ce qui m'est venu en tte pour minimiser l'effort de mmoire. Il s'agit  en fait d'un facteur de correction non linaire Fcnl(g, w). Un certain recul permet de meilleurs choix.

# 


> Autre chose qui m'a considrablement surpris : au lieu de dclarer la matrice statique avec taille impose par la constante, je l'ai dclare dynamique avec dimensions imposes par le bitmap cible, rsultat 1- il m'a fallu tricher : SetLength(Matrix, Larg_Image+1, Haut_Image); //+1 car x du graphique arrive  1536... que je ne m'explique pas bien, d'ailleurs ; Mais si pas +1 alors violation d'accs


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

# 


> je supprime des longueurs, au dtriment de la lisibilit, je te l'accorde,  ...  car je me suis rendu compte que je gagnais des millisecondes par ci par l avec ce genre de manips.... une opration en moins = une milliseconde ( la louche) gagne !


Je veux bien, mais est-ce vraiment indispensable ? Le dlai de calcul n'est pas trs long.

D'abord ne pourrais-tu pas injecter directement les valeurs calcules dans la matrice image de la variable 'bmp' ? 
Le tableau de pixels de type dfini _ARRAY[0..Max1, 0..Max2] OF Pixel_ permettait de faire le lien entre nos deux algorithmes, et de centrer l'change sur le codage des dgrads ... Il n'est peut-tre plus indispensable.

De plus compte tenu du nombre trs lev d'lments  dterminer, le recours aux pointeurs ne permettrait-il pas de rduire substantiellement le temps d'excution ? Un tableau de pointeurs , par exemple ? Je ne suis pas familier de ce procd, et je reprendrai peut-tre plus tard en ce sens la programmation des sujets actuels.
Question  creuser dans des cours de Pascal; l il y en a d'excellents sur ce site. Consulter aussi dans  cette *discussion*, l'intervention de *souviron34* (11/06/2016, 18h29).

J'avais tenu  faire le tour de la question avant de passer  la lumire visible, question sur laquelle tu dsires apparemment recevoir quelques claircissements  ::mouarf:: 

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

----------


## Jipt

Bonjour,



> Je veux bien, mais est-ce vraiment indispensable ? Le dlai de calcul n'est pas trs long.


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




> D'abord ne pourrais-tu pas injecter directement les valeurs calcules dans la matrice image de la variable 'bmp' ? 
> Le tableau de pixels de type dfini _ARRAY[0..Max1, 0..Max2] OF Pixel_ permettait de faire le lien entre nos deux algorithmes, et de centrer l'change sur le codage des dgrads ... Il n'est peut-tre plus indispensable.


J'y ai dj song, mais j'ai tellement de trucs  grer...




> De plus compte tenu du nombre trs lev d'lments  dterminer, le recours aux pointeurs ne permettrait-il pas de rduire substantiellement le temps d'excution ? Un tableau de pointeurs , par exemple ? Je ne suis pas familier de ce procd, et je reprendrai peut-tre plus tard en ce sens la programmation des sujets actuels.
> Question  creuser dans des cours de Pascal; l il y en a d'excellents sur ce site. Consulter aussi dans  cette *discussion*, l'intervention de *souviron34* (11/06/2016, 18h29).


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




> J'avais tenu  faire le tour de la question avant de passer  la lumire visible, question sur laquelle tu dsires apparemment recevoir quelques claircissements


 ::ccool:: 
Et ce qui me pose le plus gros problme, c'est la manire de rendre les couleurs (je m'exprime mal, mais tu vas voir) car, par exemple sur cette page bien documente, il y a un tableau en bas *et* tout en bas en cliquant sur "Spectre lectromagntique en dtail [afficher]" on en voit un autre, et les couleurs ne sont pas les mmes entre ces deux tableaux ! Pour moi la question est simple : o est la Vrit ?
Pour le moment j'en suis l; mais c'est une interprtation toute personnelle :





> # Au passage, un lien vers un site prsentant un *grand nombre d'algorithmes*, en tous langages. Tu auras de quoi t'occuper.


Je bookmarke, on ne sait jamais.  :;): 

Merci pour tout ce qui prcde, et trs bonne journe,

EDIT :
Arggggh, tu me refais le coup d'diter ton message de la nuit *aprs* ma rponse du matin,  ::fou:: 



> # 
> Nous avons dj voqu le choix du premier indice (0 ou 1) - une instruction inapproprie ne tranerait-elle pas dans *tes* programmes ? D'autre part, tu as fait le choix du "sur mesure", les dimensions de la variable matrice concidant avec celles du corps de l'image Bitmap; alors qu'en ce qui me concerne, elle les dpasse largement (Max1 = Max2 = 2000) - trop, sans doute ... Tu peux donc rencontrer plus souvent des problmes de transgression de limite.
> Attention aux fonctions discontinues: Int(1535.999) = 1535 ; Int(1536.000) = 1536 . C'est la petite surprise qui peut surgir en fin de boucle !


Mes programmes  ::koi:: 
_Attention aux fonctions discontinues: Int(1535.999) = 1535_
a doit tre a, l'embrouille : round(1535.5xx); --> 153*6*  ::aie:: 
 l'occasion j'essayerai avec un trunc(1535.5xx);

----------


## souviron34

Salut  tous..

Je reviens aprs quelques mois de semi-absence et je me vois cit  ::oops::   ::oops::  ::oops:: 

J'essaierais de remonter la discussion pour remonter le code (_ moins que sympathiquement vous ne fournissiez la version actuelle_ ) et faire la traduction avec les pointeurs ... Ca devrait sans doute, d'aprs ce que je comprend, acclrer pas mal..


Juste un petit point :




> _Attention aux fonctions discontinues: Int(1535.999) = 1535_
> a doit tre a, l'embrouille : round(1535.5xx); --> 153*6* 
>  l'occasion j'essayerai avec un trunc(1535.5xx);


En gnral, on fait :

int (_valeur+0.50_).

(_de 1535.50000000000  1536.499999999 => 1536_)
(_de -1536.500000000000  -1535.49999999999 => -1536_)

 ::D:

----------


## wiwaxia

Bonjour,  ::D: 

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

Cordialement, W.

----------


## Jipt

Messieurs bonjour,



> En gnral, on fait :
> 
> int (_valeur+0.50_).
> 
> (_de 1535.50000000000  1536.499999999 => 1536_)
> (_de -1536.500000000000  -1535.49999999999 => -1536_)


Oui mais ici la valeur ngative ne nous intresse pas car il est juste question de remplir la matrice, de 0  Length-1.

J'ai rajout une petite fonction de log juste aprs le calcul de x qui, je le rappelle, fonctionne comme a : 


```

```

et a donne ces valeurs ( gauche le x "rounded",  droite la formule sans le "round") (j'abrge, il n'y a que le dbut et la fin) :


```

```

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


```

```

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

Je n'ai pas remarqu de diffrences en termes de rendu des couleurs, dgrad comme graphique.

----------


## tbc92

Si je vois bien, ta boucle va s'excuter 10000 fois ( 5000+5000), alors que ton image fait 1536 colonnes. Chaque colonne va donc tre colorie 6 voire 7 fois.

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



```

```

----------


## wiwaxia

> Si je vois bien, ta boucle va s'excuter 10000 fois ( 5000+5000), alors que ton image fait 1536 colonnes. Chaque colonne va donc tre colorie 6 voire 7 fois


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




> Tu peux diviser tes temps de traitement par 6


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

----------


## Jipt

> L,  c'est trop faible et le trac sera altr. Il faut une estimation de la longueur totale du graphe.


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



En haut la boucle optimise de tbc92, temps d'excution global de la cration + affichage du dessin : 24 millisec.
En bas la boucle "laborieuse" (arf !) de wiwaxia, temps d'exc 25 millisec.
Attention, pour bien montrer les dtails, l'image est fortement agrandie et l'immense trait vert au milieu a t considrablement lagu.

----------


## tbc92

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

----------


## anapurna

salut 

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

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



```

```

je suppose donc quand connaissant la fonction inverse on devrais pouvoir retrouver nos lments
PS je pencherai donc pour une fonction sinusodale ce qui implique une priode de 360 
on retrouve ici le principe de l'onde ce qui est bien notre cas pour de la lumire ou couleur

----------


## souviron34

> Oui mais ici la valeur ngative ne nous intresse pas car il est juste question de remplir la matrice, de 0  Length-1.


Si tu me permets a ne change rien  la formule gnrale  ::P: 

Je maintiens que la formule que j'ai mise est celle qui donne *toujours* le bon rsultat : *arrondi  l'entier le plus proche*..






> J'ai rajout une petite fonction de log juste aprs le calcul de x qui, je le rappelle, fonctionne comme a : 
> 
> 
> ```
> 
> ```


* petite note de plus : faire une division par 2 sans mettre 2*.0* (_ou toute autre valeur entire sans mettre le ".0" aprs_) fait faire une division _entire_ au compilo, dans la grande majorit des cas  ::aie:: )



Et si tu veux acclrer d'un bon facteur tu cris :



```

```


(2 additions par tour au lieu de 2 divisions + 1 multiplication + 1 addition)



Mainrenant ton problme de +1, c'est juste parce que tu prends ton indice de -Lim  +Lim

Prenons simplement :

une image de dimension Dx, on l'explorera de i = 0  i < Dx  (Dx valeurs,  cause du 0)
En faisant de -Lim  +Lim tu fais 1000*1* valeurs

 ::P: 

Ton code devrait donc tre :



```

```



Quant au crash, normal si tu prends un log avec x = 0  ::D: 



(_A moins que je n'ai rien compris  tout a (pas vraiment approfondi, juste premires impressions en survolant .. Si c'est le cas je m'en excuse par avance_  ::oops::  ::oops:: )

----------


## souviron34

Je rajouterais un petit commentaire...


Soit une image de dimension Dx que l'on veut afficher sur un cran de dimension DDx


Chaque pixel de l'image devra tre tal sur   DDx/Dx  pixels de l'cran

Si l'image est plus petite que l'cran, DDX/Dx sera > 1, on aura donc comme un certain "zoom" : il faudra rpter pour un certain nombre de colonnes de l'cran la mme colonne de l'image.  
Dans le cas contraire, si on veut que toute l'image soit visible, il faudra calculer quelle colonne de l'image on va vouloir afficher pour telle colonne de l'cran..



Comme on ne peut afficher que des pixels entiers, dans un sens ou dans l'autre, il faut effectuer des arrondis..  La seule manire de le faire est via les arrondis au plus proche entier, mais c'est le SENS dans lequel on fait la transformation qu va importer (_c'est le cas avec les rotations d'images. Informez-vous sur Effet de Moir (physique) (Wiki). On prend les pixels de l'image A CALCULER et on renverse la rotation pour savoir quel pixel de l'image d'origine on doit prendre... Cela garanti de ne pas avoir de trous_)..


Dans notre cas, on a donc 1 seul cas de figure :  notre arrive est l'cran

On explore le DDx de l'cran (_ou de la zone attribue au trac_) de 1 en 1, et on calcule le i correspondant dans l'image d'origine par arrondi

----------


## foetus

> Comme on ne peut afficher que des pixels entiers, dans un sens ou dans l'autre, il faut effectuer des arrondis..


Il a des techniques pour cela supersampling, oversampling et autres  ::mrgreen::   ::mrgreen::

----------


## anapurna

salut 

suite a mon message je continue sur mon elan  :;): 




```

```

----------


## souviron34

> Il a des techniques pour cela supersampling, oversampling et autres



Toutaf, a n'empche pas de comprendre le principe  :;):

----------


## Jipt

Bonsoir  tous,

Ouh lala, quelle active participation, en plus, juste le mardi que pour moi c'est tendu,  ::mrgreen:: 




> Si l'image est plus petite que l'cran, DDX/Dx sera > 1, on aura donc comme un certain "zoom" : il faudra rpter pour un certain nombre de colonnes de l'cran la mme colonne de l'image.Dans le cas contraire, si on veut que toute l'image soit visible, il faudra calculer quelle colonne de l'image on va vouloir afficher pour telle colonne de l'cran..


Je vais en dcevoir certains, mais je ne me prends pas la tte avec cet aspect "bassement matriel" des choses,  ::mouarf:: , j'utilise pour l'affichage un composant (Delphi ou Lazarus c'est pareil) TImage quip d'une fabuleuse proprit "stretch" qui fait exactement ce qu'il faut juste en la basculant  True et hop !

a permet de se consacrer (se concentrer)  des tches plus nobles, comme comparer les procdures de souviron34  celles de wiwaxia et, indpendamment du dcalage dans l'affichage (normal, on ne va plus de -Lum  + Lum mais de 0  2Lum-1), en termes de perfs, dsol souvi, mais on ne gagne rien ! Keud ! Pas un kopec...
Les deux manires de faire affichent le dgrad en haut et le graphique dessous en environ 25 millisec.
(Dgrad pas complet pour pas trop alourdir l'illustration, les graphiques : en haut souvi en bas wiwaxia) :


 propos de ma division par 2, tu disais :



> petite note de plus : faire une division par 2 sans mettre 2.0 (ou toute autre valeur entire sans mettre le ".0" aprs) fait faire une division entire au compilo, dans la grande majorit des cas )


Est-ce que c'est grave, dans la mesure o le rsultat sera de toute faon arrondi ? Rappel du code : x:= Round(((r+1) * Larg_Image) / 2);, tant entendu que j'ai remplac cette divison par 2 par une multiplication par 0.5.

Allez, je vais voir ce que propose l'ami Anapurna.

 pluche  ::coucou::

----------


## wiwaxia

Pour reprendre les remarques de 3 d'entre vous concernant plus ou moins directement le calcul ou la slection des pixels, le programme a t conu pour la cration d'une image plus petite que l'cran. Maintenant chacun peut introduire les variantes appropries en fonction des dimensions choisies et de ce qu'il voit sur l'cran. Le dlai de calcul ne dpasse la seconde, et la rapidit est pour l'instant reste hors de mes proccupations - ce qui n'enlve rien  l'intrt de la mthode propose par *souviron34* - et que j'avais signale.

@ *souviron34*, justement:



> * petite note de plus : faire une division par 2 sans mettre 2.0 (ou toute autre valeur entire sans mettre le ".0" aprs) fait faire une division entire au compilo, dans la grande majorit des cas )


En langage Pascal, le symbole '/' *conduit toujours  un rel*.
_Les oprateurs arithmtiques du Pascal sont :
Oprateur 	Opration _ _ _ _ Oprandes _ _ _ _Rsultat
 ... / ...
/ 	Division relle _ _ _ _ _ real or integer _ _ real
div 	Division entire _ _ _ _ integer _ _ _ _ _ _ integer
mod 	Modulo (reste entier) _ 	integer _ _ _ _ _ _ integer_ 

div et mod ne fonctionnent que sur les integers.* / fonctionne sur les reals et les integers mais retourne toujours un rsultat real.*

@ *anapurna*



> je suppose donc quand connaissant la fonction inverse on devrais pouvoir retrouver nos lments
> PS je pencherai donc pour une fonction sinusodale ce qui implique une priode de 360
> on retrouve ici le principe de l'onde ce qui est bien notre cas pour de la lumire ou couleur


Il m'a fallu relire plusieurs fois le texte entier pour comprendre, et ce que j'en ai saisi est un peu inquitant: ne serais-tu pas en train de confondre
a) les coefficients de pondration des 3 couleurs fondamentales, dfinies sur [-1 ; +1], de priode gale  2 (pour des raisons pratiques) et dcales entre elles de (1/3) de priode: Coef_C(t), Coef_C(t + 2/3),  , Coef_C(t - 2/3) (en laissant de ct le paramtre d'option 'Pilote') ...
b) la structure des ondes des ondes lectromagntiques, qui rsultent de la propagation dans l'espace des oscillations simultanes de deux champs *E* et *B* ?

De ceci, il n'est nullement question, et l'on ne retient que la notion de longueur d'onde (ventuellement la frquence) pour caractriser une radiation monochromatique - et le lien avec les fonctions colorimtriques est une question difficile.
Si la largeur de l'image se superpose  la priode de Coef_C(t), c'est parce qu'on a choisi de faire apparatre la mme couleur aux extrmits de la palette, ce qui rend possible le passage d'une figure linaire  une figure circulaire.
Quand au recours  une fonction sinusodale, il est envisageable sous rserve de faire intervenir une translation et deux crtages, ce qui modifie passablement la fonction de dpart; je laisse le soin de vrifier le code, crit rapidos,  ceux qui seraient intresss:


```

```

Peu de changement, finalement, si l'on superpose les 2 graphes sur leur domaine [-1 ; +1] .

----------


## anapurna

salut 

effectivement wiwaxia, je mtait emptrer dans mes propre incomprhension du code
c'est pour cela que j'ai post une suite aprs les diverses rponses pour retrouver tes fameux coefficient en partant de x 
j'ai suppos que les lments tait rversible c'est  dire que si tu peut trouver x a partir de r il n'est pas inconcevable de retrouver r 
 partir de x l'avantage de partir de x c'est que celui-ci est connu pas besoin d'une matrice supplmentaire pour dfinir un coef 
maintemant je peut me tromper

----------


## wiwaxia

Ah oui, j'oubliais: l'introduction de la fonction cos(Pi * t), de priode gale  (2), permet un allgement du code par la suppression des 3 premires lignes, o tait impose la condition de priodicit:


```

```

----------


## Jipt

Bonsoir,

wiwaxia et anapurna, je ne comprends rien  votre apart...
wiwaxia, dans les codes que tu as posts, dans le 1er tu mets v := Abs(u); dans le second tu mets v := Abs(t); mais *dans les deux cas* ton "v" n'est ensuite pas utilis, donc cette conversion ne sert  rien ! 
Truc de ouf'  ::koi:: 
Par ailleurs, je n'ai fait qu'un seul test (flemme) mais j'ai constat que le rsultat est le mme, selon que j'utilise directement t, u ou v dans le calcul de cos(Pi...
Vraiment bizarre cette nouvelle adaptation, qui en plus fait perdre le beau dgrad RYGCBMR





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


L aussi je ne comprends rien, anapurna : tu dis que la boucle est trop longue alors qu'elle va de -5000  +5000 soit 10001, et tu proposes de la remplacer par 100000 ! 10 fois plus ! Rien compris.
Mais peut-tre que cette remarque n'est plus valide ?


Et sinon, pour optimiser, il faudrait s'affranchir du passage par la matrice et crire directement dans RawImage.Data puisque l'appel de la procdure passe le TBitmap destinataire des donnes, j'ai furet un peu hier soir mais pour le moment a n'a pas l'air aussi simple que a...

----------


## anapurna

salut jipete 
c'etait une remarque sarcastique ... le choix arbritaire des 5000 n'est pas coherent c'est pour cela que j'ai dis pourquoi pas cent mille 
d'ou ma recherche a partir de x qui represente une valeur concrete et pas un choix arbitraire ... le reste de ma demonstration est toujours valide 
j'ai bien remplac 

```
for k := - lim to lim
```

 par 

```
for k:=0 to la-1 do ....
```

----------


## wiwaxia

Bonjour,  ::D: 

Le post d'*anapurna* contenait une bonne ide, le recours  une fonction sinusodale, mais sans prciser les amnagements ncessaires.




> ... wiwaxia, dans les codes que tu as posts, dans le 1er tu mets v := Abs(u); dans le second tu mets v := Abs(t); mais *dans les deux cas* ton "v" n'est ensuite pas utilis, donc cette conversion ne sert  rien ! 
> Truc de ouf'


La chane des transferts des valeurs numriques est maintenue - mais seulement plus courte dans le second cas. J'avais oubli de supprimer une autre consigne, 

```
v:= Abs(u);
```

 devenue inutile en raison de la parit de _cos(Pi * t)_ ; cependant le transfert des Valeurs n'tais pas interrompu.

a) (t) ──> (u) ──> (v) ──> (w)


```

```

b) (t)  ──> (w)



```

```

L'cart entre les deux fonctions au niveau des segments inclins ne dpasse pas 0.00904: elles conduiront donc (pour (g) donn) aux mmes teintes.
Il serait intressant de comparer les temps de calcul sur de grandes images: je ne suis pas sr qu'une fonction trigonomtrique permette la plus grande rapidit.

----------


## Jipt

Salut  tous,




> Il serait intressant de comparer les temps de calcul sur de grandes images: je ne suis pas sr qu'une fonction trigonomtrique permette la plus grande rapidit.


Donc, comme dit prcdemment, ta nouvelle version, wiwaxia, me fait perdre mon beau dgrad RYGCBMR et sinon, en termes de perfs, a se tient avec les autres, pour mon bitmap 1536x512 : environ 25 millisec tout compris, ici avec pilote 3





> salut jipete 
> c'etait une remarque sarcastique ...


anapurna, rappelle-toi *toujours* que l'humour disparat lors du passage  l'crit,  moins de le blinder de tags [HUMOUR][/HUMOUR], la preuve je ne l'ai absolument pas capt/peru dans ton post... Oui, il tait "devinable" mais je me refuse  deviner/supposer autre chose que ce que je lis, sinon c'est la porte ouverte  tout et n'importe quoi.





> j'ai bien remplac 
> 
> ```
> for k := - lim to lim
> ```
> 
>  par 
> 
> ```
> ...


Et pour cette modif, c'est dans le droit fil de la proposition de souvi, renvoye au vestiaire :



> ... comparer les procdures de souviron34  celles de wiwaxia et, indpendamment du *dcalage dans l'affichage* (normal, on ne va plus de -Lum  + Lum mais de 0  (2Lum-1),



Bonne journe,

----------


## wiwaxia

> ... Donc, comme dit prcdemment, ta nouvelle version, wiwaxia, *me fait perdre mon beau dgrad RYGCBMR* ...


Nulle tentative de harclement de ma part  ::aie:: , tu as simplement pris la mauvaise option conduisant  F(0) = 1 , ce qui installe une couleur primaire au centre  ::mrgreen::  .
Il fallait prendre l'autre fonction disponible, vrifiant F(0) = 0 et donnant ainsi une couleur secondaire au centre.
 (Re)voir les explications donnes plus haut (14/11/2016, 00h46), par une nuit de pleine lune. a marque, ordinairement


```

```

----------


## Jipt

> Nulle *tentative de harclement* de ma part , tu as simplement pris la mauvaise option conduisant  F(0) = 1 , ce qui installe une couleur primaire au centre  .


Non non, juste que tu m'embrouilles avec tes mots !  ::mrgreen:: 
Quand je vois crit "version initiale" et "version modifie", je me dis qu'il y a des petites modifs pour optimiser des trucs et des machins, mais pas pour partir dans une autre direction !

Tu aurais d crire "version drive, pour tests only", et au final, alors, elle sert  quoi cette version avec cos(Pi... ( part  me faire des nuds dans la tte  ::mouarf:: ) ?




> Il fallait prendre l'autre fonction disponible, vrifiant F(0) = 0 et donnant ainsi une couleur secondaire au centre.


tant entendu que l'autre option (les pilotes pairs si j'ai bien suivi) ne me le raffiche pas plus... :
pilote 2, juste la partie centrale :

----------


## wiwaxia

> ... Non non, juste que tu m'embrouilles avec tes mots ! 
> Quand je vois crit "version initiale" et "version modifie", je me dis qu'il y a des petites modifs pour optimiser des trucs et des machins, mais pas pour partir dans une autre direction !
> 
> Tu aurais d crire "version drive, pour tests only" ...


a, c'est vrai, j'en suis dans mes archives  ma 5me version, et d'autres ne vont pas tarder  suivre compte tenu de toutes les ides exprimes sur ce forum. Je t'avais prvenu de bien classer les versions successives.  ::D: 




> et au final, alors, elle sert  quoi cette version avec cos(Pi... ( part  me faire des nuds dans la tte ) ?


Non, pas spcialement; je n'en avais pas parl jusque l, afin d'viter des complications inutiles et de de pas avoir  dcrocher le 15  ::aie::  ... Mais  partir du moment o un autre intervenant a mis le sujet sur le tapis, j'ai suivi.
Comme a, je ne suis ni responsable, ni coupable.

----------


## wiwaxia

Bonjour,  ::D: 

J'ai repris la programmation compare du dgrad de couleurs, selon l'chelle de teintes (RYVCBMR) si chre  *Jipt*  ::mrgreen::  et en minimisant la saisie des donnes, le choix de l'une des quatre fonctions possibles dcoulant de la valeur de la variable 'pilote':
# Coeff_C(0) = 0 ou 1 selon que (p) est pair ou impair;
# Coeff_C(t) f/linaire par morceaux ou f. sinusodale crte selon que (p) est infrieur ou suprieur  9.5 . 

L'image comporte  chaque fois 5 dgrads horizontaux correspondant  diverses valeurs du paramtre (g): (w/16 , w/4 , w=2.5 , 4*w, 16*w). 

Comme on pouvait s'y attendre, les carts sont indiscernables pour les deux types de fonctions.
Le temps de calcul de la matrice est par contre nettement augment (~ 50 %) lorsqu'intervient une fonction sinusodale, la relative souplesse lie  l'emploi d'une fonction paire et priodique (cos(Pi*t)) se payant d'un allongement du dlai d'apparition de l'image; pour une image 900x900, les valeurs affiches en fin d'excution taient de 0.20 et 0.31 s .

 _  _ (p = 8 , 9)
 _  _ (p = 20 , 21)

Sont joints ci-dessous le fichier-source du programme, et l'unit spcifique (sous sa forme la plus allge - mais encore assez lourde) qui gre la cration de l'en-tte et du corps de l'image Bitmap.


```

```



```

```

@ *Jipt* : tu pourras retrouver dans le premier fichier deux expressions plus simples des coefficients de couleur. Je n"ai pas oubli le rayonnement visible (si, si, a va venir ...)

@ *souviron34* Tu as l tous les lments essentiels du programme; j'ai laiss de ct les instructions de routine, contenues dans d'autres units. Si tu te sens le courage d'baucher un algorithme ayant recours aux pointeurs ...



> ... J'essaierais de remonter la discussion pour remonter le code (_ moins que sympathiquement vous ne fournissiez la version actuelle_ ) et faire la traduction avec les pointeurs ... Ca devrait sans doute, d'aprs ce que je comprend, acclrer pas mal ...


Les temps de calcul n'ont  ce stade rien de prohibitif, mais peuvent augmenter considrablement dans le cas par exemple de la reprsentation d'une fonction U(x, y).
Merci par avance pour toutes les remarques que tu pourrais livrer sur le sujet.

----------


## anapurna

bonsoir 

bon je reviens sur du code qui me parais pas coherent 

donc en verifiant le passage de variablr la valeur de t varie entre -1 et 1 
quand je lit le code j'ai un soucis 


```

```

autre petit truc l cest plus estetique voir pour la comprehension 



```

```

a remplacer par 


```
 w := max(min(w,1),0);// on borne w entre o et 1
```

dans le calcul de calcMat_002
je vois que tu refait 3 fois le calcul 



```
(H1+m) div 2
```

pourquoi ne pas affecter une variable avant la boucle 
genre : 



```

```

voila quelque amelioration a faire

----------


## wiwaxia

Bonsoir,  ::D: 

# 


> ... donc en verifiant le passage de variablr la valeur de t varie entre -1 et 1 
> quand je lit le code j'ai un soucis 
> 
> 
> ```
> 
> ```


Non, parce que les appels


```

```

produisent une sortie de l'intervalle [-1 ; +1] (on a h = 2/3) - c'est justement l qu'intervient la priodicit de la fonction.

# 


> ... autre petit truc l cest plus estetique voir pour la comprehension 
> 
> 
> ```
> 
> ```
> 
> a remplacer par 
> 
> ...


Sans doute (je suis maintenant trop fatigu pour vrifier) ... si l'on est familier de ce genre de choses; j'ai dj dit ce que je pensais des fonctions embotes: ce que tu souhaites remplacer a le mrite d'tre clair et facilement vrifiable, et ta formule doit de toutes faons effectuer les mmes oprations - un programme source est fait pour tre (re)lu, et l'instruction la plus concise n'est pas forcment souhaitable.

# 


> dans le calcul de calcMat_002
> je vois que tu refait 3 fois le calcul 
> 
> 
> ```
> (H1+m) div 2
> ```


Il n'y a plus d'expression de ce type dans le dernier programme envoy - les graphes ont t supprims.
Je n'ai rien retrouv de tel dans les versions prcdentes, et cela m'aurait un peu tonn - mais tout le monde peut se tromper.
Dans la procdure _CalcMat_Im01_ l'instruction


```
Ma[x, y+m]:=  ...
```

se rpte pour chacun des 3 graphes, par la force des choses; la variante que tu indiques ne vient pas de moi.

PS: ce que tu signales vient sans doute des changes laborieux qui ont eu lieu auparavant,  et qui concernaient des changements de variable. 
Je crois qu'il vaut mieux s'en tenir  la dernire version propose.

----------


## foetus

> l'instruction la plus concise n'est pas forcment souhaitable.


Bien si  ::roll::   ::roll::  ... mais il faut savoir de quoi on parle



```

```



dit: Et si on travaille avec des entiers non signs, on n'a pas besoin du "test infrieur  zro"  ::mrgreen:: 
Par contre dans ce cas, il faudra srement revoir ses algos pour faire des translations pour viter les intervalles ngatifs

----------


## Jipt

Salutations distingues,




> Envoy par anapurna
> 
> dans le calcul de calcMat_002
> je vois que tu refais 3 fois le calcul
> 
> 
> ```
> (H1+m) div 2
> ```
> ...


Pour rpondre  wiwaxia, a doit tre des bidouilles  moi, a.  :;): 
Et pour rpondre  anapurna : impossible d'utiliser une variable pour liminer l'addition car y *change avant l'addition* en fonction de s.
En gros a ressemble  a, dans une boucle For... 3 instructions par ligne, si tu mets 1 instruction par ligne tu verras que ton plan ne tient plus (les noms de variables changent mais le principe reste) : 

```

```

Sinon je te rassure, je suis un grand amateur de ce genre d'optimisation, je me suis mme invent, pour ce programme, une variable nomme LargeurMoinsUn, si si !, qui me permet de faire des boucles genre for i := 0 to LargeurMoinsUn do..., et oui !

Bonne journe,

----------


## wiwaxia

> Citation Envoy par wiwaxia
> l'instruction la plus concise n'est pas forcment souhaitable.
> 			
> 		
> 
> Bien si   ... mais il faut savoir de quoi on parle ...


La correction propose par *anapurna* est juste, astucieuse et acceptable; mais on aborde ici le procd d'embotement des fonctions  seuil, qui conduit rapidement  des consignes peu intelligibles et difficilement contrlables. Je me suis dj exprim l-dessus.
Par ailleurs une procdure personnelle est prfrable  l'imbrication forcene de fonctions prdfinies, parfois mal adaptes  ce que l'on veut faire.

# Tu propose ensuite ensuite une procdure corrective _CLAMP_0_1(VALUE)_ qui remplace deux instructions conditionnelles: o est l'avantage ? En quoi est-ce plus bref ? Le bornage n'intervient qu'*une seule fois* lors de l'appel de la fonction dans un bloc relativement court (10 lignes, dlimiteurs compris !)..
Dans le cas contraire, j'aurais tout regroup dans une procdure du genre _Bornage(a, b: Reel; VAR x: Reel)_.

# 


> Et si on travaille avec des entiers non signs, on n'a pas besoin du "test infrieur  zro"


Et o vois-tu un tel test impos  des entiers de type byte ou word ?  ::king::  
Il s'agit ici d'un fonction relle d'une variable relle initialement dfinie sur [-1 ; +1].
Dans un dbat, il n'est nullement interdit de se montrer intelligent ...  ::pastaper:: 

# 


> Par contre dans ce cas, il faudra srement revoir ses algos pour faire des translations pour viter les intervalles ngatifs


Ah oui, bonne ide:  ::bravo:: 
a) si l'on se limite au domaine (t >= 0), la parit de la premire fonction n'intervient plus, et l'on perd une simplification essentielle du calcul;
b) il faut la dfinir sur [0 ; 2], l'extension du domaine imposant de nouvelles instructions conditionnelles. Tu y a sans doute pens ?

Comme tu l'a dit ds le dbut: il faut savoir de quoi on parle.  ::mouarf::

----------


## anapurna

salut ,

je doit pas tre a jour au niveau des code ou alors on parle pas de la mme chose
pour @winamax ... les if then else imbriqu ne sont pas plus simple  lire que mon expression suivi de son commentaire ... 
mais comme je l'avais dis c'est plus une question desthtisme que de performance dans ce cas 
je pense comme toi que cela fait exactement la mme chose.

je n'ai pas lu ton code ctait celui de @jipt que je rectifiais.

@jipete le 

```
(H1+m) div 2
```

 ce trouvais au niveau des courbes et pas du dgrad dans la boucle 

```
for k := -lim to lim
```

mais peut tre l'a tu rectifi par toi mme 
j'ai rcrit le code dans "lazarus" pour pouvoir comprendre ce que vous vouliez faire 
c'est pour cela que par exemple le CalcMat_img001 je l'ai renomm CalcMat_degrade et l'autre en CalcMat_Courbe afin de bien distingu les deux lments.

peut tre faut il que je rcupre des sources  jour pour tre sre que l'on parle de la mme chose

----------


## Jipt

> peut-tre faut-il que je rcupre des sources  jour pour tre sr que l'on parle de la mme chose


Yak demander  ::D: 
Mais attention : 
- mes procdures de dessins n'ont pas t renommes avec tes noms (qui sont sympathiques, au demeurant :cool: ) ;
- j'ai conserv plein de commentaires, certains sont intressants  lire ;
- j'ai renomm coef_C en iCoef_C pour bien me souvenir que la fonction est inline, histoire de speeder un peu plus.



```

```


Et la manire de l'appeler, depuis l'ihm, avec un bouton, un memo et une image 768 x 512 :


```

```

----------


## wiwaxia

Salut,  ::D: 




> ... Pour rpondre  wiwaxia, a doit tre des bidouilles  moi, a.  ...


Nul n'est tenu  une sance d'expiation publique; nous ne sommes pas en Core du Nord, et chacun d'entre nous avait des dtails  rectifier.
Comme je viens de le rajouter au post prcdent, il vaut mieux s'en tenir  la dernire version propose *(1)* ... ou alors prsenter clairement le programme en cause.




> ... Sinon je te rassure, je suis un grand amateur de ce genre d'optimisation, je me suis mme invent, pour ce programme, une variable nomme LargeurMoinsUn, si si !, qui me permet de faire des boucles genre for i := 0 to LargeurMoinsUn do..., et oui !


Je ne suis pas inquiet, et j'ai moi-mme prosaquement introduit la variable locale


```
L1:= La- 1
```

Encore plus court.

Bonne journe.

*(1)*: d'autant plus qu'il devient difficile de suivre toutes les rponses successives ...

----------


## foetus

> # Tu propose ensuite ensuite une procdure corrective _CLAMP_0_1(VALUE)_ qui remplace deux instructions conditionnelles: o est l'avantage ? En quoi est-ce plus bref ?


Je ne t'en veux pas  ::mrgreen::  lorsqu'on voit la tronche de ton code jonch de CalcMat_Im, Creation_F, AffT_ImFi, Calc_Cf_2Si on parle bien de code plus concis. Parce qu'on va remplacer 2 tests (5-6 lignes) par une macro/ un appel d'une fonction inline (est-ce en Delphi il a ce genre de chose?)

Le but c'est la lisibilit du code. exemple: output_buffer = CLAMP_0_1( /*gros calcul*/);.

----------


## wiwaxia

@ *anapurna*: Bonjour,  ::D: 

Je reviens sur l"une de tes remarques de cette nuit:




> ... autre petit truc l c'est plus esthtique voir pour la comprhension 
> 
> 
> ```
> 
> ```
> 
>  remplacer par 
> 
> ...


qui m'a paru intressante, bien qu"elle m'ait inspir de la mfiance:




> Sans doute (je suis maintenant trop fatigu pour vrifier) ... si l'on est familier de ce genre de choses; j'ai dj dit ce que je pensais des fonctions embotes: ce que tu souhaites remplacer a le mrite d'tre clair et facilement vrifiable, et ta formule doit de toutes faons effectuer les mmes oprations - un programme source est fait pour tre (re)lu, et l'instruction la plus concise n'est pas forcment souhaitable.


Un membre du club (*picodev*) avait fait, il y a quelques mois et au cours d'un autre dbat, une intervention tout  fait pertinente au sujet de la recherche de la concision optimale, au niveau du code, et des contre-performances qu'elle pouvait entraner. Je n'ai malheureusement pas pu retrouver  ce texte.

Cependant, j'ai programm par curiosit l'excution chronomtre des deux procdures mises en comparaison:


```

```

Je te laisse le soin de traduire.
J'ai obtenu pour le mme nombre d'itrations (21E8) un dlai d'excution T1 = 25.7 s dans le premier cas,
et un dlai T2 = 90.5 s - *soit ~ 3.5 fois plus grand* - dans le cas des 2 fonctions imbriques (Min(x, y) et Max(x, y)).
Comme quoi la concision n'implique pas la rapidit ... l'embotement des fonctions prdfinies bride le logiciel !
Un peu comme si l'on se servait d'une Jaguar comme une brouette.

  PS: Il va sans dire (mais beaucoup mieux en le disant) que la fonction dfinie sur [0 ; 3] et calcule dans tous les cas, est donne par les relations:
y = 1 (pour x <= 1) ; y = x (pour 1 < x < 2) ; y = 2 (pour 2 < x) .
Dans la boucle (x) varie de (1/Imax ~ 0)  (3).

----------


## anapurna

salut 

a bien y rflchir tout ceci me parait normal 
le fait de faire systmatique un min et un max alors que toi tu fait au max 2 test au min 1 
ce qui pourrait expliquer cela 
bon j'en conviens je me suis un peut emball sur l'esthtisme au dtriment de l'efficacit 

je vais crer ma propre fonction  :;): 


```

```

PS : c'est un joke les test vont bien aussi

----------


## wiwaxia

Bonjour,  ::D: 

@ *anapurna*: J'ai poursuivi l'examen de cette question.

Avec l'expression Min(Max(r, 1), 2) , symtrique de la prcdente, les temps obtenus sont du mme ordre: 91.5 s , toujours trs suprieurs  celui de l'algorithme le plus direct (25.7 s).
Autre variante: les instructions conditionnelles tant rassembles dans une fonction Bornage(a, b, x), 


```

```

les dlais sont alors de 52.7 s , que cette fonction figure dans le mme programme ou soit reporte dans l'unit. La "proximit" du codage et le nombre d'appels de ces fonctions joue apparemment un rle dterminant.

Je ne connaissais pas ces combinaisons algorithmiques. Ce sont des curiosits logiques intressantes, mais qui n'amliorent apparemment pas l'excution des programmes.

Il est vrai que la boucle choisie tait particulirement longue: N = 2.1E9 (il est difficile de faire mieux: MaxLongInt = 231 - 1 ~ 2.147E9); mais dans le cas d'une image, le nombre d'indices de couleur peut atteindre des valeurs assez leves (3*Npixel = 3*20002 = 12E6 pour une image 2000x2000).

D'autres membres du forum pourraient apporter des informations intressantes sur ce sujet. Il conviendrait peut-tre de le porter en discussion.

----------


## Jipt

Et bonjour !

On va dvier un peu des dgrads mais c'est pas grave ; je reviens sur ce point :



> que cette fonction figure dans le mme programme ou soit reporte dans l'unit. La "proximit" du codage et le nombre d'appels de ces fonctions joue apparemment un rle dterminant.


Je me suis rendu compte que des petites fonctions appeles un nombre dmentiel de fois (genre trafiquer la couleur de tous les pixels d'une grosse image) avaient tout intrt  tre dclares "inline" (en Delphi/Lazarus tu termines la ligne de la dclaration par inline; sans oublier de l'activer dans le projet avec {$inline on} ; tu adapteras  ton outil) car tout appel de fonction ncessite de sauvegarder le contexte d'excution du programme avant l'appel pour le restaurer aprs, toutes choses non ncessaires avec l'inlinisation : a fait gagner un temps fou.

Autre chose de rigolo : dans une boucle (surtout celles qui bricolent avec l'ihm, genre mise  jour de compteurs, de barre de progression, etc.), il est ncessaire de laisser "respirer" le programme et la machine, sinon on a l'impression que l'ihm est fige (et le fameux message de Windows depuis Vista ou 7, "Ce programme ne rpond pas..."). Solution en Pascal avec Application.ProcessMessages; dans le corps de la boucle, tout le monde connait a, en VB c'est DoEvents et pour les autres langages vous regardez votre doc.
Sauf que c'est coteux.
Alors il est conseill de n'appeler cette "pompe  messages" que de temps en temps, genre 


```

```

et c'est l qu'on rigole : je me suis rendu compte que cet ensemble _division puis extraction du reste et test_ tait trs coteux, en tout cas la boucle met plus de temps  s'excuter quand le test est prsent que quand il est absent !
Je vous laisse mditer l-dessus et faire vos propres tests.


```

```

Bonne journe,

----------


## anapurna

salut 

je suis un peut surpris je pensais betement que pascal optimis et que l'apelle de fonction ne prenais pas tans de temps que a 
effectivement c'est a voir 

peut etre qu'en utilisant le mot reserv inline ceci arrangera le temps de traitement

----------


## wiwaxia

Pour la commande _inline_, je vais consulter la documentation.
Il faut *vraiment* que je reprenne le Free Pascal ! Tous les changes de ce forum m'ont d'ailleurs donn envie de m'y remettre.




> Autre chose de rigolo : dans une boucle ... , il est ncessaire de laisser "respirer" le programme et la machine,


J'ai dj eu l'occasion de faire ce constat: on ne se rend compte du cot rel d'une instruction que sur une trs longue boucle.
Et lorsque l'excution se prolonge sur plusieurs minutes (parfois 10 ou 20), je m'assure de la bonne marche par l'affichage du compteur (i) - cela permet de prendre patience - par une instruction slective du type: 


```
   if (i mod 1000 = 0) then Affichage(i);
```

Je te propose justement une petite variante, au sujet du bloc d'instructions que tu donnes en exemple:


```

```

en programmant:


```

```

Je serais curieux de savoir ce que devient le temps d'excution ...

----------


## tbc92

Pour viter la division par 20, on peut remplacer :


```

```

par :



```

```

----------


## wiwaxia

Trs bonne astuce. J'en prends note.  ::ccool::

----------


## wiwaxia

J'ai repris le programme de chronomtrage dans le cas de 2 sortes de blocs d'instructions.

1) L'affichage slectif d'un compteur, en comparant 3 procdures (P1, P2, P3):


```

```

faisant respectivement intervenir:
a) l'expression directe de la condition:  _IF ((i MOD Jm)=0) THEN_ 
b) une variable intermdiaire: _j:= (i MOD Jm); IF (j=0) THEN ..._ 
c) la variante propose par *tbc92*: 
d)  une version un peu plus brve, rsultant de la suppression d'un couple de dlimiteurs (begin ... end) devenus inutiles.

Rsultats obtenus pour Imax = 200E6 itrations: Ta = 24.9 s ; Tb = 24.5 s ; Tc = 15.35 s ; Td = 15.30 s .
Remarquer:
# la lgre diminution du temps d'excution (1  2 %) rsultant de l"insertion d'un intermdiaire de calcul;
# la rduction significative (38 %) accompagnant le remplacement de la division par une addition; la recommandation de *tbc92* est  retenir.  ::merci:: 

2) L'expression particulirement charge d'un entier *X := round(C*(1-Abs((round(H) div 60) mod 2)-1))*, figurant dans un programme de *Jipt* post le 24/10/2016(17h58), et dont le dchiffrement n'avait rien d'vident (je n'ai d'ailleurs pas tout compris, mais ici cela n'a pas d'importance).
Trois procdures (P4, P5 et P6) ont ici t compares:
a) la formule initiale, utilisant le rel (h);
b) un algorithme dtaill, utilisant 5 termes intermdiaires (H1, H2, H3, H4, r);
c) un troisime plus condens, n'en faisant intervenir que deux (H2, H4).


```

```

Rsultats pour 109 itrations: Ta =  31.1 s ; Tb = 38.3 s ; Tc = 33.2 s . 

Le temps de calcul augmente avec le nombre de variables intermdiaires, mais d'une manire modre (15 et 7 %). 
Une dcomposition de la formule en un petit nombre d'tapes reste avantageuse par la clart qu'elle apporte, et a fortiori sur des dures plus brves ne dpassant pas la seconde.

----------


## souviron34

> # la rduction significative (38 %) accompagnant le remplacement de la division par une addition; la recommandation de *tbc92* est  retenir.


Je ne dirais pas "_je l'avais bien dit_"   ::P: 


(_c'est gnralement fait par un dveloppement en suite de Taylor dans un processeur...._)

----------


## Jipt

> # la rduction significative (38 %) accompagnant le remplacement de la division par une addition; la recommandation de *tbc92* est  retenir.


Alors a doit dpendre de tout ce qu'il y a autour (calculs, tests, etc.) parce qu'avec une simple boucle et rien d'autre, a se vaut :



```

```


Et par rapport  ce que je disais ce matin, bien sr je ne retrouve pas le cas de figure et c'est bien dommage, car ce soir avec ma simple boucle a ne fonctionne plus : si je commente le test if (i mod 20 = 0) then la boucle devient 10 fois plus longue.

----------


## souviron34

> ...


Je pense surtout que tu devrais utiliser un vrai outil de profiling  ::D: 

Chronomtrer le temps est trs alatoire, il y a au moins 3 temps : le temps rel, le temps utilisateur, le temps process...

Suivant la charge, le scheduling, etc, tout peut varier...

Sous Windows, toutes les icnes sur le bureau sont des _running process_ par exemple (_si tu regardes les "tches" tu verras qu'ils tournent.._.)... Sous unixoides, tu as la capacit de seulement slectionner le temps process.. 

Les outils de profiling sont normalement faits pour a, et pour donner les % _relatifs_ d'utilisation...

Quant aux mesures absolues, j'avais mis  disposition dans la section C de code-source un chronomtre en absolu... je vais re-chercher la rfrence et j'diterais ce post...   ::D: 

[EDIT]

OK c'est ici

[/EDIT]

----------


## tbc92

L'instruction la plus longue de ton process , c'est l'instruction   Application.ProcessMessages;
Ca, c'est acquis. C'est un peu paradoxal, on met cette instruction pour  rassurer l'utilisateur quand le programme est long , et pour  rassurer l'utilisateur, on rallonge dlibrment le temps de traitement de faon importante.

Cette instruction, soit on l'excute BorneLongue fois, soit on l'excute moins souvent : 20 fois moins souvent dans le scnario tudi.

Le test que tu as fait de de comparer 2 scnarios, l'un o on excute cette instruction coteuse  BorneLongue/20 fois, et l'autre o on l'excute BorneLongue fois ( quand tu mets la ligne if imod10  0   en commentaire, c'est ce qui se produit).
Bien videmment, si on excute cette instruction couteuse 20 fois plus souvent, le traitement est plus lent. 

La comparaison utile c'est : on veut ractualiser l'affichage de temps en temps, mais pas trop souvent. Le seuil choisi est de rafrachir l' affichage BorneLongue/20 fois.
Pour cela on a 2 options, c'est tester si  mod(i,20) = 0, ou bien de tester si i = i_pause, en incrmentant i_pause comme il faut.
Et le rsultat de Wiwaxia est : l'option 2 est 38% plus rapide que l'option 1.

Ce rsultat est trs encourageant mais n'est pas rellement significatif. Quand on a une boucle qui ne fait pas grand chose, voire rien, ajouter une division est effectivement un surcot important. Mais quand dans le corps de la boucle, il y a des traitements un peu plus ralistes (calcul de la couleur d'un point dans un dgrad par exemple), alors l'ajout ou la suppression d'une division (via le test mod(i,20)=0 ) est quasiment marginal.

----------


## Jipt

> Je pense surtout que tu devrais utiliser un vrai outil de profiling 
> [EDIT]
> 
> OK c'est ici
> 
> [/EDIT]


Vu, merci, mais j'ai le mme sous Linux en Pascal, y a des gens qui ont port a, j'ai reconnu le nom des structures utilises.
Je n'ai pas voulu l'utiliser ici en me disant que si quelqu'un voulait tester rapidement et sous Windows, il n'avait qu' faire un copier-coller sans se prendre la tte et tre oblig de jongler avec des DEFINE, le but de la manip tant de comparer des choses diffrentes sur la mme machine et pas des choses identiques sur des machines diffrentes.




> Quand on a une boucle qui ne fait pas grand chose, voire rien, ajouter une division est effectivement un surcot important. Mais quand dans le corps de la boucle, il y a des traitements un peu plus ralistes (calcul de la couleur d'un point dans un dgrad par exemple), alors l'ajout ou la suppression d'une division (via le test mod(i,20)=0 ) est quasiment marginal.


Vu, not, mais je m'embrouille car je gre d'autres choses en parallle qui me mettent les neurones dans un tat proche de la serpillire un lendemain de fte bien arrose, si tu vois...

Bon, faut que j'y retourne, en plus...

----------


## wiwaxia

> ... Chronomtrer le temps est trs alatoire, il y a au moins 3 temps : le temps rel, le temps utilisateur, le temps process...
> Suivant la charge, le scheduling, etc, tout peut varier ...


Le caractre approximatif du procd apparat immdiatement, dans la mesure o un algorithme donn conduit  des rsultats successifs diffrents (quelques unes des valeurs obtenues ont t donnes); les carts observs restent relativement faibles, de l'ordre de 0.5  5 % , et atteindre un seuil de prcision de l'ordre de la milliseconde (voire plus faible encore) n'est pas le but recherch.
Toute comparaison suppose quasi-constante l'activit rsiduelle de la machine; la reproductibilit du procd est confirme par l'obtention - pour le mme algorithme - de rsultats comparables  une demi-heure ou une heure d'intervalle. 
L'estimation est videmment fausse ds lors que survient un processus lourd, comme la mise  jour de l'antivirus; quiconque manie un ordinateur a l'exprience de ces courts moments (parfois exasprants) o l'appareil s'occupe de tout autre chose que de ce que vous lui avez demand - et justement quand le temps presse !
Le recours  l'horloge interne permet de comparer rapidement l'efficacit de divers algorithmes: voir plus haut l'allongement norme du temps de calcul li  l'emploi de la fonction compose Max(Min(x, a), b) .




> ... Ce rsultat est trs encourageant mais n'est pas rellement significatif. Quand on a une boucle qui ne fait pas grand chose, voire rien, ajouter une division est effectivement un surcot important. Mais quand dans le corps de la boucle, il y a des traitements un peu plus ralistes ... alors l'ajout ou la suppression d'une division (via le test mod(i,20)=0 ) est quasiment marginal ...


C'est ce que je me suis dit aprs coup, en songeant aux calculs monstrueux concernant la dformation des polydres, ou la structure de rseaux ponctuels, et pour la ralisation desquels le PC doit mouliner pendant plus d'une heure ... l'algorithme que tu as donn reste nanmoins intressant par sa grande simplicit - pour une fois que l'on peut viter un grand nombre de divisions, pourquoi s'en priver ?

----------


## wiwaxia

@ *Jipt*

 la demande que tu as exprime au dbut du mois
*# 05/11/2016, 12h03*



> Et si on voit le bout du tunnel de tout a, je te propose ensuite de rflchir  la reprsentation des couleurs de la lumire visible (si c'est un peu ta partie) parce qu'en tapant juste "lumire visible" et en regardant les images remontes par google, on peut admirer tout et n'importe quoi...


j'ai d"abord oppos un refus, en raison de l'tendue du sujet; mais comme tu as reformul ta question
*# 06/11/2016, 18h55*



> En fait, je n'ai qu'une question toute bte, mais qui m'empche de dormir : tape donc, comme je te l'ai suggr, "lumire visible" et contente-toi de regarder les images, tu y verras des disparits de l'une  l'autre qui font que si je voulais faire la mme chose, je ne sais pas du tout laquelle choisir comme modle, d'une part, mais d'autre part il y a une constante qui me surprend : c'est pourquoi le rouge est plus large que les autres couleurs, dans leurs images  la noix ?
> Je dis " la noix" parce que certains reprsentent l'infrarouge en allant vers le noir quand d'autres vont vers le blanc, et pareil du ct de l'ultra-violet (quand il y est : certains l'omettent)


*# 14/11 , 09h31* 



> Et ce qui me pose le plus gros problme, c'est la manire de rendre les couleurs (je m'exprime mal, mais tu vas voir) car, par exemple sur cette page bien documente, il y a un tableau en bas et tout en bas en cliquant sur "Spectre lectromagntique en dtail [afficher]" on en voit un autre, et les couleurs ne sont pas les mmes entre ces deux tableaux ! Pour moi la question est simple : o est la Vrit ?
> Pour le moment j'en suis l; mais c'est une interprtation toute personnelle :
> https://fr.wikipedia.org/wiki/Spectre_visible


et que j'ai de mon ct fait quelques recherches, parce que c'tait en soi intressant, je vais essayer d'apporter quelques rponses, et tenter une mise au point sur une documentation foisonnante, et trs diverse.

1) Une *palette* est un ensemble de teintes obtenues par dgrad entre deux couleurs extrmes arbitrairement choisies; au cours de cet change on en a rencontr plusieurs exemples, dont principalement "l'arc -en-ciel" construit sur les 3 couleurs fondamentales, et ainsi nomm par une commodit de langage trs approximative; son aspect diffre passablement de celui du phnomne du mme nom.

2) Le *spectre d'mission* d'une source lumineuse reprsente la rpartition de la puissance rayonne en fonction d'un paramtre - la longueur d'onde du rayonnement, le plus souvent; on l'obtient  l'aide d'un systme optique dispersif, qui impose aux rayons lumineux une dviation dpendant de la longueur d'onde. Il rsulte de la superposition d'une infinit d'images monochromatiques (traits fins sur fond noir, parallles entre eux), dont la coloration couvre toute l'chelle du visible (du violet au rouge sombre) dans le cas de la lumire blanche. On observe du noir au-del de ces deux extrmes, les photorcepteurs de la rtine n'tant plus sollicits par le rayonnement.



L'talement relativement important du rouge est une donne neurophysiologique; elle s'explique par la sensibilit des rcepteurs prsents dans le fond de l'oeuil,  des longueurs d'onde relativement grandes (au-del de 750 nm), et dont la courbe se situe *au-dessus de celles du vert et du bleu*.



a) Les *rseaux* donnent par diffraction de la lumire des spectres quasi-linaires, dans lesquels la position des raies dpend linairement de la longueur d'onde (voir l'image ci-dessus); ils permettent d'obtenir les mesures les plus prcises de la longueur d'onde du rayonnement tudi.
b) Les *prismes* dispersent aussi la lumire blanche, mais le spectre obtenu dans ce cas prsente un talement beaucoup plus grand du ct des petites longueurs d'onde (bleu  et violet) en raison d'une variation beaucoup plus rapide de l'indice de rfraction (n): comparer la position du jaune  celle dans l'image prcdente.

 _ 

# autre version: la fente source claire en lumire blanche est plus troite, et le spectre obtenu est de meilleure qualit, quoique beaucoup moins lumineux (l'un ne va malheureusement pas sans l'autre): l'talement du violet y est encore plus marqu.

3) Le *corps noir* est un systme idal dont la surface absorbe totalement tout rayonnement incident, quelle que soit sa longueur d'onde; il est physiquement assez bien reprsent par l'entre d'une cavit dont les parois intrieures seraient recouvertes de suie: toute lumire entrante n'aurait aucune chance de ressortir, par diffusion ou rflexion du rayonnement. La puissance qu'il rayonne augmente rapidement avec sa temprature: rouge vers 1100 K (braises), jaune brillant vers 1300 K (cuivre fondu), blanc au-del (filament de tungstne - 3300 K, surface du Soleil -5800K), bleut  des tempratures encore plus leves (naines blanches): la gamme des teintes observes dpend alors de la temprature de la source (voir *1* et *2*)



L'image que tu signales est totalement fausse, et ton incomprhension est justifie: 
Je ne suis pas parvenu  la retrouver, mais les liens renvoient  de bons documents:
# Spectre visible, Longueurs d'onde approximatives des couleurs spectrales
https://fr.wikipedia.org/wiki/Spectre_visible
# Spectre lectromagntique
https://fr.wikipedia.org/wiki/Spectr...agn%C3%A9tique

4) La relation entre les *coefficients de couleur* et la longueur d'onde des radiations monochromatiques n'est pas du tout vidente, et la recherche conduit souvent  des documents trs techniques et inexploitables pour les non-spcialistes. Cela concerne en effet l'optique, la vision des couleurs et leur restitution sur cran. On trouve cependant des liens intressants, concernant les *fonctions colorimtriques*:
*# Fichier ciexyz31.txt* 



Tu as toi-mme donn *l'une des meilleures rfrences* sur le sujet.

# Pour terminer, quelques liens vers des sites bien faits, mais d'intrt moins immdiat:
http://nte-serveur.univ-lyon1.fr/tri...eCouleurs.html

https://fr.wikipedia.org/wiki/CIE_xyY 
https://fr.wikipedia.org/wiki/CIE_XYZ

http://www.lec-expert.fr/dossier/dia...romaticite-cie
http://www.tsi.enst.fr/pages/enseign...omaticity.html

----------


## Jipt

Oh bonjour !

Alors tout d'abord je te remercie chaleureusement de ne pas avoir oubli ma petite demande, qui a dbouch sur ta longue et fort bien documente rponse qui, _in fine_, me laisse un peu dans le brouillard mais, bah, c'est la vie !



> 1) Une *palette* est un ensemble de teintes obtenues par dgrad entre deux couleurs extrmes arbitrairement choisies; au cours de cet change on en a rencontr plusieurs exemples, dont principalement "l'arc -en-ciel" construit sur les 3 couleurs fondamentales, et ainsi nomm par une commodit de langage trs approximative ; son aspect diffre passablement de celui du phnomne du mme nom.


Tout  fait, mais au moins on sait de quoi on parle  ::P:   ::mrgreen:: 




> L'image que tu signales est totalement fausse, et ton incomprhension est justifie : 
> 
> Je ne suis pas parvenu  la retrouver [...]


c'est normal, je l'ai cre ex nihilo  partir d'un gnrateur de dgrads _artisanal_ mais qui fonctionne pas trop mal, dans la mesure o il m'a rendu graphiquement ce que je voyais dans ma tte aprs toutes ces lectures (qui se contredisent parfois, comme je le montrais  propos des "remontes" d'images par les moteurs de recherches).
J'utilise le mot "artisanal" car l'ide derrire tout a serait de s'inspirer d'un graphique pour gnrer le dgrad qui va bien avec les couleurs en proportion des courbes qu'on voit, ce qui n'est pas le cas  l'heure actuelle. En termes de "source d'information de base", j'hsite entre celui-ci et celui-l :



En attendant et pour rtablir une vrit, je modifie mon dgrad pour que le violet finisse vers le noir plutt que vers le blanc : 

et tu noteras au passage ces effets disgracieux comme cette bande "blanche" dans le violet, qui n'existe pas en ralit puisqu'un colorpicker dessus me dit 192-128-255 (R-G-B).

Maintenant, entre la ralit des calculs et l'interprtation du cerveau, je sais qu'il y a un gap monstrueux et pour ceux qui ne connaissent pas l'illusion de l'chiquier, je remets le lien ici mais armez-vous d'un colorpicker avant d'aller voir, sinon vous ne le croirez pas ! 

Enfin, 


> "Tu as toi-mme donn l'une des meilleures rfrences sur le sujet."


merci, je trouve pourtant son graphique un peu  ct de la plaque, quand on compare avec les tiens, mis  part le "sursaut" du rouge dans le bleu vers 400 nm (chez lui, 420-430 chez toi) :


Bon, avec tout a j'ai du pain sur la planche...
Bonne journe,

----------


## wiwaxia

> ... ma petite demande, qui a dbouch sur ta longue ... rponse qui, in fine, me laisse un peu dans le brouillard ...


Il suffit de relire tranquillement chaque passage ... Tout gober d'un seul coup doit tre fort indigeste, j'en conviens  ::aie::  , et estimes-toi heureux que toute relation mathmatique ait t bannie!  ::lol:: 




> ... J'utilise le mot "artisanal" car l'ide derrire tout a serait de s'inspirer d'un graphique pour gnrer le dgrad qui va bien avec les couleurs en proportion des courbes qu'on voit, ce qui n'est pas le cas  l'heure actuelle. En termes de "source d'information de base", j'hsite entre celui-ci et celui-l ...


Utilise les graphes des fonctions colorimtriques (pour une dfinition approche mais relativement fidle), ou mieux encore la liste trs serre des valeurs donnes dans le fichier '.txt' (pour la recherche des zros, et la dtermination des rapports en divers endroits du domaine du visible).




> ... et tu noteras au passage ces effets disgracieux comme cette bande "blanche" dans le violet, qui n'existe pas en ralit puisqu'un colorpicker dessus me dit 192-128-255 (R-G-B) ...


Tu as fait du bon travail, parce que la paramtrisation du spectre est plus difficile que celle du coloriage arbitraire de la palette (niveau CM1) auquel on s'est livr jusque l.
Tu n'as pas vu que la composante verte a compltement disparu du violet: tu devrais avoir plutt: (192 , 0 , 255); elle s'annule, au vu des courbes, aux environs de 410 nm.




> ... je trouve pourtant son graphique un peu  ct de la plaque, quand on compare avec les tiens, mis  part le "sursaut" du rouge dans le bleu vers 400 nm (chez lui, 420-430 chez toi) ...


C'est un trs bon point de dpart, mme s'il faut modifier certaines limites qui ne correspondent pas au document prcdent; on voit clairement ce  quoi il faut arriver. Reprer aussi le lien cit en rfrence, et qui peut livrer d'autres informations.
Cette reprsentation du spectre visible m'intresse, et je regarderai ce  quoi peut conduire une exploitation numrique. 
Je te communiquerai les rsultats si tu veux, mais sans dmonstration !  ::D:  C'est de la tambouille calculatoire.




> Maintenant, entre la ralit des calculs et l'interprtation du cerveau, je sais qu'il y a un gap monstrueux et pour ceux qui ne connaissent pas l'illusion de l'chiquier, je remets le lien ici mais armez-vous d'un colorpicker avant d'aller voir, sinon vous ne le croirez pas !


J'ai retrouv une illusion analogue en programmant des palettes bidimensionnelles, o se composent les couleurs de base; chaque lment du damier prsente une teinte constante:

 _  _ 

Toute la difficult vient de ce qu'il faut tablir un pont entre la perception de l'oeil et la coloration de l'cran.

----------


## Jipt

> ... et tu noteras au passage ces effets disgracieux comme cette bande "blanche" dans le violet, qui n'existe pas en ralit puisqu'un colorpicker dessus me dit 192-128-255 (R-G-B) ...
> 			
> 		
> 
> Tu as fait du bon travail, parce que la paramtrisation du spectre est plus difficile que celle du coloriage arbitraire de la palette (niveau CM1) auquel on s'est livr jusque l.


Ben toi aussi !
Et d'ailleurs, sans toi, je ne serais pas arriv jusque l, donc, encore merci  ::ccool:: 




> Tu n'as pas vu que la composante verte a compltement disparu du violet: tu devrais avoir plutt: (192 , 0 , 255); elle s'annule, au vu des courbes, aux environs de 410 nm.


Nan because je m'tais concentr sur le fait de finir le violet sur du noir (mme si esthtiquement c'tait plus joli avec du blanc) ; voil, j'ai enlev le vert, mais tout a est fait viteuf', sans aucune prise en compte des courbes -- verrai a plus tard...

----------


## wiwaxia

Le lien donn en annexe (*Dan Bruton's Color Science*) conduit  une mine de donnes et de fonctions numriques !

http://www.midnightkite.com/color.html
http://www.physics.sfasu.edu/astro/color/spectra.html
http://www.physics.sfasu.edu/astro/color/blackbody.html
http://www.physics.sfasu.edu/astro/c...e_xyz1964.html

----------


## Jipt

> J'ai retrouv une illusion analogue en programmant des palettes bidimensionnelles, o se composent les couleurs de base; chaque lment du damier prsente une teinte constante :
> 
>  _  _


Il y a quelque chose que je ne comprends pas dans ce que tu dis ci-dessus, car pour moi, _chaque lment du damier_ *ne* _prsente_ *pas* _une teinte constante_, il y a des bandes plus fonces ou plus claires, visibles  l'il nu et au colorpicker.
Et en zoomant, aussi :


morceau pris vers le bas-droit du carr central, o l'on distingue des bandes horizontales et verticales prs du centre.

Sinon, je voulais revenir deux minutes l-dessus, car une chose m'chappe (ou alors ce n'est pas une reprsentation de la lumire visible, c'est autre chose ?) :


Car en y regardant de prs et en partant du bord droit, les courbes rouge et vert tellement proches au dpart, vers 720nm, me donnent l'impression qu'il ne devrait pas y avoir de rouge pur dans l'image rsultante : vrai, faux, ou je n'ai rien compris ?

----------


## wiwaxia

Bonjour,  ::D: 




> ... Il y a quelque chose que je ne comprends pas dans ce que tu dis ci-dessus, car pour moi, chaque lment du damier ne prsente pas une teinte constante, il y a des bandes plus fonces ou plus claires, visibles  l'il nu et au colorpicker ...


Anomalies incontestables, lies au changement de format (cela a t voqu en dbut de discussion, je crois) - on ne voir rien de tel sur les images bitmap d'origine. Le transfert des fichiers bmp tant interdit, il faudra ou me croire sur parole (ce qui est un peu frustrant), ou les synthtiser (1), ou les recevoir par messagerie (l, je ne sais pas comment procder).

(1) loi de composition des couleurs trs simple pour la case (i, j): Coeff1= 51*i, Coeff2 = 51*j avec (0 <= i (et j) <= 5).




> ... Car en y regardant de prs et en partant du bord droit, les courbes rouge et vert tellement proches au dpart, vers 720nm, me donnent l'impression qu'il ne devrait pas y avoir de rouge pur dans l'image rsultante : vrai, faux, ou je n'ai rien compris ?


Je croyais moi-mme que la composante verte s"annulait avant la rouge du ct des grandes longueurs d'onde.
Or on peut constater qu'il n'en est rien, en consultant le fichier (ciexyz31.txt) tlchargeable (voir le lien correspondant);  partir de 700 nm, le rapport u = Cr/Cv devient constamment gal  2.769

----------


## Jipt

Hello !



> Bonjour, 
> Anomalies incontestables, lies au changement de format (cela a t voqu en dbut de discussion, je crois) - on ne voir rien de tel sur les images bitmap d'origine. Le transfert des fichiers bmp tant interdit, il faudra ou me croire sur parole (ce qui est un peu frustrant), ou les synthtiser (1), ou les recevoir par messagerie (l, je ne sais pas comment procder).


ou les zipper et poster le fichier rsultant (.zip, .rar, .7z accepts, peut-tre d'autres)
Ce que je fais aussi, des fois, avec une image fortement zoome  l'affichage, pour montrer un dtail par exemple, c'est une copie d'cran que je publie aprs l'avoir exporte en png.

_Anomalies incontestables, lies au changement de format_ : a doit encore tre cette satane compression jpeg, mais l c'est vraiment bizarre, d'habitude elle se fait plus discrte...

----------


## wiwaxia

Bonjour,  ::D: 




> ... Il y a quelque chose que je ne comprends pas dans ce que tu dis ci-dessus, car pour moi, chaque lment du damier ne prsente pas une teinte constante, il y a des bandes plus fonces ou plus claires, visibles  l'il nu et au colorpicker ...


Anomalies incontestables, lies au changement de format (cela a t voqu en dbut de discussion, je crois) - on ne voir rien de tel sur les images bitmap d'origine. Le transfert des fichiers bmp tant interdit, il faudra ou me croire sur parole (ce qui est un peu frustrant), ou les synthtiser *(1)*, ou les recevoir par messagerie (l, je ne sais pas comment procder).

*(1)* loi de composition des couleurs trs simple pour la case (i, j): Coeff1= 51*i , Coeff2 = 51*j avec (0 <= i (et j) <= 5).




> ... Car en y regardant de prs et en partant du bord droit, les courbes rouge et vert tellement proches au dpart, vers 720nm, me donnent l'impression qu'il ne devrait pas y avoir de rouge pur dans l'image rsultante : vrai, faux, ou je n'ai rien compris ?


Je croyais moi-mme que la composante verte s"annulait avant la rouge du ct des grandes longueurs d'onde.
Or on peut constater qu'il n'en est rien, en consultant le fichier tlchargeable (ciexyz31.txt) - voir le lien correspondant;  partir de 700 nm, le rapport u = Fr/Fv devient constant et gal  2.769176; il ne s'agit donc pas d'un rouge "pur" progressivement assombri, mais d'un rouge-orang.


```

```

Phnomne analogue  l'autre extrmit du spectre, o domine cette fois le bleu.


```

```

D'ailleurs - bonne question - qu'est-ce qu'une couleur "pure" ?  l'exception du bleu dont la fonction s'annule  partir de 650 nm, 


```

```

aucune composante ne disparat totalement dans les teintes successives du spectre visible; les 3 sortes de rcepteurs de la rtine ne ragissent jamais isolment.
Autrement dit, aucune couleur "purement" monochromatique ne correspond   une couleur fondamentale; on ne trouve dans le spectre de la lumire blanche aucune des 3 couleurs "pures" (m, 0, 0), (0, m, 0) ou (0, 0, m).



*PS: Il y a eu une fausse manoeuvre, je laisse cependant l'ancien message pour ne rien brouiiler.*

----------


## tbc92

Dans ce spectre de la chromacit, les graduations 420  680 reprsentent la longueur d'onde. Ok.
La courbe est plus ou moins en forme de parabole... mais pourquoi une parabole, pourquoi pas une droite? et pourquoi une espce de parabole avec un axe inclin? 
En fait , une seule question : que reprsentent x et y dans ce graphique ?  
Est-ce qu'aujourd'hui, 85 ans plus tard, on considre cette reprsentation toujours valable ?

----------


## wiwaxia

> La courbe est plus ou moins en forme de parabole... mais pourquoi une parabole, pourquoi pas une droite? et pourquoi une espce de parabole avec un axe inclin?
> En fait , une seule question : que reprsentent x et y dans ce graphique ?


x = X/(X + Y + Z) et y = Y/(X + Y + Z)

Les valeurs des fonctions colorimtriques (X, Y, Z) consignes dans le fichier dj mentionn (ciexyz31.txt) permettent de retrouver les deux extremums de la courbe frontire sur le domaine [500 nm ; 520 nm], en lesquels la tangente est verticale (x = Xmin) ou horizontale (y = Ymax):


```

```

Calculs rapides et peu prcis,mais les rsultats confirment ce que l'on voit sur le diagramme.




> Est-ce qu'aujourd'hui, 85 ans plus tard, on considre cette reprsentation toujours valable ?


Oui,  priori - puisque cette rfrence est confirme sur les sites les plus rcents (universits, coles d'ingnieurs) - mais je ne suis pas spcialiste de ce domaine.

----------


## tbc92

Vu.

x = X/ ( X+Y+Z) 
x = Y/ ( X+Y+Z) 

En d'autres mots :
x = Rouge / ( Rouge+Vert+Bleu)
y = Vert    / ( Rouge+Vert+Bleu)

Exemple, pour x = 600, Rouge vaut environ 1.1, Vert = 0.6, et Bleu = 0  donc x = 0.62 et y = 0.38.

et comme pour les longueurs d'onde leves (500 et plus), le bleu vaut 0, pour cette srie de valeur, la courbe devient en gros la droite d'quation X+Y =1.

Dans ce spectre, on a privilgi les rles de Rouge et Vert ; on pourrait faire des spectres similaires, mais en privilgiant Rouge est Bleu par exemple...

----------


## wiwaxia

> ... et comme pour les longueurs d'onde leves (500 et plus), le bleu vaut 0, pour cette srie de valeur, la courbe devient en gros la droite d'quation X+Y =1.


Bonne remarque. La relation devient rigoureuse  partie de 650 nm. Mais le raccourci que tu exprimes



> ... En d'autres mots :
> x = Rouge / ( Rouge+Vert+Bleu)
> y = Vert    / ( Rouge+Vert+Bleu) ...


te permet de sauter  pieds joints la difficult du passage d'un espace de couleur  l'autre (XYZ / RVB) - voir les liens ci-dessous.

Et pour rpondre d'une manire plus complte  ta question



> ... Est-ce qu'aujourd'hui, 85 ans plus tard, on considre cette reprsentation toujours valable ?


tu peux consulter
# Commission internationale de l'clairage
https://fr.wikipedia.org/wiki/Commis...%C3%A9clairage
Espaces RGB - Espace XYZ et drivs
# Colorimtrie : CIE XYZ 1931
https://fr.wikiversity.org/wiki/Colo...e/CIE_XYZ_1931
Fonctions colorimtriques
# Valeurs tabules de fonctions colorimtriques CIE 1931 et CIE 1964
https://fr.wikiversity.org/wiki/Colo...rmalis%C3%A9es

Au sujet de la perception des couleurs, une trs bonne documentation par les liens suivants:
# Btonnets
https://fr.wikipedia.org/wiki/B%C3%A2tonnet
# Rhodopsine, sensibilit de l'oeuil
https://fr.wikipedia.org/wiki/Rhodopsine

# Cne (photorcepteur)
https://fr.wikipedia.org/wiki/C%C3%B...%C3%A9cepteur)
Noter la variabilit observe d'un individu  l'autre, indpendamment des maladies et des infirmits susceptibles l'altrer la vision des couleurs:
_- Ces maximums de sensibilit sont par ailleurs diffrents de plusieurs nanomtres d'un individu  l'autre.
- Chez l'Homme, les cnes B sont les moins nombreux (4 %  5 %); puis viennent les cnes V et les cnes R, avec des variations interindividuelles importantes. 
- Des recherches actuelles tendent  prouver que chez un certain pourcentage d'hommes (10 %) et de femmes (50 %), il existerait un quatrime type de cnes sensibles aux oranges._
d'o la mention de "l'observateur de rfrence de la CIE", auquel se rapportent les dfinitions et valeurs numriques.

# Opsines
https://fr.wikipedia.org/wiki/Iodopsine
et sur l'aspect biochimique: 
http://acces.ens-lyon.fr/biotic/evol...tml/points.htm
_On trouve au niveau des disques des btonnets une molcule photosensible appele la rhodopsine, constitue d'une protine, l'opsine, et d'un groupement prosthtique, le 11-cis-rtinal li  la lysine 216 de la protine.

C'est l'isomrisation du 11-cis-rtinal en tout-trans-rtinal, induite par un photon, qui entrane l'activation de la rhodopsine. 

La vision des couleurs est lie   l'existence dans la rtine de trois types cellulaires (les cnes) qui sont des photorcepteurs synthtisant trois pigments diffrents qui prsentent des niveaux d'absorption diffrents suivant la longueur d'onde. Avec un seul des pigments, on ne voit pas les couleurs.

Les spectres d'absorption des trois opsines photorceptrices ont t mesures en clairant des cnes avec un faisceau de lumire de 1mm seulement. Les rponses des diffrentes cellules en cnes montrent l'existence de trois groupes : certaines sont excites au maximum par des longueurs d'ondes maximum de 437 nm, d'autres sont excites des longueurs d'ondes maximum de 533 nm, et les dernires par des longueurs d'ondes maximum de 564 nm. La rhodopsine prsente une bande d'absorption large dans la rgion visible du spectre avec un pic  498 nm. 

Les protines photorceptrices des cellules en cne sont, elles aussi, des rcepteurs  sept hlices, les structures spatiales sont conserves; elles contiennent elles aussi le 11-cis-rtinal._

----------

