Rendu des couleurs différent selon l'O.S. et la présence (ou pas) d'une ligne de log dans TMemo

Version imprimable

2 pièce(s) jointe(s)

Bonjour,

Yes, c'est encore moi avec mes misères, et celle-ci est gratinée !

Qu'on en juge : je voulais débugguer une fonction qui me retourne une couleur en fonction de 3 paramètres qui lui sont passés, car elle ne réagit pas correctement : si je lui passe (0, 512, compteur_de_boucle) elle fonctionne et j'ai un joli dégradé, si je lui passe (jpColorToInteger(clBlue), jpColorToInteger(clYellow), compteur_de_boucle) j'ai une couleur unie :koi:.
J'ai donc voulu voir ce qui se cachait derrière ces noms, et pour ce faire j'ai rajouté dans ma maquette une ligne de log, avant d'appeler la fonction suspecte :

Code:

memo1.Lines.Add(IntToStr(jpColorToInteger(clBlue))+' '+IntToStr(jpColorToInteger(clYellow)));

Cette fonction jpColorToInteger est tout simplement un clone de la fonction ColorToRGB récupérée dans Graphics et renommée par votre serviteur pour avoir un nom plus en rapport avec ce qu'elle fait, et j'en ai profité pour la déclarer inline;, le tout dans un module complémentaire.

Les informations de log ayant l'air normales (16711680 65535), j'ai alors rajouté sous la première ligne de log une autre ligne pour en avoir le cœur net :

Code:

memo1.Lines.Add(IntToStr(clBlue)+' '+IntToStr(clYellow));

Et c'est là qu'on rigole : si le mémo affiche maintenant deux lignes identiques avec les mêmes valeurs, la couleur unie retournée n'est plus la même !

Je n'en croyais pas mes yeux, j'ai fait 10 fois le test de commenter/décommenter cette seconde ligne de log et je confirme que ça réagit comme décrit.

Alors pour en avoir le cœur net, j'ai basculé le projet dans la machine XP / Laz 1.6rc1 / FPC 3.0 et le canard est toujours vivant, plus le fait que selon l'O.S. les couleurs ne sont pas les mêmes...

On a donc Linux (Laz 1.4 / FPC 2.6.2) à gauche et XP à droite, en haut lorsque les deux lignes de log se suivent et en bas lorsque la seconde est commentée :
Pièce jointe 221202

Et pour obtenir cette magnifique image, il me suffit donc de commenter ou pas la seconde ligne (ou la première, ça foire tout autant) :
Code:

1 2 3 4 5 6 memo1.Lines.Add(IntToStr(jpColorToInteger(clBlue))+' '+IntToStr(jpColorToInteger(clYellow))); memo1.Lines.Add(IntToStr(clBlue)+' '+IntToStr(clYellow)); // les valeurs logguées sont toujours les mêmes : 16711680 65535 for h := 0 to DisplayLenght-1 do begin aColor := GiveRainbowColor(jpColorToInteger(clBlue),jpColorToInteger(clYellow), h);
La grande question est donc : comment est-il possible que le rendu de couleurs soit différent alors que les valeurs passées à la fonction sont identiques ?

Et le plus dément, c'est lorsque je loggue ou pas mais que je passe toujours les mêmes constantes aColor := GiveRainbowColor(16711680, 65535, h); à la fonction : les résultats affichés continuent à être différents ! :cfou:
Sous Linux de gauche à droite, pas de log, une ligne de log, deux lignes de log :
Pièce jointe 221204

Je suis incapable de débugguer ça puisque d'habitude j'utilise des mémos pour voir où ça coince, mais là, :mur:
Ah, la fonction en question vient de là sans avoir rien changé.

26/09/2016, 15h26
tourlourou

Hello !

Je subodore un problème de longueur des types : le IntToStr donne la même valeur, mais passer 512 ou clMachin ou son transtypage n'est pê pas la même chose.

Ou longueur du TColor différente selon l'OS, ou alignement RGB ou BGR selon l'OS, etc.

