Bonjour à tous.

Pour traiter  avec ScanLine des bitmap 32 bits, j'utilise :

type
   TPixel32 = packed record
     Blue : byte;
     Green: byte;
     Red  : byte;
     Alpha: byte;
   end;
   TArrayPixel32 = array[0..32767] of TPixel32;
   TpToArrayPixel32 = ^TArrayPixel32;

ce qui est d'ailleurs identique au TRGBQuad de Delphi.

Cela correspond parfaitement à ScanLine, puisque je peux écrire :

var
  Line: TpToArrayPixel32;
  Pix32 : TPixel32;
.......
for Y:= 0 to Bmp.Height -1 do
     begin
        Line := Bmp.ScanLine[Y];
        for X:= 0 to Bmp.Width - 1 do
                 Line[X]:= Pix32;

     end;

Le problème est de convertir un TColor en TPixel32.
D'après l'aide de Delphi, TColor  = AA BB GG RR
Donc, il suffirait de faire (ce que j'ai d'ailleurs vu sur developpez.com)
Pix32:= TPixel32(Color shl 8);

Ce qui ne marche pas.
Je suis obligé de faire :
Pix32:= (bswap32(Color) shr 8);

function BSwap32(const a: integer): integer;
asm
bswap eax;
end;

Qu'en pensez-vous ?
Et comment être certain de devoir faire un swap ? Car j'ai lu que TColor pouvait avoir différents formats internes.

Merci d'avance pour vos éclaircissements.

Thierry
 

Correction :

Pix32:= TPixel32(bswap32(Color) shr 8);

Salut !

Juste un petit message pour te dire que les couleurs et l'ordre des bits est un truc assez déroutant et d'ailleurs, c'était souvent une sujet de discorde entre Cirec et moi.

En tout cas, il me semble qu'il y ait une histoire d'endianness là-dedans.

Tu sais, ce truc idiot qui permet de choisir si 123 est cent vingt-trois ou trois cent vingt-et-un (l'ordre de lecture des chiffres).

Et il n'est pas impossible que TColor soit en réalité stocké en tant qu'Integer et donc lu en littleendian comme le veut la norme Intel. Ce qui expliquerait que tout soit inversé !

Mais là, je m'avance trop.... faudrait tester....

Petit test :

var
P: TPixel32;
begin
P.Blue := 255;
P.Green := 0;
P.Red := 0;
P.Alpha := 0;
// A ce moment P est bleu
asm
mov eax,P // Ici eax foire complètement !!! 000000FF au lieu de FF000000 donc les données sont bien stockées en mémoire à l'envers.
mov eax,clBlue // Ici, je stocke juste la vraie couleur bleue pour comparer: 00FF0000, ce qui est normal, vu le format ABGR

// Pour obtenir 00FF0000 comme désiré, il faut donc bien faire
mov eax,P
shl eax,8
bswap eax
end;

Salut Florent.

Tu as raison, c'est complètement déroutant. 

Aussi, par mesure de prudence, je vais revenir au GetRValue, GetGValue..., fonctions en accord avec le format de stockage.

Je te remercie pour ton explication.

A +

Thierry

Attention car GetRValue ne fait en réalité qu'une opération sur les bits !

Tu pourrais lui passer une couleur en GBRA, elle te renverrai un résultat, mais faux bien sur.

Donc finalement, je ne sais pas trop quelle est la meilleure méthode. (sûrement la tienne [bswap] à condition de commentr au desus pour expliquer le pourquoi du chmilblic)

D'accord avec toi pour le GetRValue.

Mais ce qui m'intéresse uniquement, c'est de connaitre R,G,B à partir d'un TColor pour assigner au TPixel32.

Pix32.Red:= GetRValue(clRed)  sera toujours égal à 255.

Supposons que le format de TColor soit modifié à l'avenir, je suppose que les fonctions de récupération seront aussi adaptées. Ou alors...!?!!?

Salut Je pense que les fonctions seront adaptées sinon ca risque de devenir un sacré chantier  .

Ca me fait bien plaisir de te voir ici ;) Thierry. Ca faisait bien longtemps ^^.

 C'est vrai que de Swaper n'est pas le top mais en meme temps, la méthode ne fait pas sale je trouve : enfin moi elle me choque pas. Par contre je trouve que cette petite découverte est forte intéressante merci à vous deux.