Creation d'images png à partir de std::string

Bonjour

J'utilise la librairie mapnik pour générer des cartes géographiques au format png.

Pour sauvegarder les cartes il existe une méthode
void save_to_file(...)
et une méthode
string save_to_string(...)

La gestion derrière est quasiment là même, les 2 appellent une autre méthode

Code:

---

1 2	template <typename T1, typename T2> void save_as_png(T1 & file , T2 const& image)

---

dans le cas du fichier :

Code:

---

1 2 3 4

std::ofstream file (filename.c_str(), std::ios::out| std::ios::trunc|std::ios::binary); if (file) { save_as_png(file,image);

---

et dans le cas du string:

Code:

---

1 2 3 4 5

std::ostringstream ss(std::ios::out|std::ios::binary); //all this should go into image_writer factory save_as_png(ss,image); ... return ss.str();

---

jusque là tout va bien mais le code suivant me donne une image illisible :

Code:

---

1 2 3 4 5 6 7 8

save_to_file<ImageData32>(buf.data(), file, "png"); std::ofstream fichier("C:\\test.png", std::ios::out | std::ios::trunc); if(fichier) { std::string data = save_to_string<ImageData32>(buf.data(), "png"); fichier << data; fichier.close(); }

---

L'appel "save_to_file" fonctionne très bien mais le fichier rempli par la string récupérée par save_to_string est illisible.
Je ne sais pas à quoi ça peut être dû.

L'idée c'est que j'ai besoin de récupérer le string car je dois l'envoyer en réponse d'une requête http.

Si je compare les tailles des fichiers, il y a une chose étrange:
le fichier lisible :
taille : 374.560 octets
taille sur le disque :376.832 octets
le fichier illisible
taille : 376.075 octets
taille sur le disque :376.832 octets
Soit exactement la même "taille sur le disque" mais pas la même "taille".
Je ne sais pas ce quel est la différence entre ces 2 tailles.

donc voilà je m'en remets à votre savoir :)

Citation:

---

Envoyé par Ghurdyl

L'idée c'est que j'ai besoin de récupérer le string car je dois l'envoyer en réponse d'une requête http.

Si je compare les tailles des fichiers, il y a une chose étrange:
le fichier lisible :
taille : 374.560 octets
taille sur le disque :376.832 octets
le fichier illisible
taille : 376.075 octets
taille sur le disque :376.832 octets
Soit exactement la même "taille sur le disque" mais pas la même "taille".
Je ne sais pas ce quel est la différence entre ces 2 tailles.

donc voilà je m'en remets à votre savoir :)

---

Salut,
1/as-tu regardé s'il y avait des problèmes de type CR/LF ?
2/As-tu fais une comparaison binaire pour voir où se trouve les différences ?
3/Si ton string est considéré comme un buffer, alors pourquoi ne pas passer plutôt par un std::vector ?
4/Si ton string est considéré comme un buffer, alors pourquoi ne pas faire une sauvegarde binaire ?

P.S. : quel sera l'encodage dans l'envoi de la réponse HTTP ?

Bonjour

Code:

---

std::ofstream fichier("C:\\test.png", std::ios::out | std::ios::trunc);

---

Dans les autres exemples il y avait le flag std::ios::binary. Pourquoi pas dans celui-ci ?

D'autre part, si l'API de mapnik fournit une fonction save_to_string, je suppose qu'il doit y avoir aussi une fonction du genre save_to_file(image, const string&) acceptant le genre de string renvoyée par save_to_string, non ?

Pour info,

La taille du fichier est la taille réelle de celui ci
La taille sur le disque est la taille prise par le fichier sur le disque dur et comme on peut pas coupé des "cluster" ( ou un truc du genre ) et bah ça prend toujours un peu plus de place...

Du coup tes fichiers sont bien différent car c'est la taille qui compte, mais comme les fichiers non pas une grandes différences, ils utilisent le même nombre de "cluster"
Juste que le fichier illisible remplie mieux le dernier "cluster"

Tout d'abord, merci pour vos réponses

Citation:

---

Envoyé par 3dArchi

1/as-tu regardé s'il y avait des problèmes de type CR/LF ?
2/As-tu fais une comparaison binaire pour voir où se trouve les différences ?
3/Si ton string est considéré comme un buffer, alors pourquoi ne pas passer plutôt par un std::vector ?
4/Si ton string est considéré comme un buffer, alors pourquoi ne pas faire une sauvegarde binaire ?

---

Pour les CR/LF il y a un problème je pense car, même si ce n'est pas un éditeur binaire, les 2 fichiers ouverts dans le bloc-note affichaient un nombre total de lignes différent.(on voit d'ailleurs un passage à la ligne à la 2em ligne qui n'est pas dans le fichier valide)
Quel outil/méthode puis-je utiliser pour faire une comparaison binaire ?
Un string considéré comme un buffer, je n'en avais jamais entendu parler :aie:
Et la sauvegarde binaire d'un buffer non plus, comment fait-on ?

Citation:

---

Envoyé par 3dArchi

P.S. : quel sera l'encodage dans l'envoi de la réponse HTTP ?

---

La précédente API (AspMap en Asp.Net) transformait un tableau de byte (généré par l'API) en objet System.dawing.Image (C#) qui lui même était retransformé après (je n'ai pas encore étudié comment) pour être envoyé en réponse http.

Citation:

---

Envoyé par Arzar

Dans les autres exemples il y avait le flag std::ios::binary. Pourquoi pas dans celui-ci ?

D'autre part, si l'API de mapnik fournit une fonction save_to_string, je suppose qu'il doit y avoir aussi une fonction du genre save_to_file(image, const string&) acceptant le genre de string renvoyée par save_to_string, non ?

---

Pour le std::ios:binary je n'ai pas essayé, pensais que c'était une propriété du fichier et qu'il n'influencerait pas ma std::string. => Si le fichier est mauvais, ça vient de la string. (raisonnement finalement pas très logique)
Donc par acquis de conscience je vais regarder même si ça ne corrigeras pas mon souci quand je passerai ma string à la partie .Net. (les essais que j'ai déjà effectués se sont révélés infructueux)
[Edit] Vérification faite, à présent le fichier est lisible quand j'ajoute std::ios::binary [/Edit]
Quant à une méthode de mapnik prenant en argument un std::string pour écrire dans un fichier il n'y en a pas.

Et merci pour l'info sur les tailles de fichiers, c'est tout de suite plus clair :)

un petit up du topic car je continuer de buter sur la conversion.

- Ok je peux récupérer mon image sous forme d'un std::string
- Ok je peux l'écrire dans un fichier à condition de l'ouvrir en mode ios::binary

mais visiblement il doit y avoir une forme d'altération quand je converti la std::string en System::String^ (mon but n'étant pas de l'écrire sur le disque mais de l'utiliser dans mon application .Net)

