Discussion :

[BeanzMaster]

Tout autant cassé, sauf que l'image n'est pas stretchée.

Ca confirme de plus en plus une erreur lors du passage des données vers les apis

[EDIT] Sous Linux le "display" est en 24bits (mais GTK préfére les tampons sur 32bits) du coup lors du passage des données, si le "Depth" est toujours à 32 et qu'il n'y a pas d'ajustement, et c'est la que ca coince

[RE-EDIT] Après revisionnage de mon message avec mes tests. l'erreur n'est peut-être pas de si bas niveau. En y regardant de plus près avec le troisième fichier FondRVB32_xbgr.bmp le Depth est bien à 24 ealors que c'est un 32bits à l'origine.
Ce qui me "chagrine" c'est Avec le dernier et quatrième fichier rgb32bfdef.bmp dans l'image 1 le Depth est à 32 et l'affichage est correcte. Une question me viens à l'esprit est ce que le TPicture et/ou le TImage directement effectuent une correction a ce niveau ?

Pourquoi veux-tu descendre aussi bas ? Ce n'est plus notre problème de simples utilisateurs : quand on constate que la voiture tire à gauche, on l'emmène chez le garagiste, à lui de la passer au banc et de régler le parallélisme.

Pour pouvoir reporté le bug est être le plus précis possible

Ça ne va pas prendre des mois, cette affaire ?

