Discussion :

[BeanzMaster]

Moi avec C++/ Delphi Embarcadero j'avais trouvé le truc : utiliser Graphics32 (*) qui propose un TImage32 dont tu as un accès rapide à sa mémoire (via scanline si je ne dis pas de bêtises, c'est à dire sans mutex)

Et ensuite, moi c'était différent par rapport à vous parce que je n'avais pas besoin d'ouvrir d'images externes : que des images embarquées des .pam compressées en .bz2 et sans entête (que les données brutes en somme)
Et j'avais trouvé sur StackOverflow l'algo pour afficher 2 surfaces (1 en dessous, 1 au dessus) avec des transparences différentes

Avec mon approche , il faudrait faire comme soit BeanzMaster et coder tous les algos format image soit faire confiance aux bibliothèques reconnues (libpng, libtiff, ...)


* -> La documentation de Graphics32 est tout aussi dégueulasse parce qu'il y a une histoire de couches (layers), dont la documentation te vante leurs mérites, mais je n'ai jamais trouvé un code complet qui les utilisent

Exacte. Graphic32 est pas mal du tout aussi comme bibliothèque malheureusement elle n'est pas totalement compatible avec Lazarus
Utilisé les bibliothèques reconnues j'y ai pensé mais je ne veux pas trop dépendances externe j'ai déja Freetype2, OpenAL, VorbisOgg, mpg123 c'est déja pas mal

Tiens un truc qui va te faire rigolé Jipete Juste un truc avec ton FondRVB.Bmp qui s'affiche mal Avec mon test à l'arrache :

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
91
92
93
94
95
96
97
98
99
100
101
Unit Unit1;
 
{$mode objfpc}{$H+}
 
Interface
 
Uses
  Classes, SysUtils, FileUtil, Forms, Controls, Graphics, Dialogs, ExtCtrls, StdCtrls, ExtDlgs;
 
Type
 
  { TForm1 }
 
  TForm1 = Class(TForm)
    Button1: TButton;
    Button2: TButton;
    Image1: TImage;
    Image2: TImage;
    OPD: TOpenPictureDialog;
    Procedure Button1Click(Sender: TObject);
    Procedure Button2Click(Sender: TObject);
    Procedure FormDestroy(Sender: TObject);
  private
 
  public
     SrcBmp, DstBmp : TBitmap;
  End;
 
Var
  Form1: TForm1;
 
Implementation
 
{$R *.lfm}
 
{ TForm1 }
 
Procedure TForm1.FormDestroy(Sender: TObject);
Begin
  FreeAndNil(SrcBmp);
  //FreeAndNil(DstBmp);
end;
 
Procedure TForm1.Button1Click(Sender: TObject);
Begin
  if OPD.Execute then
  begin
    if not(Assigned(SrcBmp)) then SrcBmp := TBitmap.Create;
    SrcBmp.LoadFromFile(OPD.FileName);
 
    ShowMessage(SrcBmp.RawImage.Description.AsString);
    Image1.Picture.Bitmap.Assign(SrcBmp);
  End;
end;
 
Procedure TForm1.Button2Click(Sender: TObject);
Var
  i, x,y : Integer;
  SrcPtr, DstPtr : PByte;
 
Begin
  DstBmp := TBitmap.Create;
  //DstBmp.PixelFormat := pf24bit;
  DstBmp.Width := SrcBmp.Width;
  DstBmp.Height := SrcBmp.Height;
  //if dstBmp.PixelFormat = pf24Bit then ShowMessage('pf24bit');
  //if dstBmp.PixelFormat = pf32bit then ShowMessage('pf32bit');
  ShowMessage(DstBmp.RawImage.Description.AsString);
  //DstBmp.RawImage.Description.init_BPP24_R8G8B8_BIO_TTB(SrcBmp.Width,SrcBmp.Height);
  //Init_BPP24_B8G8R8_BIO_TTB(SrcBmp.Width,SrcBmp.Height);
  //ShowMessage(DstBmp.RawImage.Description.AsString);
  For y := 0 to SrcBmp.Height-1 do
  begin
    SrcPtr := SrcBmp.RawImage.GetLineStart(y);
    DstPtr := DstBmp.RawImage.GetLineStart(y);
    For x:=0 to SrcBmp.Width-1 do
    begin
      For i:=0 to 2 do
      Begin
         DstPtr^ := SrcPtr^;
         Inc(SrcPtr);
         Inc(DstPtr);
      End;
      if (DstBmp.RawImage.Description.BitsPerPixel = 32) then
      begin
        if (SrcBmp.RawImage.Description.BitsPerPixel = 32) then
        begin
          DstPtr^ := SrcPtr^;
          inc(SrcPtr);
        end;
        Inc(DstPtr);
      end;
    End;
  End;
 
 
  Image2.Picture.Bitmap.Assign(DstBmp);
  FreeAndNil(DstBmp);
