Je cherche un programme pour gérer mes photos (plus de 5000 et ça augmente toujours...).
J'aimerai me baser sur un système de tags pour gérer toutes mes photos (tags sur des photos et tags sur tags) sinon niveau transformations pour les photos je pense que je n'en demande pas trop, juste la réduction des photos pour la rapidité des transferts et la rotation pour remettre les photos dans le bon sens !
Un mode pour tagger de nombreuses photos rapidement est aussi le bien venu au vu du nombre de photos non taggées !
J'ai fait une petite recherche sur ce qui existe mais tous ce qui existe est soit avec une interface web qui est donc assez limitée (comprendre : ne fait pas tout ce que je veux), soit est un "vrai" programme mais qui n'est accessible que depuis le PC où le programme est installé (KPhotoAlbum à l'air intéressant mais n'est uniquement sous Linux et pas en mode réseau). Le problème c'est que je voudrai avoir un interface assez complète pour gérer mes 5000 photos et que chaque PC de mon réseau puisse y accéder.
J'ai donc penser créer un programme qui puisse me faire tout ça. Voici en vrac ce que j'ai pensé faire :
- Système serveur qui gère toutes les photos avec un client qui s'occupe uniquement de l'interface utilisateur
- Pour le client j'ai pensé à Python + WxPython car c'est assez simple et c'est portable
- Pour le serveur j'ai pensé à PHP car je le connais déjà un peu et que c'est assez performant
Maintenant il y a des choses que j'aimerai savoir :
- Est ce que je suis passé à côté programme miracle ?
- Existe-t-il quelque chose (surtout PHP) qui pourrai m'éviter de tout coder à partir de zéro ? (en libre évidemment...)
- Est ce que certaines personnes sont intéressées par ce projet ?
Journal Gestion des photos
20
juil.
2006
# Répertoire partagé
Posté par golum . Évalué à 4.
Ton besoin est pour un réseau local donc tu n'as pas besoin d'un interface Web.
[^] # Re: Répertoire partagé
Posté par Yusei (Mastodon) . Évalué à 3.
[^] # Re: Répertoire partagé
Posté par Sylvain Rampacek (site web personnel) . Évalué à 3.
que font ces applications si plusieurs personnes attaquent le répertoire de photo en même temps ??
pour Picassa, ce n'est pas géré si mes souvenirs sont bons !
[^] # Re: Répertoire partagé
Posté par golum . Évalué à 3.
Pour les photos d'abord:
Si tu modifies une photo en même temps qu'un autre utilisateur le dernier qui enregistre ses modifs a gagné.
C'est une des motivations des outils de gestion de versions avec l'historique des modifications.
En réponse 2 approches:
Soit on locke le fichier acceder le temps de la manip (schema d'accès concurrent pessimiste)
Soit on n'empêche la sauvegarde tant que la réconciliation avec la version editée en concurrence n'a pas été faite au moyen d'un merge (schema d'accès concurrent optimiste)
Autant c'est simple pour des fichiers texte, quoique (http://revctrl.org/CategoryMergeAlgorithm ) autant ca me parait beaucoup plus compliqué pour des photos.
Ca pourrait être possible avec les métadonnées (tags, ...) mais sur l'image en elle même.
AMHA les soft multi-utilisateurs web based ne traitent pas mieux le pb (c'est peut être pour ca qu'il n'en existe pas à ma connaissance).
Dans ces soft le verrou est permanent car seul le propriétaire de la photo peut la modifier.
Pour des softs natifs, il suffit donc que l'accès en ecriture soit autorisé juste pour le owner (droits unix).
Pour les répertoires c'est le premier qui a parlé qui gagne.
Ce n'est pas un pb en soi. Tu ne vois plus tes photos au bon endroit donc tu raffraichis ta vue dans ton appli.
Pour Picasa, le problème c'est plutôt qu'il gère ca dans une base de données (propre à chaque user). Si tu veux partager ton travail, il faut exporter et réimporter.
Mais pour d'autres softs qui modifient les fichiers dans les répertoires (comme Jbrout, AlbumShaper, ...) ca ne pose pas de pbs insolubles.
[^] # Re: Répertoire partagé
Posté par Sylvain Rampacek (site web personnel) . Évalué à 2.
Mais prenons le cas où l'on conserve la dernière modification : deux utilisateurs ouvre le même album, un des utilisateur décide de mettre à jour tous les commentaires de l'album puis valide et l'autre utilisateur modifie un seul des commentaires et valide après le premier... si tout le travail du premier utilisateur est perdu sans avertissement, ça fait mal !! (bon, si c'est juste une photo, passe encore... mais plus...)
Et le problème de la plupart des outils non prévus pour travailler dans un environnement multi-utilisateurs, c'est qu'ils écrasent purement et simplement ! sans regarder si le fichier a été modifié entre-temps ! et le tout sans aucun avertissement...
Je ne parle pas non plus des problèmes qui peuvent arriver sur un réseau (coupure pendant l'enregistrement, etc...).
[^] # Re: Répertoire partagé
Posté par golum . Évalué à 2.
Et le fait de tagger des photos et de pouvoir les organiser relève plus de la gestion que de l'affichage ou de la publication.
http://linuxfr.org/~z0rglub/6875.html
Tu as donc eu raison de le citer même s'il ne correspond pas exactement au besoin de l'auteur du journal.
Mais quitte à autoriser l'organisation pourquoi ne pas mettre à disposition un plugin de retouche plutôt que d'en repasser par un autre outil.On peut toujour utiliser Gimp mais bon c'est un peu lourdingue de retrouver la photo dans ses répertoires de lancer Gimp alors qu'on vient de juste s'apercevoir qu'on avait pas remarqué que les yeux de son boutchou étaient rouges ou que les photos de la maison sont à l'envers.
En plus Si tu héberges ca sur un site il faut relivrer les photos.
Essayez Flickr pour comprendre.
[^] # Re: Répertoire partagé
Posté par golum . Évalué à 2.
http://linuxfr.org/comments/736018.html#736018
C'est l'inconvénient des onglets quand on fait pas gaffe
# Re-inventer la roue
Posté par Philippe M (site web personnel) . Évalué à 4.
- Catégories n niveau;
- Tags;
- Commentaire;
- Notation;
- Gestion de catégories physiques et catégories virtuelles.
En plus c'est rapide, facile à mettre en place, y a des mod existant, des thèmes et templates différents.. Et je sûr d'en avoir oublié depuis la sortie de la version 1.6.
Born to Kill EndUser !
[^] # Re: Re-inventer la roue
Posté par golum . Évalué à 3.
La retouche d'image n'est pas prévue.
Je ne crois pas que la rotation d'image soit possible avec.
La retouche des yeux rouges encore moins.
L'equipe de dev s'est clairement prononcé là dessus: pas de fonctinnalités de retouche
http://linuxfr.org/comments/732296.html#732296
Je l'ai évalué récemment en 1.6 et franchement il ne m'a pas emballé en terme d'egonomie.
En plus certains thèmes font disparaitres des fonctionnalités (impossible de supprimer une photos d'un dossier), son utilisation est relativement complexe (surtout pour des néophytes en informatique).
Celui qui me parait le plus interessant actuellement est Linpha:
http://linpha.sourceforge.net/wiki/index.php/Main_Page
http://linpha.sourceforge.net/wiki/index.php/Features
Surtout avec la gestion des utilisateurs avancés à venir (même si ca ne concerne pas l'auteur du journal)
http://linpha.sourceforge.net/wiki/index.php/LinPHA2
[^] # Re: Re-inventer la roue
Posté par Philippe M (site web personnel) . Évalué à 2.
Le seul à ma connaissance est le template Zen, mais une version Zen advanced est en cours il me semble. Le but de ce template est d'avoir un affichage qui montre uniquement les photos avec le moins de "polution" autour. Pour la gestion des fichiers, je suis du même avis que l'équipe de dev, ce n'est pas à une galerie de gérer la suppression des fichiers.
La partie la plus "compliqué" est l'ajout de photos. Il doit se faire obligatoirement par FTP, d'un autre côté avoir une interface html qui envoie photo par photo, voir dans le meilleur des cas 5 par 5, c'est pas top quand tu dois ajouter 50 photos.
Ce que je trouve qu'il manque vraiment, c'est une vrai gestion des droits, mais c'est en cours de discution sur le forum, donc peut être qu'on l'aura pour la version 1.7 qui d'après ce que j'ai lu est prévu dans environ 6 mois.
Après c'est a vous de voir entre une galerie qui gère correctement l'affichage ou une appli qui tout mais pas completement (pas la peine de dire les deux serait le top, c'est un rêve).
Une fonction que je trouve super pratique, c'est l'authentification externe. Imaginé que vous avez un forum avec tout un tas de comptes utilisateurs. Dans un cas normal il faudrait que chaque personne recréé un compte sur la galerie. Avec PhpWebGallery, pas la peine il est prévu une fonction pour faire le lien entre le forum et la galerie. Ce qui permet d'avoir une seule gestion des utilisateurs.
Born to Kill EndUser !
[^] # Re: Re-inventer la roue
Posté par Thomas Douillard . Évalué à 4.
C'est un point de vue d'informaticien/développeur, ça. D'un point de vue utilisateur, ce qui importe c'est de pourvoir faire facilement et ergonomiquement ce qu'il veut. Donc en particulier dans un soft dont le but est la "gestion de photo", il me parait pas anormal qu'on puisse y retoucher des photos sans sortir et apprendre The Gimp, surtout si c'est des retouches basiques.
La modularité, un outil pour chaque tâche, c'est très bien, mais faut pas oublier qu'un peu d'intégration derrière pour obtenir des softs efficaces, c'est pas mal non plus, surtout dans un soft comme ça ou la facilité d'utilisation, l'efficacité vont faire la différence.
[^] # Re: Re-inventer la roue
Posté par Philippe M (site web personnel) . Évalué à 3.
Born to Kill EndUser !
[^] # Re: Re-inventer la roue
Posté par golum . Évalué à 2.
C'est vrai que s'il en était autrement on ne parlerait pas de "Galerie"
[^] # Re: Re-inventer la roue
Posté par Philippe M (site web personnel) . Évalué à 2.
Born to Kill EndUser !
[^] # Rectificatif
Posté par golum . Évalué à 2.
Je présente mes excuses à l'équipe de phpWebGallery.
Je ne l'avais pas evalué car je l'avais ecarté d'office étant donné qu'il ne correspond à mes besoins (cf.lien précedent post) et en tant que simple galerie il est ma foi plutôt bien fichu et réactif.
Mes critiques s'adressaient en fait à Gallery2 qui me donne vraiment l'impression d'une usine à gaz
http://gallery.menalto.com/
[^] # Re: Rectificatif
Posté par Philippe M (site web personnel) . Évalué à 0.
Born to Kill EndUser !
[^] # Re: Re-inventer la roue
Posté par nicoprog . Évalué à 1.
[^] # Re: Re-inventer la roue
Posté par golum . Évalué à 3.
[^] # Re: Re-inventer la roue
Posté par plagiats . Évalué à 1.
[^] # Re: Re-inventer la roue
Posté par nicoprog . Évalué à 1.
Mais j'avoue que pour mon utilisation, un classement hierarchique ferait très bien l'affaire
[^] # Re: Re-inventer la roue
Posté par Philippe M (site web personnel) . Évalué à 1.
Born to Kill EndUser !
# JBrout
Posté par Bibinsa . Évalué à 7.
Son auteur devrait sûrement venir faire un petit commentaire à ton message car il passe de temps en temps sur linuxfr.
JBrout peut être aussi bien utilisé sur Windows que sur Linux.
Il a l'avantage d'être rapide (voir très rapide quand on le compare aux autres) et d'insérer les tags dans les photos (au bon endroit si j'ai bien pigé...), donc pas de problèmes pour utiliser ce soft sur différents ordinateurs avec des photos partagées sur le réseau.
Son module de recherche est assez bien pensé, on peut rechercher par date, tag, ...
Voilà, voilà, un petit tour sur http://jbrout.python-hosting.com/wiki/WikiStart
Le screenshot : http://jbrout.python-hosting.com/attachment/wiki/WikiStart/s(...)
[^] # Re: JBrout
Posté par manatlan (site web personnel) . Évalué à 5.
merci pour la pub, et le commentaire ...
Cependant, le screenshot est un peu vieux, et ne correspond pas tout à fait à la version actuelle ... voilà un plus récent : http://jbrout.free.fr/gfx/capture.jpg
(le listview des thumbnails est plus moderne, merci fred)
pour compléter:
Jbrout stocke effectivement les tags dans les tags keywords/IPTC ... les commentaires dans le "jpeg comment" (plus utilisé que la description iptc) ... la rotation est lossless grace à jpegtran.
Jbrout utilise le filesystem comme espace de stockage. Un album est un répertoire, et par conséquent un album peut contenir des sous albums. Les commentaires sur les albums sont stockés dans un fichier txt à la racine du repertoire.
Jbrout n'utilise donc pas de BDD, et stocke donc les infos dans les photos/répertoires (garantissant la perennité des saisies), dans le filesystem. Mais gère à côté un fichier XML uniquement pour pouvoir faire des recherches très rapides ! Je vais bientôt dépasser les 40000 photos, et ça bronche pas encore ...
et jbrout possède un système de plugins, qui permettent d'exporter ses photos (generer une gallery html, exporter/redimensionner pour de futurs transfert, ou carrément faire office de serveur web d'appoint pour vite présenter ses photos à un tiers)
Comme dit bibinsa, c'est également en python, et donc portable (quoique la version win, je ne la package plus trop, car je ne boot plus dessous ;-). Jadis, c'était en python + wxpython, mais ça posait pas mal de problème de portabilité win/linux dès que je tentais de sortir des sentiers battus. Maintenant, depuis la série 0.2.X, c'est du pygtk, et donc, ça fonctionne à l'identique qqsoit la plateforme. (mais je perds la plateforme mac, sans x11)
Par contre, tous les devs pythons sont les bienvenus dans jbrout ;-)
[^] # Re: JBrout
Posté par nicoprog . Évalué à 2.
Sinon pour tagger on est obligé d'utiliser le drag'n'drop ?
[^] # Re: JBrout
Posté par manatlan (site web personnel) . Évalué à 2.
il y a un XML par user ... ( dans son home)
Jbrout n'est pas particulèrement développer pour le multi-user. Mais les xml se mettront à jour, dès qu'une opération est réalisée sur une photo, ou qu'un refresh est initié sur un album.
Dans tous les cas, il n'y a pas de risque de compromettre ses données.
Pour le tagguage, c'est uniquement au drag'n'drop (je ne vois pas de façon plus simple ?!)
de plus, dans jbrout, la multi-selection, que ce soit des tags ou des photos, peut être faites en cliquant avec la molette (héritage du superbe rox-filer) ... (pas obliger d'utiliser shift/control)
du coup, tu peux tagguer tes photos très rapidement, en buvant même une kro dans l'autre main !
[^] # Re: JBrout
Posté par nicoprog . Évalué à 1.
- Après la sélection d'une ou plusieurs photos, des cases à cocher apparaissent à coté de chaque tag dans la liste, il suffirait de cocher les bonnes cases pour tagger.
- Comme ci-dessus, mais avec des racourcis claviers que l'on pourrait définir (idéalement juste une lettre sans Ctrl ni Alt) qui permettent d'être plus efficasse sur les tags qui reviennent souvent, comme par exemple les personnes.
Ça à l'avantage d'économiser les déplacement car :
- un drag'n'drop = appuyer + déplacer + relacher
- un clic = appuyer + relacher
- touche clavier = pas de déplacement de souris et pas besoin de "viser" (utile si tu as abusé de la kro :-) )
Enfin je pense surtout qu'on a pas la même façon de procéder, à mon avis tu dois te dire "À quelle photo je mets le tag toto ?" et là tu sélectionnes toutes les photos que tu veux et tu mets à toutes le tag toto. Alors que moi j'aurai plutôt tendance à me dire "Quels tags je mets à cette photo ?" et donc je fait tous les tags d'une photos et je passe à la suivante.
[^] # Re: JBrout
Posté par manatlan (site web personnel) . Évalué à 1.
quant à ma manière de tagguer, je fais clairement les 2 ...
- soit je selectionne qques photos, puis y d'n'd les tags
- soit je selectionne plusieurs tags, puis d'n'd sur une photo
et il m'arrive fréquemment de selectionner plusieurs photos, et y d'n'd plusieurs tags en une fois ...
non tout ça est bien pensé pour aller au plus vite ...
le coup de touches pour les tags, ça me plait bien ... car effetivement, sur 70% de mes photos, j'ai qques tags qui reviennent très souvent (ma fille, ma copinne, par ex.), et du coup, ça pourrait carrément le faire !
[^] # Re: JBrout
Posté par manatlan (site web personnel) . Évalué à 1.
il suffit d'associer une touche à un tag, dans le fichier ".jbrout/tags.xml"
exemple :
ursula
à transformer en
ursula
ainsi, dans jbrout, on selectionne plusieurs photos, et on appui sur "u", et ça mettre le tag ursula sur les photos selected
evidemment, pour l'instant c light (et il faudra une interface de gestion/association)
ça ne doit prendre que les touches ascii, je pense ...
mais ça reponds déjà à 95% de la problématique ...
[^] # Re: JBrout
Posté par nicoprog . Évalué à 1.
Sinon pour la sélections de tous les tags puis le d'n'd je n'y avait pas pensé ! (je d'n'd bêtement les tags un par un !) mais effectivement ça remplace les checkbox !
[^] # Re: JBrout
Posté par manatlan (site web personnel) . Évalué à 1.
exemple :
<tag>ursula</tag>
à transformer en
<tag key="u">ursula</tag>
sinon, dans le svn, il affiche maintenant à coté des tags (dans le treeview), la touche de raccourci ....
[^] # Re: JBrout
Posté par Bibinsa . Évalué à 1.
# Commentaire supprimé
Posté par Anonyme . Évalué à 6.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: a quand une normalisation?
Posté par manatlan (site web personnel) . Évalué à 6.
Ces 2 systèmes sont en concurrence, et stocke les infos dans les photos. IPTC est assez vieux, et pas mal utilisé ... et XMP, c'est iptc en xml dans la photo (soutenu pas adobe).
Parmi les logiciels que tu cites, le seul qui tague en tentant d'utiliser un standard nativement est jbrout, avec l'iptc ;-). ça commence à peine à venir dans les autres.
Faire un standard pour les BDD n'est pas la solution, sachant que l'info DOIT etre stocké DANS la photo ! Maintenant, il faut choisir IPTC ou XMP.
Jbrout fait de l'iptc, car c'est les seuls api que j'avais pour ça ;-)
Si on me donne des bindings python sur XMP, moi je les intègre vite fait dans jbrout, et je gère les 2 ;-)
Pour l'anecdote, avant d'avoir les bindings python sur iptc, je stockais déjà les tags dans la photos, dans les "jpeg comment", avec les version 0.1.X ... et avec la version 0.2.x, j'avais ecrit une procédure de migration des tags du jpegcomment vers keywords/iptc ...
si xmp s'impose, j'aurai aucun prob à faire migrer de iptc à xmp
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: a quand une normalisation?
Posté par golum . Évalué à 3.
IPTC et XMP ne résolvent pas tout. Chaque logiciel stocke ses propres données et elles ne sont pas toutes exploitables par un autre et ce quelque soit la méthode de stockage.
Contrairement à toi je considère que l'info ne DOIT pas être stockée dans la photo :)
Je n'ai pas envie de polluer ma photo avec des infos inutiles quand je veux l'envoyer à un copain par mail ou la diffuser sur le net. Ou alors je dois utilser une fonction d'export exactement comme les autres logiciels.
Rien n'empêche de s'accorder sur un standard d'échange comme XBEL pour les bookmarks, XMI pour les modèle UML, OpenDocument, .... Avec XMPP ou IPTC il faut s'accorder sur le formalisme dans le champ libre et le pb reste entier.
Chaque logiciel doit fournir une fonction d'export/import qui n'interprète que les balises qu'il sait traiter pour récupérer un maximum d'info.
De cette façon on peut tout à fait stocker les méta-données dans une base de données et assicier un hash key à chaque fichier.
Ou mieux associer les métadonnées avec les photos grâce à un filesystem qui permet de les stocker. Ca ne manque pas sous Linux.
[^] # Re: a quand une normalisation?
Posté par manatlan (site web personnel) . Évalué à 2.
C'est des points de vue qui méritent d'exister.
Il est evident qu'on ne peut pas tout mettre dans iptc ou xmp (quoique techniquement xmp, qui est du xml, permet de mettre tout et n'importe quoi, là où IPTC a sa structure figé). Si un prog doit garder des caractéristiques d'affichage d'une image, là oui : c'est une info perso, il doit la stocker en base, et non dans la photo.
Si c'est un tag, un commentaire : il faut le mettre dans la photo !
On est d'accord ...
Mais le temps d'essayer (et d'avoir les moyens) de normaliser cette BDD, on sera plus là ;-) ... (iptc a au moins 10ans, et xmp : 4 ans)
Ce n'est de loin pas la meilleure soluce. Le top serait le filesystem pour moi.
(J'ai déjà tenter de transformer jbrout en une extension nautilus, mais je n'ai pas plus pousser (mais ça doit être faisable), avec inotify et cie)
Si j'ai développé jbrout, ce n'est pas pour en faire un programme qui va perdurer toujours, ou devenir la référence ... c'est uniquement pour pouvoir gerer mes photos en tentant de respecter le peu de standards, en attendant mieux ...
Dès qu'un programme fait plus que jbrout, et respecte des standards qui me vont, je n'aurai aucun prob à basculer dessus...
Et je ne desespere pas voir un jour nautilus utiliser les tags IPTC des clichés pour nourrir ses métadonnées ...
La base de données a énormément d'inconvénients. (si tu déplace/supprime/renomme des fichiers, en dehors de ton programme, tu peux mettre à mal ta bdd, ton programme, ....)
Tout en sachant qu'actuellement, et encore pour longtemps, ces bdds ne sont pas encore compatibles inter-programmes...
Tout ça pour moi, pour l'heure, est plus que redhibitoire !
(maintenant chaque prog peut incorporer un plugin d'export vers une autre bdd, certains ont déjà commencé je crois savoir)
Jbrout fait un peu les deux, le filesystem et son xml ...(et possede un export qui tue les tags iptc ;-) )
détruire le XML n'est pas grave, il peut le reconstruire from scratch (tout étant dans le FS) ... déplacer des photos/répertoires d'un autre programme ... pareil, rien n'est perdu, faut juste raffraichir ...
Mais comme dit, jbrout ne gère pas grand chose (le minimum syndical à mes yeux), à part les dates exif, les tag iptc, les comment jpeg ... rien que des infos qui ont leur place DANS la photo...
[^] # Re: a quand une normalisation?
Posté par Bibinsa . Évalué à 2.
Mais c'est vrai que le débat peut exister, trop de tags dans une photo qui s'échange peut noyer l'information... Ca se tient...
En tout cas l'extension nautilus j'attends ça avec impatience !!
[^] # Re: a quand une normalisation?
Posté par manatlan (site web personnel) . Évalué à 1.
je n'ai pas dit que j'allais le faire ... je n'ai pas assez le niveau pour rentrer dans gnome ... désolé
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: a quand une normalisation?
Posté par golum . Évalué à 2.
En stockant les métadata dans les propiétés du fichier au niveau du fs tu ne perds pas ces infos même en cas de déplacement ou de renommage. Ton soft ne conserve trace (dans une bdd :) que de l'id du fichier (inode). Avec inotify ou uns sytème de notificcation natif tu prends en compte les modifs qui peuvent affecter ta bdd et tu n'est plus obligé de stocker des infos non pertinentes dans les photos.
Sans fs approprié tu peux t'en sortir pour detecter les modifs sur les fichiers ou ses déplacements (conserver le hash et l'inode du fichier) ou en mettant en place un système de lock sur les fichiers.
Par contre l'avantage de la BDD est quand même l'accès concurrent et donc la gestion multi-utilsateur prise en charge de façon plus tigoureuse.
Pour l'interopérabilté, le but du jeu est d'avoir un format de fichier intéropérable pas de prendre en charge les imports/exports vers toutes les bases de données
[^] # Re: a quand une normalisation?
Posté par André Rodier . Évalué à 3.
J'utilises une fonction de hachage MD5 ou SHA1 pour générer une sorte « d'empreinte digitale » de chaque photo. Pour éviter les collisions ( peu probables, mais bon ) je rajoute la taille du fichier contenant la photo.
Cette empreinte numérique, sert ensuite de base à n'importe quel système de stockage : base de données, fichier xml, système de fichier, etc...
L'avantage : une image, que tu envoies sur internet, que tu récupère plus tard, aura la même empreinte, tant qu'elle n'est pas modifiée. ( ce qui peut être un inconvénient )
Bildo est une galerie photo PHP, qui utilises ajax on non.
Compatible Firefox/Opera/Konqueror/MSIE, ...
J'utilise un système de plugins, qui permet de gérer les relations entre les photos et les tags, avec la technologie qui convient au site : système de fichier simple, xml, sqlite, mysql, etc...
Les tags ne sont pas encore intégrés, mais cela devrait pouvoir se faire en une journée, sans souci.
La rotation de photo est quasiment terminée, avec du code simple PHP.
La retouche d'image est prévue, avec php-imagick ou autre.
Voilou voila.
Si tu es intéressé par une démo, je peux t'envoyer les identifiants pour l'accès à l'interface d'administration de la version en cours de développement.
Voilou.
# Retouche sur format RAW
Posté par brunus (site web personnel) . Évalué à 2.
Pour ceux qui possèdent des appareil capable de stocker du RAW :
http://www.volkergilbertphoto.com/articles.htm > différents articles sur le format RAW.
Un soft pour browser/retoucher le RAW sous Linux.
http://www.sonic.net/~rat/lightcrafts/
# Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: bins
Posté par nicoprog . Évalué à 1.
# PHP
Posté par Eric P. . Évalué à -4.
Tiens, c'est la premiere fois que je vois les mots PHP et performant dans la meme phrase :-)
Excusez l'absence d'accents dans mes commentaires, j'habite en Australie et n'ai pas de clavier francais sous la main.
# noofs
Posté par Philippe Mironov (site web personnel) . Évalué à 2.
C'est un systeme de fichier en espace utilisateur (il utilises FUSE quoi) qui utilises une base de donnée (actuellement mysql et postgresql de supporté) comme backend de stockage, ce qui permets de faire des trucs de malades. C'est winfs mais en linux, avec un vrai fs en db .. pas comme kat ou autre qui ne sont que des indexeurs ... là tu peux très bien faire un dossier virtuel etc...
La chose étant en base de donnée tu peux utiliser ça dans un reseau (local ou non) sans soucis et sans avoir besoin de logiciels particuliers... à mettre en commun partout...
La chose étant en base de donnée toutes les recherches les repertoires virtuels etc sont extremement rapide.
C'est franchement bleufant.
Sinon ce que je fais à la maison c'est un export nfs + digikam qui utilises directement le dossier mounté... ansi j'importe, je class, je modifie n'importe quelle photo de n'importe quel poste à la maison... me suffit de mounter le volume nfs et de lancer digikam ... Après je ne crois pas que digikam geres le tagging avancé (mais tu peux taguer très simplement quand même)..
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -1.
Ce commentaire a été supprimé par l’équipe de modération.
# MaPiVi
Posté par Mailik . Évalué à 1.
http://mapivi.sourceforge.net/mapivi.shtml
# i
Posté par Boa Treize (site web personnel) . Évalué à 4.
Sources : http://trac.delaunay.org/browser/srv/www.delaunay.org/antoin(...)
Le code est très léger, facile à comprendre, et fait déjà beaucoup de choses. Je ne pense pas qu'il soit trop compliquer à adapter si ses capacités te semblent insuffisantes.
Techniquement, c'est une application web écrite en Python au moyen du framework web.py.
[^] # Re: i
Posté par golum . Évalué à 2.
Le système de tag qu'on peut affiner.
Les description avec des mots clé à la wiki.
Un thème sobre mais propre.
Python powered
...
Il manque quand même un peu de documentation.
Sais-tu si il y'a un tutoriel d'install quelque part. Parce que vu tous les composants que ca requiert ca n'a pas l'air trivial.
Y a t'il une interface d'admin pour uploader les photos et les tagger ?
Il se pose aussi la question de l'hébergement étant donné que c'est du python.
[^] # Re: i
Posté par rouadec . Évalué à 3.
une fois web.py installe il faut dezipper ibrouteur quelque part, installer/configurer apache avec fastcgi et adapter le fichier config.py (et indexbuilder.py si vous decidez de stocker vos infos de maniere differentes).
pas d'interface d'admin pour le moment, tous les tags sont dans les fichiers/noms des fichiers/repertoires (la db en est elle meme ne sert qu'a accelerer et facilite les recherches)
herbergement sur http://webpy.infogami.com/hosts
thanks for the praise ;)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.