Discussion :

[BeanzMaster]

Je te confirme tu n'as pas raté une marche.
C'est ce que je te disais. Et le pire du pire c'est que la LCL n'utilise pas fpreaderBMP.pp (trop incomplet). La LCL et donc TLazIntfImage, TBitmap et autres utilisent le TLazReaderDIB dans l'unité intfGraphics Ceux qui ce sont occupé de la partie gestion des bitmap que ce soit dans FPC ou Lazarus n'ont pas été très assidus et objectifs. Résultat ça part dans tous les sens. Et après on me dit que je suis fou de coder ma propre solution.
L'alternative BGRABitmap mais il s'appuie sur les Reader et Writer de FPC et Lazarus donc pour le support des formats de fichier c'est pareil on est marron avec.
Heureusement cette bibliothèque corrige et améliore bon nombre de défaut de FCL-Image et pour tout ce qui est création et modification d'un bitmap, on peux faire pas mal de chose avec ; comme Gilles nous l'a montré au travers de ces derniers tutoriels avec les transitions

[Jipété]

Bonjour,

Je te confirme tu n'as pas raté une marche.

Quel dommage...

[...] c'est pareil on est marron avec.

Non non, c'est du orange !

D'autant plus dommage que si je force en pf16bit, ben, le writer s'en dépatouille pas trop mal :

Code :

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

1
2
3
4
5
6
7
    Writer:=TLazWriterBMP.Create;
    Writer.Initialize(lii);
    //Writer.BitsPerPixel := BitsPerPixel;
    Writer.BitsPerPixel := 16; // forcé pour voir --> et ça donne bien un 03 à l'adresse 1E
    // et ce que je suppose être des masques à partir de l'adresse 36
    // save image to file
    lii.SaveToFile(f, Writer);

Et le viewer de Linux est capable de gérer ces données qu'on n'avait jamais vues jusqu'à présent et de nous afficher le bel orange, confirmé par la loupe :


Rhôôô, il manque pas grand chose, extraits de FPWriteBMP :

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
    if FBpp=16 then Setup16bpp; { sets colormap with masks and Compression }
//...
procedure TFPWriterBMP.Setup16bpp;
var col : TColorRGBA;
begin
  BFI.Compression:=BI_BITFIELDS;
  setlength(ColInfo,3);
  {      A R G B
  r := $0000F800
  g := $000007E0
  b := $0000001F
  }
  col.A:=0; Col.R:=0; { These are 0 for all the three masks}
  { Red Mask }
  Col.G:=$F8; Col.B:=0;
  ColInfo[0]:=Col;
  { Green Mask }
  Col.G:=$07; Col.B:=$E0;
  ColInfo[1]:=Col;
  { Blue Mask }
  Col.G:=$00; Col.B:=$1F;
  ColInfo[2]:=Col;
end;

Faudrait inventer une procedure TFPWriterBMP.Setup32bpp; mais j'ai un peu du mal à comprendre ce que bricole le Setup16bpp avec ses masques...

Bon samedi,

[Jipété]

Ce n'est plus des bâtons dans les roues, c'est une forêt entière qui se jette en travers de mon chemin, et là, heeeeeeeeelp

Qu'on en juge.
J'envisage de rajouter une propriété booléenne au FPWriterBMP, sur le modèle de celles déjà présentes, genre (j'en enlève un peu histoire d'aller à 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
type
  TFPWriterBMP = class (TFPCustomImageWriter)
  private
    StartPosition : int64; { save start of bitmap in the stream, if we must go back and fix something }
    FBpp : byte;
    FRLECompress : boolean;
    FXBGRmode : boolean; // jpt 
    procedure SetBpp (const abpp : byte);
    procedure SetXBGRmode (const aValue : boolean); // jpt
  public
    constructor Create; override;
    property BitsPerPixel : byte read FBpp write SetBpp;
    property RLECompress : boolean read FRleCompress write FRleCompress;
    property XBGRmode : boolean read FXBGRmode write SetXBGRmode; // jpt 
    Property BytesPerPixel : Byte Read GetColorSize Write SetColorSize; deprecated;
  end;

Ensuite je veux utiliser cette propriété dans la unit1 de l'IHM, je tape ce qu'il faut, le point me propose la complétion,


j'accepte, je complète la ligne,

Code :

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

