J'ai oublier de parler que la bibliothèque de Lr était de forme SQLite et qu'il était possible au démarage de Lr de choisir sa bibliothèque. Il est bien sûre possible de fusionner des BDD (bibliothèques).

Merci Eric.

Pour ma part, j'ai donc fait le choix de me "planquer" un peu à l'abri du forum publique car je trouve que ça bouillonne de trop et je ne souhaite pas entretenir une discution qui peut aboutir sur... rien.
En plus, il faudra bien un jour parler technique.

Pour ma part, en toute franchise, le stockage des clichés en ligne serait préférable de le faire de manière "à la pLaoder" pour n'avoir ainsi qu'une banque d'image.
De toutes manière, les originaux se trouvent sur d'autres supports et la gestion des catégories virtuelles ça reste le must.
Reste le point encore en discution sur l'inscription du nom du fichier...

Ce n'est pas vraiment ce que j'ai dit... au contraire. Je vais plus dans le sens de plg & Co sur ce coup là.
Regardes Eric : si tu arrives à gérer tes photos non plus sur ton disque dur + serveur distant mais uniquement sur ton disque dur. C'est tout de même plus simple non ? ^_^
Moi aussi j'aime bien ranger mes catégories physiques à l'identique de ce qu'il y a sur mon disque dur. C'est déjà rassurant je trouve. Mais force est de constater que ce rangement n'est pas parfait et qu'objectivement, il ne me sert à rien...

Ainsi, avec un seul outil (Lr) tu déplaces tes photos, tu les distribues dans les catégories virtuelles de ton choix etc depuis une interface de Lr.
Seul le point sur ne nom du fichier reste délicat car mesure de sécurité oblige, il est souhaitable de modifier le nom du fichier sur le serveur. Mais ça, c'est le sujet d'un autre débat :-)

Gotcha a écrit:

Ce n'est pas vraiment ce que j'ai dit... au contraire. Je vais plus dans le sens de plg & Co sur ce coup là.
Regardes Eric : si tu arrives à gérer tes photos non plus sur ton disque dur + serveur distant mais uniquement sur ton disque dur. C'est tout de même plus simple non ? ^_^

c'est déjà le cas. J'héberge en interne mes sites web.
Le disque dur de mon serveur est la racine de mon réseau interne... il est la source à partir de laquelle je récupére les fichiers en cas de besoins. Une sauvegarde automatique duplique chaque nuit cette source vers un ordinateur de travail (qui me sers à ne pas utiliser les recource du serveur pour mes traitiements d'images) et un serveur synologie (pour la sécurité).
Alors je comprends aussi que tu te situe pour la très grande majorité d'utilisateur qui sont seul sur une galerie et hébergent en externe, c'est ce qu'il faut faire, tu as raison..

Gotcha a écrit:

Moi aussi j'aime bien ranger mes catégories physiques à l'identique de ce qu'il y a sur mon disque dur. C'est déjà rassurant je trouve. Mais force est de constater que ce rangement n'est pas parfait et qu'objectivement, il ne me sert à rien...

très amicalement, je me permets de m'inscrire en faut.
Il n'est pas question de se rassurer.. j'ai passé l'age.. il est question d'avoir ces dossiers et fichiers classés logiquement (dans mon choix, à la fois par reportage et par ordre chronologique de prise de vues)
La nécessité d'une arboréscence logique s'impose.
Par ailleurs, il n'est pas concevable d'un aspect pratique d'avoir plus de 100 000 photos dans un unique dossier.

Gotcha a écrit:

Ainsi, avec un seul outil (Lr) tu déplaces tes photos, tu les distribues dans les catégories virtuelles de ton choix etc depuis une interface de Lr.
Seul le point sur ne nom du fichier reste délicat car mesure de sécurité oblige, il est souhaitable de modifier le nom du fichier sur le serveur. Mais ça, c'est le sujet d'un autre débat :-)

