Taille maximale d'une image

**BeanzMaster** · 12/08/2017, 13h49

Envoyé par Jipété

La grande question (pour moi), c'est pourquoi on passe par gbPixmap et pas par gbBitmap dans le case de RawImage_FromBitmap...
On trouve, dans Gtk2Def, les lignes suivantes :

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
  PGDIObject = ^TGDIObject;
  TGDIObject = record
    //...
    case GDIType: TGDIType of
      gdiBitmap: (
        Depth: integer;
        SystemVisual : Boolean;
        Visual : PGDKVisual;
        Colormap : PGDKColormap;
        case GDIBitmapType: TGDIBitmapType of // TGDIBitmapType = (gbBitmap, gbPixmap, gbPixbuf);
          gbBitmap: (GDIBitmapObject: PGdkBitmap); // pixmap with depth 1
          gbPixmap: (GDIPixmapObject: record // normal pixmap
                      Image: PGdkPixmap;     // imagedata
                      Mask: PGdkBitmap;      // the mask for images with 1 bit alpha and pixmap not supporting alpha
                    end);
          gbPixbuf: (GDIPixbufObject: PGdkPixbuf);
      );

La solution serait peut-être du côté de TGDIBitmapType mais je n'ai pas trouvé ce qui le déterminait.

La réponse, je suppose :

Code :

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

gbBitmap: (GDIBitmapObject: PGdkBitmap); // pixmap with depth 1

ce qui signifie que les donnée sont codé sur 8bits (1 octet par pixel) c'est ce qu'utilise le "MaskHandle" comme format

Code :

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

Mask: PGdkBitmap;      // the mask for images with 1 bit

gbPixmap est renvoyé car on lui passe les 2 Handles : Bitmap et Mask. Dans quel cas est renvoyé "gbPixbuf" ? aucune idée.

Plus je te regarde creuser et plus je croie fortement à un problème lié à la gestion de la mémoire et des différents "buffer" dans la gestion des bitmaps FCL ? ou LCL ? je pencherai plus du coté de la LCL.
Pourquoi je dis ça ? J'arrive comme je l'ai dis, a créer une image de 32000x32000x32 (4Go) et juste petite info mon "buffer" c'est un simple type PByte alloué avec ReAllocMem

Envoyé par Jipété

Pièce jointe 302531

La on voie bien que l'erreur c'est la division par ZERO. C'est Msg qui est vide, donc maintenant ou est ce que la LCL va chercher ce Msg ?. Essayes juste

Code :

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

if (length(Msg) div 10000) = 0 then

On sait que ça donnera Zero comme resultat. Mais plus de SIGFPE. Juste pour tester. C'est peut-être un bug de la 1.4 qui à été corrigé sur les versions 1.6/1.8 ? Car chez moi dans la 1.6.4 à la ligne 860 de lclproc.pas j'ai

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 FreeThenNil(var obj);
begin
  if Pointer(obj) <> nil then 
  begin
    TObject(obj).Free;
    Pointer(obj) := nil;
  end;
end; // ------> LIGNE 860
 
procedure RegisterInterfaceInitializationHandler(p: TProcedure);
begin
  InterfaceInitializationHandlers.Add(p);
end;

EDIT :

Envoyé par Jipété

