Discussion :

[wd_newbie]

Bonjour,

Quelqu'un sait-il si il est possible de connaitre le poids en octet d'un variable image ?

J'ai testé un peu tout ce que j'ai trouvé, mais sans succès, je cherche a faire un peu comme ci-dessous, avec la fonction TailleImageOctets() qui irait bien

Code :

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

1
2
3
4
5
6
7
MonImage est une Image
 
// Chargement à partir d'un fichier
MonImage = dChargeImage("image.png")
 
// cêst ici que ça coince 
trace( TailleImageOctets(MonImage) )

[frenchsting]

Bonjour,

Le ftaille ne te suffit pas ?

Sinon, si tu "colles" l'image dans un buffer et que tu utilises taille(MonBufferQuiContientUneImage) ?

[Voroltinquo]

Bonjour,

Code :

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

nTailleImage=fTaille("image.png")

peut être

[serendib]

Bonjour,

Code :

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

nTailleImage=fTaille("image.png")

peut être

Trop tard

Bonjour,

Le ftaille ne te suffit pas ?

Sinon, si tu "colles" l'image dans un buffer et que tu utilises taille(MonBufferQuiContientUneImage) ?

[Jon Shannow]

C'est le poids de la variable ou le poids de l'image dont tu as besoin ?

Dans le premier cas, il faut utiliser Dimension,
Dans le second fTaille.

JS

[wd_newbie]

C'est bien le poids de la variable, il n'y a pas forcement de fichier image.

Par exemple si cela vient du presse-papier

J'ai testé la proposition de Frenchsting en mettant mon image dans un buffer, je peux ainsi avoir le poids de l'image

Merci à tous

[Patrice Terrier]

fTaille donne la taille en octets du fichier sur le disque, ce qui ne correspond pas du tout à l'occupation mémoire surtout dan le cas de fichier jpeg ou png qui sont compressés.

Une image, quel que soit sont format, est converti en bitmap une fois chargée en mémoire.
L'occupation mémoire dans le cas d'une image 32-bit (avec canal alpha) correspond donc à : largeur x hauteur x 4

[wd_newbie]

Une image, quel que soit sont format, est converti en bitmap une fois chargée en mémoire.
L'occupation mémoire dans le cas d'une image 32-bit (avec canal alpha) correspond donc à : largeur x hauteur x 4

Donc si je comprends bien la taille de mon buffer, si je fais :

Code :

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

1
2
3
4
5
6
7
8
9
 
imgImage est une image
bufImage est un buffer
 
PressePapier(ImgImage) 
 
bufImage = imgImage 
 
Trace(Taille(bufImage))

le trace ne me donnera pas le poids de mon image, celui qu'il prend effectivement dans une rubrique binaire de HFSQL ?

C'est ce qu'il faut comprendre ?

[serendib]

Il te dit que la taille en octets du fichier sur le disque, ne correspond pas du tout à son occupation mémoire.
Ce qui est assez logique.

[frenchsting]

C'est ce qu'il faut comprendre ?

Le format en mémoire n'est pas du tout le même que celui sur le disque. Il fut une époque, où la représentation mémoire d'une image était un BitMap. (Aujourd'hui, il semble que ce soient des formats propres à chaque logiciel). Si tu compares la taille d'un fichier au format JPEG à celle d'un fichier BMP (de la même image), tu verras l'énorme différence que cela représente.

[Patrice Terrier]

Il fut une époque, où la représentation mémoire d'une image était un BitMap.

Un bitmap, ou plus exactement un DIB bitmap, et c'est toujours le cas.

C'est comme pour les fichiers audio, in fine (en mémoie) c'est toujours un flux audio décompresé de type WAVE (inchangé depuis 1991)

[frenchsting]

@Patrice : Merci pour l'info

[wd_newbie]

Et visiblement c'est cette taille, sans compression qui est utilisée en base de donnée

Une image de 39ko sur le disque prend 470 ko dans HFSQL (selon le centre de contrôle)

ça ne motive pas de mettre des images en base de donnée

merci pour toutes ces infos

[Patrice Terrier]

En théorie vous pouvez stocker du binaire (compressé ou non) directement dans une base de données, je ne pense pas que HFSQL fasse exception.
Dans ce cas, si vous ne maitrisez pas la programmation bas niveau, il vous suffit d'exporter le binaire dans le dossier temporaire en utilisant l'extension de fichier d'origine, pour ensuite charger l'image en mémoire et l'effacer du répertoire temporaire.

[frenchsting]

Et visiblement c'est cette taille, sans compression qui est utilisée en base de donnée

Une image de 39ko sur le disque prend 470 ko dans HFSQL (selon le centre de contrôle)

ça ne motive pas de mettre des images en base de donnée

merci pour toutes ces infos

D'expérience, je déconseille de stocker des binaires dans un memo. Si le nombre d'enregistrements reste(ra) faible, alors, c'est une solution acceptable. Si le nombre d'enregistrements est amené à être (très) important (> 1 centaine de milliers d'enregistrements et/ou que les binaires sont volumineux), il vaut mieux stocker les binaires dans un dossier accessible uniquement par le programme.

Ce n'est pas un dogme. Il y a des cas dans lesquels on ne peut faire autrement, un SGBD "ultraperformant" (ex: Oracle avec un serveur qui déchire tout), etc... Mais c'est une règle que je me suis fixée et qui m'a toujours "réussi".

[wd_newbie]

Merci Frenchsting et aux autres pour toutes ces infos.

Effectivement je pense que je vais continuer dans le sens du répertoire partagé.

Je faisais quelques essais, car j'ai beaucoup de petit clients avec 2-3 machines dont une fait office de serveur, et souvent les réglages du partage c'est le foin

mais visiblement mettre ces fichiers en BDD semble apporter encore plus de soucis