Gotcha a écrit:

LR transmet des arguments et des variables à un logiciel tiers [...] pLoader

mathiasm a écrit:

Ah oui, et je plussoie au message de Gotcha. Il me parait plus simple de rendre pLoader "commande-en-lignable" (si ce n'est déjà fait) et que le plugin consiste à invoquer pLoader avec les arguments qui vont bien.

tosca a écrit:

Si pLoader pouvait se "brancher en sortie" de cette moulinette pour n'assurer que la partie upload proprement dite, ça simplifierait les choses, non ?

D'un point de vue architecture logicielle, je trouve ça très moyen (pour ne pas dire "foireux"). En imposant pLoader, ça signifie une énorme contrainte quand même ! pLoader ne s'installe pas partout (non pas à cause de la couche basse de communication avec Piwigo, mais à cause de la couche graphique). ron a déjà un peu travaillé (jusqu'à quel point je ne sais pas) sur la séparation entre l'interface graphique et l'appel à une interface dédiée pour la communication avec Piwigo. Eventuellement, il faudrait que cette couche de communication soit intégrée dans le plugin d'export de LightRoom.

D'ailleurs, cette couche basse de communication existe déjà en tant que proof of concept, et ça s'appelle piwigo_remote.pl, c'est dans le répertoire tools de votre installation Piwigo.

Je demande son avis à ron sur le sujet, mais moi je le dis clairement : je ne suis pas en faveur de telles dépendances. A mon avis, une méthode pwg.images.addSimple qui se charge de faire le redimensionnement, c'est bien plus simple et... à mon avis tous les autres font comme ça. C'est un facteur important car à mon avis ce sont ceux qui ont fait un plugin d'export pour FlickR/PicasaWebAlbum/pbase qui vont aussi faire le plugin d'export pour Piwigo, et donc plus ça ressemblera, plus ce sera facile pour eux et plus on aura de chance que ce plugin existe un jour.

Gotcha a écrit:

Je ne suis pas sûre que sa clientelle soit archi nombreuse mais si on maîtrise bien son "workflow"* Lightroom ...

Tu connais beaucoup d'autres alternatives à Lightroom pour gérer le workflow en question ? en dehors d'Aperture (Mac seulement) ou Digikam ?
En cherchant un peu, je trouve des références à BlueMarine et SmartFlow (projet Microsoft), mais aucun des deux ne parait réellement opérationnel ...

plg a écrit:

tosca a écrit:

Tu connais beaucoup d'autres alternatives ...

La cible pour un logiciel comme LightRoom/Aperture, ce sont les pros ... Je rappelle que la "bête" coûte environ 200 euros.

Il me semble que le besoin existe ... donc il doit bien être couvert par quelque chose.

Pour les professionnels, un outil de ce type me paraît incontournable ; 200 euros passés en frais déductibles du chiffre d'affaire l'année de l'achat, pour un outil de travail utilisé au quotidien, c'est très vite rentabilisé.

En tant qu'amateur, bien avant de me lancer dans la retouche ou la publication on-line, j'ai d'abord eu besoin d'importer / classer / répertorier mes photos, parce que ça devient très vite ingérable sans outil dédié ; d'où le choix, à l'époque, de Photoshop Elements.

En termes organisationnels, je rejoins complètement Gotcha :

Gotcha a écrit:

mais si on maîtrise bien son "workflow"* Lightroom jouera très bien les chef d'orchestre et j'ai bien l'intention que ce chef d'orchestre officie chez moi

Le "coeur" de mon organisation est bien chez moi, en local, avec le logiciel que je considère le plus approprié. La publication sur le web n'est qu'un "output", non structurant dans mon choix d'organisation.

plg a écrit:

Note : ce topic n'est pas "pour ou contre un logiciel pour organiser ses photos en local" :-) C'est un sujet très intéressant cela dit auquel je participerai volontiers dans la section "Hors-sujet" :-)

Monsieur est servi ;-)
[Forum, topic 16846] Organisation/workflow gestion photos, du boîtier à la mise en ligne

PS : j'ai laissé tomber le "pour ou contre", préférant l'approche (plus constructive ?) du pourquoi / comment.

mathiasm a écrit:

On fait le addSimple qui fait mouliner le serveur.[...]

C'est Chinois pour moi ce terme :-(

Je pencherai plus pour faire travailler au maximum Lr qui n'aura plus qu'a transmettre les bons fichiers (voir dans le meilleur des cas une architecture Piwigo toute prête avec thumbnail + pwg_high) et où pLoader se contentera de l'envoie HTTP.

Gotcha a écrit:

mathiasm a écrit:

On fait le addSimple qui fait mouliner le serveur.[...]

C'est Chinois pour moi ce terme :-(

Ce n'est pas très important, c'est vraiment de l'implémentation. Aujourd'hui, pour ajouter une photo, c'est un peu "complexe" (pwg.images.exist + N*pwg.images.addChunk + pwg.images.add) dans l'unique objectif de préserver la bande passante et de fonctionner "à tous les coups" (transfert par petits paquets). Malheureusement, cette complexité est blocante pour la création de plugin d'exports. Par exemple Jeffrey Friedl avec qui j'ai discuté il y a 1 an environ, m'a tout de suite demandé s'il pouvait juste faire 1 appel à l'API et c'est le serveur qui se charge de tout. Même encoder en base64 ça le gênait (et moi aussi, c'est juste que je n'ai pas réussi à m'en passer).

Donc je résume, si on veut simplifier au maximum la création de plugins d'export il FAUT une méthode ultra simple pour ajouter une photo, d'où le pwg.images.addSimple (sauf si on embarque la couche basse de pLoader qui elle gère la complexité).