Discussion :

[der§en]

Bonjour,

Sous Delphi pour un besoin très spécifique, en désactivant Direct2D, je peux créer à l'écran des images de 32768 X 16384 pixels.

J'aurais aimé savoir s'il est possible de faire la même chose sous Lazarus ?

[Jipété]

Salut

j'aurais aimé savoir, s'il est possible de faire la même chose sous Lazarus ?

Ben, surement, oui, et même plus !
Width et Height sont des integer, donc limite max 2 147 483 648 :

Code :

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

1
2
3
4
5
6
7
8
9
procedure TMainForm.btn4TestsClick(Sender: TObject);
var
  b: TBitmap;
begin
  b := TBitmap.Create;
  b.PixelFormat := pf32bit;
  b.Width := 2147483648;
  b.Height:= 2147483648;
end;

Bon, je n'avais rien sous la main pour remplir avec des datas et afficher, mais ça a compilé et pas vu de problèmes au clic sur le bouton (le reste du prog est opérationnel sans soucis après le clic).

[tourlourou]

Bonjour,

Avec ce code :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
procedure TForm1.Button1Click(Sender: TObject);
var
  b: TBitmap;
begin
  b := TBitmap.Create;
  b.PixelFormat := pf32bit;
  b.SetSize(32768, 16384);
  b.Canvas.Brush.Color:=clLime;
  b.Canvas.Rectangle(0, 0, 32768, 16384);
  b.SaveToFile('c:\UserFiles\test.bmp');
  Image1.Picture.LoadFromFile('c:\UserFiles\test.bmp');
  b.Free;
end;

j'ai réussi à créer et enregistrer un fichier Bitmap de 2 Go, mais ai gagné une EOutOfMemoryException en cherchant à l'ouvrir...

[EDIT] quant à la taille du Bitmap de JP, rien que d'y penser, ma mémoire grille !

[der§en]

Merci de vos remarques, j'ai juste besoin de pouvoir la créer et la sauver dans un fichier

sinon, doit-on en déduire que nativement Lazarus, n'utilise pas les optimisations de Direct2D ?

[Ludelphi7]

Bonjour,
Le problème sera en effet lié à la gestion de la consommation mémoire.
A ce propos, je me permets 2 remarques :
- Il est préférable de relacher la mémoire AVANT de charger l'image crée
- attention aux dimensions : le rectangle dessiné dépasse d'1 pixel la taille de l'image réservée (32768 pixels -> commence à 0 et fini à 32767)
Il ne sert à rien de dessiner 32768 pixels de trop...

Ma proposition :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
procedure TForm1.Button1Click(Sender: TObject);
var
  b: TBitmap;
begin
  b := TBitmap.Create;
  b.PixelFormat := pf32bit;
  b.SetSize(32768, 16384);
  b.Canvas.Brush.Color:=clLime;
  b.Canvas.Rectangle(0, 0, 32767, 16383); // j'ai réduit de 1 pixel (sur 2 axes) pour être conforme à la déclaration de taille ci-avant
  b.SaveToFile('test.bmp');
  b.Free;  // on relache la mémoire avant le chargement de l'image
 
  Image1.Picture.LoadFromFile('test.bmp');
end;

Il faut moins de mémoire pour exécuter ce code, et on évite d'écrire au delà des limites ;-)
ludo

[Jipété]

Code :

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

  b.SetSize(32768, 16384);

Ah Yves, t'as pas tout bien suivi (tu es excusé, c'est confus et touffu) : j'ai écrit en son temps

Me suis rendu compte qu'une instruction que j'utilisais souvent, Bitmap.SetSize(aWidth, aHeight); sous son air anodin et évident, est une brave cochonnerie qui fait des copies des données ! Pourquoi ? J'ai lu dans le code // for delphi compatibility copy old image !
Ah !
Parce que dans mon vieux D7 SetSize n'existe pas...

