Discussion :

[Jipété]

Bonjour,

Oui, c'est encore moi avec mes misères de TImage, TBitmap, PixelFormat et tout ce foutoir immonde...

Tout est dans le titre, et les détails suivent, mais tout d'abord je tiens à préciser que j'ai longtemps, très longtemps résisté (comprendre : retourné le web dans tous les sens sans rien trouver de concluant) avant de venir pleurer ici, mais là, au bout de 3 jours de vaines recherches, je n'en peux plus ...

Alors, pour résumer, sous Linux, si j'utilise aBitmap.PixelFormat := pf32bit; le TImage propriétaire de ce aBimap est vide alors qu'en enregistrant avec aBitmap.SaveToFile('test32.bmp'); ce aBitmap, le fichier, lui, est tout bon :
en beige la fiche, en noir l'image 80x80, en jaune et bleu un dessin.

Voilà le bout de code, normalement avec une TImage (image4) et un bouton sur une fiche ça devrait le faire :

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
procedure TForm1.btnTestFromFossieClick(Sender: TObject);
// examples/canvas_test
  function BytesPerPixel(APixelFormat: TPixelFormat): integer;
  begin
    Result := -1;
    case APixelFormat of pf8bit:result:=1;pf16bit:result:=2;pf24bit:result:=3;pf32bit:result:=4;end;
  end;
  procedure WorkWithCanvas(aBitmap: TBitmap);
  begin
    aBitmap.PixelFormat := pf24bit; // 24 ok, 32 vide
    aBitmap.Width  := 80;
    aBitmap.Height := 80;
    Image4.Width:=80; Image4.Height:=80; // ici ou en fin de proc = pareil, sert à rien...
    aBitmap.Canvas.Brush.Color := clBlue;
    aBitmap.Canvas.Pen.Color := clYellow;
    aBitmap.Canvas.Pen.Width := 5;
    aBitmap.Canvas.Rectangle(20, 20, 60, 60);
//    Caption:=IntToStr(BytesPerPixel(Image4.Picture.Bitmap.PixelFormat));//ok 4 si 32
//    aBitmap.SaveToFile('test32.bmp'); // OK OK OK !
  end;
begin
  Image4.Picture.Bitmap.PixelFormat := pf32bit; // forcé mais sert à rien
  Caption:=IntToStr(BytesPerPixel(Image4.Picture.Bitmap.PixelFormat));//3 par défaut
  WorkWithCanvas(Image4.Picture.Bitmap);
end;

C'est inspiré des exemples fournis avec la distrib, où j'avais déjà noté en son temps, que ça ne fonctionnait pas en pf32bit sous Linux (à croire que les exemples ne sont qu'à moitié testés ).

Un dernier mot à propos de cette construction où le bouton appelle une proc qui va bidouiller le Bitmap de l'image : c'est parce que dans un autre projet c'est la même construction sauf que le Bitmap y est bidouillé à grands coups de pointeurs et autre Scanline, et ça y fonctionne !, mais la chose n'est pas reproductible avec cet exemple simple (sinon je ne serais pas là).
Vous allez me dire, mais pourquoi faire simple quand on peut faire compliqué, c'est ça ? Je n'ai pas la réponse, mais j'ai une question simple : quelle instruction manque-t-il à ce code pour que je puisse enfin voir mon joli dessin dans cette TImage en mode 32 bits ?

Mon autre problème, aussi, c'est que j'en ai franchement marre de passer des jours et des jours sur les forums, à lire des solutions dont on dirait, d'après la discussion, que ça va fonctionner mais non, pas chez moi...
Et il y a aussi les discussions où ça part bien, avec des solutions auxquelles l'OP répond que chez lui ça ne va pas, et plus de réponse de la part des helpers : un brave mystère, ça, que de laisser ainsi les gens le bec dans l'eau...
Le nombre de discussions que j'ai pu voir comme ça, non finies, sur forum.lazarus.freepascal.org, c'est impressionnant !
Et totalement décourageant...

[gvasseur58]

Salut Jipété !

Je m'absente quelques jours et voilà que je te retrouve empêtré dans les dessins et peintures en tous genres .

Je suis toujours un peu surpris quand je te vois tripoter la propriété PixelFormat qui n'a pas de rôle fondamental en dehors de Scanline qui n'est justement pas portable .

PixelFormat ne fait pas grand chose, car cette propriété est en attente d'être complétée

Code :

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

1
2
3
4
5
6
7
procedure TCustomBitmap.SetPixelFormat(AValue: TPixelFormat);
begin
  if AValue = FPixelFormat then Exit;
  {$IFDEF VerboseLCLTodos}{$note todo copy image into new format }{$ENDIF}
  FreeImage;
  FPixelFormat := AValue;
end;

Moralité : si le format est bon, on sort sans rien faire ; si le format change, on libère l'image sans faire de copie

En fait, les outils que tu utilises sont vraiment basiques. Il est plus que conseillé de passer à des bibliothèques comme BGRABitmap ou de travailler avec des classes graphiques non natives : elles sont fiables et vraiment indépendantes des plateformes (voir ici - en anglais pour l'essentiel). Seul problème : elles demandent plus de "manœuvres" pour être utilisées...

@+ !

[Jipété]

Bonsoir Gilles,

Content de titiller ta curiosité

Alors tu vas rire :

Je suis toujours un peu surpris quand je te vois tripoter la propriété PixelFormat qui n'a pas de rôle fondamental en dehors de Scanline qui n'est justement pas portable .

J'aime bien cette histoire de Scanline et sa rapidité foudroyante ! Et par ailleurs, en étudiant ça, ça m'apprend plein de trucs à côté, bientôt à parler russe, si ça continue
Bon, pour l'instant, c'est plutôt gogol traduction qui me file un coup de main car, crois-le si tu veux mais, peu après avoir posté ici, je suis tombé sur un forum en .ru avec deux snippets ultra-courts qui m'ont inspiré au point de les mettre en œuvre, traduction comprise !
Et bien m'en a pris ! ! !

La première entrée était la question d'un gars comme moi, qui n'avait aucun résultat en pf32bit sous Linux (Bitmap.PixelFormat := pf32bit; // It does not work, but if replaced by pf24bit, then everything is fine), et la suivante était la solution (avec des commentaires du genre "c'est n'importe quoi l'implémentation pf32 sous Linux, d'autant plus que pf24 se comporte comme pf32" ! Ambiance...).
Et j'ai rarement vu un code aussi succinct : en quelques lignes c'est torché ! (j'ai rajouté qq commentaires) :

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
42
43
44
45
procedure TForm1.btnRusseClick(Sender: TObject);
TYPE // http://freepascal.ru/forum/viewtopic.php?t=11041&p=95820
     // c'est tout frais, ça date du 20 avril
    TRGBQuadArray = ARRAY[WORD] OF INTEGER;
    pRGBQuadArray = ^TRGBQuadArray;
    //réponse
    T = array[0..100000] of Byte;
    P = ^T;
  VAR
    i,j   :  INTEGER;
    Bitmap:  TBitmap;
    row   :  pRGBQuadArray;
    //réponse
    q,w: integer;
    A: P;
begin
  Bitmap := TBitmap.Create;
  TRY
    Bitmap.PixelFormat := pf32bit; // не работает, но если заменить на pf24bit, то всё отлично
                                   // It does not work, but if replaced by pf24bit, then everything is fine
    // et ça fonctionne très bien avec la correction apportée par la réponse !
    Bitmap.Width  := 320;
    Bitmap.Height := 240;
    { // original :
    FOR j := 0 TO Bitmap.Height-1 DO
    BEGIN
      row := Bitmap.Scanline[j];
      FOR i := 0 TO Bitmap.Width-1 DO
        row^[i] := i*j; // chapeau !
    END; }
    // réponse :
    for q := 0 to Bitmap.Height-1 do begin
      A := Bitmap.Scanline[q];
      for w := 0 to Bitmap.Width-1 do begin
        A^[w*4]   := 255;   //blue    // chapeau aux 4 lignes !
        A^[w*4+1] := 0; //green   
        A^[w*4+2] := 0;   //red    
        A^[w*4+3] := 127; //alpha  
      end;
    end;
    Image4.Picture.Graphic := Bitmap;
  FINALLY
    Bitmap.Free;
  END
 end;

Vous voulez lire les commentaires ?

bitmap.pixelformat = pf24bit;
This scene is painted correctly in green.
Which means that 4 bytes or has no effect , i.e. apparently it is present even in Linux 24bit mode.

if you change the [w*4 par [w*3, and comment out the line A[w*4+3]:= 255 //alpha, it will zakryshivanie bands. ???????????
and paint is only 3/4 of the whole scenebitmap. That once again confirms that it is 24bit mode 4-byte mode.

bitmap.pixelformat = pf32bit;
This situation is strange mode.

use the code as written above, with the filling of all 4 bytes ( the color should be green) very fine strips. gray background of some sort.
in this case, if you change the code to fill only 3 bytes for the 3 groups of shading in green going fine,

I tried to add one more 5th byte at one point, it does nothing, there is a crash.

I come to the conclusion that pf24bit in Linux is pf32bit, and pf32bit - I do not know how it works - a wrong format. most likely it is pf24bit.
pf32bit - normally draws only 3 bytes on the point, otherwise the picture is spoiled.

Bon, il faut que je continue à travailler là-dessus (oui, j'ai écrit en haut que ça fonctionnait très bien mais c'est pas vrai : il y a toujours cette embrouille du mic-mac entre rouge demandé et bleu affiché, par exemple, mais au moins c'est affiché !) mais, mine de rien, j'ai considérablement progressé cet aprème, après trois jours de galère (bah, ma collection d'AV et autres SIGSEGV a bien augmenté, )

Gilles, où (et comment) as-tu trouvé le bout de code que tu as posté ? Je n'ai rien trouvé dans 1.4.0

[ThWilliam]

Salut JP,

Le bout de code de Gilles se trouve dans "custombitmap.inc" (répertoire Windows : lcl\include).
J'ai fait quelques tests sous Linux, et de fait, je n'arrive même pas à créer un simple TBitmap 32bits, dessiner un carré, et l'afficher sur un Canvas quelconque !
Peut-être faut-il passer par une réinitialisation du RawImage (?)

Si je trouve un truc, je te tiens évidemment au courant.

Cordialement
Thierry

[Jipété]

Salut Thierry, salut Gilles, salut les autres

Le bout de code de Gilles se trouve dans "custombitmap.inc" (répertoire Windows : lcl\include).

OK, merci pour le retour, je ne comprends pas pourquoi je n'arrive pas à remonter avec Ctrl-clic, je ne "sors" pas de Graphics...

À l'occasion je regarderai ce qui se cache sous FreeImage, en attendant, ce que je peux dire, c'est que selon que je mets pf24bit ou pf32bit à l'endroit qui va bien, je gagne une image rouge ou une image bleue, toutes autres choses égales par ailleurs .

J'ai fait quelques tests sous Linux, et de fait, je n'arrive même pas à créer un simple TBitmap 32bits, dessiner un carré, et l'afficher sur un Canvas quelconque !
Peut-être faut-il passer par une réinitialisation du RawImage (?)

Avec mon code ? Tiens, v'là avec quoi je bosse depuis ce matin, c'est que du bonheur (tout est là, un bouton et un TImage genre 400x300) :

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
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
FUNCTION RGBtoRGBTriple(CONST red, green, blue:  BYTE): TRGBTriple;
BEGIN
  WITH RESULT DO
  BEGIN
    rgbtRed   := red;
    rgbtGreen := green;
    rgbtBlue  := blue
  END
END {RGBTriple};
 
FUNCTION RGBAtoQuadBGRA(CONST red, green, blue, reserved: BYTE): TRGBQuad;
BEGIN
  WITH RESULT DO
  BEGIN
    rgbRed   := red;
    rgbGreen := green;
    rgbBlue  := blue;
    rgbReserved := reserved;
  END
END {RGBQuad};
 
function BytesPerPixel(APixelFormat: TPixelFormat): integer;
begin
  Result := -1;
  case APixelFormat of
    pf8bit : result := 1;
    pf16bit: result := 2;
    pf24bit: result := 3;
    pf32bit: result := 4;
  end;
end;
 
procedure TForm1.btnRussagainClick(Sender: TObject);
const
  WSIZE = 320; // largeur
  HSIZE = 240; // hauteur
TYPE // http://freepascal.ru/forum/viewtopic.php?t=11041&p=95820
  TArrayOfByte = array of TRGBQuad;
//  TArrayOfByte = array of TRGBTriple; // raies verticales !?
VAR
  bmp:  TBitmap;
  h, w: integer;
  AoB: TArrayOfByte;
  fs : TFileStream;
  FileSize: Integer;
  BPP: integer;
begin
  bmp := TBitmap.Create;
  TRY
    with bmp do begin
      PixelFormat := pf32bit; // ou pf24bit, pour passer du rouge au bleu
      SetSize(WSIZE, HSIZE);
      BPP := BytesPerPixel(PixelFormat);
      FileSize := WSIZE * HSIZE * BPP;
      SetLength(AoB, FileSize);
      //Image4.Picture.Bitmap.PixelFormat:=PixelFormat; // mis pour voir si pf24/32 avait une influence, mais non
    end;
 
    //1-remplissage de l'array (ici demande = rouge transparent)
    for h := 0 to HSIZE-1 do
      for w := 0 to WSIZE-1 do
        //AoB[(h*WSIZE)+w] := RGBtoRGBTriple(255, 0, 0); // raies verticales !?
        AoB[(h*WSIZE)+w] := RGBAtoQuadBGRA(255, 0, 0, 127);
        //attention à l'ordre (selon 24 ou 32) ! /!\ B G R A  en mode 32 /!\ dans fic : 00 00 FF 7F
 
//fs := TFileStream.Create('test3005_32.bin', fmCreate);
//fs.WriteBuffer(pointer(AoB)^, FileSize);
//fs.Free;
 
    //2-affichage (= génération du bmp)
    bmp.BeginUpdate;
      for h := 0 to HSIZE-1 do
        //Move(AoB[h], bmp.ScanLine[h]^, WSIZE*BPP); // /!\ Ne pas utiliser BPP ! (sinon carré rouge et quart noir en mode pf24)
        Move(AoB[h], bmp.ScanLine[h]^, WSIZE*4); 
    bmp.EndUpdate;
 
//    bmp.SaveToFile('test3005_32_BGRA.bmp');
 
    Image4.Picture.Graphic := bmp;
  FINALLY
    bmp.Free;
  END
end;

Alors bon, Gilles, désolé mais je trouve que ça a son importance, et comme le disait le russe, pour avoir un joli rouge en mode pf24bit, il faut utiliser du TRGBQuad (= mode pf32bit) sinon tout ce qu'on gagne c'est des raies verticales toutes moches...

Je suis en train de regarder avec l'éditeur hexa, mais effectivement, en mode pf32bit il y a un mic-mac de rouge demandé et transformé en bleu à l'affichage.
Or, quand je regarde les datas brutes de chez brut en binaire pur, leur enregistrement est identique ! On voit des paquets (TRGBQuad) de 00 00 FF 7F qui se suivent, et heureusement, sinon je mangeais mon chapeau !

J'en conclus que la gestion de ces datas par le Bitmap et ses routines interfère avec elles (confirmé par l'examen hexa des datas bmp (bmp.SaveToFile('fichier.bmp');) et impacte le résultat, les paquets d'octets dans les fichiers n'étant plus les mêmes.
EDIT : j'ai regardé mes dumps avec le format BMP à côté, il en ressort que les pf24bit sont enregistrés BGR (comme j'ai pu le lire sur un autre site, d'ailleurs : "[...] l'ordre de l'alternance bleu, vert et rouge" alors que les pf32bit sont enregistrés RGBA...

À gauche ce dont je parle dans les commentaires du code, au centre le même un peu mieux, et à droite le mode pf32bit (désolé, l'explorateur de fichiers ne gère pas la transparence, qui est vraiment affichée par le TImage).
/EDIT

Nota : quand je parle de Bitmap, je parle du temporaire créé pour la manip et non pas celui inclus dans le TImage : ce TImage se contente d'afficher bêtement les données qui lui sont transmises.

OK, pour le moment, je n'ai pas encore joué avec les Headers du format bmp, il y a peut-être des choses à définir là-dedans pour avoir un comportement plus rigoureux, mais une chose à la fois

Si je trouve un truc, je te tiens évidemment au courant.

Yes yes !

[ThWilliam]

Re-bonjour JP.

Bizarre, bizarre, ton histoire de fichiers bmp !

Je viens de faire un test sous Linux Mint avec un simple TBitmap et en jouant avec quelques Canvas.Pixels.
Enregistrement du bitmap et dans l'éditeur hexa :

mode pf24bit : 3 octets par pixel , codage BGR
mode pf32bit : 4 octets par pixel, codage BGRA (alors que chez toi : RGBA !!!)

La modification de PixelFormat est donc effective ! Cela se vérifie dans les fichiers, que j'ai d'ailleurs lus sans problèmes dans Photoshop. Mais l'affichage écran : rien, rien, rien !!!

Cordialement
Thierry

[Jipété]

Ouaip, c'est encore moi : je touche au but.

J'ai un peu regardé le mode pf24bit sous Lazarus dans Linux, pas dans le code, non, juste à l'écran, à observer ce qui s'affichait en jouant (à peine) sur les paramètres.

D'abord, le bout de code publié en fin de matinée, je l'ai modifié pour travailler en pur 24 bits et avec un petit fichier (plus commode pour l'éditeur hexa), savoir (juste les modifs) :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
const
  WSIZE = 32; // largeur
  HSIZE = 24; // hauteur
 
//  TArrayOfByte = array of TRGBQuad;
  TArrayOfByte = array of TRGBTriple; // raies verticales
 
//        AoB[(h*WSIZE)+w] := RGBAtoQuadBGRA(255, 0, 0, 127);
        AoB[(h*WSIZE)+w] := RGBtoRGBTriple(255, 0, 0);
 
//        Move(AoB[h], bmp.ScanLine[h]^, WSIZE*4);
        Move(AoB[h], bmp.ScanLine[h]^, WSIZE*3);

et ce qui s'affichait, c'était trop parfait (même si faux) pour être un problème aléatoire et pifométrique. Regardez (cette image a été beaucoup zoomée dans Gimp pour bien voir) :


Et comme j'en avais marre de m'user les yeux dans l'éditeur hexa où je voyais bien, en utilisant la première option d'enregistrement (le fs.WriteBuffer), qu'il y avait les bonnes données brutes dans le fichier .bin (que des blocs de 00 00 FF du début à la fin [Wikipédia : Si l'image est codée en 24 bits, chaque pixel est codé par un entier 24 bits (RVB), ordre little-endian, c'est-à-dire que les trois octets codent successivement les niveaux de bleu, vert et rouge.]), j'ai pris le fichier .bmp de l'image ci-dessus (deuxième option, le bmp.SaveToFile), j'ai viré les datas et n'ai gardé que l'en-tête pour remplacer ses données pourries par mon fichier .bin (sous Linux, cat fic.bin >> fic_nettoyé.bmp) et là, victoire !, j'avais un très beau fichier tout rouge !

Conclusion : les mécanismes liés au TBitmap en 24 bits sous Linux sont tout pourris... Je comprends mieux pourquoi j'ai tant miséré ces derniers temps
Je vous dis pas la taille de la bosse sur le front,

[Jipété]

Bonjour,

Je ne résiste pas au plaisir de vous présenter le projet d'études final, rendu un peu joli par la barre de sélection du niveau de transparence, et tout ça fonctionne du feu de Dieu !



Je me suis même amusé à faire générer une image de 1900 x 1100 (c'est presque les limites de mon écran 24") en 3 millisecondes, je ne sais pas si c'est bien-bien ou tout pourri mais en tout cas je suis content.

Pour les puristes, je précise que le dégradé, pour avoir un vrai noir à 0,0,0 en haut à gauche et un vrai blanc à 255,255,255 en bas à droite, s'appuie sur un carré de 256 x 256, et donc, les traits rouge et jaune vous demandez-vous ? Ben le TImage pour l'affichage est dimensionné à 258 de haut et voilà.

Ce que je peux dire, au bout du compte, c'est que ce genre d'image, construite ex nihilo en sachant exactement ce qu'on veut, permet de voir instantanément les moindres défauts d'algorithme, et c'est bien pratique pour corriger des bugs cachés, genre l'affichage était bon en carré mais foirait en rectangle, ou la réapparition des raies verticales (si si ! ) si la largeur de l'image était supérieure à 256 --> mise en œuvre de ratio et de règle de 3 et hop !

Merci de m'avoir lu et supporté, merci pour les conseils (même si certains ne seront pas suivis tout de suite -- Thierry ), à bientôt pour de nouvelles aventures...
Have fun !