Discussion :

[Jipété]

Bonjour à tous,

J'y vais aussi de ma p'tite démo alors

Ci-dessous l'exercice du matin, pour se détendre un peu.

Je suis parti du code d'Andnotor, j'ai juste fait deux microscopiques modif's pour l'adapter à Lazarus, savoir :

Code :

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

1
2
  //Fond noir
  //ZeroMemory(Bmp.ScanLine[Bmp.Height -1], Bmp.Height *LineSize);

commenté car inconnu de Lazarus et flemme de chercher un remplaçant, de toute façon l'image a un fond noir dans ce contexte.

Code :

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

1
2
3
  //Premier pixel (en bas à gauche)
//  p := Bmp.ScanLine[Bmp.Height -1];
  p := Bmp.RawImage.GetLineStart(Bmp.Height -1);

et ça, juste pour que le compilo arrête de me dire que ScanLine n'est pas multi-plateforme.

De toute façon, que ça soit une ligne ou l'autre, le résultat est tout autant raté :


Pour un EDI se prétendant Delphi-like, àmha y a encore du chemin à parcourir...
Et je comprends mieux pourquoi je patauge et misère et galère pendant des jours sur des bouts de code piochés sur E-E ou SO.

Bonne journée,

[Jipété]

Yop !

Les nouvelles du soir (Andnotor t'en vas pas, j'ai besoin de toi en bas )

En fin de matinée j'avais commencé à rédiger ça :

Je suis anéanti !

Anéanti car j'étais tout content d'avoir enfin trouvé une solution (lien dans le code + bas) qui fonctionne tip-top, j'ai ma ligne rouge, j'ai d'autres fichiers avec deux lignes de 8 pixels, les couleurs sont bonnes, en pf24bit comme en pf32bit, bref, je monte dans les tours en testant avec des fichiers de + en + gros et là, patatras, j'ai plusieurs images de 250x250 en 24 et 32 bits, et aucune copie ne fonctionne

J'ai beau forcer en remplaçant 3 par 4 partout où je le trouve, rien n'y fait : les copies affichent des traits verticaux symptomatiques des problèmes de balayage, et cette fois je n'arrive pas à trouver où ça coince, indépendamment du fait que parfois bmp1.PixelFormat remonte 24 quand il est bien clair que l'image est en 32 bits.
Va comprendre...

C'est l'enfer qui revient, après seulement 15 minutes de bonheur.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
procedure TForm1.btnForumFPClick(Sender: TObject);
// http://forum.lazarus.freepascal.org/index.php?topic=7771.15  3e post en partant de la fin
var
  bmp1, bmp2:TBitmap;
  ptr1, ptr2:Pointer;
  h,w:integer;
begin
  if opd.Execute then
  try
    bmp1:=TBitmap.Create;
    bmp2:=TBitmap.Create;
 
    bmp1.LoadFromFile(opd.FileName);
caption := (IntToStr(BytesPerPixel(bmp1.PixelFormat)));
// 3 avec exp2a_250.bmp, "a" pour alpha, ie c'est un fichier 32 bits, alors pourquoi 3 ?
// mais 3 aussi (correct) avec test24bits.bmp dont la copie foire quand même...
 
    bmp2.PixelFormat := bmp1.PixelFormat;
    bmp2.SetSize(bmp1.Width, bmp1.Height);
 
    Image1.Picture.Assign(bmp1);
 
    bmp2.BeginUpdate;
    for h:=0 to bmp1.Height-1 do begin
      ptr1 := bmp1.RawImage.Data + bmp1.Width*3*h;      
      ptr2 := bmp2.RawImage.Data + bmp2.Width*4*h;
      for w:=0 to bmp1.Width-1 do begin
        Move(ptr1^, ptr2^, 3);     
        ptr1 := Pointer( integer(ptr1)+3);   //BGRBGRBGR   
        ptr2 := Pointer( integer(ptr2)+4);   //BGRXBGRXBGRX
      end;
    end;
    bmp2.EndUpdate;
 
    Image3.Picture.Assign(bmp2);
//      bmp2.SaveToFile('../cc.bmp');
  finally
    bmp1.Free;
    bmp2.Free;
  end;
end;

Mais je ne l'ai pas posté, suite à un dérangement imprévu.

Ce soir je me repenche dessus et je décide d'utiliser la formule magique d'Andnotor, que je mets en œuvre ainsi :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
//case aPixelFormat of
case bmp1.PixelFormat of
  pf1bit   : Bits :=  1;
  pf4bit   : Bits :=  4;
  pf8bit   : Bits :=  8;
  pf15bit  : Bits := 15;
  pf16bit  : Bits := 16;
  pf24bit  : Bits := 24;
  pf32bit  : Bits := 32;
  else begin ShowMessage('PixelFormat non valide !'); Exit; end;
end;
 
LineSize := Trunc(((bmp1.Width * Bits) +31) /32) *4;  //AVEC alignement
for h:=0 to bmp1.Height-1 do begin
//  ptr1 := bmp1.RawImage.Data + bmp1.Width*3*h;
  ptr1 := bmp1.RawImage.Data + LineSize*h; // <<<<<<< /!\ /!\ /!\
  ptr2 := bmp2.RawImage.Data + bmp2.Width*4*h;
  for w:=0 to bmp1.Width-1 do begin
    Move(ptr1^, ptr2^, 3);     //
    ptr1 := Pointer( integer(ptr1)+3);   //BGRBGRBGR
    ptr2 := Pointer( integer(ptr2)+4);   //BGRXBGRXBGRX
  end;
end;
bmp2.EndUpdate;

et là, miracle et stupéfaction, les fichiers qui foiraient ce matin sont enfin bien recopiés !
Merci à toi, camarade, tu m'ôtes une énooooorme épine du pied.

Il reste cependant un petit souci : comme noté ce matin, un de mes fichiers de test indique un PixelFormat à pf24bit alors que les informations récupérées dans le BitmapInfoHeader montrent un pf32bit -- qui ne s'appelle pas comme ça.
Mais qu'utiliser dans ta formule ? le PixelFormat faux mais qui permet une bonne copie, ou biSizeImage div (biWidth * biHeight) en provenance du BitmapInfoHeader, valeur correcte mais qui fait foirer la copie...


De plus, par quoi serait-il possible de remplacer le 4 de la ligne 21 ptr2 := Pointer( integer(ptr2)+4); //BGRXBGRXBGRX pour que cette valeur puisse "bouger" en fonction de paramètres récupérés par ailleurs ?
Ça serait bien agréable
(je pense que le 3 serait remplaçable par bits DIV 8, correct ? Mais si bits s'appuie sur PixelFormat, retour 5 lignes plus haut pour la question existentielle
Oui, si le PixelFormat vaut 15 je suis mort, je sais, mais je n'envisage [pour le moment] que les cas 24 et 32 -- c'est bien assez compliqué comme ça)

On avance cependant pas mal, je suis bien content

[anapurna]

salut

je crois que 4 represente le nombre octet pour un couleur

Code :

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

1
2
3
 
  sizeof(RGB) = 3
  sizeof(RGBA) = 4

a confirmer

[Jipété]

Yep !

salut

je crois que 4 represente le nombre octet pour un couleur

Code :

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

1
2
3
 
  sizeof(RGB) = 3
  sizeof(RGBA) = 4

a confirmer

L'idée est sympathique, je l'ai utilisée ainsi ptr1 := Pointer(integer(ptr1)+(bits DIV 8)); mais pas pour le 4, qui doit rester 4.

Et de toute façon, c'est désespérant cette histoire. Regarde, je viens de faire des tests en utilisant soit bmp1.PixelFormat (qui est parfois faux, je le rappelle), soit BitmapInfoHeader.biBitCount et ça donne ça :

utilisation de bmp1.PixelFormat :	utilisation de BitmapInfoHeader.biBitCount :
exp2a_250: copie ok (bih) Pixel Bit Count : 32 bmp1.PixelFormat : 24	exp2a_250: copie kc (bih) Pixel Bit Count : 32 bmp1.PixelFormat : 32
bmp4test96x96x24: copie ok (bih) Pixel Bit Count : 24 bmp1.PixelFormat : 24	bmp4test96x96x24: copie ok (bih) Pixel Bit Count : 24 bmp1.PixelFormat : 24
bmp4test96x96xA32: copie ok (bih) Pixel Bit Count : 32 bmp1.PixelFormat : 24	bmp4test96x96xA32: copie kc (bih) Pixel Bit Count : 32 bmp1.PixelFormat : 32
savetest32_xp: couleurs inversées (original créé par lazarus) (bih) Pixel Bit Count : 32 bmp1.PixelFormat : 32	savetest32_xp: couleurs inversées (original créé par lazarus) (bih) Pixel Bit Count : 32 bmp1.PixelFormat : 32