Non, les mises à jour des dépôts de la distro Manjaro, sont plûtot rapide (pour la 1.8.4, si je me souviens elle était dispo moins d'un mois et demi après la sortie officielle)
Et j'ai la flemme de l'installer à la mano.

Cette histoire de largeur divisible par 8 est vraiment louche.

[Jipété]

Ce qui me "chagrine" c'est Avec le dernier et quatrième fichier rgb32bfdef.bmp dans l'image 1 le Depth est à 32 et l'affichage est correct. Une question me vient à l'esprit, est-ce que le TPicture et/ou le TImage directement effectuent une correction à ce niveau ?

Je ne sais pas trop, j'ai un autre truc en tête, tout d'un coup :
si le bitmat du TImage est configuré à pf32 et que j'arrive à l'y maintenir (utilisation des streams ou du couple RawImage.Data et RawImage.DataSize + pByte), l'affichage des fichiers de largeur non divisible par 8 est cassé.
Si par contre le bitmap du TImage est basculé à pf24 alors l'affichage est bon.
Mais c'est ce qu'on voit, au final.
Car en fait le bitmap du TImage est vraiment configuré en amont au moment du Picture.Bitmap.Assign(aBmp) et selon le pixelFormat de ce aBmp, ça passe ou ça casse.

Le aBmp est chargé par la fonction Load vue précédemment, qui utilise probablement mal une TLazInfImage, car je suis tombé hier sur un bout de code russe, qui va peut-être me mettre le pied à l'étrier, dans la mesure où je peux dessiner un bitmap de 250 px de large en pf32 sans raies verticales !

Je vais un peu creuser dans cette direction...

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
procedure TForm1.Button7Click(Sender: TObject);  // http://delphimaster.net/view/15-1296212454/all
var     
 bitmap: Tbitmap;
 a, b:   integer;
  procedure Test(var FBitmap: TBitMap);
  type
   PPixel = ^TPixel;
   TPixel = packed record
     blue, green, red, alpha: byte;
   end;  var
   y: integer;
   RawImage: TRawImage;
   BitmapHandle, MaskHandle: HBitmap; // lcltype
   FData, FFdata: PPixel;
  begin
   ReAllocMem(FData, FBitmap.Width * FBitmap.Height * sizeof(TPixel));
   FFdata := FData;
   /////////////////////////////Здесь можем рисовать
   for y := 0 to FBitmap.Height*fbitmap.Width-1 do
    begin
     FFdata^.red   := 0;
     FFdata^.Green := 0;
     FFdata^.Blue  := 255;
//     FFdata^.alpha := 227;  // add jipété
     FFdata^.alpha   := 127;
//     FFdata^.alpha   := 27;
     Inc(FFdata);
   end;
 
   if (FBitmap.Width > 0) and (FBitmap.Height > 0) then
   begin
     RawImage.Init;
// AV :
     //RawImage.Description.Init_BPP24_B8G8R8_BIO_TTB(FBitmap.Width, FBitmap.Height);
//bleu :
     RawImage.Description.Init_BPP32_B8G8R8A8_BIO_TTB(FBitmap.Width, FBitmap.Height);
//rouge :
     RawImage.Description.Init_BPP32_R8G8B8A8_BIO_TTB(FBitmap.Width, FBitmap.Height);
     RawImage.Description.LineOrder := riloBottomToTop;
     RawImage.Data     := PByte(FData);
     RawImage.DataSize := FBitmap.Width * FBitmap.Height * sizeof(TPixel);
     if not RawImage_CreateBitmaps(RawImage, BitmapHandle, MaskHandle, False) then
       raise FPImageException.Create('Failed to create bitmap handle');
     FBitmap.Handle     := BitmapHandle;
     FBitmap.MaskHandle := MaskHandle;
   end;
 
   FBitmap.Canvas.AntialiasingMode := amOff;
   Freemem(FData);
   FData := nil;
  end;
begin
 a      := GetTickCount;
 bitmap := Tbitmap.Create;
// bitmap.Width  := 1000;
// Bitmap.Height := 1000;
 bitmap.Width  := 250;
 Bitmap.Height := 100;
 Bitmap.PixelFormat := pf32bit;
 //ShowMessage(IntToStr(BitsPerPixel(Bitmap.PixelFormat)));// 24, 32 si dessus forcé
 
 Test(bitmap);
// Canvas.Draw(0, 0, bitmap);
 image3.Picture.Bitmap.Assign(bitmap);
 
 bitmap.Free;
 b := GetTickCount;
 Caption := IntToStr(b - a);
end;

Cette histoire de largeur divisible par 8 est vraiment louche.

Peut-être qu'elle va se régler avec ce qui précède ?

[Jipété]

Le aBmp est chargé par la fonction Load vue précédemment, qui utilise probablement mal une TLazInfImage, car je suis tombé hier sur un bout de code russe, qui va peut-être me mettre le pied à l'étrier, dans la mesure où je peux dessiner un bitmap de 250 px de large en pf32 sans raies verticales !

Je vais un peu creuser dans cette direction...

Alors, une bonne et une mauvaise nouvelle :

- la mauvaise c'est que le tuto qu'on trouve à chaque recherche ggl sur FreePascal +TLazInftImage c'est une grosse bouze tout juste bonne à être jetée. Enfin, la section TLazIntfImage.
Un exemple ?
Je suis parti de leur TLazIntfImage.LoadFromFile mais quand on lit ça, déjà on se dit qu'un soupçon de cohérence serait le bienvenu :

Code :

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

1
2
3
4
// It initializes the TLazIntfImage to a 32bit RGBA format.
begin
  aRawImage.Init;
  aRawImage.Description.Init_BPP32_A8R8G8B8_BIO_TTB(0,0);

Alors, RGBA ou ARGB ? Ça part mal...

Ensuite, en rajoutant un TImage et image1.Picture.Bitmap.LoadFromIntfImage(aImage); inspiré du § suivant (Loading a TLazIntfImage into a TImage) avant le finally, pour voir, ben circulez, justement, y a rien à voir...
Tu parles d'un tuto !

On peut d'ailleurs y lire ensuite

TImage uses the screen format. If the TLazIntfImage has a different format then the pixels will be converted. Hint: You can use IntfImg.DataDescription := GetDescriptionFromDevice(0); to initialize the TLazIntfImage with the screen format.

Mais "ils" ne nous disent pas où insérer cette instruction, donc faut y aller en tâtonnant. Et quand ça tombe en marche et qu'on voit enfin quelque chose en provenance d'un fichier, rien pour indiquer qu'on l'a inséré vraiment au bon endroit...
J'avais posé la question ici en son temps, ça s'était fini en eau de boudin...
Enfin, en enregistrant leur aImage on se retrouve avec un fichier pf24,

En fouillant dans mes vieux dossiers (certains remontent à 2017) j'ai retrouvé plein d'essais qui sentent la misère noire, en partant de ce truc tout moisi. Je sens que je vais tout jeter.

- Bref, la bonne nouvelle c'est que la grande infobulle qui apparaît quand on survole TLazInftImage présente un reader XPM et là, il suffit de remplacer XPM par BMP, d'ajouter une ligne en haut après le Bitmap1:=TBitmap.Create; :

Code :

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

  Bitmap1.PixelFormat := pf32bit; // ajout moi, test rapide

et 3 autres lignes en bas, et je vous laisse admirer mes commentaires :

Code :

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

1
2
3
4
  // do something with the Bitmap1
  Bitmap1.SaveToFile(Application.Location + 'btn4_' +filestring); // pf32 +1 !
  image1.Picture.Bitmap.Assign(Bitmap1);
  image1.Picture.Bitmap.SaveToFile(Application.Location + 'btn4-img_' +filestring); // pf32 +1 !

et voilà !
Mes deux fichiers de test (32bitsKC et chebran) sont parfaitement ouverts, affichés et enregistrés en pf32 !
Yeeeeeeeeeeeeeeeeeeees !

Tout est là :

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
procedure TForm1.Button4Click(Sender: TObject);
var
  BmpHnd,MaskHnd: HBitmap;
  Bitmap1: TBitmap;
  IntfImg1: TLazIntfImage;
//  Reader: TLazReaderXPM;
  Reader: TLazReaderBMP;
  filestring: string;
begin
 filestring := 'bmp_250.bmp';
 filestring := '250x250x32.bmp'; // chebran
// filestring := '32bitsKC_save.bmp';
  // create a bitmap (or use an existing one)
  Bitmap1:=TBitmap.Create;
  Bitmap1.PixelFormat:=pf32bit; // ajout moi
  // create the raw image
  IntfImg1:=TLazIntfImage.Create(0,0);
  // get the description for the current screen (bitsperpixel, depth, ...)
  IntfImg1.DataDescription := GetDescriptionFromDevice(0);
  // create the XPM reader
//  Reader:=TLazReaderXPM.Create;
  Reader:=TLazReaderBMP.Create;
  // load the image
//  IntfImg1.LoadFromFile('filename.xpm',Reader);
  IntfImg1.LoadFromFile(Application.Location + filestring, Reader);
  // create the bitmap handles
  IntfImg1.CreateBitmaps(BmpHnd, MaskHnd, False);
  // apply handles to the Bitmap1
  Bitmap1.Handle:=BmpHnd;
  Bitmap1.MaskHandle:=MaskHnd;
  // clean up
  Reader.Free;
  IntfImg1.Free;
  // do something with the Bitmap1
  Bitmap1.SaveToFile(Application.Location + 'btn4_' +filestring); // pf 32 +1 !
  image1.Picture.Bitmap.Assign(Bitmap1);
  image1.Picture.Bitmap.SaveToFile(Application.Location + 'btn4-img_' +filestring); // pf 32 +1 !
end;

Plus qu'à adapter ma fonction "load" de chargement des fichiers et tester, tester et encore tester,

[Jipété]

EDIT : il y a une erreur dans le code de la fonction présentée plus bas (3^e listing), j'ai trouvé la solution (voir le post suivant), je garde celui-ci comme cas d'école /EDIT

Plus qu'à adapter ma fonction "load" de chargement des fichiers et tester, tester et encore tester,

J'adore le "plus qu'à", ci-dessus...

C'était compter sans la fourberie de l'environnement...

C'est à se demander si on en verra le bout un jour.

Comme je l'ai dit tout à l'heure, j'arrive bien à ouvrir un fichier pf32bit d'une largeur de 250 px et à l'afficher joliment et à l'enregistrer, tout va bien et le fichier enregistré est bien en pf32bit.

Le code qui fait ça :

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
procedure TForm1.Button4Click(Sender: TObject);
var
  b: TBitmap;
  BmpHnd, MaskHnd: HBitmap;
  lii: TLazIntfImage;
  ReaderXPM: TLazReaderXPM;
  ReaderBMP: TLazReaderBMP;
  ReaderTIF: TLazReaderTiff;
  ReaderPNG: TLazReaderPNG;
  //ReaderJPG n'existe pas, utiliser le "FastLoad"
  filestring: string;
begin
  filestring := 'bmp_250.bmp';
  filestring := '250x250x32.bmp';
  filestring := '32bitsKC_save.bmp';
 
  b := TBitmap.Create;
  b.PixelFormat:=pf32bit;
  // pas besoin des dimensions, on dirait
  lii:=TLazIntfImage.Create(0,0); // create the raw image
  lii.DataDescription := GetDescriptionFromDevice(0);
  ReaderBMP:=TLazReaderBMP.Create;
  lii.LoadFromFile(Application.Location + filestring, ReaderBMP);
  ShowMessage(StringReplace(lii.DataDescription.AsString, ' ', LineEnding, [rfReplaceAll]));
  lii.CreateBitmaps(BmpHnd, MaskHnd, False);
  // apply handles to the Bitmap
  b.Handle     := BmpHnd;
  b.MaskHandle := MaskHnd;
  // clean up
  ReaderBMP.Free;
  lii.Free;
  // do something with the Bitmap
//  b.SaveToFile(Application.Location + 'btn4_' +filestring); // pf 32 +1 !
  image1.Picture.Bitmap.Assign(b);
//  image1.Picture.Bitmap.SaveToFile(Application.Location + 'btn4-img_' +filestring); // pf 32 +1 !
  if b <> nil then FreeAndNil(b);
end;

Maintenant, ce code j'aimerais le couper en deux :
- une partie ihm (nom du fichier, affichage du résultat) et
- une fonction technique qui va faire ce qu'il y a entre les deux morceaux de la ligne précédente.

Après une petite session d'éditeur de texte, ça devient ça :

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
procedure TForm1.Button5Click(Sender: TObject);
var
  filestring: string;
begin
  filestring := 'bmp_250.bmp';
  filestring := '250x250x32.bmp';
  filestring := '32bitsKC_save.bmp';
 
// tout ce qui était là dégage dans une fonction qui 
// va recevoir le nom complet de fichier et renvoyer le bitmap
 
  // do something with the Bitmap
  image1.Picture.Bitmap := LoadFile(Application.Location + filestring); // appel de la fonction en lui passant le nom du fichier
  // pf24 si passage par fonction ! <<< et ça c'est la cata !
  image1.Picture.Bitmap.SaveToFile(Application.Location + 'btn5-img_' +filestring); // pf 24
end;

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
function LoadFile(f: string): TBitmap;
var
  BmpHnd, MaskHnd: HBitmap;
  lii: TLazIntfImage;
  ReaderBMP: TLazReaderBMP;
  function GetBitCount(f: string): integer;
  var
    bs: TBytesStream;
  begin
    GetBitCount := 0;
    bs := TBytesStream.Create;
    bs.LoadFromFile(f);
    bs.Position:=28; // biBitCount @1C
    GetBitCount := bs.ReadWord;
    bs.Free;
  end;
begin
  RESULT := TBitmap.Create;
  case GetBitCount(f) of
    24 : RESULT.PixelFormat := pf24bit;
    32 : RESULT.PixelFormat := pf32bit;
    else begin
      ShowMessage('Erreur de "pixelformat" avec le fichier '
        + ExtractFilename(f) + ', impossible de continuer.');
      Exit;
    end;
  end;
  // pas besoin des dimensions, on dirait
  lii := TLazIntfImage.Create(0,0); // create the raw image
  lii.DataDescription := GetDescriptionFromDevice(0);
  ReaderBMP := TLazReaderBMP.Create;
  lii.LoadFromFile(f);
  lii.CreateBitmaps(BmpHnd, MaskHnd, False);
  // apply handles to the Bitmap
  RESULT.Handle     := BmpHnd;
  RESULT.MaskHandle := MaskHnd;
  // clean up
  ReaderBMP.Free;
  lii.Free;
end;

Pourquoi le RESULT perd son pf32 alors qu'en pas-à-pas c'est bien 32 qui est détecté, choisi, etc.

Dans le button4 (tout-en-un), je rajoute une ligne de log :

Code :

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

1
2
3
4
  // apply handles to the Bitmap
  b.Handle     := BmpHnd;
  b.MaskHandle := MaskHnd;
  b.SaveToFile(Application.Location + 'btn4-bmp_' +ExtractFilename(Application.Location + filestring));// pf32

Là le bitmap est bien en pf32.
Dans la fonction appelée par le button5 je fais la même chose :

Code :

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

1
2
3
4
  // apply handles to the Bitmap
  RESULT.Handle     := BmpHnd;
  RESULT.MaskHandle := MaskHnd;
  RESULT.SaveToFile(Application.Location + 'btn5-in-func_' +ExtractFilename(f));// pf24

et là pas de bol, c'est du pf24.

Alors je dégaine la commande qui tue, ShowMessage(StringReplace(lii.DataDescription.AsString, ' ', LineEnding, [rfReplaceAll]));, utilisée juste après le chargement du fichier dans lii (je ne montre que les différences) :
button4, tout dans le bouton

Code :

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

1
2
3
Depth=32
AlphaPrec=8
AlphaShift=24

button5, qui appelle la fonction qui va ouvrir le fichier

Code :

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

1
2
3
Depth=24
AlphaPrec=0
AlphaShift=0

Moi je pète un câble, là...
Quelqu'un saura réparer ça ?

[Jipété]

J'ai trouvé !

Il s'est glissé une microscopique différence suite à un malencontreux couper/coller, à un endroit limite invisible, et découvert en comparant mot à mot la fonction fautive avec une autre toute fraîche dérivée du Button4 et parfaitement fonctionnelle.

Code :

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

1
2
3
4
// La ligne coupable :
  lii.LoadFromFile(f);
// La ligne correcte
  lii.LoadFromFile(f, ReaderBMP);

Hé bien croyez-moi, cette simple ligne planquée au milieu de plein d'autres avec plein de lignes en commentaires aussi, m'aura occupé toute la journée ou presque.

Et comme il n'y avait pas de message d'erreur ni d'information à la compilation et pas plus à l'exécution, je m'étais concentré sur tout sauf sur cette ligne.

Désolé pour le dérangement.

[BeanzMaster]

Salut

Le aBmp est chargé par la fonction Load vue précédemment, qui utilise probablement mal une TLazInfImage, car je suis tombé hier sur un bout de code russe, qui va peut-être me mettre le pied à l'étrier, dans la mesure où je peux dessiner un bitmap de 250 px de large en pf32 sans raies verticales !

Dans TGifViewer j'utilise un truc dans le même genre pour exporter les frame vers un TBitmap (Regardes, le RawImage.Description.Init_?????, incohérent non ?)

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
Function TFastBitmap.BuildBitmap: Graphics.TBitmap;
Var
  Temp : Graphics.TBitmap;
  IntfBmp : TLazIntfImage;
  ImgFormatDescription: TRawImageDescription;
  W,H,X,Y : Integer;
  SrcPix : PColor32;
Begin
 
  (* /!\ Le code si dessous fonctionne parfaitement sous Windows et Mac.
     Mais sous Linux ce code produit des erreur au niveau de la transparence
 
    BmpHandle := 0;
    MskHandle := 0;
    W := FWidth;
    H := FHeight;
    Buffer := PByte(GetSurfaceBuffer);
 
    RawImage.Init;
    {$IFDEF WINDOWS}
    RawImage.Description.Init_BPP32_B8G8R8A8_BIO_TTB(W,H);
    {$ELSE}
    RawImage.Description.Init_BPP32_R8G8B8A8_BIO_TTB(W,H);
    {$ENDIF}
 
    RawImage.Data := Buffer;
    RawImage.DataSize := FSize;
 
    if not RawImage_CreateBitmaps(RawImage, BmpHandle, MskHandle,False) then
      Raise Exception.Create('Impossible de créer le TBitmap')
    else
    begin
      Temp := Graphics.TBitmap.Create;
      Temp.Width := W;
      Temp.Height := H;
      Temp.PixelFormat := pf32bit;
      Temp.Handle := BmpHandle;
      Temp.MaskHandle := MskHandle;
      Temp.Transparent := True;
      //Temp.TransparentColor := FTransparentColor;
      //temp.TransparentMode := tmAuto;
      Result := Temp;
    End;
  *)
 
  Result := nil;
 
  W := FWidth;
  H := FHeight;
 
  // Pour que la transparence soit gérée correctement sous Linux on est obligé de passer par TLazIntfImage
  IntfBmp := TLazIntfImage.Create(W,H);
  ImgFormatDescription.Init_BPP32_B8G8R8A8_BIO_TTB(W, H);
  IntfBmp.DataDescription := ImgFormatDescription;
 
  SrcPix := Self.GetSurfaceBuffer;
  For Y:=0 to H-1 do
    For X:=0 to W-1 do
    begin
      IntfBmp.Colors[x, y]:=SrcPix^.ToFPColor;
      inc(SrcPix);
    end;
 
  begin
    Temp := Graphics.TBitmap.Create;
    Temp.LoadFromIntfImage(IntfBmp);
    Result := Temp;
    IntfBmp.Free;
  End;
  if Result = nil then
    Raise Exception.Create(rsBitmapCreateError);
End;

Ensuite pour pouvoir importer un bitmap j'avais fait comme ça (Test du RedShift pour savoir les données sont en RGB ou BGR suivant l'OS)

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
Function TFastBitmap.ImportFromRawImage(Const ARawImage: TRawImage): Boolean;
var
  BufferData : PByte;
