Discussion :

[Ardely]

Bonjour, je cherche une solution pour accumuler toutes mes petites images bmp (env. 1000) (de1 à 9 Kbytes) dans un seul fichier?
Comment dois-je faire pour avoir toutes les images dans un seul fichier et comment dois-je faire pour les lire et les faire afficher sur ma form (TImage).
L'affichage d' une image doit se faire par un edit ou l'on tape par example un numéro ou un nom. (Du genre TImageList!)
Quelles pistes pouvez-vous me proposer pour que je puisse faire cela.

Merci beaucoup pour le chemin.

[Ardely]

Je ne pense pas d'utiliser une base de donner... pour ce genre de stockage.
Le traitement je pense de le faire par un flux, peut-être d'une sorte : type record - est-ce possible?

[Clorish]

la classe TBitmap possede uen fonction bien pratique : SaveToStream.

Tu peux donc sauvegarder ton image dans un TMemoryStream Temporaire puis generer ton fichier final via TFileStream en y copiant le contenu des TMemorystream successif.

Je te conseille de creer un index des position dans le TFileStream de tes images pour gerer les images directement depuis le fichier.

LA je manque un peu detemps mais j'essayerais de revenir te proposer ine solution plus detaillée.

[ShaiLeTroll]

EDIT : le Temps que j'écrive ma solution Clorish est intervenu, en fait je pense que j'ai expliqué la même chose ...

Plein d'image BMP dans un fichier, tu veux te simplifier la vie, cherche des composants ZIP pour Delphi, et tu gères des images dans le Zip, l'avantage, c'est que ces composants fournissent en général des functions pour Stream idéal pour un chargement dans un TImage..., ...

Sinon, la solution manuelle, tu as un fichier, voici une structure d'exemple (es-tu à l'aise avec le FileStream, ou la fonction BlockRead, ainsi que la lecture de données binaires et non Texte ?)

Le Fichier
Un Entier = Le Nombre d'Image
Une série de Structure TArdelyIndex qui contient
Un Entier = Le Numéro de l'Image
Un Entier = Offset dans le Fichier de l'Image
Un Entier = Taille de l'Image en Octet
Une Chaine[255] = Nom du Fichier
Ensuite, qui du binaire, les BMP ...

Pour lire tu charges dans un Tableau of TArdelyIndex (taille défini par le Nombre d'Image), cela donne en gros

Code :

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

1
2
3
4
5
6
MonStream.Read(LeNombreImage, 4);
SetLength(MesImagesInfos, LeNombreImage);
for i := 1 to LeNombreImage do
begin
  MonStream.Read(MesImagesInfos[i], SizeOf(TArdelyIndex)); 
end;

Code :

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

1
2
3
4
5
6
TArdelyIndex = packed record
  ID: Cardinal;
  Offset: Cardinal;
  BMPSize: Cardinal;
  Title: ShortString[255];
end;

Ensuite tu veux lire l'image numéro 32 (disons que le numéro et l'index dans le tableau sont confondus), par de soucis

Code :

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

1
2
3
4
MemoryStream.Size := MesImagesInfos[32].BMPSize;
MonStream.Seek(MesImagesInfos[32].Offset, FromBeginning);
MonStream.Read(MemoryStream.Memory, MesImagesInfos[32].BMPSize); 
MonImage.LoadFromStream(MemoryStream);

Pour écrire, c'est plus compliqué, il faut soit tout réécrire à chaque coup, soit géré l'index de façon plus poussé (dans un second fichier ou laisser de la place pour ajouter des index avant de devoir déplacer les blob) ... je dirais que c'est un objet, que si j'avais le temps (taf taf), je l'aurais bien écrit pour toi, J'ADORE les SUSHI, euh non le traitement de Fichier ...





En Gros lire un Entier ça donne

Code :

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

MonStream.Read(UnEntier, 4);

ou encore

Code :

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

BlockRead(MonFichier, UnEntier, 4);

[Ardely]

Merci pour tes conseille.
Je connais les fonctions BlockRead, BlockWrite... pour travailler avec! Je suis plein d'enthousiasme de réfléchir sur ta proposition très intéressante. Donc si j'ai bien compris en gros je cumule par une boucle les fichiers BMP (A.bmp + B.bmp +....X.bmp) pour avoir un fichier et mémorisant à chaque fois les Offset debut-fin fichier etc.. pour l'index. ok. Maintenant pour lire un fichier soi-disant l'offset est début: 1356 - fin: 1997, comment le mettre dans un Timage !

Image1.Canvas.Draw(0,0,Image2);

Salutations et bonne soirée.
Ardely

[Clorish]

Merci le troll pour l'exemple que je voulais mettre
Ca c'ets du travail d'equipe :p