end;
 
End.

Résultat = Affichage Natif 0 , Affichage de la copie du Bitmap 1

[BeanzMaster]

Suffisamment à faire avec ce qu'on découvre au quotidien, et là ça fait deux heures que je suis dessus mais faire afficher un TImage dans un TPanel génère une différence de positionnement à gauche de 1 px et de largeur de 2 px si la source des pixels est un TLazIntfImage, par rapport à un bête TBitmap...

Un truc de malade avec peut-être une copie d'écran (mais + tard).
Je ne m'en sortirai pas de ces machins de malades...

C'est clair, pas le temps pour ça. Ton histoire de décalage c'est peut-être a cause d'un TRect si tu en utilises un. Tout dépend de comment TLazIntfImage et TBitmap les utilises eux et ce n'est peut-être plus en adéquation

Tu fais un Canvas.Draw ? ou autre chose StretchDraw" ? CopyRect ?

[mm_71]

Jipété:
C'est dans quel fichier de log tes infos ?

Dans Menu Administration -> Journaux Système -> Xorg.0.log

[Jipété]

@Jipété : coucou, voici un petit exemple d'utilisation de pointeur en récupérant celui de la zone mémoire du flux :

On peut aussi faire ses propres méthodes qui mettront la bonne endianité, ou convertiront un pixel 32 bits en pixel 24 bits ou autre.

Un énorme merci, Yves !
Je verrai ça demain matin, et pour ta seconde ligne, oui, c'est l'idée (encore un peu floue mais ça se précisera en avançant).

Moi avec C++/ Delphi Embarcadero j'avais trouvé le truc : utiliser Graphics32 (*) qui

Et sous Linux tu peux complètement l'oublier, mais merci d'être venu,

Tiens un truc qui va te faire rigoler Jipete Juste un truc avec ton FondRVB.Bmp qui s'affiche mal Avec mon test à l'arrache :

Ah, les traits le retour,

C'est clair, pas le temps pour ça. Ton histoire de décalage c'est peut-être a cause d'un TRect si tu en utilises un. Tout dépend de comment TLazIntfImage et TBitmap les utilises eux et ce n'est peut-être plus en adéquation

Tu fais un Canvas.Draw ? ou autre chose StretchDraw" ? CopyRect ?

Non, rien de tout ça. Je crois vous l'avoir déjà montré :

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
    try
      if OffsetToDatas = 54 then begin // 122 pour le argb, 138 pour le xbgr
        lii := TLazIntfImage.Create(0,0);
        lii.DataDescription:=GetDescriptionFromDevice(0);
        lii.LoadFromFile(f);
      end else with bmpSRC do begin
        lii := CreateIntfImage;
        lii.LoadFromBitmap(Handle, Handle, Width, Height);
      end;
      with imgSRC do begin
        Picture.Clear;
        Picture.Bitmap.LoadFromIntfImage(lii);
      end;
    finally
      lii.Free;
    end;

Mais en fait je me suis embrouillé quelque part, j'ai trouvé la blague et tout va bien maintenant de ce côté. Le souci est plutôt avec des choses genre TControlBorderSpacing, je vous dis pas comme ça plante !
Passer Around de 0 où tout va bien à 4, et tout est mort...

Dans Menu Administration -> Journaux Système -> Xorg.0.log

Ah merci !

Code :

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

1
2
3
4
# cat /var/log/Xorg.0.log | grep Depth
[    14.645] (==) RADEON(0): Depth 24, (--) framebuffer bpp 32
[    14.872] (--) Depth 24 pixmap format is 32 bpp
#

Mais on n'est pas fauché avec ça...

Et sur ce, merci à tous et buena notte,

[mm_71]

Encore 2 trucs importants ou pas ?



Et:

Chaque ligne de l'image doit comporter un nombre total d'octets qui soit un multiple de 4; si ce n'est pas le cas, la ligne doit être complétée par des 0 de telle manière à respecter ce critère.

