Discussion :

[foetus]

Dans tes rêves !

D'abord il faut savoir où se trouve ce masque alpha

Relis ton code : c'est exactement ce que tu fais
Tu testes la valeur de la compression. Mais en 32 bits, tu n'as en théorie qu'1 seule valeur possible. Ton format XRGB n'existe que pour toi.

Et les masques sont dans la structure BITMAPINFOHEADER (qui a différentes versions 4, 5, ...)
Ce sont des structures classiques du langage C : c'est à dire contigu en mémoire. Tu remplis le champs et c'est fini.

Et dans la documentation de la structure BITMAPV4HEADER tu as bien 4 champs pour les masques.

Euh, tu ne l'as pas bien lu, alors... Extrait de ton lien, rubrique BitCount chapitre "32" : If the bV4Compression member of the BITMAPV4HEADER is BI_BITFIELDS, the bmiColors member contains three DWORD color masks that specify the red, green, and blue components of each pixel.
À moins que 3 != three ?

Et si je regarde la V5, j'en conclus qu'ils ont fait un bête copier-coller de la V4 :
D'autant plus amusant que la structure en début d'article montre bien DWORD bV5AlphaMask;...

J'enfonce le clou : une recherche sur la page de bV5RedMask montre 4 occurrences quand bV5AlphaMask n'en montre que 2.
La conclusion de la conclusion c'est que msdn n'est pas fiable à 100 %, et là, on est très mal !

En regardant de plus près, la source msdn semble être fiable

En gros tu as la structure :

Code :

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

1
2
3
4
typedef struct tagBITMAPINFO {
  BITMAPINFOHEADER bmiHeader;
  RGBQUAD          bmiColors[1];
} BITMAPINFO, *LPBITMAPINFO, *PBITMAPINFO;

Note que les informations sont dans le champs bmiHeader qui est également une structure (avec la profondeur, les masques, ....).
Et le champs bmiColors est la palette de couleurs. Et donc tu t'en fiches de cette palette avec des couleurs vraies 16, 24 ou 32 bits.

Mais Microsoft autorise l'usage simultanée de la palette et des couleurs vraies, mais la palette contient des couleurs sur 32 bits mais sans canal alpha (c'est historique).

Et c'est là que tu as mal lu (et moi aussi )

The bmiColors color table is used for optimizing colors used on palette-based devices, and must contain the number of entries specified by the bV4ClrUsed member of the BITMAPV4HEADER.If the bV4Compression member of the BITMAPV4HEADER is BI_BITFIELDS, the bmiColors member contains three DWORD color masks that specify the red, green, and blue components of each pixel. Each DWORD in the bitmap array represents a single pixel.

