Image jpeg : buffer -> file

Version imprimable

04/06/2008, 14h16
sagopa

Image jpeg : buffer -> file

Bonjour,

Voici mon problème :

Je récupère dans un buffer une image jpeg à partir d'une caméra IP.
Je connais donc la taille du buffer.

Ensuite je copie l'image sur le disque avec fwrite.

Sur linux, je peux visualiser l'image copiée ; cepedant sur windows ce n'est pas le cas. Lorsque je l'ouvre avec gimp par exemple j'ai le mesage suivant :
"Corrupt JPEG data: premature end of data segment"

Je me demande si le problème vient des différences entre linux et windows concernant les fins de ligne.
04/06/2008, 14h26
Invité(e)

Bonjour,

A propos des fin de ligne, il y a effectivement des diffférence entre linux et windows. LEs fichiers sont ils ouvert en mode texte ou binaire ?

De plus, les images générées sur linux sont elles visualisables sur windows (et inversement) ?
04/06/2008, 14h50
ram-0000

Citation:

Envoyé par mabu

A propos des fin de ligne, il y a effectivement des diffférence entre linux et windows.

Oui mais cela ne concerne que les fichiers textes. Je ne pense pas qu'un fichier jpg entre dans cette actégorie:?

Une autre possibilité est que le fichier jpg soit légèrement invalide/corrompu/non conforme, et que gimp sous linux sait le gérer alors que sous windows, il n'y arrive pas.

Tu as essayé avec d'autre visualiseur d'e fichiers ?
04/06/2008, 14h53
JeromeBcx

Bonjour,

Quel est le format image du fichier ?
Tout dépends des besoins, mais l'utilisation d'une librairie image fournissant des fonctions d'export vers les formats courants (Bitmap, jpeg, tiff, ...) ne vous faciliterait pas la vie ?
04/06/2008, 15h18
sagopa

Tout d'abord je vous remercie pour votre aide.

Les fichiers sont ouverts en mode binaire : fopen(file.c_str(), "wb")

Les images créées sur linux sont également visualisables sur windows.

Les images sont au format jpeg.
04/06/2008, 15h34
sagopa

Autre remarque :
Les images crées sur windows ne sont pas visualisables sur linux.
Donc je ne pense pas que gimp corrige le fichier.

Le problème viendrait donc lors de l'écriture du fichier jpeg sur windows.

J'ai trouvé une lib (FreeImage) qui permet d'enregistrer dans un fichier en bmp, à partir de mon buffer jpeg.
Evidemment ça marche sur linux, mais pas sur windows.
Mais dans ce cas, peut-être que le problème vient du fait que la dll est compilée avec MVSC alors que moi j'utilise le compilateur mingw. ( j'ai du pour cela modifier légèrement le fichier .h de la lib)
04/06/2008, 15h42
JeromeBcx

Citation:

Envoyé par sagopa

Les fichiers sont ouverts en mode binaire : fopen(file.c_str(), "wb")

Il ne devrait pas avoir de problème dans ce cas entre windows et linux si mes souvenirs sont bon.

Citation:

Envoyé par sagopa

Sur linux, je peux visualiser l'image copiée ; cepedant sur windows ce n'est pas le cas. Lorsque je l'ouvre avec gimp par exemple j'ai le mesage suivant :
"Corrupt JPEG data: premature end of data segment"

... et ...

Citation:

Envoyé par sagopa

Les images créées sur linux sont également visualisables sur windows.

8O :koi:

Citation:

Envoyé par sagopa

Les images sont au format jpeg.

Est-ce que la fonction qui transforme le buffer en jpeg et OK ? Peut être que le standard n'est pas tout à fait respecté ? La caméra IP fournit peut être une image type "jpeg" (algo DCT, ....) mais il manque peut être des infos pour que linux puisse lire les données.
Comment est transférer l'image de la caméra à votre logiciel ?
04/06/2008, 15h46
JeromeBcx

Citation:

Envoyé par sagopa

Autre remarque :
Evidemment ça marche sur linux, mais pas sur windows.
Mais dans ce cas, peut-être que le problème vient du fait que la dll est compilée avec MVSC alors que moi j'utilise le compilateur mingw. ( j'ai du pour cela modifier légèrement le fichier .h de la lib)

Euh, effectivement, ce n'est pas franchement recommandé de croiser les compilateurs. En quoi avez vous modifié le fichier .h ?

J'ai l'impression que je me suis mal fait comprendre.

Alors je récapitule.
Les images crées sur linux sont visualisables sur linux et sur windows.
Celles crées sur windows ne sont visualisables ni sur linux ni sur windows.

Je n'ai pas de fonction pour transformer le buffer en jpeg. En faite, j'envoie une requête http à la caméra en utilisant les sockets (send). Cette caméra me renvoie alors une image jpeg avec une entete http (receive). Ensuite je sépare l'entete http et l'image jpeg.

Concernant la lib FreeImage, j'ai du mettre en commentaires quelques redéfinitions :
Code:

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 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 typedef int32_t BOOL; typedef uint8_t BYTE; typedef uint16_t WORD; typedef uint32_t DWORD; typedef int32_t LONG; typedef struct tagRGBQUAD { #if FREEIMAGE_COLORORDER == FREEIMAGE_COLORORDER_BGR BYTE rgbBlue; BYTE rgbGreen; BYTE rgbRed; #else BYTE rgbRed; BYTE rgbGreen; BYTE rgbBlue; #endif // FREEIMAGE_COLORORDER BYTE rgbReserved; } RGBQUAD; typedef struct tagRGBTRIPLE { #if FREEIMAGE_COLORORDER == FREEIMAGE_COLORORDER_BGR BYTE rgbtBlue; BYTE rgbtGreen; BYTE rgbtRed; #else BYTE rgbtRed; BYTE rgbtGreen; BYTE rgbtBlue; #endif // FREEIMAGE_COLORORDER } RGBTRIPLE; typedef struct tagBITMAPINFOHEADER{ DWORD biSize; LONG biWidth; LONG biHeight; WORD biPlanes; WORD biBitCount; DWORD biCompression; DWORD biSizeImage; LONG biXPelsPerMeter; LONG biYPelsPerMeter; DWORD biClrUsed; DWORD biClrImportant; } BITMAPINFOHEADER, *PBITMAPINFOHEADER; typedef struct tagBITMAPINFO { BITMAPINFOHEADER bmiHeader; RGBQUAD bmiColors[1]; } BITMAPINFO, *PBITMAPINFO;
Mais j'utilise cette lib pour la conversion jpeg -> bmp et écriture de l'image bmp sur le disque.
Pour écrire l'image jpeg, j'utilise les fonctions fopen et fwrite

04/06/2008, 16h42
JeromeBcx
Citation:

Envoyé par sagopa

J'ai l'impression que je me suis mal fait comprendre.

J'ai effectivement mal compris (Après lecture plus attentive, c'est un peu plus clair...).

Très schématiquement, la caméra envoi une page du style :
Code:

1 2 3 4 5 6 7 <html> < des infos divers .../> <image>DU_CODE_BINAIRE_QUI_REPRESENTE_UN_FICHIER_JPEG</image> </html>
Vous récupérer ce code que vous copier dans un fichier monfichier.jpg ?
Si je me suis encore trompé, :dehors: :zzz:

Oui c'est à peu près ça.

Je reçois par exemple :
Code:

1 2 3 4 5 6 7 8 9 10 HTTP/1.0 200 OK Cache-Control: no-cache Pragma: no-cache Expires: Thu, 01 Dec 1994 16:00:00 GMT Connection: close Content-Type: image/jpeg Content-Length: 50098 DONNES DE L'IMAGE JPEG AVEC HEADER JPEG de taille 50098 bytes...
Je reçois les données ci-dessus dans un buffer (uint8_t * dataRcv)

Evidemment, avant d'écrire dans un fichier j'enlève la partie concernant le header http (grâce au 2 sauts de ligne), pour n'avoir que les données concernant l'image jpeg.

j'ai donc un buffer qui ne contient que l'image (uint8_t * image)

04/06/2008, 17h09
JeromeBcx

La caméra fonctionnant surement sur un dérivé UNIX ou linux, n'y a t'il pas dans les données binaires du fichier html un retour à la ligne qui perturberai le bazard sous Windows ???

Après réception des données de la caméra j'ai écris ces données dans un fichier texte. J'ai une différence entre linux et windows.

LINUX:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
HTTP/1.0 200 OK
Cache-Control: no-cache
Pragma: no-cache
Expires: Thu, 01 Dec 1994 16:00:00 GMT
Connection: close
Content-Type: multipart/x-mixed-replace; boundary=--myboundary
 
--myboundary
Content-Type: image/jpeg
Content-Length: 50328
 
