Discussion :

[Jipété]

Salut,

J'aurais bien aimé retrouver l'original, j'ai saisi l'url qu'on peut lire, plein de choses intéressantes mais plus ce fichier, dommage...

Je l'ai retrouvé : un zip à télécharger, lien dans le second paragraphe sous l'image, et on peut y lire

I have prepared a computer generated Lab TIFF file of the ColorChecker chart, using the Lab values obtained from the ColorChecker Calculator.

Mais je ne peux pas savoir de quel ColorChecker Calculator il s'agit, quand je vais sur la page en question (lien au-dessus de l'image), mon abruti de navigateur me dit qu'un plugin est nécessaire bla bla, super, si tu me disais quel plugin est nécessaire je pourrais peut-être faire quelque chose...

Fichier dézippé sur le Bureau, mon système génère parfaitement bien la miniature associée à l'image, qui s'affiche impeccablement dans un visionneur basique ainsi que dans The Gimp et RawStudio, mais ImageMagick a du mal avec les couleurs (rendues comme avec PaintShopPro sous Windows).

Allez, FreePascal, au boulot !

Bon dimanche,

[tourlourou]

On est bien d'accord : s'il déclenche une erreur dans ReadTiff, c'est bien parce que ce n'est pas implémenté... pas parce qu'il ne fait pas partie de la norme.

[Jipété]

Bonjour,

Je n'aurais pas dû proposer ces composants de Mitchell, j'ai fait perdre son temps à BeanzMaster, à ceux qui ont suivi cette histoire, à ma pomme (mais moi ça ne compte pas et ça m'apprend des trucs, donc c'est pas grave) et pourquoi je dis ça ?
Parce que ce compo est difficile à mettre en œuvre au quotidien et que lorsqu'on y arrive, on perd la transparence, ce qui fait qu'on se retrouve 30 ans en arrière, c'est assez moyen...

J'ai réussi à lui faire générer un dégradé 4 axes/4couleurs, mais impossible d'avoir une quelconque transparence, que j'avais pourtant réussi à avoir avec le Scanline d'efg avec un exemple dérivé de son Spectra en utilisant TRGBQuad.


En utilisant le même TRGBQuad à la place de TFPColor dans le compo de Mitchell la transparence saute.
À gauche un petit dégradé à base de TRGBQuad dans un TImage chargé depuis un TBitmap avec pf32bit, à droite un autre TImage qui s'appuie sur le compo de Mitchell à qui j'ai un peu tordu le cou pour utiliser TRGBQuad à la place de TFPColor (voir dans l'unité CompImages), et dessous un label qui montre son texte selon le degré de transparence du composant que le recouvre : à gauche 128 (sur 255), à droite 15...

C'est peut-être lié à l'appel

Code :

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

1
2
3
4
5
6
7
8
{$ELSE}{$IFDEF LCLGTK2}
Begin
  gdk_draw_rgb_32_image(TGTKDeviceContext(Canvas.Handle).Drawable,
                        TGTKDeviceContext(Canvas.Handle).GC, 0, 0,
                        FCompactImage.Width, FCompactImage.Height,
                        GDK_RGB_DITHER_NORMAL,      // tramage
                        FRawImage.Data, FRawImage.Description.BytesPerLine);
End;

dans LCLCompImages, je ne sais pas...

[Jipété]

Bonsoir,

je remonte ce post pour faire un point suite à récents tests et exprimer mon désarroi face à ce qui va suivre et qui, résumé en une petite phrase, donne ça :
on ne peut pas faire de graphisme sérieux avec Lazarus, un jour ou l'autre il y aura un fichier qui va gripper le mécanisme.

On se souvient que j'ai signalé il y a une semaine le comportement incohérent des composants BGRA vis-à-vis de mon fichier CIE L*a*b*, normal, ces compos s'appuient sur fpImage qui n'implémente pas toutes les options tiff.

On a vu également que sous Linux (je n'ai aucun test sous Windows) la boîte de dialogue TOpenPictureDialog avait des soucis avec certains fichiers en 32 bits, pour ceux qui ont loupé l'épisode je remets l'image. en bas l'aperçu dans la boîte de dialogue, en haut le fichier correctement affiché avec les composants de Mitchell ou lazrgbgraphics :

Mais ce n'est pas tout ! J'ai pu créer un fichier CIE L*a*b* à partir de The Gimp (prendre un fichier normal, le décomposer en mode CIE L*a*b* puis le recomposer toujours dans ce mode et enfin exporter le résultat en .bmp). L'examen du fichier final avec les composants de Mitchell ou lazrgbgraphics (qui avait l'air très sympathique dans la colonne précédente) nous montre une image en... noir et blanc là où TPicture s'en tire honorablement.

Afin de ne pas être totalement négatif, cette image vient de XP faisant tourner XnView qui essaye d'afficher ce fichier CIE L*a*b* : lui aussi a du mal !

Mais au-delà de cette anecdote, je ne vois pas comment travailler le graphisme avec Lazarus sans trembler car, dans tous les cas de fichiers suspects que je viens d'évoquer, l'explorateur de fichiers sous Linux, mon bête visionneur et The Gimp n'ont rencontré aucun souci à les ouvrir, afficher, etc.

[anapurna]

salut jp

n'existe t'il pas d'autre bibliothèque graphique que fpimage ?
en faisant une petite recherche je suis tombé sur imagemagick

EDIT :
en regardant ceci freepascal Graphics libraries
on s'apperçois que BGRABitmap accepte le TIFF ... tu t'embrouille pas un peu les pinceaux ?

[Jipété]

Yep !

n'existe t'il pas d'autre bibliothèque graphique que fpimage ?

Pas que je sache.
Sinon il pourrait y avoir cairo, mais je n'ai trouvé aucune doc pour expliquer comment ça s'articule avec Lazarus.
Ou alors OpenGL, mais ça a l'air pire que cairo...

en faisant une petite recherche je suis tombé sur imagemagick

... qui ne gère pas mon fichier CIE L*a*b* (couleurs fausses). En haut un visionneur de ma distro, en bas le même fichier ouvert dans ImageMagick :

EDIT :
en regardant ceci freepascal Graphics libraries
on s'aperçoit que BGRABitmap accepte le TIFF ... tu t'embrouilles pas un peu les pinceaux ?

BGRA accepte le TIFF de... fpimage, c'est-à-dire incomplètement (normal, BGRA s'appuie sur fpimage )
Regarde bien mon autre post...

C'est gentil d'avoir tenté,

[Jipété]

Jai voulu tester TLazIntfImage, me disant "on ne sait jamais..."
On va sans doute penser que j'y mets de la mauvaise volonté mais je suis tout simplement parti d'un bout de code trouvé dans le wiki, et ça donne ça :

1- d'abord le bout copié/collé est foireux, ça commence bien :

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 TForm1.Button1Click(Sender: TObject);
var
  b: TBitmap;
  t: TLazIntfImage;
begin
  b := TBitmap.Create;
  if opd.Execute then // ajout
  try
    b.LoadFromFile(opd.FileName);
    t := b.CreateIntfImage;
    // Read and/or write to the pixels
//    t.Colors[10,20] := colGreen; // erreur sur colGreen (l'original), erreur sur clGreen (pour essai rapide) -- heureusement, je n'en ai pas besoin pour ce test.
    b.LoadFromIntfImage(t);
    img.Canvas.Draw(0,0, b); // ajout
  finally
    t.Free;
    b.Free;
  end;
end;

2- ensuite je rajoute juste un TOpenPictureDialog (opd) et un TImage (img), je choisis le fichier "maudit" et voilà ce que ça donne :



à gauche dans le prog de test et à droite un afficheur quelconque de Linux, pour comparer.
C'est vraiment à vomir, quoi...

D'aucuns diront que c'est à cause du fichier d'origine qui a un souci, c'est possible (on en a causé là aujourd'hui), mais alors comment expliquer que la miniature de ce fichier sur le bureau soit bonne, que ça soit ok dans le visionneur comme ci-dessus et que The Gimp et ImageMagick l'ouvrent sans problèmes ?

Le souci est clairement dans le camp de Lazarus/FreePascal, et je n'ai pas les compétences pour dépatouiller cet énorme morceau.

[mm_71]

Jai voulu tester TLazIntfImage, me disant "on ne sait jamais..."
On va sans doute penser que j'y mets de la mauvaise volonté mais je suis tout simplement parti d'un bout de code trouvé dans le wiki, et ça donne ça :

1- d'abord le bout copié/collé est foireux, ça commence bien :

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 TForm1.Button1Click(Sender: TObject);
var
  b: TBitmap;
  t: TLazIntfImage;
begin
  b := TBitmap.Create;
  if opd.Execute then // ajout
  try
    b.LoadFromFile(opd.FileName);
    t := b.CreateIntfImage;
    // Read and/or write to the pixels
//    t.Colors[10,20] := colGreen; // erreur sur colGreen (l'original), erreur sur clGreen (pour essai rapide) -- heureusement, je n'en ai pas besoin pour ce test.
    b.LoadFromIntfImage(t);
    img.Canvas.Draw(0,0, b); // ajout
  finally
    t.Free;
    b.Free;
  end;
end;

2- ensuite je rajoute juste un TOpenPictureDialog (opd) et un TImage (img), je choisis le fichier "maudit" et voilà ce que ça donne :



à gauche dans le prog de test et à droite un afficheur quelconque de Linux, pour comparer.
C'est vraiment à vomir, quoi...

D'aucuns diront que c'est à cause du fichier d'origine qui a un souci, c'est possible (on en a causé là aujourd'hui), mais alors comment expliquer que la miniature de ce fichier sur le bureau soit bonne, que ça soit ok dans le visionneur comme ci-dessus et que The Gimp et ImageMagick l'ouvrent sans problèmes ?

Le souci est clairement dans le camp de Lazarus/FreePascal, et je n'ai pas les compétences pour dépatouiller cet énorme morceau.

Ça me fait penser à une inversion de couleurs, ci-dessous le résultat donné par un swap U/V avec Avidemux suivi d'une inversion de couleurs avec Gimp. Si j'ai raison ça devrait être simple à corriger.

[Jipété]

Salut,

Ça me fait penser à une inversion de couleurs, ci-dessous le résultat donné par un swap U/V avec Avidemux suivi d'une inversion de couleurs avec Gimp. Si j'ai raison ça devrait être simple à corriger.

Tu as très certainement raison.
La seule chose que je ne m'explique pas, dans ta manip d'inversion, c'est la disparition du petit bout de ligne en vrac, en bas à droite :
Zoomé :
(Bon, déjà je ne m'explique pas d'où il sort...)

Et sinon,

D'aucuns diront que c'est à cause du fichier d'origine qui a un souci, [...] mais alors comment expliquer que la miniature de ce fichier sur le bureau soit bonne, que ça soit ok dans le visionneur comme ci-dessus et que The Gimp et ImageMagick l'ouvrent sans problèmes ?

Je viens de faire un test à l'instant : le fichier d'origine s'ouvre parfaitement bien avec le basique MSPaint d'un vieux XP sp2...
Tout comme LazPaint 6.3, d'ailleurs (qui se vautre sur le fichier CIE L*a*b*...)

[mm_71]

Tu as très certainement raison.
La seule chose que je ne m'explique pas, dans ta manip d'inversion, c'est la disparition du petit bout de ligne en vrac, en bas à droite :

??? Je le vois toujours sur mes images postées, il à l'air plus haut dans la version Gimp à cause du cadre qui était plus grand l'image.

Seule chose qui m'a surpris c'est que Gimp à remplacé le gris et blanc du cadre par du noir, il fait une inversion de couleurs mais pas un vrai swap U/V.

(Bon, déjà je ne m'explique pas d'où il sort...)

Ton programme doit s'interrompre avant d'avoir traité les derniers pixels.

[Jipété]

??? Je le vois toujours sur mes images postées, il a l'air plus haut dans la version Gimp à cause du cadre qui était plus grand l'image.

N'étais-je pas bien réveillé ? À 9 h du mat' ? Toujours est-il que je ne le voyais pas... Bon, un problème réglé, c'est cool

Seule chose qui m'a surpris c'est que Gimp a remplacé le gris et blanc du cadre par du noir, il fait une inversion de couleurs mais pas un vrai swap U/V.

Bah, comme je ne sais pas ce que c'est qu'un swap U/V...

Ton programme doit s'interrompre avant d'avoir traité les derniers pixels.

Mon programme ? Euh, je rappelle que c'est un bête copier/coller du wiki dont voici la partie utile :

Code :

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

1
2
3
4
    b.LoadFromFile(opd.FileName);
    t := b.CreateIntfImage;
    b.LoadFromIntfImage(t);
    img.Canvas.Draw(0,0, b); // ajout

PS : si je commente les 2 lignes du milieu (qui à priori n'auraient pas l'air utile), je me retrouve avec une image pleine de raies verticales (comme dans la preview, visible post 64 en bas à gauche), signe d'un décodage foireux.

[mm_71]

Bah, comme je ne sais pas ce que c'est qu'un swap U/V...

https://fr.wikipedia.org/wiki/YUV

PS : si je commente les 2 lignes du milieu (qui à priori n'auraient pas l'air utile), je me retrouve avec une image pleine de raies verticales (comme dans la preview, visible post 64 en bas à gauche), signe d'un décodage foireux.

Si tu parles de:

Code :

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

1
2
    t := b.CreateIntfImage;
    b.LoadFromIntfImage(t);

ça ne vrait rien afficher du tout et renvoyer une erreur d'exception.

[Jipété]

Si tu parles de:

Code :

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

1
2
    t := b.CreateIntfImage;
    b.LoadFromIntfImage(t);

ça ne devrait rien afficher du tout et renvoyer une erreur d'exception.

Oui mais l'informatique c'est magique, surtout avec moi...
Merci pour le lien.

Voilà un montage de copies d'écrans un peu compliqué, alors j'explique :
je suis parti d'un code d'Embarcadero (voir plus bas) qui prend un bmp et le duplique en le doublant (et sous Laz ça ne fonctionne pas du premier coup, bien sûr !).

J'ai supprimé la fonction de doublage, en gros je fais une simple copie de pixels mais en mode "scanline", ça speede (et ça rajoute des problèmes...)

J'ai utilisé 3 fichiers source :
1- en haut, un fichier 24 bits généré ex nihilo dans The Gimp
2- au milieu le fichier 32 bits dont je parle tant ces jours-ci, je l'appelle le 32bitsKC même s'il n'est pas si KC que ça puisque plein de logiciels arrivent à l'ouvrir
3- en bas le même KC mais réexporté depuis The Gimp, il serait presque bon, donc 32bitsOK.

Résultats :
À gauche c'est sous Linux et on note qu'en haut et en bas il y a 2 images l'une sur l'autre : celle du dessus est réalisée en mode Dest.PixelFormat := Src.PixelFormat alors que celle du dessous est en mode forcé à pf32bit.
Je n'ai pas mis de seconde image au milieu car elle est aussi moche que celle déjà présente.
Et à droite c'est sous XP, le trait bleu c'est le bord gauche de la fiche, pour séparer.
Et sous Linux comme sous Windows, à gauche l'original et à droite la copie.
Fouhhh, c'est clair ?

Toutes les copies d'écran sont ensuite réduites de moitié pour cette présentation.

Ah, mon code, si certains veulent jouer :

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
procedure TForm1.Button3Click(Sender: TObject);
type
  TRGBTripleArray = ARRAY[Word] of TRGBTriple;
  pRGBTripleArray = ^TRGBTripleArray; // use a PByteArray for pf8bit color
var
  w,h : Integer;
  BitMap, BigBitMap : TBitMap;
  {$IFDEF WINDOWS}
  //P, bigP   :  pRGBTripleArray; // original /!\ /!\ /!\ /!\
  P, bigP   :  pRGBTriple; // mieux /!\ /!\ /!\ /!\
  {$ELSE}
  P, bigP   :  pRGBQuad;
  {$ENDIF}
begin
  BitMap := TBitMap.create;
  BigBitMap := TBitMap.create;
  if opd.Execute then
  try
    BitMap.LoadFromFile(opd.FileName);
    BigBitMap.PixelFormat := BitMap.PixelFormat;
    //BigBitMap.PixelFormat := pf32bit; // forçage pour Linux
    BigBitMap.Height := BitMap.Height;
    BigBitMap.Width := BitMap.Width;
 
    BigBitMap.BeginUpdate();
    for h := 0 to BitMap.Height-1 do begin
      {$IFDEF WINDOWS}
      P := pRGBTriple(BitMap.RawImage.GetLineStart(h));
      bigP := pRGBTriple(BigBitMap.RawImage.GetLineStart(h));
      {$ELSE}
      P := pRGBQuad(BitMap.RawImage.GetLineStart(h));
      bigP := pRGBQuad(BigBitMap.RawImage.GetLineStart(h));
      {$ENDIF}
      for w := 0 to BitMap.Width-1 do bigP[w] := P[w];
    end;
    BigBitMap.EndUpdate();
 
    Canvas.Draw(0, 0, BitMap);
    Canvas.Draw(260, 20, BigBitMap);
  finally
    BitMap.Free;
    BigBitMap.Free;
  end;
end;

Moi j'en ai marre...

[mm_71]

celle du dessous est en mode forcé à pf32bit.

Et si elle ne fait pas 32 bits ? Le format .bmp est très variable:

Il faudrait pouvoir le déterminer en entrée pour choisir le traitement approprié.

Fouhhh, c'est clair ?

Joker...

Ah, mon code, si certains veulent jouer :

Ne sert à rien en l'état, Il faudrait zipper le projet complet avec les images incriminées.

[Jipété]

Et si elle ne fait pas 32 bits ? Le format .bmp est très variable:

C'est bon, on est presque en 2017, les vieux coucous des années '90 je les ignore, c'est suffisamment galère rien qu'avec 24 et 32 bits (et un jour faudra qu'on parle des 64 bits, découverts hier !)

Ne sert à rien en l'état, Il faudrait zipper le projet complet avec les images incriminées.

Tiens, avec les uses et le code du post précédent, un bouton sur la fiche et un TOpenPictureDialog (opd) t'es bon, avec le zip des 3 images : 3bmp.zip

Code :

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

1
2
3
uses
  graphtype, intfgraphics,
  LCLType, LCLProc,  LCLIntf;

[mm_71]

Tiens, avec les uses et le code du post précédent, un bouton sur la fiche et un TOpenPictureDialog (opd) t'es bon, avec le zip des 3 images

Ok, je jetterai un oeil dans la soirée.

[mm_71]

Bon...
Après un bref coup d’œil deux choses:
Une bizarre: Si je prend ton script en simple C/C il ne m'affiche rien du tout quand je clique le bouton. J'ai dû rajouter une temporisation pour que ça marche:

Code :

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

1
2
3
4
    BigBitMap.Width := BitMap.Width;
//    Canvas.Draw(0, 0, BitMap); // Ne sert à rien ?
    Application.ProcessMessages; // Temporiser.
    BigBitMap.BeginUpdate();

Et la deuxième c'est que ton problème de stries vient du fait que tu charges une image 32 bits en 24 bits. Il faudrait avoir une fonction qui donne l'encodage du .bmp après son chargement.
Quant au problème de différence entre bitmap et bigbitmap ta conversion du bmp d'origine en 32 bits ( Si j'ai bien compris ce que tu cherche ) est trop simpliste. Les .bmp ont un en tête qui contien entre autres le format et si il n'est pas mis à jour il ne comprend plus rien à l'affichage.
Lazarus a peut-être aussi un problème, ton bmp cassé apparaît strié dans la prévis de l'openimage alors que tous mes programmes l'affichent proprement.
Je verrai plus en détail plus tard.

[Jipété]

Une bizarre: Si je prend ton script en simple C/C il ne m'affiche rien du tout quand je clique le bouton. J'ai dû rajouter une temporisation pour que ça marche:
Et la deuxième c'est que ton problème de stries vient du fait que tu charges une image 32 bits en 24 bits. Il faudrait avoir une fonction qui donne l'encodage du .bmp après son chargement.
Quant au problème de différence entre bitmap et bigbitmap ta conversion du bmp d'origine en 32 bits ( Si j'ai bien compris ce que tu cherches ) est trop simpliste.

1- T'as dû te gourrer pour le C/C car le Canvas.Draw est tout à la fin de la proc, pas au début comme tu le montres...
2- tu charges une image 32 bits en 24 bits. : Oui, c'est exactement ce que je fais et sous Windows, va comprendre, ça s'affiche correctement, regarde l'image postée (image gauche de la colonne de droite au milieu).
Et la fonction qui donne ça, c'est bitmap.PixelFormat.
3- Je rappelle que je suis parti d'un code d'Embarcadero et que je me suis contenté de l'alléger car au départ il doit prendre la source et la recopier en doublant hauteur et largeur.
Je l'ai allégé parce que je me suis dit que ça serait plus facile à comprendre et à dépatouiller s'il n'y avait pas le redimensionnement, juste la copie 1:1.

Lazarus a peut-être aussi un problème, ton bmp cassé apparaît strié dans la prévis de l'openimage alors que tous mes programmes l'affichent proprement.

Oh que oui ! Et c'est bien ce que je dis aussi depuis 8 à 10 jours environ...
Tous tes programmes Windows ou Linux ?
Parce que comme on le voit dans mon montage des copies d'écran, il y a moins de problèmes sous les fenêtres que chez le pingouin...

Je verrai plus en détail plus tard.

Perds pas ton temps.

[mm_71]

T'as dû te gourrer pour le C/C

Exact.

Je rappelle que je suis parti d'un code d'Embarcadero

Mais code delphi il me semble ?

Tous tes programmes Windows ou Linux ?

Uniquement linux. Ton bmp cassé chargé sous gimp et réexporté en 32 bits n'est plus cassé.

il y a moins de problèmes sous les fenêtres que chez le pingouin.

Mais ton programme ne foncionne pas de la même manière sous windows que sous Linux.

Code :

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

1
2
3
4
5
6
  {$IFDEF WINDOWS}
  //P, bigP   :  pRGBTripleArray; // original /!\ /!\ /!\ /!\
  P, bigP   :  pRGBTriple; // mieux /!\ /!\ /!\ /!\
  {$ELSE}
  P, bigP   :  pRGBQuad;
  {$ENDIF}

Code :

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

 BigBitMap.PixelFormat := pf32bit; // forçage pour Linux

Pour pouvoir comparer tu dois donner exactement les mêmes paramètres aux deux systèmes.

Maintenant voici la longue liste du caca bmp.

24 bits tu n'as que R8 G8 B8
32 Bits tu as A8 R8 G8 B8 et X8 R8 G8 B8 ou la première valeur est le canal alpha. Donc tu dois avoir un tableau à 3 colonnes pour le 24 bits et un à 4 pour le 32 bits. Il faut en plus considérer que le canal alpha n'est pas géré de la même manière selon qu'il soit A8 ou X8.
Et la ou ça devient vraiment comique c'est que j'ai mis un test:

Code :

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

1
2
3
4
5
6
7
8
    Case  BitMap.PixelFormat of
      pf16bit: TmpStr:='16 Bits';
      pf24bit: TmpStr:='24 Bits';
      pf32bit: TmpStr:='32 Bits';
      pfDevice: TmpStr:='Device';
    end;
 
    Label1.Caption:='Format en entrée:  '+TmpStr;

Et toutes les images sont identifiées comme du 24 Bits sauf ton bmp cassé qui est reconnu comme 32 bits !!!
J'ai créé 2 bmp avec transparence via gimp respectivement en A8 et X8 et même chose identifiés 24 bits et la zone transparente ressort en noir, les afficheurs standard Linux ne reconnaissent pas le format, seuls les gros logiciels ( Gimp, Natron, Blender, Fusion 8 etc... ) s'en sortent.
Ceci dit je confirme que TBitmap est une daube. Si ton tableau à 3 élément fonctionne sous windows ( Je pose un doute ) c'est que les 32 bits ont été reformatés en 24 bits et le canal alpha viré alors qu'il est resté sous linux.

Sur ce je vais braquer une pharmacie pour trouver de l'aspirine.

[Jipété]

Salut,

Mais code delphi il me semble ?

À ce niveau-là je dirais plutôt code Pascal.

Mais ton programme ne foncionne pas de la même manière sous windows que sous Linux.
Pour pouvoir comparer tu dois donner exactement les mêmes paramètres aux deux systèmes.

Pas de panique, c'était juste pour faire des tests : cette histoire est tellement troublante...

Sur ce je vais braquer une pharmacie pour trouver de l'aspirine.

Alors pour résumer tes tests, tout le monde (sauf ton Linux [trop vieux ? Trop light ?] -- mais le mien = r. à s.) gère bien un truc parfaitement ingérable.
C'est quand même loufoque, quoi.

J'ai refait les tests 32/24, in fine ou bien c'est The Gimp qui est à la ramasse ou bien c'est le couple FreePascal/Lazarus, un point c'est tout.

Sous The Gimp, selon que j'ouvre un fichier 32 ou 24 bits, son nom s'affiche en maigre ou en gras dans la fenêtre des calques (comportement normal), et le clic droit sur la miniature me propose de supprimer ou d'ajouter un canal alpha, normal aussi.
Le 32 bits caca, si je lui demande de le reexporter, la fenêtre d'export s'affiche avec les réglages de la source, comme ça :


Je ne change rien (juste le nom du fichier), puis j'ouvre ce nouveau fichier, je demande son export, j'ai exactement les mêmes réglages (et d'ailleurs le poids des fichiers est identique) donc pour moi ce fichier est un 32, alors pourquoi, en m'appuyant sur ton petit bout de code, PixelFormat me remonte pf24bit ?
Hallucinant !

Et à partir de là tout ne peut que partir en sucette...

EDIT : je me disais bien qu'on en avait déjà causé, je l'avais à moitié oublié (désolé, Gilles ) :

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

Code :

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

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

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

/EDIT
Plus qu'à attendre que le todo soit pris en compte...
Ce qui est bizarre c'est de bien lire le commentaire de Gilles (PixelFormat ne fait pas grand chose) puis cette discussion de 2011 où l'on trouve une procédure ChangeImagePixelFormat : alors, ça fait quelque chose ou pas grand chose ?
Car on y trouve aussi cette ligne :

En fait, il faut rajouter l'instruction qui modifie le PixelFormat du TImage

EDIT2 : J'ai fait des recherches ici sur le mot PixelFormat (23 résultats), j'ai retrouvé plein de vieilles discussions, et par exemple ce petit bout qui aura bientôt 3 ans :

j'ai refait quelques recherches, tests et essais, et comme beaucoup le disent sur des forums, le graphisme sous Lazarus c'est un truc à finir fou : il y en a partout, ça se mord la queue, il y a des machins intermédiaires, on ne sait pas qui fait quoi, la doc est nulle ou inexistante ou buggée, la complétion de code propose des choses que le compilateur refuse, bref je jette l'éponge.

/EDIT2