Données EXIF semble-t-il effacées au chargement par bigup #4878

Ne comprenant pas pourquoi des points géolocalisés n'étaient pas créés par GIS lors de l'upload de photos qui contenaient des données GPS j'ai constaté qu'une image téléversée avec ces données était stockée dans le site sans aucune donnée EXIF.
(constaté en téléchargeant cette image depuis SPIP)

SPIP 4.2.2 PHP 8.2.4

Ne comprenant pas pourquoi des points géolocalisés n'étaient pas créés par GIS lors de l'upload de photos qui contenaient des données GPS j'ai constaté qu'une image téléversée avec ces données était stockée dans le site sans aucune donnée EXIF. (constaté en téléchargeant cette image depuis SPIP) SPIP 4.2.2 PHP 8.2.4

Idem en SPIP-dev
https://rumeur.jack31.org/donnees-exif-dans-image

Une image chargée en FTP, données EXIF OK, et la même image traitée par SPIP

Idem en SPIP-dev https://rumeur.jack31.org/donnees-exif-dans-image Une image chargée en FTP, données EXIF OK, et la même image traitée par SPIP

Un rapport avec #4538 ?

C'est l'option de retaillage coté client qui fait perdre les données EXIF.

Un rapport avec #4538 ?

Apparemment oui, mais ça ne m'a pas sauté aux yeux comme la notion d'EXIF n'est pas dans le titre...
En tout cas c'est dommage que je n'ai pas fait attention à ce souci lors de mes tests de bigup (si c'est bien introduit par le retaillage, c'est un bug très gênant.

> Un rapport avec #4538 ? Apparemment oui, mais ça ne m'a pas sauté aux yeux comme la notion d'EXIF n'est pas dans le titre... En tout cas c'est dommage que je n'ai pas fait attention à ce souci lors de mes tests de bigup (si c'est bien introduit par le retaillage, c'est un bug très gênant.

A priori la lib utilisée était https://github.com/blueimp/JavaScript-Load-Image

C’était pas censé conserver les metadata ?

A priori la lib utilisée était https://github.com/blueimp/JavaScript-Load-Image C’était pas censé conserver les metadata ?

Ah bé c'est balot, ça va pas du tout comme régression :(

Faut faire un ticket dans la lib JS ?

Et si la lib JS ne peut pas être corrigée, alors il faudrait aspirer les EXIF en amont (en JS donc forcément), les stocker, passer l'image dans la lib de retaillage, et remettre les EXIF après ?

Ah bé c'est balot, ça va pas du tout comme régression :( Faut faire un ticket dans la lib JS ? Et si la lib JS ne peut pas être corrigée, alors il faudrait aspirer les EXIF en amont (en JS donc forcément), les stocker, passer l'image dans la lib de retaillage, et remettre les EXIF après ?

Si c'est bien la librairie donnée par marcimat il semble qu'il faille activer une extension Exif parser :
https://github.com/blueimp/JavaScript-Load-Image#exif-parser

Peut-être s'agit-il de ce js https://github.com/blueimp/JavaScript-Load-Image/blob/master/js/load-image-exif.js ?

Si c'est bien la librairie donnée par marcimat il semble qu'il faille activer une extension Exif parser : https://github.com/blueimp/JavaScript-Load-Image#exif-parser Peut-être s'agit-il de ce js https://github.com/blueimp/JavaScript-Load-Image/blob/master/js/load-image-exif.js ?

le problème n'est pas la lib load image, les EXIF existent toujours mais la fonction toblob pour transformer canvas en image.
Je suis entrain de regarder pour les réimporter

le problème n'est pas la lib load image, les EXIF existent toujours mais la fonction toblob pour transformer canvas en image. Je suis entrain de regarder pour les réimporter

@Jack31 pourrais tu essayer la branche issue_4878.
Chez moi, je récupère bien maintenant l'EXIF

@Jack31 pourrais tu essayer la branche issue_4878. Chez moi, je récupère bien maintenant l'EXIF

Il reste une question, et comme je n'y connais pas grand chose en EXIF, la voici.

dans la partie : structure Exif :
Pixel X Dimension et Pixel Y Dimension ont les valeurs de l'image de départ.

Est ce qu'il faut laisser comme ça, pour connaître les valeurs de l'image de départ, ou faut il essayé de les réécrire ?

Est ce des valeurs purement informatives ?

Il reste une question, et comme je n'y connais pas grand chose en EXIF, la voici. dans la partie : **structure Exif** : **Pixel X Dimension** et **Pixel Y Dimension** ont les valeurs de l'image de départ. Est ce qu'il faut laisser comme ça, pour connaître les valeurs de l'image de départ, ou faut il essayé de les réécrire ? Est ce des valeurs purement informatives ?

J'ai essayé sur mon site de test en 5-dev (lien plus haut) et ça fonctionne.
Merci pour cette correction hyper-rapide !

Demain j'essaierai en "prod"sur mon site velovacances :-)

Perso je laisserais les dimensions d'origine telles qu'elles sont. Il me semble que c'est comme Date time qui est la date de la prise de vue, informatif...

J'ai essayé sur mon site de test en 5-dev (lien plus haut) et ça fonctionne. Merci pour cette correction hyper-rapide ! Demain j'essaierai en "prod"sur mon site velovacances :-) Perso je laisserais les dimensions d'origine telles qu'elles sont. Il me semble que c'est comme Date time qui est la date de la prise de vue, informatif...

