TBitmap et occupation mémoire [Résolu]

ThWilliam 424 Messages postés mardi 3 janvier 2006Date d'inscription 26 novembre 2013 Dernière intervention - 1 mai 2006 à 15:00 - Dernière réponse : ThWilliam 424 Messages postés mardi 3 janvier 2006Date d'inscription 26 novembre 2013 Dernière intervention
- 3 mai 2006 à 10:24
Bonjour à tous.<?xml:namespace prefix o ns "urn:schemas-microsoft-com:office:office" /?>







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.
Afficher la suite 

Votre réponse

13 réponses

Meilleure réponse
f0xi 4304 Messages postés samedi 16 octobre 2004Date d'inscription 9 mars 2018 Dernière intervention - 1 mai 2006 à 18:35
3
Merci
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)

Merci f0xi 3

Avec quelques mots c'est encore mieux Ajouter un commentaire

Codes Sources a aidé 72 internautes ce mois-ci

Commenter la réponse de f0xi
Meilleure réponse
DeltaFX 459 Messages postés lundi 19 avril 2004Date d'inscription 8 avril 2009 Dernière intervention - 2 mai 2006 à 23:24
3
Merci
Thwilliam, le RGB standard est 24 bit ( 3 octets, soit 256 valeurs possible pour le rouge, le bleu et le vert, et 256^3 pour les combinaisons possibles). En 32bit ( 4 octet) tu as un octet de plus donc 256 valeurs utilisables, 256 niveau de transparence, soit 256 index de selection..... au choix selon ce que tu decides de stocker dedans. Exemple le Bumpmapping où tu peux fort bien stocker dans cet octet supplémentaire une valeur qui définit comment la surface est déformée, dans le cas ou tu codes une texture pour faire de la 3D.

Le HDR, le High Dynamic Range.... ben imagine une eglise avec des vitraux. T'es dedans, ta vue s'adapte a l'obscurité du lieu, et vlan le soleil passe par un vitrail: Tu obtiens une image TRES lumineuse (le vitrail) dans une plus grande image globalement sombre (mais riche en détails néanmoins). Là tu as comme l'impression que les couleurs "débordent" de la fenetre. Imagine un manche de parasol qui cache pil poil le soleil, parfois on a l'impression que l'obstacle est plus "étroit" quand la lumiere passe de part et d'autre.
La palette de luminosité/teinte que peux rendre un ecran est faible, plus faible que ce que peux voir ton oeil ( déja rien que les couleurs fluo sont merdiques, on perd l'aspect fluo du truc qui transforme une partie de l'UV en jaune, par exemple) Donc une scene d'eglise en synthese d'image, entre les ombres subtiles et le vitrail eclatant, ou tu rends bien les ombres mystérieuses, et t'as un vitrail terne, ou tu rends un vitrail flashant, mais par contre tes ombres subtiles pleines de détails précieux, zobi ! Car on est limité par le RGB standard.

Le HDR permet de stocké par pixel un "multiplicateur", ainsi dans le cas du vitrail, on peut avoir des ombres subtiles, détaillées et tout,  ET en ayant  les pixels du vitrail affectés d'un multiplicateur élevé, on étend artificiellement la palette. ( si c'est pas clair, penses a un MP3 enregistré avec un volume faible, le format du tagID2 te permet de stocker par mp3 une valeur d'ajustement du volume, sans avoir besoin de faire un passage par un wav, corriger le volume du wav, réencoder le mp3. C'est le lecteur qui lit le tag, et sait qu'il doit augmenter de 10% le volume en sortie)

En soit ca ne change rien, mais dans les scene en mouvement, les bons progs (3dsmax entre autres) te font un motionblur (flou de mouvement) correspondant au déplacement de la scene pendant le temps où l'iris (simulé) est ouvert (la formule 1 floue sur une photo trop lente). ET là, vlan, le vitrail semble fade, tout terne, alors que dans la réalité, il reste n fois plus lumineux que le reste de l'image, et meme te laisse une trainée sur la rétine (persistence rétinienne).