begin
  SetSize(ARawImage.Description.Width,ARawImage.Description.Height);
  result:=false;
  // On verifie si la taille des deux tampons sont identique
  // Si ce n'est pas le cas, cela veut dire que le TRawImage n'est pas au format 32bit
  if (ARawImage.DataSize= FSize) then
  begin
    try
      BufferData := PByte(Self.getSurfaceBuffer);
      Move(ARawImage.Data^, BufferData^, self.Size);
      {$IFDEF WINDOWS}
        if (ARawImage.Description.RedShift = 0) and ((ARawImage.Description.BlueShift = 16)) then Self.SwapRB; // Le RawImage est-il en RGB, si oui on échange
      {$ELSE}
        if (ARawImage.Description.RedShift = 16) and ((ARawImage.Description.BlueShift = 0)) then Self.SwapRB; // Le RawImage est-il en BGR, si oui on échange
      {$ENDIF}
    finally
      result:=true;
    end;
  end;
End;
 
Function TFastBitmap.ImportFromBitmap(Const ABitmap: Graphics.TBitmap): Boolean;
var
  LTempBitmap: Graphics.TBitmap;
  ok,ResetAlpha:Boolean;
 
  procedure SetAlpha(Value : Byte);
  var
    i : Integer;
    PixPtr : PColor32;
    maxi : Integer;
  begin
    i:=0;
    Maxi := (FWidth * FHeight)-1;
    PixPtr :=PColor32(FData);// Self.GetScanLine(0);
    While i<Maxi do
    begin
      PixPtr^.Alpha:= Value;
      inc(PixPtr);
      inc(i);
    end;
  end;
 