https://www.commentcamarche.com/cont...bmp-format-bmp

[Jipété]

Encore 2 trucs importants ou pas ?

Salut,

Concernant l'espace de couleur, j'avoue n'avoir pas fait de tests approfondis, ce que j'ai vu à l'éditeur hexa c'est que ça génère des fichiers de type "28" soit BitmapInfoHeader version 1, et àmha une appli pas capable d'ouvrir ce type de fichier, à notre époque, tu la prends tu la jettes.

Chaque ligne de l'image doit comporter un nombre total d'octets qui soit un multiple de 4; si ce n'est pas le cas, la ligne doit être complétée par des 0 de telle manière à respecter ce critère.

Oui, c'est le fameux et célèbre "padding", pas de souci.
Note : ça ne concerne donc pas les lignes avec des pixels de 32 bits (et sans doute 4, 8 et 16 mais je n'ai jamais fait de tests dessus).

Sinon, Le lien manque d'infos :
au début,

• CP indique qu'il s'agit d'un pointeur de couleur OS/2.
• PT indique qu'il s'agit d'un pointeur OS/2.

C'est quoi un pointeur (de couleur) OS/2 ? Jamais entendu parler...

Puis il y a une rubrique fausse par omission :

La taille de l'entête de l'image en octets (codée sur 4 octets). Les valeurs hexadécimales suivantes sont possibles suivant le type de format BMP :

• 28 pour Windows 3.1x, 95, NT, ...
• 0C pour OS/2 1.x
• F0 pour OS/2 2.

Z'ont juste oublié 4 autres valeurs déterminant la version du BitmapInfoHeader (extrait d'un code à moi) :

Code :

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

1
2
3
4
5
       28: Result.VersionHeader:=1;
       34: Result.VersionHeader:=2;
       38: Result.VersionHeader:=3;
       6C: Result.VersionHeader:=4;
       7C: Result.VersionHeader:=5;

et ce "pour" dans leur texte m'énerve, il n'a pas de sens.

Enfin, tout en bas, dans

Codage de l'image

il manque juste les images en 32 bits avec le canal alpha (paquets de bytes b-g-r-a dans le fichier) ou anonyme et non utilisé (quoique...), paquets x-b-g-r dans le fichier.
Rien que ça !

En gros, là on a le drame de l'internet dans toute sa splendeur, où n'importe qui peut publier n'importe quoi et sans plus jamais le mettre à jour.
Et comme il n'y a pas de date de publication, on ne sait pas si ça remonte à 3 semaines ou 20 ans...
Le temps qu'on passe, là aussi, à trier le bon du mauvais, c'est terrible.
Si j'étais taquin, je dirais qu'on est à la limite de la fake news, non ?

Bon, allez, au code, qu'il fait frais,

[Jipété]

Bon, allez, au code, qu'il fait frais,

et déjà une première question pour Yves :

dans ton code, je relève (à peine adapté, pour la lisibilité) :

Code :

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

1
2
3
4
5
  PosDate := 202;
  P := Flux.Memory;  // je récupère le pointeur sur la zone mémoire du flux
  Inc(P, PosDate);   // je l'avance à la date EXIF
  D1 := StrPas(P);
  SetLength(D1, 19); // car #0 en 20ème position

c'est quoi la différence avec

Code :

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

1
2
  Flux.Position := PosDate;
  D1 := Flux.ReadAnsiString;

Parce qu'une fois compilés avec un compilo efficace et performant, ces deux bouts devraient donner le même code machine, non ?

Par exemple, l'aide à propos de ReadAnsiString nous dit que

This is a utility function which simply calls the read function several times.

Et comme ça de proche en proche en s'enfonçant dans les tréfonds du code jusqu'à l'assembleur illisible,

Quelqu'un a déjà fait des tests de timing poussés, dans ce domaine ?

[Jipété]

Concernant l'espace de couleur, j'avoue n'avoir pas fait de tests approfondis, ce que j'ai vu à l'éditeur hexa c'est que ça génère des fichiers de type "28" soit BitmapInfoHeader version 1, et àmha une appli pas capable d'ouvrir ce type de fichier, à notre époque, tu la prends tu la jettes.

Donc je prends l'appli sur laquelle je suis en train de suer sang et eau et... je la jette !

Car j'ai terminé la première des deux parties un poil compliquées, à savoir la copie d'un fichier 24 bits vers un 32 bits et ça fonctionne tip-top sauf qu'en demandant

Code :

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

1
2
bmpDST := TBitmapCreate;
bmpDST.PixelFormat := pf32bit;

si la structure créée est correcte, il s'agit d'un BitmapInfoHeader version 1 et imgDST.Picture.Bitmap.Assign(bmpDST); n'affiche rien alors que le bête viewer de Linux me dit que je n'ai pas perdu mon temps ce matin :

Code :

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

1
2
3
4
5
6
7
8
      for h := 0 to jpb.Height-1 do begin // pour chaque ligne, -- "jpb" c'est mon bitmap header perso dérivé des vrais après leur lecture (à terme ça devrait disparaître -- ou pas)
        for w := 0 to (jpb.LineSize - jpb.Padding)-1 do begin // recopier les bytes
          msDst.WriteByte(msSrc.ReadByte); // les streams avancent automatiquement, cool
          if ( (w + 1) mod 3 = 0) then // tous les 3 bytes en rajouter un
            msDst.WriteByte(100); // 100 pour tester la transp 
        end;
        for p := 1 to jpb.Padding do aByte := msSrc.ReadByte; // avancer en lisant le padding
      end;

Va falloir que je passe par TLazIntfImage, qui sait gérer ça (étudié il y a 3 semaines environ, déjà proposé qqpart ici).

Un dernier mot concernant la transparence : le viewer de Linux ne la gère pas avec cette version de header, pas plus que le TLazIntfImage, mais The Gimp oui !
Donc mon fichier est bon, donc le snippet ci-dessus aussi, ouf !

Plus que la copie 32 vers 24, ça devrait être plus simple, je la garde pour demain,

[Jipété]

Fouhhh, y a que moi qui cause, ce matin,
J'espère ne pas trop vous saouler...

Deux minutes sur la transparence, parce que même Gimp me joue des tours...



En bas le fichier issu de ma recopie à coups de TMemoryStreams après création ex nihilo d'un bitmap en v1 concernant son InfoHeader.
L'image animée bascule entre l'ouverture dans The Gimp où l'on voit bien les carrés matérialisant la transparence, et l'ajout d'un calque blanc sous le calque de l'image pour bien montrer l'effet de transparence.
Pour enfoncer le clou, en arrière-plan la vision hexa du fichier, les datas commencent à droite du coin inférieur droit de l'imagette Gimp (89), et la valeur de transparence est 78, on repère vite les colonnes de 78, tous les 4 bytes.

Le gag vient d'en haut, où l'on voit l'ouverture du fichier créé par l'export du fichier du bas sans avoir touché la transparence et avant l'ajout du calque (qui ne change rien à l'affaire).
On voit bien que les datas sont les mêmes (89 et suivantes) et que la transparence est là (colonnes 78), mais elle n'est pas rendue.

La différence entre les deux fichiers ? Celui du haut incorpore les informations de couleur (6C en 0E₁₆ vs 28).

Alors pour ne pas mourir idiot, je reprends dans Gimp le fichier d'origine issu de ma copie et je le re-exporte sans les informations de couleurs et là je génère un fichier strictement identique au mien, et l'ouverture avec Gimp montre les carrés de transparence comme avec le mien.

Tout va donc bien, sauf que d'un point de vue purement intellectuel, j'aurais mieux compris de voir les carrés de transparence avec les informations de couleurs plutôt que sans.
Pas vous ?

PS : en orange l'information 32 bits par pixel.

[BeanzMaster]

C'est quoi un pointeur (de couleur) OS/2 ? Jamais entendu parler...

Pointeur = curseur souris

et déjà une première question pour Yves :

dans ton code, je relève (à peine adapté, pour la lisibilité) :

Code :

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

1
2
3
4
5
  PosDate := 202;
  P := Flux.Memory;  // je récupère le pointeur sur la zone mémoire du flux
  Inc(P, PosDate);   // je l'avance à la date EXIF
  D1 := StrPas(P);
  SetLength(D1, 19); // car #0 en 20ème position

c'est quoi la différence avec

Code :

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

1
2
  Flux.Position := PosDate;
  D1 := Flux.ReadAnsiString;

Quelqu'un a déjà fait des tests de timing poussés, dans ce domaine ?

Oui déjà fais des tests, mais tu te rend compte de la différence que sur de très grande quantité de données. Par exemple sur le chargement de très grosse image Lazarus utilise les Stream pour lire les données et moi je passe par un tampon (comme ici P) Le résultat est 2 à 3 fois et plus rapide suivant les dimensions et le format d'image. (pour les jpeg c'est idem, vu que j'utilise le même code. Mais pour le BMP, XPM, TGA, PCX là il n'y a pas photo.
Dans celui du haut tu manipule directement les données qui sont mise en mémoire. L'accès en lecture (ou écriture) via un le pointeur, ici "P" est beaucoup plus rapide que d'utiliser "Flux" directement.

Donc je prends l'appli sur laquelle je suis en train de suer sang et eau et... je la jette !

Car j'ai terminé la première des deux parties un poil compliquées, à savoir la copie d'un fichier 24 bits vers un 32 bits et ça fonctionne tip-top sauf qu'en demandant

Code :

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

1
2
bmpDST := TBitmapCreate;
bmpDST.PixelFormat := pf32bit;

Sous Linux pas besoin de bmpDST.PixelFormat := pf32bit le bitsPerPixel est par défaut 32. C'est RawImage.Description.Depth qu'il faut vérifier qu'il soit bien à 32. Là je suis sous Windows je peux pas affirmer.

Plus que la copie 32 vers 24, ça devrait être plus simple, je la garde pour demain,

Sous Linux le problème ne se posera pas tu n'aura jusqu'à copier les même données. Et clai qu'il faut mieux utiliser TLazIntfImg qui te permettras de bien mieux initialiser l'image et surtout correctement c'est à dire RawImgae.Description.Depth = 24 et RawImage.Description.BitsPerPixel = 24

Fouhhh, y a que moi qui cause, ce matin,

Le gag vient d'en haut, où l'on voit l'ouverture du fichier créé par l'export du fichier du bas sans avoir touché la transparence et avant l'ajout du calque (qui ne change rien à l'affaire).
On voit bien que les datas sont les mêmes (89 et suivantes) et que la transparence est là (colonnes 78), mais elle n'est pas rendue.

As tu essayé d'ajouter un calque dessous ? et ton fichier c'est un XRGB ? ou RGBA ?

Alors pour ne pas mourir idiot, je reprends dans Gimp le fichier d'origine issu de ma copie et je le re-exporte sans les informations de couleurs et là je génère un fichier strictement identique au mien, et l'ouverture avec Gimp montre les carrés de transparence comme avec le mien.

Tout va donc bien, sauf que d'un point de vue purement intellectuel, j'aurais mieux compris de voir les carrés de transparence avec les informations de couleurs plutôt que sans.
Pas vous ?

PS : en orange l'information 32 bits par pixel.

La version d'en-tête est important pour la lecture des masques RGB(A). Sont-il identiques dans les 2 versions ? de même que le format des pixels XRGB ou RGBA ? . Cela peux influencer l'affichage de la transparence

[mm_71]

La version d'en-tête est important pour la lecture des masques RGB(A). Sont-il identiques dans les 2 versions ? de même que le format des pixels XRGB ou RGBA ? . Cela peux influencer l'affichage de la transparence

Avec gimp c'est XRGB, ARGB reste grisé chez moi et RGBA absent. ( LM 18.3 )

[BeanzMaster]

Avec gimp c'est XRGB, ARGB reste grisé chez moi et RGBA absent. ( LM 18.3 )

Oups ! RGBA = ARGB. Il reste grisé car tu n'as pas de calque transparent

[Jipété]

As-tu essayé d'ajouter un calque dessous ?

L'image animée bascule entre l'ouverture dans The Gimp où l'on voit bien les carrés matérialisant la transparence, et l'ajout d'un calque blanc sous le calque de l'image pour bien montrer l'effet de transparence.

Le gag vient d'en haut, où l'on voit l'ouverture du fichier créé par l'export du fichier du bas sans avoir touché la transparence et avant l'ajout du calque (qui ne change rien à l'affaire).
On voit bien que les datas sont les mêmes (89 et suivantes) et que la transparence est là (colonnes 78), mais elle n'est pas rendue.

et ton fichier c'est un XRGB ? ou RGBA ?

Simplement en regardant les images des éditeurs, on voit bien que la répartition des bytes est C C C 4 (C pour B ou G ou R, les bytes de couleurs, et 4 pour dire 4^e byte) donc... donc ??? donc BGRA,

La version d'en-tête est importante pour la lecture des masques RGB(A). Sont-il identiques dans les 2 versions ? de même que le format des pixels XRGB ou RGBA ? . Cela peux influencer l'affichage de la transparence

La différence entre les deux fichiers ? Celui du haut incorpore les informations de couleur (6C en 0E₁₆ vs 28).

Donc v4 versus v1.

Pas grave, ça doit être cette chaleur démente...

[BeanzMaster]

Le gag vient d'en haut, où l'on voit l'ouverture du fichier créé par l'export du fichier du bas sans avoir touché la transparence et avant l'ajout du calque (qui ne change rien à l'affaire).
On voit bien que les datas sont les mêmes (89 et suivantes) et que la transparence est là (colonnes 78), mais elle n'est pas rendue.

Mon Gimp ne fonctionne pas de la même façon avec un BMP version 1.0 contenant de la transparence. A l'ouverture identique que toi pas de gestion de la transparence. Gimp charge et voit le BMP comme un 24 bits et les infos de transparence disparaissent. A l'export je n'ai donc que XRGB de dispo.

Dans un sens c'est normal que gimp ne tienne pas compte de la transparence avec les BMP version 1.0 car suivant les spécifications officielles le BMP Version 1 ne gère pas la transparence. La gestion de la transparence à été introduite qu'à partir de la version 3.

[Jipété]

Plus que la copie 32 vers 24, ça devrait être plus simple, je la garde pour demain,

Bonjour, on est demain !

Matière à réflexion : j'ai terminé ma procédure de copie utilisant les streams, ça fonctionne du feu de Dieu, source avec ou sans information de couleur en 24 ou 32 bpp et destination en 24 ou 32 bpp, je génère donc 8 fichiers (vus là dans l'explorateur en mode aperçu) qui tous s'ouvrent avec le viewver de Linux ainsi qu'avec Gimp.

aidc pour avec information de couleur et sidc sans.
Bien.

La catastrophe arrive quand je veux les faire afficher dans le TImage de contrôle, exemple avec la copie d'un 32 bpp sidc vers un 32 bpp, une copie à l'identique, donc, et pourtant, vous voyez dans l'outil de copie la source à gauche et sa copie à droite.



(Ne tenez pas compte des bandes colorées verticales, utiles pour moi en construction des panels)

Comme le fichier copié est parfait (le viewer de Linux dans le bandeau blanc, dessous), j'en conclus que c'est le TImage qui met sa pagaille, et je pensais contourner ce défaut en utilisant le TLazIntfImage (puisqu'après tout je l'utilise déjà pour la source).

Mais la source est un fichier et, même si pour les tests la copie en génère un, j'aurais préféré m'en passer et j'ai donc à ma disposition le TBitmap dans lequel je ne vois pas trop comment lire le header si je n'ai pas de fichier, ou le TMemryStream que j'envisage d'utiliser ainsi :

Code :

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

1
2
3
4
5
6
7
8
        lii := bmpDST.CreateIntfImage;
        lii.DataDescription:=GetDescriptionFromDevice(0);
        msDst.Position:=0;
        lii.LoadFromStream(msDst);
        with imgDST do begin
          Picture.Clear;
          Picture.Bitmap.LoadFromIntfImage(lii);
        end;

qui pourrait bien fonctionner si ce n'était ces messages sortis de l'Enfer de Dante ou plutôt, de l'exécution de lii.LoadFromStream(msDst); (les 3 à la suite),




complètement loufoques puisqu'après eux, une bonne image de la copie est bien affichée à droite !

Vous noterez l'à-propos de ces messages, dans la mesure où je me cantonne au monde des bmp's. Qui a dit que certains bouts de code étaient écrits avec les pieds ?

Alors si quelqu'un sait comment s'affranchir de ces messages vraiment mal venus, qu'il l'écrive vite vite vite !
Merci,

[BeanzMaster]

Salut

Bonjour, on est demain !

La catastrophe arrive quand je veux les faire afficher dans le TImage de contrôle, exemple avec la copie d'un 32 bpp sidc vers un 32 bpp, une copie à l'identique, donc, et pourtant, vous voyez dans l'outil de copie la source à gauche et sa copie à droite.