On peut rencontrer la valeur 122 (et peut-être d'autres, alors, à ce compte-là...), démonstration avec une routine dont l'origine remonte à l'ami Thierry William :

122 signifie que tu as à faire un fichier BMP avec l'en-tête Version 4 :
En-tête commune à tous les bmp :

Code :

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

1
2
3
4
5
6
7
8
 
  TGLZBMPFileHeader = Packed Record // Taille 14 octets
    bfType: Array[0..1] Of Char; // bfType, Normalement Word; En déclarant un array of char on évite de se prendre les pieds avec  le "Little et Big Endian"
    bfSize: Longword;   // Taille totale du fichier
    bfReserved1: Word;  // Hospot X -> OS2x
    bfReserved2: Word;  // Hospot Y -> OS2x
    bfOffBits: Longword; // Position des données de l'image dans le fichier
  End;

+

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
  //En-tête BMP Windows V4
  //     biSize: LongWord;                // Taille de l'en-tête avec biSize = 108 octets
  TGLZWindowsBMPInfoHeaderV4 = Packed Record   // Ici Taille 104, biSize est lu avant
    biWidth: Longint;                // Largeur de l'image en pixels
    biHeight: Longint;               // Hauteur de l'image en pixels
    biPlanes: Word;                  // Nombre de Plans de couleur  = 1
    biBitCount: Word;                // Nombre de bits par pixel
    biCompression: Longword;         // Type de compression
    biSizeImage: Longword;           // Taille de l'image  AVEC LE PADDING peut être 0 si pas de compression, :zoubi:
    biXPelsPerMeter: Longint;        // hoizontal pixels per meter
    biYPelsPerMeter: Longint;        // vertical pixels per meter
    biClrUsed: Longword;             // Nombre de couleurs utilisées (0 = toutes)
    biClrImportant: Longword;        // Nombre de couleurs importantes (0 = toutes)
    biRedMask: Longword;             // Masque Couleur Rouge
    biGreenMask: Longword;           // Masque Couleur Vert
    biBlueMask: Longword;            // Masque Couleur Bleu
    biAlphaMask: Longword;           // Masque Couleur Alpha
    biCSType: Longword;              // Type de l'espace de couleur CIE
    biEndpoints: TGLZBMP_CIEXYZCoordTriple; // "Color space endpoints"
    biGammaRed: Longword;            // Correction Gamma Rouge
    biGammaGreen: Longword;          // Correction Gamma Vert
    biGammaBlue: Longword;           // Correction Gamma Bleu
  End;

14+108 = 122

------------------------------

**Jipété** · 12/08/2017, 14h36

Envoyé par BeanzMaster

La on voit bien que l'erreur c'est la division par ZERO. C'est Msg qui est vide, donc maintenant où est-ce que la LCL va chercher ce Msg ?.

As-tu bien lu ce que j'ai écrit hier ?

Envoyé par Jipété

Ce qui est intéressant, c'est le commentaire lié à l'erreur :

Code :

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

1
2
3
4
5
6
7
8
{------------------------------------------------------------------------------
  procedure RaiseGDBException(const Msg: string);
 
  Raises an exception.
  Normally gdb does not catch fpc Exception objects, therefore this procedure
  raises a standard "division by zero" exception which is catched by gdb.
  This allows one to stop a program, without extra gdb configuration.
 ------------------------------------------------------------------------------}

En gros l'erreur n'est pas une division par zéro, mais les programmeurs ont mis ça là pour arrêter le prog pour qu'on puisse aller trifouiller, mais où ? Nobody knows...

Envoyé par BeanzMaster

Envoyé par Jipété

La solution serait peut-être du côté de TGDIBitmapType mais je n'ai pas trouvé ce qui le déterminait.

La réponse, je suppose :

Code :

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

gbBitmap: (GDIBitmapObject: PGdkBitmap); // pixmap with depth 1

Et là tu n'as pas tenu compte du post suivant où je disais :

Envoyé par Jipété

Ben non, la solution est planquée Dieu seul sait où (Lazare ! Lève-toi et viens nous dire où Lazarus merdouille !) car je viens de faire un essai avec W = 4000 et H = 3000 et ça passe sans problèmes...

Donc les limites sont fluctuantes (and mergitur si je peux me permettre ce jeu de mots [mais au point où on en est, why not ?]), aléatoires et pifomètriques...

Envoyé par BeanzMaster

122 signifie que tu as à faire un fichier BMP avec l'en-tête Version 4

généré par Lazarus, hein, moi je me contente d'écrire bmp.SaveToStream(aStream);.

**BeanzMaster** · 12/08/2017, 15h52

Envoyé par Jipété

As-tu bien lu ce que j'ai écrit hier ?

Si, mais je n'ai pas fait le lien tout a l'heure

avec le truc sur gdb

Envoyé par Jipété

Et là tu n'as pas tenu compte du post suivant où je disais :....
W = 4000 et H = 3000 et ça passe sans problèmes...

Si mais j'ai supposé que cela te renvoyait également un "gbPixmap"

**Jipété** · 12/08/2017, 18h22

Envoyé par BeanzMaster

Si, mais je n'ai pas fait le lien tout a l'heure

avec le truc sur gdb

Envoyé par BeanzMaster

Si mais j'ai supposé que cela te renvoyait également un "gbPixmap"

Mais tout à fait !

Envoyé par Jipété

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
      gbPixmap: begin // on passe ici
        Drawable := GdiBitmap^.GDIPixmapObject.Image; // Drawable = nil après exécution, mais <> nil avec 4000x3000
        Bitmap := GdiBitmap^.GDIPixmapObject.Mask; // Bitmap = nil après exécution
      end;
    end;
    Result := RawImage_FromDrawable(ARawImage, Drawable, Bitmap, ARect);
 
// et enfin ça envoie dans gtk2widgetset.inc :
function TGtk2WidgetSet.RawImage_FromDrawable(out ARawImage: TRawImage; ADrawable, AAlpha: PGdkDrawable; ARect: PRect): boolean;
begin
  Result := False;
  if ADrawable = nil then
    RaiseGDBException('TGtk2WidgetSet.RawImage_FromDrawable'); // voilà l'erreur affichée ! Sauf que ce texte ne remonte pas, pour nous mettre sur la piste...

Sauf qu'avec 4000x3000 ADrawable <> nil, donc pas d'exception.

**BeanzMaster** · 12/08/2017, 22h54

Comme tu l'as dis faut chercher du coté de GDIPixmapObject j'ai regardé dans la LCL ou on pouvais le trouver. Deja c'est exclusif à GTK, donc encore un truc qui fonctionne sous win mais pas avec linux/gtk2.
De plus c'est assez confus. C'est une grosse variable qui passe de fonctions en fonctions, même avec un point de suivi ca risque d'être long et fastidieux pour trouver la source du problème. Le problème viendrait de la "conversion / creation " du bitmap vers le format de "GtkPixmap/PixBuf" (sous gtk c'est ça si je ne me trompe pas.)