Ce sont 3 DWORDS pour chaque couleur dans cette palette parce que tu as précisé un nombre de couleurs pour cette palette différent de 0 (c'est le champs bV4ClrUsed du champs bmiHeader).
On ne parle pas des 4 masques.

[Jipété]

Ils indiquent quels bits des 32 codent chaque canal, selon le schéma d'où mon image était extraite).

Merci pour le lien (je crois que tu l'avais déjà donné, mais c'est épuisant à lire et parfaitement indigeste : il faudrait l'avoir sur papier et bien mis en page, tout un métier... À l'écran c'est une horreur.)

Non je n'ai rien dit

Pas de bol, j'ai lu avant que tu n'édites, et ce n'est pas mon fichier, il est généré par The Gimp.

Et dans la documentation de la structure BITMAPV4HEADER tu as bien 4 champs pour les masques.

Oui, dans la structure, mais pas dans les explications (chapitre 32, ), pour qu'on comprenne à quoi ça sert et comment ça marche...

Bon, ça doit être la chaleur de la fin de journée, mais je n'ai rien compris à vos réponses et je ne vois pas comment m'en servir.
Alors je prends le problème à l'envers :
je génère avec The Gimp une image en 32 bpp de 3x2 avec 6 couleurs différentes (en haut de g à dr mon bel orange, un vert et un vieux-rose, dessous du noir du gris et du blanc
-- image très agrandie),
je l'exporte en argb et en xrgb, et je regarde avec l'éditeur hexa :



ligne du haut (en bas dans le fichier)
202 69 08 -- 80 153 4 -- 240 190 210, soit CA 45 08 -- 50 99 04 -- D2 BE F0 en mode RGB

ligne du bas, facile de reconnaître les 00, 80 et FF
0 0 0 -- 128 128 128 -- 255 255 255

Résultat, on voit bien la position du byte Alpha après les 3 couleurs B G R dans le fichier argb, et la position du byte X avant les 3 couleurs B, G, R dans le fichier xrgb.

Il est très facile de confirmer la position du byte Alpha dans le fichier argb en jouant sur la transparence dans The Gimp : en la passant à 50% et en réexportant, on constate le remplacement de FF par 7F.


Tout ça pour dire qu'avec le xrgb et dans ce cas (génération par The Gimp), la lecture peut très bien oublier les masks et se concentrer sur la lecture des pixels, moyennant l'adaptation qui va bien et à laquelle je réfléchirai demain.

[foetus]

Édit : Apparemment, les valeurs des entêtes doivent être lues en "little endian" (de droite à gauche) sauf le nombre magique "BM"

Première image :

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
BMP Header
0h	2	42 4D		"BM"				ID field (42h, 4Dh)
2h	4	92 00 00 00	146 bytes			Size of the BMP file
6h	2	00 00		Unused				Application specific
8h	2	00 00		Unused				Application specific
Ah	4	7A 00 00 00	Offset where the pixel array (bitmap data) can be found
DIB Header
Eh	4	6C 00 00 00	108 bytes			Number of bytes in the DIB header (from this point)
12h	4	03 00 00 00	3 pixels (left to right order)	Width of the bitmap in pixels
16h	4	02 00 00 00	2 pixels (bottom to top order)	Height of the bitmap in pixels
1Ah	2	01 00		1 plane				Number of color planes being used
1Ch	2	20 00		32 bits				Number of bits per pixel
1Eh	4	00 00 00 00	0				BI_RGB, no pixel array compression used
22h	4	18 00 00 00	24 bytes			Size of the raw bitmap data (including padding)
26h	4	13 0B 00 00	2835 pixels/metre horizontal	Print resolution of the image, 72 DPI × 39.3701 inches per metre yields 2834.6472
2Ah	4	13 0B 00 00	2835 pixels/metre vertical
2Eh	4	00 00 00 00	0 colors			Number of colors in the palette
32h	4	00 00 00 00	0 important colors		0 means all colors are important
36h	4	42 47 52 73	little-endian "sRGB"		color space ????
???? plein de zéros
7Ah		Start of the Pixel Array (the bitmap Data)

Un truc que je ne maîtrise pas , c'est comme la compression est BI_RGB, les masques sont absents.
Mais il semble qu'on ait gardé quand même les champs color space, Color Space endpoints, Red Gamma, Green Gamma, Blue Gamma (c'est mon "plein de zéros")

Deuxième image :

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
BMP Header
0h	2	42 4D		"BM"					ID field (42h, 4Dh)
2h	4	A2 00 00 00	162 bytes				Size of the BMP file
6h	2	00 00		Unused					Application specific
8h	2	00 00		Unused					Application specific
Ah	4	8A 00 00 00	Offset where the pixel array (bitmap data) can be found
DIB Header
Eh	4	7C 00 00 00	124 bytes				Number of bytes in the DIB header (from this point)
12h	4	03 00 00 00	3 pixels (left to right order)		Width of the bitmap in pixels
16h	4	02 00 00 00	2 pixels (bottom to top order)		Height of the bitmap in pixels
1Ah	2	01 00		1 plane					Number of color planes being used
1Ch	2	20 00		32 bits					Number of bits per pixel
1Eh	4	03 00 00 00	3					BI_BITFIELDS, no pixel array compression used
22h	4	18 00 00 00	24 bytes				Size of the raw bitmap data (including padding)
26h	4	13 0B 00 00	2835 pixels/metre horizontal		Print resolution of the image, 72 DPI × 39.3701 inches per metre yields 2834.6472
2Ah	4	13 0B 00 00	2835 pixels/metre vertical
2Eh	4	00 00 00 00	0 colors				Number of colors in the palette
32h	4	00 00 00 00	0 important colors			0 means all colors are important
36h	4	00 00 00 FF	FF000000 in big-endian			Red channel bit mask (valid because BI_BITFIELDS is specified)
3Ah	4	00 00 FF 00	00FF0000 in big-endian			Green channel bit mask (valid because BI_BITFIELDS is specified)
3Eh	4	00 FF 00 00	0000FF00 in big-endian			Blue channel bit mask (valid because BI_BITFIELDS is specified)
42h	4	00 00 00 00	00000000 in big-endian			Alpha channel bit mask
46h	4	42 47 52 73	little-endian "sRGB"			color space ????
4Ah	24h	24h* 00...00	CIEXYZTRIPLE Color Space endpoints	Unused for LCS "Win " or "sRGB"
6Eh	4	00 00 00 00	0 Red Gamma				Unused for LCS "Win " or "sRGB"
72h	4	00 00 00 00	0 Green Gamma				Unused for LCS "Win " or "sRGB"
76h	4	00 00 00 00	0 Blue Gamma				Unused for LCS "Win " or "sRGB"
8Ah		Start of the Pixel Array (the bitmap Data)

Conclusion :
Ton image (la première) celle que tu dis BGRA est juste une image 24 bits (et donc sans canal alpha) (une ligne : BGRBGR...BGR + padding)
Ton image (la première) celle que tu dis BGRA est juste une image 32 bits (et donc avec canal alpha) (une ligne : BGRABGRA...BGRA)
Ton image (la deuxième) celle que tu dis XBGR est juste une image 32 bits mais avec un canal alpha désactivé (masque alpha == 0) (une ligne suivant les masques : XBGRXBGR...XBGR)

Donc, c'est que je disais : c'est simple - il faut lire la compression + les masques s'ils sont présents.

Et désolé pour tout à l'heure , j'ai oublié la structure BMP Header (@tourlourou me l'a précisé) et je me suis pris les pieds dans le tapis sur la taille des WORD, DWORD, LONG, ...

Édit : D'après la documentation de Microsoft, le nombre de bit est un maximum pour les couleurs vraies 16, 24 ou 32 bits. C'est pour cela qu'on a 32 bits au lieu de 24 bits pour la première image
Non ce n'est pas un maximum encore lu de travers. Par contre ce que ne dit pas Microsoft (enfin si, mais il faut le chercher ailleurs) c'est que la compression BI_RGB à 32 bits supporte les couleurs bgra (avec un canal alpha donc)

Et la taille des données brutes semble correcte : 24 octets, soit [3*2* 3 octets par couleur + 2 lignes * 3 bits de padding (<- 12 - 9)] soit 3*2 * 4 octets par couleur

[Jipété]

Conclusion :
Ton image (la première) celle que tu dis BGRA est juste une image 24 bits (et donc sans canal alpha) (une ligne : BGRBGR...BGR + padding)

T'aurais dû rapprocher ça du petit bout concernant la troisième image où j'ai "descendu" la transparence (l'opacité serait plus juste) de 100 (FF) à 50 (7F) :

donc ce canal est capable d'enregistrer la valeur positionnée dans The Gimp, donc non, ce n'est pas une image 24 bits (et donc sans canal alpha), c'est une image 32 avec alpha.
C'est d'ailleurs ce que j'avais demandé au Gimp, dans la fenêtre des calques : clic droit ajouter un canal alpha, et une fois cela fait, l'export de l'image en bmp proposera le choix ARGB, vu ici avant l'ajout du canal :


Et, rappel, il n'y a pas de padding en 32 bits, et enfin, un byte qui change de valeur en fonction de la transparence demandée n'est pas du padding, c'est du canal alpha.
D'autant plus que le padding n'est pas ajouté après chaque byte, il est ajouté en fin de ligne en fonction du nombre de pixels !

Fouhhh, les tapis sont traîtres, cet été, y en a partout

Conclusion :
Ton image (la deuxième) celle que tu dis XBGR est juste une image 32 bits mais avec un canal alpha désactivé (masque alpha == 0) (une ligne suivant les masques : XBGRXBGR...XBGR)

Ce n'est pas moi qui le dis, c'est ce que j'ai demandé à Gimp de générer.

Et un canal alpha désactivé, j'appellerais ça un canal X. Nan ?
("X" pas comme coquin mais comme n'importe quelle valeur, on s'en fiche, elle ne sera pas utilisée.)

Code :

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

46h	4	42 47 52 73	little-endian "sRGB"			color space ????

Moi aussi ça m'intrigue ; Jérome dit que ce n'est pas ça, mais il ne dit pas ce que c'est...

Je retrouve cette info dans tous les fichiers générés par Gimp sauf si je coche la case "Ne pas inscrire l'information d'espace couleur" dans la rubrique d'export "Options de compatibilité".

Jérome, t'es sûr de ton coup, là ? 'Tention, y a un tapis planqué qui te surveille du coin de l'œil,

[foetus]

donc ce canal est capable d'enregistrer la valeur positionnée dans The Gimp, donc non, ce n'est pas une image 24 bits (et donc sans canal alpha), c'est une image 32 avec alpha.

Fin du mystère : lorsque tu mets la compression à BI_RGB et le nombre de bits à 32 bits, le format bmp supporte le stockage des couleurs en BGRA.
Et c'est ce que j'avais noté : tu as bien 32 bits dans l'entête et j'ai cru à tort que c'était un maximum (<- en fait j'avais mal lu encore 1 fois ).

Alpha Blending (<- lien msdn en anglais) -> Alpha values per pixel are only supported for 32-bpp BI_RGB.

Code :

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

1
2
3
4
This is represented in memory as shown in the following table.
 
31:24	23:16	15:08	07:00
Alpha	Red	Green	Blue

Et un canal alpha désactivé, j'appellerais ça un canal X. Nan ?

J'utilise aussi X pour la notation : pour une image 32 bits (*) tu as 4 masques de 4 octets lorsque tu as une compression à BI_BITFIELDS (et tu as les masques qu'avec cette compression) : 1 masque bleu, 1 masque rouge, 1 masque vert et 1 masque alpha qui sont dans l'entête.
Et donc, tu vas prendre tes données 4 octets par 4 octets soit ABCD

• ABCD ET BINAIRE masque bleu = couleur bleue
• ABCD ET BINAIRE masque rouge = couleur rouge
• ABCD ET BINAIRE masque vert = couleur vert
• ABCD ET BINAIRE masque alpha = transparence

Et donc si ton masque est à zéro, un ET BINAIRE te donnera toujours 0 : c'est donc désactivé, X, « ce que tu veux ».


* -> pour les images 16 et 24 bits, il faudrait tester ce qui se passe ... ou trouver la prose de Microsoft.

[Jipété]

Fin du mystère

Alpha Blending (<- lien msdn en anglais) -> Alpha values per pixel are only supported for 32-bpp BI_RGB.

Code :

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

1
2
3
4
This is represented in memory as shown in the following table.
 
31:24	23:16	15:08	07:00
Alpha	Red	Green	Blue

Il est marrant ce lien, parce qu'il commence par la structure et nous montre ex-ac-te-ment ce qu'on voit dans les fichiers générés par The Gimp (B puis G puis R puis A, de g à dr), puis dessous il nous inverse tout "en mémoire".
Mais qui va aller regarder en mémoire ? Perso je regarde la sortie de l'afficheur hexa et basta, fin bon, on voit le bout du tunnel,

Pour les 16 et 24 bits, on laissera ça comme un exercice pour les stagiaires,

+++
Devoir de vacances : déjà la solution ?

Ben oui parce que mon idée d'hier ("déjà une piste") n'étant pas bonne, je retourne à mes premières amours, c'est le code déjà posté :

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
    4:
      with Pix do
      if SrcInfo.Format = ifX8R8G8B8 then // jpt -- to deal with xrgb
      // move X_B_G_R (as recorded in file) to B_G_R_A (needed for good display)
      begin
        A := MulDiv(PColor32Rec(Src).B, 65535, 255);
        R := MulDiv(PColor32Rec(Src).A, 65535, 255);
        G := MulDiv(PColor32Rec(Src).R, 65535, 255);
        B := MulDiv(PColor32Rec(Src).G, 65535, 255);
      end else  // Format is ifA8R8G8B8
      begin
        A := MulDiv(PColor32Rec(Src).A, 65535, 255);
        R := MulDiv(PColor32Rec(Src).R, 65535, 255);
        G := MulDiv(PColor32Rec(Src).G, 65535, 255);
        B := MulDiv(PColor32Rec(Src).B, 65535, 255);
      end;

ce qui donne ça avec l'image 3x2 et 6 couleurs, où l'on voit bien que la transparence est prise en compte à la deuxième image et qu'on a donc bien affaire à un argb,




Mais pour continuer à faire fonctionner les neurones et avant d'écrire au monsieur, j'aimerais bien élucider le mystère de sa détection A8/X8, qui se goupille ainsi et que mes premiers tests ont montré non performants (me souviens pas si j'en ai déjà causé) :
ImagingBitmap, ligne 504

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
    if BI.AlphaMask = 0 then
    begin
      // Alpha mask is not stored in file (V3) or not defined.
      // Check alpha channels of loaded images if they might contain them.
      if Format = ifA1R5G5B5 then
      begin
        // Check if there is alpha channel present in A1R5GB5 images, if it is not
        // change format to X1R5G5B5
        if not Has16BitImageAlpha(Width * Height, Bits) then
          Format := ifX1R5G5B5;
      end
      else if Format = ifA8R8G8B8 then
      begin
        // Check if there is alpha channel present in A8R8G8B8 images, if it is not
        // change format to X8R8G8B8
        if not Has32BitImageAlpha(Width * Height, Bits) then
          Format := ifX8R8G8B8;
      end;
    end;

ImagingFormats, ligne 2181

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 Has32BitImageAlpha(NumPixels: LongInt; Data: PLongWord): Boolean;
var
  I: LongInt;
begin
  Result := False;
  for I := 0 to NumPixels - 1 do
  begin
    if Data^ >= 1 shl 24 then    // infobulle de debug sur Data^ = FFCA4508 avec 1x1x32 argb, CA450800 avec xrgb
    begin
      Result := True;
      Exit;
    end;
    Inc(Data);
  end;
end;

en français : si on décale le pixel FFCA4508 de 24 bits vers la gauche on va se retrouver avec FFCA4508000000, correct ?
En tout cas, c'est ce que me montre un ShowMessage de test, pas dans la boucle qui est appelée par PaintBoxPaint donc pagaille, mis ailleurs sous un bouton.
Et donc Data^ sera > à 1, on est d'accord.
Sauf que c'est idiot car si fichier xrgb, les 32 bits sont CA450800 et donc le décalage de 24 bits vers la gauche donne CA450800000000 et Data^ est encore > à 1,
ÀMHA il manque un masque, là, à "and"er avec le décalage. Non ?

Je vous laisse réfléchir à ça, faut que je bouge.

[BeanzMaster]

Salut piouf s'en est passé des choses hier

Je le redis 1 fois : une image voire même une vidéo sont assez simple à comprendre avec un peu de connaissance (même si certains algo comme la compression sont hardcore)
Mais le format BMP est un gloubi-boulga et le témoignage de l'évolution des cartes graphiques

Et pourtant à la base c'est simple : un format d'image non compressé, ou légèrement avec RLE.

Oui c'est simple pour TOI mais nous avons tous chacun des niveaux de compréhension différents. Un professeur est parfois obligé d'expliquer de plusieurs manières différentes une problématique avant que les élèves comprennent.

BI_ALPHABITFIELD tu oublies parce que spécifique WinCE et d'après la documentation Microsoft n'existe plus (sûrement en compatibilité)

Et ensuite je me méfie des valeurs BI_JPEG et BI_PNG.
Faire un jpeg ou un png avec un format bmp quel est l'avantage du truc ?
Et je suis persuadé qu'il n'y a que la bibliothèque de Microsoft qui puisse faire des bmp valides avec un jpeg/ png.

Ou ces trois là sont déconcertant et comme toi je ne vois pas ce que viens faire le JPEG et le PNG dans le BMP. Pour ce qui est du BI_ALPHABITFIELD su tu as des fichiers de ce format sur ton PC. Il faut le prendre en compte dans un outils de visualisation.

Ce n'est pas ce qui ressort : BI_BITFIELDS -> BITMAPV2INFOHEADER: RGB bit field masks, BITMAPV3INFOHEADER+: RGBA

Et il y a ambiguïté parce qu'on peut supposer que les formats BITMAPV2INFOHEADER et antérieur ne supportent pas le masque alpha (et ce serait logique si on regarde l'histoire)
Édit : C'est Jipété qui l'a confirmé. D'après son lien vers la documentation Microsoft, une vieille version de l'entête ne contient aucun masque et n'utilise que la table des couleurs.

Seuls les outils ferment les yeux et se débrouillent comme ils peuvent lorsqu'ils rencontrent BITMAPCOREHEADER/ BITMAPV1INFOHEADER/ BITMAPV2INFOHEADER et 1 canal alpha.

Ce qu'il en ressort, c'est que si tu veux les masques il faut mettre la compression à BI_BITFIELDS.

Oui d'après la documentation. Et comme tu les dis les outils ferment les yeux et certains ne respectent pas les standards.

Voici un exemple en pièce jointe : rgb32fakealpha.zip Le BMP est un BMP version 1 32 bits avec transparence sans BI_Bitfield définis
Voila comment il est s'affiche dans mon outil (notes il s'affiche également dans l'explorateur, mais sans transparence bien entendu) :

Et si ton image a des couleurs 32 bits, c'est la seule valeur possible. Parce que BI_RGB ne remplit que 24 bits et le canal alpha n'existe pas.
Quel est l'intérêt de vouloir des couleurs 32 bits sans canal alpha, et en sachant que le format BMP enregistre les lignes avec un multiple de 4 ?
Seuls les outils ferment les yeux et se débrouillent comme ils peuvent lorsqu'ils rencontrent BI_RGB et 32 bits ou bien BI_BITFIELDS, 24 bits et un canal alpha non vide.

Édit : d'après Microsoft il n'est pas valide d'avoir en même temps BI_BITFIELDS et 24 bits

Je n'ai encore jamais rencontré ce cas précis sur des bmp 24 bits. Mais c'est possible si il est mal encodé. Et comme toi je ne vois pas l'intérêt d'un canal Alpha dans ce cas
Par contre avec des BMP 32 bits seul les masques RGB peuvent être présent. Celui de l'apha peut-être omis. Tout dépend de la taille du GAPSIZE

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
        If (Compression = BMP_COMPRESSION_BITF) Then
        Begin
          With BitFields Do
          Begin
            If (FHeaderType = bmpht_WindowsV1) or (FHeaderType = bmpht_WindowsV4) or (FHeaderType = bmpht_WindowsV5) Then
            Begin
              If GapSize1 = 12 Then
              Begin
                Size := 12;
                RedMask := (Memory.ReadLongWord);
                GreenMask := (Memory.ReadLongWord);
                BlueMask := (Memory.ReadLongWord);
                AlphaMask := 0;
                AlphaShift := 0;
                AlphaSize := 0;
              End
              Else If GapSize1 = 16 Then
              Begin
                Size := 16;
                RedMask := (Memory.ReadLongWord);
                GreenMask := (Memory.ReadLongWord);
                BlueMask := (Memory.ReadLongWord);
                AlphaMask := (Memory.ReadLongWord);
              End
              Else If GapSize1 = 0 Then
              Begin
                If (FHeaderType = bmpht_WindowsV4) or (FHeaderType = bmpht_WindowsV5) Then
                Begin
                  Size := 16;
                  RedMask := GetHeaderRedMask;
                  GreenMask := GetHeaderGreenMask;
                  BlueMask := GetHeaderBlueMask;
                  AlphaMask := GetHeaderAlphaMask;
                End;
 
              End;
            End
            Else    // Version Windows 2 ou 3
            Begin
              Size := 12;
              RedMask := GetHeaderRedMask;
              GreenMask := GetHeaderGreenMask;
              BlueMask := GetHeaderBlueMask;
              AlphaSize := 0;
              AlphaMask := 0;
              If (FHeaderType > bmpht_WindowsV2) Then
              Begin
                Size := 16;
                AlphaMask := GetHeaderAlphaMask;
 
              End;
            End;
 
            RedShift := GetMaskShift(RedMask);
            GreenShift := GetMaskShift(GreenMask);
            BlueShift := GetMaskShift(BlueMask);
            AlphaShift := GetMaskShift(AlphaMask);
 
            RedSize := GetMaskSize(RedMask, RedShift);
            GreenSize := GetMaskSize(GreenMask, GreenShift);
            BlueSize := GetMaskSize(BlueMask, BlueShift);
            AlphaSize := GetMaskSize(AlphaMask, AlphaShift);
 
            If AlphaSize > 0 Then
            Begin
              // Le Mask Alpha cache-t-il une autre composante de la couleur
              If (RedMask or GreenMask or BlueMask) and AlphaMask <> 0 Then
              Begin
                AlphaMask := 0;
                AlphaShift := 0;
                AlphaSize := 0;
              End;
            End;
          End;
        End;

Les couleurs indexées sont à part. Elles sont stockées sur 32 bits, mais le canal alpha n'est pas géré (et ce serait logique si on regarde l'histoire)
Microsoft par contre l'autorise en spécifiant le drapeau "RGBQUAD.rgbReserved" pour les entêtes 4 et 5 ... et en même temps le désapprouve

Oui encore d'accord avec toi. Le problème c'est que Microsoft n'a pas été assez strict. De ce fait les logiciels spécialisés font un peu comme ils veulent.
La gestion des données du BMP est très intéressante. On peux stocké n'importe quel format pour les couleurs. D'ailleur si tu analyse les sources de la LCL tu te rendra comptes que la gestion des bitmaps est calqué sur ce schéma.

Et donc, c'est assez simple pour distinguer le format ARGB du format RGBA : il faut lire la valeurs des masques, et notamment celui du masque alpha.
Microsoft précise que les masques ne doivent pas se chevaucher (ce qui est logique)

Là encore un problème d'encodage avec les logiciels. De toutes les façon même Microsoft ne gère pas toutes les possibilités des BMP

Voila une vu de l'explorateurs (par exemples l'affichage des bmp avec du vert dans le texte "BMP" est incorrecte. Pour que l'affichage soit correcte il faut pré-multiplier les valeurs RGB avec l'aplha )



Toujours avec mon outil



Le seul fichier que je ne lis pas avec mon outil c'est le 1er "pal1huff.bmp" (mais j'y pense)

Sauf qu'on parle d'un format de stockage et non pas d'une représentation en mémoire. Si sur ton disque dur tes images sont stockées en bgra, tu vas avoir une différence lorsque tu vas essayer de la lire en argb.