Comme le fichier copié est parfait (le viewer de Linux dans le bandeau blanc, dessous), j'en conclus que c'est le TImage qui met sa pagaille, et je pensais contourner ce défaut en utilisant le TLazIntfImage (puisqu'après tout je l'utilise déjà pour la source).

Oui c'est le TBitmap. C'est comme avec FondRVB à l'affichage c'est foireux après copie des données l'affichage est correcte (cf mon poste plus haut)

EDIT : On l'avais déja vu Lazarus le prend pour un 24 bits et gère donc l'affichage en ce sens alors qu'il ne devrait pas. Si je me souviens bien c'est l'alphaSize/AlphaShift qui sont erronés dans ce cas dans le RawImage.Description

Mais la source est un fichier et, même si pour les tests la copie en génère un, j'aurais préféré m'en passer et j'ai donc à ma disposition le TBitmap dans lequel je ne vois pas trop comment lire le header si je n'ai pas de fichier, ou le TMemryStream que j'envisage d'utiliser ainsi :

Code :

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

1
2
3
4
5
6
7
8
        lii := bmpDST.CreateIntfImage;
        lii.DataDescription:=GetDescriptionFromDevice(0);
        msDst.Position:=0;
        lii.LoadFromStream(msDst);
        with imgDST do begin
          Picture.Clear;
          Picture.Bitmap.LoadFromIntfImage(lii);
        end;

qui pourrait bien fonctionner si ce n'était ces messages sortis de l'Enfer de Dante ou plutôt, de l'exécution de lii.LoadFromStream(msDst); (les 3 à la suite),

complètement loufoques puisqu'après eux, une bonne image de la copie est bien affichée à droite !
....
Alors si quelqu'un sait comment s'affranchir de ces messages vraiment mal venus, qu'il l'écrive vite vite vite !
Merci,

As tu les unités FPReadBMP, FPWriteBMP dans les uses ? Vue que c'est un stream il ne peux pas deviner le format d'image il teste donc les signatures une à une.
Pour lire les infos du TBitmap, elle sont extraites lors du chargement du fichier, et c'est dans TRawImage.Description tu n'as pas le choix. Le soucis comme on l'a vu avec "fondRBV" et le fichier que tu viens de générer les infos peuvent être erronées (Depth,BitsPerPixel, et AlphaShift, AlphaSize) d'ou l'affichage foireux. Par contre je ne pense pas que TLazIntfImage résolve ce problème. C'est dans le "Reader BMP" que semble être le soucis.

Vous noterez l'à-propos de ces messages, dans la mesure où je me cantonne au monde des bmp's. Qui a dit que certains bouts de code étaient écrits avec les pieds ?

Pas moi !

[Jipété]

As-tu les unités FPReadBMP, FPWriteBMP dans les uses ? Vu que c'est un stream il ne peux pas deviner le format d'image il teste donc les signatures une à une.

Même pas besoin !

J'ai eu une intuition : j'ai essayé hors EDI et là ce fut tout bon pour les 8 essais ! Alors je suis retourné dans l'EDI, j'ai relancé, j'ai coché les cases "Ignorer ce type d'exception" et, ma foi, ça fonctionne tip-top, même après un arrêt-redémarrage de l'EDI.
Trop bien !

Plus qu'à fignoler les panneaux d'affichage puis terminer mon générateur de headers et mon bonheur sera complet,

Merci à tous,

PS : pour être raccord avec le titre de la discussion, à un moment j'ai fait un test pour voir si je remarquais une différence entre les fichiers, à coups de ShowMessage(StringReplace(bmpDST.RawImage.Description.AsString, ' ', LineEnding, [rfReplaceAll]));,
et voilà ce que j'ai noté :
// le truc qui sert à rien ! Aucune différence entre les fichiers mal affichés et les fichiers bien affichés !

Alors soyons clairs : peut--être que dans mon dos et sans rien me dire le code généré par des trucs genre

Code :

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

1
2
    bmpDst:= TBitmap.Create; // header v1 --> pas glop
    if ckbx24D.Checked then bmpDst.PixelFormat:=pf24bit else bmpDst.PixelFormat:=pf32bit;

y fait appel, mais ça ne dépasse pas ce niveau, après j'exploite les headers des fichiers à lire à grands coups de streams et ça va très bien comme ça !

[Jipété]

Comme on en avait parlé, je reviens dessus.