1
2
3
4
    Writer:=TLazWriterBMP.Create;
    Writer.Initialize(lii);
    Writer.BitsPerPixel := BitsPerPixel;
    Writer.XBGRmode := True;

F9 pour voir si tout va bien et là, bim :



Et pourtant, si je mets la souris sur le mot qui pose problème, tout a l'air de bien aller et si je Ctrl-clique, je me retrouve sur la bonne ligne dans la bonne unité.


Que faire pour me sortir de ce pétrin ?

[BeanzMaster]

Ce n'est plus des bâtons dans les roues, c'est une forêt entière qui se jette en travers de mon chemin, et là, heeeeeeeeelp

Que faire pour me sortir de ce pétrin ?

Premièrement je te suggères de ne pas modifié directement les sources de FPC comme tu le fais ici. Sinon il faut recompiler TOUS les paquets de la FCL et de la LCL
Le mieux c'est de faire une copie de l'unité fpwriterbmp et de la renommer et changer le nom de la classe :

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
type
  TJPFPWriterBMP = class (TFPCustomImageWriter)
  private
    StartPosition : int64; { save start of bitmap in the stream, if we must go back and fix something }
    FBpp : byte;
    FRLECompress : boolean;
    FXBGRmode : boolean; // jpt 
    procedure SetBpp (const abpp : byte);
    procedure SetXBGRmode (const aValue : boolean); // jpt
  public
    constructor Create; override;
    property BitsPerPixel : byte read FBpp write SetBpp;
    property RLECompress : boolean read FRleCompress write FRleCompress;
    property XBGRmode : boolean read FXBGRmode write SetXBGRmode; // jpt 
    Property BytesPerPixel : Byte Read GetColorSize Write SetColorSize; deprecated;
  end;

et ensuite tu utilises

Code :

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

1
2
3
4
5
6
7
 
uses 
  JPFPWriterBMP; 
 
Writer:=TJPFPWriterBMP.Create;
Writer.BitsPerPixel := BitsPerPixel;
Writer.XBGRmode := True;

Je peux me tromper, mais c'est une question que je me suis posé :

Parce que les 4 masques ont une taille fixe de 32 bits (4 octets) Or en 16 bits, la moitié des masques est inutilisée : mais le masque doit être calé à droite (poids faible) ou calé à gauche (poids fort) ?
Et l'autre truc, on passe d'un format A8R8G8B8 (donc avec des octets complets) à un format A1R5G5B5 (donc avec des octets incomplets)

ils doivent être calés à droite en little-endian

Code :

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

1
2
3
4
5
//format RGBA 1555 avec ce format la transparence est possible
RedMask     := $00007C00;
GreenMask  := $000003E0;
BlueMask    := $0000001F;
AlphaMask  := $00008000;

Tu ne passes pas de A8R8G8B8 à un format A1R5G5B5 premièrement sauf si la compression est BI_RGB
Si la l'encodage est sur BI_BITFIELD le format par defaut est A0R5G6B5

soit

Code :

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

1
2
3
4
5
//format RGB 565
RedMask     := $0000F800;
GreenMask  := $000007E0;
BlueMask    := $0000001F;
AlphaMask  := $00000000;

on passe bien d'un format A8R8G8B8 à un format A1R5G5B5 mais pas avec des octets incomplets. Le format étant 16Bits les pixels ne sont plus codés sur 4 octets (Integer) mais sur 2 octets (Word)

[Jipété]

Premièrement je te suggère de ne pas modifier directement les sources de FPC comme tu le fais ici. Sinon il faut recompiler TOUS les paquets de la FCL et de la LCL
Le mieux c'est de faire une copie de l'unité fpwriterbmp et de la renommer et changer le nom de la classe :

Vi, c'est ce que j'ai fait cet après-midi, ensuite je me suis copieusement battu et pris la tête avec les masques mais, au bout du compte,

ça fonctionne !

Plus de détails plus tard, j'ai encore plein de tests à faire...

[Jipété]

Alors voilà.

Je me suis donc généré un fichier WriterBMP.pas perso avec la petite modif' qui va bien pour pouvoir enregistrer un ficher XBGR (si Gimp le fait, pourquoi pas nous, mmmh ?) et ma foi, ça a l'air de fonctionner.



Le seul souci, c'est que mon hack n'enregistre pas les informations de couleur comme le fait Gimp ("42 47 52 73", juste après les 4 bytes de mask en orange, sur l'image du bas), résultat le viewer de Linux (petite image du milieu) se mélange les pinceaux (l'image est floue à cause de l'agrandissement, énorme pour pouvoir voir qqchse, l'image d'origine fait 3x2).
Par contre, juste au-dessus Gimp l'ouvre bien, tout comme l'outil tout en haut qui a servi à la générer.

Sous Linux ImageJ ne "supporte pas cette compression" (pour un outil écrit par des scientifiques pour des scientifiques, ça marque mal), par contre ImageMagick s'en sort très bien et sous XP, un récent XnView n'affiche qu'un gris terne [EDIT mais affiche correctement le fichier sans informations de couleur généré par Gimp, voir mon post suivant /EDIT], mon vieux PaintShopPro de '97 mélange les couleurs et... l'imperturbable MsPaint l'affiche sans problèmes, tout comme un Inkscape pas trop vieux (0.91).

En bleu dans les éditeurs hexa les deux lignes de datas de 3 pixels de 4 bytes, rappel, la ligne du haut visible à l'affichage a ses datas stockées en bas.
Et en orange tout seul à l'adresse 1E_hex le fameux champ bih.Compression contenant l'info BI_BITFIELDS (03).
PAR-FAIT !

Ce soir je suis mort, alors le code, demain...

[BeanzMaster]

Salut, n'oublis pas que ton outils génère des fichiers BMP en version 1 et Gimp en version 3 ou 5 suivant si tu décides d'incorporer l'espace de couleur
Chelou que XNView n'arrive pas a visualiser ce fichier Ni l'outils des scientifiques.

Pourrais tu me fournir tes 2 fichiers celui généré avec gimp et celui enregistré par ton outils.

[Jipété]

Yop !

Salut, n'oublie pas que ton outil génère des fichiers BMP en version 1 et Gimp en version 3 ou 5 suivant si tu décides d'incorporer l'espace de couleur.

Oui, mais Mme Michu n'en sait rien, de ces détails internes à la mécanique du graphisme au sens large... Je te renvoie au titre de la discussion, où se trouve "si on ne le sait pas",

Pourrais-tu me fournir tes 2 fichiers celui généré avec gimp et celui enregistré par ton outil.

Tes désirs sont des ordres,
2_fichiers_xbgr.zip

Dans la pj, le fichier 6couleurs.bmp a été généré par mon outil après ouverture de l'autre fichier, généré avec Gimp.

Et pour comparer je viens de m'amuser à générer, toujours avec Gimp, un fichier sans informations de couleurs en haut, pour le comparer à celui sorti par mon outil en bas et voilà le résultat :


Strictement identiques en termes de longueur globale, ils varient cependant sur l'information en 0E_hex, le number of bytes required by the bih structure !
Gimp (valeur 38_hex soit 56_dec) inclut les masques (16 bytes à partir de 36_hex [sous le "13" de la colonne "A" de "Aide"]) dans cette structure, FPC (28_hex soit 40_dec) non...

Et du coup le viewer de Linux ne supporte pas ce fichier (celui de Gimp sidc) et crie très fort :


FPC 1 -- Gimp 0 sur ce coup-là.
Mais c'est un vieux Gimp (2.8.2) ; EDIT il serait intéressant que quelqu'un avec un Gimp récent vérifie ce point, ainsi :

Je viens d'installer la toute dernière (2.10.4), sortie début juillet, elle a à peine 15 jours, et le problème est identique... /EDIT

Également une petite différence de valeurs en ce qui concerne les résolutions H et V en 26_hex et 2A_hex, mais ça n'a pas d'incidence.

EDIT2 : en résumé, c'est un peu l'enfer.
2 OS, 2 logiciels à chaque fois :

Code :

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

1
2
3
4
5
fichier |gimp avec idc|gimp sans idc|fpc sans idc|
XPXnView|     kc      |      ok     |     kc     |
XP_Paint|     ok      |      kc     |     ok     |
LXViewer|     ok      |      kc     |     kc     |
LX_ImgDs|     ok      |      ok     |     ok     |

LX_ImgDs c'est Linux ImageDisplay (mais quelle interface à vomir...)

[tourlourou]

BeanzMaster a raison : la différence vient du support ou non de la version 3 du BIH, non officiel, quoique !

[Jipété]

BeanzMaster a raison : la différence vient du support ou non de la version 3 du BIH, non officiel, quoique !

Mais je n'en ai jamais douté,

Très intéressant, ton lien ! Quelle empoignade !
Et en résumé, on note au tout début que la discussion n'est pas résolue, et j'ai adoré la dernière phrase, que je remets ici pour le fun :

Without the MSDN documentation, I suspect that many file readers are going to fail to support that variant of BMP.

On va essayer de se souvenir qu'il est limite impossible d'avoir un lecteur qui puisse ouvrir tous les fichiers .bmp existants.


+++
Je profite de cette réponse pour vous faire part de cette petite chose, trouvée récemment dans Graphics.pp, lignes 1965 et suivantes (toujours valide en 1.8.2) :

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
...
function IsSysColor(AColor: TColorRef): Boolean; // curieux que ça n'ait pas été commenté "does not work on system color"
 
function Blue(rgb: TColorRef): BYTE; // does not work on system color
function Green(rgb: TColorRef): BYTE; // does not work on system color
function Red(rgb: TColorRef): BYTE; // does not work on system color
function RGBToColor(R, G, B: Byte): TColor;
procedure RedGreenBlue(rgb: TColorRef; out Red, Green, Blue: Byte); // does not work on system color
function FPColorToTColorRef(const FPColor: TFPColor): TColorRef;
function FPColorToTColor(const FPColor: TFPColor): TColor;
function TColorToFPColor(const c: TColorRef): TFPColor; overload; // pas de commentaire cette fois ?
function TColorToFPColor(const c: TColor): TFPColor; overload; // does not work on system color -- really ou bien il doit aller ligne précédente ?
 
// fonts
...

Les erreurs vont parfois se cacher dans des endroits où personne ne va jamais voir.
Faudrait faire des tests mais, franchement, j'ai la flemme...

[BeanzMaster]

Salut

J'ai téléchargé la dernière version de XNView tes 2 fichiers s'affichent correctement sous Win10
Par contre dans FastOneImage Viewer que j'utilise régulièrement l'affichage est en vrac avec les 2 fichiers.

Ton fichier généré avec Lazarus est correcte. Mais il est vrai que pour le format XBGR un en-tête version 3 minimum (au mieux la 4) est requis. Pour rester 100% valide avec les spécifications de Microsoft.

Le choix de gimp, si pas d'idc d'utiliser l'en-tête version 3 est stratégique et n'écrit pas d'informations supplémentaires servant à rien et génère donc un fichier "optimisé" en taille.
D'un point de vue historique le masque alpha à fait son apparition avec l'en-tête version 3. A la base les bmp version 1.0 n'utilisaient qu'un seul format en 32 bits pour les masques, par défaut BGRA. Le fait que certains visualiseurs se plantent sur l'affichage de ces fichiers est que soit il ne supportent pas les en-têtes version 3/4/5 et/ou ne tienne simplement pas compte du "GapSize" dans les version 1. Ils chargent directement les données depuis l'offset inscrit dans l'en-tête commune à tous les BMP (bfOffBits, offsets 11 à 14 dans le fichier).

On va essayer de se souvenir qu'il est limite impossible d'avoir un lecteur qui puisse ouvrir tous les fichiers .bmp existants.

A part mon outils je n'en connais aucun, même la dernière version de XNView se prend des murs avec certains fichiers

On peux même voir que le nombre de bits par pixel retourné est incorrecte avec certains fichiers (notamment les 16 bits)

et idem ci-dessous avec IrfanView qui s'en sort à peine un petit mieux avec la gestion des masques, mais ce n'est pas encore ça



Ces deux logiciels sont pourtant parmi les mieux cotés sous Windows pour afficher des images et font référence en la matière.

Microsoft à été trop permissif au fil du temps avec le format BMP. Et je ne comprend toujours pas pourquoi Microsoft à mis ce "GapSize" en place, car c'est à cause de lui que vienne la majorité des erreurs d'affichage.

[Jipété]

J'ai téléchargé la dernière version de XNView tes 2 fichiers s'affichent correctement sous Win10
Par contre dans FastOneImage Viewer que j'utilise régulièrement l'affichage est en vrac avec les 2 fichiers.

Ton fichier généré avec Lazarus est correct. Mais il est vrai que pour le format XBGR un en-tête version 3 minimum (au mieux la 4) est requis.

Oui oui, et maintenant je t'invite à ouvrir lazarus/lcl/lcltype.pp et à aller voir du côté de la ligne 1286 (pour la 1.8.2) et là, cramponne-toi, le TBitmapInfoHeader en est encore et toujours à la v1 !
Qui doit dater de Mathusalem, au moins.
Et on retrouve la même chose dans fpc/num_version/source/packages/fcl-image/src/bmpcomn.pp.

Tiens, cadeau, suite lecture du lien d'Yves, un poil remis en forme, c'est bien sympa d'avoir les 5 versions côte-à-côte, ça permet une comparaison instantanée :




Là-dessous on voit bien la différence entre en haut exporté par Gimp sans informations de couleur donc v3 et 38 en 0E_hex et en bas enregistré par l'outil sur lequel je travaille, et donc en v1 et 28 en E0_hex.


Je sens que ça va bidouiller, la semaine prochaine...

[Jipété]

Bonjour,

voilà donc mon writer modifié : myfpwritebmp.pas.zip

C'est une copie du FPwriterBMP.pp à laquelle j'ai rajouté 2 ou 3 fonctions et procédures pour gérer le xbgr, plus des ajustements dans des méthodes existantes, et tout ce que j'ai ajouté ou modifié est repéré par la chaîne "jpt".

Il y a des commentaires, mais j'aimerais bien un coup de main pour finir l'annotation des masks dans SetupXBGR32bpp, en s'inspirant du Setup16bpp existant car j'avoue que ces histoires de masks, entre le LittleEndian et le BigEndian, une chatte n'y retrouverait pas ses petits.
J'ai réussi à pondre une explication pas piquée des vers concernant le remplacement des bytes RGBA par les bytes XBGR pour qu'ils "tombent" au bon endroit dans le fichier, vous m'en direz des nouvelles, ligne 140.

Pour l'utiliser, je fais comme ça :

1. j'ouvre un fichier .bmp, je récupère les datas du header et je fais afficher son image dans un TImage ;
2. il y a un clic-droit associé au TImage qui peut ouvrir un TSavePictureDialog ;
3. auquel cas,
   

   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
     procedure Enregistre(b:TBitmap; fic:string); // infos Header : LCLType ligne 1280
     var
       lii: TLazIntfImage;
       Writer: TmyLazWriterBMP; // Basé sur TFPWriterBMP de FPC dans l'unité FPWriteBMP du dossier fcl-image/src/
       //ImgFormatDescription: TRawImageDescription; semble inutile
     begin
       //b.SaveToFile(fic); // pour test
       // on a récupéré cette info (et 2 autres + bas) dans le header au chargement du fichier
       if OffsetToDatas = 54 then begin // 122 pour le argb, 138 pour le xbgr
         lii := TLazIntfImage.Create(0,0);
         lii.DataDescription:=GetDescriptionFromDevice(0);
         lii.LoadFromFile(opd.FileName);
       end else with b do begin
         lii:=TLazIntfImage.Create(0,0,[]);
         lii.LoadFromBitmap(Handle, MaskHandle, Width, Height);
       end;
       Writer:=TmyLazWriterBMP.Create;
       Writer.Initialize(lii);
       Writer.BitsPerPixel := BitsPerPixel; // idem
       Writer.XBGRmode := (Compression = BI_BITFIELDS); // idem
       // save image to file
       lii.SaveToFile(fic, Writer);
       // clean up
       Writer.Free;
       lii.Free;
     end;

et voilà.

+++
Ah, pendant que je vous tiens, j'ai trouvé un truc (en C++ mais c'est lisible, et probablement adaptable au Pascal) en provenance de Microsoft, qui est sensé récupérer toutes les infos d'un .bmp, à voir là : https://raw.githubusercontent.com/wi...ex/bmpdump.cpp