**FlorentA** · 10/11/2017, 16h24

Envoyé par Jipété

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 !

Bonjour.

Je confirme que pour l'avoir testé il y a deux jours qu'en supprimant un pixel on a un joli liseré sur les bords droits et bas en mettant deux couples de coordonnées plutôt que l'origine et les dimensions.
Peut-être un problème de surcharge de routine ?

Je profite de la réponse pour poser une question.
J'ai un TImage dans un TPanel dans un TScrollBox. En voulant étendre la dimension de l'image celle-ci ne change pas alors que le TPanel S'adapte bien et la TScrollBox aussi. En réduisant la taille cela marche correctement. Tout se passe comme si je ne pouvais pas dépasser les dimensions initiales pourtant aussi fixées par programmation.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
    FTailleFeuille.fixeForm(largeurFond,hauteurFond);
    if (FTailleFeuille.ShowModal=MrOk) then
      begin
        FTailleFeuille.changeProprietes(largeurFond,hauteurFond);
        FondReleve.Width:=largeurFond;
        FondReleve.Height:=hauteurFond;
        FondReleve.Color:=clred;
        Image1.Width:=largeurFond;
        Image1.Height:=hauteurFond;
        TReleve(projet.releves[projet.releveCourant-1]).haut:=hauteurFond;
        TReleve(projet.releves[projet.releveCourant-1]).larg:=largeurFond;
        dessine_grille(Image1.Canvas,Image1.Width,Image1.Height);
    end;

Si le formulaire retourne des dimensions plus grandes qu'à l'origine, le TPanel FondReleve apparaît bien non recouvert de l'image (en rouge) et la grille dessinée ne couvre que la partie non rouge du TImage.

Après des tests supplémentaires la solution que j'ai trouvée est d'associer l'image à un nouveau TBitmap de la taille requise. Étrange puisque je ne le fais pas au premier redimensionnement.

**Jipété** · 10/11/2017, 18h03

Salut,

Si ça peut t'inspirer, voilà avec quoi je bricole :

Code :

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

1
2
3
      pnl4image.Width := bmpFic.Width;
      pnl4image.Height:= bmpFic.Height;
      imgSource.Picture.Bitmap.Assign(bmpFic);

bmpFic est un TBitmap (créé dans FormCreate, détruit dans FormClose) chargé par une procédure qui s'appuie sur OpenPictureDialog et Bitmap.LoadFromFile, pnl4image comme son nom l'indique est un TPanel qui accueille un TImage avec Align := alClient, et imgSource est le TImage en question.

**der§en** · 11/02/2019, 20h23

Petit up, pour le fun...

j’ai installé la dernière version de Lazarus (2.0.0) et j’ai testé la création d’un bitmap de 32768 X 16384, ainsi que son chargement dans mon logiciel de dessin (Affinity Photo) avec succés.

je me suis dit, allez pour le fun, essayons le double (vu que j’ai 32 giga de ram sur ma Machine sous Win 10 64 bits).