Citation:

Envoyé par tourlourou

Je subodore un problème de longueur des types : le IntToStr donne la même valeur, mais passer 512 ou clMachin ou son transtypage n'est pê pas la même chose.

Ou longueur du TColor différente selon l'OS, ou alignement RGB ou BGR selon l'OS, etc.

Arggghhhhhhhhhhhhhhh ! Où est mon Valium^® ?

Parce que, mine de rien, pour résumer la situation, et sans vouloir aller contre ta réponse, je passe toujours les mêmes valeurs à cette fonction, la seule chose qui change c'est la présence ou pas d'un certain nombre de commentaires avant son appel !
Je te la refais, en mode "encore plus vicieux (ou fouineur, c'est selon ;))" :
Code:

1 2 3 const bleue = 16711680; jaune = 65535;
"Constante", ça dit bien ce que ça veut dire, non ? Profitons-en :
Code:

1 2 3 4 5 6 memo1.Lines.Add(IntToStr(jpColorToInteger(clBlue))+' '+IntToStr(jpColorToInteger(clYellow))); memo1.Lines.Add(IntToStr(clBlue)+' '+IntToStr(clYellow)); // les valeurs logguées sont toujours les mêmes : 16711680 65535 for h := 0 to DisplayLenght-1 do begin aColor := GiveRainbowColor(bleue, jaune, h);
et perdons notre temps :pleure:
Voilà le résultat, selon ce qui est commenté ou pas.
Les 3 nombres sont les valeurs RGB relevées avec un ColorPicker sur un TPanel recevant la couleur générée, qui me sert de témoin :
Code:

1 2 3 4 les deux mémos présents --> 136 0 131 l. supérieure commentée --> 136 0 99 l. inférieure commentée --> 136 0 195 les 2 lignes commentées --> 204 0 3
Alors ok, ce petit tableau ça n'est pas visuel, il aurait mieux valu des copies d'écran, assemblage avec The Gimp, toussa toussa, mais c'est bon, là, je fatigue, j'utilise deux constantes et on constate en regardant le tableau que les 4 lignes n'ont rien de constant (à part le rouge à 136 au début).

Je ne sais pas quoi faire, la fonction a l'air correcte, je n'ai pas la moindre idée de quoi chercher où...

Tout ce que je peux dire, avec ce dernier essai, c'est que je passe deux constantes de type integer, tel qu'attendu par la fonction (proto : function GiveRainbowColor(iMin, iMax, i: Integer): TColor;), et le mémo et ses proc's de traduction ne touchent pas à mes deux constantes et malgré ça, pâté...

Et mine de rien, si ce genre de chose merdouille, alors tout n'importe où peut merdouiller dans les codes...

26/09/2016, 17h11
tourlourou

aColor : où est-il déclaré ? Est-ce un paramètre de fonction ?
Si tu l'utilises dans ta fonction, enlever la directive [C]inline[/] à la fonction jpColorToInteger arrange-t-il les choses ?

J'ai fait plus simple, Yves ; tout est là :

Code:

1
2
3
4
5
6
7
8
procedure TForm1.Button1Click(Sender: TObject);
const
  bleue = 16711680;
  jaune = 65535;
begin
//  panel1.Caption := IntToStr((clGreen))+'  '+IntToStr(clWhite);  
panel1.Color := GiveRainbowColor(bleue, jaune, 0);  
end;

On est bien d'accord que les deux valeurs passées à la première ligne n'ont rien à voir avec les deux constantes utilisées sur la seconde ligne ?
Et pourtant, les résultats (toujours en RGB, toujours à partir de mon ColorPicker) prouvent le contraire, concernant la ligne Panel1.Caption := ... :

Code:

1
2
si commentée :  // 100 104 109
si décommentée :// 172 52 0

et la fonction en question :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
function GiveRainbowColor(iMin, iMax, i: Integer): TColor;
var  //https://en.wikibooks.org/wiki/Color_Theory/Color_gradient
  m: Double;
  r, g, b, mt: Byte;