begin
  ResetAlpha:=False;
  result:=false;
  if (ABitmap.PixelFormat <> pf32bit)  then
  begin
    LTempBitmap := Graphics.TBitmap.Create;
    try
      ResetAlpha:=True;
      LTempBitmap.SetSize(ABitmap.Width, ABitmap.Height);
      LTempBitmap.PixelFormat := pf32bit;
      LTempBitmap.Canvas.Draw(0, 0, ABitmap);
    finally
      ok:=Self.ImportFromRawImage(LTempBitmap.RawImage);
      if ResetAlpha then SetAlpha(255);
      FreeAndNil(LTempBitmap);
      result:=true and (ok);
    end;
  end
  else
  begin
   ok:=Self.ImportFromRawImage(ABitmap.RawImage);
   result:=true and (ok);
  end;
End;

Moi je pète un câble, là...
Quelqu'un saura réparer ça ?

La différence que j'ai noté c'est dans le Button4 tu utilises image1.Picture.Bitmap.Assign(b); et que dans le Button5 tu utilises image1.Picture.Bitmap := LoadFile(....);

J'ai trouvé !

Il s'est glissé une microscopique différence suite à un malencontreux couper/coller, à un endroit limite invisible, et découvert en comparant mot à mot la fonction fautive avec une autre toute fraîche dérivée du Button4 et parfaitement fonctionnelle.

Code :

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

1
2
3
4
// La ligne coupable :
  lii.LoadFromFile(f);
// La ligne correcte
  lii.LoadFromFile(f, ReaderBMP);

Hé bien croyez-moi, cette simple ligne planquée au milieu de plein d'autres avec plein de lignes en commentaires aussi, m'aura occupé toute la journée ou presque.

Et comme il n'y avait pas de message d'erreur ni d'information à la compilation et pas plus à l'exécution, je m'étais concentré sur tout sauf sur cette ligne.

Désolé pour le dérangement.

Le fait d'indiquer le Reader voudrait donc, peut-être dire que le problème vient du "ReaderBMP" utilisé (celui de FPC ou de Lazarus) Mais cela ne résout pas le problème de la copie de Image1-->BmpTemp-->Image2 avec des images en 32bits (j'ai essayé avec des PNG avec transparence donc bien 32bits) et l'affichage reste foireux dans l'image2. Il y a donc bien quelques choses qui cloche (qui manque) dans le code avec Linux à ce niveau. (vu avec TGIFViewer cf commentaire du code plus haut à ce sujet)


Bon dimanche

[Jipété]

Yop !

Bon dimanche

Ouais merci, mais c'est mal barré on dirait.

Après ma réussite dans le projet de l'autre discussion où on peut voir un magnifique gif en action, je copie/colle la fonction qui va bien dans le projet d'ici et ça ne fonctionne plus, c'est aussi simple que ça !
Il n'y a que deux lignes rajoutées, les 2 .SaveToFile pour voir de quoi il retourne à l'éditeur hexa :

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
function GetBitCount(f: string): integer;
var
  bs: TBytesStream;
begin
  GetBitCount := 0;
  bs := TBytesStream.Create;
  bs.LoadFromFile(f);
  bs.Position := 28; // biBitCount @1C
  GetBitCount := bs.ReadWord;
  bs.Free;
end;
 
function TForm1.LoadFile(f: string): TBitmap;
var
  BmpHnd, MaskHnd: HBitmap;
  lii: TLazIntfImage;
  ReaderBMP: TLazReaderBMP;
