Discussion :

[Jipété]

Yep !

• 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

et le test sert à quoi, alors ?

EDIT : je l'ai eu !
Ce test doit être du code Delphi, qui doit se comporter autrement que Lazarus (je l'ai montré hier soir tard avec ma manip en deux temps), alors j'ai retenté le coup et là, ça fonctionne as expected !

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

/EDIT
Mais ça c'est juste la détection xbgr (puisque par défaut Vampyre démarre en bgra), il faut ensuite faire le croisement des bytes tel qu'exprimé dans le devoir de vacances pour avoir le bel orange, don't forget that !

Parce que étendre les couleurs à 48 - 64 bits pourquoi pas, mais derrière je pense qu'il y a plus que cela.

Il y a le fait qu'on peut avoir des dégradés magnifiques, alors que les 8 bits présentent très vite des effets de sauts d'une couleur à la suivante, voir page 78 de "La gestion des couleurs" par Jean Delmas, si vous êtes sages je ferai une photo de l'exemple, c'est assez impressionant.

• libTIFF impossible de faire fonctionner l'exemple trivial. De souvenirs, c'est un bordel

On avait travaillé dessus avec Yves et peut-être d'autres il y a qq années, mais je ne le retrouve pas, l'outil de recherche est en vrac...

[foetus]

et le test sert à quoi, alors ?

Moi je pensais que c'était tester la composante alpha à zéro. Mais d'après ce que vous me dites, c'est tester 5 octets à zéro : c'est bizarre

Il faut demander à l'auteur de ce magnifique code

Et l'autre truc, c'est qu'il teste en premier la valeur du masque alpha et ensuite le format : c'est en mode parano - il veut créer un format XRGB qui n'est pas pertinent pour moi d'exister.
D'ailleurs mes remarques et ces commentaires en atteste :

// Alpha mask is not stored in file (V3) or not defined. Check alpha channels of loaded images if they might contain them.

// Check if there is alpha channel present in A1R5GB5 images, if it is not change format to X1R5G5B5

// Check if there is alpha channel present in A8R8G8B8 images, if it is not change format to X8R8G8B8

[Jipété]

un format XRGB qui n'est pas pertinent pour moi d'exister.

Peut-être, sans doute, cependant il existe, puisque The Gimp sait le créer,

Àmha c'est l'équivalent d'un bgr 24 bits sans les contraintes du padding, non ?

Attention, j'ai édité mon message précédent après ton post, relis-le.

[BeanzMaster]

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

C'est exactement pour ça que la procédure de Vampyre me semble chelou

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

Ces deux mode sont identique c'est du RLE le premier pour les 8 bits le deuxième pour les 4bits. C'est déja fait de mon coté

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.

Je ne sais pas d'ou est sortie ce mode XBGR mais une chose est sure il n'est pas officiel

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)