J’ai créer un bitmap de 65536 X 32768. Puis je l’ai bien sauvé sur disque, hélas mon prog de dessin n’a pas réussi à le charger

Bon, il est vrai que le fichier fait plus de 6 giga sur disque.

alors est-ce mon fichier qui est pourri ou bien j’en demande trop à mon logiciel de dessin...

A votre avis ?

**gandf** · 11/02/2019, 21h24

Bonsoir,

Je pense que ça vient du logiciel de photo.
Une personne a déjà posé la question sur leur forum car suivant la taille et la résolution, il semble avoir quelques problèmes pour ouvrir les fichiers volumineux.
https://forum.affinity.serif.com/ind...e-limitations/

Il y a des chances que certaines librairies de gestion de formats d'image ont ce type problème.

**der§en** · 11/02/2019, 22h01

Merci pour l’info

Sinon, j’ai bien essayé d’affiche mon bitmap dans un TImage, cela n’a pas planté mais mon TImage est resté désespérément vide

A votre avis, il y aurai une possibilité d’artiver à l’afficher dans une form ?

**Jipété** · 11/02/2019, 23h03

Salut,

il y a un an environ, j'ai fait des tests.
Je vous laisse lire les commentaires, mais en gros il y a des contraintes liées aux unités de mesure des fichiers, et en plus il faut composer avec les ressources du système d'exploitation :

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
procedure TForm1.Button1Click(Sender: TObject);
var
//  b: TBitmap;
  w,h: integer;
begin
//  w := 16000;  h := 16000; // fichier de 0 byte créé + proc à bloc...
//  w := 16640;  h :=  10; // image noire
//  w := 16392;  h :=  10; // image noire
//  w := 16384;  h :=   8; // image correcte
//  w := 16384;  h :=  12; // image noire
//  w := 16384;  h :=  16; // image noire
//  w := 16384;  h :=  32; // image noire
//  w := 16384;  h :=  64; // image noire
//  w := 16384;  h :=  100; // image noire
//  w := 16384;  h :=  10; // image correcte  et noire après tous les essais
//  w := 16376;  h :=  10; // image correcte
//  w := 16320;  h :=  10; // image correcte
//  w := 16000;  h :=  10; // image correcte
//  w := 18000;  h :=  10; // image affichée noire (ok avec viewer et ImageMagick, mais ImageJ meurt silencieusement), alors que le fichier (128000054 octets) est bon
//  w := 20000;  h :=  10; // image correcte mais ne l'est plus 20 minutes plus tard...
//  w := 20008;  h :=  10; // image affichée noire (ok avec viewer et ImageMagick, mais ImageJ meurt silencieusement), alors que le fichier (128000054 octets) est bon
//  w := 20040;  h :=  10; // image affichée noire (ok avec viewer et ImageMagick, mais ImageJ meurt silencieusement), alors que le fichier (128000054 octets) est bon
//  w := 20080;  h :=  10; // image affichée noire (ok avec viewer et ImageMagick, mais ImageJ meurt silencieusement), alors que le fichier (128000054 octets) est bon
//  w := 20160;  h :=  10; // image affichée noire (ok avec viewer et ImageMagick, mais ImageJ meurt silencieusement), alors que le fichier (128000054 octets) est bon
//  w := 20240;  h :=  10; // image affichée noire (ok avec viewer et ImageMagick, mais ImageJ meurt silencieusement), alors que le fichier (128000054 octets) est bon
//  w := 20320;  h :=  10; // image affichée noire (ok avec viewer et ImageMagick, mais ImageJ meurt silencieusement), alors que le fichier (128000054 octets) est bon
//  w := 20400;  h :=  10; // image affichée noire (ok avec viewer et ImageMagick, mais ImageJ meurt silencieusement), alors que le fichier (128000054 octets) est bon
//  w := 20460;  h :=  10; // image affichée noire (ok avec viewer et ImageMagick, mais ImageJ meurt silencieusement), alors que le fichier (128000054 octets) est bon
//  w := 20520;  h :=  10; // image affichée noire (ok avec viewer et ImageMagick, mais ImageJ meurt silencieusement), alors que le fichier (128000054 octets) est bon
//  w := 24000;  h :=  10; // image affichée noire (ok avec viewer et ImageMagick, mais ImageJ meurt silencieusement), alors que le fichier (128000054 octets) est bon
//  w := 28000;  h :=  10; // image affichée noire (ok avec viewer et ImageMagick, mais ImageJ meurt silencieusement), alors que le fichier (128000054 octets) est bon
//  w := 30000;  h :=  10; // image affichée noire (ok avec viewer et ImageMagick, mais ImageJ meurt silencieusement), alors que le fichier (128000054 octets) est bon
//  w := 30000;  h :=  100; // image affichée noire (ok avec viewer et ImageMagick, mais ImageJ meurt silencieusement), alors que le fichier (128000054 octets) est bon
//  w := 32000;  h :=  1000; // image affichée noire (ok avec viewer et ImageMagick, mais ImageJ meurt silencieusement), alors que le fichier (128000054 octets) est bon
//  w :=  1000;  h := 32000; // parfaitement correct
//  w := 32000;  h := 16000; // fichier de 0 byte créé et c'est tout.
//  w := 32000;  h := 10000; // fichier de 0 byte créé + proc à bloc + message "out of mem" au bout d'un moment.
 