Par contre j'opterais plutot pour un TFileStream qu'un BlockRead/Write.

L'avantage c'est la lecture/ecriture simultané sur le flux et la possibilité de basculer d'un TMemoryStream a un TFileStream sans une ligne de code.
Tres pratique quand on souhaite aller un peu plus loin que le simple chargement de fichier (gestion reseau, packages, protection de fichier par cryptage, etc ....)

[Edit]
Petite illustration :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
Procedure MaClasse.LoadFromStream(AStream : TStream);
begin
<Traitement des donnees>
End;
 
Procedure TMaClasse.LoadFromFile(Filename : String);
Var FS : TFileStream;
Begin
FS := TFileStream.Create(Filename, fmOpenRead);
Self.LoadFromStream(FS);
FS.Close;
End;

Ce code permet de charger des donnees depuis un fichier via :

Code :

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

mc.LoadFromFile('c:\données.dat');

ou bien depuis la memoire :

Code :

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

1
2
3
4
5
6
7
 
Var MS : TMemoryStream;
MS := TMemoryStream.Create;
MS.LoadFromFile('c:\donnees.dat');
<pre-traitement>
mc.LoadFromStream(MS);
MS.Free;

Lors du pretraitement on peut par exemple faire appel a :

Code :

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

Decrypt(MS, Key);

une fonction quelconque qui decripte le contenu d'un flux.
De cette maniere on peux charger un fichier en memoire, le decrypter dans une procedure autonome et le charger en suite depuis le flux memoire decrypté sans avoir a le resauver sur le disque en clair, ce qui est pas terrible

Bien d'autres application sont possible comme le transfert reseau depuis un serveur ou encore comme on le voit deja pour ce cas la, la gestion des "archives".
Dans notre cas on cree une sorte de "zip" contenant des fichier image bitmap simple. Heureusement que TBitmap possede une fonction LoadFromStream qui nous evite de charger l'image sur le disque de maniere temporaire.

Sur le meme principe, ce fichier image peut etre stocké avec d'autres ressources soit dans une archive de ce type, soit directemetn en tant que ressource (TRessourcreStream ) de l'application. Et la encore, si on veux eviter de passer par une version "filename" il et interessant de gerer la lecture depuis un Stream

[tourlourou]

