copie images en mémoire

Dans l'aide il est écrit qu'un objet image peut stoker en mémoire une copie d'une image par la commande file_save.
Pourtant c'est sur le disque dur dont il est question là, pas de la mémoire.
Le manuel se trompe.
Savez-vous comment garder une série de copie d'images en mémoire et non sur disque ?

La doc dit:
- image peur SAUVEGARDER une image par FILE_SAVE
- image peut CHARGER une image par FILE_LOAD
ce qui me semble cohérent.

Un objet image contient une seule image quelque soit son origine (un fichier BMP chargé par FILE_LOAD, une partie d'un picture ou d'une form chargée par 2D_IMAGE_COPY, ...).

Si l'on veut stocker plusieurs images en mémoire, il faut autant d'objets image.

Non, la doc dit bien :
Image peut SAUVEGARDER une image en mémoire par FILE_SAVE





Ce que je souhaite faire c'est comme en turbopascal ou en C

stocker une image en mémoire et pouvoir la reférencer par un pointeur.
ou par un index dans un tableau je sais pas.

des fois ce sont des images de 64 px et d'autres fois des 16 px

Eh oui, c'est le problème de la sémantique de la langue française ! Je reformule cette phrase:
Un IMAGE peut sauvegarder son image contenue en mémoire, dans un fichier BMP par la commande FILE_SAVE.

Est-ce plus clair comme ça ?

J'ai pensé utiliser un picture comme stockage des images, mais comme leur taille varie, c'est pas facile de les stoker dessus sans qu'une écrase un bout d'une autre.

EDIT :
Oui c'est plus clair

Effectivement, c'est moins évident avec un PICTURE. Utilise un IMAGE par image à stocker, ce sera beaucoup plus simple, moins lourd à gérer. Tu n'as pas de problème de visibilité ou non à l'écran, et tu peux récupérer n'importe laquelle de ces images à tout moment, par 2D_IMAGE_PASTE, pour les envoyer dans un PICTURE ou même en image de fond sur une FORM.

Tu sais, il s'agit de 30 images, donc je me vois pas créer 30 objet images oO

C'est pas pratique comme systeme, je cherche à sauver les emplacement de map, pour rétablir en cas d'erreur, c'est un UNDO sur 30 coups quoi.

Je sais le faire par fichier mais c'est embêtant par disque car ça lag des fois, je cherche le moyen de faire ça en mémoire, mais si je peux pas je le ferais par fichiers.
.

Tu crées simplement 30 objets IMAGE comme ceci:

Code:

dim i%
for i%=1 to 30
    IMAGE i%+100  : ' images 101, 102, ...
next i%

puis tu les utilises en les accédant par 100+numéro d'image. Beaucoup plus rapide que par des fichiers sur disque, et facile à gérer.

Bon, maintenant dodo...

Oulaaaa mais c'est pas lourd en mémoire ça ?

Bon dodo

PS: Pour le moment le code que j'ai utilisé est dans le source que j'ai partagé dans la partie partage de sources.
Source pour faire des Undos

Ben... tu n'as pas trop le choix:
si tu ne veux pas d'accès disque, il va bien falloir stocker tes images en RAM...
Récemment, j'avais simuler un gif de cette manière....

Ah ok !!!



Dommage qu'on aie pas des pointeurs en mémoire^^

Et même dans ce cas, avec des pointeurs, il faut quand-même que les images soient en mémoire quelque part pour pouvoir être pointées...

Oui bien sûr^^ mais c'est moins de place qu'avec un objet systeme reservé à chacun non ?

Mais non. Les images doivent bien physiquement se trouver quelque part. Si tu les as sur disque, tu les accèdes par leurs noms de fichiers, et tu as les dégradations dues au temps d'accès. Si tu les as en mémoire, la place doit être réservée quelque part, et c'est l'objet IMAGE qui le fait. Tu ne peux pas avoir le beurre et l'argent du beurre.

@exdragon,
Une petite explication sur les pointeurs...

Si j'écris ceci:

Code:

DIM v,p
v=125
p=ADR(v)

On peux dire que la variable p est un pointeur sur la variable v.

Oui je sais ce qu'est un pointeur ^^
Ce que je dis, c'est qu'un objet systeme a un tas de données qui lui sont propres et en plus de se coltiner l'image qu'on lui charge, et tout ça ça prend sûremnt plus de place qu'une juste les données de l'image en mémoire.
Avec un pointeur, on a rien pris comme place et on peut adresser la zone mémoire de l'image, c'est ce que je dis.
.

Amen

Pour rendre "palpable" le problème des images et pointeurs, on va considérer des sacs de patates, au lieu des images. Chaque image est remplacée par un sac de patates, le disque dur par la cave, et la mémoire centrale par le cellier d'un appartement au 3ème étage sans ascenseur, et le programme par la cuisine de l'appartement.

1ère option: tous les sacs de patates restent à la cave. Donc, lorsqu'on a besoin d'un sac, on prend son courage à deux mains et on va le chercher, à pied, pour le remonter dans la cuisine de l'appartement, où il va prendre juste la place nécessaire pour le sac. Et lorsqu'un a besoin d'un sac de patates d'une autre variété, on redescend le premier sac pour en aller chercher un autre, etc. Fatiguant pour les jambes, mais optimisation de la place dans l'appartement !

2ème option: tous les sacs sont toujours à la cave, mais cette fois, on monte les sacs dont on a besoin, dans l'appartement, dans un cellier, par exemple. Certes, c'est du boulot au début - il faut se les trimbaler ! Mais ensuite, les sacs sont facilement accessibles. Si l'on a besoin d'une variété ou d'une autre, il suffit d'aller dans le cellier et remplir un panier. Mais c'est vrai: on prend de la place dans l'appartement !

