Bonjour à tous.

Je me pose des questions concernant l'occupation en mémoire d'un TBitmap.

L'aide de Delphi 7 est à ce sujet assez sommaire.

Par exemple :

Méthode Assign : l'aide précise : « Si le bitmap doit être changé, l'image bitmap actuelle est copiée avant que les modifications soient effectuées. ». Quel intérêt ? Je suppose qu'après changement, la copie est libérée sinon : après avoir assigné à un bitmap une image de 10 millions de pixels, un deuxième appel à Assign avec une image de 300 pixels ferait garder en mémoire les 10 millions !!!?

Propriété Height : « Si la nouvelle valeur de Height est inférieure à la valeur en cours, l'image bitmap est détourée. ». Que reste-t-il en mémoire ?

 

Quel est l'intérêt gestion mémoire (et les inconvénients) des méthodes Dormant, FreeImage et ReleaseHandle ? 

Merci d'avance.

Réponse acceptée !
la reponse est dans ta question.

logiquement, on peu sans soucis appeler Bitmap.Assign(BitmapSource) sans que la memoire soit surchargée.
en effet, aprés plusieurs tests avec de grosses images, on voit bien que la memoire augmente ou diminue selon la taille de l'image en cours et il n'y a pas d'effet de surplus dus a l'ancienne image.

et en toute logique, Assign remplace les anciennes données par les nouvelles...

donc tu peux ouvrir 100000 fois une images BMP de 15Mo avec la methode assign, cela ne surchargeras pas la memoire de 15Tera Octet pour autant.

pour ce qui est du "detourée" c'est une nuance de traduction en anglais la def donne "crop" soit "recadrée" et donc les partie d'image qui ont étées "recadrée" sont perdues.
mais il suffit de retablir la taille d'origine pour recuperer les octets perdues (mais pas les pixels perdus)

pour reprendre la methode de calcul de michele qui a fait une erreur de taille,
la taille d'une image bitmap en memoire se calcule comme cela :

(Largeur * Hauter) * (PixelFormat div 8)

soit :
en pf24bits et pf32bits (pixels stockés dans des entiers 32bits (Integer, LongWord, Cardinal, LongInt))
(il n'existe pas a proprement parler de Bitmap 32bits, la valeur maximale serat donc la pluspart du temps pf24bits)

(L*H)*4

en pf16bits (pixels stockés dans des entiers 16bits (Word, SmallInt))
(L*H)*2

en pf8bits (pixels stockés dans des entiers 8bits (Byte, ShortInt))
(L*H)*1

Bonjour MICHELE,
merci pour ta réponse, mais mon souci n'était pas de connaître la taille d'un fichier, mais bien l'occupation en mémoire vive d'un TBitmap après diverses manipulations (assign, changement de taille...).
Bien à toi
Thierry

precisions et explications, si on stock les pixels 24bits dans des entiers 32bits c'est parce qu'il n'existe pas dans le CPU de registre 24bits mais uniquement 8, 16, 32 et 64 bits.
et il serait stupide de vouloir stocker un pixel de 24bits dans 3 registres 8 bits ... cela ne faciliterais pas les calculs et augmenterais par 3 le nombre d'instruction pour les traitements.

donc a retenir, si on utilise un entier 32bits pour stocker des valeur 24bits c'est parce que le CPU ne possede pas de registre 24bits.

Salut f0xi,

merci pour ta réponse.
Si tu as le temps, un petit mot peut-être sur Dormant, FreeImage et ReleaseHandle ? 

Thierry

sinon, willy ne t'inquiete surtout pas, au pire l'image ne peut faire que 4 giga-octets.
mais je doute que le systeme aille jusque la ... il devrais logiquement s'arreter dans les 350 - 400Mo

mais il te faudrat beaucoup de temps ou d'erreurs avant d'arriver au out of memory avec un simple bitmap.

au mieux, avec l'utilisation d'un buffer pour les traitement la taille en memoire fluctuerat entre la taille d'origine du bitmap et deux fois cette taille pendant le traitement sur le buffer qui devrat etre obligatoirement libéré aprés chaque traitement.

donc si cela peut te rassuré, avec une image de taille maximale : 1600x1280
tu auras une fluctuation de memoire entre 8.2Mo et  16.4Mo

mais aprés, l'astuce sur les trés grande image et de travailler sur des petite portions grace au methode copyrect et draw des canvas ou encore Scanline qui affiche d'incroyable performances.

alors

Dormant permet d'economiser la GDI ... mais cette methode semble bonne que sur les vieux systeme Windows 95/98/98se/Me
je pense qu'il est inutile de s'en soucier sous Windows XP / 2000

FreeImage libere l'image memoire chargée par le TBitmap ... en gros ça reviens a vider le TBitmap un peu comme la methode Clear des TStrings. on libere les données mais pas l'objet en lui meme.
cela permet d'eviter de recréer des centaines de fois un buffer pendant les traitements, on le vide tout simplement et on le libere réelement qu'a la fin des traitements.

ReleaseHandle et a utiliser avec precautions, il ne libere pas l'image mais permet de dissocier l'image de l'objet bitmap.
il faudrat donc reassigné l'image a une routine ou un objet qui lui se chargeras de libérer l'image.
Cela viens du fait que quand on ouvre une image dans un objet TBitmap, ce dernier crée une image memoire et lui assigne un Handle pour la reconnaitre. ReleaseHandle fait en sorte que l'objet ne reconnaisse plus ce handle mais en aucun cas ne libere l'image de la memoire.
Il est donc necessaire de bien faire attention, quand a l'utilisation de cette methode car elle peut engendrer de trés grosse fuites de memoires si on ne gere pas correctement tout cela.

Re-f0xi,

ok pour Dormant et ReleaseHandle.
Pour FreeImage, tu dis qu'il libère les données.
Je viens d'essayer :
   Bmp.LoadFromFile(...);
   Bmp.FreeImage;
   Image1.Canvas.Draw(bmp);

et j'ai toujours l'affichage du bmp !

En fait, d'après l'aide Delphi, FreeImage ne ferait que libérer la mémoire allouée à la copie (l'image) du bitmap.

A +
Thierry