pour ma part, plutôt qu'utiliser 2 streams et copier les données de l'un à l'autre, j'utiliserais un TMemoryStream pour ouvrir le fichier, et un TSharedMemoryStream (un stream que j'ai développée exprès, disponible ici : http://www.phidels.com/php/index.php...ip.php3&id=595)
il permet de passer au TImage pour son LoadFromStream un Stream (ReadOnly) qui pointe sur une portion de la mémoire d'un TMemoryStream, évitant de dupliquer les données.

ce n'est pas déterminant sur de petits volumes, mais c'est toujours ça de pris !!!

[Clorish]

L'idee est en effet interessante.
Mais pourquoi charger dans un TMemoryStream plutot que dans un TFileStream ?

Sinon en ce qui me concerne, quand je developper des fonctions LoadFromStream pour mes propres formats de fichiers, je charge les données depuis la position courrante du Stream, ce qui me permet de transmettre successivement le meme stream a divers instances qui se chargent de charger les donnéees qui la concerne a partir de la position courrante, me laissant le stream en sortie de procedure a une nouvelle position, situé apres le bloc chargé et donc pret a charger le bloc suivant dans une autre procedure.

Je ne connait pas la methode LoadFromStream du TBitmap mais si ils ont fait comme moi, on aurais meme pas besoin d'un TSharedMemoryStream

[Edit] Apres verification des sources et confirmation par un petit test, il semblerias bien que TBitmap ne reinitialiser pas les Stream lors de la sauvegarde/Chargement d'un stream.
On peut donc appeller successivement les methodes LoadFromStream et SaveToStream sur le meme Stream, pour enregistrer/charger successivelement les images dans la Stream, sans apsser par un stream temporaire ou le TSharedMemoryStream

[tourlourou]

il semblerias bien que TBitmap ne reinitialiser pas les Stream

il lira donc jusqu'au bout le stream, à partir de la position fournie, mais en ne s'arrêtant pas à la fin du bitpam souhaité (à moins que je ne me trompe)

Mais pourquoi charger dans un TMemoryStream plutot que dans un TFileStream ?

pour utiliser des pointeurs sur la zone mémoire qu'il a allouée !

[Clorish]

il lira donc jusqu'au bout le stream, à partir de la position fournie, mais en ne s'arrêtant pas à la fin du bitpam souhaité (à moins que je ne me trompe)

Tu te trompe

pour utiliser des pointeurs sur la zone mémoire qu'il a allouée !

Ouaip .... je maitrise mal cette partie. Je pense que l'on peut faire autrement mais je ne sais pas si c'est faisable.

[tourlourou]

je me suis effectivement gouré ! car il y a un header dans le BitMap qui est lu et donne sa taille ; mea culpa

[ShaiLeTroll]

Effectivement, j'ai aussi basé mon exemple sur un principe de précaution, qui veut que l'on ne fourni que ce qui est nécessaire au composant Image, je suis donc passé par un LoadFromStream qui utilise un tampon, si le TBitMap ou TImage, lit l'entête et donc juste l'image demandé, on peut manupiler directement avec des Seek ...

Code :

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

1
2
3
 
AFileStream.Seek(MesImagesInfos[32].Offset, FromBeginning);
MonObjetImage.LoadFromStream(AFileStream);

[anapurna]

salut

bon si on reprenez du debut
tes images ont toutes le meme format ?
le nombre de tes image ne bouge plus ?

si oui pourquoi ne pas creer un mega bitmap avec tes diverses images
ensuite il te suffit juste de lire le bitmap et ne copier
que la zone qui t'interesse

sinon effectivement tu peut utiliser les stream

@+ Phil

[Ardely]

Salut a tous..
Je pense que je devrais avoir assez d'information pour commencer à programmer et l'idée que vous me proposer est bonne pour me préparer dans cette direction,
je dois juste encore un peu me familiariser avec quelque commande et puis je pense que c'est parti....
Merci beaucoup et salutation.

[Clorish]

a tout hasard ... quel est la solution que tu as retenue ?

Sinon l'idee d'un meta bitmap est une bonne idee.
LA plupart des skins utilisent ce genre de chose.
Mais ca exclut le coté dynamique, enfin de maniere simple

[Ardely]

Hallo,
La solution qui m'intéresse et qui est aussi très pratique est la gestion du contenu du flux avec les TFileStream ,par exemple comme tu le proposes le cryptage, cette façon est très dynamique, aussi pour d'autre posibiliter.

Pour moi sufi de créer un index et les images en une seule fois, c'est-à-dire si on veut ajouter une image on réécrit le tout.

Merci beaucoup pour les bonnes idées, salutations.

[Clorish]

Pour gerer les fichier indexés, en general je sctoke en premier le nombre de donnees, puis une suite de 2N Integers (Postion/Taille) puis je copie successivement les donnes en stokant en memoire dans un tableau la taille et la position du stream avant la copie.
Apres je positionne mon stream sur le 4e octet (ou plus si le "header" contient plus d'infos que le nombre d'objets) et je boucle pour ecrire a partir de cette position les couples tailles/position stockés en memoire.
Cela ecrase en fait les données existantes, qui sont en faite que la serie de "0" ecrit precedement pour les remplacer par les valeurs exactes. Si tout est bien fait, on ira pas ecraser les donnees qui suivent :p
On peut aussi simplement ecrire cet index a la fin du stream et revenir ecrire juste la position de cet index en debut de fichier.

Pour les fichiers dont on ne connait pas a l'avance le nombre de fichier, une utilisation d'un index a la fin est necessaire.
Tu copie juste un "0" en entete de stream, puis la liste des donnéees, et apres l'index : Nombre de donnees suivi des couples position/tailles.
Tu reviens ensuite ecrire dans le premier octet l'adresse de depart de l'index.

Un des avantages des index en fin de fichier est qu'on peut y stocker des information de taille dynamique comme les noms des fichiers.
Place en entete, il est necessaire de connaitre la taille exacte finale de l'index pour eviter l'ecrasement des données qui suivent.

Tu peux aussi gerer cet index dans un fichier a part, le fichier principal ne servant qu'a concatener les donnees. L'inconvenient de cette methode est qu'il est facile de perdre l'index, rendant le fichier inutilisable.

[Ardely]

Superbement grand merci pour tes notes très constructives qui m'aide très beaucoup a la construction.
À bientôt, salutations.

[tourlourou]

@ Clorish : je viens de retomber sur le problème qui m'avait fait développer le TSharedMemoryStream !

A savoir : l'ouverture de la vignette jpeg d'une photo au format exif avec l'unité IJpeg.pas, qui exploite une librairie intel pour accélérer la décompression.

Le LoadFromStream à partir d'un stream positionné sur le début de la miniature ouvre quand même l'image principale, qui est stockée un peu plus loin dans le flux... et c'est dans la lib que ça se passe, pas dans le wrapper !

Tout ça ne fait pas avancer le schmilblick, mais j'avais bien un problème sans autre (?) solution.

Et donc, malheureusement, le comportement d'une fonction LoadFromStream n'est pas identique d'un objet à l'autre, le TJpegImage ouvrant bien, lui, la miniature...