Aïe...

Déjà, vos convives ne devaient pas avoir les même boitiers (appareils photos numérique) donc le réglage du point de vu de l'heure, il suffit que l'un d'eux soit complétement à l'ouest et c'est la cata.
Du coup, vu que vous n'arriverez probablement pas à définir une même échelle de temps pour tous* il va falloir faire autrement.

3000 photos pour un évènement c'est vraiment beaucoup. Imaginez la tête des visiteurs devant cette masse de photos ! En plus, bonjour les doublons...
Donc soit il faut opter pour découper le mariage en différentes "phases" (préparatifs, arrivé des mariés, église, sortie de l'église etc etc) soit afficher les photos par "photographes". On peut même imaginer les deux à la fois ^^

Bref, du coup, l'affichage sera déjà bien meilleur et le tri s'effectuera sur la date (oui bon, elle sera toujours là même...) mais aussi et surtout sur le nom du fichier qui lui, est chronologique [normalement].

Et voilà comment on contourne un problème ^^

On peut toujours renommer les images avec le DateTimeOriginal via XnView.

Je suis du même avis que VDigital.

Les photos du photographe "pro" ne pèsent quand même pas 5Go ?!

VDigital a écrit:

J'en ai un peu marre de ces problèmes de classement par date et heure qui ne fonctionnent pas.
Je vais sans doute tordre le coup au problème dans la prochaine version (pas release, car cela demande un changement dans la base de donnée).

+1

On saurait "relativement facilement" régler le problème de l'heure.

En gros, nous avons des fichiers photos avec 2 dates de création (l'une avec l'heure et l'autre sans),
mais nous avons aussi d'autres fichiers (que des photos: scan, vidéos, musique, zip, pdf, etc...) pour lesquels il ne faut pas trop compter sur la date et heure de création.

En réalité, la solution passe par une modification de la base.
Un champ "datetime" au lieu d'un champ "date" dans la base.
Suivant ce qu'on a de disponible en entrée, on mettra la date et heure d'entrée dans la base, ou la date avec une heure fixe, ou la date et heure réelle.

Le vrai problème est la reprise de l'existant (je pense aux 99 529 photos de vimages et pas seulement aux 5 petits Go d'un beau mariage). Comment, rapidement, pouvons-nous réintègrer l'heure qui manque dans les bases actuellement?
Voilà tout le problème, et ne croyez pas qu'il sera résolu comme ça par un claquement de doigts.

VDigital a écrit:

On saurait "relativement facilement" régler le problème de l'heure.

En gros, nous avons des fichiers photos avec 2 dates de création (l'une avec l'heure et l'autre sans),
mais nous avons aussi d'autres fichiers (que des photos: scan, vidéos, musique, zip, pdf, etc...) pour lesquels il ne faut pas trop compter sur la date et heure de création.

En réalité, la solution passe par une modification de la base.
Un champ "datetime" au lieu d'un champ "date" dans la base.
Suivant ce qu'on a de disponible en entrée, on mettra la date et heure d'entrée dans la base, ou la date avec une heure fixe, ou la date et heure réelle.

Le vrai problème est la reprise de l'existant (je pense aux 99 529 photos de vimages et pas seulement aux 5 petits Go d'un beau mariage). Comment, rapidement, pouvons-nous réintègrer l'heure qui manque dans les bases actuellement?
Voilà tout le problème, et ne croyez pas qu'il sera résolu comme ça par un claquement de doigts.

J'avais déjà constaté ce problème, pas de champ heure pour le tri malgré la présence de l'information dans les exif.

Au plus rapide pour l'utilisateur pressé, utiliser un logiciel qui renome les fichiers en intégrant la date heure dans le nom du fichier aammjjhhnnss_filename.extension puis gérer le tri de la catégorie sur le nom de fichier.
Au plus efficace et plus simple pour l'utilisateur : exploiter l'information présente dans les exif et la stocker dans le champ date_creation (modifié de date en datetime)



Pour le problème de la reprise :
- l'heure est présente dans les exif : la récupérer
- l'heure n'est pas présente ou pas d'exif du tout : forcer l'heure à zéro (çà ne changera rien au tri actuellement en place)

Un ALTER TABLE `piwigo_images` MODIFY COLUMN `date_creation` DATETIME  DEFAULT NULL; applique bien une heure à 00:00:00 pour les champs déjà alimentés d'une date, et laisse les champs à null pour ceux étant déjà à null.


Une resynchro avec l'option "synchroniser les metadonnées" devrait alors suffire à la reprise de l'existant sur la plupart des galeries.
Pour des galeries comme celles de vimages, la resynchro risque de provoquer un timeout :
- prévoir un traitement de reprise
- revoir la synchro avec de l'ajax : provoquer des resynchro par paquets de 5000 ou 10000 images à la fois par exemple (le sujet avait déjà été évoqué dans un topic que la tout de suite je n'ai pas le temps de rechercher) pour éviter le time out.

Gotcha a écrit:

Je suis du genre plus expéditif à savoir que si ça ne fonctionne pas, je fait autrement pour m'en sortir sans réinventer la roue.

Donc cette histoire d'heure, pour moi c'est vraiment trop pointu comme commodité, pour une utilisation tout aussi tirée par les cheveux.
Bref, ce n'était que mon point de vu ^^

+1