Je ne peux pas répondre à ta question car je ne comprends pas la mise à jour des catégories associées...
Les liens doivent rester, si pLoader fait une mise à jour en créant une nouvelle catégorie.
Il l'a crée mais les mises à jour ne touchent pas aux associations existantes dans tous les cas.
Les tags?
Cumul = association aux tags si non présent.
Remplacement = dissociation de l'image de tous les tags / association aux tags proposés par l'image
Les catégories? (à mon avis).
Quelles catégories? Si j'ai associé l'image à 18 catégories virtuelles, pLoader va faire quoi?
=> Interdit de toucher aux associations existantes dans tous les cas.
Hors ligne
D'accord donc toi tu es plus catégorique sur la question. Bon ok ^^
Encore une fois, je n'utilise pas pLoader donc je dois avoir un raisonnement faussé...
Hors ligne
Salut :)
Je viens de tomber sur votre discution et ça m'intéresse vraiment.
En effet, j'utilise que Ploader pour mettre ma galerie à jour et je me demandais comment faire pour mettre les images en HD après coup ! Voila une solution qui permettrait de le faire.
Je trouve que l'option de Gotcha est vraiment bien:
SI une photos à déjà été envoyée >>
[?] Que faire ?
[_] Remplacer le fichier existant en remplaçant les anciennes informations (écrasement ; remplacement)
[_] Remplacer le fichier existant en ajoutant les nouvelles informations : tags, catégories etc (mise à jour ; mise à jour)
[_] Remplacer le fichier existant par la nouvelle photo sans toucher aux informations : tags, catégories etc (mise à jour ; mise à jour)
[_] Seulement mettre à jour les informations en remplaçant les informations (écrasement ; remplacement)
[_] Seulement mettre à jour les informations en cumulant les informations (mise à jour ; mise à jour)
[_] Ne rien faire (aucun changement ne sera effectué)
Par contre que faire si on veux envoyer la HD et ne rien mettre à jour il faut une option également. Que ce passe t'il si on a ajouté des photos qui n'ont pas été compressé par ploader et que maintenant on souhaite rajouter la photo original ? comme va t'il trouver la photo correspondante ?
Hors ligne
Je mixe ce que VDigital et moi proposont et ça me donne:
Certaines photos déjà livrées ont été modifiées.
[x] remplacer les fichiers
Que faire pour les propriétés de la photo ? (catégories associées, liste de tags, titre, description, etc.)
(_) rien
(o) cumuler
(_) remplacer
[x] ne plus poser la question aujourd'hui
[_] ne plus poser la question
[Valider]
qu'ai-je fait :
1. pris le titre de VDigital
2. gardé la notion de "fichiers" et non de "photos" pour la première checkbox
3. gardé la phrase sous forme de question pour "que faire...?"
4. plutôt que "informations associées" ou "informations relatives", je reprend le vocabulaire déjà présent dans pLoader (par soucis de cohérence), et ça donne "propriétés de la photo"
5. simplifié le libellé des propositions, tant qu'à enlever "informations", autant y aller carrément (the simpler the better)
6. gardé les questions de VDigital pour "ne plus poser la question..."
Hors ligne
Rappel: le comportement actuel de l'API Piwigo (pwg.images.setInfo) c'est de cumuler les propriétés multivaluées (catégories, tags) et de remplacer les autres (titre, description, auteur). C'est ce que je propose avec l'option par défaut de "cumuler" dans le "que faire...?"
VDigital a écrit:
Les tags?
Cumul = association aux tags si non présent.
Remplacement = dissociation de l'image de tous les tags / association aux tags proposés par l'image
Les catégories? (à mon avis).
Quelles catégories? Si j'ai associé l'image à 18 catégories virtuelles, pLoader va faire quoi?
=> Interdit de toucher aux associations existantes dans tous les cas.
Pourquoi fais-tu une différence entre tags et catégories ?
Si l'utilisateur choisit de remplacer et qu'il va volontairement passer de "cumuler" à "remplacer", moi je dis qu'il perd les associations des catégories. Tu prends le cas extrême d'un utilisateur qui aurait déjà 18 associations catégorie sur sa photo, mais dans 98.6% des cas, l'utilisateur va simplement "déplacer" sa photo d'une catégorie dans une autre et c'est ça qu'il veut faire.
Selon moi, vouloir différencier le comportement entre tags et catégories, ça va vouloir dire l'expliciter niveau interface utilisateur de pLoader et je préfèrerais que ça reste "simple" comme dans notre proposition conjointe (post précédent)
Hors ligne
sharkus a écrit:
Par contre que faire si on veux envoyer la HD et ne rien mettre à jour il faut une option également.
Ca c'est l'option "que faire...?" => rien.
sharkus a écrit:
Que ce passe t'il si on a ajouté des photos qui n'ont pas été compressé par ploader et que maintenant on souhaite rajouter la photo original ? comme va t'il trouver la photo correspondante ?
Si la photo a été ajoutée par la méthode FTP, ça ne marchera pas. Il faut que la photo ait été ajoutée via pLoader (ou PloaderMac ou piwigo_remote.pl, etc... un client qui exploite l'API Piwigo pour ajouter les photos)
Pour le "comment il retrouve la photo", direction [Forum, post 124405 by plg in topic 16518] gestion de la mise à jour des photos avec pLoader (à la fin de mon post, j'explique le md5sum)
Hors ligne
Merci plg pour toutes ces précisions ;)
plg a écrit:
Pour le "comment il retrouve la photo", direction [Forum, post 124405 by plg in topic 16518] gestion de la mise à jour des photos avec pLoader (à la fin de mon post, j'explique le md5sum)
J'avais bien lu le message mais ma question était plutôt de savoir si pour 2 photos identiques mais avec un taux de compression différent (la compression ayant été réalisée en amont et pas par ploader), est-ce que le calcul du md5sum renvoi la même chose ? Car si c'est pas le cas une photo compressé avant envoi via ploader ne sera pas reconnu comme la même photo "hd".
Je ne sais pas si je me suis fait comprendre :/
Hors ligne
sharkus a écrit:
ma question était plutôt de savoir si pour 2 photos identiques mais avec un taux de compression différent (la compression ayant été réalisée en amont et pas par ploader), est-ce que le calcul du md5sum renvoi la même chose ? Car si c'est pas le cas une photo compressé avant envoi via ploader ne sera pas reconnu comme la même photo "hd".
Avec des taux de compression différents, les fichiers sont différents ( déjà par la taille ), et le md5 sum également.
Dans la communication avec Piwigo, pLoader envoie les md5 sums :
- de la photo originale
- de la photo redimensionnée ( celle qui s'affiche dans la galerie )
- de la miniature
- de la photo haute définition, quand il y en a une.
C'est le md5 sum de l'original qui est utilisé comme identifiant unique de la photo. Les 3 autres md5 sont utilisés pour déterminer s'il y a eu des changements et s'il faut mettre à jour les photos correspondantes.
Donc dans le cas où l'original change, par le taux de compression, il n'y a pas moyen de retrouver la photo existante déjà uploadée et la nouvelle version sera ajoutée, comme une nouvelle photo, sans remplacer la précédente.
Dernière modification par ron (2009-12-05 17:42:34)
Hors ligne
En testant l'implémentation de la gestion de la mise à jour des photos, selon la dernière proposition de plg, nous nous sommes aperçu que le fait d'avoir un comportement global pour les propriétés simples ( titre, auteur, descriptions ) et pour les propriétés multivaluées ( tags, catégories associées ) limite les possibilités. La nouvelle implémentation sera plutôt :
Certaines photos ont déjà été livrées.
Que faire pour les fichiers ? (miniature, taille web, haute résolution)
(_) rien
(o) remplacer
Que faire pour les propriétés simples de la photo ? (titre, description, date de création)
(_) rien
(_) cumuler ( garder les propriétés existantes et remplir celles qui sont absentes dans Piwigo)
(o) remplacer
Que faire pour les propriétés multiples de la photo ? (catégories associées, liste de tags)
(_) rien
(o) cumuler ( garder les propriétés existantes et ajouter les nouvelles )
(_) remplacer
[x] ne plus poser la question aujourd'hui
[_] ne plus poser la question
[Valider]
qui permettra par exemple d'ajouter des tags dans une mise à jour, sans avoir à ressaisir les informations ( titre, auteur, description ) qui ont été transmises lors de l'envoi précédent.
Hors ligne
Poser des questions, pourquoi pas c'est vrai qu'on est très proche de l'utilisateur, lequel n'est pas forcément le webmaster.
Donc, sur cet aspect, je me range à votre choix.
Peut être que de n'avoir que des boutons radios est plus simple, et très clair.
Mais:
Un radio
(_) rien faire
(o) faire
ou
Une case à cocher
[_] faire
Je ne vois pas la différence fonctionnelle.
Pour illustrer mon propos
Exemple: quand tu postes sur le forum, tu n'as pas:
Options
(o) Ne pas s'abonner à cette discussion
(_) S'abonner à cette discussion
Mais bien:
[_] S'abonner à cette discussion
Et cela ne perturbe personne.
Hors ligne
Le bouton radio force à lire quasiment l'intégralité des solutions proposées. Pourquoi ? Parceque c'est important et qu'un choix entre x et y et demandé.
La case à cocher est plus optionnelle à savoir que si elle n'est pas cochée, l'action associé n'est pas entreprise.
Avec les boutons radios, on voit tout de suite la "valeur par défaut" que prendra l'action.
Hors ligne
Gotcha a écrit:
Le bouton radio force à lire quasiment l'intégralité des solutions proposées. Pourquoi ? Parceque c'est important et qu'un choix entre x et y et demandé.
La case à cocher est plus optionnelle à savoir que si elle n'est pas cochée, l'action associé n'est pas entreprise.
Avec les boutons radios, on voit tout de suite la "valeur par défaut" que prendra l'action.
Je suis tout à fait d'accord avec Gotcha
Dernière modification par sharkus (2009-12-08 10:55:00)
Hors ligne
Bonjour à toutes et tous !
Petite re-suggestion, question gestion des noms de fichiers, actuellement j'utilise une application photothèque similaire à piwigo, excepté que je n'ai pas du tout de module d'ajout en nombre. C'est pour cela que je test actuellement Piwigo.
Cas concret, lorsqu'une personne choisit ou me demande une sélection de photos à but d'utilisation diverses (impression, site internet, magazine, etc...) il faut absolument qu'il ait d'un coup d'oeil (notamment lorsqu'il va publier les photos) une description basique ainsi que le crédit de la photo.
Pour cela j'utilise photoshop ou nview, pour retailler à la volée selon trois définition et pour renommer parfaitement les différents format (numéro d'ordre + nom ou lieu + le caractère spécial © crédit + nom du photographe.
J'obtiens ainsi un nom de fichier de type : 0001-place-vauban2885©nom-auteur.jpg
Ensuite une fois ma sélection faite, je télécharge le panier (zip) selon la définition choisie et dans ce panier, j'obtiens directement le nom d'origine, ce qui permet de travailler correctement et évite les problèmes de droits !!! celui-ci étant inclut dans le nom du fichier. (gain de temps pour tous le monde et plus de travail avec des fichiers ayant un numéro d'ordre non utilisable.
Je précise bien sûr que ca fonctionne actuellement sur mon application car je tiens à jour la liste des derniers numéros de photos, sachant que j'ai prévu 4 caractères donc 9999 pour le nombre.
J'espère avoir été clair par ces explications, en tout cas je pense vraiment que l'option permettant de conserver le nom du fichier physique serait un plus et me fera choisir piwigo.
Bien à vous et avec mes encouragements.
Cordialement.
@Slimane :
Vos photos se trouvent donc déjà au format que vous indiquez ?
Je n'ai pas essayé mais est-ce que le symbole © fonctionne bien ? Avec Piwigo j'en doute...
Donc si je comprends bien, vous désirez trouver un moyen à ce que le visiteur télécharge un format .zip contenant les photos ainsi renommée ?
Hors ligne