Discussion :

[Jipété]

Bonjour,

Aujourd'hui, rien à voir avec du code, mais c'est quand même grâce à mes recherches et mes outils codés en... Lazarus que je peux vous faire part de ceci, à noter dans un coin de sa tête, on ne sait jamais.



Si vous comparez attentivement la 3e ligne des deux fichiers que j'affiche dans mon éditeur hexa, vous constaterez une sacrée différence concernant les 4 bytes à partir de l'adresse 22₁₆, et quelle est l'information présente dans Cubic.bmp (00 65 04 00, générée par Bmp.SaveToFile, merci FPC ) en bas, et absente dans 400_xnview_cubic.bmp en haut (tout à zéro, générée par XnView version 2.22) ?
Je vous le donne en mille, c'est la... taille de l'image !

Donc méfiance, pour ceux qui comme moi récupèrent le BitmapInfoHeader et font des calculs à partir de là !

[FChrisF]

A ma connaissance, ce champ a toujours été "optionnel", tout au moins pour certain types de bitmap. Il faut alors le calculer dans ce cas (i.e. scanLineSize * height).

Sur Wikipedia, par exemple, la confirmation de ceci ( https://en.wikipedia.org/wiki/BMP_file_format ). Extrait du paragraphe DIB header:

22 34 4 the image size. This is the size of the raw bitmap data; a dummy 0 can be given for BI_RGB bitmaps.

[BeanzMaster]

Salut pour une fois ce n'est pas FPC le causeur de troubles Xn-View est un peu flemmard sur ce coup.
Pour ma part je me suis jamais servie de cette donnée, car justement elle est optionnelle. Elle est vraiment pas fiable du tout, car si le application qui sauvegarde le fichier à un "bug" dans les calculs. Tu te prend le

[Jipété]

A ma connaissance, ce champ a toujours été "optionnel", tout au moins pour certains types de bitmap. Il faut alors le calculer dans ce cas (i.e. scanLineSize * height).

Sur Wikipedia, par exemple, la confirmation de ceci ( https://en.wikipedia.org/wiki/BMP_file_format ). Extrait du paragraphe DIB header:

Ok, bien noté, merci pour l'info, j'étais passé à côté (il y a tellement à lire sur ce sujet...)

[...] si l'application qui sauvegarde le fichier a un "bug" dans les calculs, tu te prends le

Vi, mais à ce compte-là on ne fait plus rien !

Je vais faire des tests, j'ai soit l'option de FChrisF qui s'appuiera sur la formule magique d'Andnotor, (Trunc(((Width * bih.biBitCount) +31)/32) * 4) * abs(bih.biHeight);, soit sur quelque chose à creuser, bfh.Size - bfh.bfOffBits;.

Merci de m'avoir remis sur les rails !

[BeanzMaster]

Ok, bien noté, merci pour l'info, j'étais passé à côté (il y a tellement à lire sur ce sujet...)

Vi, mais à ce compte-là on ne fait plus rien !

Je vais faire des tests, j'ai soit l'option de FChrisF qui s'appuiera sur la formule magique d'Andnotor, (Trunc(((Width * bih.biBitCount) +31)/32) * 4) * abs(bih.biHeight);, soit sur quelque chose à creuser, bfh.Size - bfh.bfOffBits;.

Merci de m'avoir remis sur les rails !

Cette valeur si elle est présente peux juste aider à valider nos propres calcul. N'oublies pas les "GapSizes" aussi, dans tes calculs bfh.Size - bfh.bfOffBits;. si bfhSize est à Zero c'est mort. La meilleure formule est celle d'AndNotOr.
ou bien sans division et avec 1 multiplication en moins, avec décalage : TailleTotale := (round((Width * bih.biBitCount) + 31) shr 5) shl 2) * abs(bih.biHeight);;
Une autre formule que j'ai vu est TailleTotale := (round((Width * bih.biBitCount) + 31) and - 32) shr 3) * abs(bih.biHeight); mais la je me perd un peux avec l'opérateur logique AND je n'arrive pas à visualiser "le calcul". Une question me taraude qu'est ce qui est le Mieux "Trunc" qui coupe net ou "Round" qui arrondira au plus proche ?

[Jipété]

Cette valeur si elle est présente peut juste aider à valider nos propres calculs. bfh.Size - bfh.bfOffBits;. si bfhSize est à Zero c'est mort.

Je n'ai pas vu de probabilité d'absence de la valeur dans MSDN, plus qu'à croiser les doigts,

N'oublies pas les "GapSizes" aussi, dans tes calculs

T'inquiète, je les ai toujours sous les yeux !

Une question me taraude qu'est-ce qui est le mieux, "Trunc" qui coupe net ou "Round" qui arrondira au plus proche ?

Pas d'idée sur la question, et d'après le lien de FChrisF ça se jouerait aussi avec Floor...

Tu sais quoi, j'en ai un peu marre, des fois, d'avoir l'impression d'être embauché comme livreur de pizzas et d'être obligé de passer mon temps arrêté le long du trottoir pour démonter le moteur, refaire l'embiellage, réaléser le piston et réajuster les segments... Et c'est quand que je livre ?
Tu vois l'idée ?

[BeanzMaster]

Je n'ai pas vu de probabilité d'absence de la valeur dans MSDN, plus qu'à croiser les doigts,


T'inquiète, je les ai toujours sous les yeux !



Pas d'idée sur la question, et d'après le lien de FChrisF ça se jouerait aussi avec Floor...

x = 8,6
Round(x) = 9
Trunc(x) = 8

Floor = Trunc avec traitement sur nombre négatif. Je pas comment le résultat de "notre" formule peut-être négative ???

Code :

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

1
2
3
4
5
6
7
8
function Floor(v : Single) : Integer;
begin
   {$HINTS OFF}
   if v<0 then
      Result:=System.Trunc(v)-1
   else Result:=System.Trunc(v);
   {$HINTS ON}
end;

Vue que tu utilises Trunc Floor c'est kifkif je vais changer par trunc cela me semble plus judicieux. Je verrai si il y a des changements au niveau des résultats.

Tu sais quoi, j'en ai un peu marre, des fois, d'avoir l'impression d'être embauché comme livreur de pizzas et d'être obligé de passer mon temps arrêté le long du trottoir pour démonter le moteur, refaire l'embiellage, réaléser le piston et réajuster les segments... Et c'est quand que je livre ?
Tu vois l'idée ?

Oui c'est ça le challenge. Mais c'est vrai que c'est fatiguant parfois. Et le manque d'informations en français est pénalisant, même lorsque l'on pratique un niveau "moyen" la langue de shakespeare.

Je courrais toujours pour aller partout, mais je ne pensais pas pour autant que ça allait me mener quelque part
Forest Gump

[Jipété]

Salut salut,

J'ai donc récupéré des fichiers 24 et 32 bits par ci par là, issus de logiciels divers et variés, le 3^e (appelé "Cubic") est créé par FPC/Lazarus, les 5 derniers proviennent de la bmp_suite déjà signalée par l'ami BeanzMaster (), et voilà un joli tableau, où l'on voit bien que xnview a des petits soucis :



(Nota : le gag idiot d'hier sur Width et Height erronés a été corrigé -- à lire là)

Comment les résultats sont calculés :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
SizeImage0  := bih.biSizeImage; // peut être à zéro ! donc ça craint pour ce qui en dépend
ByPL0       := SizeImage0 div abs(bih.biHeight);
Padding0    := ByPL0 - (bih.biWidth * bih.biBitCount div 8);
 
SizeImage1  := LineSizeT * abs(bih.biHeight); // et LineSizeT c'est Trunc(((bih.biWidth * bih.biBitCount)+31)/32) * 4;
ByPL1       := SizeImage1 div abs(bih.biHeight);
Padding1    := ByPL1 - (bih.biWidth * bih.biBitCount div 8);
 
SizeImage2  := bfh.bmfFileSize - bfh.bmfBitMapDataOffset;
ByPL2       := SizeImage2 div abs(bih.biHeight);
Padding2    := ByPL2 - (bih.biWidth * bih.biBitCount div 8);

Un résultat fiable pourrait être :

Code :

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

1
2
3
4
if SizeImage0 = 0 then 
begin
  if SizeImage1 = SizeImage2 then SizeImage := SizeImage1 else ShowMessage('Grosse erreur de taille !');
end;

À pluche,