begin
  if b = nil then b := TBitmap.Create;
  case GetBitCount(f) of
    24 : b.PixelFormat := pf24bit;
    32 : b.PixelFormat := pf32bit; // je passe bien ici en pas-à-pas
    else begin
      ShowMessage('Erreur de "pixelformat" avec le fichier '
        + ExtractFilename(f) + ', impossible de continuer.');
      Exit;
    end;
  end;
  // pas besoin des dimensions, on dirait
 
  lii := TLazIntfImage.Create(0,0); // create the raw image
  lii.DataDescription := GetDescriptionFromDevice(0);
  ReaderBMP := TLazReaderBMP.Create;
  lii.LoadFromFile(f, ReaderBMP);  //
  lii.SaveToFile('/chemin/lii.bmp'); // magnifique 24bit :-(
  lii.CreateBitmaps(BmpHnd, MaskHnd, False);
  // apply handles to the Bitmap
  b.Handle     := BmpHnd;
  b.MaskHandle := MaskHnd;
  // clean up
  ReaderBMP.Free;
  lii.Free;
  RESULT := b; // détruit par l'appelant
  b.SaveToFile('/chemin/b.bmp'); // magnifique 24bit :-(
end;

C'est vraiment une horreur, tout ça : qu'est-ce qu'il peut bien y avoir dans projet2 qui mette sa pagaille alors que tout va bien avec projet1, dans la mesure où LoadFile est chaque fois appelé de la même manière par un bouton ?

[BeanzMaster]

Ton 24bits c'est à cause de lii.DataDescription := GetDescriptionFromDevice(0); (le display sous Linux est 24bits)

Donc si tu charges une image 32bits, à la place il essayes d'utiliser, comme dans mon bout de code

Code :

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

1
2
3
4
5
6
7
8
 
Var
  IntfBmp : TLazIntfImage;
  ImgFormatDescription: TRawImageDescription; // si je me souviens bien c'est important de passer par cette variable intermédiaire, au lieu d'utiliser directement TLazIntfImage.DataDescription
begin
  IntfBmp := TLazIntfImage.Create(W,H);
  ImgFormatDescription.Init_BPP32_B8G8R8A8_BIO_TTB(W, H); // ou Init_BPP32_R8G8B8A8_BIO_TTB(W, H); en fonction des données charger (Pour le format BMP c'est BGR)
  IntfBmp.DataDescription := ImgFormatDescription;

Et la encore, il faut bien faire attention au format BGR ou RGB d'origine

[Jipété]

Ton 24bits c'est à cause de lii.DataDescription := GetDescriptionFromDevice(0); (le display sous Linux est 24bits)

Non !
Car tout ça vient du test copié/collé depuis l'infobulle quand tu mets la souris sur TLazIntfImage, tout bêtement.

Et je viens de faire un nouveau test à l'instant, juste avec ce qu'il y a dessous, sans rien enregistrer en termes de projet (du coup ça travaille dans le dossier /tmp) et ça fonctionne :



Tu le vois, le "20", au bout de la 2^e ligne ? Il veut dire "pf32" alors copie/colle tout ça dessous, mets un fichier dans /tmp, F9 et clique et dis-nous :

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
84
85
86
87
88
89
90
uses
  LCLIntf, LCLType,
  Classes, SysUtils, FileUtil, Forms, Controls, Graphics, Dialogs, ExtCtrls,
  IntfGraphics, // lii
  Graphtype, // rawimage
  FPImage, // russe
  Buttons, StdCtrls;
 
type
 
  { TForm1 }
 
  TForm1 = class(TForm)
    Button1: TButton;
    Image1: TImage;
    procedure Button1Click(Sender: TObject);
  private
    { private declarations }
    b:  TBitmap;
    function LoadFile(f: string): TBitmap;
  public
    { public declarations }
  end;
 
var
  Form1: TForm1;
 
implementation
 
{$R *.lfm}
 
{ TForm1 }
 
function GetBitCount(f: string): integer;
var
  bs: TBytesStream;
begin
  GetBitCount := 0;
  bs := TBytesStream.Create;
  bs.LoadFromFile(f);
  bs.Position := 28; // biBitCount @1C
  GetBitCount := bs.ReadWord;
  bs.Free;
end;
 
function TForm1.LoadFile(f: string): TBitmap;
var
  BmpHnd, MaskHnd: HBitmap;
  lii: TLazIntfImage;
  ReaderBMP: TLazReaderBMP;
begin
  if b = nil then b := TBitmap.Create;
  case GetBitCount(f) of
    24 : b.PixelFormat := pf24bit;
    32 : b.PixelFormat := pf32bit;
    else begin
      ShowMessage('Erreur de "pixelformat" avec le fichier '
        + ExtractFilename(f) + ', impossible de continuer.');
      Exit;
    end;
  end;
  // pas besoin des dimensions, on dirait
 
  lii := TLazIntfImage.Create(0,0); // create the raw image
  lii.DataDescription := GetDescriptionFromDevice(0);
  ReaderBMP := TLazReaderBMP.Create;
  lii.LoadFromFile(f, ReaderBMP);  //
  lii.CreateBitmaps(BmpHnd, MaskHnd, False);
  // apply handles to the Bitmap
  b.Handle     := BmpHnd;
  b.MaskHandle := MaskHnd;
  // clean up
  ReaderBMP.Free;
  lii.Free;
  RESULT := b; // détruit par l'appelant
end;
 
procedure TForm1.Button1Click(Sender: TObject);
var
  filestring: string;
begin
  filestring := '250x250x32.bmp';
  //filestring := '32bitsKC_save.bmp';
  b:= LoadFile(Application.Location + filestring);
  b.SaveToFile(Application.Location + 'test_' + filestring);
  image1.Picture.Bitmap.Assign(b);
  if b <> nil then FreeAndNil(b);
end;
 
end.

[Jipété]

Mettez votre navigateur en grande largeur et admirez (oui, un jour je me suis bricolé un petit viewer à base de synedit) à gauche le projet qui fonctionne, à droite celui qui foire :

d'abord l'appel de la fonction



puis la fonction



Moi je ne vois pas de différence, à part les machins strictement fonctionnels dans le bouton à gauche...

[tourlourou]

Problème d'ordre des uses et l'une des variables aurait un type différent ? Il faudrait comparer en passant le curseur sur les 2 versions, ou préfixer par le nom d'unité quand ambiguïté possible.

Sinon, le code ne gagnerait-il pas à prendre une forme du style :

Code :

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

1
2
3
4
5
6
7
8
9
function LoadFileInBitmap(aFile: TFileName; var aBitMap: TBitmap): Boolean;
begin
  Result := False;
  if aBitmap is TBitmap then
    aBitmap.Clear // ou Assign(nil) ?
  else 
    aBitMap := TBitmap.Create;
  //...
end;

[Jipété]

Bonjour Yves, et merci de venir jouer avec nous,

Problème d'ordre des uses

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
// le projet qui va bien 
uses
  LCLIntf, LCLType,
  Classes, SysUtils, FileUtil, Forms, Controls, Graphics, Dialogs, ExtCtrls,
  IntfGraphics, // lii
  Graphtype, // rawimage
  FPImage, // russe
  Buttons, StdCtrls;
 
