Discussion :

[Jipété]

Petit montage gif amusant pour se détendre un peu :



Vous noterez en bas à droite "Images identiques" ! On le croirait pas, hein, vu comme ça. Pourtant ça doit être vrai, au niveau des bytes c'est surement les mêmes.

Je rappelle que l'image moche vient d'une discussion chez les voisins de Delphi, créée (l'image, pas la discussion) par Andnotor, et que cette image moche s'affiche bien sous Windows ainsi que sous Linux avec Qt et Laz 1.6.2 (là vous voyez Gtk2 et Laz 1.4).
J'attends donc avec impatience la sortie de la 1.8 définitive...

Quant à l'image "belle", c'est juste l'ouverture de la moche dans Gimp (où elle s'affiche bien) et sa réexportation sous un autre nom, sans rien changer.
Pi d'abord la moche n'est moche que dans Lazarus : elle est parfaite dans l'explorateur de fichiers, dans le visionneur rapide, dans Gimp, dans ImageJ, etc.

D'après Andnotor, post 38,

Il y a clairement un problème d'offset si l'image d'origine n'est pas supportée sous Lazarus. Par exemple si la taille de l'entête est calculée par SizeOf(BITMAPV5HEADER) plutôt que récupérée dans le fichier lui-même ou peut-être en supposant qu'il y a toujours des informations de couleur.

Va encore falloir jouer avec l'éditeur hexa : z'avez pas vu mon aspirine ?

Un dernier mot : le dégradé moche dans le bleu vient de la compression gif, je ne contrôle pas ce process.

[Jipété]

Bonjour,

Va encore falloir jouer avec l'éditeur hexa

Voilà qui est fait.

Je reviens donc sur cette histoire qui me prend la tête car je n'arrive pas à voir où Lazarus se vautre, dans la mesure où l'examen des headers ne révèle pas de différences (bas de la 1^re image), pas plus que les infos remontées par imgDisplay.Picture.Bitmap.RawImage.Description, au bas de la seconde image (honte sur moi pour avoir utilisé RawImage, ).
1^re image :

Le point curieux dans le beau fichier, c'est ce 02 à l'adresse 6A (7^e ligne) dont je ne sais pas à quoi il correspond. Est-ce lui qui fait la différence ?
seconde image :

On voit bien que les pixels en couleurs sont identiques, 7B B8 E7 et FF de padding pour le 1^er pixel, et ainsi de suite.

Bref, c'est à n'y rien comprendre, et pourtant le fichier "moche" s'affiche comme je vous l'ai montré, tout en vrac dans Lazarus (ailleurs c'est good, je le rappelle), alors que les données sont strictement les mêmes...

Si quelqu'un a une idée, ça pourrait être utile.
Ah, je remets le fichier suspect : FondRVB.zip

[anapurna]

salut

elle est pas un peu vielle la version de lazarus que tu utilise avec le GTK2 ?

[Jipété]

elle est pas un peu vieille la version de lazarus que tu utilise avec le GTK2 ?

C'est pas impossible, mais ce qui m'aurait motivé pour migrer, c'est une vraie TListView, or à chaque sortie de version j'épluche les notes des choses mises à jour et rien en ce qui la concerne, alors bon...
Cependant, j'ai quand même écrit, hier,

J'attends donc avec impatience la sortie de la 1.8 définitive...

On en est à la rc3 (tiens, Gilles ne nous l'a pas annoncée, ), patience patience, donc...

[BeanzMaster]

Bonjour,
Le point curieux dans le beau fichier, c'est ce 02 à l'adresse 6A (7^e ligne) dont je ne sais pas à quoi il correspond. Est-ce lui qui fait la différence ?
seconde image :

En fait tu ne lis pas assez de données :
Voila ce qu'il te manque :

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
 
  TWindowsBMPInfoHeaderV4 = Packed Record
    biSize: LongWord;                // Taille de l'en-tête  = 108 octets  
    biWidth: Longint;                // Largeur de l'image en pixels
    biHeight: Longint;               // Hauteur de l'image en pixels
    biPlanes: Word;                  // Nombre de Plans de couleur  = 1
    biBitCount: Word;                // Nombre de bits par pixel
    biCompression: Longword;         // Type de compression
    biSizeImage: Longword;           // Taille de l'image  AVEC LE PADDING peut être 0 si pas de compression
    biXPelsPerMeter: Longint;        // hoizontal pixels per meter
    biYPelsPerMeter: Longint;        // vertical pixels per meter
    biClrUsed: Longword;             // Nombre de couleurs utilisées (0 = toutes)
    biClrImportant: Longword;        // Nombre de couleurs importantes (0 = toutes)
    biRedMask: Longword;             // Masque Couleur Rouge
    biGreenMask: Longword;           // Masque Couleur Vert
    biBlueMask: Longword;            // Masque Couleur Bleu
    biAlphaMask: Longword;           // Masque Couleur Alpha
    biCSType: Longword;              // Type de l'espace de couleur CIE
    biEndpoints: TGLZBMP_CIEXYZCoordTriple; // "Color space endpoints"
    biGammaRed: Longword;            // Correction Gamma Rouge
    biGammaGreen: Longword;          // Correction Gamma Vert
    biGammaBlue: Longword;           // Correction Gamma Bleu
  End;

Pour ton affichage foireux. Regarde le BitCount dans la description 24 et de combien est ton fichier : 32
J'affiche sans problème ce fichier dans mon projet
Compares les valeurs du "bitfields" avec ceux de tes descriptions :


Du coup Lazarus se prend le mur en lisant des données 24bits au lieu de 32bits

Ps : ne tiens pas compte de la ligne "Format de couleur" dans la capture. C'est un truc à moi en interne que je n'ai pas encore finalisé (au cas ou, pour ne pas te dérouter un peu plus)

EDIT :

Ca mérite quelques explications complémentaires.

Lazarus dans le cas du 2eme fichier le "bô". Il lit les valeurs des masques RGB et malgré que le BitCount soit à 24, l'affichage est correcte dans ce cas.
La manière dont Lazarus détermine si les données sont au formats 24bits ou 32bits est foireuse voila l'explication pour ce mauvais BitCount. (Je le sais ça m'a pris une bonne grosse dizaine de jour pour piger comment gérer la transparence correctement dans mon projet)
Réfère toi au TLazDIBImg ou un truc dans le genre, de l'unité IntfLazImg ou lazInftImg je sais plus
Par contre pour le 1er fichier, il n'y a pas ces informations.Du coup Format par defaut pour RawImage = pf24bits et la PAF dans le mur

[Jipété]

En fait tu ne lis pas assez de données :

Je lis tout le RawImage.Description. Qu'est-ce qu'il faut de plus ? Et s'il faut des choses en plus, pourquoi n'est-ce pas indiqué en gros dans le wiki ?

Du coup Lazarus se prend le mur en lisant des données 24bits au lieu de 32bits
[...]
EDIT :
Par contre pour le 1er fichier, il n'y a pas ces informations.Du coup Format par defaut pour RawImage = pf24bits et la PAF dans le mur

Et là, je me demande si tu lis tout ce que je poste, ou si tu en oublies au passage
à gauche le moche à droite le beau :


Et en ce qui me concerne, je me contente de demander gentiment (si si !) à Lazarus de bien vouloir me charger le fichier et de m'afficher l'image qu'il contient, sans aucune intervention de bas niveau de ma part, un truc genre

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
procedure TMainForm.OpenAnImage(Filename: string);
Var
  pic: TPicture;
Begin
  pic := TPicture.Create;
  Try
    pic.LoadFromFile(Filename);
    image1.Picture.Assign(pic);
  Finally
    pic.Free
  End;   
end;

Réfère-toi au TLazDIBImg ou un truc dans le genre, de l'unité IntfLazImg ou lazInftImg je sais plus

Tu es en train de me dire qu'il faut encore lever le capot et mettre les mains dans le cambouis ? Mais c'est quand que je livre mes pizzas (qui vont arriver périmées) ou que je débarque mon malade à l'hôpital (qui a toutes les chances de mourir dans mon taxi, dans ces conditions) ?

Et encore, on a le bol d'être tombé sur ce fichier bizarre ! Si je n'avais pas trouvé la discussion où il était caché, et si je n'avais pas essayé d'étudier ce sujet, on passait à côté du souci, qui pourra un jour ou l'autre se reproduire sans prévenir.

Un peu lassant, cette informatique aléatoire...

EDIT : rien à voir, cependant, très joli ton tableau d'informations techniques, mais enlève la majuscule à Générales et à Compléméntaires, ce sont des adjectifs donc pas de majuscule, et enlève ce "é", un bête "e" ira très bien.

[Jipété]

Réfère-toi au TLazDIBImg ou un truc dans le genre, de l'unité IntfLazImg ou lazInftImg je sais plus

TLazIntfImage, dans IntfGraphics, celui dont j'ai indiqué il y a quelques mois que l'exemple qui s'affiche en infobulle dans certaines circonstances est faux ?

et TLazDIBImg dans la même unité, tu veux dire TLazReaderDIB ?

Je suis allé y voir, suis tombé sur TLazReaderBMP = class(TLazReaderDIB) et autres prises de tête qui m'ont fait penser que pour conduire mon scooter (ou mon taxi), il me fallait 5 ans d'études et au moins un Master en chimie du pétrole, juste pour pouvoir faire le plein à la pompe !

Naaaaaaaaaaaaaaaaaaaaaaaan ! Faut arrêter les c0nn3r13s !

Il existe une routine qui fait le taf d'afficher une image en 4 lignes de code de haut niveau, tout ce qu'on lui demande, c'est de bien faire son taf, un point c'est tout !

[BeanzMaster]

Je lis tout le RawImage.Description. Qu'est-ce qu'il faut de plus ? Et s'il faut des choses en plus, pourquoi n'est-ce pas indiqué en gros dans le wiki ?

Ici faut te referer au xxxShift et xxxPrec dans la description. (Je pensais que tu décryptais toi même l'en-tête du fichier, mais en fait tu ne lis que le header général) Pour info dans un fichier BMP Windows V1 si le "GapSize" = 12 les masques RGB sont là (24bits) si = 16 alors 32bits (masques RGBA)

Et là, je me demande si tu lis tout ce que je poste, ou si tu en oublies au passage
à gauche le moche à droite le beau :

Si si c'est ce que j'ai tenté de t'expliquer dans les remarques complémentaires

Et en ce qui me concerne, je me contente de demander gentiment (si si !) à Lazarus de bien vouloir me charger le fichier et de m'afficher l'image qu'il contient, sans aucune intervention de bas niveau de ma part, un truc genre

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
procedure TMainForm.OpenAnImage(Filename: string);
Var
  pic: TPicture;
Begin
  pic := TPicture.Create;
  Try
    pic.LoadFromFile(Filename);
    image1.Picture.Assign(pic);
  Finally
    pic.Free
  End;   
end;

TLazIntfImage, dans IntfGraphics, celui dont j'ai indiqué il y a quelques mois que l'exemple qui s'affiche en infobulle dans certaines circonstances est faux ?
et TLazDIBImg dans la même unité, tu veux dire TLazReaderDIB ?
Je suis allé y voir, suis tombé sur TLazReaderBMP = class(TLazReaderDIB) et autres prises de tête qui m'ont fait penser que pour conduire mon scooter (ou mon taxi), il me fallait 5 ans d'études et au moins un Master en chimie du pétrole, juste pour pouvoir faire le plein à la pompe !

Naaaaaaaaaaaaaaaaaaaaaaaan ! Faut arrêter les c0nn3r13s

!

Tu es en train de me dire qu'il faut encore lever le capot et mettre les mains dans le cambouis ? Mais c'est quand que je livre mes pizzas (qui vont arriver périmées) ou que je débarque mon malade à l'hôpital (qui a toutes les chances de mourir dans mon taxi, dans ces conditions) ?

Oui c'est bien ça TLazReaderDIB dans IntfGraphics .

Ca ne sert plus à rien de mettre les mains dans le cambouis. Ici c'est une erreur interne à faire remonter mais bon vue que tout le système sur les bitmaps est sujet à changement.Peut-être que pour Lazarus 2.0 ?

Au cas ou voila le mauvais bout de code dans TLazReaderDIB de l'unité IntfGraphics

Ligne 5443 :

Code :

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

1
2
 
FIgnoreAlpha := FIgnoreAlpha and (Color.alpha = alphaTransparent);

Ensuite plus bas
Ligne 5565

Code :

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

1
2
3
4
5
6
7
 
  // if there is no alpha in real (all alpha values = 0) then update the description
  if FUpdateDescription and FIgnoreAlpha and (Depth = 32) then // -----> C'est à partir d'ici que l'on se prend le mur
  begin
    Desc.AlphaPrec:=0;
    FImage.SetDataDescriptionKeepData(Desc); // Si mes souvenirs sont bon c'est lui le vrai fautif
  end;

Merci pour le nom de l'unité et de la classe, je m'en souvenais plus

Si non patientez un peu (2, 3 mois) . Je vais avoir une petite demande d'aide à faire à la communauté pour mon projet. et fini des tlazimg, trawimage,...

Et encore, on a le bol d'être tombé sur ce fichier bizarre ! Si je n'avais pas trouvé la discussion où il était caché, et si je n'avais pas essayé d'étudier ce sujet, on passait à côté du souci, qui pourra un jour ou l'autre se reproduire sans prévenir.

Un peu lassant, cette informatique aléatoire...

Ouep depuis cette discussion, il nous en fait voir ce fichier

EDIT : rien à voir, cependant, très joli ton tableau d'informations techniques, mais enlève la majuscule à Générales et à Compléméntaires, ce sont des adjectifs donc pas de majuscule, et enlève ce "é", un bête "e" ira très bien.

Merci je vais changer tout ça.

[Jipété]

Salut,

Ouep depuis cette discussion, il nous en fait voir ce fichier

Pas que lui qui nous en fait voir ! Je viens de retrouver ça dans un dossier de test, je ne me souviens pas de l'avoir déjà mentionné, et si oui, ben j'en remets une 'tite couche, ça peut pas faire de mal :

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
procedure TForm1.Button1Click(Sender: TObject);
var
  bm1,bm2: TBitmap;
begin
  bm1 := TBitmap.Create;
  ShowMessage(StringReplace(bm1.RawImage.Description.AsString, ' ', LineEnding, [rfReplaceAll]));
  // --> BitsPerPixel à 32
  bm1.LoadFromFile(opd.FileName);
  ShowMessage(StringReplace(bm1.RawImage.Description.AsString, ' ', LineEnding, [rfReplaceAll]));
  // --> BitsPerPixel à 24 ! --> mis à 24 par LoadFromFile, même en lui donnant un fic 32 bits -- truc de ouf !
 
  bm2 := TBitmap.Create;
  bm2.pixelformat := bm1.PixelFormat;  // --> ne sert à rien !
  // Et pourtant, dans resize_from davdata, je note :
  bm2.pixelformat := pf24bit; // 24 ou rien = ok, 32 --> inversion R<>B
  // un vrai foutoir...
 
  // suite du progr., supprimé pour ne pas alourdir le post
  bm2.Free;
  bm1.Free;
end;