On y trouve aussi ça : // use slow copy of pixeldata till rawimage can also copy to larger destination et bien sûr l'aide toujours indigente n'en dit pas un mot...

Bref, suis repassé à Bitmap.Width et Bitmap.Height, dommage...

[EDIT] quant à la taille du Bitmap de JP, rien que d'y penser, ma mémoire grille !

Et pourquoi donc ? La machine devrait swapper dans le pagefile.sys (pour Windows) mais devrait y arriver, non ?

j'ai réussi à créer et enregistrer un fichier Bitmap de 2 Go, mais ai gagné une EOutOfMemoryException en cherchant à l'ouvrir...

Et pourquoi donc ? Faudrait creuser en pas-à-pas pour savoir ce qui se passe dans les profondeurs...

Quant à moi, sous Linux Debian 7 / 32 bits, c'est un poème (45 000 x 45 000 = 2 025 000 000) :

Code :

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

1
2
3
4
5
6
7
8
9
10
  b := TBitmap.Create;
  b.PixelFormat:=pf32bit;
  b.Width :=45000;
  b.Height:=45000;
  b.Canvas.Brush.Color:=clLime;
  b.Canvas.Rectangle(0, 0, 44999, 44999); // run error 204
//alors j'essaye
  b.Canvas.Rectangle(0, 0, 45000, 45000); // run error 204
//alors j'essaye sans Rectangle, et bim ! quand même...
  b.SaveToFile('/tmp/test.bmp'); // run error 204

Bienvenue dans le monde merveilleux du graphisme sous Lazarus ! Pas trop le temps ni l'envie de dépatouiller cette vérole, car il me suffit d'enlever un zéro à la largeur et un zéro à la hauteur pour que ça fonctionne...
Mais pas en "remontant" aux valeurs demandées par Der§en :

Ça me gave, si vous saviez comme ça me gave et me bassine...

sinon, doit-on en déduire que nativement Lazarus, n'utilise pas les optimisations de Direct2D ?

De quoi parle-tu ?

[Jipété]

- attention aux dimensions : le rectangle dessiné dépasse d'1 pixel la taille de l'image réservée (32768 pixels -> commence à 0 et fini à 32767)
Il ne sert à rien de dessiner 32768 pixels de trop...

Ma proposition :

Code :

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

  b.Canvas.Rectangle(0, 0, 32767, 16383); // j'ai réduit de 1 pixel (sur 2 axes) pour être conforme à la déclaration de taille ci-avant

Oui, sauf qu'il y a un tuto qui montre bien que les dév's Laz' ne font pas comme ça :

Code :

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

1
2
3
4
5
6
  Bmp := TBitmap.Create;
  Bmp.Width := 10;
  Bmp.Height := 10;
  Bmp.Canvas.Pen.Color := clYellow;
  Bmp.Canvas.Brush.Color := clYellow;
  Bmp.Canvas.Rectangle(0, 0, 10, 10);

Flemme de faire des tests...
Pi il me semble avoir lu un jour quelque part (et bien sûr je ne le retrouve pas...) que les 2 premiers nombres représentent des coordonnées, quand les deux suivants représentent des longueurs, donc méfiance !

[tourlourou]

Code :

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

1
2
  b.Width := 2147483648;
  b.Height:= 2147483648;

Et pourquoi donc ? La machine devrait swapper dans le pagefile.sys (pour Windows) mais devrait y arriver, non ?

Ben, un petit bitmap de maxint au carré en pf32bit, ça nous fait à peine 16,8 millions de To (2G*2G*4o), un peu au delà de mon pagefile.sys...

[der§en]

En fait quand je parle de Delphi c'est avec Firemonkey, et si on ne désactive pas Direct2D, la taille maxi d'un bitmap est 8192 X 8192 pixels, mais en bénéficiant de l'accélération du GPU grâce à Direct2D !

Donc, je me posait la question des mécanismes sous Lazarus.

