Matthieu Moy a écrit 3248 commentaires

Les différents prix, c'est selon quand tu commandes. Ceux à 1 449 sont déjà épuisés, maintenant c'est plus cher.

Bah, ça existait déjà dans Darktable 1.4, et sans doute bien avant … (option « spot white balance », je n'ai pas la traduction française sous la main).

Côté ergonomie, c'est clair que c'est assez non-standard. Avant de lire la doc, je trouvais ça pas pratique du tout, mais après avoir lu le manuel, ça va beaucoup mieux en fait :o).

Tu as plusieurs façons de gérer ça :

• Le bouton « effacer » (delete) qui supprime l'image sur le disque

• Le bouton « enlever » (remove), ou touche « Suppr » du clavier, qui enlève l'image de la base de données Darktable, mais la conserve sur le disque

• La croix dans le coin de chaque image en vue « table lumineuse », ou touche 'r' comme rejeter. Ça affecte une note négative à la photo, et on peut ensuite travailler en n'affichant que les images non-rejetées. Si on veut faire du ménage par la suite, il suffit de sélectionner toutes les images rejetées et de les supprimer définitivement avec « effacer ».

Ou pour être plus précis: on doit toujours pouvoir revenir aux données d'origine, au bit près, quoi qu'on fasse dans l'image.

Bah justement non. L'outil « spot removal » ou le retaillage avec « crop and rotate » ne sont pas du tout non-desctructif au sens « bijectif » par exemple. Le fait que de l'information se perde dans le pipeline n'est pas du tout un problème. L'important est que les transformations soient rejouables sur une autre image.

Sinon, c'est Control-e depuis le mode « darkroom ».

Pour résumer, le problème évoqué dans ce lien est que GIMP est destructif, à l'heure actuelle, alors que Darktable est uniquement non destructif

Oui et non. Le problème n'est pas tellement d'être destructif ou non, c'est d'être répétable. Avec Darktable, les opérations faites sur l'image sont faites dans un ordre déterminé par le logiciel (les modules sont appliqués de bas en haut par rapport à l'ordre dans lequel ils sont affichés). Si je joue avec le module contrastes/luminosité/saturation, et qu'après je change le réglage de réduction du bruit, alors Darktable va réappliquer tous les calculs en repartant du RAW, en commençant par la réduction de bruit, même si c'est la dernière opération que j'ai fait.

Ça n'aurait pas vraiment de sens de lancer Gimp dans le flot Darktable : ça me permettrait de faire une modif d'image une fois dans Gimp, mais que se passerait-il si je changeais les réglages côté Darktable après ?

Donc, pour l'instant, le seul flot raisonnable, c'est de bien travailler son image dans Darktable, de l'exporter, et de retoucher le résultat dans Gimp. Si on veut modifier les réglages de Darktable, il faudra refaire le boulot dans Gimp.

Ça pourrait changer avec les prochaines versions de Gimp, qui saura aussi gérer une pile d'effets via GEGL. On peut imaginer d'avoir des opérations faites dans Gimp au milieu du pipeline de Darktable. Mais ça n'arrivera pas demain ;-).

les RAW sont en général en très haute résolution, donc la perte peut être très raisonnable

La perte d'information, ce n'est pas sur la résolution (l'export en .png la conserve sans problème par exemple), mais sur la profondeur des pixels. Gimp utilise pour l'instant 8 bits/pixel/couleur (ça changera dans la 2.10), et Darktable utilise des flottants 24 bits. Pour le résultat final, 8 bits/pixel/couleur est suffisant pour la plupart des utilisations (pour de l'affichage sur un écran lambda, on ne peut pas faire mieux), mais pour les calculs intermédiaires, les erreurs d'arrondis se cumulent, et faire tous les traitements sur 8 bits peut poser problème même pour des non-puristes non-professionnels. L'autre intérêt d'utiliser des flottants est qu'on peut manipuler des valeurs intermédiaires qui débordent de l'intervalle des valeurs représentables (trop blanc ou trop noires), mais revenir dans des bonnes valeurs plus loin dans le pipeline. Par exemple, c'est ce qui permet de retrouver les détails dans des parties un peu sur/sous-exposées avec le module « Shadows and Highlights » de Darktable.

• comme c'est un projet opensource et qu'il est plus difficile "d'imposer" une façon de faire, ils préfèrent tout squasher

Euh, on n'a pas parlé de tout squasher, mais de travailler avec des patchs/patch sets. Ça n'implique pas du tout de squasher quoi que ce soit. Et pour le fait que ce genre de workflow soit utilisé par des gens qui ne savent pas ce que permet Git, rappelons que le développement de Git fonctionne comme ça … ;-).

En fait, Ubuntu n'es pas si loin de ça : les outils de base changent tous les 6 ou 18 mois selon si tu utilises une LTS ou pas, mais certains soft sont mis à jour quand même (par exemple Firefox qui arrive dans les mises à jour stables d'Ubuntu dans les jours qui suivent la sortie de chaque version de Firefox).

Il faut sélectionner les colonnes A et B.
et effectuer le tri selon la colonne A (c'est la première colonne sélectionnée par défaut).
Il ne faut pas toucher à la colonne C.

… et la colonne C sera ajustée automatiquement par LibreOffice
(cf. mon autre message dans ce thread), et ça fout effectivement le boxon dans la colonne C, même si elle n'est pas sélectionnée : les cellules de la colonne C ne pointent plus vers celles de la colonne B qui sont sur la même ligne !

Quand une cellule est déplacée, son contenu ne change pas

Quand une cellule est déplacée, les formules qui utilisaient cette formule sont adaptées.

Si je fais un copier/coller d'une cellule avec des références absolues, ces références absolues ne sont pas changées

Ah, OK, on ne parle pas de la même chose. Si tu copie-colle la cellule qui contient la formule, oui. Si tu déplace la cible de la cellule à coup de couper/coller, la formule est adaptée pour continuer à pointer sur la cellule que tu viens de déplacer. Si tu tries la cible avec un vieux libreoffice, les références ne sont pas ajustées. Si tu tries la cible avec un 4.3, les références sources sont ajustées.

C'est un peu de ça que parle le journal d'ailleurs, si tu lis bien ;-).

sauf que pour un tri ça ne rajoute ni n'enlève rien, du coup ça justifie moins de casser les références

Si tu fais ton tri à la main à coup de couper/coller, les références sont ajustées. Si tu fais ton tri automatiquement, ça parait logique de s'attendre au même comportement.

Maintenant, je suis d'accord sur le fait qu'avoir une option pour permettre aux habitués de l'ancien comportement de le garder aurait été une bonne chose.

Ce que tu décris est un comportement possible, mais pas celui qu'implémente LibreOffice dans la plupart des cas. Si tu écris =B2+1 dans une cellule, et que plus tard tu déplaces des cellules (par exemple, tu coupe B2, et tu colles la cellule en C3) le « B2 » de la formule est ré-écrit (dans l'exemple, il devient C3).

C'est un peu comme la différence entre « cp /tmp/toto.txt . » et « cp ../toto.txt . »

Le fait que la référence soit absolue ou non ne change rien, je viens de refaire l'essai, $B$2 est réécrit de la même manière que B2.

Si tu veux une analogie avec le filesystem, ça serait plutôt inode contre nom de fichier. Le fait qu'on déplace le fichier ne change pas les références aux numéros d'inode.

C'est souvent très pratique (quand on déplace des choses pour la mise en forme, les références s'adaptent toutes seules), et parfois très pénible comme le cas de l'auteur du journal.

À peu près toutes les opérations ajustent les références. Par exemple, si tu supprimes une ligne et que ça décale des cases, les références sont ajustées (et les références aux cellules effacées deviennent invalides). Si tu coupe-colle pour déplacer des cellules, idem. Ça parait assez logique de faire pareil pour un tri.

y a t'il une volonté d'ajouter les fonctionnalités d'Admin Tool sur le tronc commun

Une volonté de ma part, oui ;-). Mais je ne fais pas partie de l'équipe.

J'ai évoqué l'idée au détour d'autres conversations, pour l'instant la réponse est « A discuter. ». Ça fait partie de mes projets de lancer une discussion plus précise et de tenter un patch.

Dans Koken je créé un Set, je le définie comme privé ou public et j'ajoute les photos par un glissé/déposé et voila c'est tout. Certes avec la dernière version de Piwigo et le nouvel uploader c'est faisable […]

Avec Piwigo + le plugin "Admin tools", tu peux par exemple aller à l'endroit où tu veux ajouter des photos dans l'interface publique, puis un clic sur "ajouter des photos" dans la barre de menu ajoutée par admin tools, et tu te retrouves sur la page de l'uploader. Là, tu peux créer un nouvel album ou ajouter les photos dans l'album existant (cf. le screenshot de la dépêche).

Sur la page d'ajout des photos, piwigo te propose de choisir le niveau de confidentialité des photos. Avec ce système, la gestion des droits est faite par photo, avec un système assez primitif (famille, amis, contacts, autres) mais suffisant pour 90% des utilisations et très simple à utiliser. Si tu veux le système plus avancé (permissions par utilisateur, par groupe), il faut passer par les permissions de l'album, c'est quelques clics de plus.

Et oui, maintenant c'est juste un glisser-déposer pour envoyer les photos ;-).

Il y a parfois un peu plus de clics que nécessaire pour faire des choses simples, mais c'est quand même très raisonnable.

