J’ai ouvert un photoblog il y a quelque temps et vu ma feignasse attitude qui me prend en ce moment, j’ai pensé que ce serait plus simple pour moi que les informations stockées avec la photo pendant la prise de vue par l’APN ou ajoutées ensuite dans mon logiciel de gestion de mon stock photo favori soient extraites et reprises sur l’affichage des billets. Pour résumer, voilà un exemple de ce que ça donne :
Dans l’exemple montré ici, j’ai choisi d’afficher le titre de la photo, sa légende s’il en existe une, le lieu (ville et pays) où elle a été prise — informations que j’ai saisies dans Lightroom® —, le mois et l’année de la prise de vue et les informations techniques correspondantes à la vitesse, l’ouverture, la sensibilité ISO et la longueur de focale, valeurs qui sont enregistrées par l’appareil et qui peuvent intéresser les photographes amateurs.
Je vous propose de détailler le moyen d’obtenir cela.
Vous avez compris que le prérequis pour obtenir ces informations est que la photo utilisée contiennent ses informations. Sur le photoblog, j’affiche un format réduit de la photo (en 600 x 400 pixels) et je mets un lien vers la photo originale (en 800 x 600 pixels). C’est sur cette dernière que les informations EXIF sont stockées — Lightroom® permet de conserver ces informations lors d’une exportation en JPEG. De plus, Dotclear est capable de récupérer ses informations et les stocke dans une table de la base de données pour leur utilisation ultérieure dès qu’on parcourt le dossier où la photo est stockée. Du coup il ne reste plus qu’à coder le nécessaire pour les récupérer et les afficher.
Pour ne pas réinventer ce qui avait déjà été fait ailleurs — et pas par le premier venu — j’ai sollicité Olivier Meunier qui avait développé pour ses propres besoins de quoi me satisfaire. J’ai récupéré le code qu’il utilise chez lui et je l’ai adapté ici.
if (!defined('DC_RC_PATH')) { return; } $core->addBehavior('publicAfterContentFilter',array('neokraftBehaviors','publicAfterContentFilter')); class neokraftBehaviors { protected static $post_imgs = array(); protected static $post_imgs_reg = '#(?:<p>\s*)(?:<a[^>]+href="(.+?)"(.+?)>\s*</a>)\s*</p>#msu'; public static function publicAfterContentFilter($core,$tag,$args) { global $_ctx; if ($tag != 'EntryContent' || ($core->url->type != 'post' && $core->url->type != 'preview')) { return; } self::$post_imgs = array(); $str =& $args[0]; if (preg_match_all(self::$post_imgs_reg,$str,$m) > 0) { foreach ($m[1] as $i => $v) { self::$post_imgs[$v] = array( 'w' => null, 'h' => null, 'title' => null, 'meta' => null ); } $m = new neokraftMedia($core); $m->getMediaItems(self::$post_imgs); $str = preg_replace_callback(self::$post_imgs_reg,array('self','photoMeta'),$str); } } protected static function photoMeta($m) { if (!self::$post_imgs[$m[1]]['w']) { return $m[0]; } $i = self::$post_imgs[$m[1]]; # read meta $meta = $i['meta']; $meta_title = array('Title','City','Country'); $title = array(); foreach ($meta_title as $t) { if ((string) $meta->$t) { $title[] = html::escapeHTML((string) $meta->$t); } } $title[] = dt::dt2str( '<span class="exif-datetime">'. '<span class="exif-weekday"> %A</span>'. '<span class="exif-daynum"> %e</span>'. '<span class="exif-month"> %B</span>'. '<span class="exif-year"> %Y</span>'. '<span class="exif-time">, %H:%M</span>'. '</span>', (string) $meta->DateTimeOriginal); $description = ''; if ((string) $meta->Description && (string) $meta->Title != (string) $meta->Description) { $description = '<p class="exif-desc">'.html::escapeHTML((string) $meta->Description).'</p>'; } $info = array(); if ((string) $meta->Exposure) { $info['speed'] = (string) $meta->Exposure.'s'; } if ((string) $meta->FNumber) { $info['aperture'] = (string) $meta->FNumber; $aperture = sscanf($info['aperture'],'%d/%d'); if ($aperture) { $info['aperture'] = 'f/'.$aperture[0]/$aperture[1]; } } if ((string) $meta->ISOSpeedRatings) { $info['ISO'] = (string) $meta->ISOSpeedRatings; } if ((string) $meta->FocalLength) { $info['focal length'] = (string) $meta->FocalLength; $flength = sscanf($info['focal length'],'%d/%d'); if ($flength) { $info['focal length'] = $flength[0]/$flength[1].'mm'; } } if (!empty($info)) { foreach ($info as $k => &$v) { $v = $k.': <span class="exif-value">'.$v.'</span>'; } $info = '<p class="exif-info">'.implode(', ',$info).'</p>'; } else { $info = ''; } $s = preg_replace('#(</p>)$#', '$1'. '<div class="exif">'. '<p class="exif-title">'.implode(', ',$title).'</p>'. $description. $info. '</div>', $m[0] ); return $s; } } class neokraftMedia extends dcMedia { public function getMediaItems(&$post_imgs) { $paths = array_keys($post_imgs); foreach ($paths as &$v) { $v = preg_replace('/^'.preg_quote($this->core->blog->settings->public_url,'/').'(\/?)/','',$v); } $rs = $this->con->select( 'SELECT media_id, media_path, media_title, '. 'media_file, media_meta, media_dt, media_creadt, '. 'media_upddt, media_private, user_id '. 'FROM '.$this->table.' '. "WHERE media_path = '".$this->path."' ". 'AND media_file '.$this->con->in($paths) ); while ($rs->fetch()) { $u = $this->core->blog->settings->public_url.'/'.$rs->media_file; if (!isset($post_imgs[$u])) { continue; } $o = $this->fileRecord($rs); $s = getimagesize($o->file); $post_imgs[$u]['w'] = $s[0]; $post_imgs[$u]['h'] = $s[1]; $post_imgs[$u]['title'] = $o->media_title; $post_imgs[$u]['meta'] = $o->media_meta; } } }
Ce code est à placer dans le fichier _public.php
du thème utilisé — fichier à créer s’il n’existe pas en rajoutant une première ligne contenant <?php
et une ligne à la fin contenant ?>
. L’idée retenue est de retrouver la forme du code utilisé pour afficher les photos, d’en extraire l’URL pour retrouver le fichier correspondant, celui dans lequel les infos EXIF sont stockées, puis ensuite de retrouver ces infos dans la base et de les afficher à la suite de ladite photo. Ceci pour chacune des photos rencontrées dans le billet.
Le code HTML qui sera rajouté juste après le paragraphe qui contient la photo aura cette structure :
<div class="exif"> <p class="exif-title">titre, ville, pays, <span class="exif-datetime"> <span class="exif-weekday">nom du jour</span> <span class="exif-numday">numéro du jour</span> <span class="exif-month">nom du mois</span> <span class="exif-year">année</span> <span class="exif-time">heure</span> </span> </p> <p class="exif-desc">description</p> <p class="exif-info"> speed: <span class="exif-value">vitesse</span> aperture: <span class="exif-value">ouverture</span> ISO: <span class="exif-value">sensibilité</span> focal length: <span class="exif-value">longueur de focale</span> </p> </div>
Et voilà enfin le code CSS spécialement dédié à la mise en forme de ces informations :
/* Info EXIF -------------------------------------------------------- */ .exif { margin: 10px 0; } .exif-title { } .exif-datetime { } .exif-weekday { display: none; } .exif-daynum { display: none; } .exif-month { } .exif-year { } .exif-time { display: none; } .exif-desc { } .exif-info { padding: 5px 20px 10px; color: #999; font-size: 0.9em; } .exif-value { padding: 0 4px; color: #fff; background-color: #555; -moz-border-radius: 4px; -webkit-border-radius: 4px; }
À vous de jouer et d’adapter si nécessaire ;-)
1 De Osku -
Super classe.
2 De Cunégonde -
Pourquoi une aussi importante ouverture et une si grande vitesse pour un truc qui ne bouge pas?:-]]
3 De Franck -
La vitesse à cause de la lumière (beaucoup de soleil ce jour là), l’ouverture … bouge pas je demande à mon appareil photo ! Viens ici sale bête, j’ai deux-trois questions à te poser …
4 De annso -
génial !
J’essayerais de mettre ça en place chez moi (sauf que après ça soulève les questions embarassantes: pourquoi t’as fait tel réglage et pas celui ci ?)
5 De Jean-Michel -
Moi qui allait te demander de me fournir ce code que tu m’as montré à l’install party. Merci.
6 De Franck -
annso, évidemment ça peut donner lieu à de jolies discussions dans les commentaires des photos, mais en fait c’est bien l’idée finalement ;-)
Jean-Michel zizir ;-) (il fallait d’abord que je demande l’autorisation à Olivier de le publier, ce qui a été fait hier soir)
7 De mirovinben -
C’est vrai que les valeurs choisies par l’appareil et/ou le photographe peuvent être matière à moult discussions.
Si je mettais en place chez moi, chacun s’apercevrait que j’utilise mon EOS350 quasi exclusivement en mode automatique en le laissant choisir le couple vitesse/diaphragme qu’il veut. Je modifie éventuellement les ISO (si je sens que le flou de bougé n’est pas loin) et ne m’intéresse qu’au cadrage et à la position de la lumière.
Gloups…
8 De Franck -
Tu sais mirovinben, j’ai fait et publié plusieurs centaines (peut-être plus encore) de photos faites avec mon ancien compact, un Fuji, et le tout sans jamais faire la moindre retouche ni recadrage et bien évidemment en mode tout automatique. Donc ça vaut pas le Gloups… que tu mets à la fin.
Je trouve au contraire intéressant de constater que certains boitiers ont des modes auto plus que satisfaisant et par conséquent donnent accès à ce mode d’expression sans obliger un passage par la case technique, c’est ce qui m’a libéré dans ce domaine ;-)
9 De Cunégonde -
Vas y je t’écoute.
tu peux aussi m’envoyer un mail.
10 De Cunégonde -
Tout automatique c’est un choix aussi respectable qu’un autre!!
11 De mirovinben -
Si j’utilise le mode automatique lors de la prise de vue, je dois confesser ma très grande appétence pour les post-traitements : cadrage, luminosité, contraste (rarement couleur), “débourrage” des noirs etc…
Rares sont les photos qui n’ont pas subi un petit quelque chose. Et toutes voient une accentuation de la netteté pour palier la perte de pixels entraînant l’apparition d’un flou léger) due à la réduction de format pour le oueb.
12 De julien -
Un truc me paraît bizarre à la lecture du code (je ne l’ai pas encore testé chez moi, ce n’est qu’à la lecture que cela m’a sauté aux yeux). Il s’agit de la ligne 93 du code pour _public.php. On y lit ça :
if (!emptyempty($info)) {
Est-ce normal qu’on y trouve deux fois empty ?
Pour la question de l’ouverture, cela me semble pourtant évident : pour avoir une faible profondeur de champ… Bien qu’en voyant la photo, je réalise que le capteur doit être tellement petit que tout est net. ;-)
13 De Franck -
Il n’y a bien sûr qu’un seul empty sur le code original. Ce doit être le plugin Yash qui s’emmêle les pinceaux ;-)
14 De Franck -
D’ailleurs il suffit de cliquer sur le lien “voir source” en début de listing pour s’en apercevoir.
15 De julien -
Très intéressant cela, merci beaucoup… mais je vais avoir pas mal de travail pour adapter cela à mon utilisation. :-) (Déjà qu’il m’a fallu un temps énorme pour comprendre que c’est à cause de la ligne 14 qu’il n’affichait rien chez moi.)
Par contre, c’est un peu surprenant quand le temps de pose affiché est 15625/10000000s. Ca fait nettement moins naturel que 1/640s. ;-)
Au programme des modifs que je vais devoir faire :
Souhaitez-moi bonne chance ! :-)
(Pour les points 1 et 4, j’ai le sentiment a priori que le mieux sera de passer par un « tag » écrit manuellement dans le billet et filtrer cela via un *ContentFilter. À voir.)
(Désolé de penser tout haut dans tes commentaires… :-) )
16 De Franck -
Oui c’est curieux Julien ce temps de pose. Est-il enregistré tel-quel dans les infos EXIF/IPTC de tes photos par ton boîtier ?
Pour l’heure (UTC+TZ) j’aimerais connaître la solution que tu vas utiliser, comme ça je pourrais l’intégrer moi aussi.
(continue à penser tout haut ici, j’aime bien et ça peut intéresser d’autres que moi :-))
17 De julien -
Pour l’heure, j’ai trouvé. C’était plus “vicieux” que je ne l’avais imaginé. En fait, lors de l’affichage, il ne tient pas compte de la timezone définie par le blog et affiche donc l’heure UTC (et non le contraire comme je l’avais imaginé d’abord). Pour modifier ce comportement (et ainsi afficher l’heure dans la même timezone que le reste du blog), le bloc en lignes 57 à 65 devient :
Pour le temps de pose, je n’arrive pas encore à comprendre… Dotclear est le seul logiciel que j’ai lisant les données EXIF et qui l’affiche sous cette forme (et j’en ai testé au moins cinq différents). :-/ À voir si je vais continuer à chercher, puisque je n’ai a priori pas l’intention de publier cette information.
18 De julien -
Ah si, voilà enfin un logiciel qui me donne la même valeur pour le temps de pose : ImageMagick…
(Oui, je continue à penser tout haut puisque tu m’en as donné l’autorisation. Tu vas finir par le regretter ! ;-) )
19 De Franck -
Julien il manque une petite virgule après le
(string)$meta->DateTimeOriginal
et ce sera parfait ;-)Je me permets de corriger ton commentaire en conséquence.
20 De julien -
C’est le problème quand on fait du copier-coller de plusieurs sources différentes. :-) Merci pour la correction.
21 De julien -
Il y a un truc vraiment pas clair dans ce code (et qui m’a posé plein de problèmes avant que je le comprenne) : ligne 21, on définit la variable
$m
pour contenir les différents « matches » de l’appel àpreg_match_all
et ligne 32, on redéfinit cette même variable$m
pour contenir un objet de type neokraftMedia.Bon, d’accord à ce stade-là on n’est plus sensé avoir besoin du tableau des matches, mais c’est quand même un peu gênant d’avoir réutilisé le même nom de variable…
22 De julien -
À la réflexion, il y a encore un truc qui me paraît bizarre… Si j’ai bien compris le tout, ce code est appelé à chaque affichage d’une page et contenant une photo, pour afficher des informations qui, somme toute, sont plutôt statiques. Ne serait-il pas mieux (d’un point de vue des performances) de faire en sorte que ces données EXIF soient inclues dans le billet lors de sa rédaction ? Ou alors est-ce que le cache de Dotclear joue bien son rôle et rend mes inquiétudes inutiles ?
23 De Franck -
Pour le premier point, réutilisation d’un nom de variable, je ne pense pas que cela pose quelconque problème hormis une éventuelle confusion à la lecture du code.
Pour le deuxième point, le code est effectivement appelé pour chacune des photos présentes dans le billet (si j’ai bien compris), et il est probable qu’une mise en place à l’édition du billet serait plus efficace. Ceci dit, le cache doit prendre la relève dans la majeure partie des cas (peu de commentaires postés, donc peu de changement du contenu des pages servies).
24 De julien -
Pour le nom de la variable, je faisais effectivement la remarque dans le sens d’un problème lors de la lecture du code. J’ai besoin de réutiliser cette variable
$m
de manière différente dans le code que j’ai adapté et j’ai mis fort longtemps à comprendre pourquoi PHP me disait que j’avais un objet au lieu du tableau que je souhaitais. :-)Je viens de vérifier dans le cache : rien n’y est stocké (cache par défaut de Dotclear et sans utilisation de staticCache ou autre). Il y a juste l’appel au callback :
Pour mon cas perso, je vais donc regarder pour faire cela lors de la transformation wiki vers XHTML (puisque je ne rédige qu’en wiki). Je peux tout à fait comprendre que cette solution ne soit pas acceptable pour quelqu’un qui rédige en XHTML (je doute qu’il apprécie de voir le code et la structure de son billet être modifié lors de la sauvegarde) et je suppose que c’est pour cela qu’Olivier a pris le chemin du behavior.
25 De Franck -
Tu peux éventuellement t’inspirer du plugin Typo que j’ai développé, il transforme la version XHTML des billets pour appliquer les transformations, et donc peu importe que celui-ci soit issu d’une saisie wiki ou pas.
De plus celui qui aura installé ton plugin l’aura fait en connaissance de cause et ne devrait normalement pas être surpris des modifications apportées. Attention tout de même à ne pas les appliquer à chaque enregistrement du billet, sinon tu vas te retrouver avec n blocs d’info EXIF sous chaque photo ;-)
26 De julien -
Après une grosse frayeur hier soir (j’ai absolument besoin que les données EXIF que j’affiche apparaissent dans les flux, ce qui n’était pas le cas), mon système est actif depuis ce matin. \o/
Je vais regarder du côté de Typo, cela semble être une bonne idée… Et avec l’approche que j’ai choisie, aucune chance d’avoir plusieurs blocs EXIF qui apparaissent : étant donné que mes infos viennent se glisser au milieu de texte existant, je viens en fait remplacer un mot-clé dans le texte.
27 De julien -
Merci pour la piste d’utiliser Typo, ma version plugin de mon bouzin fonctionne à merveille (et avec elle je ne risque plus d’avoir de surprise de non-affichage des données EXIF qui m’importent ;-) ).
Et ma remarque précédente concernant une modification de la structure du billet XHTML de l’utilisateur peut être considérée comme nulle et non avenue… Je n’avais en effet pas conscience du fait que le code rédigé par l’utilisateur est stocké dans le champ
post_content
et que lepost_content_xhtml
contient ce qui est réellement affiché (après l’appel de filtres divers et variés sur le contenu depost_content
). Dans mon esprit, en mode d’édition XHTML, je pensais que seul le champpost_content_xhtml
se remplirait.Un grand merci pour tes précieux conseils. Il ne me reste plus qu’à étendre tout cela (par exemple pour ajouter automagiquement les attributs
width
etheight
sur le tagimg
…)28 De Franck -
Tu envisages une nouvelle version du plugin Photoblog ou est-ce un plugin indépendant ?
29 De julien -
C’est complètement indépendant et hautement « tailored to my specific needs. » Donc il n’y aura probablement pas de version publique.
30 De Simon H. -
Moi je suggère que t’en fasse un plugin :-D
31 De Franck -
J’y ai songé Simon, mais le problème est de savoir comment les photos sont mises en page dans les billets, ça peut varier beaucoup (avec ou sans lien, miniature utilisée, …). Un autre problème concerne les infos EXIF. Elles peuvent être transportées par la photo originale ou par une des miniatures, etc. Pas évident d’en tirer des généralités.
32 De mirovinben -
Chez moi, par la méthode utilisée (*) : pas d’Exif…
(*) : Travail sur l’original (jpeg) sauvegardé en PNG. Quand besoin de mettre en ligne : conversion en JPG.
33 De Franck -
Dommage parce que parfois, savoir comment sont prises certaines de tes photos m’intéresserait drôlement !
Ceci dit certains logiciels sont capables de conserver les infos EXIF pendant l’export ou la sauvegarde.
34 De mirovinben -
Heu… Outre un usage quasi permanent du mode automatique, 90% des photos sont prises avec cet objectif macro, (focale fixe 60mm -equiv 90mm- avec un piqué épatant). Et elles font toutes l’objet d’un post-traitement plus ou moins poussé.
Donc une lecture des données Exif issues de l’APN serait peu significative…
35 De Franck -
Quand à moi j’ai mis un 100mm dans ma liste de souhait pour le père Noël, celui-ci plus exactement ;-)
À ton avis ça fait une grosse différence avec le 60mm ?
36 De mirovinben -
A mon avis oui, car il a une focale (equiv 150 pour moi) quasi double du mien et, du coup, si ce n’est pas forcément gênant pour de la macro ou du portrait (pas besoin d’autant se rapprocher du sujet), cela peut le devenir si tu souhaites l’utiliser comme objectif courant (ainsi que je pratique) sans être obliger d’en changer à chaque nouveau sujet.
Je ne connais pas son piqué. Celui que j’ai est excellent et permet aisément de zoomer numériquement (et/ou recadrer) en post-traitement… Ce que je fais régulièrement en cadrant plus large à la prise de vue pour avoir un peu plus de profondeur de champ (important en macro) et en “resserrant” ensuite pour le blog.
Par contre “le tien” est plus imposant, il pèse le double “du mien”… ce qui peut avoir de l’importance… Et il coûte 100€ de plus chez le même fournisseur (ici).
37 De Franck -
Effectivement. Ceci dit je le destinerai probablement à un usage macro et/ou portrait. Ça va devenir compliqué de savoir quel caillou emporter et je commence à comprendre pourquoi les photographes avertis ont de multiples sacs et besaces en fonction de l’équipement à avoir sur soi !
38 De julien -
Je crois que j’ai peut-être trouvé pourquoi Olivier a pris cette voie-là au lieu d’un plugin modifiant le contenu du billet avant son insertion dans la base : avec mon plugin, je ne suis plus capable de créer un billet contenant une image ! (Par contre, je peux ajouter une image à un billet déjà créé.) Une sombre histoire de verrou sur des tables sur laquelle je vais devoir me pencher. :-/
39 De julien -
Bon, j’ai trouvé une parade à mon problème, mais c’est pas beau (refaire un update du billet dans la base de données après chaque ajout ou modification du billet)…
40 De Franck -
Tu n’as pas moyen de passer par le behavior
coreAfterPostContentFormat
qui va bien, comme celui que j’ai utilisé pour le plugin Typo ? Tu récupères le contenu, tu le modifies à ta guise et c’est tout.41 De julien -
C’est ce que j’avais fait d’abord. Mais le problème est que j’ai besoin d’accéder au contenu de la table
dc_media
. Or, la méthodeaddPost
dedcBlog
pose un verrou (lock) sur la tabledc_post
. Du coup, il n’est plus possible (en tout cas avec MySQL) de faire unselect
sur d’autres tables (le message d’erreur est alors « Table dc_media was not locked with LOCK TABLES »). La solution « propre » serait de pouvoir ajouter la tabledc_media
à la liste des tables verrouillées, mais il est impératif de verrouiller toutes les tables nécessaires en une seule opération et Dotclear2 n’offre pas la possibilité de le faire.Par conséquent, je me suis résolu à me greffer sur les behaviors
adminAfterPostCreate
etadminAfterPostUpdate
, modifier les champs*_xhtml
et refaire un update dans la base… Je me dois encore d’améliorer cela pour ne faire l’update que s’il est vraiment nécessaire. (Et je pense qu’il faudrait encore que je fasse également un appel àtriggerBlog
si je veux être sûr que le cache soit à jour… il faut que j’y réfléchisse.)Le truc « vicieux » dans cette histoire, c’est que de passer par
coreAfterPostContentFormat
fonctionne très très bien lors d’une mise à jour d’un billet, car la méthodeupdPost
ne pose pas de verrou. Le verrou est utilisé seulement lors de la création de billet car il est là pour assurer l’unicité de l’identifiant du billet (puisqu’il est calculé en PHP et non pas géré directement par la base). Et, bien sûr, j’avais fait mes tests la semaine dernière sans créer de nouveaux billets… ;-)42 De Franck -
Merci Julien pour toutes ces infos. Je comprends mieux maintenant le problème posé.
43 De Gradiva -
Franck, je veux pas être désagréable mais ça sert à quoi d’afficher cela ? On les devine et elles sont dans le jpg sauf si on les efface.
44 De Franck -
Les deviner ? Mazette, je ne suis pas assez fortiche pour faire ça au premier coup d’œil, par contre ça m’intéresse drôlement pour apprendre comment font les autres, voilà pourquoi j’ai trouvé intéressant de le faire.
J’efface effectivement les infos EXIF de tous les formats des miniatures, seule l’original les conserve, histoire d’alléger un peu la taille des fichiers — d’ailleurs il faudrait que je regarde combien ça pèse — pour les visiteurs qui se fichent de ces infos là.
45 De mirovinben -
Franck, je viens de faire un test rapide sur une photo. Avec les données Exif : 6160 Ko, sans : 6141 Ko différence : 19 Ko.
Les données Exif n’ont pas été modifiées et sont telles que l’APN les a écrites.
46 De Franck -
Donc une taille non négligeable en ce qui concerne les miniatures. Je fais bien de ne pas les garder ailleurs que sur l’image de plus grand format.
Merci d’avoir pris le temps de faire le test, Mirovinben.
47 De Franck -
Après vérification, il s’avère que c’est effectivement pas très rentable de les conserver sur les miniatures.
J’utilise les formats medium (400px max) pour l’affichage ici et un format user-defined (un peu plus grand, c’est-à-dire 600px max) pour les affichages sur Open-Eyes, eh bien les infos EXIF représentent respectivement 75% et 25% de plus en terme de taille de fichier. Ça fait beaucoup, je trouve, surtout que ces formats se retrouvent également dans les flux RSS.
48 De mirovinben -
Franck : et si tu ne laisse que les données Exif qui te paraissent intéressantes ? Ca devrait diminuer fortement la taille globale de cette partie data du fichier jpeg.
Je crois également que le format jpeg intègre une vignette de la photo. Je n’en suis plus très sûr (peut-être que ce n’est qu’au niveau du stockage par l’APN… m’en souviens plus) mais si c’est exact, on doit pouvoir la virer aussi pour tes tailles intermédiaires.
49 De Franck -
Une vignette dans un JPEG ? Il me semble que c’est plutôt dans les fichiers RAW qu’on peut trouver un aperçu JPEG, en tout cas mon APN le fait.
Peut-être qu’il faudrait trier dans les informations EXIF, mais pour ça il faut avoir le logiciel qui va bien, et ça complique singulièrement le processus. Je n’ai rien vu de possible dans ce sens avec Lightroom et je n’ai pas trop envie de changer d’application juste pour trier ça.
Je me dis que si quelqu’un est vraiment intéressé par les infos EXIF alors il peut tout à fait les extraire du format original de la photo dans lequel je les conserve.
50 De mirovinben -
Toutafé ! Si les passionnés ont accès quelque part aux données Exif ils sauront les trouver. Les autres s’en foutent un peu. Et c’est sur le grand format que j’aurais le réflexe de chercher et uniquement là.
Pour les Exif en général, une doc intéressante… notamment là pour l’histoire des vignettes…
51 De Gradiva -
Bonjour,
Si je peux redonner mon avis de pro, avec brutalité, je dirais que les exif n’ont aucun intérêt sauf pour un club photo. Je les utilise depuis 10 ans depuis le Nikon D1( les métadonnées ). Effectivement les supprimer n’est pas si simple, à noter que les softs gratuits de Nikon le font.
Quand je dis qu’on voit les exif sur l’image , je veux dire que les règles physiques de la photo sont connues et que l’on peut déduire de l’image à-peu-près tout, à la louche.
Par contre avec Dotclear et ses qualités de fiabilité et de rigueur, il est intéressant d’investir sur les iptc qu’il s’agisse de photos familiales ou professionnelles.
De plus les appareils deviennent sophistiqués pour des presets de métadonnées.
N.B.: Ce qui est intéressant dans les photos du blog de Mirovenben, ce sont les photos pas les exifs des photos……
52 De mirovinben -
“N.B.: Ce qui est intéressant dans les photos du blog de Mirovinben, ce sont les photos pas les exifs des photos…”
Merci Gradiva !… je crois que j’ai comme un coup de soleil sur mon visage, là.
Pour le reste de ton commentaire, ce que tu dis est d’autant plus vrai que , dans mon cas, la “chaîne de traitement” passe par une conversion PNG en cours de route qui éjecte automatiquement tout ce qui se rapporte aux données Exif et à une éventuelle vignette.
D’autant plus vrai que mes différentes interventions (plus ou moins conséquentes) sur mes photos à destination d’internet dénaturent complètement les données Exif d’origine tel que luminosité, contraste, colorimétrie, voir même focale relative.
53 De Gradlon -
Bonjour,
pour info, le code PHP suivant affiche les champs IPTC d’une image (cf iptc.org pour + d’info):
Voir aussi exif_read_data pour les données exif.
Gradlon
54 De Franck -
Merci Gradlon pour l’info.
55 De Gradlon -
You’re welcome ! Il s’agit des champs IPTC “historiques”(Information Interchange Model (IIM version 4.1) de l’IPTC) mais qui contiennent les données de base (Titre, mot-clés,…) permettant déjà bien des manips.
Le concept a été étendu en 2005 par Adobe sous la forme du noyau XMP/IPTC qui permet un stockage plus large et extensif grace au XML ( voir dans Photoshop les 4 panneaux IPTC de la commande “Informations”) mais qui me semble moins immédiat d’accès (pour l’ensemble des champs) que par l’intermédiaire des deux lignes de code ci-dessus… (cf http://peccatte.karefil.com/Softwar…).
Gradlon
56 De marc -
Salut et bravo pour ce tuto…est-ce vraiment obligatoire de passer par Dotclear pour lire ses données et les sauvegarder??? Je veux dire pour quelqu’un qui voudrais faire un simple galerie sur site perso du style.
Marc ;-)
57 De Franck -
Il existe probablement beaucoup d’utilitaires et de librairies de code permettant d’inclure les infos EXIF avec chaque photo affichée. Il est même probable que quelques applications web de gestion de galerie le proposent.
58 De julien -
Nouveau problème que je rencontre (et pour lequel je me creuse la tête sans succès) : dans la méthode getMediaItems, on récupère les méta-données stockées dans la table idoine de Dotclear pour l’image. Cette recherche s’effectue via le nom du fichier (récupéré ici dans l’attribut href d’une ancre).
Problème : si le nom du fichier qu’on récupère correspond à une des miniatures générées par Dotclear, comment retrouver le nom du fichier original (puisque les méta-données ne sont stockées en base que sous le nom de l’original) ?
59 De Franck -
Je dois avoir un peu de code qui ressemble à ce qu’il faudrait dans le plugin ListImages (dispo sur DotAddict, je n’ai pas le lien sous la main).
60 De julien -
Merci pour le pointeur vers ListImages… Cela m’a permis de développer quelque chose qui semble fonctionner.
Il y a toutefois une erreur dans la fonction ContentImageLookup de ListImages : si l’image originale a une extension entièrement en majuscules (exemple DSC_1234.JPG, ce qui arrive souvent avec les images produites par les appareils photo numériques), la miniature générée par Dotclear aura, elle, une extension entièrement en minuscules. Ce qui fait que le code de recherche de l’image originale ne pourra pas trouver le fichier dans un tel cas (puisqu’on commence par tester la concaténation avec l’extension de la miniature avant d’essayer des cas de « fallback » où toutes les extensions sont en minuscule).
Désolé, je n’ai pas de patch à offrir (mon cas se faisant lors d’une recherche dans la base de données, je peux me permettre de tout convertir en minuscules dans la requête SQL).
61 De Franck -
Tu nous ouvres un petit ticket sur le Lab pour qu’on y pense ? Merci !
62 De notafish -
Bon, une question puisque tu l’abordes dans ces commentaires. Comment génères-tu le format “user-defined” de tes photos pour Open Eyes ? Y’a un truc magique à faire que je peux reproduire ? :D Merci !
63 De Franck -
En fait, notafish, je génère moi-même toutes les miniatures utilisées par DC, sauf le format sq (square utilisé uniquement côté administration), avec Lightroom. Ensuite j’ai développé un petit plugin de publication de billet qui utilise, pour le photoblog Open-Eyes, le format
généré préalablement et uploadé au même endroit que les autres.Pour le nom des miniatures de ce format, j’utilise simplement la même convention que pour les autres miniatures (sq, s, t, m) en utilisant un
u
en lieu et place.64 De notafish -
J’avais bien vu le petit _u sur tes images, je ne savais pas si tu le générais directement dans dotclear ou si tu le générais ailleurs. J’ai maintenant ma réponse, merci.
Si j’ai bien compris, tu uploades donc deux images (DSC6754_u.jpg et DSC6754.jpg) et ton plugin bidouille pour dire au billet d’afficher la version _u et de la lier à la version originale, qui s’affiche ensuite avec Lightbox, c’est bien ça ?
Et si j’ai bien tout compris, le code lit l’url (donc /public/DSC6754.jpg) et va chercher dans la base les infos qui ont été extraites du fichier.
Une autre question, si je peux me permettre : utilises-tu le plugin Photoblog2 pour l’affichage des archives en miniatures ? Ou une autre astuce ? Merci d’avance :)
65 De Franck -
J’uploade toutes les miniatures (t, s, m, u) et l’image originale et mon plugin se charge quand je suis sur la page média d’une de ces photos et lorsque je confirme de créer un billet sur le photoblog (et un autre qui me sert de déco ici sur Open-Time).
Les infos EXIF sont quand à elles
par l’image originale ce qui permet à Dotclear de les récupérer au premier affichage du dossier la contenant dans l’administration.Donc le cycle est le suivant :
J’utilise en effet le plugin de Julien Mudry pour la gestion de la navigation sur le côté et pour les archives, sauf que pour cette dernière j’ai inversé l’utilisation : j’affiche la version colorée et le survol provoque l’affichage de la version monochrome.
66 De notafish -
Merci mille fois :)
67 De notafish -
Coucou, c’est encore moi. Comment j’appelle la fonction dans mon fichier de thème ? J’ai rien trouvé sur publicAfterContentFilter nulle part et je comprends pas tout :/. Merci.
68 De notafish -
Ah ben en fait, faut pas l’appeler :) Désolée du dérangement.