une fois dans C# j'ai trouvé comment convertir un System.String base 64 en un objet System.drawing.Image mais c'est au moment de l'appel de la fonction
byte[] imageBytes = Convert.FromBase64String(base64String);
que le programme m'envoie une FormatException en me disant qu'il y a des caractère non valide dans ma chaine base 64.

je cherche donc à convertir ma chaine en base 64 dans le C++ avant de la convertir en System::String^

Citation:

---

Envoyé par Ghurdyl

le programme m'envoie une FormatException en me disant qu'il y a des caractère non valide dans ma chaine base 64.

---

Fait un dump de ta string vers un fichier texte et ouvre le pour voir s'il est conforme à l'encodage base 64. Ca te permettra de mieux isoler le responsable du problème.

Pourquoi faut-il passer par des String^ ?
Si j'ai bien compris, il semble que System.Drawing.Image soit construite à partir d'un byte[]. Donc ce serait plus simple de copier directement la std::string dans un byte[], non ?

(C'est une question naive, je ne connais pas du tout le C++/CLI)

merci pour vos réponses.

pour dump, je ne sais pas ce que c'est, je vais chercher.

Pour le tableau de byte, oui le constructeur peut prendre un tableau de byte.
Mes premiers essais sur cette voie on été peu concluant mais je vais ré-essayer.

Je verrai ça à mon retour de vacance dans une semaine :P

Citation:

---

Envoyé par Ghurdyl

pour dump, je ne sais pas ce que c'est, je vais chercher.

---

dump -> il s'agit juste d'écrire le contenu de ta chaîne dans un fichier pour voir son contenu plus facilement qu'avec un debugger.

Bonjour,
de retour de vacance, je ré-attaque le problème.

J'ai trouvé que dans ma conversion de std::string vers System::String^ je fais appel à la méthode std::string::data().

Code:

---

1 2	std::string img = createImage(); System::String^ res = gcnew System::String(img.data());

---

Cette méthode data() a le gros défaut de retourner un unsigned char* jusqu'au premier '\0' rencontré or dans ma "std::string img" il y en a et vu que c'est une image, ce sont des bytes à ne pas ignorer.

Comment donc puis-je contourner les méthodes data() ou c_str() (même effet à un caractère de fin de chaine près) pour créer une System::String^ à partir d'une std::string.
J'ai bien envisagé une boucle caractère par caractère de ma std::string mais ça me semble pas terrible point de vue optimisation non ?

du coté de la solution tableau de byte, je n'ai pas encore trouvé le moyen de convertir un std::string en BYTE* (unsigned char *) et puis restera à convertir un BYTE* en tableau managé de System::byte^

C'est vraiment une drôle d'idée que d'utiliser un std::string pour stocker une image.

Quand tu vas chez le boulanger, tu lui demande de la viande ?

Entièrement d'accord avec toi, mais c'est mapnik qui veut ça et j'aimerais dans la mesure du possible l'utiliser tel quel plutôt que de le modifier, mon expérience en C++ étant très largement inférieure à celle de son créateur.

Si non je pense que ma seule option viable c'est bien de passer par le tableau de byte car outre les '\0' qui perturbent les méthodes habituelles de manipulation de strings, les autres bytes de la chaines sont des unsigned char et non de simples char d'où impossibilité d'utiliser les méthodes "traditionnelles" à priori.

Je m'avance peut-être car à nouveau je suis novice :aie:

Edit :

Donc via un tableau de byte managé j'ai réussi :mrgreen:
voici comment je convertis :

Code:

---

1 2 3 4 5 6 7 8 9 10

{ std::string img = _map_F->finalize();   List<Byte>^ listByte = gcnew List<Byte>();   for(int i=0 ; i<img.size() ; i++) listByte->Add((unsigned char)img[i]);   return listByte; }

---

Ensuite dans le code C# je transforme le tableau de Byte en Image :

Code:

---

1 2 3 4 5 6

List<Byte> lb = map.finalize("png", _top, _left, _bottom, _right); byte[] imgByte = lb.ToArray(); MemoryStream ms = new MemoryStream(imgByte, 0, imgByte.Length);   // Convert byte[] to Image Image image = Image.FromStream(ms, true);

---

Citation:

---

List<Byte>^

---

Si l'objet List se comporte comme une std::list du C++, c'est à dire une liste chainée, alors tu vas détruire les perfos ! (allocation d'un nœud pour chaque pixel de l'image !)

J'insiste, mais pourquoi ne pas copier directement la std::string dans un byte[] ? :koi: (qui semble être en C++/Cli un array<Byte>^)

Edit : Apparemment, en C#, les List<> sont des versions "génériques" des ArrayList qui sont... des tableaux dynamiques. 8O
Je vois pas comment faire plus confus sérieusement.

Bonjour,

Je ré-ouvre mon topic car au fil des développement j'en suis arrivé à devoir écrire mon "image" toujours un std::string sur la sortie standard (std::cout)

Seulement voilà, cout est par défaut en mode texte et il me pourri les bytes que je lui envoie.

J'ai essayé d'imprimer caractère par caractère avec un vieux printf et tout les formats qui vont avec mais j'arrive au même résultat qu'avant.
Je pense que je dois configurer cout en mode binaire mais les solutions de l'ami google sont lacunaires ...

Si je redirige cout comme suit, le résultat dans le fichier est correcte

Code:

---

1 2 3 4 5

string s_img = MR.save_to_srting(); std::ofstream Out("map2.png", std::ios::out | std::ios::binary); std::streambuf* OldBuf = std::cout.rdbuf(Out.rdbuf()); cout.write(s_img.data(), s_img.size()); std::cout.rdbuf(OldBuf);

---

(notez le std::ios::binary)

mais ça ne m'arrange pas.
L'application que je crée en C# va appeler l'autre application C++ et lis le résultat (l'image) sur cout seulement pour le moment elle est altérée ...

Une fois de plus je me tourne vers votre science :)

j'avance à petits pas :

En entrée du programme C++ qui crée l'image je mets :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

#include <io.h> // _setmode #include <fcntl.h> // _O_BINARY //... int main(int argc, char** argv) { _setmode( _fileno( stdout ), _O_BINARY ); ... string s_img = MR.save_to_string(); cout.write(s_img.data(), s_img.size()); cout.flush(); return 0; }

---

Il semblerait que ça ne fonctionne que sous Windows mais ce n'est pas un souci.

Ensuite, dans le programme C# appelant le processus :

Code:

---

1 2 3 4 5 6

System.Diagnostics.Process proc = new System.Diagnostics.Process(); // On désactive le shell proc.StartInfo.UseShellExecute = false; // On redirige la sortie standard proc.StartInfo.RedirectStandardOutput = true; proc.StartInfo.StandardOutputEncoding = System.Text.Encoding.UTF7;

---

là, j'obtiens une image "correcte" dans le sens où elle est interprétable en temps qu'image mais au lieu d'avoir une belle tuille de 2000x2000 j'ai un machin racrapoté de 2000x32 (les propriétés de l'image annonçant bien 2000x2000)

En comparant les fichiers (l'image correcte et la nouvelle) dans NotePad ++, je constate la présence de caractères "+" c'est semble-t-il la seule différence.
Le nombre de byte étant le même je ne sais pas trop vers où me tourner, est-ce l'image qui est mal sortie ou mal lue ... :?

Dans la découverte des codages, je pense avoir trouvé la cause de ces '+'

Visiblement, une partie des bytes codé en UTF-7 sont codés en base 64 avec un caractère d'échappement '+' au début de la séquence.

Si tel est bien le cas, il faut que je trouve le moyen d'encoder proprement l'image png en un byte array en reconvertissant les séquences en base 64 en base ... euh ... :aie:

La persévérance, ça paye et comme vu dans la signature de je ne sais plus quel illustre membre de ce forum : "la solution la plus simple est toujours la moins compliquée"
(ou quelque chose dans ce goût là)

bref,

pour récupéré mon image via stdout dans l'application C# il y a 2 choses à faire :
- définir stdout en binaire comme je l'expliquais plus tôt avec le _setmode()
- rediriger stdout
- récupérer l'image comme suit dans le C# :

Code:

---

1 2 3 4

System.Diagnostics.Process proc = new System.Diagnostics.Process(); proc.StartInfo.RedirectStandardOutput = true; proc.Start(); Image image = Image.FromStream(proc.StandardOutput.BaseStream);

---

Mes problèmes venaient de la façon dont je récupérais l'image sur stdout ...:roll: