🌍
Français
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é).
Un peu HS car ça ne fait pas avancer notre problématique mais c'est intéressant de voir comment se passe les chose avec d'autres galeries.
http://www.lemondedelaphoto.com/Le-serv … ,2758.html
Par contre, je sujet consacré semble "buggé"
J'en profite tout me même pour signaler aux personnes intéressées que le cite précédemment cité dispose de tutauriaux pour Lr TRES bien faits !
[/HS]
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.
On fait le addSimple qui fait mouliner le serveur.
Le développeur du plugin d'export aura le choix:
- LR redimensionne et passe le addImage à Piwigo (ex: images RAW)
- LR ne fait rien et passe le addImageSimple à Piwigo (ex: images JPG déjà optimisées par un autre filtre etc)
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 ;-)
topic:16846
PS : j'ai laissé tomber le "pour ou contre", préférant l'approche (plus constructive ?) du pourquoi / comment.
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" :-)
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.
tosca a écrit:
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 ...
Parmi les utilisateurs d'appareil photo numérique, le nombre d'utilisateurs de LightRoom est ridiculement faible. Et c'est normal. La cible pour un logiciel comme LightRoom/Aperture, ce sont les pros, il suffit de regarder la page "Aperture en action" sur le site d'Apple. Et parmi les pros, il y a certainement peu d'utilisateurs de ce type de logiciel. Je rappelle que la "bête" coûte environ 200 euros.
Cela dit, c'est aussi une question de visibilité qu'un plugin d'export vers Piwigo donnerait à Piwigo.
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 ...
Pour revenir sur Lr (Lightroom), le module d'export par contre redimensionnera les photos coté client. Je me vois mal demander aux serveurs de manipuler des fichiers de 50Mo...
@plg : là je passe mes journées à éplucher les tutoriels concernant le travail avec ce fabuleux logiciel qu'est Lr.
Dans l'ensemble il est bien pensé pour peut que l'on prenne le temps de se pencher dessus. Je ne suis pas sûre que sa clientelle soit archi nombreuse 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 lol
(*) Ligne de travail / Processus en ligne
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.
mathiasm a écrit:
Question: Pour le webservice "lourd", cela correspondrait en fait aux fonctionnalités de la page d'upload, non?
Oui, sauf que ce message est antérieur à nos discussion sur la refonte du formulaire web d'ajout de photo dans lequel on conclut que le redimensionnement se fera forcément côté serveur, voir post:129115
Dans la mesure où je souhaite qu'on utilise le même algo dans le formulaire web d'ajout que via l'API (mais ça j'en discuterai en détails sur le forum central anglophone), on va effectivement créer un algo que j'ai toujours refusé jusqu'à maintenant : un algo susceptible de charger le CPU du serveur. Dans la mesure où je vois que d'autres applis le font et qu'elles sont mises en avant par les hébergeurs, je ne vois pas pourquoi nous ne le ferions pas (parce que dans le même temps, l'absence de ce genre de fonctionnalité nous prive de certains utilisateurs...).
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 ?
@plg : ça ne te rappel pas un autre sujet :-D
plg a écrit:
Le principe du "client complexe Vs serveur simple" va bien dans le cas de pLoader par exemple, car pLoader a été conçu et écrit spécifiquement pour Piwigo. Mais dans le cas d'applications existantes comme LightRoom, Aperture, Picasa, F-Spot, Digikam, etc, le principe du "client simple Vs serveur complexe" est largement préférable.
Je n'ai pas encore pris le temps de regarder de très près (je n'ai installé la dernière version de Digikam qu'il y a quelques jours) mais Digikam dispose du module de traitement batch qui peut faire pas mal de choses, dont redimensionnement, renommage, etc. soit tout ou partie des fonctions assurées côté client par pLoader.
Si pLoader pouvait se "brancher en sortie" de cette moulinette pour n'assurer que la partie upload proprement dite, ça simplifierait les choses, non ?
plg a écrit:
Plus j'y pense, plus je me dis qu'il n'y a pas forcément un choix à faire. On pourrait implémenter les 2 dans l'API web de Piwigo. Les applications spécifiques (comme pLoader) exploiteraient le principe du "client complexe" et les plugins d'export dans les applications existantes (comme LightRoom donc) exploiteraient le principe du "client simple". Cela voudrait dire que si tu fais un "export to Piwigo" avec LightRoom, ça va faire ramer ton serveur. Pour piwigo.com, je peux implémenter une mécanique asynchrone pour gérer cela (avec un autre serveur dédié aux resize), mais sur un hébergement "standard", ça ressemble à un nid à problème :-/
C'est un choix du webmestre. Question: Pour le webservice "lourd", cela correspondrait en fait aux fonctionnalités de la page d'upload, non?
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.