Alors je voulais approuver la PR mais je n'ai pas vu comment.
En tout cas ça marche nickel chez moi, et en plus aujourd'hui j'ai une connexion faiblarde.
J'ai retrouvé mes photos géolocalisées, et du coup aussi ma trace qui en dépend :-)

Grazie mille!

Alors je voulais approuver la PR mais je n'ai pas vu comment. En tout cas ça marche nickel chez moi, et en plus aujourd'hui j'ai une connexion faiblarde. J'ai retrouvé mes photos géolocalisées, et du coup aussi ma trace qui en dépend :-) Grazie mille!

Alors je voulais approuver la PR mais je n'ai pas vu comment.

oui : la PR n'existait pas encore :-)

Maintenant que c'est fait c'est là que ça se passe : #4880/files

> Alors je voulais approuver la PR mais je n'ai pas vu comment. oui : la PR n'existait pas encore :-) Maintenant que c'est fait c'est là que ça se passe : https://git.spip.net/spip/bigup/pulls/4880/files

C’est corrigé (master et branche 3.2). J’ai publié une version 3.2.3 pour SPIP 4.2 dans la foulée.

Merci @tofulm !

Alors désolé mais chez moi :

le code actuel ne fonctionne pas
la première proposition de code que j'avais testée fonctionnait sans le if incluant

{
			loadImage.replaceHead(blob, data.imageHead, function (newBlob) {
				return resolve(newBlob);
			})

et donc, toujours chez moi, lorsque ça fonctionne les images sont stockées toutes en largeur sans tenir compte du positionnement. voir mediabox#4877

Alors désolé mais chez moi : - le code actuel ne fonctionne pas - la première proposition de code que j'avais testée fonctionnait sans le if incluant ``` { loadImage.replaceHead(blob, data.imageHead, function (newBlob) { return resolve(newBlob); }) ``` - et donc, toujours chez moi, lorsque ça fonctionne les images sont stockées toutes en largeur sans tenir compte du positionnement. voir mediabox#4877

@Jack31 c'est corrigé, pourrais tu confirmer ?

Quand j'avais fait du ménage avant la PR, j'avais effacé la commande qui permettait de générer les metas

@Jack31 c'est corrigé, pourrais tu confirmer ? Quand j'avais fait du ménage avant la PR, j'avais effacé la commande qui permettait de générer les metas

Oui j'ai remplacé javascript/bigup.js par le nouveau fichier sur mon site de test (en 4.2.2) et les données EXIF sont maintenant bien présentes.

Par contre on voit maintenant le souci de positionnement portrait/paysage : à voir sur la dernière image (la fresque murale) de https://blabla.jack31.org/article27.html

Oui j'ai remplacé javascript/bigup.js par le nouveau fichier sur mon site de test (en 4.2.2) et les données EXIF sont maintenant bien présentes. Par contre on voit maintenant le souci de positionnement portrait/paysage : à voir sur la dernière image (la fresque murale) de https://blabla.jack31.org/article27.html

@Jack31 si tu supprimes le retaillage, est ce que tu as aussi le problème d'orientation portrait / paysage ?

@tofulm

Alors j'ai enlevé le retaillage (blanchi les zones de configuration avec les dimensions) et le résultat est rigolo : c'est maintenant la vignette qui est de travers et pas l'image elle même (dernière image, escalier, dans l'article cité au dessus)

Mais sur les essais faits alors que le EXIF n'était pas pris en compte l'image était OK en vignette ou en normal. voir sur la même page la tour ou l'épouvantail.

@tofulm Alors j'ai enlevé le retaillage (blanchi les zones de configuration avec les dimensions) et le résultat est rigolo : c'est maintenant la vignette qui est de travers et pas l'image elle même (dernière image, escalier, dans l'article cité au dessus) Mais sur les essais faits alors que le EXIF n'était pas pris en compte l'image était OK en vignette ou en normal. voir sur la même page la tour ou l'épouvantail.

tu utilises quoi comme moteur de génération des vignettes ?

GD2
imagick
???

tu utilises quoi comme moteur de génération des vignettes ? - GD2 - imagick - ???

J'utilise GD2

Je peux faire des essais avec CONVERT ou NETPBM (mais CONVERT n'avait rien changé par rapport à GD2 l'autre jour)

J'utilise GD2 Je peux faire des essais avec CONVERT ou NETPBM (mais CONVERT n'avait rien changé par rapport à GD2 l'autre jour)

Ne trouvant pas comment faire respecter les exifs de rotation à travers les différentes opérations sur les images, j'ai ajouté un petit bouton sur les vignettes pour les tourner en un clic de 90 ou 180° (sans devoir appeler tout le formulaire d'édition) et les redresser. Évidemment ça perd les autres EXIFs. (Et c'est pas dans /ecrire)

On peut fermer maintenant ?

Labels Milestones

Données EXIF semble-t-il effacées au chargement par bigup #4878