3ème option: comme la (2), mais après avoir monté tous les sacs dans le cellier, on remplit un panier à oartir de chaque sac, et on place ces paniers dans la cuisine, dans une étagère par exemple. Cette fois, plus de déplacements - toutes les variétés sont directement accessibles, sans effort et sans perte de temps. Mais il y a toujours la place prise par les sacs dans le cellier (bon, on l'accepte pour ne pas avoir à faire les escaliers sans arrêt), et en plus il y a les paniers dans la cuisine. Ils prennent un peu de place supplémentaire, mais on l'accepte aussi, car on n'a plus à courir entre cuisine et cellier ! Ces paniers, ce sont les pointeurs, on l'aura compris.

La morale de cette histoire ? Dans la solution 3, tout semble idéal. On a un accès rapide, immédiat. Mais il faut quand-même réserver de la place dans le cellier pour autant de sacs que nécessaire simultanément, sinon, on sera quand-même obligé de descendre à la cave.

Cela montre que d'une manière ou d'une autre, on est toujours gagnant d'un côté et perdant de l'autre. Soit on optimise l'encombrement ce qui se fait forcément au détriment de la performance, soit c'est exactement le contraire.

Maintenant, une chose est certaine. Les nouvelles méthodes de construction nous donnent en permanence des appartements de plus en plus grands, et le peu de place occupée par quelques sacs de patates n'a que peu d'importance et en aura encore moins dans l'avenir. Tu vois où je veux en venir ? lLa mémoire vive des ordinateurs grandit très rapidement, et même une trentaine d'images ne pèsent pas lourd en mémoire. Une image genre photo pèse, disons 4 méga-octets ? 30 Images font dont 120 Mo . Par rqpport à des mémoires vives de 2, 3 ou 4 Go, c'est infime.

Très belle démonstration

Mais bon, il y a la solution aussi de descendre à la cave, remplir les paniers de chaque varietés et placer les paniers à la cuisine.

C'est plutôt comme ça que je le voyais.

Klaus, bravo pour l'analogie épicière !

Cela dit, effectivement on ne voit pas trop où il y a un problème de mémoire, avec les quantités pléthoriques que nous avons de nos jours, autant en profiter pour ne pas avoir à se coltiner les patates sans arrêt.
Et on gagne en rapidité d'exécution.
On n'est plus au temps où on avait 4 k de mémoire (j'ai eu), là on atteignait vite les limites.

N'empêche c'est vrai que le temps de l'économie de mémoire est passé, mais si on se laisse aller comme ça, les utilisateurs vont se retrouver avec des programmes qui font des tonnes.
Avant vous le savez un petit programme de rien du tout faisait des merveilles, maintenant il faut une usine pour faire presque la même chose.
Je trouve dommage que les programmeurs de nos jours aient perdu ça.

Exdragon, vu la taille de 30 images, les données annexes ne représente rien du tout par rapport à la taille mémoire qu'elles prennent. Si tu veux gérer avec un grand niveau de finesse la mémoire, ce qui dans ton usage ne me parrait pas utile, il faudrait faire appels à des programmes externes car ce n'est pas la philosophie de Panoramic. Il y aurait donc 2 possbilités, soit changer de langage, soit faire appel à une DLL externe qui s'en charge et soit appelé en Panoramic.
Toutefois, je le répète, selon moi, cela n'apporterait vraiment rien à ton programme et ne ferait pas gagner de mémoire car le peut que tu gagnerais serait largement occupé par le chargement de la DLL et tu perdrais le temps des appels qui correspondrait largement au temps que tu gagnerais en appelant directement les zones mémoires.

Je n'ai pas dit que la dll était le nec plus ultra....

J'ai juste demandé s'il y avait moyen de faire autrement qu'en chargeant 30 objets images, c'est tout, le truc des DLL ce n'est pas moi qui l'ai suggéré, donc garde tes remarques pour toi.

OK, j'essaye de t'expliquer, mais je garderai mes remarques pour moi à partir de maintenant Exdragon, il n'y a pas de soucis... Bon courage dans tes dev

@Exdragon:
Un pointeur sur un fichier sur disque, ça s'appelle un nom de fichier. Il n'y a pas d'autre solution. Et il faut alors lire le fichier chaque fois qu'on en a besoin. C'est là que l'analogie boite: il n'est pas possible de garder en mémoire un lien ou pointeur sur un fichier de type image. Dans l'analogie, cela signifie que les paniers n'ont pas le doit de sortir de l'appartement.

C'est différent avec des fichiers contenant des données, binaires ou texte, par exemple. Là, on peut "ouvrir" tous ces fichiers et les garder ouverts, et en cas de besoin, lire en accès direct juste la portion qui nous intéresse. Ceci n'est pas possible avec des fichiers de type média (image, son, video,...) et de manière tout type de fichier qui est géré en sa totalité par une entité système. Désolé, ça n'existe pas.

Donc, n'aie pas de regrets, utilise la mémoire et tu auras une application performante.

Mais oui, moi aussi, j'ai connu le temps où il fallait se contenter de mémoires centrales de 64 ko 5oui, soixante-quatre kilo-octets !) dans lesquels il fallait faire tenir le système d'exploitation, le programme ET les données dynamiques ! Les overlays de 300 segments en 15 niveaux hiérarchiques, je connais ! Cela paraît totalement fou aujourd'hui, mais à l'époque, on a fait tenir une compta et une paie complète dans cet espace, avec 4 disquettes souples de 512 ko chacune comme disque dur ! C'est la pré-histoire ! Et encore, pour moi, à l'époque, c'était déjà un gros progrès car j'ai connu encore plus archaïque... Mais là, on parle de paléontologie informatique.