Si un canal HDR est présent, et que le prog le gère ( et que t'as une Geforce 12000 DirectX18 ....), au moment de faire un MotionBlur, il utilisera les infos de luminosité étendue pour compenser l'affadissement du vitrail. ET là, whaaaa....    photoréalisme.

Merci DeltaFX 3

Avec quelques mots c'est encore mieux Ajouter un commentaire

Codes Sources a aidé 72 internautes ce mois-ci

Commenter la réponse de DeltaFX
f0xi 4304 Messages postés samedi 16 octobre 2004Date d'inscription 9 mars 2018 Dernière intervention - 1 mai 2006 à 18:44
0
Merci
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
Commenter la réponse de f0xi
ThWilliam 424 Messages postés mardi 3 janvier 2006Date d'inscription 26 novembre 2013 Dernière intervention - 1 mai 2006 à 18:45
0
Merci
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
Commenter la réponse de ThWilliam
f0xi 4304 Messages postés samedi 16 octobre 2004Date d'inscription 9 mars 2018 Dernière intervention - 1 mai 2006 à 18:48
0
Merci
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.
Commenter la réponse de f0xi
ThWilliam 424 Messages postés mardi 3 janvier 2006Date d'inscription 26 novembre 2013 Dernière intervention - 1 mai 2006 à 18:50
0
Merci
Salut f0xi,

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

Thierry
Commenter la réponse de ThWilliam
f0xi 4304 Messages postés samedi 16 octobre 2004Date d'inscription 9 mars 2018 Dernière intervention - 1 mai 2006 à 18:54
0
Merci
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.
Commenter la réponse de f0xi
f0xi 4304 Messages postés samedi 16 octobre 2004Date d'inscription 9 mars 2018 Dernière intervention - 1 mai 2006 à 19:05
0
Merci
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.
Commenter la réponse de f0xi
ThWilliam 424 Messages postés mardi 3 janvier 2006Date d'inscription 26 novembre 2013 Dernière intervention - 1 mai 2006 à 19:20
0
Merci
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 !
Commenter la réponse de ThWilliam
ThWilliam 424 Messages postés mardi 3 janvier 2006Date d'inscription 26 novembre 2013 Dernière intervention - 1 mai 2006 à 20:44
0
Merci
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
Commenter la réponse de ThWilliam
DeltaFX 459 Messages postés lundi 19 avril 2004Date d'inscription 8 avril 2009 Dernière intervention - 2 mai 2006 à 10:08
0
Merci
Comme l'a dit Foxi, le 32bit c'est bien souvent du 24bit enrobé, pour passer intelligement dans les registres. Mais le 32bit a une utilité flagrante, l'alphachannel. soit un octet de plus pour coder la transparence d'un pixel. On peut s'en servir aussi pour planquer un mask de selection, voir du HDR.
Commenter la réponse de DeltaFX
ThWilliam 424 Messages postés mardi 3 janvier 2006Date d'inscription 26 novembre 2013 Dernière intervention - 2 mai 2006 à 12:27
0
Merci
Salut DeltaFX,

Un petit mot peut-être sur la couche alpha ? Je connais par PhotoShop, mais je ne l'ai jamais utilisée en Delphi.
Le 4° octet est-il simplement 0 ou 1 (transparent, non transparent) ou permet-il 256 valeurs d'opacité (pour fusionner deux images) ?
Et que signifie HDR ?

Thierry 
Commenter la réponse de ThWilliam
ThWilliam 424 Messages postés mardi 3 janvier 2006Date d'inscription 26 novembre 2013 Dernière intervention - 3 mai 2006 à 10:24
0
Merci
Salut DeltaFX,
Superbes, tes explications.
Merci et à +
Thierry
Commenter la réponse de ThWilliam

Vous n'êtes pas encore membre ?

inscrivez-vous, c'est gratuit et ça prend moins d'une minute !

Les membres obtiennent plus de réponses que les utilisateurs anonymes.

Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.

Le fait d'être membre vous permet d'avoir des options supplémentaires.