Sinon, je vais peut-être dire un truc bête, mais si je lis bien http://piwigo.org/forum/viewtopic.php?id=18008, la raison principale était que ça demandait du travail que les développeurs n'étaient pas prêts à fournir (je suppose que tu es le « Nicolas » mentionné dans le message ?). Si le travail est maintenant fait de toutes façons (par toi), ça me paraîtrait intéressant que les autres en bénéficient.

Je suis assez d'accord avec Pierrick sur le fait que ce n'est pas une fonctionnalité majeure pour les utilisateurs (encore que, le support SQLite est sympa pour quelqu'un qui veut se simplifier la vie avec les backups, une arborescence à sauvegarder et tout est dedans), mais je suis aussi d'accord avec toi sur le fait qu'exposer le code à plusieurs environnements aide à trouver des bugs.

Enfin, je dis ça d'un point de vue parfaitement naïf, tu connais mieux la question que moi.

Et comme tu l'as indiqué, il n'y a pas de vérification des droits dans i.php donc si on a une connaissance qui diffuse cette URL (intentionnellement (Facebook, Twitter,…) ou pas MSN, Hangout,…) elle peut devenir public.

Attention, l'URL « confidentielle », c'est celle du fichier .jpg, pas l'URL de la page web qui permet de la visualiser (i.e. si tu partages http://demo.piwigo.com/picture?/115/category/birthday-party, tu restes en sécurité, il faudrait que tu partages une URL du style http://demo.piwigo.com/uploads/v/8/z/v8z3358vr7/2010/06/25/20100625235929-97d0f688.jpg pour prendre un risque). Le partage « par mégarde » me parait peu probable. Pour le partage intentionnel, ça n'est pas beaucoup plus difficile de partager l'image que de partager son URL.

Et ce n'est pas du tout spécifique à piwigo. Au moins Google+ et Facebook font pareil (ce qui leur permet d'avoir les images sur des serveurs optimisés pour les pages statiques, et d'utiliser des CDN pour que les téléchargements se fassent depuis des serveurs proches de l'utilisateur).

Ça ne veut pas dire qu'il n'y a pas de problème du tout, mais c'est quand même beaucoup moins problématique que ça pourrait en avoir l'air.

Dans le cas de Piwigo, on devrait pouvoir s'en sortir avec mod_xsendfile sous Apache (https://www.tn123.org/mod_xsendfile/) quand il est présent pour ne pas plomber les perfs.

Sur un petit écran, je veux bien croire. Mais le mieux que j'arrive à obtenir même avec gThumb+, c'est un <div> de 1120 pixels de large. C'est moins de la moitié de la largeur de mon écran.

Et pour l'affichage de la photo elle-même, gThumb ne change rien, les photos sont toutes petites (avec une lightbox pour agrandir, mais pourquoi ajouter une étape ?).

une fonction qui pourrait être pratique c'est d'avoir une interface dans l'admin où on choisi un compte et on voit tout ce qu'il peut voir de manière concise (la liste des chemins de photo qu'il peut voir par exemple).

Tu as à peu près ça avec admin tools : une fois activé, tu as un menu qui te permet de voir la galerie comme la verrait un autre utilisateur :

Tu peux voir exactement quelle photo il voit, et tu peux naviguer dans l'arborescence des albums pour voir lesquels il peut voir. Tu peux aussi ouvrir la page « photos récentes » pour voir si ce que tu viens d'ajouter est visible ou pas.

Par rapport à ce que tu imagines, il manque sans doute la concision.

J'allais répondre la même chose. Pour moi, le problème d'ergonomie de Piwigo, c'est que les trucs bien et pratiques sont dans des plugins désactivés par défaut, et que le débutant doit trouver ceux qui vont lui faciliter la vie parmi une centaine d'autres.

Mais effectivement, une fois le choix de plugins fait, c'est quand même agréable à utiliser.

Je vois que tu travailles aussi sur des tests automatisés, du nettoyage de code, et d'autres fonctionnalités que Piwigo n'a pas. Rien que les tests, c'est vraiment bien, je pense que c'est un gros manque de Piwigo. J'aimerais vraiment avoir ça remonté en upstream, perso.

Est-ce que le but est de fusionner un jour avec Piwigo ? Si non, quelle est la raison pour avoir forké au lieu de contribuer directement ?

Le préchargement avec Piwigo, certains thèmes le font, mais pas tous.

(et on tombe pile sur un des reproches que je fais au système de thèmes : on devrait choisir un thème pour son apparence, pas pour des fonctionnalités « sous le capot » comme le préchargement)

Oui. Il y a des choses que j'aime vraiment bien dans ce thème, mais je n'ai pas réussi à le faire marcher avec le plugin Automatic Size. La fonctionnalité numéro 1 pour moi, c'est d'utiliser tout l'espace disponible pour afficher la photo par défaut, et la majorité des thèmes est très mauvaise sur ce point.

Sinon, je ne suis pas fan du texte en rouge par défaut, mais ça, c'est configurable.