Tu veux dire, je pense que toutes les photos d'un reportage restent dans un unique dossier source quelque part.. puis que LR exporte virtuellement la selection que l'on veux mettre en ligne..

en remarque préambule, si je souhaite très fort travailler avec LR ou Dijikam, et un module d'upload, il ne faut en aucun cas développer Piwigo et son système de dossiers en se disant que tout le monde fera pareil. La gestion par catalogue n'est pas la panacée.. LR sait concerver les fichiers originaux et stocker virtuellement les éventuelles modifications.. les classements, catalogues etc.. c'est très bien et très pro.. mais assez peu de gens ont idée de ces possibilités et très peu au final travaillent de cette façon., il faut impérativement permettre une gestion simple et minimaliste des photos pour l'utilisateur lambda. Pense aussi au travail collaboratif.. quand plusieurs phtographes mettent en ligne sur une mêm galerie..

Alors.. pour ma part..
1) on fait X photos sur un reportage
2) ces fichiers sont déposés au fur et à mesure dans des dossiers "bruts", et renommés systematiquement.
3) on fait une selection, on conserve en archive les photos non sélectionnées.
4) il convient de garder les fichiers originaux de cette selection non retouchés. donc, on doit dupliquer la selection.
5) il convient d'avoir un dossier avec la selection prète (fichiers éventuelement retouchés, légendés..etc...)

=> à l'arrivée : 1 dossiers avec les archives non selectionnées brutes, 1 dossiers avec les fichiers sélectionés bruts, 1 dossier avec la sélection prète.

=> les dossiers sont nommés de la sorte "yyymmdd_info", et les fichiers,  : "yyymmdd_info_info_x###EF"
le prefix avec la date à l'américaine permet une similitude entre les classement chronologique et alphabétique, "info" représente un numéro de voiture, un nom de lieu, de personne, d'évennement etc.. , "x" une lettre qui correspond a celle d'un sous dossier brut (pour le cas des gros reportages) , "###" represente un numéro de série incrémenté automatiquement lors de renomage de l'ensemble de fichiers bruts. "EF" les initiale du photographe.

Avec ce système
- je n'ai jamais deux fichiers qui portent le même nom
- avec un nom de photo, je retrouve toujours très vite le dossier source avec la selection ou encore le dossier avec l'original, le dossier bruts avec les petites soeurs de cette photo. Je peux donc, sur un coup de fil d'un utilisateur, trouver exactement 3 clics de souris la photo sur mon ordinateur. 
- je peux faire un export d'une catégorie sur un CD rom et l'envoyer...


Mes impératifs
Je me repète encore, pardon.. mais ce sont des priorités non négociables à mon sens.
- dossiers virtuels ou physiques : Il faut que les photos mises en ligne soient contenues dans des dossiers physiques respectant une arborescence de notre choix.
Que, ensuite, cette arboréscence soit reproduite en virtuel afin qu'elle ne soit pas directement accessible pour un visiteurs mal intentioné, ok, oui, je suis d'accord...
- il faut que, dans les dossiers qui contiennent physiquement les fichiers, lors de l'affichage sur la galerie, puis, lors du téléchargement des fichiers HD, ceux-ci soient identifiés et nommés du nom que nous avons choisi, ni plus, ni moins.
Que, pour les mêmes raisons de sécurité, les noms des fichiers, dans l'arboréscence virtuelle, dans les URL, soient cabalistiques, pourquoi pas... quoique.. pour des raison de référencement, il est évident qu'il vaut donner au fichier un nom explicite.


Je comprends ta logique, et elle ne me déplait pas.. de même que plg et Co comme tu dis, non pas tors.. mais moi non plus. J'ose penser que mon avis représente celui de pas mal d'utilisateurs.. Il faut trouver des solutions satisfaisantes pour tous.

mathiasm a écrit:

pLoader stocke ça dans uploads avec sa propre hiérarchie. Rien n'empêche, sans pLoader, d'avoir sa propre hiérarchie physique et qu'elle soit quand même bien intégrée côté cat virtuelles.

oui.. mais je précise, il laisser au webmaster quand il le souhaite, la possibilité de décider de l'arboréscence du dossier qui contient physiquement les images. Pour les catégories virtuelles, elles sont parfaites pour l'affichage et chacun peut les gérer comme il veut, il n'y a rien à changer..


Je suis tétu mais pas obtu, je défends certaines nécessités et une approche "non informaticienne", je ne suis pas contre le progrès, si il y a des solutions techniques et pratiques qui font que l'identification des fichiers demeure possible par tous, que la gestion physique, l'export sont respectés..  je suis à l'écoute, entendrais et accepterais celles-ci.

Nous parlons d'une révolution dans la gestion des dossiers et des fichiers par Piwigo..  malgrès mes propos, comprenez que je suis partant pour la soutenir, je veux juste recadrer les choses, apporter un regard de "candide", j'ai aussi mes contradictions, comme vous sur ce sujet..
Ce mini débat peut aider à y voir clair et troucver les solutions. je l'ai pensé HS un instant, mais non, puisqu'il s'agit aussi de poser les bases téhoriques du module d'export LR :o)


les mots à retenir ?  identification, traçabilité.

merci de votre patience...
amitiés,
éric.

mathiasm a écrit:

pLoader stocke ça dans uploads avec sa propre hiérarchie. Rien n'empêche, sans pLoader, d'avoir sa propre hiérarchie physique et qu'elle soit quand même bien intégrée côté cat virtuelles.

Oui oui on est d'accord.

Mais afin de ne par réinventer un système d'envoi de fichiers, pour le moment je compte sur l'expérience de pLoader.
Plus précisément, se servir de pLoader pour envoyer les fichiers.

Ce n'est pas un point fixé définitivement. Mais ça serait plus simple plutôt que de recommencer un tel système. Bref, là on est déjà dans le cas de la réalisation et non dans l'analyse du besoin/existant.
:-)

En effet, j'ai vu sur le forum EN qu'il était question de revoir un peu la différence entre "catégorie" et "album". Mon Anglais ne me permet pas de discerner s'il ne s'agit que de la sémantique ou bien d'une révolution.

Laisser le choix aux utilisateurs ces bien, mais encore faut-il arriver à ce choix. A l'heure actuelle c'est pLoader ou bien un précédé lourd mais plus pointue et maîtrisable. Donc ce choix est fait en général une bonne fois pour toute par le webmaster. Dans pLoader, là il n'y a plus de choix possible. C'est là que ça ne va pas.

Ok, je suis en train de dérivé sacrément du sujet initiale mais pour arriver à mer, il faut passer par des fleuves, des rivières et des petits filés d'eau.

Nuls doutes que des interrogations au niveau de Piwigo seront à fixer avant de se lancer dans l'étude de faisabilité du module pour Lr. Les débats sont là aussi pour faire avancer les chose :-)



[HS]
Je ne signe pas à chaque fois mes messages par une phrase type : "Cordialement" "Respectueusement" etc mais sachez, cher Eric, que j'ai plaisir à correspondre avec vous, d'échanger de manière constructive et courtoise, de lire vos interventions emplies de sagesse éclairées par le regard d'un professionnel de l'image.
Veuillez agréez patati patata !
Ca c'est fait lol
[/HS]

[HS] ha ha ha ... :o))
disons que je voulais tempérer le côté autoritariste de mes propos par une politesse exagérée... je respecte beaucoup les personnes du teams qui s'impliquent autant pour le bien de tous.[/HS]


oui, j'ai vu le lien, pour le renommage beacoup de programmes font cela très bien maintenant. J'utilise depuis longtemps xnview.. l'adoption de LR correspond au désire de regrouper en un seul programme toutes les manipulations que nous faisons sur nos fichiers; j'en profite pour dire tout le bien que je pense de LR.. mêm si il n'est pas évidement de changer de métodologie de travail.