Cet article se destine avant tout aux mêmes personnes que moi, pour leur éviter de longues recherches et différents tests. N'hésitez pas à le commenter pour y apporter tout complément d'informations.
Voici le résultat de mes recherches :
- Traitement des RAW
- Bibble (propriétaire)
- Raw Therapee (libre mais moins complet [NdM : Raw Therapee ne semble pas libre du tout au contraire de ce qui a été publié initialement.])
- Bibble (propriétaire)
- Retouche d'images
- The GIMP
- The GIMP
- Gestionnaire d'images (chacun ayant ses avantages et inconvénients)
- F-Spot
- digiKam
- F-Spot
Ces jours-ci je me suis donc penché sur ceux qui sont disponibles pour gérer mes photos avec Linux. Étant passionné de photographie, mes exigences étaient simples mais précises. Il me fallait trouver un ou plusieurs logiciels pour gérer l'ensemble de mon flux de travail, du développement à la gestion de la bibliothèque, en passant par la retouche d'images.
Je me suis alors mis à la recherche des logiciels parfaits. Et quelle ne fut pas ma surprise en constatant la profusion des logiciels dans cette catégorie ! En effet, notre système d'exploitation dispose de tout ce qu'il faut pour gérer un flux de photographie numérique.
Je vais vous présenter les logiciels qui ont retenu mon attention à partir des recherches et des comparatifs que j'ai eu l'occasion de réaliser dans l'accomplissement de ma quête. Il ne s'agit en aucun cas d'un test exhaustif entre chacun de ces logiciels. J'ai choisi ceux qui étaient les plus à même de répondre à mes besoins, autant par leurs possibilités offertes que leur facilité de prise en main.
Développer ses pellicules numériques : les RAW
Bien qu'une partie des photographes soient satisfaits des images JPEG produites par leur appareil photo, un photographe exigeant ne pourra faire l'impasse sur le propre développement de ses clichés, il lui faudra donc traiter ses RAW.
Le RAW, pour ceux qui ne le saurait pas, est un format d'image qui conserve l'ensemble des données brutes obtenues par l'appareil photo. Il se distingue du JPEG puisque celui-ci est un format déjà traité par l'appareil (couleurs, contraste, balance des blancs etc.) et qu'il supprime certaines informations pour compresser l'image et aboutir à une taille de fichier réduite. Les possibilités de correction ou d'amélioration lors du développement sont donc fortement limitées...
Après avoir comparé de nombreux logiciels pour développer mes RAW avec Linux, je me suis orienté vers l'un d'entre eux. Je voulais vous le faire connaître tant il est surprenant : Bibble. Bibble est un logiciel propriétaire. Il a été crée dans la ville d'Austin au Texas (États-Unis), par une société souhaitant donner une alternative à l'onéreux décodeur RAW fournis par Nikon à l'époque de ses appareils photo D1.
Souhaitant obtenir plus d'informations sur ce logiciel et cette entreprise, je me suis entretenu avec Eric Hyman, le fondateur de ce logiciel. Son leitmotiv n'a pas changé par rapport à l'époque. En effet, depuis sa sortie en octobre 2004, Bibble v4, alors métamorphosé en véritable gestionnaire de photos, est disponible sur notre plate-forme. Linux n'est pourtant pas réputé pour être le système d'exploitation de nombreux graphistes et photographes, encore moins de sociétés d'éditions. Pourquoi donc avoir fait un tel choix ?
Sa réponse est très claire : "Bibble fait tout pour donner le choix à ses utilisateurs plutôt que de les enfermer dans une seule façon de faire. Il y a tant de styles photographiques différents, chacun avec ses propres attentes et flux de travails, qu'une seule façon de faire ne va fonctionner pour personne. Le choix de sa plate-forme n'en n'est qu'une extension. Beaucoup de studios aujourd'hui utilisent plus d'un type d'ordinateur, et le fait de posséder le même logiciel sur chacun d'entre eux rends les choses plus faciles. Quand nous avons commencé à travailler sur Bibble 4, un de nos développeurs a montré un vif intérêt pour Linux et nous a poussé à le supporter. Comme nous utilisons la bibliothèque QT de Trolltech, c'est une décision qu'il fut facile de prendre."
Pour résumer, en plus de proposer un outil redoutablement performant, cet éditeur de logiciels propriétaires considère notre plate-forme comme égale aux autres. Bibble est disponible en même temps sur Windows, Mac OS et Linux. Il dispose par ailleurs des mêmes fonctionnalités et d'un support identique. Que demander de plus ? Hormis que l'aventure continue, rien de plus.
Ah si, un peu plus de détails sur ce que sera Bibble dans sa prochaine version, la v5. Pour l'instant très peu d'informations ont circulé et je n'ai pas réussi à en obtenir d'avantages. Selon les propos d'Éric : "Bibble 5 sera construit sur ce qui fait notre force : rapidité, qualité et flux de travail. Il y a quelques logiciels concurrents qui sont apparus récemment sur le marché avec des fonctionnalités que nous n'avons pas. En plus d'ajouter celles dont les utilisateurs ont fait la demande, nous avons planifié quelques surprises uniques et excitantes, qui, si tout va bien, seront bientôt disponibles."
Si certains ne sont toujours pas convaincu par Bibble après la période d'essai de 1 mois, ils pourront peut-être se tourner vers LightZone.
C'est un autre logiciel, propriétaire lui aussi, qui a été développé par la société LightCrafts. Cependant cette société n'a pas du tout le même comportement vis à vis de Linux que Bibble. En effet, contrairement à la version payante pour Windows et Mac OS, la version Linux était gratuite mais dépourvue de tout support. Et je dis bien 'était' puisque la version Linux, n'a pas évolué depuis la version 2.4 alors que la version 3 est disponible pour Windows et Mac OS depuis des mois...
J'ai donc contacté directement la société pour savoir ce qu'il en était, et la réponse est plutôt décevante : "LightZone a été officiellement publié au MacWorld de janvier 2006. La décision de fournir au commencement une version pour Windows et Mac OS était financière. Pendant le dernier trimestre 2006, un de nos ingénieurs à décidé de porter LightZone vers Linux en tant que projet parallèle, et à été mis à disposition gratuite de la communauté de Linux. Il a arrêté de fournir les mises à jour après la version 2.4 de LightZone, puisque cela prenait trop de son temps. Le temps passé à travailler sur la version de Linux prenait du temps sur ce qui générait des revenus. Quand cet ingénieur a finalement quitté la société, il n'y a pas eu de plan pour continuer son projet. C'est pourquoi, en date d'aujourd'hui, le mot officiel est que LightZone est seulement disponible pour Windows et Mac OS, nous ne supportons pas, ni n'avons jamais supporté Linux. Le revenu d'une version Linux serait dépassé par les ressources nécessaires à son support."
Quand je lis de tels propos je ne peux qu'en frémir. Heureusement des logiciels libres existent dans cette catégorie. Ils sont, à mon goût, en deçà de leur concurrent propriétaire ; mais ils avancent à bonne allure.
Deux ont retenu mon attention. Le premier est RAWtherapee. Disponible dans la version 2.2 depuis le 24 août, c'est celui qui est, à l'heure actuelle, le plus abouti. Je lui préfère Bibble au niveau des fonctions présentes mais comme j'ai testé beaucoup de logiciels en peu de temps, je ne préfère pas trop me prononcer à ce sujet tant que je n'aurai pas pris le soin de l'examiner en détail. Je laisse ce soin à ceux qui le connaissent bien. Pour ma part, si vous devez en choisir un logiciel
Le deuxième est un logiciel encore en développement mais très prometteur. Il s'agit de BlueMarine, un logiciel multi plate-forme, très modulable, ayant pour objectif de fournir un logiciel tout en un, quelque soit vos besoin en matière de photographie. Il n'est malheureusement pas encore utilisable en production et c'est bien dommage...
Après le développement d'une photo, vient, parfois, l'étape de retouche d'image.
La retouche d'images
Dans ce domaine, pas de tergiversation possible, The GIMP est le roi. Cette situation n'est pas dû à un manque de concurrence, comme Krita, mais parce qu'il la surpasse, et de loin, pour tout ce qui est d'une utilisation photographique.
Plutôt que de vous en faire l'éloge plus longtemps, je vous conseille la lecture de ces trois sites très instructifs :
- La bible de The Gimp (en français)
- Tutoriels officiels orientés photo
- Des tutos, plus plein d'infos autour de l'image numérique
Gérer sa bibliothèque d'images
Les logiciels présents sous Linux dans ce domaine sont, une fois de plus, très nombreux.
Pour ma part, mon attention a été retenue par F-Spot qui permet, entre autres, de gérer une collection très importante d'images, et même plusieurs versions d'une même image, ce qui se révèle être très pratique. Il offre également des fonctions plus avancés, que j'utilise rarement, mais qui sont très pratiques quand on en a besoin.
Certains lui préfèrent digiKam , en arguant qu'il possède plus de fonctionnalités. C'est exact, vous pourrez même vous en servir pour retoucher directement vos fichiers ; mais ne soyez pas trop exigeant tout de même, il est loin d'offrir toute la richesse de The GIMP.
Vous l'aurez compris, F-Spot et digiKam se livrent une concurrence féroce. Le meilleur moyen de trouver celui qui vous convient et de les essayer tous les deux...
Pour conclure
Vous avez maintenant en main tous les outils pour gérer votre collection d'images numériques. Alors n'attendez plus et faites vous plaisir. Switchez !
N'oubliez pas non plus de soutenir les logiciels libres que vous utilisez, et même les autres. Ils représentent de nombreuses heures de travail, et un don, même de 5 ou 10 euros, vous assure que votre logiciel préféré continuera d'être amélioré. Pour notre plus grand plaisir à tous :)
Aller plus loin
- Bibble (121 clics)
- Raw Therapee (37 clics)
- The GIMP (7 clics)
- F-Spot (38 clics)
- digiKam (33 clics)
# ImageMagick \o/
Posté par Francois Revol (site web personnel) . Évalué à 7.
[^] # Re: ImageMagick \o/
Posté par Rémi baudruche . Évalué à 2.
Moi je suis preneur :-)
[^] # Re: ImageMagick \o/
Posté par papap . Évalué à 0.
[^] # Re: ImageMagick \o/
Posté par Archibald (site web personnel) . Évalué à 3.
[^] # Re: ImageMagick \o/
Posté par Pierre Jarillon (site web personnel) . Évalué à 3.
Vu le nombre de possibilités de ce logiciel, je pense qu'un cliquodrome serait encore plus compliqué à utiliser qu'une commande que l'on peut glisser dans un script de quelques lignes.
[^] # Re: ImageMagick \o/
Posté par 태 (site web personnel) . Évalué à 8.
[^] # Re: ImageMagick \o/
Posté par Pierre Jarillon (site web personnel) . Évalué à 4.
[^] # Re: ImageMagick \o/
Posté par psychoslave__ (site web personnel) . Évalué à -1.
[^] # Re: ImageMagick \o/
Posté par Nicolas Legrand (site web personnel) . Évalué à 6.
for i in *;do convert -size 50% $i -thumbnail 50% ../petit/$i;done
Avoir des informations sur l'image :
identify image.jpg
et plein plein plein plein d'autres choses.
# Effet ken burst
Posté par taupette . Évalué à 7.
Ken Burst est disponible en général sur les macs et permet pendant le diaporama d'avoir un effet de traveling et se zoom combiné ce qui rend plus vivant le diaporama et donne un l'effet d'un film vidéo plutôt que d'une diapo . Je n'ai encore rien vu de tel sous Linux ...
[^] # Re: Effet ken burst
Posté par dark_moule . Évalué à 4.
http://www.kipi-plugins.org/
Avec Gnome tu as la possibilité d'utiliser GLiv http://guichaz.free.fr/gliv/
Je ne pense pas que ce soient les seuls mais c'est un bon début ;)
[^] # Re: Effet ken burst
Posté par Guinns . Évalué à 2.
Kipi ne propose pas les effets recherchés.
Les effets transition 3D de kipi font tourner, animer les images dans tous les sens, ca fait vraiment transition.
Les effets Mac ne sont en fait pas des transitions, mais c'est comme une caméra qui survole calmement l'image tout en zoomant ou dézoomant sans s'arrêter, en plus ça centre sur les points d'intérêts (normalement situés aux tiers des images) et c'est vraiment agréable à l'oeil.
Je m'étais dit que si ca n'existait pas, je n'avais qu'à le coder ...
mais faute de temps.
Ceci dit, Kipi semble en effet tout dédié pour posséder ce genre d'animation
[^] # Re: Effet ken burst
Posté par taupette . Évalué à 3.
mais faute de temps."
Dommage , il y a de la demande et je ne suis pas développeur ...
[^] # Re: Effet ken burst
Posté par Guinns . Évalué à 3.
Il semble que "dvd-slideshow" possède déjà ce qu'il faut (même s'il est vrai que le déplacement ne soit pas vraiment "coulé"):
http://dvd-slideshow.sourceforge.net/examples/complex/
Mais le prb de ce soft, c'est qu'il ne semble pas permettre _simplement_ le visionnage de photos d'un répertoire.
Sinon, p'tet que si j'ai de l'aide sur d'autres projets, je trouverai du temps à consacrer à ce sujet ...
Tiens, on cherche justement des compétences non informatiques pour le jeu MoleInvasion :
http://moleinvasion.tuxfamily.org/
Peut-être à bientôt ;-)
[^] # Re: Effet ken burst
Posté par bonnaud frederic (site web personnel) . Évalué à 3.
Mais je trouve que les effets obtenus souffrent d'un effet assez désagréable de saccades.
[1] http://dvd-slideshow.sourceforge.net/wiki/Main_Page
[2] http://slcreator.sourceforge.net/
[^] # Re: Effet ken burst
Posté par -mat . Évalué à 4.
[^] # Re: Effet ken burst
Posté par ʭ ☯ . Évalué à 5.
(ligne imageDirectory: dans ~/.xscreensaver)
puis lancer le visionneur lui-même (il n'est pas dans le PATH)
/usr/lib/xscreensaver/glslideshow --help
tu peux régler la vitesse, etc. Mais avec mes cartes graphiques je constate une saccade à chaque changement d'image. Probablement dû au changement de texture dans la mémoire vidéo, il faudra une bonne âme qui s'y connaisse en 3D pour fluidifier ça.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Effet ken burst
Posté par Glorbouille . Évalué à 2.
Il marche trés bien et l'effet est parfait même en 1600*1200 avec la vidéo intégré de la carte mère intel que j'ai au taff.
http://web.inf.tu-dresden.de/~cw183155/smoothslidesaver/
ou
http://kde-apps.org/content/show.php/SmoothSlideSaver?conten(...)
# Merci...
Posté par case42 (site web personnel) . Évalué à 8.
Pour ma part, j'utilise GThumb pour classer mes photos. Il est certainement moins puissant que F-Spot ou digiKam, mais il a l'avantage d'être léger et intégré au bureau Gnome (contrairement à F-Spot qui est en vilain Mono, bhouuu! meussant!).
La rare fois ou je me suis penché sur le traitement des images RAW, j'ai essayé RawStudio , mais je ne sais pas du tout comment il se compare à la concurrence ( ce serait certainement intéressant de faire cette comparaison)
[^] # Re: Merci...
Posté par Zorro (site web personnel) . Évalué à 9.
F-Spot, pour ce que j'ai pu en comprendre, fait partie de ces logiciels qui génèrent eux-même leur système de fichier et leur arrangement des photos.
Je m'explique : d'abord F-Spot recopie ailleurs, dans son cache à lui, les photos qu'on lui apporte : si on avait un répertoire Images déjà bien rempli et bien organisé, ça prend le double de place sur le disque dur, et le répertoire image ne sert presque plus à rien.
Ensuite, une fois qu'elles sont gérées par F-Spot, plus moyen de les gérer avec quoique ce soit d'autre : si on les déplace ou qu'en en change le nom avec Nautilus, F-Spot retrouve plus ces billes. C'est ultra-pénible. Et plus possible de naviguer dans les images avec un logiciels autre, vu l'organisation assez spéciale des dossiers F-Spot.
Je suis peut-être vieux jeu, mais je peux pas supporter de laisser un logiciel gérer lui-même la hiérarchie sur le disque d'un truc aussi important que mes images. Pour accéder à mon disque dur, je veux continuer à passer par un explorateur de fichiers, et pas avoir à utiliser un gestionnaire de collection différent en fonction des fichiers que je veux trier ou ranger.
Et en plus, la dernière fois que j'avais fait le test, F-Spot ne pouvait même pas renommer les images. Peut-être que ça a changé depuis, mais j'ai trouvé ça assez fort, quand même...
Bref, c'est pour ces raisons que je préfère utiliser GQview, qui est plus une sorte de super explorateur de fichier consacré aux images qu'un gestionnaire de collection. Il peut lui aussi gérer les tag et les collections, mais c'est pas ce qu'il fait de mieux et c'est pas très intuitifs.
[^] # Re: Merci...
Posté par gnumdk (site web personnel) . Évalué à 6.
Les brevets mis à part, j'ai essayé TomBoy hier, ca met trois jours à se lancer pour afficher un pauvre postit dans le panel gnome...
Qu'on viennent pas me dire que Mono ca rame pas à mort...
[^] # Re: Merci...
Posté par zerbro . Évalué à -3.
Donc, non, ca rame pas du tout à mort. Le problème vient surtout qu'il serait bien de pouvoir précharger et garder en mémoire certaines choses, pour ne pas les recharger, et ainsi gagner en vitesse.
Voila, critiquez mono si vous voulez (perso je m'en fou comme de l'époque "java capucépalibre"), mais essayez de rester un tout petit peu objectif, ca fait pas de mal.
[^] # Re: Merci...
Posté par gnumdk (site web personnel) . Évalué à 6.
Alors que je totem pas préchargé: < 1 seconde
idem pour gedit, ...
Intel(R) Pentium(R) D CPU 3.00GHz
[^] # Re: Merci...
Posté par Guillaume Savaton (site web personnel) . Évalué à 2.
La dernière fois que je l'ai essayé, je ne crois pas que F-Spot dupliquait les fichiers.
Par contre, il stockait toutes les métadonnées (classement des photos, etc) dans une base SQLite spécifique à chaque utilisateur.
Ce problème a déjà fait l'objet de nombreux débats : d'un côté, nos photos sont stockées sous forme de fichiers dans une hiérarchie de dossiers. De l'autre, nous voulons pouvoir les parcourir par dates, catégories, contenu, etc. en leur associant tout un tas de métadonnées que le système de fichiers ne prend pas en charge.
Chaque logiciel (du simple navigateur de fichiers aux outils de traitement et de gestion des images) aura sa façon d'organiser les affaires et le passage de l'un à l'autre est quasiment impossible.
Pourquoi ne pas créer un (oui, encore un) comité de standardisation qui définirait clairement l'organisation d'une base de photos en termes de système de fichiers et de métadonnées ?
[^] # Re: Merci...
Posté par TImaniac (site web personnel) . Évalué à 2.
Ou pas. Il te propose les 2. C'est vrai que si on coche pas la case correspondante, par défaut il recopie. Parcqu'on peut aussi lui brancher un appareil photo par exemple (auquel cas il n'y a pas besoin de lui dire quoi faire).
Mais tu as raisons, F-Spot propose par défaut une abstraction du support de tes photos. L'idée est de proposer plutôt une vue par tag et une vue temporelle plutôt qu'un arbre de dossier qui est beaucoup plus contraignant.
Il faudrait effectivement ajouter à F-Spot une fonction de "surveillance" de répertoire pour qu'il détecte les renommages et les ajout/suppression.
vu l'organisation assez spéciale des dossiers F-Spot.
2007/09/26/toto.jpg
Pas si compliqué :)
[^] # Re: Merci...
Posté par satan . Évalué à 4.
J'aime beaucoup l'interface de f-spot pour gérer mes photos mais il manque cruellement une option pour avoir une vue des dossiers à la place d'une vue des tags sur la partie gauche de l'UI, comme Picasa.
Picasa permets les deux en même temps, gérer les dossiers ET avoir une vue sur les tags comme f-spot. J'utilise pas Picasa parce que j'ai ni envie d'une app proprio ni envie de voir la laideur et non intégration d'une appli Wine mais f-spot prends beaucoup trop de décision à la place de l'utilisateur dans sa philosophie.
Je taggue toutes mes photos, et je suis content d'avoir une vue sur les tags. Mais je veux aussi pouvoir déplacer les photos d'un dossier à un autre sans devoir passer par mon gestionnaire de fichiers, et c'est un truc que permets Picasa, Digikam.. et faut réimporter les photos dans f-spot quand tu modifies la hiérarchie, c'est une horreur.
Je backup et déplace régulièrement mes photos, c'est une nécessité pour moi de toucher à la hiérarchie des dossiers et noms des fichiers.
# My 2 cents
Posté par romu . Évalué à 4.
A savoir que la fonctionnalité "qui tue" de Lightzone, les régions vectorielles, a été annoncée pour la version 3 de RawTherapee. Celui étant par ailleurs très bon, se présente comme le nouveau champion du traitement Raw sous Linux.
Gimp j'utilise pas.
BlueMarine, ben le jour où ça se lancera correctement, je jetterai un oeil.
Pour la gestion d'images, F-Spot est vraiment bien. Problème, il utilise une base de données et si t'oublie de sauvegarder le dossier ~/.f-spot quand tu changes ou mets à jour (from scratch) ta distrubution, t'es mort faut tout refaire.
Alors un petit coup d'oeil à JBrout (jbrout.free.fr) pourrait être pas mal.
[^] # Re: My 2 cents
Posté par Guillaume Savaton (site web personnel) . Évalué à 3.
C'est vrai que ce n'est pas forcément évident pour tout le monde.
Je suis sûr qu'il y a des utilisateurs qui font régulièrement des sauvegardes de leurs photos (sur disque dur externe ou CD, par exemple) et qui ne pensent absolument pas à sauvegarder aussi leur dossier .f-spot
L'autre problème, c'est que cette base de données est propre à chaque utilisateur. Pour une utilisation familiale, par exemple, si chacun a son propre compte utilisateur, il est malaisé de partager la même base de données.
La solution que j'ai adoptée consiste à placer le fichier "photos.db" dans un dossier partagé, et à faire pointer des liens symboliques à partir de chaque dossier .f-spot des utilisateurs.
Là encore, ce n'est pas une solution pour les débutants :
- il faut savoir que le dossier .f-spot existe et à quoi il sert
- il faut savoir ce qu'est un lien symbolique
- il faut gérer les permissions sur le fichier .db pour qu'il soit utilisable par tous
[^] # Re: My 2 cents
Posté par carlo . Évalué à 1.
F-spot ne permet-il pas d'inclure les tags et les commentaires dans les photos directement ?
Digikam le permet et dans ce cas il suffit de rescanner tout le répertoire pour avoir la même chose.
Dans tous les cas, .f-spot est généralement dans $HOME et c'est ce qu'on sauvegarde/ne formate pas même si on réinstalle from scratch, non ?
J'avoue avoir définitivement abandonné f-spot après de nombreuses tentatives, il était vraiment trop instable et pas encore aussi abouti et pratique (traitement par lots par ex) que Digikam.
[^] # Re: My 2 cents
Posté par romu . Évalué à 1.
F-spot ne permet-il pas d'inclure les tags et les commentaires dans les photos directement ?
>>
Ben non justement, tout est stocké dans une base MySql.
<<
Dans tous les cas, .f-spot est généralement dans $HOME et c'est ce qu'on sauvegarde/ne formate pas même si on réinstalle from scratch, non ?
>>
Ben pas moi, je dois être bourrin, mais comme je tourne avec Ubuntu sur un portable Mac, à chaque nouvelle version, je repards "from scratch" sinon j'ai toujours des doutes.
<<
J'avoue avoir définitivement abandonné f-spot après de nombreuses tentatives, il était vraiment trop instable et pas encore aussi abouti et pratique (traitement par lots par ex) que Digikam.
>>
Ben tu peux y retourner, stable, rapide, interface vraiment pratique. Il est vraiment super...hormis sa base de données. Mais il y a une super astuce juste ci-dessus.
[^] # Re: My 2 cents
Posté par 태 (site web personnel) . Évalué à 4.
Si, mais il faut le lui dire explicitement : option "Write metadata to file". Et le fait qu'il est capable d'importer les tags iptc et xmp aurait du mettre la puce à l'oreille de ses utilisateurs.
[^] # Re: My 2 cents
Posté par satan . Évalué à 2.
Si, mais il faut le lui dire explicitement : option "Write metadata to file".
Si Havoc Pennington voyait ça, il dirait que c'est une misfeature qui crie "click me to fix a stupid behavior" alors que ça devrait être coché par défaut et caché loin dans gconf. C'est typiquement le genre d'option qui ne devrait même pas exister, l'option est présente pour corriger un comportement par défaut relativement dangereux pour l'archivage.
[^] # Re: My 2 cents
Posté par dark_moule . Évalué à 3.
[^] # Re: My 2 cents
Posté par Nicolas Schoonbroodt . Évalué à 1.
[^] # Re: My 2 cents
Posté par cosmocat . Évalué à 1.
[^] # Re: My 2 cents
Posté par 태 (site web personnel) . Évalué à 8.
[^] # Re: My 2 cents
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
> sauvegarde/ne formate pas même si on réinstalle from scratch, non ?
Quand on fait les choses proprement, oui, mais quand on fait des backups à coups de
$ cp ~/* /media/backup
(ou son équivalent avec l'interface graphique de ton choix), les fichiers cachés ne sont pas sauvegardés. C'est bête, mais j'ai eu le problème avec un débutant, qui n'arrivait même pas à sauvegarder son ~/.mozilla/ avec K3B.
[^] # Re: My 2 cents
Posté par carlo . Évalué à 1.
rassurez-moi, toutes les nouvelles distributions user-friendly crée quand même une partition dédiée à /home, non ?
parce que sinon... vu les tailles de DD aujourd'hui c'est quand même bête de pas en profiter, et hop ainsi en cas de reinstall un petit message de ubutnu ou opensuse disant "vous avez déjà une partition contenant des données personnelles, souhaitez-vous la réutiliser ou l'effacer ?" et hop c'est réglé !
[^] # Re: My 2 cents
Posté par Effraie (site web personnel) . Évalué à 3.
moi j'utilise:
rsync -avzh --exclude=cache/ --exclude=Cache/ --exclude=thumbs/ --exclude=.thumbnails/ --stats -e ssh --delete-after --delete-excluded /home/user/ user@backup-server:/backup-dir/user/
qui implique l'existence d'un serveur de sauvegarde.
je le lance une fois par jour, et c'est un régal.
\Ö<
[^] # Re: My 2 cents
Posté par soulflyb (Mastodon) . Évalué à 2.
c'est ce que j'utilise et c'est super (et l'équipe de dev est super sympa, ça compte aussi)
[^] # Re: My 2 cents
Posté par briaeros007 . Évalué à 3.
Y'a sans doute un front end aussi pour votre bureau favori (non je ne parle pas de ion2) ;)
[^] # Re: My 2 cents
Posté par Quzqo . Évalué à 2.
Et avec un "habillage" type fichiers de configuration (plus d'autres fonctionnalités omises volontairement), ça donne backupninja.
Excellent, simple et puissant... s'appuie sur du rdiff-backup, en incrémental ou complet...
A essayer pour un outil de backup léger.
# The GIMP
Posté par satan . Évalué à 10.
Certains lui préfèrent digiKam , en arguant qu'il possède plus de fonctionnalités. C'est exact, vous pourrez même vous en servir pour retoucher directement vos fichiers ; mais ne soyez pas trop exigeant tout de même, il est loin d'offrir toute la richesse de The GIMP.
Les outils de Digikam ne remplacent pas ce qu'on trouve dans The GIMP et ils ne sont pas faits pour ça. Les outils qu'on trouve dans digikam sont équivalents aux ajouts pour photographes qui ont été faits dans les derniers Photoshop comme les Lens Correction Tools.
http://graphicssoft.about.com/od/photoshop/ss/cs2morenew_2.h(...)
http://extragear.kde.org/apps/digikamimageplugins/lensdistor(...)
http://extragear.kde.org/apps/digikamimageplugins/antivignet(...)
C'est ridicule de dire qu'il n'offre pas la richesse de The GIMP, digikam n'est pas fait pour de la "retouche", ces outils sont faits pour le workflow de développement des photos. Au contraire, pour les photographes digikam offre par défaut des tonnes de trucs qui nécessitent avec The GIMP de chercher des plugins à installer un par un. Les mecs d'Adobe ont compris que ce sont de très bons outils à intégrer dans un programme de manipulation d'image mais il faudra surement des années pour The GIMP avant qu'on voit une interface ergonomique équivalente aux Lens Correction Tools ou aux outils de digikam pour corriger la distortion, vignettage, les outils de sharpening intelligent et tout le reste.
[^] # Re: The GIMP
Posté par Mr_Moustache . Évalué à 4.
D'ailleurs ce n'est pas non plus le rôle de The Gimp de gérer le workflow de développement des photos. C'est un logiciel de traitement d'image, ce n'est pas spécifique aux photos.
Il faut bien différencier des logiciels comme Bibble ou RAW Therapee et d'autres comme The Gimp, ils n'ont pas la même utilité et se complètent. Les premiers ont pour vocation d'être dédié aux retouches photos, donc plus proche du photographe. The GIMP est destiné aux graphistes, il est bien plus fourni mais bien plus pénible à manipuler pour le photographe ...
[^] # Re: The GIMP
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 8.
[^] # Re: The GIMP
Posté par irimi . Évalué à 2.
Tant que j'y suis, j'ajoute quelques points noirs connus de The GIMP :
- pas de groupement d'effets sur les calques (c'est trèèès limitant pour la productivité) ;
- gestion limitée de certaines tablettes graphiques ; impossible de dessiner proprement avec une Volito (1 ou 2) par exemple, ça "marche" mais on obtient des polylignes très moches dès qu'on accélère un peu (la comparaison avec Photoshop est sans appel, ce n'est donc pas une limitation matérielle) ;
- pas de gestion de la couleur en CMJN, ça peut être très handicapant pour passer à l'impression (quoique, maintenant beaucoup d'imprimeurs travaillent essentiellement en RVB) ;
Je ne sais pas vraiment où ça en est, je suppose que c'est bien connu de l'équipe de développement, mais bon autant le réécrire...
En tout cas je sais par expérience que si ces fonctionnalités arrivent dans GIMP, pas mal de professionnels seraient prêts à abandonner Photoshop sans regret, pour enfin passer sur une plateforme GNU/Linux.
[^] # Re: The GIMP
Posté par beagf (site web personnel) . Évalué à 1.
C'est clair que c'est un problème, mais à mon avis, pas le plus important. Pour moi le 16bit et le CMJN passent avant.
- gestion limitée de certaines tablettes graphiques ; impossible de dessiner proprement avec une Volito (1 ou 2) par exemple, ça "marche" mais on obtient des polylignes très moches dès qu'on accélère un peu (la comparaison avec Photoshop est sans appel, ce n'est donc pas une limitation matérielle) ;
Je n'ai jamais testé ces tablettes sous linux, mais est-ce que le problème ne serait pas plustôt au niveau du driver que sous Gimp ?
- pas de gestion de la couleur en CMJN, ça peut être très handicapant pour passer à l'impression (quoique, maintenant beaucoup d'imprimeurs travaillent essentiellement en RVB) ;
Une des très grosse lacune de Gimp pour du travail professionel. Et personnelement je ne travaillerais jamais avec un imprimmeur qui me demande mes fichiers en RGB, car dans tous les cas pour l'impression il y aurra une convertion en CMJN et attention au mauvaise surprises.
# hugin
Posté par jm trivial (site web personnel) . Évalué à 7.
On peut notamment avoir en sortie du tiff multicalques, ce qui permet de retoucher le panorama final calque par calque avec gimp. Un vrai plaisir.
J'utilise aussi qtpfsgui pour le bracketing, un logiciel très complet avec lequel il faut faire mumuse un peu pour trouver des choses intéressantes.
[1] http://hugin.sourceforge.net/
[2] http://qtpfsgui.sourceforge.net/
[^] # Re: hugin
Posté par madko (site web personnel) . Évalué à 3.
pour hugin ça manque un peu d'automatisation, et c'est vrai qu'il est pas facile d'acces. D'ailleurs merci pour l'astuce sur les tiff multicalques ça a l'air bien pratique
[^] # Re: hugin
Posté par BAud (site web personnel) . Évalué à 4.
[^] # Re: hugin
Posté par Guinns . Évalué à 2.
Le passage par gimp ne sert quasiment plus qu'a redécouper l'image rectangulaire ensuite.
A voir (ca date de 2004, mais toujours utilisable) :
http://www.linuxfocus.org/English/September2004/article348.s(...)
[^] # Re: hugin
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
Ça dépends. Si les images se recolent mal (typiquement, un mec qui est passé devant au mauvais moment et qui apparait coupé en deux par défaut), un passage par Gimp peut sauver la mise : à coup de selection, floutage de selection, et découpage, on choisit facilement la zone de transition entre les photos.
[^] # Re: hugin
Posté par jm trivial (site web personnel) . Évalué à 1.
# Choix de l'appareil photo
Posté par TuxMips . Évalué à 4.
1) les marques d'appareils font la plus part du temps es raw propriétaires pour refourguer leur soft proprios avec l'appareil.
Qu'un Canon pro ou un Nikon pro soit commercialisé dans cet esprit est pour moi lamentable.
2) lorsque j'ai acheté mon reflex j'ai opté pour le K10 de Pentax.
Ce n'était peut être pas le meilleur choix. Mais c'est à ma connaissance le seul capable de fournir du raw au format DNG d'adobe dont les spécificités sont totalement ouvertes comme le PDF.
In fin,pour le photographe professionnel qui se respecte et s'il avait connaissance de la problématique du format des fichiers laisserait tomber Canon et Nikon.
[^] # Re: Choix de l'appareil photo
Posté par satan . Évalué à 3.
http://www.adobe.com/support/downloads/detail.jsp?ftpID=3732
Ca marche sous wine, l'interface graphique est très buggée mais si on lui donne les fichiers sous la commande line et qu'on click juste le bouton qu'il faut pour convertir c'est ok.
C'est bien pour l'archivage et j'ai même d'autres bénéfices : les raw d'Olympus sont incroyablement plus lourds que nécessaire et pèsent 13,5mo pour mon appareil, contre 7.5 MO pour le DNG.
[^] # Re: Choix de l'appareil photo
Posté par pada . Évalué à 3.
J'en profite pour signaler une lecture qui m'a été très utile
http://www.volkergilbertphoto.com/articles.htm
et en particulier son livre
Développer ses fichiers RAW, Volker Gilbert
http://www.eyrolles.com/Accueil/Livre/9782212120837/livre-de(...)
Il m'a d'ailleurs conduit à essayer puis adopter Bibble
[^] # Re: Choix de l'appareil photo
Posté par Alexandre (site web personnel) . Évalué à 1.
Tous les problèmes que j'avais avant avec mes *.nef, je ne les ait plus : chaque thumbnail se crée sans problème, et le raw s'ouvre parfaitement (avec import de la bdb, etc...) sur tous les logiciels.
[^] # Re: Choix de l'appareil photo
Posté par Émilien Tlapale . Évalué à 1.
[^] # Re: Choix de l'appareil photo
Posté par patate . Évalué à 5.
http://www.openraw.org/node/1482
[^] # Re: Choix de l'appareil photo
Posté par regdub . Évalué à 2.
Par exemple, Pentax est accusé d'appliquer une balance des blancs aux données.
http://openraw.org/node/1541
[^] # Re: Choix de l'appareil photo
Posté par patate . Évalué à 2.
(c'est vendredi, c'est permis)
[^] # Re: Choix de l'appareil photo
Posté par Drakho . Évalué à 5.
Mais voilà, je suis équipé Nikon (et plutôt bien fourni en optiques).
De plus, quand on choisi une marque d'appareil photo reflex, on ne choisi pas en fonction du boîtier mais d'un système complet, et les optiques y tiennent une place importante.
Alors favoriser les marques faisant du DNG, oui; pour autant que les gammes optiques conviennent à l'utilisation qu'on a de l'appareil
Les photographes pro qui se respectent connaissent (en tout cas certains) la problématique, mais ils font le choix d'un système complet, pas juste d'un format de fichier de sortie. Domage, mais je comprends ce choix.
[^] # Re: Choix de l'appareil photo
Posté par pada . Évalué à 3.
[^] # Re: Choix de l'appareil photo
Posté par patate . Évalué à 2.
[^] # Re: Choix de l'appareil photo
Posté par pada . Évalué à 2.
[^] # Re: Choix de l'appareil photo
Posté par Émilien Tlapale . Évalué à 1.
# et picasa ?
Posté par lionel tricon . Évalué à 2.
Téléchargeable sur http://picasa.google.com/linux/
Ok c'est pas pile poil la dernière version si j'en crois mon dernier essai, mais ca offre tout de même quelques fonctionnalités supplémentaire vis à vis d'un digikam (que ma femme aime beaucoup au demeurant).
Motorisé par wine mais bon, c'est toujours ça.
[^] # Re: et picasa ?
Posté par JereMe . Évalué à -2.
[^] # Re: et picasa ?
Posté par eldwane . Évalué à 2.
Bibble non plus...
[^] # Re: et picasa ?
Posté par JereMe . Évalué à 1.
[^] # Re: et picasa ?
Posté par lionel tricon . Évalué à 5.
Mais effectivement, picasa n'est pas libre mais est par-contre multi-plateforme win/lin (intéressant pour ceux qui ont un pied entre deux mondes).
[^] # Re: et picasa ?
Posté par z a . Évalué à 4.
vraiment multi-plateformes ? ça marche sur autre chose que x86 ?
[^] # Re: et picasa ?
Posté par lionel tricon . Évalué à 1.
non, x86 only visiblement
[^] # Re: et picasa ?
Posté par Zorro (site web personnel) . Évalué à 2.
Et "multi", on peut le dire à partir de combien ?
[^] # Re: et picasa ?
Posté par dark_moule . Évalué à 5.
Quand je suis arrivé sur le site officiel http://picasa.google.com/index.html j'ai lu
Configuration système nécessaire
Microsoft Windows 2000 ou XP
Microsoft Internet Explorer version 5.0 ou ultérieure"
Il m'a donc semblé que seule une version Windows était disponible...
De plus ses fonctions me semblent limités. N'est-il pas trop orienté grand public ?
[^] # Re: et picasa ?
Posté par lionel tricon . Évalué à 1.
[^] # Re: et picasa ?
Posté par Alex . Évalué à 1.
A coté digikam me parait bien plus complet, mais également plus complexe (en tout cas pour la retouche photo, pour le tri digikam me va très très bien)
# UFRaw et GimpUfraw \o/
Posté par Drakho . Évalué à 2.
Ce couple est agréable, réactif et colle à mes besoins
J'ai essayé Bibble lite et c'est vrai qu'il est très bon et même loin devant UFRaw mais comme ce dernier me suffit amplement et s'améliore aussi.
[^] # Re: UFRaw et GimpUfraw \o/
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
# Gimp vs Krita
Posté par peau chat . Évalué à 9.
C'est bizarre les goûts et les couleurs, parce qu'en ce qui me concerne, je suis justement passé sur Krita il y a quelques jours (sur ma Kubuntu Feisty).
Alors je ne suis peut être pas un exemple significatif, parce que j'ai toujours fait une profonde allergie au look & feel de Gimp, et en plus de ça, je ne suis pas un graphiste professionnel.
Mais j'ai cru comprendre quand même que Krita était plus performant en terme de calibrage des couleurs, CMJN etc.
[^] # Re: Gimp vs Krita
Posté par Anonyme . Évalué à 3.
krita *.jpg
et la c'est le drame, cela swap a mort, me bloque tout, la souris ne bouge plus, apres 10 minute j'ouvre une console, 5 minute apres killall krita et 5 minute aprés aprés, la machine redeviens disponible, pfffff
donc je refait la manip avec gimp:
gimp *.jpg , hop hop hop toute mes images s'affichent en moins de 20 seconde il y en a partout :-) et je peux commencer a retailler gentiment mes images tranquillement.
donc bon krita c'est bien mais pas pour tout
[^] # Re: Gimp vs Krita
Posté par briaeros007 . Évalué à 5.
Donc the gimp, c'est bien, mais pas pour tout ;)
Enfin pour faire du traitement batch de resizing , pourquoi ne pas utiliser convert (imagemagick), prendre krita ou the gimp c'est un peu le canon pour tuer la mouche
[^] # Re: Gimp vs Krita
Posté par Matthieu Moy (site web personnel) . Évalué à 5.
[^] # Re: Gimp vs Krita
Posté par Pierre Jarillon (site web personnel) . Évalué à 4.
convert -geometry "$HMAX" "$g" "$h"
Voici un petit script qui fait fait ça avec convert -geometry "$HMAX" "$g" "$h" et un peu plus.
#!/bin/sh
# Pierre Jarillon, le 1er mars 2006
# Ce script :
# 1- fabrique le répertoire "reduit" si il n'existe pas.
# 2- le peuple de toutes les images du répertoire courant réduites
# 3- les noms des fichiers seront dépourvus d'accents, d'espaces, de majuscules.
# 3- crée un aperçu de toutes ces images (Planche contact).
REP=reduit # Nom du répertoire recevant les réductions
NOM=Apercu # Nom de la "planche contact"
HMAX=x700 # hauteur maximum des images réduites.
if [ $# != 0 ]; then
TITRE="$1";
else
echo -e "Usage : `basename $0` \"Le titre (même vide) que vous voulez\""
exit
fi
if [ ! -d $REP ]; then mkdir $REP ; fi
ls *.jpg *.jpeg *.JPG *.JPEG *.png *.PNG 2>/dev/null | while read f
do
# enlever espaces et accents
g=`echo $f |tr " àçéèêëîïôöùüÂÇÉÈÊËÎÏÔÖÙÜ" "_aceeeeiioouuACEEEEIIOOUU"`
# enlever espaces, accents et majuscules (pour web)
h=`echo "$REP/$g" |tr [:upper:] [:lower:]`
if [ "$f" != "$g" ] ; then mv "$f" $g; fi
echo " => $g"
convert -geometry "$HMAX" "$g" "$h"
done
# Création d'une "planche contact"
echo "Création d'un $NOM pour $TITRE"
cd $REP
montage -font "-adobe-helvetica-medium-r-normal--14-140-75-75-p-77-iso8859-15" \
-fill "#ffffff" \
-title "$1" \
-background "#2e4e74" \
-border "2x2" \
-borderColor "blue" \
-page "595x842" \
$(ls *.jpg *.jpeg *.png *.gif 2>/dev/null |sed -e "s/ /_/g") $NOM.jpg
echo "C'est fait !"
cd ..
[^] # Re: Gimp vs Krita
Posté par Anonyme . Évalué à 5.
j'aurais d'ailleurs du le preciser avec les intégriste de la ligne de commande qui traine ici ;-D
je vais d'ailleurs de ce pas moinsser les commentaires sous estimant mes capacités. pom pom pom
[^] # Re: Gimp vs Krita
Posté par Olivier LAHAYE (site web personnel) . Évalué à 4.
Pour les traitements batches, il faut utiliser digikam.
la combinaison krita digikam est vraiment la meilleure qu'il m'ai été donné de voire, et la gestion des images 16bits par composante avec les color profiles est vraiment géniale...
Un truc tout bête que je n'ai jamais réussi à faire avec the Gimp:
tracer une ligne droite ou un flèche sur une photo pour pointer un détail.
C'est pourtant basique une droite, bah personne, je dis bien personne dans les gimp afficionados de mon entourage n'a été capable de répondre à cette question sans faire un scripte fu LOL...
Au niveau comparatif gimp krita, j'aurais bien aimé connaître les critères de l'auteur qui lui font dire qu'il n'y a pas comparaison, car lancer un jugement dans le vide sans argumentaire est plutôt léger...
[^] # Re: Gimp vs Krita
Posté par gyhelle . Évalué à 1.
Un truc tout bête que je n'ai jamais réussi à faire avec the Gimp:
tracer une ligne droite ou un flèche sur une photo pour pointer un détail.
Lapin compris, tu veux juste dessiner une ligne droite ? si oui [SHIFT]+[CLIC] est ton ami.
[^] # Re: Gimp vs Krita
Posté par peau chat . Évalué à 2.
Là où ça se corse, c'est pour tracer un rectangle :-D
[^] # Re: Gimp vs Krita
Posté par abramov_MS . Évalué à 3.
Ca fait des annees qu'il est pourri, ce n'est pas possible de zoomer sur une zone de la photo dans ce plugi et donc on ne peut pas rajouter quoi que ce soit comme figures geometrique de facon precise sur l'image.
Alors oui il y a plein de possibilite en jouant avec les calques etc mais bon c'est un peu prendre un buldozer pour enfoncer un clou.
Gimp devrait normalement passer a Gegl mais combien de temps cela va t'il prendre? En attendant il faut bien avouer que la concurrence a bouger et qu'ils ne sont plus seuls sur le marche du logiciel de traitement d'image libre. De plus dans quelques mois Krita2 va arriver et cela devrait bien ameliorer tout ca.
Je dois avouer que je trouve cela bien, Gimp s'est un peu trop endormi sur ses lauriers et cela va les forcer a bouger!
[^] # Re: Gimp vs Krita
Posté par dark_moule . Évalué à 5.
Où as tu vu les améliorations future de Krita ? J'ai parcouru leur site officiel mais je n'ai pas vu ces informations.
Si tu as un lien, je suis très intéressé.
[^] # Re: Gimp vs Krita
Posté par abramov_MS . Évalué à 3.
[^] # Re: Gimp vs Krita
Posté par papap . Évalué à -1.
c'est l'histoire du lièvre et de la tortue: l'essentiel c'est d'arriver à temps
[^] # Re: Gimp vs Krita
Posté par briaeros007 . Évalué à 3.
Ca fait trois ans qu'on nous sort GeGL.
Et même si dernièrement il semblerait qu'il y ait une ui en plein dvp, ca va mettre encore du temps :'(
[^] # Re: Gimp vs Krita
Posté par peau chat . Évalué à 6.
Et puis bon, au niveau colorimétrie, je crois qu'il n'y a pas photo (si j'ose dire). Dans Krita on peut gérer ses calibrages et profils de moniteurs et d'impression, ainsi que des profils colorimétriques lorsqu'on fait des importations depuis d'autres softs.
Je ne sais pas ce qu'il en est exactement de Gimp pour ça (comme je l'ai dit, j'ai toujours été allergique à Gimp, ce qui n'a rien à voir avec ses défauts ou qualités), mais je ne crois pas qu'il y ai l'ombre d'une gestion colorimétrique dans gimp...
[^] # Re: Gimp vs Krita
Posté par gnujsa . Évalué à 2.
> mais je ne crois pas qu'il y ai l'ombre d'une gestion colorimétrique dans gimp...
au lieu de croire ou de ne pas croire, tu ferai mieux d'aller au moins jeter un coup d'oeil sur le site avant de parler dans le vide.
> Dans Krita on peut gérer ses calibrages et profils de moniteurs et d'impression, ainsi que des profils colorimétriques lorsqu'on fait des importations depuis d'autres softs.
Gimp sait faire tout ça depuis ses versions de dev. 2.3.x, 2.4-rc .
Ça va faire bientôt 3 ans que l'on a pas eu de nouvelle version stable de Gimp (depuis Décembre 2004) mais ils ont quand même un peu travaillé entre temps... Ça vaut largement le coup de se le compiler, d'autant que les versions de dev. sont particulierement stable.
[^] # Re: Gimp vs Krita
Posté par peau chat . Évalué à 5.
Ah ben donc j'en suis certain, Gimp ne le gère pas.
2.3 = Version de dev.
2.4rc = Release Candidate, c'est donc toujours pas sorti.
euh, je suppose que tu voulais dire version "MAJEURE" :
13 juillet 2007 : GIMP 2.2.17 Released
Ben voyons, un graphiste n'a que ça a foutre d'installer le devkit qui va bien et de compiler des versions de dev de gimp.
[^] # Re: Gimp vs Krita
Posté par Psychofox (Mastodon) . Évalué à 2.
C'est du logiciel libre. S'il y avait vraiment une demande, il y'aurait bien quelqu'un qui aurait distribué des binaires pour ces pauvres graphistes impotents, et on en trouverait surement des paquets pour les distribs principales.
La vérité c'est que les graphistes ne sont de toute façon pas intéressés par gimp. Ils ne jurent que par photoshop, même si des alternatives de qualité (qu'elles soient libres ou proprio, chères ou pas, et quelque soit l'OS) existent depuis des années (jasc/corel paint shop pro, pixel32, Photo Paint, gimp). La plupart du temps, ce n'est pas une question de fonctionnalités (le cmjn n'a pas d'intérêt pour un web designer par exemple, qui la plupart du temps ferait d'ailleurs mieux d'utiliser fireworks), mais une question de religion, le même genre de monothéisme qui fait que les avocats ont presque tous des mac. Et puis ça les rassure de payer 1000 ¤ pour un produit, il a tout de suite l'air mieux.
[^] # Re: Gimp vs Krita
Posté par peau chat . Évalué à 4.
C'est bien ce que je dis, le CMJN n'a d'intérêt que pour les graphistes, et Gimp n'est pas pour les graphistes.
Si on classe les Web Designers parmis les graphistes, il faudra qu'on parle des torchons et des serviettes, ou de la confiture et des cochons.
Un Web designer il ne sait même pas ce que c'est la colorimétrie, il s'en tape complètement d'ailleurs puisque son website il va s'afficher sur des écrans qui ne sont pas calibrés.
La seule inutilité du webdesigner qui utilise Gimp, c'est de faire des sites que seront inaccessibles aux mal-voyants et non-voyants. Cela n'a rien de glorieux.
Moi, en ce qui me concerne, à chaque fois que j'ai vu un vrai graphiste, dans ses outils de base avant même de choisir un logiciel, il avait sa sonde colorimétrique et son nuancier pantone.
Alors après, quand il choisit un logiciel, il veut que le logiciel s'adapte à ses outils de travail de base : La sonde et le pantone.
Donc forcément, il ne regarde même pas Gimp qui est un truc juste bon pour faire son blog ou ses carte de voeux amateures.
PSP coûte une fortune, oui. PSP ne mérite pas un tel prix. Mais PSP est quasiment le seul outil disponible pour les graphistes. Gimp n'en fait pas partie.
Par contre, ce qui me fait doucement marrer, ce sont les M. & Mme Michu qui utilisent (et payent) PSP pour enlever les yeux rouges de leurs photos de vacances. Là oui, Gimp, Krita, Digikam & cie font bien l'affaire...
[^] # Re: Gimp vs Krita
Posté par bollzy . Évalué à 1.
[^] # Re: Gimp vs Krita
Posté par gpe . Évalué à 1.
J'avais essayé il y a peu la version qui est dans Debian Testing (1.6.2 je crois) et j'ai bien vite abandonné!
C'est lent (surtout avec plusieurs photos), je n'ai jamais réussi à appliquer une courbe sur une image, l'affichage du module de gestion de courbe semble défectueux, etc.
# Rawtherapee = pas libre
Posté par Hubert Figuière . Évalué à 3.
[^] # Re: Rawtherapee = pas libre
Posté par tuiu pol . Évalué à 1.
# digiKam vs F-Spot
Posté par Eric M. . Évalué à 6.
Le fait qu'il écrive les tags du catalogue dans les infos IPTC garanti une reprise beaucoup plus aisée ultérieurement dans l'hypothèse d'un changement de logiciel.
[^] # Re: digiKam vs F-Spot
Posté par B16F4RV4RD1N . Évalué à 8.
Exportation dans une galerie html (avec les commentaires en iptc je crois), ou directement dans flickr entre autres.
Je n'ai pas testé f-spot, mais comme cela utilise mono, je préfère l'éviter.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: digiKam vs F-Spot
Posté par 태 (site web personnel) . Évalué à 2.
# Rawstudio
Posté par Edouard Gomez (site web personnel) . Évalué à 3.
rawstudio
Libre, basé sur dcraw pour la partie decodage du raw, le reste de la chaine de traitement est faite maison, optimisée MMX/SSE/3DNow! pour Intel/AMD 32/64bit.
Voir: http://rawstudio.org/
[^] # Re: Rawstudio
Posté par carlo . Évalué à 4.
L'offre libre étant succinte et l'offre proprio en 64 bits étant pratiquement nulle, je me suis retrouvé à explorer Rawstudio (http://rawstudio.org) et Ufraw (http://ufraw.sourceforge.net/).
Ufraw semble plus abouti pour la manipulation des RAW et a l'avantage d'avoir un meilleur support des profils de couleurs [1] mais malheureusement son mode de travail photo par photo ne me paraît pas du tout pratique.
Rawstudio lui par contre a un support profil de couleurs expérimental mais offre un mode de travail de type workflow très intéressant. En gros, vous sélectionnez un répertoire et Rawstudio y scanne tous les fichiers RAW qu'il vous met à disposition. Vous pouvez ensuite les prioriser pour organiser votre travail voire les effacer.
Une autre fonction très intéressante est la possibilité d'avoir 3 modifications A B C en même temps sur chaque photo. Cela permet de faire des tests et de les comparer en direct avant de choisir (ou pas).
La fonction crop (retaillage) et de "réorientation" (on met droit en prenant un repère sur la photo) sont également très pratiques.
À côté de ça, quand on veut exporter une photo, il suffit d'ajouter le travail courant (une des modifs A B ou C sur une photo) dans le batch (traitement par lot). On peut ainsi accumuler des exports et les exécuter tous ensemble à la fin du travail (contrairement à ufraw qui par exemple exporte photo après photo).
Il manque juste le support des EXIF et autres XMP dans ces exports.
Bien évidemment, toutes ces manipulations ne modifient pas le fichier RAW (c'est le principe) mais sont stockées dans un répertoire .rawstudio
Vous l'aurez compris, rawstudio c'est bien mangez-en. Et la version disponibles dans Debian testing/unstable qui est celle dont je parle est encore mieux que les précédentes et très stable.
Enfin un logiciel qui s'approche des logiciels de workflow propriétaires.
De la doc à cette adresse : http://rawstudio.org/Getting_started.pdf
Dans la même idée, bluemarine (http://bluemarine.tidalwave.it/) semble vouloir pousser encore plus loin le concept de workflow numérique sous licence libre, mais malheureusement, pour l'instant aucune possibilité d'édition n'est encore disponible... à suivre donc.
carl0:
[1] un truc effroyablement compliqué mais néanmoins nécessaire pour ne pas avoir de vilaines surprises, et qui consiste à étalonner scanner, écran, imprimante, en clair toute la chaîne de travail. mots clés : ICC, RGB.
[^] # Re: Rawstudio
Posté par Borax (site web personnel) . Évalué à 1.
# jbrout
Posté par manatlan (site web personnel) . Évalué à 5.
jbrout est en python/pygtk, donc s'intègre à gnome (sans toutefois respecter la hig ;-) ... c'est multi plateforme (win/linux).
Ce n'est qu'un gestionnaire de photo, tentant de n'utiliser que des standards (exif/iptc/jpeg-comment) pour gérer ses photos (et bientôt xmp, car à terme, ça utiliser libexiv2).
ça n'oblige pas non plus d'avoir une certaines méthode pour classer ses photos (contrairement à fspot qui duplique tout). Ca laisse à l'utilisateur le soin de s'organiser comme il le désire.
C'est calibrer pour gérer des collections énormes de jpeg (pas de raw, pas de tif (mais peut être bientôt les tifs (cf libexiv2))). Et contrairement à beaucoup, il ne genere pas des thumbnails, ou n'utilise pas les thumbs nautilus ... il utilise les "internal exif thumbnail" (mini image contenu dans les données exif), et se débrouille pour que celle ci soit toujours en adéquation avec la vraie image. Quand on a plus 30000 photos, ça ne vas pas emcombrer les hdd avec des thumbs, alors que ces thumb existe déjà dans la jpeg, dans ses données exif.
Il n'y a pas de bdd, tout est stocker dans les photos, et dans le filesystem. (il y a certes une bdd xml, mais elle peut être "rebuild from scratch at anytime" ... et sert uniquement pour booster les recherches/affichages)
jbrout ne s'occupe que du taggage/recherche/classement d'albums/photos ... et fait accessoirement visionneuse. Mais sait également appeler des applis externes (genre gimp, script/batch imagemagick, etc ...) sans détruire les sacro saintes données internes de l'image (exif/iptc ...). Le taggage se fait très rapidement au drag'n'drop ou au clavier.
Accessoirement, des plugins gravitent autour pour fournir d'autres options bien utilies, export (vers ftp/filesystem/gallery)) / mail / serveur_http / upload flickr-picasa (l'upload picasa ne marche plus actuellement)
Les gros manques par rapport aux consorts ci-dessus, c'est le support des formats TIF et RAW, et le support de l'XMP. Mais l'intégration de libexiv2 devrait améliorer les choses.
NON le "J" ne veux pas dire que c'est fait en java (mais jpeg), et OUI : l'interface n'est pas ce qui se fait de mieux en ihm, mais reste très pratique et rapide à l'usure ;-)
[^] # Re: jbrout
Posté par rangzen (site web personnel) . Évalué à 3.
Personne peut le battre en temps de taggage une fois qu'on comprend la bête :)
Avec en plus maintenant, l'interface en plein écran avec les cases et la complétion des tags en saisie directe, j'adore.
Tout ce qui me manque c'est l'affichage par ordre chronologique :D
[^] # Re: jbrout
Posté par cosmocat . Évalué à 2.
Quand on veux visionner ou montrer des photos, c'est plutot dans l'autre sens.
Je comprends pas vraiment l'interet du tri anti-chronologique...
Je vote pour cette fonctionnalité!
Sinon, parfait la bête. Tu as raison.
Sous windows, y'a pas mieux et sous linux je le met presque au même niveau que digikam maintenant qu'on peut sauver les tag dans les photos.
[^] # Re: jbrout
Posté par manatlan (site web personnel) . Évalué à 2.
> niveau que digikam
ça c'est de la flatterie !
allez, je te promet que dans une prochaine version, on pourra choisir dans le menu "affichage" le tri chrono ou anti-chrono
Pourquoi uniquement un tri anti-chrono ?
déjà, je ne voulais pas laissé à l'utilisateur de trier comme il voulait, ne serait-ce que pour afficher toujours dans le même ordre ... c'est moins perturbateur ... ainsi c'est toujours du plus récents au plus vieux ....
Pourquoi le sens anti-chrono ?
si tu cliques par exemple sur un "repertoire/album maitre" (celui au sommet de tous tes albums), tu auras de suite les plus récentes en 1er.
si c'était l'inverse : t'aurai toujours tes plus vielles en premier ... et logiquement, elles ne bougeront jamais ;-) ...
C'est ultra "pratique - logique - simple" que de savoir que les premières sont plus récentes (celles tout en haut) que les dernières (celles tout en bas)
# Chaine colorimetrique
Posté par Fabien Engels . Évalué à 3.
Je crois me souvenir que c'etait l'une des forces des Mac mais qu'en est il pour Linux ?
[^] # Re: Chaine colorimetrique
Posté par oliv . Évalué à 3.
[^] # Re: Chaine colorimetrique
Posté par Alexandre (site web personnel) . Évalué à 3.
http://bellette.tuxfamily.org/pixelpost/index.php?x=page&(...) (et tant pis pour la pub)
(Bon, ok c'est une rustine, mais ça marche très bien quand on s'habitue à la manip)
# calibrage?
Posté par Loïc Jaouen . Évalué à 3.
La première étape est la calibration de l'écran, comment avez-vous résolu ce problème?
J'ai une sonde malheureusement inutilisable sous Linux.
[^] # Re: calibrage?
Posté par dark_moule . Évalué à 7.
Pour faire simple vous avez 2 cas possibles :
Votre sonde est compatible avec avec Argyll sous Linux :
Dans ce cas http://www.argyllcms.com/ et http://www.littlecms.com/
Sinon il faut utiliser Windows ; récupérer le profil généré sous c:\windows\system32\spool\drivers\color\ et l'utiliser sous Linux avec http://www.etg.e-technik.uni-erlangen.de/web/doe/xcalib/
Voilà, j'espère que ces informations vous aurons été utile.
Pour ceux qui ne peuvent pas faire l'investissement ou louer une sonde, vous pouvez essayer de calibrer votre écran sans matériel : http://blog.all-pixels.com/?p=14
# Rawtherapee
Posté par Mailik . Évalué à 6.
http://www.rawtherapee.com/forum/viewtopic.php?t=145 (Mai 2007)
Hi Janne,
thank you for the polite mail. I get several rough mails from open source fans forcing me to switch to GPL ("you owe the open source community...", etc.).
There is only one reason to keep the source closed: I would like to earn some money with it (as I have put so much effort in it). I dont want to be a millionaire, I just want to live a bit easier (in the Hungarian circumstances).
I can promise the following two things:
a) If I can not devote time into the development, I will release the source code under GPL
b) If I collect a given amount of donation, I switch to GPL. (Now I am at 1.5%)
Best regards
Gabor
Bibble est pour l'instant celui que je trouve le plus efficace pour dévelloper des raw. Mais, il est dommage qu'il ne supporte pas le dng.
[^] # Re: Rawtherapee
Posté par dark_moule . Évalué à 4.
J'ai dû me mélanger les pinceaux avec http://rawstudio.org.
Du coup ça m'a cassé le moral, c'est une triste nouvelle. Tous mes espoirs se portent maintenant vers digiKam pour avoir un logiciel complet. Encore quelques améliorations et il sera très intéressant.
J'en profites également pour répondre à satan (c'est inquiétant dit comme ça), qui, dans son commentaire http://linuxfr.org/comments/869882.html#869882, remarque ma confusion quand je parle de digiKam.
Je voulais comparer ce logiciel à ces concurrents Bibble et Raw Therapee. Il ne propose pas du tout les mêmes fonctions que The Gimp et n'en a pas la vocation.
Il lui manque encore un peu de maturité pour être vraiment intéressant mais je suis son développement avec beaucoup d'attention.
Merci à tous pour vos précisions et rectifications. Peuvent-elles être intégrés à la dépêche par un modérateur ?
[^] # Re: Rawtherapee
Posté par Mailik . Évalué à 4.
Ba c'est pas si horrible. D'aprés ce que je comprend, il veut juste faire un peu de sous avec. Libérer les sources lorsque les dons auront atteint un certain seuil.
Reste plus qu'a attendre une version plus évoluer et savoir le seuil en question.
[^] # Re: Rawtherapee
Posté par dark_moule . Évalué à 2.
Pour le seuil en question, on peut l'estimer avec les informations qu'il donne sur son site.
D'une part, il indique qu'il a reçu en mai 2007 1,5% du montant avant de le passer en GPL. De l'autre, en date du 24 août, que 80 dons lui ont été fait.
Si l'on considère une population de x donateurs lui ont transmis x 5$ ; x 10$ et x 25$, et qu'il y a eu également une répartition équitable des dons sur toute la période alors on obtient un chiffre très fiable de 30.000$.
Cette méthode de calcul utilise une fonction que seuls quelques initiés savent manier, mais rassurez elle a fait ses preuves !
[^] # Re: Rawtherapee
Posté par Mailik . Évalué à 1.
# Pixel Image Editor
Posté par mccob . Évalué à 2.
cf. http://www.virusphoto.com/13833-10-ans-de-travail-pour-creer(...)
# gestion de collection: kphotoalbum
Posté par beb . Évalué à 1.
En ce qui concerne la gestion de collections, j'utilise personnellement kphotoalbum que je trouve assez bien fait. Le système de classement est un peu similaire à des tags, mais avec une notion de hiérarchie dans les tags (par exemple tags de personnes, lieux, évènements ...). Le seul hic, c'est que je me demande si ces infos sont portables vers d'autres logiciels. Bon, il s'agit de libre donc a priori c'est moins un souci. Existe-t-il un format de fichier un peu standard pour la classification de photos ? Ca me semble important vu le nombre élevé de photos produites avec les appareils numériques.
[^] # Re: gestion de collection: kphotoalbum
Posté par satan . Évalué à 2.
IPTC et XMP.
http://en.wikipedia.org/wiki/IPTC
http://en.wikipedia.org/wiki/Extensible_Metadata_Platform
Tu peux regarder sur le site des logiciels que tu emploies s'ils supportent les IPTC dans les jpg ou le XMP.
[^] # Re: gestion de collection: kphotoalbum
Posté par B16F4RV4RD1N . Évalué à 2.
Bref, tout cela a été pensé intelligemment.
Par contre ce que je reproche un peu à digikam c'est qu'il ne semble pas possible de faire des albums virtuels, tout en gardant l'arborescence d'origine (après plusieurs essai, je préfère finalemment classer par date (par mois, vu le faible volume de photos que l'on fait) car on s'y retrouve mieux. On aimerait pouvoir ensuite faire un album avec certaines photos et pas d'autres, mais je n'ai pas trouvé comment le faire facilement, en tout cas au pire des cas on peut s'en sortir relativement facilement avec le système d'étiquettes, et avec la fonction de recherche (recherches que l'on peut sauvegarder), on peut inclure ou pas certaines images en fonction de divers critères ; notes, mots-clés, commentaires etc.
(ps : au fait, dépêche très intéressante, merci de ces infos !)
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: gestion de collection: kphotoalbum
Posté par Batmat . Évalué à 5.
KPA prend le parti initial de ne pas modifier la photo originale. Les méta-données sont donc stockées par défaut de façon externe. La version stable des méta-données est actuellement en XML, un backend SQL arrive. Comment KPA fait donc pour retrouver les méta-données d'une image si elle est déplacée ? Très simple : il stocke pour chacune une checksum.
De plus, KPA étant compatible avec l'interface KIPI de plugins. Il peut en fait déclencher le traitement externe de tout un tas d'outils, ce que peut donc certainement faire aussi DigiKam puisqu'il me semble qu'il est aussi compatible avec KIPI.
Pour finir, quelqu'un a développé un outil qui permet d'exporter toutes les méta-données de KPA en iptc.
Personnellement, j'utilise KPA depuis maintenant plusieurs années avec une grande satisfaction. Il est extrêmement puissant et évolue sans cesse (par exemple, le portage vers Qt4/KDE4 est en cours) grâce à une communauté importante (la ml de kpa compte en effet, en plus des nouveaux utilisateurs bienvenus, un grand nombre d'habitués qui ont plus ou moins tous déjà fourni des patches ou des évolutions).
Par exemple, depuis un peu plus d'un an environ, KPA gère aussi les vidéos.
Les fonctionnalités pour annoter les images sont très optimisées pour une saisie la plus rapide possible (auto-complétion, recopie des tags de l'image précédente qu'on vient d'annoter par raccourci, etc.)
Je gère ainsi plus de 12000 photos et vidéos.
Voilà pour ma petite expérience, j'espère que ça vous donnera envie d'essayer KPA. Vous pouvez toujours jouer avec en le lançant avec l'option -demo. Une base de test sera ainsi chargée pour vous permettre de voir son fonctionnement.
http://kphotoalbum.org
[^] # Re: gestion de collection: kphotoalbum
Posté par B16F4RV4RD1N . Évalué à 2.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: gestion de collection: kphotoalbum
Posté par Batmat . Évalué à 2.
http://mail.kdab.net/mailman/pipermail/kphotoalbum/2007-Sept(...)
[^] # Re: gestion de collection: kphotoalbum
Posté par Laurent Morel . Évalué à 1.
Je connais peu digikam, mais comme tu dis ça doit être faisable par des étiquettes (un peu bidouille quand même).
Je voulais vous parler d'un script que j'utilise pour faire tirer mes photos (environ 1 photo sur 10) : j'ai créé des étiquettes 'aTirer' et 'aTirer2Fois' dans digikam, et ces tags se retrouvent dans la base sqlite. Ensuite un simple script python permet de "sortir" (copier) les images ayant un tag donné dans un répertoire temporaire qui contient in fine toutes les photos à tirer (avec des doublons pour aTirer2Fois).
Le script est peut-être un peu long pour être posté ici, les curieux peuvent me le demander. C'est plutôt pratique je trouve... Après la copie, je préfère revenir sous digikam pour filtrer les images à tirer, leur enlever le tag, et le remplacer par le tag 'tirée' (ceci devrait être fait fonctionnellement par le script, mais je n'ai pas osé écrire dans la base ; en outre l'opération est rapide sous digikam)
# Digikam traite les fichiers RAW
Posté par mathusael . Évalué à 4.
[^] # Re: Digikam traite les fichiers RAW
Posté par abramov_MS . Évalué à 6.
Tiens ca coute combien une licence photoshop maintenant?...
[^] # Re: Digikam traite les fichiers RAW
Posté par zebra3 . Évalué à 3.
http://www.amazon.fr/Adobe-Photoshop-cs3-v10/dp/B000OV12UW/r(...)
=> 1 049 ¤
Encore un qui a profité du bug d'Excel...
(À ce prix, je préfère m'acheter une bonne machine et y installer Gimp)
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Digikam traite les fichiers RAW
Posté par Olivier LAHAYE (site web personnel) . Évalué à 3.
# Photo numérique et écran
Posté par Quzqo . Évalué à 5.
En revanche, je crois qu'il est difficille d'aborder la photo numérique et la retouche sur ordinateur sans dire un mot sur la calibration de l'écran et le respect des couleurs, surtout lorsqu'on souhaite traiter du RAW.
Il y a un fil de discussion sur le forum Ubuntu-fr intéressant à ce sujet : http://forum.ubuntu-fr.org/viewtopic.php?id=83221
En bref, pas glorieux mais des solutions existent.
Note personnelle: l'argentique aussi c'est magique \o/
[^] # Re: Photo numérique et écran
Posté par Drakho . Évalué à 3.
Tout d'abord pour parler de la calibration (étape ô combien importante dans le traitement des images).
Mais aussi pour la note personnelle : vive la magie des Velvia50 et autres Tri-X \o/
[^] # Re: Photo numérique et écran
Posté par Anthony Jaguenaud . Évalué à 1.
Ah, nostalgie des 30x45 ou on voit les defauts du papier à la loupe...
[^] # Re: Photo numérique et écran
Posté par Drakho . Évalué à 0.
Mon FM2n et mon F5 sont nourris régulièrement à la Velvia (et à la Provia 100F) et sont toujours aussi fringuants.
J'ai d'ailleurs encore quelques rouleaux au frigo et vais en exposer certains d'ici une semaine et demi =)
# Attention avec DcRaw !!
Posté par romu . Évalué à 3.
La plupart des logiciels "Pro" ou assimilés qui utilisent DcRaw ne l'utilisent que pour lire les informations du fichiers et absolument pas pour faire le décodage de l'image, cette remarque est au moins valable pour Bibble et Lightzone. Ce decodage étant ensuite de la cuisine interne qui fait une grosse partie de la "valeur" du logiciel en question.
RawTherapee n'utilise pas DcRaw mais mais des algo à lui, très performants.
Pour ceux équipés en Canon, il y a la possibilité de faire tourner le logiciel maison DPP via Wine. Ca marche mais j'aime pas DPP.
# renommage avec jhead
Posté par Wawet76 . Évalué à 3.
Avec jhead en ligne de commande : jhead -nf%Y_%m_%d_%H%M%S *.JPG
[^] # Re: renommage avec jhead
Posté par DerekSagan . Évalué à 1.
[^] # Re: renommage avec jhead
Posté par Wawet76 . Évalué à 4.
# Un album photo très simple pour le web
Posté par Pierre Jarillon (site web personnel) . Évalué à 6.
C'est l'½uvre de Jean-Charles Pernot suite à une discussion sur la liste technique de l'ABUL. De nombreux abonnés de cette liste ont participé à sa mise au point.
L'originalité de Squarely est d'utiliser exclusivement les informations exif et les commentaires JPEG contenus dans les photos. Ainsi quand on ajoute ou enlève des photos, il n'y a absolument rien à lancer ou à modifier.
Les commentaires JPEG peuvent être lus et écrits avec Konqueror (propriétés) ou kuickshow ou les commandes wrjpgcom et rdjpgcom.
L'intérêt des commentaires exif et jpeg est qu'ils voyagent avec la photo, on est sûr de ne jamais les perdre alors que les logiciels "galeries" et "albums photos" sont très jolis mais leur pérennité n'est pas garantie.
# Comment c'est que je fais moi
Posté par 태 (site web personnel) . Évalué à 3.
La première chose que je fais est de classer mes photos dans une arborescence du style année/mois/date_et_heure.jpg à l'aide d'un tout petit script python.
Ensuite, si je veux « tagger » des photos, j'ai une arborescence voisine dans laquelle j'ai un arbre de tags genre albums/places/Belgique/Brugge ou albums/people/Famille/Géraldine qui contiennent des liens vers les photos. J'ai un applescript qui me permet de créer ce lien automatiquement quand je regarde une photo avec FFView (voir plus loin pour mes questions sur les viewers). Et donc il est facile de voir toutes mes photos de famille ou toutes les photos prises à Brugge, Belgique (mais pas celles de Brugge, USA).
Je synchronise ces arborescence sur mon baladeur pour pouvoir les transporter et les montrer aux gens (branchement sur télé, tout ça).
J'ai un autre script python qui me crée un album web statique de photos, qui me permet de temps en temps de partager mes photos pour que ma famille ou mes mais les voient.
Récemment, j'ai découvert le geotagging. J'ai créé deux scripts qui me permettent de rentrer les coordonnées où se trouve google earth dans les exif d'une photo et inversement d'ouvrir google earth au bon endroit quand je veux voir où a été prise une photo. Je me suis ensuite mis à renseigner les champs city, country et quelques autres des tags xmp d'un certain nombre de photos. Et pour faire cette opération de tagging, j'utilise exiftool qui est vraiment le couteau suisse pour les métadonnées (essayez-le).
On en arrive à mes problèmes et questions :
1) je n'ai pas de moyen simple (un script un peu efficace) pour obtenir toutes les photos ayant un certain tag xmp. J'ai donc besoin de conserver ces données dans un autre stockage (j'ai essayé avec une petite bdd postgresql et mon système de liens), mais c'est fatigant et cela fait double emploi. J'ai essayé f-spot que j'aime beaucoup, mais quand je suis sous Mac OS X, je ne l'ai pas (je ne veux pas y installer gnome, ni mono).
2) Sous Mac OS X, je me suis rendu compte que les profils de couleurs n'étaient pas bien gérés par tous les logiciels, je suppose qu'il en est de même sous linux. Petit exemple, une même image visualisée avec Preview (qui lit le profil (je crois que ça s'appelle icmp)), FFview, Xee et feh http://static.zooomr.com/images/3376810_8452ac1cc9_o.png on voit bien que les couleurs ne sont pas les mêmes.
3) J'ai du python, de l'applescript, du script shell pour gérer tout ça. L'applescript m'impose d'utiliser Preview ou FFView, les autres logiciels que j'aime bien ne le gèrent pas. J'aimerais éventuellement simplifier tout ça, mais ça marche en fait plutôt bien.
[^] # Re: Comment c'est que je fais moi
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 1.
Tu pourrais publier cela... j'avoue que je suis en train de m'organiser et et d'évaluer les différents logiciels (avec un penchant pour Digikam), et j'ai quelques Go de photos à organiser sous cette forme (année/mois/date_et_heure.jpg ) a partir des Exif...
Je t'en serai au moins dix mille fois reconnaissant...
[^] # Re: Comment c'est que je fais moi
Posté par briaeros007 . Évalué à 2.
CR=*.cr2 if [ -n "$CR" ] then for i in *.cr2 do DATE=`exiftool -d "%Y-%m-%d" -p fmt "$i"` mkdir "$DATE" 2>/dev/null mv "$i" "$DATE" done fiBon ensuite tu peux modifier le format de la date. Par exemple le stocker dans uen variable, puis découper cette variable en deux l'un en un 'mois' et l'autre en un 'date et heure et seconde' puis faire le mv qui va bien[^] # Re: Comment c'est que je fais moi
Posté par MrLapinot (site web personnel) . Évalué à 4.
[^] # Re: Comment c'est que je fais moi
Posté par briaeros007 . Évalué à 3.
/me recherche
Petit coquinou c'est pas la section 'writing' mais la section renaming.
Pour ceux que ca intéresse ca semble etre cet exemple :
exiftool -r ’-FileName<CreateDate’ -d %Y-%m-%d/%H%M_%%f.%%e dir
Both the directory and the filename may be changed together via the "FileName" tag if the new "FileName" contains a ’/’.
The example above recursively renames all images in a directory by adding a "CreateDate" timestamp to the start of the
filename, then moves them into new directories named by date.
# Irfanview like pour linux ?
Posté par Guillaume57 . Évalué à 2.
Car pour la gestion de lot, je n'ai pas encore trouvé mieux. Certes on va me rétorquer que tout peut se scripter, mais même si j'en suis capable, et que j'ai quelques scripts qui trainent par ci, par là, je n'ai jamais rien vu de plus rébarbatif que de gérer des photos de manière non "visuelle".
[^] # Re: Irfanview like pour linux ?
Posté par Guillaume57 . Évalué à 1.
[^] # Re: Irfanview like pour linux ?
Posté par Sano . Évalué à 3.
Quand j'ai cherché un équivalent sous linux, j'en ai testé pas mal, et je me suis rabattu sur Gwenview.
Il est parfaitement intégré à mon KDE (aperçus sous konqui entre autres), est capable d'utiliser les kipi plugins (y compris les batch), ...
Un très bon soft IMHO.
*Sano*
[^] # Re: Irfanview like pour linux ?
Posté par Pierre Jarillon (site web personnel) . Évalué à 2.
[^] # Re: Irfanview like pour linux ?
Posté par Frédéric COIFFIER . Évalué à 1.
Si quelqu'un avait le courage de porter Kuickshow sur une librairie récente (Qt4 ou imlib2) !
# Bibble vs Digikam pour les RAWs
Posté par Frédéric COIFFIER . Évalué à 1.
Avec Digikam en 16-bit, il y a des problèmes pour la gestion des profiles de couleurs et dcraw (les images sont trop sombres à cause d'un mauvais gamma) et il est assez difficile de trouver le bon profil de couleur (cf http://linuxfr.org/comments/845906.html#845906 ). Mais bon, ça permet d'avoir un seul logiciel à tout faire (ou presque : Gimp reste utile pour les petites retouches, suppression de tâche, etc...).
A priori dans le domaine du logiciel libre, en dehors de UFraw et Digikam, il n'y a guère mieux pour le développement des RAWs.
J'ai voulu essayé Bibble mais que ce soir en version lite ou pro, j'ai des crashs dès que j'ouvre un fichier RAW. J'ai baissé la taille du cache à 200Mo (j'ai 640Mo de RAM) mais ça n'a pas changé grand chose. Il semble qu'il y ait beaucoup d'options disponibles.
Pensez-vous que Bibble est un minimum si on veut travailler en RAW ?
[^] # Re: Bibble vs Digikam pour les RAWs
Posté par gpe . Évalué à 1.
Bibble est pas mal du tout mais il a un gros défaut, qui fait que je ne l'utilise pas, c'est le rendu des couleurs qui est vraiment très spécial notamment sur les verts qui sont très flashy.
# Linux et la photo
Posté par Nicolas LS . Évalué à 0.
Picasa n'existe pas pour Linux a proprement dire, il fonctionne (même la dernière version) via Wine. Par rapport aux deux sus-cités, il offre : plus de fonctionnalités, une meilleure ergonomie, un mode de gestion des photos qui me convient plus et surtout beaucoup plus de stabilité et fiabilité...
F-spot est très instable, je l'ai quitté quand il a fini par m'oublier quelques tags et me mélanger un millier de photos... Digikam est très compliqué (un peu lent a mon gout), et offre finalement des fonctionnalités qui ne sont pas celles que je cherche et n'offre pas celle que je cherche.
En bref, rien n'arrive a la cheville de Picasa qui même sous Wine se paye le privilège d'être le plus rapide et le plus stable (et de loin).
Pour le développement des photos, j'utilise UFRAw, mais c'est très occasionel et je n'ai pas eu l'occasion d'explorer plus ce domaine.
# distribution spécialiseés sur garbure.org
Posté par jihell78 . Évalué à 1.
Il y a un site dédié aux stations de travail spécialisées : http://garbure.org/
On peut y trouver, entre autres, la distribution galantine, spécialisée dans l'édition pré-presse.
jihell78
# Et pour faire un web-album ?
Posté par gc (site web personnel) . Évalué à 4.
Pour faire un court rappel, historiquement les logiciels pour générer des web-album permettaient de créer des vignettes et une série de fichiers HTML à mettre sur son site web (on parle de Web-Album statique). On peut citer par exemple WebAlbum.pl[1] de Denis Havlik qui était déjà disponible en 1999.
Plus récemment, un système plus souple est apparu : des sites offrant un upload online et un hébergement du web-album (Web-Album dynamique) ; le processus devient plus simple, et on n'a pas besoin de gérer l'hébergement (avec la problématique de la taille importante prise sur disque). On peut citer bien sûr l'ultra-célèbre Flickr[2] ou encore Picasa Web[3].
Pour finir maintenant avec ma pub perso : j'étais personnellement insatisfait des fonctionnalités des logiciels du premier type, et peu intéressé par le deuxième type, j'ai donc créé mon propre logiciel, booh[4] en 2005 pour pallier ce problème. Il s'agit d'un Web-Album statique qui offre certains avantages que je vous laisserai découvrir sur le site web si vous êtes intéressés.
[1] http://natura.di.uminho.pt/~jj/perl/WebAlbum.pl
[2] http://www.flickr.com/
[3] http://picasaweb.google.com/
[4] http://booh.org/
# Non gimp n'est pas adapte a la photographie
Posté par EchoPapaMike . Évalué à 7.
Pour la photographie, c'est d'autant plus important que l'on peut avoir une source echantillonnée a plus de 8 bits ( scanner ou raw de l'appareil photo ) .
Par contre krita sait le faire . ( Comme le leader de chez Adobe ) .
Gimp 2.4 n'aura pas cette evolution . Donc il faudra attendre au moins 1 an .
C'est une arlesienne pour gimp .
Il y'a eu un fork ( gimp film qui est devenu cinepaint ) , qui date de gimp 1.X .
En conlusion , je dirai que gimp 2.2 & 2.4 , ne sont pas les bon choix pour un traitement numerique de l'image ( photo , cinema , image medical ) .
[^] # Re: Non gimp n'est pas adapte a la photographie
Posté par gc (site web personnel) . Évalué à -4.
Pour la photographie, c'est d'autant plus important que l'on peut avoir une source echantillonnée a plus de 8 bits ( scanner ou raw de l'appareil photo ) .
Hum, les yeux ont du mal à différencier 7 bits de profondeur, sur le vert et dans les meilleures circonstances - et sachant que le vert est la couleur où les yeux ont la meilleure sensibilité[1]. Si on doit bien multiplier la sensibilité par 2 pour s'assurer de ne pas perdre de données dans les différentes manipulations informatiques qui sont de nature discrètes (donc arriver à 8 bits), l'augmenter encore me semble inutile. Y a-t'il une raison particulière pour avoir besoin de plus ?
[1] voir l'image que j'ai mise dans http://en.wikipedia.org/wiki/Highcolor#16-bit_highcolour
[^] # Re: Non gimp n'est pas adapte a la photographie
Posté par EchoPapaMike . Évalué à 6.
8 bits suppose qu'il y'a un rapport de 1:256 entre le blanc et le noir .
16 bits suppose qu'il y'a un rapport de 1:65536 entre le blanc et le noir .
voir l'introduction de de la page suivante http://luxal.dachary.org/webhdr/
Une zone peut etre blanche avec en echantillonage 8 bits , par contre avec un echantillonage 16 bits et un traitement supplementaire , on peut faire resortir des details .
Ce n'est pas pour rien que les studios de cinema , utilisent 16 bits , que les images medicales sont des tiff 16 bits .
[^] # Re: Non gimp n'est pas adapte a la photographie
Posté par Olivier LAHAYE (site web personnel) . Évalué à 10.
- Le brun en 8bit: raytrace une sphère brune brillante et tu aura de joli cercles autour du reflet, car l'oeil n'a pas une sensibilité comparable à du RGB. Dans les bruns, il est bien supérieur à ce que peut rendre un espace RGB 8 bits.
- Lorsqu'un spectre est très endomagé (exemple: photo sous-marine: le rouge), tu peux amplifier ce spectre et avoir un peu moins de solarisation
- Lorsque ta photo as de forts contrastes, des sur expositions ou des sous expositions, les traitements détruisent moins les zones claires ou sombres.
- Il ne faut pas confondre le rendu et le traitement. Si tu ignore les color profile et convertis les valeures 16bits en 8bits par moyennage, le rendu est fade et le contraste perdu.
PS: ta photo effectivement n'a que peu d'intéret en 16bits. 8bits suffisent amplement.
PPS: ce n'est pas parce-que peu de gens ont besoin du 16bits que ça excuse gimp de ne pas le gérer....
Mon avis perso est que the gimp est un logiciel d'un autre temps qui a eu ses heures de gloire mais qui accuse la viellesse aujourd'huis.
- Manque d'intégrations des les desktops (ne tire pas partie des API (file requesters, print dialogs, standard plugins, ...)
- Pas de gestion des technologies modernes (16bits, color profiles, géolocalisation, ...)
- Ergonomie atypique le rendant très difficile d'accès à un novice (essaye de tracer une flèche sur une photo pour pointer un détail)
[^] # Re: Non gimp n'est pas adapte a la photographie
Posté par oliv . Évalué à 8.
En outre, Gimp est un logiciel pour retoucher/traiter l'image, donc il faut tenir compte que les modifications de la couleur vont faire perdre beaucoup d'information. Tu commences avec une image 8 bits, tu changes le gamma, refais la balance des blancs, augmentes le contraste, et tu as vite fait de te retrouver avec une image 6 bits ou détériorée par des arrondis successifs des valeurs :-(
16 bits ou bien virgule flottante, c'est essentiel. D'ailleurs, tous les logiciels le font (PS, PSP, Pixel, Krita, Cinepaint...). Tous sauf un.
[^] # Re: Non gimp n'est pas adapte a la photographie
Posté par maderios . Évalué à 2.
Quant aux nombre de couleurs, l'oeil humain peut distinguer "à peine plus" de sept millions de couleurs.
Parce que, au départ, à la différence de Photoshop, Gimp n'a pas été fait pour la photographie.
"L'art est fait pour troubler. La science rassure" (Braque)
[^] # Re: Non gimp n'est pas adapte a la photographie
Posté par satan . Évalué à 6.
Euh.
The GIMP n'est ni un outil de simulation de peinture à la Painter, ni un outil vectoriel à la Inkscape. Si il n'est pas fait pour la photographie, il a été fait pour quoi ? dessiner des boutons .gif d'une page web ?
[^] # Re: Non gimp n'est pas adapte a la photographie
Posté par maderios . Évalué à 2.
Photoshop est un outil qui a été conçu dès le départ par des professionnels pour les professionnels et surtout pour les photographes. Gimp me semble avoir été fait pour les pages web et tout ce qui concerne l'écran. Ce qui me fait dire cela : 95 % des fonctions de Gimp sont inutiles pour la photographie dite "professionnelle". Il manque par contre certaines choses indispensables, dont le 3x14 ou 3x16 bits.
"L'art est fait pour troubler. La science rassure" (Braque)
[^] # Re: Non gimp n'est pas adapte a la photographie
Posté par peau chat . Évalué à 4.
Gimp est d'une autre époque. C'est un bricolage.
C'est, certes, un magnifique bricolage, mais qui date d'une époque où le logiciel libre n'avait pas encore la prétention de s'adresser aux professionnels (mis à part les professionnels de l'informatique).
[^] # Re: Non gimp n'est pas adapte a la photographie
Posté par gpe . Évalué à 1.
[^] # Re: Non gimp n'est pas adapte a la photographie
Posté par maderios . Évalué à 2.
Photo Shop a toujours été un logiciel de Photo Montage, quel que soit le mode d'acquisition des images numériques, scanner ou boitier numérique.
"L'art est fait pour troubler. La science rassure" (Braque)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.