Compressé avec BZip2 t'es sure de ton coup. Car j'ai implementé ce format (sauf le PAM que je n'ai pas fini) Et nul part j'ai vue mentionné BZip. Tu aurais un lien autre que le wiki a ce sujet ?

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.

Ce que je sais c'est que les carte graphique n'envoye pas les données en 32bits sur des écrans 4k si je me souviens bien le nombre de bit par composante de couleurs est 10 mais je ne me souviens plus pour l'alpha, je n'en suis par sûre

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

Oui je connais ces librairie, LibPng est excellente. LibTiff ne sempble plus être mise à jour depuis quelques temps déja. Il semble difficile de trouver les bonnes librairie avec les bonnes déclarations d'en-tête. Mais but est justement d'eviter d'utiliser des bibliothèques externes. Dans mon projet pour le JPEG j'utilise les unités fournis avec FPC. Sinon c'est du fait maison. Pour l'instant j'ai déja le BMP PCX, TGA, PixMap( pbm, ppm, pgm, pfm) , XPM, GIF et le JPEG. Le PNG est en cours ensuite j'ai d'autres petits formats simple à mettre en place comme le HDR, RLA, DDS, KTX et 2 trois autres de moindre importance.

Yep !

et le test sert à quoi, alors ?

EDIT : je l'ai eu !
Ce test doit être du code Delphi, qui doit se comporter autrement que Lazarus (je l'ai montré hier soir tard avec ma manip en deux temps), alors j'ai retenté le coup et là, ça fonctionne as expected !

Moi je pensais que c'était tester la composante alpha à zéro. Mais d'après ce que vous me dites, c'est tester 5 octets à zéro : c'est bizarre

A mon avis ce n'est pas une différence Delphi/Lazarus mais un erreur de l'auteur. Mais comme foetus, je ne saisi pas en quoi il teste 5 octets en faisant un décalage. Pourquoi ne pas tester directement la valeur Alpha ? De plus Data, ce sont les donnée brute du fichier ou ce sont les donnée de l'image finale ? surtout qu'en plus tester seulement la valeur Alpha n'est pas viable à 100% pour détecter un XBGR. Après je pense comprendre pourquoi lorsque l'on regarde le schéma sur les bitfield que Yves à poster l'auteur as fait comme ça. Mais faudrait poser lui question directement, seul lui peux répondre à ce mystère.

Àmha c'est l'équivalent d'un bgr 24 bits sans les contraintes du padding, non ?

En gros oui c'est ça

[Jipété]

Moi je pensais que c'était tester la composante alpha à zéro.

C'est ce qu'il me semble aussi, d'autant plus que c'est le comportement que j'obtiens, suite à ma modif "en deux temps".

Mais d'après ce que vous me dites, c'est tester 5 octets à zéro : c'est bizarre

Mais comme foetus, je ne saisis pas en quoi il teste 5 octets en faisant un décalage

Mais qu'est-ce que vous avez, tous les deux, avec ce 5 ?
Partant d'un integer sur 32 bits, si je décale à gauche de 24 bits, je perds ces 24 il m'en reste 8, et comme c'est un integer, les 24 apparus à droite seront remplis de 0 et voilà.

Il me semble que la copie d'écran d'hier était parlante, non ?

Code :

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

1
2
3
4
5
6
7
8
procedure TForm1.Button3Click(Sender: TObject);
var
  tst: integer;
begin
  Caption := '$FFCA4508' + ' ' + IntToStr($FFCA4508);
  tst := $FFCA4508 shl 24;
  ShowMessage(IntToStr(tst));
end;

Attention au piège visuel (je viens de tomber dedans) avec le 8000000 : il faut le lire avec 4 zéros devant, comme ça :

Code :

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

1
2
3
4
1111 1111 1100 1010 0100 0101 0000 1000 // avant le shl 24
  F    F    C    A    4    5    0    8
0000 1000 0000 0000 0000 0000 0000 0000 // après le shl 24
  0    8    0    0    0    0    0    0

PS : depuis le début je dis que ce test ne vaut rien pour détecter un xbgr et qu'il vaut mieux se fier au if BI.Compression = BI_BITFIELD,

+++
Bon, vous avez été sages ? Alors voilà, chose promise chose tenue :


et le texte de la page suivante :

Pour vous convaincre de l'intérêt d'une profondeur de couleur de 16 bits, voici un dégradé, dont les couleurs sont définies tour à tour sur 8 bits et 16 bits par composante.
Avec Photoshop, nous lui avons infligé une sévère opération d'accentuation, c'est-à-dire d'augmentation de la netteté des contours [...]. De telles corrections, quand elle sont conduites imprudemment (ce qui est le cas ici), peuvent dévaster les zones de transition progressive des couleurs par la génération de vilaines bandes fantômes perpendiculaires à la direction du dégradé.
L'exemple donné ici n'a pas pour objectif de montrer quelle est la dégradation, souvent négligeable, infligée à une image sur 8 bits par une opération d'accentuation raisonnable, mais de prouver combien une profondeur de couleur de 16 bits est capable de préserver sa qualité, même quand on lui applique une correction brutale, voire aberrante.

[foetus]

Je ne sais pas d'ou est sortie ce mode XBGR mais une chose est sure il n'est pas officiel

Lorsque tu vois les "monstres" sur cette page (peut-être la tienne d'ailleurs *), et la compression BI_BITFIELDS peut tout faire, alors XBGR c'est le plus gentil.

Il faudrait tester des images au couleurs GRAB ou BAGR cela peut être amusant


* -> d'ailleurs, je le redis mais toutes les images ne s'affichent pas certes, mais au vu des erreurs et du grand nombre qui s'affichent, cette page montre que si on reste dans les clous, il n'y aura quasi aucun problème.

Compressé avec BZip2 t'es sure de ton coup. Car j'ai implementé ce format (sauf le PAM que je n'ai pas fini) Et nul part j'ai vue mentionné BZip. Tu aurais un lien autre que le wiki a ce sujet ?

Étant un format non compressé comme le format .bmp, on peut les fournir en les compressant "à la main" : on rajoute une étape en plus lors de la manipulation.

Mais comme tu n'utilises aucunes bibliothèques externes, c'est mort, mais la libbzip2 est sympa en C

Mais qu'est-ce que vous avez, tous les deux, avec ce 5 ?

BeanzMaster pensait que Vampyre manipulait des entiers 64 bits donc 8 octets.

Et donc 12345678 shl 24 -> 45678000, donc 5 octets qui restent
Mais en 32 bits, 1234 shl 24 -> 4000, donc 1 octet qui reste, mais c'est le plus à droite.

PS : depuis le début je dis que ce test ne vaut rien pour détecter un xbgr et qu'il vaut mieux se fier au if BI.Compression = BI_BITFIELD,

Un peu normal non lire les entêtes et ne pas faire de la magie vaudou et autres analyses stochastiques en parcourant les données brutes.

[BeanzMaster]

C'est ce qu'il me semble aussi, d'autant plus que c'est le comportement que j'obtiens, suite à ma modif "en deux temps".




Mais qu'est-ce que vous avez, tous les deux, avec ce 5 ?
Partant d'un integer sur 32 bits, si je décale à gauche de 24 bits, je perds ces 24 il m'en reste 8, et comme c'est un integer, les 24 apparus à droite seront remplis de 0 et voilà.

Il me semble que la copie d'écran d'hier était parlante, non ?

Code :

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

1
2
3
4
5
6
7
8
procedure TForm1.Button3Click(Sender: TObject);
var
  tst: integer;
begin
  Caption := '$FFCA4508' + ' ' + IntToStr($FFCA4508);
  tst := $FFCA4508 shl 24;
  ShowMessage(IntToStr(tst));
end;

Attention au piège visuel (je viens de tomber dedans) avec le 8000000 : il faut le lire avec 4 zéros devant, comme ça :

Code :

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

1
2
3
4
1111 1111 1100 1010 0100 0101 0000 1000 // avant le shl 24
  F    F    C    A    4    5    0    8
0000 1000 0000 0000 0000 0000 0000 0000 // après le shl 24
  0    8    0    0    0    0    0    0

Et après ta fabuleuse manipe il te restes la composante bleu 08 de ton beau orange, super comme test pour la valeur de la composante Alpha

PS : depuis le début je dis que ce test ne vaut rien pour détecter un xbgr et qu'il vaut mieux se fier au if BI.Compression = BI_BITFIELD,

Pourquoi tu persistes alors ?

Un truc simple simple t'essayes avec les fichiers que j'ai montré dans ma dernière anim en gif et tu seras tout de suite fixé

Lorsque tu vois les "monstres" sur cette page (peut-être la tienne d'ailleurs *), et la compression BI_BITFIELDS peut tout faire, alors XBGR c'est le plus gentil.

Il faudrait tester des images au couleurs GRAB ou BAGR cela peut être amusant


* -> d'ailleurs, je le redis mais toutes les images ne s'affichent pas certes, mais au vu des erreurs et du grand nombre qui s'affichent, cette page montre que si on reste dans les clous, il n'y aura quasi aucun problème.

Oui c'est bien cette page. Après rester dans les clous c'est vite dit. Ce n'est pas si simple que cela et il vaut dévier et faire des tours de passes passes suivants les fichiers. Ici il n'y a pas tous les fichiers de cette suite
Masi ce qui m'interloque ce sont les représentations correctes des fichiers "q/pal8rletrns.bmp", "q/pal8rlecut.bmp" , "q/pal4rlecut.bmp" et "q/pal4rletrns.bmp". 3 bonnes réponses, par image. Comment tu l'expliques ?

Étant un format non compressé comme le format .bmp, on peut les fournir en les compressant "à la main" : on rajoute une étape en plus lors de la manipulation.
Mais comme tu n'utilises aucunes bibliothèques externes, c'est mort, mais la libbzip2 est sympa en C

Ha ok, mais ça c'est toi, ça n'a rien à voir avec la description officielle du format. En ce faisant je peux alors utiliser directement la compression avec ZLIb présente dans FPC. Ou je peux faire un 7z ou un zip. Cela n'a aucune valeur légale dans ce contexte d'utiliser BZip2. Et pourquoi ne pas l'appliquer aux BMP dans ce cas aussi ?.

Bon, vous avez été sages ? Alors voilà, chose promise chose tenue :

Merci
Bah c'est normal ça et si tu utilises des nombre à virgule flottante c'est encore mieux Single = 32 bits, Double =64 bits, Extend = 80 bits (si je ne me trompe pas)
C'est clair qu'avec du 8 bit dès que ton dégradé dépasse les 256 couleurs il commence à avoir des artefacts c'est logique. la conversion 8 vers 16 puis re-vers 8 bits (ben oui nos écrans n'affichent pas en 16bits par canal) cela atténue les effets disgracieux.

Mais ici dans le cas du chargement du'un BMP je vois pas en quoi ca va améliorer les couleurs. Par contre dans l'application de filtres il est certain que cela peux jouer sur la qualité

[Jipété]

Et après ta fabuleuse manip il te reste la composante bleu 08 de ton beau orange, super comme test pour la valeur de la composante Alpha

N'est-ce pas !

Pourquoi tu persistes alors ?

C'est pour voir si vous suivez,
Nan, sans rire, c'est pour essayer de comprendre sa fichue mécanique, qui n'est pas si évidente que ça, avec une aide pas à jour et des exemples qui ne compilent plus suite à changements de noms de choses...

Merci
Bah c'est normal ça et si tu utilises des nombre à virgule flottante c'est encore mieux Single = 32 bits, Double =64 bits, Extend = 80 bits (si je ne me trompe pas)

Je te dis pas la taille des fichiers, alors...
Heureusement qu'ils ont inventé les disques de plusieurs teras !

Mais ici dans le cas du chargement du'un BMP je vois pas en quoi ça va améliorer les couleurs. Par contre dans l'application de filtres il est certain que cela peut jouer sur la qualité

Ben voilà.
Pi faut savoir ce genre de choses, pour la culture générale et se la péter un soir entre amis au... restau !

[foetus]

Mais ici dans le cas du chargement du'un BMP je vois pas en quoi ca va améliorer les couleurs. Par contre dans l'application de filtres il est certain que cela peux jouer sur la qualité

Comme je l'ai dit : il faut voir au delà du passage 24/ 32 -> 48/ 64
Parce que même si on passe à des nombres flottants effectivement, ce ne changera pas l'ouverture.

Par contre, avec le HDR, et si j'ai bien compris, il faudra lire pour chaque point une couleur + une intensité. Cela complique le bouzin

Masi ce qui m'interloque ce sont les représentations correctes des fichiers "q/pal8rletrns.bmp", "q/pal8rlecut.bmp" , "q/pal4rlecut.bmp" et "q/pal4rletrns.bmp". 3 bonnes réponses, par image. Comment tu l'expliques ?

D'après ce que je comprends (je n'ai pas analysé les fichiers à l'éditeur héxa ), mais la compression RLE créé des trous. Donc c'est un peu normal que les logiciels soient perdus et adoptent des "contournements".
En plus on parle de fichiers avec des couleurs indexées + compression RLE : ce sont pire que des reliquats des années 90 - Windows 3.1.

Ha ok, mais ça c'est toi, ça n'a rien à voir avec la description officielle du format. En ce faisant je peux alors utiliser directement la compression avec ZLIb présente dans FPC. Ou je peux faire un 7z ou un zip. Cela n'a aucune valeur légale dans ce contexte d'utiliser BZip2. Et pourquoi ne pas l'appliquer aux BMP dans ce cas aussi ?.

Tu peux appliquer une compression "à la main" pour tout fichier non compressé (.bmp compris) et effectivement pas que bzip2.

[BeanzMaster]

Bon allez je vais vous la faire courte, et comme quoi on peux faire des chose vachement bien avec Lazarus et FPC et en pascal en général, même mieux que le C (nan je rigole c'est surtout le code et le codeur qui font tout après le langages n'est qu'un outils) C'est comme en cuisine même avec des couteaux et des casseroles tout pourris et des aliments moyens c'est l'homme derrière son fourneau et sa recette qui font toute la différence.

Allez juste une tchite video pour vous faire rager avec ces BMP

Pour ce qui est du XBGR je te remet la formule magique à tenter d'appliquer dans Vampyre

Code :

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

1
2
3
4
5
    if ImageDescription.PixelFormat = pf32bits then
      if ((ImageDescription.BitFields.AlphaSize=0) and (ImageDescription.BitFields.Size=16)) then
      begin
         ImageDescription.ColorFormat := cfXBGR;
      End;

[Jipété]

Pour ce qui est du XBGR je te remets la formule magique à tenter d'appliquer dans Vampyre

Code :

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

1
2
3
4
5
    if ImageDescription.PixelFormat = pf32bits then
      if ((ImageDescription.BitFields.AlphaSize=0) and (ImageDescription.BitFields.Size=16)) then
      begin
         ImageDescription.ColorFormat := cfXBGR;
      End;

et moi je remets la formule que j'applique dans Vampyre :

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
    case BI.BitCount of
      1, 4, 8: Format := ifIndex8;
      16:
        if BI.RedMask = $0F00 then
          // Set XRGB4 or ARGB4 according to value of alpha mask
          Format := IffFormat(BI.AlphaMask = 0, ifX4R4G4B4, ifA4R4G4B4)
        else if BI.RedMask = $F800 then
          Format := ifR5G6B5
        else
          // R5G5B5 is default 16bit format (with Compression = BI_RGB or masks).
          // We set it to A1.. and later there is a check if there are any alpha values
          // and if not it is changed to X1R5G5B5
          Format := ifA1R5G5B5;
      24: Format := ifR8G8B8;
//jpt 32: Format := ifA8R8G8B8; // As with R5G5B5 there is alpha check later
      32:
        if BI.Compression = BI_BITFIELDS
        then Format := ifX8R8G8B8
        else Format := ifA8R8G8B8; // As with R5G5B5 there is alpha check later
    end;

[BeanzMaster]

Je viens de jeter un oeil dans les sources de Vampyre. Le fait est qu'il se sert toujours des de tous les masques dans sa gestion. Il ne différencie pas si le masque Alpha est présent ou pas dans le fichier BMP

C'est à dire que si tu tombe sur un fichiers XBGR dont les valeur du canal Alpha est à zero, alors il le détectera comme un XRGB mais si toutes les valeurs sont à FF soit un fichier totalment opaque il ne pourra pas détecter que le BMP est un XRGB et il le traitera comme un BGRA

Par contre j'ai fait un petit changement pour verifier
dans ImagingFormats.pas

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 (Byte(Data^ shr 24)) > 0 then // Extraction du canal alpha des données
    begin
      Result := True;
      Exit;
    end;
    Inc(Data);
  end;
end;

Dans ImagingBitmap.pas on trouve ça :

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;

Le soucis ici c'est que BI fait référence à un en-tête BMP pour la version 4. De ce fait son BI.AlphaMask auras toujours une valeur de zero si celui-ci n'est pas lu. Il ne tiens pas compte de l'importance du GapSize et des version antérieur à la 4 et de surcroit la version n'est pas gérée.

En plus je viens de faire un petit test j'ai exporté une image jpg avec gimp vers deux bmp en mode XBGR et avec et sans les informations les informations de l'espace de couleur
le résultat un fichier BMP version 3 et fichier BMP version 5

Le résultat avec vampyre est foireux avec les 2 images avec et sans ma petite modification (j'ai la flemme là tout de suite de remonter dans les messages pour voir ce que tu as modifié)
a gauche version 3, à droite version 5


Avec mon outils ces 2 fichiers sont bien reconnu comme des XBGR



Le problème dans Vampyre c'est surtout qu'il ne calcul pas la taille du masque comme je le fais. Il est donc impossible de discerner correctement ce type de BMP

le plus simple serait encore de faire

Code :

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

1
2
3
4
5
6
  if BI.AlphaMask = 0 then
  begin
    if Format = ifA8R8G8B8 then
      begin
        // change format to X8R8G8B8
        Format := ifX8R8G8B8;

mais là encore ça ne ferai que déplacer le problème et renverrai des XBGR à tout va alors qu'il ne devra pas dans certain cas. Sa gestion du format BMP est trop superficiel pour faire la différence. Ce manque à gagner est aussi dû dans la manière dont il gère les bitmaps. C'est plutôt bien foutu mais il y a trop de manipulation des données entre le chargement et l'affichage final à mon sens.

[Jipété]

Bonjour,

Par contre j'ai fait un petit changement pour vérifier
dans ImagingFormats.pas

Code :

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

1
2
function Has32BitImageAlpha(NumPixels: LongInt; Data: PLongWord): Boolean;
    if (Byte(Data^ shr 24)) > 0 then // Extraction du canal alpha des données

Ah ouais, pas mal !

+++
Ce matin j'ai repris la discussion depuis le début (car au bout du compte, si Vampyre c'est la croix et la bannière à utiliser à cause de l'aide pas à jour et des exemples en vrac, je vais peut-être le zapper), et je me suis rendu compte d'une bêtise là :

A l'heure actuelle TLazIntfImage est la meilleure solution pour la gestion des bitmap surtout sous Linux, on a vu le problème lié à la transparence dans TGifViewer.

Non, puisqu'il se plante sur l'inversion des couleurs R<>B comme je l'ai montré dans le 1^er post (le triangle en haut à gauche doit être dans les orange-marron et pas bleu !)

En fait cette inversion R <> B est due à une mauvaise utilisation de ma part, pour cause d'ignorance.
Et je m'en sors comme ça, c'est assez amusant car, oui, j'ai remarqué que le xrgb est affiché en gris selon comment j'initialise le TLazIntfImage ! :

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
 
    try
      if OffsetToDatas = 54 then begin // fichier d'origine sans infos de couleur -- 122 pour le bgra, 138 pour le xbgr
        lii := TLazIntfImage.Create(0,0);
        lii.DataDescription := GetDescriptionFromDevice(0);
        lii.LoadFromFile(opd.FileName);
      end else begin
        lii := bmpFic.CreateIntfImage; // bmpFic c'est le bitmap d'origine qui fonctionne bien sauf quand le fichier source n'a pas les infos de couleur
        lii.LoadFromBitmap(bmpFic.Handle, bmpFic.Handle, bmpFic.Width, bmpFic.Height);
      end;
 
      with img4result do begin // TImage d'affichage final
        Picture.Clear;
        Picture.Bitmap.LoadFromIntfImage(lii);
      end;
 
    finally
      lii.Free;
    end;

Et voilà.
Résultat, , héhé !

Me reste plus qu'à creuser l'enregistrement sur disque d'un fichier LazIntfImage car l'enregistrement du TImage fait sauter le canal Alpha,

Bon week-end, merci à tous, gros bisous, toussa toussa,

[BeanzMaster]

Salut,

Bonjour,

...

Me reste plus qu'à creuser l'enregistrement sur disque d'un fichier LazIntfImage car l'enregistrement du TImage fait sauter le canal Alpha,

Bon week-end, merci à tous, gros bisous, toussa toussa,

Pour la sauvegarde essayes comme ça (cf dans l'unité IntfGraphics)

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
    var
        BmpHnd,MaskHnd: HBitmap;
        Bitmap1: TBitmap;
        IntfImg1: TLazIntfImage;
        Writer: TLazWriterBMP; // Basé sur TFPWriterBMP de FPC dans l'unité FPWriteBMP du dossier fcl-image/src/
      begin
        ...
        // create the raw image
        IntfImg1:=TLazIntfImage.Create(0,0,[]);
        // load the raw image from the bitmap handles
        IntfImg1.LoadFromBitmap(Bitmap1.Handle,Bitmap1.MaskHandle);
        // create the BMP writer
        Writer:=TLazWriterBMP.Create;
        // save image to file
        IntfImg1.SaveToFile('filename.BMP',Writer);
        // clean up
        Writer.Free;
        IntfImg1.Free;
      end;

A+

[Jipété]

Oh lala, grand merci à toi, tu m'ôtes une épine du pied

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
  procedure Enregistre(b:TBitmap; f:string);
  var
    lii: TLazIntfImage;
    Writer: TLazWriterBMP; // Basé sur TFPWriterBMP de FPC dans l'unité FPWriteBMP du dossier fcl-image/src/
  begin
    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 := CreateIntfImage;
      lii:=TLazIntfImage.Create(0,0,[]);
      lii.LoadFromBitmap(Handle, MaskHandle, Width, Height);
    end;
    Writer:=TLazWriterBMP.Create;
    Writer.BitsPerPixel := BitsPerPixel; // obligatoire sinon les 32 sont écrits en 24
    // save image to file
    lii.SaveToFile(f, Writer);
    // clean up
    Writer.Free;
    lii.Free;
  end;

Avec les manips de ce matin, j'ouvre sans me prendre la tête les 24 ou 32 bits avec ou sans informations de couleur, et j'enregistre en 24 ou 32 mais hélas il me fait sauter les informations de couleur.
À moins qu'il n'existe une option que je ne connais pas ? J'ai essayé comme ça, mais ça n'a pas payé :

Code :

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

1
2
3
    Writer:=TLazWriterBMP.Create;
    Writer.Initialize(lii); // rajouté
    Writer.BitsPerPixel := BitsPerPixel; // obligatoire sinon les 32 sont écrits en 24

[BeanzMaster]

Oh lala, grand merci à toi, tu m'ôtes une épine du pied
....
Avec les manips de ce matin, j'ouvre sans me prendre la tête les 24 ou 32 bits avec ou sans informations de couleur, et j'enregistre en 24 ou 32 mais hélas il me fait sauter les informations de couleur.

Pas de soucis

Qu'est ce que tu entend par "il me fait sauter les informations de couleur" tu peux être un peux plus précis stp.

EDIT : essayes plutôt de définir :

Code :

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

Writer.BytesPerPixel := 4; // 3 pour le 24 bits

Cette propriété n'est pas mise à jour lorsque tu changes le "bitsPerPixel" mais quand tu changes "BytesPerPixel" alors "bitsPerPixel" est mise à jour. Incongru d'avoir mis les 2 propriétés en lecture et ECRITURE, à mon sens.

RE-EDIT : le "BitsPerPixel est initialisé ici :

Code :

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

1
2
3
4
5
6
procedure TLazWriterBMP.Initialize(AImage: TLazIntfImage);
begin
  // set BPP
  // we can also look at PixelFormat, but it can be inexact
  BitsPerPixel := AImage.DataDescription.Depth;
end;

Voila le truc pourquoi tu perds tes informations. Comme on l'a déja vu, avec certain fichier lorsque le "PixelFormat" est définit à pf32bits, le Depth peut-être à 24 à cause de l'alpha mal définit. Tu te souviens Le TRawImage.DataDescription" c'est le mal

[Jipété]

Pas de soucis

Qu'est ce que tu entends par "il me fait sauter les informations de couleur" tu peux être un peu plus précis stp.

La zone comprise entre 36_hex inclus et 7A_hex exclu n'est pas enregistrée :


Bon, ça n'est pas dramatique, mais je trouve dommage que Gimp génère cette zone et que derrière le couple FPC/Lazarus la supprime sans nous demander notre avis.

EDIT : essayes plutôt de définir :

Code :

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

Writer.BytePerPixel := 4; // 3 pour le 24 bits

Si tu regardes la source que tu as indiquée, tu constateras que BytePerPixel est affublé de la balise Deprecated !
Et je ne vois pas ce que ça changerait de lui dire BytePerPixel := 4; plutôt que BitsPerPixel := 32;.

[BeanzMaster]

Si tu regardes la source que tu as indiquée, tu constateras que BytePerPixel est affublé de la balise Deprecated !
Et je ne vois pas ce que ça changerait de lui dire BytePerPixel := 4; plutôt que BitsPerPixel := 32;.

Effectivement, je n'avais pas fait attention. Depuis 2005, ils auraient pu la supprimé depuis le temps

{ 08/2005 by Giulio Bernardi:
- Removed FBytesPerPixel, BytesPerPixel property is now deprecated, use BitsPerPixel instead. }

Ils l'ont juste supprimé virtuellement, pfff

J'ai regardé le code d'enregistrement le format BI_BitField n'est pas pris en charge. Les BMP seront donc toujours enregistrés avec les masques définit par défaut dans la doc, soit dans l'ordre suivant en BGRA ( avec AlphaMask = 0 pour les 24 bits)

[Jipété]

J'ai regardé le code d'enregistrement le format BI_BitField n'est pas pris en charge. Les BMP seront donc toujours enregistrés avec les masques définit par défaut dans la doc, soit dans l'ordre suivant en BGRA ( avec AlphaMask = 0 pour les 24 bits)

En effet !


Ces gens-là sont des grands malades : transformer un xbgr en bgra, notez-le sur vos tablettes, les gars !

Bon, allez, relâche cet aprème (j'ai attaqué très très tôt ce matin, )

[Jipété]

Coucou me revoilou !

J'ai un peu la haine, là maintenant tout de suite.

Voilà ce qu'on trouve dans fpwritebmp.pp, vers la fin, procedure TFPWriterBMP.InternalWrite (Stream:TStream; Img:TFPCustomImage);. Vous ferez attention, à la lecture, car, comme son nom ne l'indique pas du tout, BFI c'est le Bitmap Info Header (dans mes outils je l'appelle BIH -- chacun ses goûts, chacun ses choix, mais merci de penser à ceux qui passent derrière) :

Code :

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

1
2
3
  if FRLECompress and (FBpp=4) then BFI.Compression := BI_RLE4
  else if FRLECompress and (FBpp=8) then BFI.Compression := BI_RLE8
  else BFI.Compression := BI_RGB;

Et l'option BI_BITFIELDS ? Ben, ça devait être trop compliqué, alors ils l'ont zappée ?

Et comment on va faire, nous ?
Le pire, c'est que fpreadbmp.pp est capable de lire l'info, dans sa procedure TFPReaderBMP.InternalRead(Stream:TStream; Img:TFPCustomImage); :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
  with BFI do
  begin
    BadCompression:=false;
    if ((Compression=BI_RLE4) and (BitCount<>4)) then BadCompression:=true;
    if ((Compression=BI_RLE8) and (BitCount<>8)) then BadCompression:=true;
    if ((Compression=BI_BITFIELDS) and (not (BitCount in [16,32]))) then BadCompression:=true;
    if not (Compression in [BI_RGB..BI_BITFIELDS]) then BadCompression:=true;
    if BadCompression then
      raise FPImageException.Create('Bad BMP compression mode');
    TopDown:=(Height<0);
    Height:=abs(Height);
    if (TopDown and (not (Compression in [BI_RGB,BI_BITFIELDS]))) then
      raise FPImageException.Create('Top-down bitmaps cannot be compressed');
    ...

Ou alors j'ai raté une marche ?
Quelqu'un pour jeter un œil dans (sous WP) lazarus182/fpc/3.0.4/source/packages/fcl-image/src/fpwritebmp.pp ?
Mille mercis,