[spip-dev] Données Exif des images réduites

Dev
#1

J'ai l'impression que le filtre image_reduire ne tient pas compte des données exif des photos,
et ne fournit aucune exif au fichier de l'image-réduite.

Du coup, des photos prises en penchant l'appareil photo, qui ont donc une exif de rotation qui leur permet d'apparaître partout à l'endroit car les lieux communs de visualisation d'une image tiennent compte des données exifs de rotation
apparaissent tournées une fois réduites

Je m'étonne d'avoir mis si longtemps à m'en apercevoir.
(n'avez vous pas constaté ça aussi ?)

Et du coup comment faire pour avoir des vignettes toujours à l'endroit ?

JL

#2

J'avais commencé à voir pour faire un filtre exif, sur les images pour le plugin html5up_lens, mais après un petit moment, j'ai fait le constat que ce devait être à l'utilisateur de modifier l'image avant de la placer sur le site.

Cependant, mon problème était à la base, pour des images de type "dessin d'art", ce n'était pas des photos.

Je crois avoir gardé le code du filtre si tu veux.

RS.

17 juillet 2020 15:49 "JLuc" <jluc@no-log.org> a écrit:

#3

J'avais commencé à voir pour faire un filtre exif, sur les images pour le plugin html5up_lens, mais après un petit moment, j'ai fait le constat que ce devait être à l'utilisateur de modifier l'image avant de la placer sur le site.
Cependant, mon problème était à la base, pour des images de type "dessin d'art", ce n'était pas des photos.
Je crois avoir gardé le code du filtre si tu veux.

Merci de proposer ton aide.
Il y a plusieurs plugins déjà qui interrogent et présentent les exif :
https://contrib.spip.net/Metadonnees-Photo est le plus récent je crois
https://contrib.spip.net/Balise-EXIF-recuperer-les le plus ancien, mais le code central doit être encore bon
et https://contrib.spip.net/Afficher-les-donnees-EXIF-des-images

Mais ce que je voudrais c'est que les utilisateurs qui uploadent une image
et qui la voient "à l'endroit" sur leur bureau (car celui ci tient compte de la rotation exif)
puissent simplement la télécharger sans jamais savoir qu'il eiste des exifs
et la voir également et tout simplement "à l'endroit" sur le site spip.

J'imagine qu'il faudait...
soit que image_reduire réinjecte les metadonnées exif après avoir réduit (?)
soit que l'upload en tienne compte pour assurer "physiquement" la rotation décrite par les métadonnés...

JL

#4

Je comprends, je pense, votre demande.
Cependant, j’émets une légère objection :
Mettons nous en situation si vous le permettez :
Je fais une image, on peut donc dire que j’en suis le “créateur”.
Je peux donc normalement supposer que mon oeuvre va rester en l’état.
Or, voilà t y pas qu’un système d’information me modifie mon travail!
Quid du droit d’auteur ?
Si vous êtes le seul rédacteur sur le site, je pense qu’il n’y a aucun problème, ce sont (à priori) vos photos, mais pour un site multi-redacteurs, peut être que cela peux engendrer quelques tensions.
Il me semble que c’est un point à prendre en considération.

R.S.

#5

oui enfin ca s'appliquerait aussi à des textes dont spip corrigerait la typographie en insérant des espaces insécables...

en plus en l'occurence la modification de l'œuvre est quasi null, il s'agit d'un ajustement technique qui ne change pas le rendu visuel de l'œuvre, mais qui, au contraire, vise à le faire respecter

#6

Hello,

il y a plusieurs sujets différents dans cette discussion :

# la rotation automatique sur la base des exifs à l'upload
c’est quelque chose qui existe, est dans le core ou le plugin medias, mais je sais plus si c’est désactivé par défaut ou si ça ne marche plus du fait de bigup par exemple ? -> a investiguer

# l’attribution de l’oeuvre à son auteur tel que renseigné dans les exifs
là encore, il me semble qu’à l’upload le champ credits devrait être renseigné avec les infos des exifs si il y en a, ce serait le plus simple et le plus clair, en permettant en plus de voir dans l’admin les informations et de les éditer si besoin

# la conservation des exifs à travers les filtres image, et plus généralement le « respect de l’oeuvre de l’auteur »
Et là c’est le drame, on ouvre la boite de Pandore et on touche à plein de sujets différents.

En ce qui concerne purement les exifs, moi je suis au contraire très contents qu’ils disparaissent automatiquement car je n’ai pas envie que la géolocalisation et la date et heure de la prise de vue de mes photos soit automatiquement diffusée à tout internet...
Juste pour illustrer que ce n’est pas un sujet si simple.

Sur le respect de l’oeuvre, c’est beaucoup plus compliqué.
Mauvaise nouvelle : le web n’est intrinsèquement pas un media qui permet d’assurer le respect de l’oeuvre pour la diffusion des photos.
Les images vont devoir être redimensionnées, cropées, compressées pour être diffusées dans des conditions d’accès correctes pour les utilisateurs. Et je ne parle même pas du rendu sur des écrans non calibrés voire totalement mal réglés...

J’ai eu il y a pas très longtemps le cas d’un photographe qui se plaignait que ses couleurs n’étaient pas respectées : pour cause, ses image étaient enregistrées avec un profil ICC de couleur qui n’était pas conservé lors du redimensionnement, les images étant rendues dans la palette web standard...

Donc bon on pourrait envisager que conserver les exifs à travers chaque filtre image, mais c’est aussi dangereux du point de vue des données personelles. Je verrais plutot un filtre qui permettrait de recopier certains exifs d’une image source sur l’image finale, sur le mode

[(#FICHIER|image_reduire{…}|image_recadre{…}|image_copie_exif{#FICHIER,’author’})]
(syntaxe exacte à définir)

Cela permettrait aux développeurs qui le souhaitent de conserver les exifs, tout ou partie, ce qui peut être parfois utile (site de photographe par exemple), mais ne serait pas systématique...

#7

Attention, pente glissante : à quel moment considère-t-on qu’une modification d’une oeuvre est ou non une trahison de l’auteur ?

Je pense que c’est à partir du moment où on la modifie sans avis de l’auteur, qui est le seul habilité à dire si son oeuvre est respectée ou non, chacun ayant ses propres exigences, qui sur le format, qui sur les couleurs, qui sur les exifs...

#8

Je ne suis pas trop d'accord avec la comparaison des espaces insécables (voir des fôtes d'orthographes).
Mais si je cadre à ma façon la tour de Pise à 90°, allez vous la recadrer de 3°59' (exactement!)?

Par contre, je ne dis pas qu'il faut interdire les modifications d'images.
Je pose juste les questions du point de vue des auteurs (depuis que j'ai une fille autrice, je prends parti!)
Je suis d'accord, pour ce qui est de la modification des images pour mettre au format web par rapport à une colorimétrie ICC, c'est une vrai modification, et personne n'a le choix de dire "non, je ne veux pas modifier".
Par contre, c'est peut être pas mal de demander l'avis de l'auteur, et de modifier après?

Et pour terminer, oui, Internet, c'est pas prévu pour respecter ni la vie privée, ni les auteurs.
Mais on peut se demander si c'est un problème de média ou d'humain.

R.S.

19 juillet 2020 10:35 "Maïeul Rouquette" <maieul@maieul.net> a écrit:

#9

Ça n'a strictement aucun rapport, c'est même l'inverse. Suivant les appareils, si tu prends en portrait au lieu du paysage classique (donc appareil tourné à 90), alors parfois la photo enregistrée est "physiquement" directement tournée (largeur petite, hauteur grande) OU BIEN parfois elle est "physiquement" en paysage MAIS avec une indication dans l'exif disant "cette image doit être visionnée tournée à 90" (et l'inverse sur les mobiles ou c'est plutôt le portrait par défaut, je crois)

Or justement sans cette prise en compte, la photo vue dans l'admin ne sera PAS vue comme tu l'avais prise, tournée à 90, pas comme tu voudrais la voir. JLuc dit donc que SPIP devrait bien toujours prendre en compte cette information et afficher la photo comme TOI tu voulais qu'elle soit, car c'est ce qu'attende les gens intuitivement. C'est donc l'inverse, c'est actuellement sans cette prise en compte que ça modifie et n'affiche pas comme tu l'avais prise. Et Cédric précise en disant que normalement SPIP a bien un code pour que ce soit pris en compte mais que peut-être il y a un bug et que ça ne marche plus (à confirmer et faire un ticket pour ça donc).

#10

Ok, je retire ce j’ai dit.

R.S.

#11

et je précise que ma comparaison avec la typographie était uniquement sur ce point : SPIp fait des traitements automatiques pour assurer la typo, de même qu'il peut/pourrait faire des traitements automatique pour assurer le fait que l'on voit l'image dans le bon sens.

#12

comme le dit Rasta dans un autre fil : si la personne prend une photo en mode "paysage" mais que pour cause de réduction et de non prise en compte de l'exif SPIp retourne cela en portrait (et reciproquement) c'est bien là qu'il y a trahison de l'œuvre.

SPIp fait un certain nombre de traitement automatique pour assurer la cohérence du site (reduction de taille pour les images, correction typo pour les textes), et donc deja à ce moment là on sent une trahison de l'œuvre...

#13

Bonne nouvelle : ça vient pas de Bigup :slight_smile:
Autre nouvelle : «medias» indique dans son code :

  // permettre aux plugins de faire des modifs a l'ajout initial
  // ex EXIF qui tourne les images si necessaire
  // Ce plugin ferait quand même mieux de se placer dans metadata/jpg.php

Et ne tourne donc pas les images selon l’exif par défaut. Mais je ne trouve pas non plus je crois de plugin qui ferait ça, (j’ai pas trop cherché non plus)...

MM.

#14

Bonjour,
Je viens d'uploader des photos avec bigup en 3.2.7 et l'orientation exif des images est conservée.
Jacques

#15

J'ai l'impression que le filtre image_reduire ne tient pas compte des données exif des photos,
et ne fournit aucune exif au fichier de l'image-réduite.

Vacances finies je rééxamine le squelette et les exifs des différentes images produites aux différentes étapes du traitement, et il m'apparaît que image_reduire conserve bien les données EXIF
mais que c'est image_proportion qui les fait disparaître.
Est-ce que ça facilite t il la prise en compte de ce soucis ?

JL

#16

Je pense que pour image_reduire ça dépend aussi de la méthode que tu as choisi dans ecrire/ pour la création des vignettes.
Certaines méthodes probablement perdent aussi les données.

Mais ensuite, pour tous les filtres qui transforment les images (donc modifient son contenu au delà d’une simple mise à l’échelle, donc y compris recadrent) il y a en effet création d’une nouvelle image via GD2 et aucun processus de recopie des exif de la source vers la destination.

#17

Je pense que pour image_reduire ça dépend aussi de la méthode que tu as choisi dans ecrire/ pour la création des vignettes.
Certaines méthodes probablement perdent aussi les données.

J'ai essayé GD2 et CONVERT avec les mêmes résultats.

Mais ensuite, pour tous les filtres qui transforment les images (donc modifient son contenu au delà d’une simple mise à l’échelle, donc y compris recadrent) il y a en effet création d’une nouvelle image via GD2 et aucun processus de recopie des exif de la source vers la destination.

J'ignore la mécanique de spip pour ces traitements, mais je vois que les différentes images réduites bénéficient bien de la rotation EXIF de l'image initiale, alors que celle qui passe par image_recadre ou image_proportions (qui appelle image_recadre) n'en dispose plus.
N'y a t il pas création d'une nouvelle image dans les 2 cas ?

Ya quelque chose qui cloche là dedans (https://www.youtube.com/watch?v=eryzp0Pklc8)

JL

#18

Je pense que pour image_reduire ça dépend aussi de la méthode que tu as choisi dans ecrire/ pour la création des vignettes.
Certaines méthodes probablement perdent aussi les données.

J'ai essayé GD2 et CONVERT avec les mêmes résultats.

OUPS NON les caches des proxies m'avaient joué un tour.
En testant avec de nouveaux documents je vois que image_reduire perd les EXIF de rotation avec GD2
mais que CONVERT les préserve (c'est la librairie que j'utilisais initialement).

Il faudrait parvenir à généraliser les bonnes pratiques de CONVERT avec image_reduire.

Mais ensuite, pour tous les filtres qui transforment les images (donc modifient son contenu au delà d’une simple mise à l’échelle, donc y compris recadrent) il y a en effet création d’une nouvelle image via GD2 et aucun processus de recopie des exif de la source vers la destination.

J'ignore la mécanique de spip pour ces traitements, mais je vois que les différentes images réduites bénéficient bien de la rotation EXIF de l'image initiale, alors que celle qui passe par image_recadre ou image_proportions (qui appelle image_recadre) n'en dispose plus.
N'y a t il pas création d'une nouvelle image dans les 2 cas ?

Oui mais il y a plusieurs manières possibles de créer une nouvelle image.
Par exemple la fonction _image_creer_vignette dans le cas GD2 utilise ImageCopyResampled
et sinon utilise ImageCopyResized.
On ne semble pas passer par là pour image_reduire mais ce serait une piste !

Je vois aussi qu'une bonne part du code garde les stigmates trompeurs d'une histoire où gd était la principale ou seule librairie :
- la fonction appelée "_image_gd_output" est en fait appelée par d'autres méthodes que gd (yc convert)
- "_image_valeurs_trans" est utilisée par toutes les méthodes (yc convert) alors qu'un commentaire indique que c'est réservé à GD2 (https://git.spip.net/spip/spip/src/branch/master/ecrire/inc/filtres_images_lib_mini.php#L105)

Au passage je découvre que var_mode=images permet de refaire les calculs d'images.
Yeah bonne pioche !
À documenter dans https://www.spip.net/fr_article4453.html ?

JLuc

#19

J'ai fait ticket (https://core.spip.net/issues/4546)
mais ne vais pas creuser car j'ai pu contourner en utilisant des css
(https://www.educative.io/edpresso/how-to-crop-an-image-in-css).

JLuc

#21

Pour revenir là dessus, on a bien une fonction tourner_selon_exif_orientation() dans medias action/tourner.php · master · spip / medias · GitLab mais celle-ci n’est jamais appelée dans le core. Et c’est peut-être pas plus mal car ça pourrait générer de belles pages blanches (ou de simples échecs si on utlise convert) quand il s’agit de tourner une image de 8000x6000 pixels sur un petit serveur.

Le ticket est ici maintenant #4546 - image_recadre perd l'EXIF de rotation - filtres_images - SPIP on GIT