//w := 12000;  h := 8000; // long à venir mais ça a fonctionné (fic = 384 Mo)
//w := 12300;  h := 8200; // long à venir mais ça a fonctionné (fic = 302 Mo, passé en pf24 ! Pourquoi ? 12300 / 8 = 1537,5)
//w := 12320;  h := 8200; // long à venir mais ça a fonctionné (fic = 404 Mo, resté en pf32, 12320 / 8 = 1540)
//w := 12296;  h := 8200; // long à venir mais ça a fonctionné (fic = 404 Mo, resté en pf32, 12296 / 8 = 1357)
//w := 16000;  h := 6000; // long à venir mais ça a fonctionné (fic = 384 Mo)
 
  w := 384;  h :=   68; // image correcte
 
  b := TBitmap.Create;
//  b.PixelFormat := pf32bit; // ne fonctionne pas sur le canvas de la form, faut passer en pf24
  b.PixelFormat := pf24bit;
//  b.Width:=32768;  b.Height:=16384;
  // Ludelpho7 post 19 : j'ai lancé un gros 31000x16384 qui a pris du temps, mais qui marche,
  //b.Width:=31000;  b.Height:=16384; // plante comm' d'hab
  //b.Width:=32000;  b.Height:=16000; // BM post 26 out of memory
                                    // BM Lazarus 1.6.4 64bits sous windows 10 : max = 32767x16383
                                    // moi ça plante, mais 12287x8191 ça génère un fichier pf32bit de 402 Mo.
  b.Width:=w;  b.Height:=h;
  b.Canvas.Pen.Color:=clLime; // ligne à rajouter
  b.Canvas.Brush.Color:=clLime;
  b.Canvas.Rectangle(0, 0, w, h);
  b.Canvas.Changed; //--> BM Pour que l'enregistrement soit ok
  b.SaveToFile('/root/Desktop/test.bmp');  // plante ici
//  b.Free;  // on relache la mémoire avant le chargement de l'image
  Application.ProcessMessages;// jpt, pour que l'affichage redessine le bouton
//  Image1.Picture.LoadFromFile('/root/Desktop/test.bmp');
{ tests mm_71 :
16000 * 16000 OK
32000 *  1000 OK
 1000 * 32000 Beaucoup plus long à traiter que 32000 * 1000 mais OK
32000 * 16000 Noir ( Pixel vu par GHex: 8A 28 A0 02 )
32000 * 10000 Bordel général ( Image jointe ) et sauvegarde noire.
}
  FormPaint(nil);
end;

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
procedure TForm1.Button2Click(Sender: TObject);
var
  w,h: integer;
begin
    w := 512;  h :=   68; // petites valeurs pour voir si tout va bien
 
//  w := 16380;  h :=  21970; // sigsegv dans function gtk2proc.inc GetGdkImageBitsPerPixel(Image: PGdkImage): cardinal;
//  w := 16380;  h :=  21969; // rendu correct
 
//  w := 16383;  h :=  21966; // sigsegv dans function gtk2proc.inc GetGdkImageBitsPerPixel(Image: PGdkImage): cardinal;
//  w := 16383;  h :=  21965; // rendu correct
 