A vous lire, sur une machine de 16 Go de RAM, sous Lazarus (en 64bits) , je pourrais largement avoir une image bien supérieur à mes 32768 ?

[gandf]

Bonsoir,

La demande initiale est pour Win64 ou Win32 ?
J'ai fait le test en compilant pour Win32 et c'est la ligne suivante qui stop.

Code :

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

ReAllocMem(Data, DataSize);

Avec DataSize à 2147483648.

Il me semble que ReAllocMem est une fonction gérée par le système. Ici, si c'est en Win32, le système ne peut allouer en une fois plus de 2Go de mémoire car je ne pense pas avoir activer l'option de compilation qu'il faut. Je ne sais pas si ce compilateur en as besoin ou non mais c'est probable.
https://social.technet.microsoft.com...m=winservergen
https://msdn.microsoft.com/en-us/library/aa366778.aspx

J'ai téléchargé l'add-on pour compiler en Win64 et le code fonctionne très bien. Il faut juste être patient quand le fichier est écrit sur le disque et quand il est lu.
Le fichier est trop gros pour être ouvert par la visionneuse d'image de Windows 7 et dans la fenêtre, c'est une image noire qui s'affiche (pas jaune) mais si je mets une petite taille, c'est toujours noire.
La mémoire ne semble pas correctement gérée par le TImage déposé sur la fiche car lors du chargement, il me semble avoir vu la mémoire de l'application monter à 4Go.

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
procedure TForm1.Button1Click(Sender: TObject);
var
  Bmp: TBitmap;
begin
  Bmp := TBitmap.Create;
  Bmp.PixelFormat := pf32bit;
  Bmp.Width := 32768;
  Bmp.Height := 16384;
  Bmp.Canvas.Pen.Color := clYellow;
  Bmp.Canvas.Brush.Color := clYellow;
  Bmp.Canvas.Rectangle(0, 0, 32767, 16383);
  Bmp.SaveToFile('c:\test\test.bmp');
  Bmp.Free;
 
  Image1.Picture.LoadFromFile('c:\test\test.bmp');
end;

[Jipété]

Code :

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

1
2
  b.Width := 2147483648;
  b.Height:= 2147483648;

Ben, un petit bitmap de maxint au carré en pf32bit, ça nous fait à peine 16,8 millions de To (2G*2G*4o), un peu au delà de mon pagefile.sys...

Petit joueur,

Bon, trêve de plaisanterie, où avais-je la tête ?
Mais j'ai une excuse, le graphisme sous Lazarus c'est tuant déprimant exténuant chronophage mortel débile démotivant démobilisateur, etc.
Regarde :

Fonctionne très bien (immense image vert clair) :

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
procedure TMainForm.btn4TestsClick(Sender: TObject);
var
  b: TBitmap;
begin
  b := TBitmap.Create;
  b.PixelFormat:=pf32bit;
  b.Width :=4500;
  b.Height:=4500;
  b.Canvas.Brush.Color:=clLime;
  b.Canvas.Rectangle(0, 0, 4500, 4500); 
  b.SaveToFile('/tmp/test3.bmp'); // 60 Mo environ
  b.Free;  // on relache la mémoire avant le chargement de l'image
  // dessous, procédure à moi  pour faire afficher le .bmp 
  // ce bouton "squatte" un projet (en cours de dév') pour faire des tests rapides
  if OpenAnImage('/tmp/test3.bmp') then tkbrZoomChange(Self);
end;

Ne fonctionne pas -- image 4x2 noire :

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
procedure TMainForm.btn4TestsClick(Sender: TObject);
var
  b: TBitmap;
begin
  b := TBitmap.Create;
  b.PixelFormat:=pf32bit;
  b.Width :=4;
  b.Height:=2;
  b.Canvas.Brush.Color:=clLime;
  b.Canvas.Rectangle(0, 0, 4, 2); 
  b.SaveToFile('/tmp/test3.bmp'); // 86 bytes
  b.Free;  // on relache la mémoire avant le chargement de l'image
  // dessous, procédure à moi  pour faire afficher le .bmp 
  // ce bouton "squatte" un projet (en cours de dév') pour faire des tests rapides
  if OpenAnImage('/tmp/test3.bmp') then tkbrZoomChange(Self);
end;

Les seules différences concernent Width et Height du bitmap, et le rectangle associé.
EDIT :
Je ne comprends pas, et je ne vois pas du tout où et quoi chercher...

J'ai compris, en faisant un test avec 4x3 :
(la bordure gris foncé ne fait pas partie du bitmap généré par code, c'est la zone d'affichage)

Image très agrandie (x 1600) où l'on voit que le canvas fait bien 4x3, mais qu'il y a une "réservation" de 1 px tout autour pour la bordure.
Solution :

Code :

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

1
2
  b.Canvas.Pen.Color:=clLime; // ligne à rajouter
  b.Canvas.Brush.Color:=clLime;

Et avec ça j'arrive à avoir une image de 1 ligne de haut en spécifiant b.Height := 1; bien sûr, et aussi Rectangle(0, 0, w, 1);.
Voilà, c'était pour confirmer ce point (qui à une époque m'avait également interpellé) : il ne faut pas faire "- 1" aux deux dernières valeurs de Rectangle.

Exemple avec un carré de 5x5 et la ligne "Pen" rajoutée, et en codant comme suggéré (à tort, désolé ) par Ludelphi7 le rectangle avec b.Canvas.Rectangle(0, 0, w-1, h-1);.

[Jipété]

Avec ce code :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
procedure TForm1.Button1Click(Sender: TObject);
var
  b: TBitmap;
begin
  b := TBitmap.Create;
  b.PixelFormat := pf32bit;
  b.SetSize(32768, 16384);
  b.Canvas.Brush.Color:=clLime;
  b.Canvas.Rectangle(0, 0, 32768, 16384);
  b.SaveToFile('c:\UserFiles\test.bmp');
  Image1.Picture.LoadFromFile('c:\UserFiles\test.bmp');
  b.Free;
end;

j'ai réussi à créer et enregistrer un fichier Bitmap de 2 Go, mais ai gagné une EOutOfMemoryException en cherchant à l'ouvrir...

Et moi avec ces dimensions

Code :

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

1
2
  b.Width := 8000;
  b.Height:= 8000;

j'arrive à générer un fichier de 256 Mo qui s'ouvre sans problème avec le visionneur de fichiers de Linux tout comme avec The Gimp mais une tentative avec Lazarus (TBitmap, TPicture, TImage) se solde par un délog/relog violent de la session, alors méfiance !

[gandf]

Je suis arrivé à la même conclusion au sujet des bandes noires. Il faut utiliser :

Code :

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

0, 0, maxX, maxY

Par contre, il y a des limitations au format bmp. L'image est de la bonne couleur jusqu'en 16384 x 16384 mais pour la taille demandée (32768 X 16384), le fichier est indiqué invalide par plusieurs programmes différents.
http://www.fileformat.info/format/bmp/egff.htm

Pour gérer des fichiers de cette taille, le mieux serait d'utiliser un autre format que le bmp.

[Jipété]

Bonjour,

Par contre, il y a des limitations au format bmp. L'image est de la bonne couleur jusqu'en 16384 x 16384 mais pour la taille demandée (32768 X 16384), le fichier est indiqué invalide par plusieurs programmes différents.

Je me demande si ça ne serait pas une limitation de Lazarus (qui a dit "bug" ? ) car j'ai fait une recherche ggl avec bitmap limits, j'ai trouvé pas mal de choses intéressantes (chez S.O. entre autres), la synthèse c'est que la limite serait basée sur des integer d'il y a 30 ans donc 16 bits donc 32768 mais pour la hauteur on se souvient que selon que la valeur est positive ou négative l'image sera construite top2bottom ou bottom2top (ou l'inverse), on n'a donc plus que 16384 valeurs disponibles pour la hauteur.

Le problème en ce qui me concerne (limitation de la machine ? de Debian 32 bits ? de mon vieux Laz 1.4 [j'attends la 1.8 définitive] ?), c'est que je gagne

Code :

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

1
2
3
4
5
6
7
8
9
10
  // au-dessus, lignes pour création du bitmap
  b.Canvas.Rectangle(0, 0, w, h);
  // avec 32768x16384 et pf32bit
  // Le projet imgtasks a levé une exception de class "External: SIGFPE".
  // dans le fichier "lclproc.pas" à la ligne 860
 
  // avec 32768x16384 et pf24bit ou 23170x23170 (https://stackoverflow.com/questions/29175585/what-is-the-maximum-resolution-of-c-sharp-net-bitmap)
  // Le projet imgtasks a levé une exception de class "External: SIGSEGV".
  // dans le fichier "./gtk2/gtk2proc.inc" à la ligne 1251
  // idem avec 1 point de moins, 32767x16383

J'abandonne, ça m'épuise.

Voir
https://stackoverflow.com/questions/...mp-file-format
https://social.msdn.microsoft.com/Fo...forum=netfxbcl
https://stackoverflow.com/questions/...ec-limitations

[tourlourou]

La mémoire ne semble pas correctement gérée par le TImage déposé sur la fiche car lors du chargement, il me semble avoir vu la mémoire de l'application monter à 4Go.

Le Timage a à la fois un Bitmap correspondant à l'image chargée, et un Canvas pour son affichage, d'où je pense les 2 fois 2 Go.

[BeanzMaster]

Salut à tous, j'ai fais quelques tests

avec ce code

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
 
procedure TForm1.Button1Click(Sender: TObject);
var
  Bmp: TBitmap;
begin
  Bmp := TBitmap.Create;
  Bmp.PixelFormat := pf32bit;
  Bmp.Width := 32768;
  Bmp.Height := 16384;
  Bmp.Canvas.Pen.Color := clYellow;
  Bmp.Canvas.Brush.Color := clYellow;
  Bmp.Canvas.Rectangle(0, 0, 32768, 16384);
  Bmp.SaveToFile('test.bmp');
  Bmp.Free;
 
  Image1.Picture.LoadFromFile('test.bmp');
end;

Sous Windows 10

Avec Lazarus 1.8RC3 32bits je me prend un gros RuntimeError 203 dans lcl\include\custombitmap.inc ligne 239 :

Code :

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

1
2
// setup data
  ImagePtr^.CreateData(True);

Avec Lazarus 1.6.4 64bits pas de soucis ça fonctionne. Seul truc un gros carré noir à la place de jaune. Il semblerai que le fichier soit mal enregistrer par Lazarus
J'ai verifié avec FastOneImageViewer, IrfanView idem image noire.
La mémoire utilisée après le chargement dans le TIMAGE est d'environ 5.6 GO (vue dans le gestionnaire de tache)

En ce qui concerne l'ouverture dans un 1 de mes projets avec la version 64bits pas de soucis j'ouvre le fichier ; avec la 32bits je me prend un bon "gros Out of memory"

A Priori, der§en tu devras pouvoir créer ton fichier. Mais pas en BMP, faudrait tester avec JPEG et PNG si ça ne plante pas. Tu devras utiliser la version 64bits de Lazarus. Juste un truc au lieu de manipuler des TBitmap, je pense qu'il serait préférable de passer par TLazIntfImg c'est un peu plus galère à utiliser, mais sûrement plus "sûre".

EDIT : Avec mon projet après l'ouverture du fichier, la consommation mémoire est de 2054,4 Mo exactement (et il y a plus d'un bouton)
Et petit test avec juste

Code :

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

Image1.Picture.LoadFromFile('test.bmp');

après chargement consommation mémoire 5699,9 Mo. Autant dire que le TImage/TBitmap coté gestion mémoire, c'est la CATA !

A +

[Jipété]

Bonsoir,

Salut à tous, j'ai fais quelques tests

Les grands esprits se rencontrent, comme on dit, car moi aussi j'ai testé, enfin, j'ai surtout cherché les limites (je n'ai pas essayé d'ouvrir les fichiers générés dans un TImage, sachant que ça serait une abomination) :

Code :

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

1
2
3
4
5
6
7
   10000x10000x32 ok, fic 400 Mo
   11000x11000x32 ok, fic 484 Mo
   16000x8000x32 ok, fic 512 Mo, beaucoup + rapide à générer que 11000x11000
   16384x8192x32 proc à fond et ne rend pas la main...
   16384x8190x32 proc à fond et ne rend pas la main...
   16380x8190x32 ok, fic 402,5 Mo très rapide, fic aurait dû être à 536,6
   16383x8191x32 ok, fic 402,6 Mo très rapide, fic aurait dû être à 536,7

Et au-delà c'est SIGSEGV ou SIGFPE au hasard, au choix, au pif, je n'ai pas encore trouvé (et je ne chercherai pas) pourquoi l'un plutôt que l'autre.

Le truc mystérieux, vraiment, c'est la taille des fichiers qui diminue... Enfin, pas si mystérieux que ça, Lazarus a basculé en mode pf24bit, mais sans que je le demande...
Elle est pas belle la vie ?

[der§en]

Bon, merci de votre participation à tous, je vais regarder du côté de : TLazIntfImg

Côté sauvegarde, c'est bizarre que le bmp pose problème, il me semblait que c'était le format natif de Windows, mais perso, je préféré le PNG même si c'est plus consommateur d'espace disque.

Pour la taille de l'image sous Firemonkey, cela n'est bien entendu possible uniquement en mode 64 bits.

[Ludelphi7]

J'ai fait aussi un test, ok avec bmp=20000x20000x32b=1,6Go
Avant d'aller plus loin j'ai fait des recherches
Un fichier bmp se compose de 3 parties :
Entete fichier (14 octets)
Entete bmp (40 octets)
Palette (optionnel )
Data (width x height x 4 octets)

Pour info, les width et height doivent être multiple de 4, sinon les lignes seront complétées à 4 dans data et vous ne pourrez pas vérifier la formule
Taille fichier Totale=tailleData+54octets

Dans l'entete du fichier, le 2eme champ (sur 4 octets) défini la taille totale du fichier, forcément supérieur à la taille des data
Dans l'entete du bmp, le 7eme champ (sur 4 octets) défini la taille totale des data, forcément inférieur à la taille totale du fichier

En supposant que ces tailles soient des nombres signés, on est limité à 2Go pour la taille du fichier entier
Donc :
soit width x height x 3 + 54 est strictement inférieur à 2Go (pf24bit)
Soit width x height x 4 + 54 est strictement inférieur à 2Go (pf32bit)
Du coup j'ai lancé un gros 31000x16384 qui a pris du temps, mais qui marche, taille totale légèrement inférieure à 2Go
Je pense qu'il peut être agrandi un peu, mais on n'arrivera plus à doubler la taille ;-)
ludo

[BeanzMaster]

J'ai fait aussi un test, ok avec bmp=20000x20000x32b=1,6Go
Avant d'aller plus loin j'ai fait des recherches
Un fichier bmp se compose de 3 parties :
Entete fichier (14 octets)
Entete bmp (40 octets)
Palette (optionnel )
Data (width x height x 4 octets)

Ca c'est juste si le BMP en codé en version 1 ('l'en-tête de la Version 5 = 124 octets). Ce que tu décrit n'est pas une généralité.

Pour info, les width et height doivent être multiple de 4, sinon les lignes seront complétées à 4 dans data et vous ne pourrez pas vérifier la formule
Taille fichier Totale=tailleData+54octets

Faux la taille n'est pas obligatoirement de 4, rien à voir C'est la LIGNE CODEE dans le fichier BMP qui doit être alignée sur 32bits

Dans l'entete du fichier, le 2eme champ (sur 4 octets) défini la taille totale du fichier, forcément supérieur à la taille des data
Dans l'entete du bmp, le 7eme champ (sur 4 octets) défini la taille totale des data, forcément inférieur à la taille totale du fichier

Le 1er paramètres est correcte
Le 2eme quand à lui est optionnel. Il est souvent à 0.

En supposant que ces tailles soient des nombres signés, on est limité à 2Go pour la taille du fichier entier
Donc :
soit width x height x 3 + 54 est strictement inférieur à 2Go (pf24bit)
Soit width x height x 4 + 54 est strictement inférieur à 2Go (pf32bit)
Du coup j'ai lancé un gros 31000x16384 qui a pris du temps, mais qui marche, taille totale légèrement inférieure à 2Go
Je pense qu'il peut être agrandi un peu, mais on n'arrivera plus à doubler la taille ;-)
ludo

Que se soit signé ou pas c'est la même chose lorsque c'est négatif cela signifie que l'image est codée de bas en haut ou de droite à gauche
Les calculs de taille se font toujours sur les valeurs absolues.

Bonsoir,

Et au-delà c'est SIGSEGV ou SIGFPE au hasard, au choix, au pif, je n'ai pas encore trouvé (et je ne chercherai pas) pourquoi l'un plutôt que l'autre.

SIGFPE c'est une erreur arithmétique genre division par zero

Le truc mystérieux, vraiment, c'est la taille des fichiers qui diminue... Enfin, pas si mystérieux que ça, Lazarus a basculé en mode pf24bit, mais sans que je le demande...
Elle est pas belle la vie ?

C'est comme à la lecture (avec le vil "RawImage.Description.BitCount" si tous les pixels on le canal alpha à 255 alors le bitmap est considéré comme un 24bits

Bon, merci de votre participation à tous, je vais regarder du côté de : TLazIntfImg

Sinon si tu patiente un peu, il y'aura mon projet qui proposera une gestion des bitmaps totalement indépendante de FPC/Lazarus qui ressemble beaucoup au TBitmap originel, mais surtout beaucoup plus optimisée et rapide. Mais me reste plein de petite chose à coder (notamment le support des 3 gros formats JPEG, PNG et TIFF et la gestion des "masques bitmap") Mais tout ça tout seul c'est long.
A l'heure actuelle je gère que la lecture des formats BMP, XPM, Portable PixMap (pgm, pbm,pnm,ppm,pam,pfm) , TGA, PCX, HDR, plus 2/3 autres formats. (l'enregistrement devrai être un parcours de santé et rapide). Je gère plusieurs filtres (sur les couleurs, des effets de blur, convolutions...). Differents mode redimensionnement sont disponibles brute, billineaire, bicubique, par rééchantillonage ( avec plus +de 30 fonctions d'interpolations) et 1 fonction expérimentale. Et plein d'autre petites chose....

EDIT : J'ai oublié petite précision TLAzIntfImg provient de la LCL. Et tu peux également regarder du coté de TFPCustomImage et ces descendants (Provient de la FCL), ou essayé la librairie BGRABitmap qui s'appuie sur celui-ci.

Côté sauvegarde, c'est bizarre que le bmp pose problème, il me semblait que c'était le format natif de Windows, mais perso, je préféré le PNG même si c'est plus consommateur d'espace disque.

Pour la taille de l'image sous Firemonkey, cela n'est bien entendu possible uniquement en mode 64 bits.

C'est pas le BMP en lui même, ce sont les fonctions de Lazarus/FPC qui posent problèmes


A+