🌍
Français
merci de tes réponses.
Et je suis d'accord avec toi. Soit la donnée existe dans la photo soit non. Et c'est bien que maintenant, il soit possible de la stocker.
@+
O-R
Octobre-Rouge a écrit:
Juste une chose encore, c'est lequel le fichier de config pour modifier en dur l'ordre par défaut?
local/config/config.inc.php
Il y a plusieurs raisons pour lesquelles ça a pris du temps (et davantage que 3 ans). La première étant sans doute qu'aucun des développeurs n'en avait eu besoin. Ensuite, j'avoue avoir plusieurs fois été prêt à l'intégrer mais je ne savais pas comment régler la question de l'ergonomie : si on donne la possibilité de stocker l'heure, il faut pouvoir la modifier dans l'interface graphique.
En fait pour l'instant j'ai tranché en disant : non, on ne la gère pas dans l'interface utilisateur. Soit on trouve l'heure dans les EXIF et on la stocke dans la base de données, soit l'heure reste à 00:00:00. J'ai estimé que personne ne va définir à la main l'heure de prise de vue, donc inutile d'alourdir l'interface utilisateur. Ce qui a bien simplifié l'implémentation de la fonctionnalité.
Gotcha a écrit:
La correction de ce bug en effet est à marquer d'une pierre blanche :-)
Bonjour à vous tous!
Après 3 ans de non participation au forum, je vois que le sujet était toujours d'actualité.
C'est dommage car depuis la version 1.7 et ce post: post:80793 , la solution était connue et celle ci devait être implémenté dans la 1.8...
Bon apparemment maintenant, cela va se faire pour la 2.2 et j'en suis très content car cela manquait à piwigo.
Juste une chose encore, c'est lequel le fichier de config pour modifier en dur l'ordre par défaut?
cdlt,
O-R
La correction de ce bug en effet est à marquer d'une pierre blanche :-)
Mascarille a écrit:
A noter que le champ date_creation incluait déjà l'heure avec PostgreSQL et SQLite.
Si j'avais su cela, j'aurai installé PostgreSQL sur mon serveur !
Merci à tous !
Le champ était compatible avec l'heure, mais Piwigo ne fournissait pas l'heure à la base de données pour autant...
Et puis avec PostgreSQL actuellement, tu aurais dû te passer de pas mal de plugins.
Super !
A noter que le champ date_creation incluait déjà l'heure avec PostgreSQL et SQLite.
Si j'avais su cela, j'aurai installé PostgreSQL sur mon serveur !
Merci à tous !
c'est commité (on a discuté avec rvelices pour son cas spécifique), [Subversion] r9073
A noter que le champ date_creation incluait déjà l'heure avec PostgreSQL et SQLite.
rvelices, je suis perplexe sur ton explication. Je cherche à comprendre mais je n'y parviens pas.
Préambule : par défaut, la date de création n'est pas utilisée pour l'ordre des photos.
$conf['order_by'] = ' ORDER BY date_available DESC, file ASC, id ASC';
Sur ta galerie les fichiers sont nommés ainsi R20100902_7981.jpg, R20100812_7737.jpg. On peut raisonnablement penser qu'il s'agit de "R" comme dans rvelices, puis 2010-08-12 la date de prise de vue et enfin 7737 le numéro incrémenté que ton appareil photo donne à la photo. J'en conclus que tu ne bidouille pas les noms de fichiers pour gérer l'ordre des photos, ce qui est la solution plusieurs fois préconisée par le passé pour palier à l'absence de l'heure dans la propriété date de création.
Si on ajoute l'heure dans le champ images.date_creation, certes la base de données n'aura probablement jamais besoin d'aller regarder les critères de tri qui sont après la date de création, mais en quoi est-ce un problème ? Dans ton cas, avec tes noms de fichiers, tu peux décider de ne pas utiliser la date de création dans les critères de tri et te contenter du nom du fichier (qui contient la date sans l'heure).
Ca concerne ton cas personnel, mais tu peux aussi ajouter un petit plugin qui supprime l'heure après la lecture de l'info dans les données EXIF. Ou encore on peut le mettre en paramètre de configuration du genre :
$conf['store_hour_in_date_creation'] = true;
(chez toi tu mets à false, et hop tu retrouves le même comportement qu'en 2.1 puisque toutes les heures seront à 00:00:00)
Oui, le problème avec les deux boîtiers,
c'est que sur le même jour on à une série D31_2542 à D31_2860 à fusionner avec D32_7654 à D32_8110 - Ce n'est pas possible !
Et je ne parle pas du spectacle qui passe minuit (ce qui n'est pas rare sur un Festival comme Avignon), du compteur qui arrive à 9999 et bascule en 0000 (plusieurs fois par an !)... = n++ séries
alors qu'avec date + heure on retrouve les photos parfaitement interclassées (On peut le vérifier avec Picasa)
- Par ailleurs on ne touche pas la numérotation d'origine (id Raw = id jpeg) stockée sur un NAS par date, pour pouvoir retrouver les photos d'origine en raw si nécessaire (Autrement la renumérotation serait une solution...).
Cordialement
Emile
Normalement, le nom du fichier étant incrémenté à chaque prise de vue, ce paramètre pour moi est égale à l'heure de la prise de vue. Je veux dire que le tri s'effectuera de la même manière mais sera bien plus précis avec comme paramètre l'heure de la prise de vue :-)
Mascarille a écrit:
Je ne comprend pas trop :
Date + heure fait que l'on aura bien le départ au début et le podium à la fin ?
Parce que
- aujourdhui tri descendant par date + ascendant par fichier -> le meme jour les dates sont egales et c'est le nom du fichier qui prend le relais ensuite
- demain tri descendant par date et heure + ascendant par fichier -> le nom de fichier n'a plus l'effet car l'heure prend la priorité
Mascarille a écrit:
Et quand on a un photographe avec deux boîtiers très bien calés (c'est mon cas en permanence sur tous les spectacles) on aura une fois le début et une fois la fin... et pas deux fois le tout ce qui est vrai problème quand je rentre avec 500 ou 1000 photos, plusieurs fois dans la semaine !
Désolé, de réagir un peu brutalement, mais pour moi c'est LE seul problème aujourd'hui de Piwigo dont j'apprécie par ailleurs la très grande qualité et la somme de travail que cela représente !
Bon j'ai dit "aussi bizarre que ca peut parraitre" sans rajouter pour "mon utilisation", mais c'est pour mon utilisation; je n'ai pas N boitiers bien callés.
Je suis d'accord avec Mascarille.
Je rajoute que l'ordre est déterminé aussi par l'ordre d'arrivé dans la galerie (BDD) et ce phénomène est très important par exemple pour le module externe "Piwigo" pour Lightroom. On peut y changer manuellement l'ordre des photos pour les ajouter dans cette ordre précis dans Piwigo.
Quoi de plus normal pour un photographe de de vouloir trier chronologiquement ses clichés. Qu'il soit sur logiciel de flux de travail ou bien dans Piwigo ;-)
Je ne comprend pas trop :
Date + heure fait que l'on aura bien le départ au début et le podium à la fin ?
Et quand on a un photographe avec deux boîtiers très bien calés (c'est mon cas en permanence sur tous les spectacles) on aura une fois le début et une fois la fin... et pas deux fois le tout ce qui est vrai problème quand je rentre avec 500 ou 1000 photos, plusieurs fois dans la semaine !
Désolé, de réagir un peu brutalement, mais pour moi c'est LE seul problème aujourd'hui de Piwigo dont j'apprécie par ailleurs la très grande qualité et la somme de travail que cela représente !
Aussi bizarre que ca peut paraitre, je prefere avoir les dates sans les heures. Si on a un album ou on publie des photos tout au long de l'année, je met l'ordre des images par date_creation DESC, file ASC. Cette config permet
- d'avoir les photos prises le meme jour dans le bon ordre (on voit d'abord le depart de la course/fete et ensuite le podium/les bougies)
- d'avoir les ordres chronologiwuement à l'inverse - les visiteurs n'ont pas a aller à la 120eme photo pour voir si du nouveau il y a
Je crains que pas moyen de s'en sortir si on met l'heure (utiliser une fonction MySql dur date_creation est une possibilité, mais ca n'utilise pas les index)