//  w := 16383;  h :=    100; // rendu correct
//  w := 16385;  h :=     10; // rendu correct
//  w := 16385;  h :=      1; // rendu correct
//  w := 16384;  h :=      1; // rendu correct
//  w := 17000;  h :=     100; // plantage du debuggeur -- fonctionne ce matin 26/07...
//  w := 16384;  h :=     100; // plantage du debuggeur -- fonctionne ce matin 26/07...
//  w := 16384;  h :=     10; // plantage du debuggeur -- fonctionne ce matin 26/07...
//  w := 16383;  h :=     10; // rendu correct    et pourtant, 16383 / 8 = 2047,875
//  w := 16000;  h :=     10; // rendu correct
//  w := 20000;  h :=     10; // plantage du debuggeur
//  w := 28000;  h :=     10; // plantage du debuggeur
//  w := 30000;  h :=     10; // plantage du debuggeur
//  w := 30000;  h :=    100; // plantage du debuggeur
//  w := 32000;  h :=   1000; // plantage du debuggeur
//  w :=  1000;  h :=  32000; // rendu correct
 
// 26/07/2018
  w := 262144; h :=   100; // valeur max Gimp --> tué par l'OS
  w := 32768;  h :=   100; // tué par l'OS
  w := 32768;  h :=    10; // tué par l'OS
  w := 32768;  h :=     1; // tué par l'OS
  w := 32767;  h :=   100; // ok
  w := 32767;  h :=  1000; // ok
  w := 32767;  h := 10000; // ok
  w := 32767;  h := 22174; // ok
//  w := 32767;  h := 22175; // out of memory et après qq secondes, hop !, delog, bim !
 
  b24 := TBitmap.Create;
  b24.PixelFormat := pf24bit; // pf32bit ne fonctionne pas sur le canvas de la form
  b24.Width:=w;  b24.Height:=h;
  b24.Canvas.Pen.Color:=clLime; // ligne à rajouter
  b24.Canvas.Brush.Color:=clLime;
  b24.Canvas.Rectangle(0, 0, w, h);
  FormPaint(nil);
end;

Bon, j'ai relu à toute allure, il semblerait que le maximum pour moi soit de w := 32767; h := 22174; // ok car si je dépasse la largeur de 1 point :

Code :

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

1
2
3
  w := 32768;  h :=   100; // tué par l'OS
  w := 32768;  h :=    10; // tué par l'OS
  w := 32768;  h :=     1; // tué par l'OS

ou la hauteur de 1 point w := 32767; h := 22175; // out of memory et après qq secondes, hop !, delog, bim !.
Voilà.

**BeanzMaster** · 12/02/2019, 10h39

Envoyé par der§en

Petit up, pour le fun...

j’ai installé la dernière version de Lazarus (2.0.0) et j’ai testé la création d’un bitmap de 32768 X 16384, ainsi que son chargement dans mon logiciel de dessin (Affinity Photo) avec succés.

je me suis dit, allez pour le fun, essayons le double (vu que j’ai 32 giga de ram sur ma Machine sous Win 10 64 bits).

J’ai créer un bitmap de 65536 X 32768. Puis je l’ai bien sauvé sur disque, hélas mon prog de dessin n’a pas réussi à le charger

Bon, il est vrai que le fichier fait plus de 6 giga sur disque.

alors est-ce mon fichier qui est pourri ou bien j’en demande trop à mon logiciel de dessin...

A votre avis ?

Salut, oui ceci semble être une limitation de ton logiciel de dessin. Si il utilise un tampon de chargement + un tampon temporaire + ???? la ram peut vite être pleine surtout avec des images de ces tailles
Un test à faire serai d'ouvrir le gestionnaire de tache et de regarder les infos sur la mémoire pendant le chargement.

Dans cette discussion https://www.developpez.net/forums/d1...ssible-ouvrir/
J'avais créé l'image BMP de 64000x20000 avec IrfanView et vider la ram au maximum de tout polluant. Regardes les gifs et l'utilisation de la mémoire lors des chargements. (page 2)

Envoyé par der§en

Sinon, j’ai bien essayé d’affiche mon bitmap dans un TImage, cela n’a pas planté mais mon TImage est resté désespérément vide

A votre avis, il y aurai une possibilité d’artiver à l’afficher dans une form ?

Cela n'a pas planté car bon nombre d'erreurs restes silencieuses avec le TBitmap cela m'a déja couté de nombreuses heures à parcouir les codes de la FCL et LCL pour comprendre comment fonctionne les TBitmap/TLazIntfImage etc....

Ton bitmap de 32768 X 16384 il passe lui ou pas ?.