begin
  m := (i - iMin)/(iMax - iMin + 1) * 6;
  mt := (round(frac(m)*$FF));
  case Trunc(m) of
  0: begin
      R := $FF;
      G := mt;
      B := 0;
    end;
  1: begin
      R := $FF - mt;
      G := $FF;
      B := 0;
    end;
  2: begin
      R := 0;
      G := $FF;
      B := mt;
    end;
  3: begin
      R := 0;
      G := $FF - mt;
      B := $FF;
    end;
  4: begin
      R := mt;
      G := 0;
      B := $FF;
    end;
  5: begin
      R := $FF;
      G := 0;
      B := $FF - mt;
    end;
  end; // case
  Result := rgb(R,G,B);
end;

Encore plus fort ! Attention, âmes sensibles s'abstenir, le résultat suivant pourraient choquer les personnes fragiles :

Code:

1
2
3
4
5
6
7
8
procedure TForm1.Button1Click(Sender: TObject);
const
  bleue = 16711680;
  jaune = 65535;
begin
//  panel1.Caption := 'Salut forum !';
  panel1.Color := GiveRainbowColor(bleue, jaune, 0);  // 172 52 0
end;

Résultat :

Code:

1
2
si commentée :  // 100 104 109
si décommentée :// 240 120 0

26/09/2016, 17h30
anapurna

salut,

En reprenant la formule sous excel tu t’aperçois que la valeur tronqué correspond a 6 tans que la hauteur n'est pas supérieur a environs 65537... dommage elle n'est pas dans le case ;)
plus tes couleur sont grande plus tu auras des chance d'obtenir des valeur = 6 dans des petites hauteur
26/09/2016, 17h36
Jipété

Citation:

Envoyé par anapurna

En reprenant la formule sous excel tu t’aperçois que la valeur tronquée correspond à 6 tant que la hauteur n'est pas supérieure à environ 65537... dommage elle n'est pas dans le case ;)
plus tes couleurs sont grandes plus tu auras des chances d'obtenir des valeurs = 6 dans des petites hauteurs

Salut et merci de ta participation et de tes tests, mais on oublie tout ça, relis bien mon post qui précède le tien : je ne fais pas varier les couleurs, je me contente de commenter ou décommenter une ligne avec un texte n'ayant rien à voir avec ces histoires de couleurs...
Incompréhensible...
26/09/2016, 17h53
anapurna

salut

jpete regarde bien mon commentaire aussi
quand tu regarde la fonction en fin de block il fait un Result := rgb(R,G,B);

sauf que les valeurs dans notre cas ne sont pas initialisé car il ne passe pas dans le case et par conséquence il prend n'importe quel valeur et donc quelque soit la modification de code celui-ci pourras jouer sur la valeur de retour car les couleur pointe dans un espace mémoire non initialisé
26/09/2016, 18h54
Jipété

1 pièce(s) jointe(s)

Citation:

Envoyé par anapurna

quand tu regardes la fonction en fin de block il fait un Result := rgb(R,G,B);

sauf que les valeurs dans notre cas ne sont pas initialisées

Bien vu, camarade !
J'ai rajouté r := 0; g := 0; b := 0; au début de la fonction et toutes ces couleurs bizarres sont devenues noires :ccool: !

À partir de là, je me suis rendu compte que cette fonction n'était capable que de générer des arcs-en-ciel en mode "rainbow", et bon, ça ira comme ça.
J'ai d'autres fonctions pour d'autres types de dégradés.

Tiens, cadeau :
Pièce jointe 221245

PS : j'ai volontairement généré de grands pas (aColor := GiveRainbowColor(0, 32, h div 16);) pour pouvoir bien voir le saut d'une couleur vers la suivante.
Ce qui est dommage, c'est qu'on ne sache pas précisément à quoi correspondent iMin et iMax, mais 32 x 16 correspond à la longueur de mon buffer de travail et au Width du TImage de destination ; à partir de là, essais et observations ;)

Merci à tous, je me coucherai moins bête ce soir :mrgreen: