[Résolu] Métadonnées dans une image

Bonjour à tous
J'ai besoin d'attacher quelques informations à de nombreuses photos
Pour l'instant, je crée pour chaque photo un fichier xml contenant ces informations, sous la forme

<photo autor="dupont" ...>
    <file>adresse du fichier</file>
    <title lang="fr">titre en français</title>
    <title lang="en">title in English</title>
    <description lang="fr">description en français</description>
    <description lang="en">description in English</description>
    ....
</photo>

L'ennui de cette technique, c'est qu'il faut manipuler à la fois l'image et son fichier xml attaché, ce que je préférerais éviter.
Je suis en train d'étudier deux approches:
- mettre les données comme métadonnées dans les fichiers image, ce qui semble possible même si c'est un peu compliqué à coder en php
- mettre l'image elle-même, et non son adresse, dans la balise <image> sous la forme d'un CDATA
Sans doute y a-t-il d'autres approches pour réaliser cela??

Votre avis?
Modifié par PapyJP (30 Apr 2018 - 16:02)

Et l'eau PapyJP,

Je ne vois pas le contexte, mais Sqlite (voir carrément MySQL) n'est pas plus adapté ?
Modifié par niuxe (01 May 2018 - 01:44)

niuxe a écrit :
Et l'eau PapyJP,

Je ne vois pas le contexte, mais Sqlite (voir carrément MySQL) n'est plus adapté ?

Chaque fois que j'envisage d'utiliser une BDD je me rends compte que c'est un outil disproportionné pour mes besoins... outre que la plupart du temps on ne met pas les images DANS la BDD mais on y met plutôt l'adresse de l'image, exactement ce que je tente d'éviter.

Bonjour PapyJP,

Et ses metas, tu les utilisent pour de l'affichage ?
A quoi, elles servent?

PapyJP a écrit :

Chaque fois que j'envisage d'utiliser une BDD je me rends compte que c'est un outil disproportionné pour mes besoins...

Si tu as besoin d'une base, tu t'en sers.... C'est tout. Ensuite, il faut savoir quelle base répond à ton besoin :
- Sqlite (pour les petites applications web avec peu de visite. Sqlite est une base de données mono utilisateur). Bien que j'aime beaucoup Sqlite, celle ci n'est pas complète.
- MySQL(moyenne applications avec un taux de visite conséquent)
- PostgreSQL (grosse application web et monter en charge)
- Oracle (grosse application web et monter en charge)
- ms server (grosse application web et monter en charge)
- etc.

PapyJP a écrit :
outre que la plupart du temps on ne met pas les images DANS la BDD mais on y met plutôt l'adresse de l'image, exactement ce que je tente d'éviter.

+1. Je vois pas où est le souci. En base de données, tu récupères toutes les informations nécessaires (url de ton image, description, auteur de l'image, etc.).

Sinon, tu utilises un champ blob pour encoder ton image (ce n'est pas une bonne pratique).

Au passage, XML c'est bien, le JSON c'est mieux pour un échange de données. XML est intéressant avec l'XSLT
Modifié par niuxe (30 Apr 2018 - 19:30)

Un point à ne pas négliger s'il y a beaucoup d'images, c'est le total des temps d'accès disque pour tous ces petits fichiers de méta-données.

Et là une base de données simple à administrer comme SQLite3 est un bon compromis pour récupérer les méta-données d'un lot d'images.

Personne n'utilise Firebird ?
Modifié par bazooka07 (30 Apr 2018 - 21:40)

bazooka07 a écrit :
Personne n'utilise Firebird ?

Pour chipoter :

sql douteux....
- shadow
- filter
- role (je vois pas l'intérêt, ça fait doublon non ?)

Bien que parfois MySQL ait une syntaxe un peu particulière et quand on utilise un ORM (tel que ORM cakePHP, notORM, redbean, SqlAlchemy, Doctrine), il n'est pas dit que tu puisses l'utiliser dans ce cas là.
Modifié par niuxe (01 May 2018 - 02:27)

Bonjour,

Je comprends bien les réticences de PapyJP car je partage en partie son avis. Le "pauvre", il a à tout casser, quoi, 100, 200 images à traiter et jusque lors il n'a jamais fais appel à une Bdd. Je le vois mal s'y mettre pour traiter uniquement ce point sans l'étendre au reste des données de son site. Et là quel travail ?! A ce compte autant qu'il refasse de A à Z son site et je pense que c'est une épopée, que dis-je, un péplum qu'il évitera.

L'idée des métadonnées n'est pas bête et à mes yeux présente un avantage certain. En effet, pour des images qui peuvent être référencées, les métadonnées apportent un plus ; elles ajoutent de la sémantique à une donnée graphique. Donnée qui sera prise en compte et interprétée par les crawlers.

De fait, avoir la capacité de pouvoir les récupérer en php pour les intégrer au html fait, à mes yeux, d'une pierre deux coups.

Sans rentrer dans la technique car c'est un processus que je n'ai pas expérimenté (mais qui m'intéresse grandement), ceci présentera 2 inconvénients (si ce n'est plus). Le premier est lié au poids des images qui se verra grossir en conséquence. Toute optimisation des images (compression ou autre) devra se faire avec des pincettes au risque de voir les méta supprimées.
L'autre inconvénient consiste, s'il y a lieu, dans le cas où une image existerait en plusieurs tailles. Un dilemme de taille est de déterminer s'il faille ajouter les méta à toutes les versions d'une image ou juste à une "promise".

Merci de vos réponses, qui m'aident à faire progresser mes réflexions.

A propos des BDD: elles sont très utiles pour des données dynamiques, mais les sites dont je m'occupe ont des données statiques, les seule modifications qui y sont apportées sont faites par le gestionnaire du site.

A propos des performances, en particulier des accès fichiers:
Une BDD relationnelle ne peut fonctionner efficacement que si on dispose d'une grande quantité de mémoire. Ce qui retardé d'au moins 20 ans l'utilisation des bases de données relationnelles dont on avait fait des maquettes dès la fin des années 1960, c'est que la mémoire des ordinateurs était très onéreuse, la capacité des disques et leur vitesse d'accès très faibles.
Une BDD fait beaucoup d'accès disques pour mettre en mémoire une grande quantité de données, ce qui permet ensuite d'accéder rapidement aux tables, naviguer dans les tables et finalement reconstituer les données.
Si on est amené à consulter une BDD pour afficher quelques images, je pense que le temps d'accès sera nettement plus long que si on ne charge que les fichiers descriptifs de ces quelques images.

Dans mon cas particulier, les informations servent uniquement à générer du HTML quand on désire afficher les photos.
Pour cela, le plus pratique est de constituer des "objets" php et/ou JS selon le contexte, dont les "propriétés" sont les données attachées à la photo, et les "méthodes" permettent de générer le HTML selon ce qu'on veut afficher, en particulier la langue de l'utilisateur et le rôle de l'image dans la page, qui peut aller d'une simple icône sans titre à une page entière avec la photo grand format, le titre, la description détaillée de ce que cette photo représente, etc.

Si on regarde la façon dont les images matricielles sont représentées en svg, ce sont des balises comme celle-ci:

<image
     width="458"
     height="400"
     preserveAspectRatio="none"
     xlink:href="data:image/jpeg;base64,/9j/4AAQSkZJRgABAQAAAQABAAD//
    ..........
    KjZlqaErp0b+WFnjOG285FVhDuGfta88/dNSXEzhcGT5HG0gdj2NQrOAoBZeBVJDSfQ//9k=
   "
     id="image4493"
     x="0"
     y="0" />

c'est à dire qu'elles contiennent le fichier jpeg codé base64.
Il est tout à fait envisageable d'inclure les images dans les fichiers xml qui représentent actuellement les "objets" en utilisant ce mécanisme, et faire en sorte que les "objets" soient transmis en xml ou JSON à un script php ou JS qui génère le HTML désiré.

Ce qui risque par contre de poser problème, c'est la façon dont de telles images vont être référencées par Google et consorts.

Salut Papy,

Comme Greg_Lumiere, je peux comprendre qu'utiliser une BDD te demande presque une refonte complète de ton site, d'où la réticence. En revanche, je pense qu'il faut pas nier non plus les avantages de cette dernière.

Les BDD structurées ne sont pas seulement adaptées pour un usage de données dynamiques. Elles sont idéales à partir du moment où tu dois... structurer tes données. En gros, tu peux représenter l'information (statique ou pas donc) en choisissant le modèle qui te convient, pour te faciliter la tâche lors de la lecture.

Dernièrement, l'avantage d'une BDD ne se limitera pas à ta galerie. Tu pourrais aussi implémenter un CMS (ou utiliser un déjà existant) pour permettre au propriétaire de gérer son contenu de manière décente.

Mais oui, ça demande un peu de travail.

Good luck !

Ce n'est pas que "ça demande un peu de travail", c'est que ça ne le semble pas du tout approprié à ce que je cherche à faire.
La structuration des données à la base des BDD actuelle hérite directement des applications écrites en langage COBOL dans les années 1960-1980. Je pense que plus personne n'utilise le COBOL, mais le typage de données du COBOL est toujours là.
Les seules BDD qui pourraient m'être utiles sont les BDD objets, techno très prometteuse en 1990 mais qui a été tuée par le trio IBM-Microsoft-Oracle. C'est comme la voiture électrique, ça reverra le jour, mais je ne serai plus là pour le voir.
Pour info, j'ai passé les dix dernières années de ma carrière professionnelle chez le principal fournisseur de BDD.

Pour en revenir au référencement des images base64, il se confirme qu'elles ne sont pas référencées par Google & al. Ce qui veut dire que je ne peux pas me dispenser d'avoir des fichiers jpeg ou png "en dur" dans l'arborescence du site. Il doit du reste en être de même si on met des images à l'intérieur d'une BDD et c'est sans doute pour ça que c'est considéré comme une "mauvaise pratique".
L'approche "metadonnée" pour sa part est trop limitée, notamment en taille. Elle est essentiellement destinée à mettre des informations sur l'auteur d'une photo, la date de la photo, etc. Dès qu'une image est modifiée par un éditeur d'image, les metadonnées sont perdues.
Je pense donc que je vais en rester à ma méthode de travail actuelle: un descriptif d'une part, un fichier image d'autre part.
Je marque donc le sujet comme "résolu", faute de mieux.

On pourrait s'interroger sur la légitimité de ceux qui qualifient de "mauvaises" les pratiques des autres, mais c'est une autre histoire.
Modifié par PapyJP (01 May 2018 - 12:32)

Le Cobol et le Fortran sont des langages encore utilisés de nos jours. Un dev Cobol en province peut avoir un excellent salaire. Je connais une ou deux structures qui utilisent encore ces langages.

Par ailleurs, je vais donner les avantages et inconvénients d'encoder les images dans une base :
pour un encodage :
- La gestion des uploads est simplifiée.
- Il n'y a pas de problèmes de droits en lecture ou écriture sur les répertoires,
- pas de sauvegarde des fichiers à faire,
- pas de risque d'incohérence entre les fichiers stockés sur le disque et leurs chemins répertoriés dans la base.
- Quand on veut faire une sauvegarde, ce sera seulement un dump de la base

contre un encodage :
- la base de données risque d'être très sollicitée en cas de gros fichiers.
- Pour ne pas la surcharger, on préfèrera stocker uniquement le chemin de l'image dans un champ de type varchar.
- De plus les images seront facilement accessibles via un simple URL.
Modifié par niuxe (01 May 2018 - 16:48)

Bonjour les amis,
Un peut étonné par la teneur de ce sujet, je voudrais rappeler quelques points toujours non résolus par les fabriquants ....
1) les Métadonnées contenues dans les photos ne sont pas cryptées de façon identique ni même au même endroit, en fonction du matériel, (appareil photo,logiciels, scaner etc...)
2) Les Métadonnées sont bien sur et malheureusement concervées par les programmes (par exemple Adobe Photoshop Pro)

Exemple, je prends une photo prise par moi avec un Nikon (a telle date, focal vitesse etc) et faisant 4200*2048 pixels.
Deux ans aprés je vais sur le web et prends une image dans google image. disons de 1024*1024 pixels .....
Je charges les deux images dans Adobe Photoshop, je redimentionne mon image en 1024*1024 ....
Je copie colle la photo google sur la mienne, puis j'aplatit les calques et sauvegardes !

L'Exif me dira photo prise par Nikon focale etc.... bref tout intacte !

Dernier points je peut simplement en windows10 (explorateur) clic droit propriétées aller changer la plus part des données de l'exif et appliquer !

Voila juste pour clarifier ce sujet !
Amitiées