+++

BeanzMaster a raison : la différence vient du support ou non de la version 3 du BIH, non officiel, quoique !

dans l'article d'Adobe, tout en bas il y a un lien vers une autre page (danger ! il y a des pages bizarres avec des dames charmantes et peu vêtues qui s'affichent quand on clique pour faire un malheureux copier/coller !) qui raconte en plus des bêtises : faites une recherche sur CSType, il n'y a que 5 entrées très proches, qui expliquent des trucs et des machins qui n'ont rien à voir avec la vraie vie...
La réalité est là :
https://msdn.microsoft.com/en-us/library/cc250396.aspx

Code c++ :

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

1
2
3
4
5
6
7
8
9
10
11
 typedef  enum
 {
   LCS_CALIBRATED_RGB = 0x00000000,
   LCS_sRGB = 0x73524742,
   LCS_WINDOWS_COLOR_SPACE = 0x57696E20
 } LogicalColorSpace;
    LCS_CALIBRATED_RGB:  Color values are calibrated red green blue (RGB) values.
    LCS_sRGB:  The value is an encoding of the ASCII characters "sRGB",
        and it indicates that the color values are sRGB values.
    LCS_WINDOWS_COLOR_SPACE:  The value is an encoding of the ASCII characters "Win ", including the trailing space,
        and it indicates that the color values are Windows default color space values.

et je pense qu'il a confondu bv5CSType avec bv5Intent...

[Jipété]

Un peu de coloriage, comme les gamins à l'école, le sujet étant le Bitmap_Info_Header_v5 :



Pour "voir" un v4 il suffit d'enlever les 4 derniers integers avant les datas (Intent, ProfileData & Type, et Reserved) et pour "voir" un v3, on enlève également les EndPoints et le CSType.

Enfin; pour "voir" un v1 on supprimera les 4 masks.

Bien sûr la data en 0E₁₆ évolue en conséquence (c'est rigolo, d'ailleurs, car c'est une taille, mais tellement normalisée qu'elle peut faire office de version, c'est d'ailleurs comme ça que je m'en sers :

Code :

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

1
2
3
4
5
6
7
8
    case bih.biSize of
       40: Result.VersionHeader:=1;
       52: Result.VersionHeader:=2;
       56: Result.VersionHeader:=3;
      108: Result.VersionHeader:=4;
      124: Result.VersionHeader:=5;
      else Result.VersionHeader:=0;
    end;

), ainsi que la taille du fichier mais ce n'est pas l'objet du coloriage.

[BeanzMaster]

Un peu de coloriage, comme les gamins à l'école, le sujet étant le Bitmap_Info_Header_v5 :


Pour "voir" un v4 il suffit d'enlever les 4 derniers integers avant les datas (Intent, ProfileData & Type, et Reserved) et pour "voir" un v3, on enlève également les EndPoints et le CSType.

Enfin; pour "voir" un v1 on supprimera les 4 masks.

Bien sûr la data en 0E₁₆ évolue en conséquence (c'est rigolo, d'ailleurs, car c'est une taille, mais tellement normalisée qu'elle peut faire office de version, c'est d'ailleurs comme ça que je m'en sers :

Code :

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

1
2
3
4
5
6
7
8
    case bih.biSize of
       40: Result.VersionHeader:=1;
       52: Result.VersionHeader:=2;
       56: Result.VersionHeader:=3;
      108: Result.VersionHeader:=4;
      124: Result.VersionHeader:=5;
      else Result.VersionHeader:=0;
    end;

), ainsi que la taille du fichier mais ce n'est pas l'objet du coloriage.

Tu n'as pas plusieurs solutions pour connaitre la version de l'en-tête, il faut effectivement testé "bih.biSize". Tu n'as sans doute pas fait attention dans mes posts ici et là mais dans mes descriptions d'en-tête je n'ai pas incorporé le "biSize". Regardes les commentaires.

Pour ce qui est de la taille du fichier 'bfSize', je te conseil de ne pas en tenir compte car cette donnée peut être erronée, il faut mieux se servir de "bfOffBits" (octet 11 à 14 - présent dans l'en-tête commun à tous les BMP) qui te permet de déterminer la taille du "GapSize" par rapport au nombre d'octet que tu as déjà lu dans le fichier.

POur ce qui est de FPWriteBMP j'ai regardé plus attentivement et franchement je trouve le code vraiment moche et trop "brut de pomme" surtout la façon dont les masques sont décrit et écrit, passer par le "TColorRGBA" c'est vraiment pas beau. Il faudrais mieux avoir une structure genre :

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
Type
  TBitFieldMasks = packed record
    RedMask : LongWord;
    GreenMask : LongWord;
    BlueMask : LongWord;
    AlphaMask : LongWord;
  end;
 
Var
  XBGRMasks : TBitFieldMasks;
 
function Swap(This : longword): longword; // Prsésent dans FPImgCmn
var
  TmpW1 : Word;
  TmpB1,
  TmpB2 : Byte;
  AnInt : longword;
begin
  TmpW1 := This AND $0000FFFF;
  TmpB1 := TmpW1 AND $00FF;
  TmpB2 := (TmpW1 AND $FF00) SHR 8;
  AnInt := TmpB1;
  AnInt := (AnInt SHL 8) + TmpB2;
  TmpW1 := (This AND $FFFF0000) SHR 16;
  TmpB1 := TmpW1 AND $00FF;
  TmpB2 := (TmpW1 AND $FF00) SHR 8;
  TmpW1 := TmpB1;
  result := (AnInt SHL 16) + (TmpW1 SHL 8) + TmpB2;
end;
 
// Entrée des masques dans l'ordre RGBA
// Sortie des masques en ABGR gràce à swap
 
  With XBGRMasks do 
  begin
      RedMask    := Swap($FF000000); // = $000000FF
      GreenMask := Swap($00FF0000);  // = $0000FF00
      BlueMask   := Swap($0000FF00); // = $00FF0000
      AlphaMask := Swap($00000000);  // = $00000000
  end;

[Jipété]

Yop !

Tu n'as sans doute pas fait attention dans mes posts ici et là mais dans mes descriptions d'en-tête je n'ai pas incorporé le "biSize". [...]

Les deux liens ne fonctionnent pas ou plutôt, renvoient sur le dernier post (celui où tu écris cette phrase que je quote). Et curieusement les liens *_ici_*, dans cette réponse, fonctionnent.
Et sinon, il devait faire trop chaud, je n'ai pas eu le déclic, je ne sais pas... Le déclic je l'ai eu avec le lien d'Yves vers Adobe et cette jolie image des différentes versions du header côte-à-côte.

Pour ce qui est de la taille du fichier 'bfSize', je te conseille de ne pas en tenir compte car cette donnée peut être erronée [...]

"bfSize" ? Ça sort d'où, ce truc ? Je ne connais que bmfFileSize dans le TBitmapFileHeader et biSize dans le TBitmapInfoHeader (que tu dis ne pas utiliser).

Une que j'ai bien notée comme variable, par contre, c'est biSizeImage qui ne serait utile que si le fichier est compacté, d'après ce que j'ai lu.

[...] et franchement je trouve le code vraiment moche [...]

Tu sais, je raconte toujours qu'il y a longtemps, j'ai dépanné à deux heures du mat' un câble d'accélérateur cassé dans une petite bagnole avec un sucre d'électricien (un "domino", tu vois de quoi je parle ?), car va trouver un câble d'une vieille bagnole en pleine nuit dans le Sud de la Corse quand les gens devaient prendre le bateau quelques heures plus tard au petit matin à Bastia.

Une fois le capot refermé, les gens ont pu prendre la route et là, c'est pareil : une fois le code compilé, tes jolies instructions (ie bien écrites et propres sur elles) font la même chose que mon bazar infâme, et c'est tout ce qu'on lui demande,
Mais peut-être que je testerai ta solution, que je garde sous le coude,

À +,

[BeanzMaster]

Yop !


Les deux liens ne fonctionnent pas ou plutôt, renvoient sur le dernier post (celui où tu écris cette phrase que je quote). Et curieusement les liens *_ici_*, dans cette réponse, fonctionnent.
Et sinon, il devait faire trop chaud, je n'ai pas eu le déclic, je ne sais pas... Le déclic je l'ai eu avec le lien d'Yves vers Adobe et cette jolie image des différentes versions du header côte-à-côte.

Bizarre les liens sont bon pourtant, bref c'est dans la première page


"bfSize" ? Ça sort d'où, ce truc ? Je ne connais que bmfFileSize dans le TBitmapFileHeader et biSize dans le TBitmapInfoHeader (que tu dis ne pas utiliser).

bfSize = BMP FILE = BMP_FILE_HEADER = bmfFileSize c'est la même

Si si j'utilise le biSize, mais je ne l'inclus pas dans les header car je le lis avant justement pour determiner le bon en-tête

Code :

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

1
2
3
 { En-tête BMP Windows V2 (non documenté - Adobe Photoshop)@br
    biSize: LongWord; Taille de l'en-tête  = 52 octets }
  TBZWindowsBMPInfoHeaderV2 = Packed Record   //< Ici Taille 48, biSize est lu avant

Une que j'ai bien notée comme variable, par contre, c'est biSizeImage qui ne serait utile que si le fichier est compacté, d'après ce que j'ai lu.

Heu, je sais plus, je ne m'en sert pas.

Tu sais, je raconte toujours qu'il y a longtemps, j'ai dépanné à deux heures du mat' un câble d'accélérateur cassé dans une petite bagnole avec un sucre d'électricien (un "domino", tu vois de quoi je parle ?), car va trouver un câble d'une vieille bagnole en pleine nuit dans le Sud de la Corse quand les gens devaient prendre le bateau quelques heures plus tard au petit matin à Bastia.

Une fois le capot refermé, les gens ont pu prendre la route et là, c'est pareil : une fois le code compilé, tes jolies instructions (ie bien écrites et propres sur elles) font la même chose que mon bazar infâme, et c'est tout ce qu'on lui demande,

Bien vrai, mais ils auraient pu faire mieux, c'est comme si les gars de ferrari mettaient un moteur de 2cv

Mais peut-être que je testerai ta solution, que je garde sous le coude,

À +,

Il faudra que je te refile la mise à jour, depuis le début de cette discussion, j'ai fait pas mal de petite modifs à cause de XBGR Dans tous les cas ma solution sera publiée, quand ? ça c'est une autre paire de manches. Je suis entrain de faire du ménage et affiné les choses de base. Je vais surement rogner quelques parties et ferai des mises à jour au fur et à mesure que je les réincorporai.

[Jipété]

Bien vrai, mais ils auraient pu faire mieux, c'est comme si les gars de ferrari mettaient un moteur de 2cv

L'histoire se passait sur le parking d'une pizzeria-boîte de nuit associée à un camping au milieu de nulle part, et j'étais le seul à avoir des tournevis et autres pinces coupantes à des kilomètres à la ronde pour cause d'emploi de disk-jockey et bricolages divers et variés dans l'établissement.
Alors c'était ça ou rien, et si rien, bateau raté, retour continent échoué, retour au taf et à la vraie vie en vrac, tu vois le truc ?

Il faudra que je te refile la mise à jour, depuis le début de cette discussion, j'ai fait pas mal de petite modifs à cause de XBGR Dans tous les cas ma solution sera publiée, quand ? ça c'est une autre paire de manches. Je suis en train de faire du ménage et affiner les choses de base. Je vais surement rogner quelques parties et ferai des mises à jour au fur et à mesure que je les réincorporai.

Prends ton temps, prends ton temps, on n'est pas aux pièces, mon câble rafistolé au domino tient bon et pourra faire des milliers de kilomètres,

[Jipété]

Bonsoir,

Alors pendant que certains farfouillent au fond du code source des programmes (dans l'autre fil, pour trafiquer des images géantes), moi je farfouille au fond des fichiers .bmp de 1x1 : je suis en train d'écrire à la va-vite une petite bricole pour générer à la demande un squelette de fichier .bmp ne comportant que FileHeader et InfoHeader et couvrant les 5 versions, en pf24 ou 32 (bgra ou xbgr) et avec ou sans les informations de couleurs : à coup de TMemoryStream ça a l'air assez facile, la blague se cache dans les fichiers, regardez ces 2 fichiers générés par Gimp :



En haut un xbgr, en bas un bgra et notez bien la différence de hauteur de la chaîne CSType (BGRs) : une ligne entière de 16 bytes d'écart, correspondant à la présence de 4 masks du mode xbgr (repéré par le 03 à l'adresse 1E₁₆).

Quant à l'option d'export sans les infos de couleur, ça donne ça (bon, comme un imbécile j'ai inversé la présentation des fichiers : cette fois le bgra est en haut) :



Des fichiers plus petits (là il y a tout, c'est-à-dire 1 pixel 08 45 CA FF ou 00 08 45 CA, c'est selon) mais surtout on note que le xbgr incorpore toujours ses 16 bytes de masks.

C'est tout pour le moment, "clic-droit enregistrer sous" et rangez ça dans un coin.

[BeanzMaster]

Dans le deuxieme il n'y pas les masques car BGRA est le mode par défaut des BMP donc pas besoins d'ajouter les informations sur les masques Par contre ce qui est plutôt étrange c'est que Gimp rajoute le GapSize avec le XBGR vue que la version d'exportation est la 5 (chez moi). En principe il n'y en a pas besoin

EDIT : Je viens de vérifier avec ma version de Gimp et l'esport du BMP (version 5) le gapsize n'est pas présent pour le XBGR