Discussion :

[130i-24v]

Bonjour,

Je réalise un petit programme qui sert à localiser sur carte des données mesurées sur le terrain.
En fonction de coordonnées (x,y) en lambert 2E, j'ouvre à l'écran la carte sur lequel se trouve les données mesurées. On dispose ainsi de 300 cartes au 100 000 ieme découpant le territoire national.
On aimerait bien donner ce petit soft à des clients, mais pour le moment je suis obligé de fournir les 300 dalles (c'est du jpeg) avec mon soft.
Quel moyen simple (je suis pas un as du delphi) existe t il pour ne pas donner les 300 cartes (400 mo à peu pres)?

J'aimerais par exemple donner le .exe de mon programme et un gros fichier unique contenant les 300 dalles. Est ce possible?

Ou sinon integrer les jpeg en tant que ressources, afin de les mettre dans le .exe ? Est ce raisonnable sachant que je vais me retrouver avec .exe de 400Mo au moins? Ca ne risque pas de ramer ou d'etre bcp trop lourd vu que je presume que le .exe va etre mis dans la ram ?

Le but de la manoeuvre c'est surtout d'éviter de donner 300 fichiers au client.

Voila voila...
Merci à ceux qui m'ont lu
Thierry

[Gaadek]

Pour moi, je ne vois pas en quoi cela pose un problème?

Si tu compresses tes cartes dans une archive, certe, tu vas gagner en place, mais le jour où tu fais une mise à jour, tu dois donner la nouvelle archive complète, et ce même si une seule dalle a changée.

Ne parlons même pas du cas où tu insère ces images sous forme de ressources, vu que dans ce cas, tu dois redonner un exe d'une centaine de Mo.

Donc la solution que je te propose: tu graves le tout sur un CD (.exe + les 300 fichiers) et c'est tout. Il existe énormément de logiciels qui nécessitent beaucoup de données découpées en centaines de fichiers, donc je ne vois pas en quoi cela serait génant dans ton cas?

[130i-24v]

Oui en cas de changement d'une dalle il faudrait tout changer. Mais la mise à jour des dalles est au plus d'une fois par an, ce qui reste raisonnable. (j'ai d'un coté les fichiers jpg des dalles et d'un autre coté les mesure géoréférencé).
En fait c'etait principalement pour le coté pratique d'avoir un seul fichier regroupant les 300 dalles, mais aussi pour que le client n'ait pas un accès trop facile aux dalles jpg sans pour autant faire un truc super protégé.

Thierry

[Gilbert Geyer]

En fait c'etait principalement pour le coté pratique d'avoir un seul fichier regroupant les 300 dalles,

Juste une idée : Ne serait il pas possible, via un TFileStream, d'envoyer en rafale les 300 jpeg séparés par un marqueur de séparation sur le disque dans un fichier unique de regroupement ? ... sachant que ces marqueurs de séparation serviront ultérieurement lors des relectures de retrouver chaque bloc de données jpeg entre les positions délimitées par ces séparateurs.

J'ai fait plusieurs bidouilles similaires en regroupant dans un seul fichier des trucs délimités par des séparateurs (bloc-notes-de-fiches au format .txt, mode-d'emploi multipages au format .rtf) avant de découvrir les possibilités des FileStream.

En plus avec TFileStream on peut même profiter de l'étape d'écriture de regroupement pour capturer la position de chaque séparateur dans une table qu'on envoie également sur le disque en prévision des relectures ultérieures par positionnement-direct en pré-chargeant ce fichier-de-relevé-topographique-du-gros-fichier avant de lancer la lecture de ce gros fichier.

Si en plus tu donnes par exemple au nom de ces fichiers une extension du style .dll ou un truc qui détourne l'attention aucun client lambda n'ira y chercher les cartes et même un fouineur qui utiliserait un éditeur Hexa aurait des difficultés pour s'y retrouver ... sans oublier qu'avec l'astuce du fichier-de-relevé-topographique des positions on pourrait même se permettre d'utiliser des séparateurs variables (ex : CRLF un coup et autres combinaisons de deux caractères du début de la table Ascii en évitant toute combinaison propre au format jpeg) pour berner un bidouilleur fouineur ... mais comme tu dis "sans pour autant faire un truc super protégé" c'est peut-être pas la peine de se compliquer la vie en allant jusque là.
Bon dév.

[EPJSoft]

je serais aussi dans l'idée Gilbert Geyer
générer des Records contenant les données images (jpeg voir même mieux des png)
De préférences j'opterai pour plusieurs fichiers plutôt qu'un car en cas d'anomalie c'est le gros fichier qui morfle...
Tu peux aussi faire comme dans certains jeux, tu changes l'extension de l'image, tu mets .dat par exemple alors qu'en réalité il s'agit d'images...
Pourquoi pas aussi l'intégrer dans un .cab ou un fichier compresser mais on rejoint l'idée de Gilbert : 1 fichier pour 300 dalles...
Ou alors faire des fichiers par zone latitude ou longitude... (cela ne limite pas les fichiers à une futur extension européenne ou planétaire lol) sauf si la terre s'applatit arrggg

Gaadek a dit :Si tu compresses tes cartes dans une archive, certe, tu vas gagner en place, mais le jour où tu fais une mise à jour, tu dois donner la nouvelle archive complète, et ce même si une seule dalle a changée.

Pas forcément, si tu fournis un programme de mise à jour genre patch qui te remplace la dalle correspondante dans l'archive... Tu peux même l'inclure dans le programme exe => emplacement du patch update.zip par exemple et dedans tu mets les dalles mises à jour... dés qu'il y a un fichier update.zip au lancement du programme celui ci met à jour l'archive et surprime l'update ou le flag comme mis à jour (tenir compte de la version de la dalle)

cela me fait rebondir sur un truc...
créer son propre format de fichier avec une entete personnalisé et ensuite l'image en question (le jpeg). Dans l'entete tu pourras ainsi intégréer la date de l'image ou sa version...

D'ailleurs tu peux aussi t'orienter vers le principe d'intégrer les ressources dans une dll. (en plus tu as la version de ce fait)...

[Paul TOTH]

j'ai fait un soft comme ça

pour ne pas diffuser toutes les images d'un coup, j'utilise un site web.
Celui ci-contient toutes les images plus un fichier texte contenant la liste des images.

le nom de chaque image est lié à sa position lambert, du coup, je peux facilement savoir si l'image d'une dalle est disponible en consultant le fichier texte.

le programme charge donc d'abord le fichier texte, puis, si nécessaire charge les images dont il a besoin. Un système de cache local évite bien évidemment de recharger l'image à chaque fois

les images JPEG possèdent d'ailleurs une caractéristique intéressante, il est possible de décompresser l'image à une taille réduite. J'utilise cette possibilité pour adapter la taille des dalles au facteur de zoom de la carte et ainsi gagner en occupation mémoire.

[130i-24v]

Bonjour et tout d'abord merci pour vos contributions...

Je suis parti sur l'idée de Gilbert. Ne connaissant pas les "Streams" j'ai cherché des infos sur internet et je suis finalement arrivé tant bien que mal à faire un petit programme qui à partir de deux images JPG A et B font un seul fichier A+B (je me contente pr le moment de concaténer simplement).
Et paralèllement j'ai fait le programme inverse qui à partir du fichier A+B me redonne A et B, connaissant le début de B.

Voici une partie du code du programme qui découpe A+B et qui récupére uniquement le fichier B et qui en meme temps charge B dans un Tmemorystream (à terme je ne veux pas redecouper en créant un fichier mais simplement le charger en mémoire) :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
procedure TForm1.Button1Click(Sender: TObject);
begin
 
 T2:='test';  // A+B
 T4:='test2.jpg'; // A
 T5:='test5.jpg'; // B
 
 E := TFileStream.Create(T4, fmCreate);
 E2 := TFileStream.Create(T5, fmCreate);
 L1 := TFileStream.Create(T2, fmOpenRead);
 Memostream:=Tmemorystream.create;
 
 L1.position:=1781904;  // je me place au début de B
 
 for i:=1 to 169657  do  // je parcoure la "zone" de B
  begin
   L1.readBuffer(b,sizeof(byte));  // Je lis le fichier A+B
   E2.WriteBuffer(b,sizeof(byte)); //J'écris ce que je lis dans E2 (Filestream)
   memostream.WriteBuffer(b,sizeof(byte)); //J'ecris ce que je lis dans                        memostream
  end;
 
 
  pict:=TjpegImage.create;
  pict.LoadFromStream(Memostream); //Je charge dans Pict mon Memostream
  image1.picture.bitmap.assign(pict); //J'affiche Pict (Erreur #41)
 
 
 E.free;
 E2.free;
 L1.free;
 pict.free;
end;

Le probleme c'est que je n'arrive pas a afficher l'image dans un Timage placé sur ma form. Ca me renvoie une erreur JPG#41 (format invalide). Pourtant le fichier crée en meme temps que je remplis mon memory stream est bien un jpg valide car je peux l'afficher sans probleme avec paint. Et c'est bien la derniere ligne qui cause l'erreur

Code :

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

image1.picture.bitmap.assign(pict); //J'affiche Pict (Erreur #41)

Est ce que je me sers bien de Memorystream?

Soyez indulgent avec mon code je suis pas informaticien

Merci !
Thierry

[Gilbert Geyer]

Ne connaissant pas les "Streams" j'ai cherché des infos sur internet

... t'aurais pu trouver ici-même des infos dans le Tutorial avec Edition-Rechercher stream.

Remarque 1 à propos de ton code :

Code :

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

1
2
3
4
5
6
7
8
 
T2:='test';  // A+B
T4:='test2.jpg'; // A
T5:='test5.jpg'; // B
 
E := TFileStream.Create(T4, fmCreate);
E2 := TFileStream.Create(T5, fmCreate);
L1 := TFileStream.Create(T2, fmOpenRead);

... c'est un jeu de piste assez difficile à suivre et à se mélanger les pinceaux ce serait plus clair de pouvoir suivre les indices ou le genre à la trace par exemple comme suit :

Code :

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

1
2
3
4
5
6
7
TAB:='test';  // A+B
TA:='test2.jpg'; // A
TB:='test5.jpg'; // B
 
FSA := TFileStream.Create(TA, fmCreate);
FSB := TFileStream.Create(TB, fmCreate);
FSAB := TFileStream.Create(TAB, fmOpenRead);

... c'est-y-pas plus lisible ?

Remarque 2 au sujet de L1.position:=1781904; et de for i:=1 to 169657 : Est-tu certain du 1781904 et du 169657 car il suffit de se tromper d'une unité en plus ou en moins et la partie lue sur disque risque de ne pas être ensuite reconnue comme du .jpg.

Remarque 3 à propos de L1.readBuffer(b,sizeof(byte)); : dommage que l'on ne dispose pas du reste du code pour voir comment est déclaré le buffer "b" car ReadBuffer(var Buffer; Count: Longint); cela permet de lire Count octets en rafale sans avoir à passer par une boucle de freinage for i:=1 to n (ça c'est de la lecture besogneuse octet par octet, c'est plus de la lecture de flux).
Il serait souhaitable que la déclaration de b soit var b : array [0..TailleMaxImage] et d'utiliser ensuite pour la lecture octetsLus:=L1.Read(b,SizeOf(b)); où octetsLus est le nombre d'octets réellement lus (cas d'images de taille <=TailleMaxImage).

Remarque 4 à propos de E2.WriteBuffer(b,sizeof(byte)) et de memostream.WriteBuffer(b,sizeof(byte)) : pour transférer ce qui a été lu depuis L1 dans E2 et dans memoryStream tu peux faire directement E2.CopyFrom(L1,octetsLus) et MemoryStream.CopyFrom(L1,octetsLus) où octetsLus est le même que celui de la lecture de la remarque 3.

Remarque 5 à propos de image1.picture.bitmap.assign(pict) et de (Erreur #41) : Essayes avec image1.Picture.Assign(pict) ou image1.Picture.Graphic.Assign(pict) ou encore image1.Picture.Graphic.LoadFromStream(MemoryStream) pour voir ce que ça donne (j'ai davantage l'habitude avec *.bmp) ... mais c'est pas certain que "c'est bien la derniere ligne qui cause l'erreur" comme évoqué plus haut, faut procéder par élimination pour faire le diagnostic.

A+

[130i-24v]

Remarque 2 au sujet de L1.position:=1781904; et de for i:=1 to 169657 : Est-tu certain du 1781904 et du 169657 car il suffit de se tromper d'une unité en plus ou en moins et la partie lue sur disque risque de ne pas être ensuite reconnue comme du .jpg.

Justement dans mon code, quand je lis le fichier (A+B) pour y extraire B , j'écris les données dans un TFilestream (que j'ouvre avec paint) et en même temps dans un TMemorystream, donc je présume vu ce que j'ai mis dans mon code que le contenu devrait être identique dans l'un comme dans l'autre?
En tout cas le fichier jpg que j'extrais sur mon disque est bien un Jpg identique à l'octet près aux fichiers jpg original, et les caractères de départ sont les mêmes...

Remarque 3 à propos de L1.readBuffer(b,sizeof(byte)); : dommage que l'on ne dispose pas du reste du code pour voir comment est déclaré le buffer "b" car ReadBuffer(var Buffer; Count: Longint); cela permet de lire Count octets en rafale sans avoir à passer par une boucle de freinage for i:=1 to n (ça c'est de la lecture besogneuse octet par octet, c'est plus de la lecture de flux).
Il serait souhaitable que la déclaration de b soit var b : array [0..TailleMaxImage] et d'utiliser ensuite pour la lecture octetsLus:=L1.Read(b,SizeOf(b)); où octetsLus est le nombre d'octets réellement lus (cas d'images de taille <=TailleMaxImage).

Effectivement dans mon programme j'ai fais de la lecture octet par octet

Remarque 5 à propos de image1.picture.bitmap.assign(pict) et de (Erreur #41) : Essayes avec image1.Picture.Assign(pict) ou image1.Picture.Graphic.Assign(pict) ou encore image1.Picture.Graphic.LoadFromStream(MemoryStream) pour voir ce que ça donne (j'ai davantage l'habitude avec *.bmp) ... mais c'est pas certain que "c'est bien la derniere ligne qui cause l'erreur" comme évoqué plus haut, faut procéder par élimination pour faire le diagnostic.

A+

Aucune ne marche... j'ai présumé que c'était la derniere ligne car en faisant du pas à pas c'est là que ça "bloquait". Mais effectivement c'est le contenu de memorystream qui est peut etre pas bon, mais je ne vois pas pourquoi. Quoique je mette ça me renvoie toujours l'erreur #41. Merci pour vos réponses très précises en tout cas.

@++
Thierry

Modification:

Je scrute pendant l'execution mon Tmemorystream et mon Tfilestream, et les deux font bien la même taille...et ont apparemment les mêmes octets Ce qui tends bien a dire qu'il n'y a pas d'erreur "d'adressage" quand je pioche dans le fichier contenant (A+B). J'y comprends plus rien...

[Paul TOTH]

il doit manquer un memoStream.Position:=0 avant le LoadFromStream

d'ailleurs je me demande si ceci ne fonctionnerait pas

Code :

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

1
2
3
 
 L1.position:=1781904;
 pict.LoadFromStream(L1);

NB il existe aussi la fonction suivante dans TStream

Code :

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

1
2
 
 function CopyFrom(Source: TStream; Count: Int64): Int64;

[130i-24v]

Merci !

La deuxième solution proposée marche aussi d'ailleurs.

@++
Thierry

[Clorish]

Si je puis me permettre, je te conseille le code suivant :

Cretion du fichier DAT :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
FS := TFileStream(FichierDat, fmCreate);  
MS := TMemoryStream.Create;
FS.Write(FileList.Count, SizeOf(Integer));  // Nombre d'images
For i := 0 to FileList.count-1 do   // FileLsit : TStringList
  Begin
  MS.loadFromFile(FileSist[i]);
  FS.Write(MS.Size, SizeOf(Integer));  // taille du stream a copier
  FS.CopyFrom(MS, MS.Size);
  End;
FS.Free;
MS.Free;

Lecture du stream :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
Type  TIndex = record (StartAdr, Size : Integer);   
Var Indexes : Array of TIndex;
 
FS := TFileStream.Create(MonFichierDat, fmOpenRead);
FS.read(nbPics, SizeOf(Integer));  // Lecture du mnombre d'images
SetLength(Indexes, NbPics);
For i := 0 to NbPics-1 do
  Begin
  MS.Size := 0;
  MS.Position := 0;
  FS.Read(Size, SizeOf(Integer));  // Taille de l'image
  Indexes[i].StartAdr := FS.Position;
  Indexes[i].Size := Size;
  FS.Seek(Size, soFromCurrent);   // a verifier pour "soFromCurrent"
  End;
FS.Free;

LE principe etant de charger en memoire une table d'index permetant de retrouver dans le fichier l'image en question.
Pour la lire, il suffit de faire :

Code :

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

1
2
3
4
5
6
 
MS := TMemoryStream.CReate;
FS.Position := Indexes[PicNum].StartAdr;
MS.CopyFrom(FS, Indexes[PicNum]);
Image1.Picture.LoadFromStream(MS);
MS.Free;

Bien entendu ... il est possible de conserver le fichier FS ouvert tant qu'on en a besoin, ou de l'ouvrir a chaques fois ... au choix.

Pas mal d'autres choses sont envisageable, comme generer et sauvegarder la table d'index directement dans le fichier Dat en entete de fichier et concatener les images derriere. La simple lecture de la table suffira au lieu de la recreer a partir du parcours du fichier.

Il est egalement envisageable de conserver d'autres infos comme nom d'images, etc ... mais aussi crypter les images depuis le MS, avant la copie dans le fichier dat et le decrypter apres chargemetn depusi le fichier dat.

Remarque importante : Ne pas oublier d'inclure l'unitee Jpeg quand on charge un jpg depuis un stream .... sinon on obtient l'erreur #42 de memoire

Pour toutes autres infos, je suis disponible
Je traite actuelent quelque chose de similaire au taff
D'ailleur, faudra peut etre que je post un jour mon unitee de lecture de donnees dans un stream

[Clorish]

J'oubliais .. pour patcher le fichier dat, il suffit d'envoyer un autre "DAT" avec des regles de concatenations ....

On ouvre le fichier Dat a patcher, on copie les blocs images un par un dans un secon fichier dat.
Si l'id est egal a un fichier patché, on copie les données depuis le dat de patch .... sinon on copie le fichier depuis le dat normal.

Je te conseille d'ailleur de rajouter un champs "ID" qui te permetra de retrouver plus facilement tes fichiers sans avoir a te baser sur leur ordre dans le fichier dat ....

Bref la encore pour plus d'infos, me demander, le sujet est vaste