De toute façon avec le TBitmap/et le TImage il y a des limitations a cause du type des variables utilisées lors de la manipulation des données en autres choses.....

Il y a aussi une différence avec l'utilisation de getmem et reallocmem lorsque que tou alloue l'espace mémoire pour les "buffer" si mes souvenirs sont bon, mais je n'en suis pas sûr. A Vérifier donc.

Je pars du principe que le bitmap est codé sur 32bits

65536 X 32768 x 4 = 8 589 934 592 octets si tu utilise un type non signé longword [0..4 294 967 294] (max pour un OS 32bits) pour parcourir ton tableau (buffer) de pixels tu l'as dans le baba.
Il te faut donc utiliser le type QWord [ 0..18 446 744 073 709 551 615 ] à la place pour accéder aux pixels et tu pourra éventuellement afficher ton image uniquement dans un environnement 64 bits et suivant l'utilisation en ram de ton programme.

A+

**der§en** · 12/02/2019, 16h58

Alors oui, j'ai réussi a créer et a afficher dans un TImage, un bitmap en 32768 X 16384 sans problème mais il est vrai que suis full 64 bits..

Je suis même arrivé a afficher mon bitmap dans 2 TImages différent en même temps (c'est miraculeux a se niveau le 64 bits)

Petite précision, mon bitmap est codé en 24 bits soit des TRGBTriple...

**der§en** · 12/02/2019, 17h14

En ce qui concerne la taille du "buffer" image, voila comment je gère le remplissage du Bitmap:

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
 
Procedure TForm1.AfficheCarteStandard;
begin
  FBmp.BeginUpdate(True);
 
  ProcThreadPool.DoParallel(@AfficheLigneStandard, 0, FBmp.Height - 1, nil, ProcThreadPool.MaxThreadCount);
 
  FBmp.EndUpdate();
end;
 
Procedure TForm1.AfficheLigneStandard(Y: PtrInt; D: Pointer;
  I: TMultiThreadProcItem);
var
   X: integer;
   P: PRGBTriple;
begin
  P := PRGBTriple(FBmp.RawImage.GetLineStart(Y));
 
  for X := 0 to LX - 1 do
  begin
    P^.rgbtRed   := Palette[Carte[Y, X]].rgbtRed;
    P^.rgbtGreen := Palette[Carte[Y, X]].rgbtGreen;
    P^.rgbtBlue  := Palette[Carte[Y, X]].rgbtBlue;
 
    Inc(P);
  end;
end;

PALETTE est un tableau de TRGBTriple pour les couleurs que j'ai défini en amont.

CARTE est un tableau de byte qui me sert pour créer le bitmap depuis l'algo Diamant-Carré...

Il est possible, que cela ne soit pas la meilleur méthode, je suis preneur de suggestion pour des améliorations...

**BeanzMaster** · 12/02/2019, 21h04

Je n'avais pas réagis au précédent messages mais 32768X16384 en 32bits ça ne fait que 2Go. Du coup si tu ne peux pas charger de plus grosse images c'est que le type des variables dans les boucles en interne doit être du type Longint d'ou cette limite avec les TBitmaps

Pour ce qui est de ton algo avec l'utilisation des Threads parallèles il faudrait que je m'y plonge un plus pour te répondre.

Le seul petit truc que je vois

C'est que tu peux remplacer

Code :

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

1
2
3
P^.rgbtRed   := Palette[Carte[Y, X]].rgbtRed;
P^.rgbtGreen := Palette[Carte[Y, X]].rgbtGreen;
P^.rgbtBlue  := Palette[Carte[Y, X]].rgbtBlue;

par

Code :

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

P^:= Palette[Carte[Y, X]];

tes 2 variables étant des TRgbTriple;

Bonne soirée

**der§en** · 12/02/2019, 21h35

Bien vu, je suis passé à coté

je vais refaire des tests en mettant des longint mais je reste dubitatif sur la réussite de mes essais en 65536 X 32768...

**der§en** · 13/02/2019, 11h40

Alors, je ne suis pas arriver a afficher mon Bitmap en 65535 X 32768 mais par contre en découpant en 4 fois 32768 X 16384, j'ai réussi a les charger dans 4 TImages en même temps.

voici la consommation mémoire quand je me suis contenter d'afficher les 4 bitmaps:
Nom : Essai_monstrueux.jpg
Affichages : 179
Taille : 39,9 Ko

Nom : Essai_monstrueux.jpg
Affichages : 179
Taille : 39,9 Ko

Et voici la consommation quand je les ai sauvé sur disque:
Nom : Consommation_memoire_lazarus.jpg
Affichages : 188
Taille : 43,9 Ko

En sortie de programme, j'ai eu ceci d'affiché:
Nom : message_memoire_lazarus.jpg
Affichages : 164
Taille : 21,1 Ko

Pas tout compris, mais il me semble que j'ai un peu de fuite de mémoire

Je vais tenter de recreuser le problème pour afficher l'image dans son intégralité...

**BeanzMaster** · 13/02/2019, 13h36

Envoyé par der§en

Alors, je ne suis pas arriver a afficher mon Bitmap en 65535 X 32768 ....
....
Je vais tenter de recreuser le problème pour afficher l'image dans son intégralité...

Je me suis mal exprimé hier en te parlant de Longint.
Pour faire simple tu ne pourras pas afficher ton Bitmap en 65535 X 32768 SANS MODIFIER LES CODES SOURCES DE LA LCL qui gèrent les TBitmap/TRawImage/TImage....

Pour tenter de t'expliquer le problème INTERNE je vais reprendre ton Algo Diamant-Carré

Pour ce faire tu utilises un Tableau (Carre) qui contient des Byte et un tableau (Palette) avec 256 couleurs maximum. Si tu souhaites avoir plus de nuances dans tes couleurs il te faudras agrandir ton tableau Palette et dans Carre il faudrat que tu utilise un type Word par exemple au lieu du Byte (tu vois ou je veux en venir ?)

Je vais reprendre ton bout de code , mais au lieu d'utiliser des PRGBTriple, je souhaite manipuler un Byte à la fois. Donc je prend un type PByte (c'est comme ça en interne)