ÿØÿà...

WINDOWS:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
HTTP/1.0 200 OK
 
Cache-Control: no-cache
 
Pragma: no-cache
 
Expires: Thu, 01 Dec 1994 16:00:00 GMT
 
Connection: close
 
Content-Type: image/jpeg
 
Content-Length: 50098
 
 
 
ÿØÿà...

04/06/2008, 17h46
JeromeBcx

Je ne pense que la différence d'entête joue, par contre, si il y a une différence de structure dans les datas, là il peut avoir un problème.
L'idéal serait une comparaison byte à byte des datas, mais pour cela, il faudrait la même image, et je ne pense pas que ce soit possible (? A moins de figer l'image stockée sur la caméra ?)
04/06/2008, 17h56
sagopa

Oui tu as raison mais il n'est pas possible d'avoir la même image ...
04/06/2008, 18h10
Invité(e)

Citation:

Envoyé par sagopa

Oui tu as raison mais il n'est pas possible d'avoir la même image ...

As tu acces à la caméra ?
Est il possible de la sur-exposer, ou de jouer sur son gain pour avoir une image uniformement blanche ? (saturation)

Si tu as deux images saturées, il est tout à fait concevable quelles soient identiques.
05/06/2008, 01h01
nicroman

Faut arrêter....
Une requete HTTP est une requete HTTP... si c'est la même requête qui est envoyée au même serveur, c'est la même réponse qui est reçu (en tout cas dans le forme), le serveur étant incapable de detecter si cela vient de Windows ou de Linux ou d'un Sun-Spark ! Hors là ce n'est pas le cas....

J'aimerai bien jeter un oeil au code de la query HTTP (en particulier les 'accept' qui sont passés) et du décryptage de la réponse.... (avec écriture dans le fichier texte)

Juste histoire de voir plus clair dans cette partie...

Pour le contenu de l'image JPEG... dans tous les cas c'est du binaire, et ca ne devrait poser aucun problême

Je ne sais pas s'il est possible d'avoir des images saturées ; je vais me renseigner.

Voici la requete envoyée à la camera:

Code:

1
2
3
GET /axis-cgi/jpg/image.cgi?resolution=640x480 HTTP/1.1
Host: 172.23.7.28
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*

Maintenant je vais essayer de détailler un peu plus la séparation header http et données binaires de l'image:

Code:

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
33
34
35
36
37
38
39
40
41
 
//J'envoie la requete avec sa taille en octets
Send(requete, taille requete);
//Je recupère tout d'abord 1024 octets de la socket
//1024 est choisi arbitrairement, mais suffisamment grand pour avoir le header http en entier
Receive(dataRcv, 1024)
//Recherche une occurence de "Content-Length: "
uint8_t* content = (uint8_t *) strstr((char*) dataRcv, "Content-Length: ");
//Recherche de la fin du header http
uint8_t* endHeader = (uint8_t *) strstr((char*) content , "\r\n\r\n");
*endHeader = 0x00;
//Recupere la valeur de "Content-Length: ", cad la taille de l'image, dans imageSize
sizeLength = STRLEN(content +16);
length = (uint8_t *) MALLOC( sizeof(uint8_t) * sizeLength + 1 );
memcpy(length, content+16, sizeLength);
length[sizeLength] = 0;
imageSize = atoi((char*) length);
free(length);
//Allocation memoire pour le buffer qui va contenir l'image
uint8_t* downloadedImage = (uint8_t*) malloc( imageSize );
//On Recupere la taille du header 
sizeHeader = STRLEN(dataRcv) + 4;
//Je copie la premiere partie de l'image, recuperée avec le header http, dans le buffer
memcpy(downloadedImage, endHeader+4, 1024 - sizeHeader);
//On definit la nouvelle taille (en octects tjs) à recevoir 
sizeDataRcv = imageSize  - (PACKET_SIZE - sizeHeader);
free(dataRcv);
//On récupère la dernière partie de la réponse http qui correspond à la dernière partie de l'image
Receive(dataRcv,sizeDataRcv );
//Je copie la dernière partie dans le buffer
memcpy(downloadedImage+(1024-sizeHeader), dataRcv, sizeDataRcv);
free(dataRcv);
//Enfin je copie l'image sur le disque pour vérifier si l'image a été récuperée correctement ou non
FILE * bulk;
if ( ( bulk = fopen("image.jpg", "wb") ) == NULL ) 
  cout << "Can't open file to write image.jpg" << endl;