Voilà les codes :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
  function IdenticalCopy(ident: string): boolean; // avec les streams, 1 seule ligne utile
  begin
    Result := False;
    try
      msSrc.Position:=0;
 
      msDst.LoadFromStream(msSrc);
 
      msDst.Position:=0;
      dst.LoadFromStream(msDst);
      Result := True;
    finally
    end;
  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
  function IdenticalCopyWithP(ident: string): boolean; // avec les pointeurs, il faut 8 lignes
  var
    PS,PD: pByte;
    i: integer;
  begin
    Result := False;
    try
      msSrc.Position:=0;
 
      msDst.Position:=0;
      PS := msSrc.Memory; 
      PD := msDst.Memory; 
      for i:=0 to msSrc.Size-1 do begin
        PD^ := PS^;
        inc(PS);
        inc(PD);
      end;
 
      msDst.Position:=0;
      dst.LoadFromStream(msDst);
      Result := True;
    finally
    end;
  end;

Et voilà les résultats :

Code :

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

1
2
3
4
5
 800x600x32 mode stream   copie en 226 nanosec 
            mode pointeur copie en 217 nanosec
 
1280x960x32 mode stream   copie en 552 nanosec 
            mode pointeur copie en 554 nanosec

Au vu de ces résultats, je n'ai pas l'intention de convertir les deux autres procédures de copie (24->32 et 32->24), je subodore que les résultats seront + ou - identiques, et pourquoi ?
Mais tout simplement parce que travailler avec des flux est une vision humaine, un arrangement cosmétique pour nous faciliter la vie du coding, mais au bout du compte et en sortie de compilo, là où le code généré va directement faire fonctionner la machine, il n'y a plus de notions de streams et autres machins de haut niveau, il n'y a plus que des registres qui stockent des données et des instructions pour les manipuler.

Même le célèbre pointeur, le truc écrit avec le chapeau (pType^), on ne le retrouvera pas dans un code binaire.
Alors bon, ne pas se compliquer la vie s'il n'y a quasiment rien à gagner, c'est ma devise.

Par contre, sous XP tout ça est loin d'être gagné : un bête 24 bpp avec des dimensions toutes simples, 800x600, et bim !

[BeanzMaster]

Pour les pointeurs tu as plus simple vu que tu copie la totalité des données

Code :

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

1
2
3
4
5
6
7
8
9
10
 function IdenticalCopyWithP(ident: string): boolean; // avec les pointeurs, il faut 8 lignes
  begin
    Result := False;
    try
      move(msSrc.Memory^, msDst.Memory^, msSrc.Size) ; //msSrc.Read(msDst.Memory^,msSrc.Size);      
      dst.LoadFromStream(msDst);      
    finally
       Result := True;
    end;
  end;

Seulement 1 ligne de code également

[Jipété]

Bonjour,

Pour les pointeurs tu as plus simple vu que tu copie la totalité des données

Seulement 1 ligne de code également

D'un strict point de vue d'écriture dans l'EDI, parce qu'on ne m'ôtera pas de l'idée que d'un point de vue machine, le compilateur sur cette ligne va générer des instructions à la manière du mode multi-lignes. Comment pourrait-il en être autrement ?

Et je déconseille de faire Ctrl-Clic sur move, au risque de se perdre dans des kilomètres de lignes en assembleur totalement illisibles pour le commun des mortels.

Et tout ça pour ça :

Code :

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

1
2
3
4
5
6
7
 800x600x32 mode stream   copie en 226 nanosec 
            mode pointeur copie en 217 nanosec
            mode 1 ligne  copie en 215 nanosec
 
1280x960x32 mode stream   copie en 552 nanosec 
            mode pointeur copie en 554 nanosec
            mode 1 ligne  copie en 621 nanosec <<< devait pas être bien réveillée, la machine, les électrons un peu froids sans doute

En fait et en y réfléchissant bien, en cas de copie de données identiques, la seule manière efficace serait non pas de copier les données une à une d'une zone mémoire source vers une autre zone mémoire destination, mais bien plutôt de recopier l'adresse du début de la zone source vers quelque chose qui serait déclaré comme la copie mais qui ne serait qu'un autre pointeur pour accéder aux mêmes données.
Bien sûr ça interdit toute manipulation sur les données copiées (puisqu'elles ne le seraient pas), c'est donc juste un cas d'école, un truc qui sert à rien.

Bonne journée.