J'insère volontairement des erreurs et je part du principe que ton bitmap est en 32 bits par pixel

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
var
   nbPixelTotal: Longint;  // LongiInt ENTIER SIGNE
   X : Byte;
   P: PByte;
begin
  P := PByte(FBmp.RawImage.GetLineStart(0)); // On se place sur la premiere ligne
  nbPixelTotal := FBmp.Width * FBmp.Height * 4;
  for X := 0 to nbPixelTotal - 1 do
  begin
    P^  := Palette[Carte[X*4]].Red;
    Inc(P);
  end;

Il clair que ce bout de code ne fonctionnera pas à cause du type de la variable X

Prenons ton Bitmap en 65535 X 32768 et calculons la taille total des données en conservant le type LongInt pour la variable nbPixelTotal

nbPixelTotal := 65535 * 32768 * 4 = 8 589 803 520 octets ce nombre astronomique dépasse l'intervalle autorisé par le type LongInt [ -2147483648
...2147483647 ] changeons LongInt par LongWord, idem nous avons un dépassement. LongWord [ 0..4 294 967 295 ]

Pour que le bout de code ci-dessus fonctionne et que tu puisses traiter toutes les données il te faut donc remplacer le type des variables X, nbPixelTotal par un type ordinal de 64 bit comme par exemple Int64 (Signé) et dont l'intervalle est [ -9223372036854775808
...9223372036854775807 ] ou mieux (car on commence à 0 et nous n'utilisons pas de type signé pour se déplacer dans un tampon) un QWord qui à un intervalle de [ 0..18446744073709551615 ]

Lazarus se voulant compatible 32bits et 64bits. C'est pourquoi les types utiliser dans ce genre de manipulation sont des types sur 32bits et signé en plus (ce qui est un mauvais choix de mon point de vu), ce qui fait que la limitation de pouvoir charger des images 32bits (32768 * 16384 * 4 = 2147483648 octets ) de plus de 2Go par défaut n'est pas possible. Et pour pouvoir monter jusqu'a 4Go il faudrait modifier les sources de Lazarus en utilisant un type signé comme LongWord.

Sinon il faut faire comme dans ton exemple utiliser plusieurs bitmap.

Dans mon cas pour ma solution de gestion des bitmaps, j'ai pu chargé de très grosse image (uniquement avec un OS en 64bit) car j'utilise des types 64bits dans la manipulation des tampons de données. La limite physique théorique serai de 18446744073709551615 octets soit 4.611686e+18 pixels codée en 32bits

plus que suffisant

Voila j'espère que j'ai été assez clair avec ces explications et que tu me comprendras

Bonne journée