else
{
  fwrite(downloadedImage, 1 , imageSize , bulk);
  fclose(bulk);
}

J'espère que c'est assez clair...
Merci.

05/06/2008, 09h39
JeromeBcx

Citation:

Envoyé par nicroman

Faut arrêter....
Une requete HTTP est une requete HTTP... si c'est la même requête qui est envoyée au même serveur, c'est la même réponse qui est reçu (en tout cas dans le forme), le serveur étant incapable de detecter si cela vient de Windows ou de Linux ou d'un Sun-Spark ! Hors là ce n'est pas le cas....

Je suis partiellement d'accord, tout dépend le protocole caméra / PC qui pourrait varier suivant que coté PC, les fonctions sont du type WIN32 ou Linux

Citation:

Envoyé par nicroman

J'aimerai bien jeter un oeil au code de la query HTTP (en particulier les 'accept' qui sont passés) et du décryptage de la réponse.... (avec écriture dans le fichier texte)

Juste histoire de voir plus clair dans cette partie...

Ca ferait avancer le problème...

Citation:

Envoyé par nicroman

Pour le contenu de l'image JPEG... dans tous les cas c'est du binaire, et ca ne devrait poser aucun problême

Oui le binaire, c'est le binaire. Mais comme dans le premier cas, la caméra pourrait se comporter différemment dans le formattage de ces données suivant les informations envoyée par le client.
Deuxièmement, si dans le fichier HTML, il y des retour à la ligne ou autre (qui dépendent de l'os) cela peut expliquer le problème.
Enfin, attention à la manière de lire le binaire (Big endian / little endian) ...

Les raisons peuvent vraiment être variée.

Je pense qu'une lecture attentive de la doc caméra devrait peut être aider (lire les petits * ou 1 2... en bas de page)

Enfin pour l'idée d'une image blanche (ou noir d'ailleurs qui serait plus simple à obtenir), je ne suis pas sùr qu'on obtienne exactement le même code binaire du fichier JPEG, mais bon à essayer.
06/06/2008, 11h06
sagopa

Problème résolu

J'ai enfin trouvé le problème:

En faite lorsque je faisais un receive pour lire les données de l'image de la socket, sur windows il n'est pas possible de lire tout l'image en entier, certainement du à une taille de buffer des sockets trop petite par rapport à la taille d'une image jpeg. Donc tant que je n'ai pas lu l'image en entier je fais de nouveau un receive pour avoir l'image en entier.

Merci encore à tous.
06/06/2008, 18h19
nicroman

Citation:

Envoyé par JeromeBcx

Je suis partiellement d'accord, tout dépend le protocole caméra / PC qui pourrait varier suivant que coté PC, les fonctions sont du type WIN32 ou Linux

Ben oui... mais le protocole, on le connait: HTTP... le serveur ne changeant pas, les protocole de communication non plus, la seule différence peut venir du client...

Citation:

Deuxièmement, si dans le fichier HTML, il y des retour à la ligne ou autre (qui dépendent de l'os) cela peut expliquer le problème.
Enfin, attention à la manière de lire le binaire (Big endian / little endian) ...

Ben non... une image jpeg, c'est une image jpeg, quel que soit l'OS ou le byte-ordering.
Et les headers HTTP sont écrits en toute-lettre...

Dans tous les cas... pour revenir au problême initial... il y a déjà un problême coté implémentation HTTP:
En HTTP/1.0 rien ne force le serveur à envoyer un content-length. HTTP/1.0 est censé fermer la connection une fois le fichier envoyé...
D'autre part... même en HTTP/1.1... le content-length peut ne pas exister si les données sont en "BULK"...
06/06/2008, 18h44
JeromeBcx

Citation:

Envoyé par nicroman

Ben oui... mais le protocole, on le connait: HTTP... le serveur ne changeant pas, les protocole de communication non plus, la seule différence peut venir du client...

Justement, je me disais que les procédures d'acquisition coté client pouvant changer, cela pouvant générer le problème.

Citation:

Envoyé par nicroman

Ben non... une image jpeg, c'est une image jpeg, quel que soit l'OS ou le byte-ordering.
Et les headers HTTP sont écrits en toute-lettre...

Pour les headers OK.
et pour le byte-ordering, :dehors: désolé...une mauvaise idée qui m'a traversé.
pour les retours de ligne par contre, c'était possible...