// le projet à souci
uses
  LCLIntf, LCLType,
  Classes, SysUtils, FileUtil, Forms, Controls, Graphics, Dialogs, ExtCtrls,
  IntfGraphics, // lii
  Graphtype, // rawimage
  FPImage, // russe
  StdCtrls, ExtDlgs, ComCtrls;

La grosse différence, là, c'est le Buttons en haut absent en bas, alors je l'ai rajouté mais ça ne change rien, et je ne peux pas trop enlever les deux derniers, nécessaires pour un trackbar et l'openpicturedialog.

et l'une des variables aurait un type différent ? Il faudrait comparer en passant le curseur sur les 2 versions, ou préfixer par le nom d'unité quand ambiguïté possible.

Tout est strictement identique...

Sinon, le code ne gagnerait-il pas à prendre une forme du style

En fait, je vais m'inspirer de ce que fait efg (réduit à l'essentiel) :

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
PROCEDURE TFormFRR.ModifyOriginalImage;
VAR
  bmpRotate     :  TBitmap; // créé dans RotateScanLine
BEGIN
  bmpRotate := RotateScanLine(rdgRotation.ItemIndex*90, bmpFlipReverse);
  imgModified.Picture.Graphic := bmpRotate;
  bmpRotate.Free
END
 
FUNCTION RotateScanLine(CONST angle: INTEGER; CONST src: TBitmap): TBitmap;
BEGIN
  RESULT := TBitmap.Create;
  RESULT.PixelFormat := src.PixelFormat;  // only pf24bit for now
  RESULT.Width       := src.Width;
  RESULT.Height      := src.Height;
  RESULT.BeginUpdate();
  // ...
  RESULT.EndUpdate();
END {RotateScanline};

J'aime bien cette manière simple,

[Jipété]

Arrêtez de chercher et de perdre votre temps !

Le problème est encore dans le code Lazarus/FreePascal et pas dans nos misérables petites lignes, car ça dépend des fichiers...

À gauche 4 fichiers utilisés comme sources, à droite les 4 mêmes une fois passés à travers la fonction.



Effectivement, avec le 250x250x32 qui posait tant de soucis hier, il n'y en avait plus ce matin, donc roule ma poule. Mais c'était sans compter sur certains autres, qui sont traités bizarrement par les "internals" du code.

Bref, je devrais avoir 20 (pour pf32) partout et vous voyez en haut à droite les deux premiers ça le fait pas (pf24), et qu'y puis-je ?
--->> et surtout, je suis tombé là-dessus par hasard ! <<---

Au premier coup d'œil, on dirait que Lazarus/FreePascal n'aime pas les fichiers avec une version 5 (ou 4, je ne sais pas exactement, faut que j'étudie ça mais là j'en ai marre) du BitmapInfoHeader (le 7A presque au bout de la 1^re ligne des 2 premiers fichiers à gauche).

EDIT : version 4 si 6C @ 0E (version 5 c'est 7C), non visible dans la grande image dessus, à cause du recouvrement des images de test.


Je creuserai...

[tourlourou]

Hier, je lisais rapidement le code de TLazReaderBMP et TLazReaderDIB dans intfgraphics.pas. Il faudrait pê faire un outil établissant les différences entre ce qu'on lit de l'en-tête du bitmap et ce qu'en lit TLazReaderDIB.InternalReadHead ou transforme TLazReaderDIB.InternalRead (cf. ci-dessous la partie conditionnée par FUpdateDescription).

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
procedure TLazReaderDIB.InternalRead(Stream: TStream; Img: TFPCustomImage);
var
  Desc: TRawImageDescription;
  Depth: Byte;
begin
  FContinue := True;
  Progress(psStarting, 0, False, Rect(0,0,0,0), '', FContinue);
  FImage := TheImage as TLazIntfImage;
  FIgnoreAlpha := True;
  Depth := 0;
  InternalReadHead; // voir qq lignes avec des conjectures (toujours vérifiées ?) ligne 5735 et suivantes
 
  if FUpdateDescription // qui le sette ?
  then begin
    if (Info.BitCount = 32) and (Info.MaskSize.A = 0)
    then Depth := 24 // je comprends pourquoi, mais en quoi cela influe-t-il ensuite sur les traitements ?
    else Depth := Info.BitCount;
    DefaultReaderDescription(Info.Width, Info.Height, Depth, Desc);
    FImage.DataDescription := Desc;
  end;
 
  InternalReadBody;
 
  // if there is no alpha in real (all alpha values = 0) then update the description
  if FUpdateDescription and FIgnoreAlpha and (Depth = 32) then
  begin
    Desc.AlphaPrec:=0;
    FImage.SetDataDescriptionKeepData(Desc);
  end;
 
  Progress(psEnding, 100, false, Rect(0,0,0,0), '', FContinue);
end;

Mais ce sont des points que vous avez pê déjà vérifié : j'ai beau tout lire, je ne retiens pas tout !

[Jipété]

Mais ce sont des points que vous avez pê déjà vérifié : j'ai beau tout lire, je ne retiens pas tout !

Il est marrant ton post parce que quand ma messagerie m'a fait "ding dong !", j'avais les mains au même endroit !

dans ReadHead je suis content parce que je fais la même chose :

Code :

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

1
2
3
var
  BIH: TBitmapInfoHeader;
  BCH: TBitmapCoreHeader;

plus loin, ça, ça a l'air correct
5715

Code :

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

1
2
3
4
5
6
7
8
9
10
11
  if BIH.biSize >= 108
  then begin
    // at least a V4 header -> has alpha mask, which is always valid (read other masks too)
    TheStream.Read(FDibInfo.PixelMasks, 4 * SizeOf(FDibInfo.PixelMasks.R));
    GetMaskShiftSize(FDibInfo.PixelMasks.A, FDibInfo.MaskShift.A, FDibInfo.MaskSize.A);
  end
  else begin
    // officially no alpha support, but that breaks older LCL compatebility
    // so add it
    // blabla, mais je ne suis pas d'accord avec le commentaire ci-dessus puisqu'on peut trouver/créer des v1-32 bits
  end;

à la fin

Code :

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

1
2
  if Info.MaskSize.A <> 0 {Info.BitCount = 32}
  then CheckAlphaDescription(TheImage);

qui peut faire passer par AddAlphaToDescription où ADesc.Depth := 32;, donc je ne vois pas pourquoi mes deux fichiers v4 remontent en pf24...

Hier, je lisais rapidement le code de TLazReaderBMP et TLazReaderDIB dans intfgraphics.pas. Il faudrait pê faire un outil établissant les différences entre ce qu'on lit de l'en-tête du bitmap et ce qu'en lit TLazReaderDIB.InternalReadHead ou transforme TLazReaderDIB.InternalRead (cf. ci-dessous la partie conditionnée par FUpdateDescription).

Comment tu verrais ça ?
Et tu penses qu'on aurait accès aux données private et protected, qui seront plus intéressantes que les public qui nous envoient dans le mur ?


Me suis souvenu d'un vieux hack pour afficher correctement à partir d'un bitmap déjà chargé par bmp.LoadFromFile :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
    lii := TLazIntfImage.Create(0,0);
    try
      if GetOffsetToDatas(Pict.bitmap) = 54 then begin // synonyme de VersionHeader = 1
        lii.DataDescription := GetDescriptionFromDevice(0);
        lii.LoadFromFile(f);
      end else  // 70, 122 pour bgra, 138 pour xbgr, n/a pour jpg et d'autres encore
        lii.LoadFromBitmap(Pict.bitmap.Handle, Pict.bitmap.Handle, Pict.bitmap.Width, Pict.bitmap.Height);
 
      RESULT.LoadFromIntfImage(lii); // renvoie un bitmap "bien" rempli mais en pf24 si pf32 en entrée
    finally
      lii.Free;
    end;

mais je ne vois pas comment je pourrais l'adapter à la configuration du nouveau projet, puisque le fichier ne sera chargé que par TLazIntfImage.

En attendant, on n'est pas loin... On tourne autour du pot... Vais essayer avec du pas à pas dans intfgrapics et autres classesh.inc
Si je suis pas revenu dans 2 heures, prévenez les secours, avec une longue corde,

[BeanzMaster]

Non !
Car tout ça vient du test copié/collé depuis l'infobulle quand tu mets la souris sur TLazIntfImage, tout bêtement.

Quelles sont les valeurs chez toi de Depth et BitsPerPixel dans le lii.DataDescription après l'avoir initialiser avec GetDescriptionFromDevice(0); ?

Arrêtez de chercher et de perdre votre temps !

Le problème est encore dans le code Lazarus/FreePascal et pas dans nos misérables petites lignes, car ça dépend des fichiers...

Ca on le savais !

Hier, je lisais rapidement le code de TLazReaderBMP et TLazReaderDIB dans intfgraphics.pas. Il faudrait pê faire un outil établissant les différences entre ce qu'on lit de l'en-tête du bitmap et ce qu'en lit TLazReaderDIB.InternalReadHead ou transforme TLazReaderDIB.InternalRead (cf. ci-dessous la partie conditionnée par FUpdateDescription).

Le code ne tiens pas compte des différentes versions des headers du format BMP, il ne se sert que de l'en-tête commune soit la version 1. Le reste n'est qu'un jeu de calcul plus ou moins exactes.
du coup par rapport à ce qu'a dit Jipete

Au premier coup d'œil, on dirait que Lazarus/FreePascal n'aime pas les fichiers avec une version 5 (ou 4,

C'est pour cela que certains fichiers sont mal interprétés, il y a des erreurs de décodage "BIT_FIELD"

à la fin

Code :

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

1
2
  if Info.MaskSize.A <> 0 {Info.BitCount = 32}
  then CheckAlphaDescription(TheImage);

qui peut faire passer par AddAlphaToDescription où ADesc.Depth := 32;, donc je ne vois pas pourquoi mes deux fichiers v4 remontent en pf24...

C'est bien cette fonction dont je parlais un peu plus haut, qui met en vrac, certains fichiers BMP 32bits et qui les fait passer pour des 24bits. Cette fonction m'avait posé d'ailleurs posé un gros problème de compréhension lorsque j'avais codé mon "Reader" pour ma solution

De plus il est clair qu'il y a un soucis général sous LINUX avec les Bitmaps 32bits lors de leur création et/ou lors de l'assignation. le Depth et le BitsPerpixel ne sont plus en adéquation avec les données

cf : mon post plus haut avec TGIFViewer et ce que je disais des tests de copie fait avec des PNG transparent

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
(* /!\ Le code si dessous fonctionne parfaitement sous Windows et Mac.
     Mais sous Linux ce code produit des erreur au niveau de la transparence
 
    BmpHandle := 0;
    MskHandle := 0;
    W := FWidth;
    H := FHeight;
    Buffer := PByte(GetSurfaceBuffer);
 
    RawImage.Init;
    {$IFDEF WINDOWS}
    RawImage.Description.Init_BPP32_B8G8R8A8_BIO_TTB(W,H);
    {$ELSE}
    RawImage.Description.Init_BPP32_R8G8B8A8_BIO_TTB(W,H);
    {$ENDIF}
 
    RawImage.Data := Buffer;
    RawImage.DataSize := FSize;
 
    if not RawImage_CreateBitmaps(RawImage, BmpHandle, MskHandle,False) then
      Raise Exception.Create('Impossible de créer le TBitmap')
    else
    begin
      Temp := Graphics.TBitmap.Create;
      Temp.Width := W;
      Temp.Height := H;
      Temp.PixelFormat := pf32bit;
      Temp.Handle := BmpHandle;
      Temp.MaskHandle := MskHandle;
      Temp.Transparent := True;
      //Temp.TransparentColor := FTransparentColor;
      //temp.TransparentMode := tmAuto;
      Result := Temp;
    End;
  *)

Pour rappel dans la description le Depth correspond au format de couleur du pixel et le bitsperpixel correspond à la taille de stockage du pixel dans le tampon. Donc Bitmap.PixelFormat = Depth
D'ou cette sans cesse confusion dans la gestion des bitmaps avec Lazarus.

Ce que je ne comprend pas c'est pourquoi les développeurs décisionnels du projet Lazarus persistent dans cette voie avec les bitmaps. Je pense que c'est du à l'ampleur du travail de tout revoir, car la gestion même des graphiques est a la base de pratiquement tous les WIDGETS (affichage des compos visuels) De plus, si on compares avec les codes source de Delphi, la gestion interne des bitmap est codée de façon nettement plus simple et fiable.

Petites questions qui me vient à l'esprit, je me demande si le code de CodeTyphon dans les unité IntGraphic, Graphics est exactement le même ? Comment se comporte le code que j'ai fourni lors de mes test, sous Linux avec CodeTyphon ? Le résultat est-il le même avec les fichiers 32bits après copie ? voit-ont cet horrible décalage ?

[Jipété]

Quelles sont les valeurs chez toi de Depth et BitsPerPixel dans le lii.DataDescription après l'avoir initialiser avec GetDescriptionFromDevice(0); ?

J'étais en train de préparer ma réponse quand "ça a sonné", , donc lire un peu plus bas...

Si je suis pas revenu dans 2 heures, prévenez les secours, avec une longue corde,

Je ressors du gouffre :

on passe x (voir dessous) fois dans CheckAlphaDescription et à chaque fois if Desc.AlphaPrec >= 8 then Exit; et je sors

Si je commence un run avec un fichier sans souci, j'y passe 6 fois !
Si je commence un run avec un fichier avec souci, j'y passe 5 fois.
ensuite,
si je clique sur un avec souci, je n'y passe pas.
si je clique sur un sans souci, j'y passe 1 fois.

Et tout ça est bien régulier et rejouable.


J'ai ensuite noté des infos depuis la fonction :

Code :

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

1
2
3
4
5
6
7
  lii := TLazIntfImage.Create(0,0); // create the raw image
memo1.Lines.Add('1 '+StringReplace(lii.DataDescription.AsString, ' ', LineEnding, [rfReplaceAll]));
  lii.DataDescription := GetDescriptionFromDevice(0);
memo1.Lines.Add('2 '+StringReplace(lii.DataDescription.AsString, ' ', LineEnding, [rfReplaceAll]));
  ReaderBMP := TLazReaderBMP.Create;
  lii.LoadFromFile(f, ReaderBMP);
memo1.Lines.Add('3 '+StringReplace(lii.DataDescription.AsString, ' ', LineEnding, [rfReplaceAll]));

Le BitsPerPixel est partout à 32, et voilà les autres résultats (je n'ai gardé que les différences) :

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
fichier avec header v1 (avec défaut, donc)
1 tout à 0
 
2 après GetDescriptionFromDevice(0)
HasMask->False
Depth=24 <<<<<<<<<<<<<<<< pas bon !
AlphaPrec=0
AlphaShift=0
~~~mask~~~
MaskBytesPerLine->0
 
3 après LoadFromFile : on a les dimensions
HasMask->False et pourtant il y a 24
Depth=24 <<<<<<<<<<<<<<<< pas bon !
AlphaPrec=0
AlphaShift=0
~~~mask~~~
MaskBytesPerLine->24
 
++++++++++++++++++++++++++++++++++++++++
fichier avec header v4 tout bon
 
1 tout à 0
 
2 identique au fichier v1
 
3 après LoadFromFile : on a les dimensions
HasMask->False et pourtant il y a 32
Depth=32 diff !
BitsPerPixel=32
AlphaPrec=8 diff !
AlphaShift=24 diff !
~~~mask~~~
MaskBytesPerLine->32 diff !
 
dans tous les résultats, on a
RedPrec=8
RedShift=16
GreenPrec=8
GreenShift=8
BluePrec=8
BlueShift=0

C'est pour cela que certains fichiers sont mal interprétés, il y a des erreurs de décodage "BIT_FIELD"

Euh non, regarde mon 2^nd bout de code du post précédent, qui commence par if BIH.biSize >= 108, dans intfGraphics c'est du côté de 5685, il y est bien question de BI_RGB.

Dernier test :
point d'arrêt dans AddAlphaToDescription, ligne 810 :
run avec v1 : on n'y passe pas
run avec v4 : on y passe et c'est là qu'on bascule Depth à 32.

Plus qu'à trouver/comprendre où/pourquoi Depth arrive à 24.

[Jipété]

post 58, bientôt 60...

Bon, ça ira comme ça pour aujourd'hui, j'en ai grave ma claque, là.

J'ai trouvé une combine (merci à toi, Jérôme, je me marre car on tourne en rond, à la fin : Je cherche une info sur le web et sur qui je tombe ? https://forum.lazarus.freepascal.org...topic=41674.15 )

Bref, en fin de matinée j'avais deux fichiers pas bons, ce soir je n'en ai plus qu'un ! Et si l'on considère qu'il est enregistré en pf32bit, ce n'est plus qu'une histoire d'affichage, mais là j'en peux plus...


Faut dire aussi qu'avec ses dimensions barbares, je n'arrange pas les choses. Mais ça doit passer !

La solution consiste donc à récupérer la version du header, à faire un case dessus et mettre ça :

Code :

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

1
2
3
4
5
6
7
8
9
  procedure Setup_V1; // la manière d'origine, qui ne supporte pas les headers V4
  begin
    lii := TLazIntfImage.Create(0,0); // create the raw image
    lii.DataDescription := GetDescriptionFromDevice(0);
  end;
  procedure Setup_V4; // depuis la proc à Jérôme -- merci à toi, ça ne s'invente pas, des paramètres comme ça
  begin
    lii := TLazIntfImage.Create(0,0,[riqfRGB, riqfAlpha, riqfMask])
  end;

Un dernier mot avant de plier : pendant que je parcourais les fichiers .pas, je suis tombé sur ça (je ne sais plus si c'est dans graphtype ou un autre, on s'en fiche), et je l'ai noté car ça m'a fait peur, au niveau du commentaire, 2^de phrase :

Code :

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

1
2
function  GetDataLineStart(y: integer): Pointer;
  // similar to Delphi TBitmap.ScanLine. Only works with lines aligned to whole bytes.

Ou alors c'est comme bien souvent comme partout, c'est mal dit ? Pour moi, ça n'a pas de sens, lines aligned to whole bytes : depuis quand des lignes ne seraient pas alignées sur des bytes entiers ? Qu'est-ce qu'ils ont voulu dire ?
Parce que dans la vraie vie, avec les pf24bit il y a le padding pour nous sauver la vie et l'alignement, et pour le pf32bit avec donc 4 bytes par pixel, il n'y a pas de problème.

Sauf avec ma Lena à 397 de large,
Mais ce matin elle s'affichait pourtant bien, au prix d'en enregistrement en pf24, parfaitement inadmissible pour la suite, ah mais !

:

[tourlourou]

Pardonnez ma paresse, mais je ne sais plus trop où vous en êtes, et je crains de ne pas bien y coller en reprenant tous les posts de cette discussion (voire d'autres...).

Bref, je peux faire des tests avec CT 6.4 sous Ubuntu 18.04 avec widgetset gtk2, mais si vous pouviez me fournir les portions de code à tester et des images OK et KO, ce serait parfait ! Que ce soit sur le forum, ou par mail.

[Jipété]

Bonsoir,

Bref, je peux faire des tests avec CT 6.4 sous Ubuntu 18.04 avec widgetset gtk2, mais si vous pouviez me fournir les portions de code à tester et des images OK et KO, ce serait parfait ! Que ce soit sur le forum, ou par mail.

un fichier avec les 4 images qui ont servi à générer les fichiers dont on voit ici le contenu hexa : 4images.zip

et le code là, je te laisse compléter ce qui manque, c'est-à-dire quasiment rien, et en prime tu as l'image de la fiche utilisée, avec son bouton et son TImage.
Il faudra rajouter les noms des deux fichiers absents.

Le but de la manip est d'examiner les fichiers générés par le code pour voir si on peux avoir ces quatre fichiers en mode 32 bits (20 à l'adresse 1C).

Merci à toi de tes tests.