Oui exacte, on s'est mal compris

Pour en revenir à Vampyre (vous n'êtes pas assis ? Vous devriez...), je me suis amusé à prendre un fichier 1x1x32_argb et à le recopier puis lui faire subir avec l'éditeur hexa le remplacement de BI_RGB en BI_BITFIELD et le remplacement de 08 45 CA FF par 00 08 45 CA et que croyez-vous qu'il arriva ?
Vampyre (modifié par ma bidouille d'hier) l'affiche avec mon bel orange, par contre Gimp comme le viewer Linux me sortent le marron sale.
Conclusion : certains utilisent les masques (et rendent mal les couleurs s'ils sont absents) et d'autres non.
C'est vraiment une pagaille désespérante.

Le problème ici c'est que les valeurs des masques sont décritent 2 fois. Une fois dans l'en-tête et un un fois après (Le GAPSIZE) si je ne me trompe pas. Vampyre lui tiens compte des masques présents dans le "GAPSIZE" alors que GIMP et ton visualiseur tiennent compte de celui de l'en-tête. Je ne sais pas, mais si en appliquant la convention d'espace de couleur décrite dans l'en-tête soit "sRGB" on devrait obtenir ton jolie orange. (http://www.ryanjuckett.com/programmi...ce-conversion/)

Code :

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

46h	4	42 47 52 73	little-endian "sRGB"			color space ????

Oui c'est bien pour décrire le Type de l'espace de couleur CIE

Fin du mystère : lorsque tu mets la compression à BI_RGB et le nombre de bits à 32 bits, le format bmp supporte le stockage des couleurs en BGRA.
Et c'est ce que j'avais noté : tu as bien 32 bits dans l'entête et j'ai cru à tort que c'était un maximum (<- en fait j'avais mal lu encore 1 fois ).

Je vais encore mettre la pagaille au niveau de la "gestion des DIB" avec GDI+ on peut avoir une description des pixels sur 64bits c'est dans la doc de microsoft mais je ne sais plus dans quelle section

Mais pour continuer à faire fonctionner les neurones et avant d'écrire au monsieur, j'aimerais bien élucider le mystère de sa détection A8/X8, qui se goupille ainsi et que mes premiers tests ont montré non performants (me souviens pas si j'en ai déjà causé) :

Je vous laisse réfléchir à ça, faut que je bouge.

Ce n'est peut-être qu'un impression, mais ce test me semble peux viable.

Pour ce qui est de savoir si il ya transparence ou pas comme je l'ai déja mentionné. Dans mon outil je teste directement la valeur Alpha (pour les formats 16 et 32 bits)

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
// 16 bits
DstColor := ConvertBitFieldsToBZColor(ImageDescription.BitFields, SrcColor16);
FIgnoreAlpha := FIgnoreAlpha and (DstColor.alpha = 0);
// 32 bits
DstColor := ConvertBitFieldsToBZColor(ImageDescription.BitFields, SrcColor);
FIgnoreAlpha := FIgnoreAlpha and (DstColor.alpha = 0);
 
  // Dans le cas ou tous les pixels sont transparent
  If FIgnoreAlpha Then
  Begin
    MakeOpaque;
    ImageDescription.HasAlpha := False;
    With ImageDescription.BitFields Do
    Begin
      AlphaSize := 0;
    End;
  End;

[Jipété]

Voici un exemple en pièce jointe : rgb32fakealpha.zip Le BMP est un BMP version 1 32 bits avec transparence sans BI_Bitfield définis
Voila comment il est s'affiche dans mon outil :

Mais pourquoi s'appelle-t-il rgb32fakealpha.bmp ?
Si ce fichier s'était appelé toto.bmp, un examen rapide aurait montré qu'il s'agit d'un argb, un fichier 32 bits tout bête où le canal alpha n'est pas toujours à FF.
Le voilà ouvert dans Gimp, en mode 'travail" si je puis dire, et on voit parfaitement la transparence appliquée à l'unique calque :


Par ailleurs, un examen à l'éditeur hexa montre clairement que le canal Alpha varie d'une ligne à la suivante de 00 à FF par pas de 4, pour pouvoir parcourir facilement la hauteur (64 px) : 00, 04, 08, 0C, etc.

Conclusion : ce fichier n'a rien de "fake", pour moi il est parfait.

[BeanzMaster]

Le problème ici c'est que les valeurs des masques sont décritent 2 fois. Une fois dans l'en-tête et un un fois après (Le GAPSIZE) si je ne me trompe pas. Vampyre lui tiens compte des masques présents dans le "GAPSIZE" alors que GIMP et ton visualiseur tiennent compte de celui de l'en-tête. Je ne sais pas, mais si en appliquant la convention d'espace de couleur décrite dans l'en-tête soit "sRGB" on devrait obtenir ton jolie orange. (http://www.ryanjuckett.com/programmi...ce-conversion/)

Oups j'ai pas eu le temps de rééditer avant. Petit imprévu. En fait il y avait encore un tapis et j'ai trébuché. C'est l'inverse, ce sont GIMP et ton visualiseur qui appliquent l'espace de couleur

[BeanzMaster]

Mais pourquoi s'appelle-t-il rgb32fakealpha.bmp ?
Si ce fichier s'était appelé toto.bmp, un examen rapide aurait montré qu'il s'agit d'un argb, un fichier 32 bits tout bête où le canal alpha n'est pas toujours à FF.

Par ailleurs, un examen à l'éditeur hexa montre clairement que le canal Alpha varie d'une ligne à la suivante de 00 à FF par pas de 4, pour pouvoir parcourir facilement la hauteur (64 px) : 00, 04, 08, 0C, etc.

Conclusion : ce fichier n'a rien de "fake", pour moi il est parfait.

Il a été nommé "fake" car par rapport aux conventions du format BMP. Le format BMP ne gère pas la transparence.

[foetus]

Voici un exemple en pièce jointe : rgb32fakealpha.zip Le BMP est un BMP version 1 32 bits avec transparence sans BI_Bitfield définis
Voila comment il est s'affiche dans mon outil (notes il s'affiche également dans l'explorateur, mais sans transparence bien entendu)

Justement, dans les entêtes il n'y a jamais la version de l'entête
La notion de version de l'entête 4, 5 core, ... c'est juste en gros une notion de programmation. Il faut presque savoir ce qu'il y a dedans - jusqu'à l'adresse 32h on connait les champs. Mais entre 32h et le début des données c'est le flou artistique.
Et on le voit bien : avec la compression BI_RGB les 4 masques disparaissent, mais on a encore l'espace de couleurs et la correction gamma.

Et donc, ton fichier est juste un fichier 32 bits BI_RGB qui supporte le canal alpha et avec l'explorateur Windows 10, la transparence passe correctement.
Ce serait un fichier bmp version 1.0 s'il y a avait seulement une palette de couleurs, mais ce n'est pas le cas : c'est un fichier avec des couleurs vraies 32 bits (<- et on le voit avec les icônes sur ton aperçu de l'explorateur Windows, les palettes de couleurs et le 16 bits ne gèrent pas la transparence)

Là encore un problème d'encodage avec les logiciels. De toutes les façon même Microsoft ne gère pas toutes les possibilités des BMP

Voila une vu de l'explorateurs (par exemples l'affichage des bmp avec du vert dans le texte "BMP" est incorrecte. Pour que l'affichage soit correcte il faut pré-multiplier les valeurs RGB avec l'alpha )

Justement, moi je trouve que les images 24 et 32 bits (avec transparence donc) passe correctement (et on peut penser aussi si les données de l'entête sont cohérentes comme, par exemple, les masques en 32 bits sont contigus et ne se chevauchent pas)

Mais effectivement les images avec des palettes de couleurs et avec des couleurs vraies 16 bits c'est la fête du slip ... ou peut être parce que cela fonctionne mais comme les couleurs sont contraintes sévères le résultat est de prime abord surprenant.

[BeanzMaster]

Justement, dans les entêtes il n'y a jamais la version de l'entête

La notion de version de l'entête 4, 5 core, ... c'est juste en gros une notion de programmation. Il faut presque savoir ce qu'il y a dedans - jusqu'à l'adresse 32h on connait les champs. Mais entre 32h et le début des données c'est le flou artistique.
Et on le voit bien : avec la compression BI_RGB les 4 masques disparaissent, mais on a encore l'espace de couleurs et la correction gamma.

C'est vrai, la version n'est pas explicitement indiqué par un numéro elle est définie à l'octet 15 juste après l'en-tête commune as tous les BMP par le paramètre présent dans tous les en-têtes de la v1 à v5 et OS/2x nommé biSize, bV4Size et bV5Size dans la documentation. Sinon comment lire les bonnes données si tu n'arrives pas à déterminer le bon en-tête ?

Et donc, ton fichier est juste un fichier 32 bits BI_RGB qui supporte le canal alpha et avec l'explorateur Windows 10, la transparence passe correctement.

La transparence est juste pas prise en charge dans l'affichage par l'explorateur et aussi dans Paint

Ce serait un fichier bmp version 1.0 s'il y a avait seulement une palette de couleurs, mais ce n'est pas le cas : c'est un fichier avec des couleurs vraies 32 bits (<- et on le voit avec les icônes sur ton aperçu de l'explorateur Windows, les palettes de couleurs et le 16 bits ne gèrent pas la transparence)

Qu'il y est ou pas une palette c'est un BMP version 1.0. Ca ne change rien. Si une palette aurais été présente, soit c'est un 8 bits et le biBitCount serai définis tel que. Soit la palette est juste là à titre informatif et est présente pour aider à une réduction et/ou analyse des couleurs

Pour info tu peux gérer de la transparence avec du 16 bits

Justement, moi je trouve que les images 24 et 32 bits (avec transparence donc) passe correctement (et on peut penser aussi si les données de l'entête sont cohérentes comme, par exemple, les masques en 32 bits sont contigus et ne se chevauchent pas)

Tout dépend des valeurs des masque, regardes sur la capture de l'explorateur (les chiffres à la fin des noms de fichier représente les décalage en bits des masques)
Mais comme je l'ai dis beaucoup de logiciel ou programmeur ne suivent pas les conventions du format. Celui-ci est très permissif justement à cause de ces "BitFields"

Je t'invite à tester toutes mes images de test https://github.com/jdelauney/BMP-ImageTestSuite avec plusieurs visualiseurs et les quelques solutions existantes sous Delphi et Lazarus.

Mais effectivement les images avec des palettes de couleurs et avec des couleurs vraies 16 bits c'est la fête du slip ... ou peut être parce que cela fonctionne mais comme les couleurs sont contraintes sévères le résultat est de prime abord surprenant.

Non les bmp avec palettes sont hypersimple chaque pixel correspond à un index dans la palette que ce soit un bmp 1 bit, 2,4 ou bits. Pour les 16 bits c'est comme le 32 bits, c'est un décalage de bits. Les masques peuvent d'ailleurs être aussi présents avec les bmp 16 bits. Par défaut, les décalages en bit sont R5G6B5. Ce qui donne RedMask := $00007C00; GreenMask := $000003E0; BlueMask := $0000001F;

[foetus]

Mais pour continuer à faire fonctionner les neurones et avant d'écrire au monsieur, j'aimerais bien élucider le mystère de sa détection A8/X8, qui se goupille ainsi et que mes premiers tests ont montré non performants

Ce que tu ne dis pas c'est comment tu récupères les 2 valeurs BI.AlphaMask et Format

Et à ce que je comprends c'est pour 2 cas :

• Pour une image couleurs vraies 16 bits, compression BI_RGB, quel est le format des couleurs ? X1R5G5B5 ou A1R5G5B5 ? (<- justement je me posais cette question)
• Pour une image couleurs vraies 32 bits, compression BI_BITFIELDS et un canal alpha désactivé (== 0), est-ce bien le cas ? Aucune couleur n'utilise la transparence ?

Donc pour répondre à ces 2 questions, tu testes toutes les couleurs (<- le truc de bourrin )


Parce que ce que tu oublies , lorsqu'on décale un entier de 4 octets, on obtient un entier de 4 octets et non pas de 8. Et donc le décalage gauche de 24 permet de tester l'octet le plus à droite (qui est censé être le canal alpha en "little endian")

Je retrouve cette info dans tous les fichiers générés par Gimp sauf si je coche la case "Ne pas inscrire l'information d'espace couleur" dans la rubrique d'export "Options de compatibilité".

C'est en réfléchissant à la version de 1.0 de BeanzMaster que je pense justement que c'est pour une compatibilité maximale.

Microsoft définit l'ordre des éléments dans un fichier bmp Bitmap : file header -> DIB header -> palette de couleurs -> données brutes -> profils ICC (sauf erreur de ma part)

Et c'est justement la partie DIB header et rien qu'elle qui a évolué au cours du temps en rajoutant toujours à la fin les nouveaux champs (<- il y a juste l'omission des masques dans certains cas qui n'est pas très bien expliqué )
Et donc un logiciel autant utilisé que GIMP est obligé de se caler sur la dernière version (la 4 (apparue avec Windows 95) puisque la version 5 (apparue avec Windows 98) tout le monde s'en cogne). D'où les champs color space et correction gamma présents mais inutiles.
De toute manière, lorsque tu regardes l'histoire des versions, seules les versions 4 et 5 existent, et la version 3 est une version officieuse d'Adobe pour gérer la transparence dans Photoshop.


Et c'est aussi justement pour cela que Microsoft a dû supporter des combinaisons de valeurs (par exemple 32 bits BI_RGB) parce qu'en rajoutant à chaque fois, on arrive à des ambiguïtés, à des doublons.
Mais il reste un truc : apparemment Microsoft ne supporte pas le 24 bits BI_BITFIELDS, mais cela peut être intéressant de gérer le format A6R6G6B6 ou A8R5G6B5

[BeanzMaster]

Ce que tu ne dis pas c'est comment tu récupères les 2 valeurs BI.AlphaMask et Format

La valeur des masques peux être dans deux endroits :

• Soit dans les en-têtes de la version 3 à 5 (notez que dans l'en-tête version 2 le masque Alpha n'est pas présent, il a fait sont apparition que depuis la 3)
• Soit dans ce fameux "GAPSIZE" (présent après les en-tête et avant les données). Ce GapSize a alors une taille de 12 octets ou de 16 octets (12 = Masques RGB, 16 = Masque RGBA)

Attention il y a des pièges (forcément) si une palette est présente il faudra faire un petit calcul pour déterminer la taille du "bitfields" 12 ou 16. Pour des BMP dont le biBitCount est égal à 32 bits, le GapSize peux avoir une taille de 12 octets donc le masque alpha n'est alors pas définis.

Et à ce que je comprends c'est pour 2 cas :

• Pour une image couleurs vraies 16 bits, compression BI_RGB, quel est le format des couleurs ? X1R5G5B5 ou A1R5G5B5 ? (<- justement je me posais cette question)
• Pour une image couleurs vraies 32 bits, compression BI_BITFIELDS et un canal alpha désactivé (== 0), est-ce bien le cas ? Aucune couleur n'utilise la transparence ?

Les 16 bits et 32 bits se gèrent de la même manière avec les masques. Ils peuvent soit être BI_RGB soit BI_BITFIELDS
Si le canal Alpha est désactivé, masque, taille et décalage à zero alors oui c'est bien ça, aucune couleur n'utilise la transparence, on pourrait l'apparenté à un vulgaire bmp 24 bits.

Donc pour répondre à ces 2 questions, tu testes toutes les couleurs (<- le truc de bourrin )

C'est un peu comme ça que j'ai fait d'ailleurs. J'ai même rajouté un test pour savoir si tous les pixels sont opaques. Pis ce n'est pas si bourrin que ça et le test est rapide. Et juste tester la taille du masque alpha, n'as pas l'air de suffire quoi qu'il en soit.

Code :

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

1
2
3
 
  FIgnoreAlpha := FIgnoreAlpha and (DstColor.alpha = 0);
  IsOpaque := IsOpaque and (DstColor.alpha = 255);

Après ça il facile de déduire si l'image utilise la transparence. Si FIgnoreAlpha est vrai alors tous les pixels sont transparent, si IsOpaque est vrai alors tous les pixels sont opaque. Si les 2 sont faux alors il y a transparence

Cet après midi j'ai justement approfondi la chose sur ce format XRGB. J'ai fait plusieurs test avec les fichiers de la BMP-TestSuite officielle
Il en ressort que peux importe que les valeurs Alpha décodées soient à Zero ou définies à 255. Les deux valeurs à tester en plus sont surtout la taille du masque Alpha et la tailles du BitField

Code :

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

if ((ImageDescription.BitFields.AlphaSize=0) and (ImageDescription.BitFields.Size=16))  then ColorFormat := cfXRGB

En effet si la taille du masque alpha est supérieur à 0 ce n'est pas un XRGB, mais en plus il faut prendre en compte que si le masque Alpha est présent que sa taille soit à zero et que la taille du GapSize est égale à 12 alors ce n'est pas un XRGB car le masque alpha est alors celui par défaut.
Je n'ai pas testé avec des BMP 16 bits, mais je pense que cela doit-être pareil (enfin j'espère)

Parce que ce que tu oublies , lorsqu'on décale un entier de 4 octets, on obtient un entier de 4 octets et non pas de 8. Et donc le décalage gauche de 24 permet de tester l'octet le plus à droite (qui est censé être le canal alpha en "little endian")

Tu as raison, le seul truc c'est que dans cet exemple qui induit en erreur c'est que vampyre fonctionne avec des pixels sur 64 bits comme FPImage de la FCL. C'est pour ça que j'ai l'impression que ce test n'est pas viable, mais je trompe surement.

[foetus]

Soit dans ce fameux "GAPSIZE" (présent après les en-tête et avant les données). Ce GapSize a alors une taille de 12 octets ou de 16 octets (12 = Masques RGB, 16 = Masque RGBA)

C'est là que j'ai du mal : tu veux dire que certains génèrent des fichiers .bmp en replaçant la partie DIB header par ... ce qu'ils veulent

Parce que déjà cette partie c'est du flou artistique (version 4 ou 5, présence des 4 masques ou pas en fonction de la compression) qu'il faut être complétement suicidaire en ne respectant pas la diarrhée explicative de Microsoft
Tu m'étonnes que ton jeu de test, c'est plus un jeu de loterie en fonction du logiciel
Le format .bmp c'est de la m$rd$, mais il y a quand même des choses qui fonctionnent avec une énorme compatibilité Windows/ logiciel lorsque c'est dans les clous.

Parce que pour moi c'est simple : il faut regarder la compression et le nombre de bits et ensuite la valeur des masques s'ils sont présents.
Et ensuite, pour certains cas comme le 16 bits BI_RGB ou le 24 bits BI_RGB (<- Microsoft ne semble pas le valider celui-ci), tu peux tester toutes les couleurs pour t'ôter des doutes.

Parce que pour moi c'est un faux problème : une image en 32 bits XRGB n'a pas lieu d'exister et doit être remplacée par une image 24 bits, mais pourquoi pas parce que son traitement est transparent.
Seuls les onanistes du détail héxadécimal s'en apercevront

[Jipété]

Bonsoir les copains,

Pour le décalage :

Code :

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

ShowMessage(IntToStr($FFCA4508 shl 24));// si fichier argb

Résultat :


Une idée me vient, le faire en deux temps :

Code :

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

1
2
  tst := $FFCA4508 shl 24;
  ShowMessage(IntToStr(tst));

Mais pas mieux, le résultat est toujours >= 1 :



Quant aux masques, comme déjà dit, je m'en tamponne allègrement le coquillard ! Ayant constaté qu'avec un quatrième canal présent à la création de l'image je n'aurai que deux exports possibles (argb/xrgb) et qu'un examen à l'éditeur hexa montre l'emplacement du byte concerné, le reste est un jeu d'enfant car je n'ai pas la prétention ni l'intention de décoder tous les fichiers .bmp de la Terre, surtout ceux mal construits, ou avec des paramétrages exotiques ou tordus.

J'avance avec mon temps, alors les fichiers 16 bits, ou 15 ou moins encore, c'était bon à l'époque des cartes vidéo VGA avec 4 Mo de mémoire, et je crois qu'on a évolué.

Maintenant, si un jour quelqu'un débarque avec une diskette et des fichiers dessus et sort de sa poche des dollars qu'il me met dans la main ou un couteau qu'il me met sur la gorge, bah, je ressortirai les codes de Jérome et/ou Vampyre, et je verrai bien ce que je peux faire,

En attendant, je me cantonne aux 24/32 bits, en lorgnant de temps en temps vers les 48/64 bits, histoire de préparer l'avenir.
Pas vous ?

[foetus]

Mais pas mieux, le résultat est toujours >= 1 :

Parce que ta couleur est en "big endian"

Dans un fichier .bmp ta couleur $FFCA4508 est stockée $0845CAFF.
Et là tu vois que le canal alpha (FF) est le plus à droite et donc IntToStr(tst) == $FF

Et pour vampyre, pas de transparence : alpha == 0

Quant aux masques, comme déjà dit, je m'en tamponne allègrement le coquillard !

Et pourtant avec la compression BI_BITFIELDS tu définis exactement la place de tes composants RGBA et tu n'es pas dépend comme avec la compression BI_RGB de Microsoft, de son support ou pas du canal alpha et du format utilisé
Et limite avec les masques, tu ne prends en compte que du 32 bits soit en XRGB/ ARGB soit en RGBX/ RGBA.

[Jipété]

Parce que ta couleur est en "big endian"

Je redonne la fonction de test :

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 Has32BitImageAlpha(NumPixels: LongInt; Data: PLongWord): Boolean;
var
  I: LongInt;
begin
  Result := False;
  for I := 0 to NumPixels - 1 do
  begin
    if Data^ >= 1 shl 24 then    // FFCA4508 avec argb, CA450800 avec xrgb
    begin
      Result := True;
      Exit;
    end;
    Inc(Data);
  end;
end;

Le commentaire, c'est ce qui s'affiche dans l'infobulle de débug quand je mets un point d'arrêt sur la ligne if Data^ et la souris sur Data, et on voit ce qui est remonté par le système, pas par moi : je fais avec ce que me donne le système.

Ensuite, comme il n'est pas possible de mettre un ShowMessage dans cette fonction (trop liée au PaintBoxPaint), j'ai noté les valeurs et j'ai utilisé un bête bouton pour simuler le test en écrivant en dur les valeurs.

C'est tout.

Et pour vampyre, pas de transparence : alpha == 0

Pour moi, alpha à 0 c'est tellement transparent qu'on ne voit pas l'image. Kess' tu veux dire exactement, là ?

Et limite avec les masques, tu ne prends en compte que du 32 bits soit en XRGB/ ARGB soit en RGBX/ RGBA.

soit en XRGB / RGBA soit en XRGB / RGBA et plus précisément XBGR / BGRA

[BeanzMaster]

C'est là que j'ai du mal : tu veux dire que certains génèrent des fichiers .bmp en replaçant la partie DIB header par ... ce qu'ils veulent

Parce que déjà cette partie c'est du flou artistique (version 4 ou 5, présence des 4 masques ou pas en fonction de la compression) qu'il faut être complétement suicidaire en ne respectant pas la diarrhée explicative de Microsoft
Tu m'étonnes que ton jeu de test, c'est plus un jeu de loterie en fonction du logiciel
Le format .bmp c'est de la m$rd$, mais il y a quand même des choses qui fonctionnent avec une énorme compatibilité Windows/ logiciel lorsque c'est dans les clous.

Parce que pour moi c'est simple : il faut regarder la compression et le nombre de bits et ensuite la valeur des masques s'ils sont présents.
Et ensuite, pour certains cas comme le 16 bits BI_RGB ou le 24 bits BI_RGB (<- Microsoft ne semble pas le valider celui-ci), tu peux tester toutes les couleurs pour t'ôter des doutes.

Parce que pour moi c'est un faux problème : une image en 32 bits XRGB n'a pas lieu d'exister et doit être remplacée par une image 24 bits, mais pourquoi pas parce que son traitement est transparent.
Seuls les onanistes du détail héxadécimal s'en apercevront

Ouep en gros c'est ça. Le truc qui a fait mal c'est que crosoft n'a pas crue bon limiter les choix au niveau de la standardisation et fils des nouvelles versions et de supprimer ce "GapSize" qui embrouille tout.
Mais il est vrai que la structure en elle même, et la technique du bitfield est excellente. Et ça ne me m'étonne pas que les dev de lazarus s'en soit inspiré malheureusement pas assez bien

Un autre format de fichier très anarchiques c'est le GIF comme on l'as vu avec Jipete. Il est pas mal dans son genre lui aussi avec sa panoplie de logiciels qui ne respectent pas les standards.

Bonsoir les copains,

Quant aux masques, comme déjà dit, je m'en tamponne allègrement le coquillard ! Ayant constaté qu'avec un quatrième canal présent à la création de l'image je n'aurai que deux exports possibles (argb/xrgb) et qu'un examen à l'éditeur hexa montre l'emplacement du byte concerné, le reste est un jeu d'enfant car je n'ai pas la prétention ni l'intention de décoder tous les fichiers .bmp de la Terre, surtout ceux mal construits, ou avec des paramétrages exotiques ou tordus.

J'avance avec mon temps, alors les fichiers 16 bits, ou 15 ou moins encore, c'était bon à l'époque des cartes vidéo VGA avec 4 Mo de mémoire, et je crois qu'on a évolué.

Maintenant, si un jour quelqu'un débarque avec une diskette et des fichiers dessus et sort de sa poche des dollars qu'il me met dans la main ou un couteau qu'il me met sur la gorge, bah, je ressortirai les codes de Jérome et/ou Vampyre, et je verrai bien ce que je peux faire,

En attendant, je me cantonne aux 24/32 bits, en lorgnant de temps en temps vers les 48/64 bits, histoire de préparer l'avenir.
Pas vous ?

Salut,

Bien d'accord et je crois que je vais clairement laisser tomber la compression Huffman trop de bouleau pour pas grand chose. Mais je suis plutôt content de pouvoir afficher mes BMP mieux que beaucoup de soft y compris firefox, et autres grosses usines à gaz . Et comme toi a part les 24 et 32 bits avec ou sans transparence le reste je n'en ai pas l'utilité.

Le 64 bits et les 128 bits oui carrément surtout pour les optimisations avec les instructions SIMD (j'ai quelques idées la-dessus, mais ce ne sera pas pour demain). Le 48bits c'est du blablacar pour le 24bits aucun intérêts à mon avis. A moins que le 48bits ne soit utilisé directement en RGBA (12 bits par composantes) mais là encore autant utiliser le 64 bits bien mieux adapter pour les optimisations.

Allez avant le prochain format, faut que je termine le PNG et je passe au TIFF, je sens que je vais bien rigoler avec celui-là aussi

[foetus]

Pour moi, alpha à 0 c'est tellement transparent qu'on ne voit pas l'image. Kess' tu veux dire exactement, là ?

C'est de la logique pour moi :

• Si tu fais un décalage de bits, c'est pour isoler une partie, positionner des valeurs ou faire des multiplications/ divisions par puissance de 2. Mais effectivement si cela est sur 8 octets, isoler 5 octets est très bizarre
• Il y a 4 composantes : RGBA. La seule composante qui pose question est la composante alpha. Après si le codeur teste le vert ou le rouge, pourquoi pas, mais pour moi cela ne sert strictement à rien.
• Si on fait un test "supérieur ou égal à 1", cela veut dire que pour le codeur, la valeur particulière est 0. Et effectivement pour une composante alpha ce serait plus $FF, mais bon étant désactivée on peut mettre ce qu'on veut

soit en XRGB / RGBA soit en XRGB / RGBA et plus précisément XBGR / BGRA

Pour le format .bmp, effectivement c'est plus du BGR

Bien d'accord et je crois que je vais clairement laisser tomber la compression Huffman trop de bouleau pour pas grand chose.

Effectivement il reste 2 compressions BI_RLE8 et BI_RLE4 dont personne ne parle et peut être intéressantes à utiliser.

Mais je suis plutôt content de pouvoir afficher mes BMP mieux que beaucoup de soft y compris firefox, et autres grosses usines à gaz .

Cela dépend du contexte, mais à quoi bon. Tu fais comme Gimp : tu te cales sur la version 4, 24/ 32 bits et point barre.

À moins de vouloir faire une fonction qui détecte et corrige les erreurs dans les entêtes.

Le 64 bits et les 128 bits

Déjà je n'utilise jamais le format .bmp et privilégie le format .png ou alors les formats simples comme Netpbm (<- lien wiki en anglais) (compressé avec bzip2)

Mais je sais que Microsoft a travaillé sur un nouveau format JPEG XR et entre autre, le support du HDR.
Parce que étendre les couleurs à 48 - 64 bits pourquoi pas, mais derrière je pense qu'il y a plus que cela.

Allez avant le prochain format, faut que je termine le PNG et je passe au TIFF, je sens que je vais bien rigoler avec celui-là aussi

J'ai essayé les exemples simples d'ouverture et de lecture avec les bibliothèques libPNG et libTIFF en langage C :

• libPNG, le code est un peu long, il faut garder 2-3 trucs mais cela fonctionne correctement
• libTIFF impossible de faire fonctionner l'exemple trivial. De souvenirs, c'est un bordel