C'est désespérant, et j'ai l'impression qu'il est illusoire d'espérer trouver une solution définitive : on manque d'informations pour savoir quels paramètres utiliser...

Et comme je l'ai lu lors de mes pérégrinations sur le web, travailler à partir de Linux n'arrange rien :
sur cette page, dans cette discussion, cherchez (c'est tout au début) le 2^e post d'un certain Marc (l'avatar aux cheveux blancs) qui explique, sous un 1^er bloc de code, que

The bitmap loaded has a bits-per-pixel of 24 while bitmap 2 has a bits-per-pixel of 32. While the depth of both bitmaps are 24bpp, the gtk widgetset internally prefers 4 bytes to store a pixel. Therefore you cannot simply copy a whole line.

Mais en plus personne ne nous explique cette notion de depth (profondeur ? = nombre de bits par pixel ? C'est ce que dit une page [lien de tourlourou au début] sur RawImage : Number of used bits per pixel).
Et pourquoi/comment se fait-il que Marc note une différence au niveau de bits-per-pixels entre les 2 bitmaps, alors que depth, qui représenterait aussi bits-per-pixels, est identique pour les 2 bitmaps.

C'est hallucinant ce comportement.

D'autres idées ?

[anapurna]

salut

dis moi la valeur de "bicompression" dans le BITMAPINFOHEADER est toujours la même ?

pour rappel

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
tagBITMAPINFOHEADER  = RECORD 
   biSize       : DWORD;
   biWidth     : LONGINT;
   biHeight    : LONGINT;
   biPlanes          : WORD;
   biBitCount       : WORD;
   biCompression : DWORD;
   biSizeImage : DWORD;
   biXPelsPerMeter : LONGINT;
   biYPelsPerMeter : LONGINT;
   biClrUsed : DWORD;
   biClrImportant : DWORD;
END
 
 BITMAPINFOHEADER = tagBITMAPINFOHEADER   ;

je pense que tout les éléments fournis dans l’entête ont une incidence sur la lecture des données

[Jipété]

dis-moi, la valeur de "bicompression" dans le BITMAPINFOHEADER est toujours la même ?

Je ne l'ai jamais regardée pour la bonne et simple raison qu'elle doit être tout le temps à 0 sinon je ne pourrais pas afficher les images qui, dans l'ensemble, se décodent bien.

pour rappel

Je connais.

je pense que tout les éléments fournis dans l’entête ont une incidence sur la lecture des données

etc.

J'ai voulu essayer de creuser un peu cette histoire de couleurs inversées notées hier soir, et voici comment je m'y suis pris :

je suis parti d'un fichier de test de 4 pixels rouges sur 1 ligne en mode pf24bit, je l'ai ouvert avec TheGimp, je lui ai ajouté un canal alpha et l'ai exporté (je rappelle qu'il a été créé sous XP avec un vieux PaintShopPro qui ne supporte pas l'alpha).
Je l'ai ensuite ouvert avec mon prog de test, ai demandé une copie et ai enregistré la copie.

Je vous laisse regarder les résultats : en haut l'original avec ses pixels sur 4 bytes, en bas la copie où les pixels repassent en 3 bytes

Pourquoi ?
Hé bien, surement parce qu'on s'appuie sur bmp.PixelFormat, look :

Code :

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

1
2
(bih) Pixel Bit Count : 32
 bmp1.PixelFormat     : 24

Mais si je m'appuie sur biBitCount, d'autres problèmes surviennent (revoir le tableau d'hier).
Je serais bien resté avec l'idée du bmp.PixelFormat si je pouvais trouver dans le fichier une indication comme quoi il a été écrit avec Lazarus, d'où obligation d'adaptation à la lecture, mais nib de nib..

Alors que faire ?

[anapurna]

salut

on vois bien la différence ou la couleur d'un pixel dans un cas est défini sur 3 pixel et dans le second sur 4

[Jipété]

on voit bien la différence où la couleur d'un pixel dans un cas est défini sur 3 pixel et dans le second sur 4

Oui, ça je l'avais bien remarqué aussi, mais ce n'est pas de mon fait. La question déjà posée est : pourquoi ? Pourquoi cette différence ?

[anapurna]

salut

bon pour retrouver ton nombre d'octet tu fait

Code :

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

nbDiv := biSizeImage/biBitCount/(biWidth/biHeight)

après je ne sais pas si cela marche quand la hauteur et plus grand que la largeur
il faut peut être inverser à voir

Ps : le pourquoi tu l'as dis toi meme ton premier logiciel ne connais pas l'alpha ... je suppose qu'il ne connais pas le 32 non plus

[Jipété]

bon pour retrouver ton nombre d'octet tu fait

Code :

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

nbDiv := biSizeImage/biBitCount/(biWidth/biHeight)

Euh, non, surement pas :

Code :

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

1
2
3
4
5
6
7
(bih) Width           : 4
(bih) Height          : 1
(bih) Size Image      : 16
-> PixelFmt = SI / WxH: 4
(bih) Pixel Bit Count : 32
tst anapurna SI/BC/W/H: 0
(brid) Depth          : 32

Ps : le pourquoi tu l'as dis toi-même ton premier logiciel ne connaît pas l'alpha ... je suppose qu'il ne connaît pas le 32 non plus

Merci de bien lire. J'ai mis en gras les parties importantes :

je suis parti d'un fichier de test de 4 pixels rouges sur 1 ligne en mode pf24bit, je l'ai ouvert avec TheGimp, je lui ai ajouté un canal alpha et l'ai exporté (je rappelle qu'il a été créé sous XP avec un vieux PaintShopPro qui ne supporte pas l'alpha).
Je l'ai ensuite ouvert avec mon prog de test, ai demandé une copie et ai enregistré la copie.

Je vous laisse regarder les résultats : en haut l'original avec ses pixels sur 4 bytes, en bas la copie où les pixels repassent en 3 bytes

[Jipété]

Bonjour,

encore passé la fin de soirée d'hier et la matinée d'aujourd'hui à faire des tests de + en + bas niveau, avec toujours un curieux problème.
Compte rendu :

Afin de lever toute ambiguité, j'ai créé ex nihilo avec The Gimp un fichier de 4 px de couleur cyan sur 1 ligne et avec un canal alpha, donc PixelFormat = pf32bit, normalement.

Déjà ça part mal car ouvrir ce fichier avec bmp.LoadFromFile me retourne un bmp.PixelFormat à 24 bits alors que BitmapInfoHeader.biBitCount remonte 32.

Si tout le monde trouve ça normal, je vais peut-être me recycler dans un camion pizza-frites.

Parce que c'est bien joli, dans GraphType il y a quelques commentaires explicatifs :

Code :

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

1
2
3
  TRawImageDescription = object
    Depth: Byte; // used bits per pixel
    BitsPerPixel: Byte; // bits per pixel. can be greater than Depth.

mais rien pour nous expliquer la différence entre "bits per pixel" et "used bits per pixel".
Un peu léger, je trouve...

Mais bon, c'est comm' ça, en plus, les forums Lazarus parfois abandonnent les problèmes des gens : lecture (affligeante)...

Prenons donc le taureau par les cornes.
Toujours dans GraphType on trouve aussi :

Code :

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

1
2
  TRawImage = object
    Data: PByte;

Alors je pars de mon fichier ultra-simple de 4 pixels avec canal alpha, qui fait donc 16 bytes à la queue-leu-leu dans la zone Data du RawImage, c'est très net avec un afficheur hexa, voir + bas, et comme il n'y a qu'une ligne, je simplifie à l'extrême la formule de copie, qui devient :

Code :

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

1
2
3
4
5
6
7
ptr1 := bmp1.RawImage.Data; // pointeur sur source 
ptr2 := bmp2.RawImage.Data; // pointeur sur destination
for w := 0 to (bmp1.Width*4)-1 do begin  // allons-y byte par byte
  Move(ptr1^, ptr2^, 1);   // copie d'un byte 
  ptr1 := Pointer( integer(ptr1)+1); // byte suivant du source
  ptr2 := Pointer( integer(ptr2)+1); // byte suivant de la destination
end;

et le résultat est un grand n'importe quoi (j'ai mis les deux dernières couleurs en gris, en fait c'est transparent [Alpha à 00]) -- en haut l'original, en bas le résultat de ces quelques lignes de code :


Alors, où est l'erreur dans cette formule ?

Parce qu'à ce bas niveau-là, RawImage.Data et autres pointeurs, et avec un fichier aussi petit, il n'est plus question de Bitmap, PixelFormat (remonté par Lazarus comme pf24bit pour l'original, désolé de le rappeler encore et encore), et autres infos de haut niveau, ici il est juste question de ne pas se tromper dans les pointeurs, en gros il s'agit de copie de bytes et point barre.

Où est l'erreur dans la formule ?
Le fichier source pour ceux qui veulent jouer : basic4x1_A.zip

Le problème c'est que les pointeurs c'est compliqué. Très compliqué ! La preuve : comme je voulais essayer de comprendre ce qui coince, j'ai à peine modifié tout ça en rajoutant un TBytesStream :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
var 
  bs: TBytesStream;
begin
  // petite modif proc de copie :
  bs:= TBytesStream.Create;
  bs.SetSize(16);
  ptr1 := bmp1.RawImage.Data; // pointeur sur source 
  for w := 0 to (bmp1.Width*4)-1 do begin  // allons-y byte par byte
    bs.WriteByte(byte(ptr1^));  // avec chapeau c'est le + proche.
    // sans chapeau affiche 90 91 92 93 94 95 etc.
    // avec @ affiche 64 64 64 64 64 etc.
    // avec @ et chapeau affiche 90 91 92 93 94 95 etc.
    ptr1 := Pointer( integer(ptr1)+1); // byte suivant du source
  end;
  bs.Position:= 0;
  bs.SaveToFile('/path/MemData.bin');

Partant des résultats indiqués ci-dessus, je me suis dit, bien que ça semble fou, qu'il fallait tenter ptr1 := Pointer( integer(ptr1)+2); mais effectivement, je récupère moins de bonnes données, et une tentative (stupide, juste pour dire -- au point où j'en suis...) dans l'autre sens ptr1 := Pointer( integer(ptr1)+0); ne renvoie que des FF FF FF etc.

Comme il y avait quand même un décalage intéressant dans le mode bs.WriteByte(byte(ptr1^)); // avec chapeau c'est le + proche, j'ai aussi tenté avec

Code :

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

1
2
3
if ( (w+1) mod 4 = 0 ) then // ajoute un 00 dans le stream toutes les 4 positions,
// mais les données qui y arrivent sont toujours mauvaises.
  bs.Position:=bs.Position+1;

mais si le stream se décale (et augmente de taille), les données qui lui parviennent à partir du deuxième pixel sont toujours décalées : en haut la ligne "avec chapeau c'est le + proche", dessous en rouge la matérialisation du byte rajouté avec if...


Merci de vos lumières car là, je suis complètement à court d'idées.
Et désolé d'avoir été aussi long, mais c'est loin d'être simple.
J'espère avoir été clair.

[anapurna]

salut

il n'y aurais pas un problème de taille
je pense que l’incrément est un incrément de la taille d'un Integer

tu travail au niveau du byte mais la restitution se fait a mon avis au niveau entier donc 2 byte
à vérifier

je pense qu'il faut que tu cherche de se coté là

[ThWilliam]

Salut JP.

Bon, j'ai fait quelques tests sous Windows...

Le fichier bmp dans ton zip est en 32bits/pixel, je le vois même dans les propriétés du fichier que m'affiche l'OS.
Après un Bmp1.Loadfromfile, Lazarus le considère comme un pf24bit !
Et pourtant, il a bien été lu et la preuve : un Bmp1.Savetofile me donne, dans éditeur hexa, exactement les mêmes valeurs que le fichier original (on est toujours en 32bits).

Où est l'erreur dans la formule ?

Simplement pcq Lazarus considère le bitmap en 24 bits, d'où :

Code :

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

1
2
3
4
5
6
7
    ptr1 := bmp1.RawImage.Data; // pointeur sur source
    ptr2 := bmp2.RawImage.Data; // pointeur sur destination
    for w := 0 to (bmp1.Width*3)-1 do begin  // au lieu de Width*4
         Move(ptr1^, ptr2^, 1);   // copie d'un byte
         inc(ptr1);
         inc(ptr2);
    end;

Le résultat est un parfait 24 bits !!!
Ne me demande pas comment Lazarus a fait pour s'y retrouver !!!

Maintenant, j'ouvre ton fichier original sous Photoshop, je modifie un pixel, j'enregistre --> cette fois, Lazarus reconnait le pixelformat (pf32bits).
Dans ce cas, ton "width*4" est tout-à-fait correct.

Je ne te demande pas ce que tu penses de ce truc de fou

Amicalement
Thierry

[Jipété]

e pense qu'il faut que tu cherche de ce côté-là

Tu es gentil, mais je ne sais plus quoi chercher...

Bon, j'ai fait quelques tests sous Windows...

Le fichier bmp dans ton zip est en 32bits/pixel, je le vois même dans les propriétés du fichier que m'affiche l'OS.
Après un Bmp1.Loadfromfile, Lazarus le considère comme un pf24bit !
[...]

Oui, c'est bien ce que je répète depuis une semaine... Attends, on va faire les choses en grand (j'en ai tellement marre que je me lâche un peu )

Le fichier bmp dans ton zip est en 32bits/pixel, je le vois même dans les propriétés du fichier que m'affiche l'OS.
Après un Bmp1.Loadfromfile, Lazarus le considère comme un pf24bit !
[...]

[...]
Le résultat est un parfait 24 bits !!!

qui perd donc son canal alpha et donc la transparence...

[...]
Je ne te demande pas ce que tu penses de ce truc de fou

Ouf !
Tu l'a dit, j'ai bien cru que je devenais fou...

Maintenant, j'ouvre ton fichier original sous Photoshop, je modifie un pixel, j'enregistre --> cette fois, Lazarus reconnait le pixelformat (pf32bits).
Dans ce cas, ton "width*4" est tout-à-fait correct.

Tu pourrais mettre un .zip avec ce fichier modifié ? Merci.
J'espère m'en sortir en allant chercher les datas brutes de chez brut sans notions de bitmap ou autre, ça, ça a l'air de fonctionner, en attendant de comparer ton fichier modifié et le mien

[ThWilliam]

Voici le fichier modifié sous PS.

basic4x1_A.zip

Le dernier pixel en BGRA : F0 9D D2 FF
A noter que PS ajoute 2 octets 00 à la fin, ce que ne fait pas Lazarus.

[Jipété]

Grand merci

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
Filename : basic4x1_A.bmp
(bih) Width           : 4
(bih) Height          : 1
(bih) Size Image      : 16
-> PixelFmt = SI / WxH: 4
(bih) Pixel Bit-Count : 32
(brid) Depth          : 32
---
Filename : basic4x1_Aps.bmp
(bih) Width           : 4
(bih) Height          : 1
(bih) Size Image      : 18 <<< les 2 bytes en plus
-> PixelFmt = SI / WxH: 4
(bih) Pixel Bit-Count : 32
(brid) Depth          : 32
---
Filename : basic4x1_Athierrybygimp.bmp
(bih) Width           : 4
(bih) Height          : 1
(bih) Size Image      : 16
-> PixelFmt = SI / WxH: 4
(bih) Pixel Bit-Count : 32
(brid) Depth          : 32
---

Et le plus dément, c'est que, oui, le PixelFormat de ton fichier est bien passé à pf32bit, je l'ai ouvert avec The Gimp, rien modifié, juste exporté sous un autre nom et il est repassé à pf24bit !
Pourtant RawImage.Description.Depth (la vraie commande de PixelFormat, qui n'est qu'un helper vers l'autre) montre 32. Un mystère cette histoire.


Je regarderai plus en détail l'intérieur de tout ça plus tard, là j'en ai un peu marre...

[Jipété]

A noter que PS ajoute 2 octets 00 à la fin, ce que ne fait pas Lazarus.

The scan lines are DWORD aligned, except for RLE-compressed bitmaps. They must be padded for scan line widths, in bytes, that are not evenly divisible by four, except for RLE compressed bitmaps.

https://msdn.microsoft.com/en-us/lib...=vs.85%29.aspx

Et comme 4 pixels de 4 bytes ça fait 16 bytes et que 16 c'est divisible par 4, ben PS a "paddé" avec 2 bytes pour rester pair et non divisible par 4.
Allez, j'y retourne (quand j'étais minot, je faisais du Meccano pi quand c'était fini fallait tout démonter [et tout ranger ] -- ben là je démonte de fond en comble le format bitmap...)

[Jipété]

Salut à tous, amis lecteurs (et merci de me supporter stoïquement )

Je ne sais pas comment Lazarus (ou FreePascal) fait son compte, mais je suis sûr que le problème est dans leur camp et dans leur code.
Démo avec des mots :

Ce matin, retour à la source des sources, je lance MSPaint dans Windows XP et je génère un fichier en pf24bit (au-dessus, c'est simple, ça n'existe pas) qui pèse 66 octets.
Dans la foulée je fais la même chose avec PaintShopPro, qui génère exactement le même fichier (comparés à l'éditeur hexa).

Dans ce fichier, les pixels s'appuient sur des RGBTriple (et déjà Microsoft n'est pas conforme avec Microsoft [certains diront "on a l'habitude" ]...) :


je vous passe le reste, voilà l'article pour les curieux) et l'information utile pour décoder le machin se trouve à l'adresse 28 (1C hex), "biBitCount, number of bits-per-pixel" dans la littérature MSDN : 18 hex dans le fichier MSPaint, soit 24 bits.

L'info est confirmée par mes petits outils :

Code :

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

1
2
3
4
5
Filename : MSopaque3x1.bmp
(bih) Pixel Bit-Count : 24 --> 24 / 8 = 3 --> use RGBTriple
(brid) BytesPerLine   : 12 --> donc 12 / 3 = 4 RGBTriple, 3 utiles et 1 de padding
(brid) Depth          : 24
img2contrôle.Picture.Bitmap.PixelFormat : 24

Ensuite j'ouvre ce fichier avec The Gimp et l'exporte sous un autre nom sans avoir rien changé et, mis à part l'ajout par The Gimp d'une palette (optionnelle d'après MSDN) avant les vraies datas, les infos techniques des fichiers sont identiques.

Là où on rigole (jaune), c'est quand toujours dans The Gimp j'ajoute un canal alpha puis exporte, et voilà le résultat :

18 hex = 24 (bits-per-pixel),
20 hex = 32 (bits-per-pixel).

Code :

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

1
2
3
4
5
Filename : gimpA_MSopaque3x1.bmp
(bih) Pixel Bit-Count : 32 --> 32 / 8 = 4 --> use RGBQuad
(brid) BytesPerLine   : 12 --> 3 RGBQuad, no padding
(brid) Depth          : 32
img2contrôle.Picture.Bitmap.PixelFormat : 24

C'est ce que je dis depuis une semaine, et là c'est confirmé et on a bien mis le doigt dessus :
(bih) Pixel Bit-Count : 32
(brid) Depth : 32
img2contrôle.Picture.Bitmap.PixelFormat : 24
Et je rappelle que le calcul de PixelFormat s'appuie sur RawImage.Description.Depth, qui est juste


Bon, ben je vais continuer à explorer la piste de la récupération des datas en mode raw, ou alors tenter une approche avec les RGBTriple.

Code :

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

    for w := 0 to (bmp1.Width*3)-1 do begin  // au lieu de Width*4

Le résultat est un parfait 24 bits !!!

Ce qui m'épate, là, c'est qu'en faisant Width*3 tu te contentes de diminuer la zone de datas à parcourir, genre si Width vaut 4 tu vas de 0 à 11 alors que moi je vais de 0 à 15, et tu trouves un fichier parfait !?


Bientôt le , par contournement.
Bon week,

[Andnotor]

An array of RGBQUAD structures (also called a color table)

Color table égale palette des couleurs (lorsque les couleurs sont indexées). Cela n'a rien à voir avec la zone de données

[Jipété]

An array of RGBQUAD structures (also called a color table)

Color table égale palette des couleurs (lorsque les couleurs sont indexées). Cela n'a rien à voir avec la zone de données

Mouais...
La phrase entière c'est ça :

An array of RGBQUAD structures (also called a color table) follows the bitmap information header structure.

et je te garantis que c'est pas toujours vrai ! :


Elle est où, ta color table là-dedans ? De toute façon, if clrUsed = 0 then no color table (quelque part dans le web Microsoft, ce lien s'en approche) et clrUsed, à l'adresse 2E hex, est bien à 0.

Les gars qui ont rédigé l'article ont juste oublié un mot : may ! :

An array of RGBQUAD structures (also called a color table) may follow the bitmap information header structure.