Linux et la photographie : état des lieux

Posté par . Modéré par Florent Zara.
1
26
sept.
2007
Linux
Ces derniers temps j'ai eu un peu de temps libre pour rechercher des logiciels adaptés à l'utilisation de mon appareil photo sous Linux. Je n'ai pas la prétention d'avoir fait un test poussé de chacun d'entre eux. Je les ai seulement utilisés en tant qu'amateur passionné de photographie. Les critères de sélection que j'ai utilisés sont en premier lieu les possibilités de traitement offertes par les logiciels, c'est évident. Il n'en reste pas moins que leur ergonomie, leur facilité de prise en main et leur intégration dans mon environnement de travail ont été très importantes.

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.])

  • Retouche d'images
    • The GIMP

  • Gestionnaire d'images (chacun ayant ses avantages et inconvénients)
    • F-Spot
    • digiKam
Heureux possesseur d'un PC sur lequel j'ai installé Linux, il m'arrive, parfois, d'avoir à faire des recherches pour trouver le meilleur logiciel correspondant à mes besoins du moment. Il est bien loin le temps où, sous Windows, je n'avais qu'à me contenter d'utiliser les logiciels dont les éditeurs m'assaillaient continuellement. Et oui, il faut le savoir, les Linuxiens partent eux même à la recherche de leurs logiciels...

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 libre [NdM : Raw Therapee ne semble pas libre du tout au contraire de ce qui a été publié initialement.], je vous conseille celui-là sans aucun doute.

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 :
  1. La bible de The Gimp (en français)
  2. Tutoriels officiels orientés photo
  3. Des tutos, plus plein d'infos autour de l'image numérique
Une fois votre travail terminé, quoi de plus plaisant que de pouvoir le retrouver facilement ? C'est ici qu'entrent en jeu les gestionnaires d'images.


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 :)
  • # ImageMagick \o/

    Posté par (page perso) . Évalué à  7 .

    non mais :P
    • [^] # Re: ImageMagick \o/

      Posté par . Évalué à  2 .

      tu connait un tutorial pour s'en servir sans lire les 10 000 pages du man qui me semblent inpénétrables ?
      Moi je suis preneur :-)
    • [^] # Re: ImageMagick \o/

      Posté par (page perso) . Évalué à  6 .

      On ne le dira jamais assez ImageMagick fait plein de choses très bien, change la vie et donne un beau poil. Alors sortez vous les shells du cul, vous gagnerez du temps pour certaines taches, comme traiter un répertoire entier d'image pour par exemple réduire la taille de moitié :

      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 . Évalué à  7 .

    J'en profite pour demander quel outil de diaporama pourrait produire un effet Ken Burst (du nom du photographe) sous Linux .

    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 . Évalué à  4 .

      Si tu es sous KDE tu peux essayer les plugins kipi pour digiKam et autres.
      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 (page perso) . Évalué à  2 .

        J'ai déjà essayé lorsque je recherchais la même chose ...
        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 . Évalué à  3 .

          "Je m'étais dit que si ca n'existait pas, je n'avais qu'à le coder ...
          mais faute de temps."


          Dommage , il y a de la demande et je ne suis pas développeur ...
          • [^] # Re: Effet ken burst

            Posté par (page perso) . Évalué à  3 .

            Bin oui ... c'est toujours le problème ...
            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 (page perso) . Évalué à  3 .

      dvd-slideshow[1] permet le ken-burns. C'est assez simple à utiliser si on accepte de mettre les mains dans un fichier texte de configuration, et il existe même une interface[2] faites avec gambas (et donc non disponible sur x64).
      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 . Évalué à  4 .

      Essaye GLSlideShow (dispo avec xscreensaver ou gnomescreensaver)
      • [^] # Re: Effet ken burst

        Posté par (page perso) . Évalué à  5 .

        oui, c'est ce que j'utilise : il te faut configurer le dossier contenant les images

        (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://agauch.fr

    • [^] # Re: Effet ken burst

      Posté par . Évalué à  2 .

      Perso, j'utilise ksmoothslidesaver comme économiseur d'écran openGL. Cela peut, bien sûr, servir de diaporama.
      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 (page perso) . Évalué à  8 .

    ...Pour cet article qui m'incite a aller essayer tout ça...

    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 (page perso) . Évalué à  9 .

      Je comprends pas les reproches faits à F-spot par rapport à Mono, mais bon, j'en ai aussi d'autres, moi, sans doute moins intégristes :
      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 (page perso) . Évalué à  6 .

        >Je comprends pas les reproches faits à F-spot par rapport à Mono

        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 (page perso) . Évalué à  -3 .

          Sur ma machine (qui est loin du dernier cri : simple celeron 2.6ghz et 512M de ram), au 1er lancement (ie la 1ere fois qu'on clique dessus), tomboy met quelques secondes a s'afficher, comme quasi toutes les applications, gnome ou pas. Et après, comme quasi toutes les applications, c'est instantané.

          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 (page perso) . Évalué à  6 .

            Ici, c'est 3 à 4 seconde pour tomboy même si préchargé.

            Alors que je totem pas préchargé: < 1 seconde
            idem pour gedit, ...

            Intel(R) Pentium(R) D CPU 3.00GHz
      • [^] # Re: Merci...

        Posté par (page perso) . Évalué à  2 .


        F-Spot recopie ailleurs, dans son cache à lui, les photos qu'on lui apporte


        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.


        si on les déplace ou qu'en en change le nom avec Nautilus, F-Spot retrouve plus ces billes


        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 (page perso) . Évalué à  2 .

        d'abord F-Spot recopie ailleurs, dans son cache à lui, les photos qu'on lui apporte
        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 . Évalué à  4 .

          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.
          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 . Évalué à  4 .

    Concernant Lightzone, leur attitude vis à vis de Linux est lamentable, on a attendu plus de 4 mois, sur leur forum, une réponse claire, bref pas des gens bien.

    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 (page perso) . Évalué à  3 .


      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.


      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 . Évalué à  1 .

      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.

      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 . É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 (page perso) . Évalué à  4 .

        > F-spot ne permet-il pas d'inclure les tags et les commentaires dans les photos directement ?

        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 . É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 . Évalué à  3 .

            Au contraire, je préfère ça. Et c'est là le plus important, laisser à l'utiliser la possibilité d'adopter le comportement de choix.
          • [^] # Re: My 2 cents

            Posté par . Évalué à  1 .

            C'est pareil pour Digikam et moi aussi, je trouve ça stupide ce chox par defaut...
            • [^] # Re: My 2 cents

              Posté par (page perso) . Évalué à  8 .

              C'est un choix qui se justifie par le fait qu'on n'a pas nécessairement envie qu'une application qu'on va lancer une fois pour tester se mette à pourrir les tags de ses fichiers. Par défaut, les images ne sont pas modifiées. Et si elles le sont (retouche), l'original est conservé. C'est un comportement assez sain, surtout si tu testes plusieurs gestionnaires d'images, tu ne veux pas qu'ils tentent d'écrire des choses différentes au même endroit.
      • [^] # Re: My 2 cents

        Posté par (page perso) . Évalué à  2 .

        > 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 ?

        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 . Évalué à  1 .

          bon, d'accord rien ne faut un tar cvzf

          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 (page perso) . Évalué à  3 .

          nan, mais rsync c'est tt de même bien plus adapté, hein...


          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.

          /!\ ne pas écrire a cette adresse : potdemiel@400iso.net

          • [^] # Re: My 2 cents

            Posté par . Évalué à  2 .

            voir aussi rdiff-backup pour faire de la sauvegarde incrémentale aussi simplement qu'une copie de fichier

            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 . Évalué à  3 .

              keep est un frontend (kde) à rdiff backup qui permet pour ceux qui aime les clickodrome , ou n'ont pas envie de lire une page de manuel pour le lancer automatiquent , de le faire avec peut d'effort ;)

              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 . Évalué à  2 .

              voir aussi rdiff-backup pour faire de la sauvegarde incrémentale aussi simplement qu'une copie de fichier
              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 . É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 . Évalué à  4 .

      Je suis tout à fait d'accord avec toi.
      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 (page perso) . Évalué à  8 .

        En plus, Gimp fait ses traitements en 8bits, ce qui le rend inadapté pour les traitements courant à partir de Raw (lumiere, contraste...). Donc non adapté aux photographes.
        • [^] # Re: The GIMP

          Posté par . Évalué à  2 .

          C'est bien dommage d'ailleurs. C'est une des grosses lacunes de The GIMP pour tenir le coup et être utilisable par des professionnels.

          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 (page perso) . Évalué à  1 .

            - pas de groupement d'effets sur les calques (c'est trèèès limitant pour la productivité) ;

            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 (page perso) . Évalué à  7 .

    Pour le montage des diaporamas, j'utilise depuis maintenant quelques temps hugin [1], un logiciel très performant, même si un peu difficile à prendre en main.
    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 . Évalué à  3 .

      qtpfsgui est vraiment pas mal pour la photo HDR

      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 (page perso) . Évalué à  2 .

      J'espère que tu utilises bien "enblend" après hugin ?
      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 (page perso) . Évalué à  2 .

        > Le passage par gimp ne sert quasiment plus qu'a redécouper l'image rectangulaire ensuite.

        Ç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 (page perso) . Évalué à  1 .

          Tout à fait. L'utilisation des masques de calques pour ça, c'est vraiment pratique. Notamment si la transition n'est pas parfaite (un poteau au premier plan, etc)...
  • # Choix de l'appareil photo

    Posté par . Évalué à  4 .

    Pour ma part il faut élargir la réflexion.

    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 . Évalué à  3 .

      Ben à propos du DNG, le seul logiciel propriétaire que j'ai accepté d'utiliser récemment c'est justement le convertisseur de raw vers DNG fait par Adobe.
      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 . Évalué à  3 .

        Merci pour ce bel article, et il est intéressant de remarquer qu'en face de besoins similaires, les choix convergent. Ce printemps comme delgatux je me suis offert un Pentax K10 (choisi pour les mêmes raisons) dont je suis content, puis j'ai abouti au choix bibble + Gimp + Digikam. Il est très pratique que tous les outils travaillent sur des répertoires, c'est simple et facile à gérer.

        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 (page perso) . Évalué à  1 .

          Hm... j'ai fais pareil en achetant un kadisse il y a pas longtemps, j'ai pris en compte dans mon choix le raw en dng, et bien je regrette pas.

          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 (page perso) . Évalué à  1 .

          Sauf que Bibble ne semble pas prendre en compte les DNG iirc.
    • [^] # Re: Choix de l'appareil photo

      Posté par . Évalué à  5 .

      En dehors des qualités du K10, et des bonnes intentions derrière l'introduction d'un appareil offrant un format RAW "ouvert" en plus du format maison, il semblerait que les avis soient partagés sur le format DNG:
      http://www.openraw.org/node/1482
      • [^] # Re: Choix de l'appareil photo

        Posté par . Évalué à  2 .

        Ce à quoi on peut ajouter que les constructeurs donnent accès à un raw plus ou moins brut.
        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 . Évalué à  2 .

          Une norme ouverte mais contenant des sections dont le contenu n'est pas clairement défini... DNG et OOXML, même combat?
          (c'est vendredi, c'est permis)
    • [^] # Re: Choix de l'appareil photo

      Posté par . Évalué à  5 .

      Je dois bien avouer que, si je n'avais pas été plutôt bien équipé de matériel Nikon argentique (boîtiers et optiques), j'aurai peut-être aussi pris du Pentax K10D (quoi que, niveau optiques, c'est un peu limite pour les super-télé).

      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 . Évalué à  3 .

        Optiques c'est vrai et cela m'avait fait hésiter, mais mes optiques Nikon ne sont plus utilisables sur les nouveaux boitiers de la même marque et il me reste assez de choix (en fonction de mes besoins et de mes moyens pour le Pentax). Par contre sa "tropicalisation" m'intéressait aussi et a pesé dans la balance, en temps que plaisancier je fais souvent des photos en milieu humide.
        • [^] # Re: Choix de l'appareil photo

          Posté par . Évalué à  2 .

          Normalement, toutes les optiques Nikon depuis les premières AI (1977) se montent sur tous les reflex, au pire on perd la mesure et il faut régler vitesse et ouverture à la main. Avec un numérique, c'est pas un gros problème si on est pas pressé.
          • [^] # Re: Choix de l'appareil photo

            Posté par . Évalué à  2 .

            Mais voila les miennes dataient d'avant, oui je sais c'est vieux mais elles étaient très bonnes et encore tout à fait fonctionnelles (pas rayées)
      • [^] # Re: Choix de l'appareil photo

        Posté par (page perso) . Évalué à  1 .

        Au pire il y a toujours les sigma/tamron toujours dispo sous pentax entre autres pour les super-télé (800mm & co).
  • # et picasa ?

    Posté par (page perso) . Évalué à  2 .

    Il me semble qu'il manque clairement picasa à cet état des lieux.
    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 . Évalué à  -2 .

      Pas libre.
      • [^] # Re: et picasa ?

        Posté par . Évalué à  2 .

        Et alors?

        Bibble non plus...
        • [^] # Re: et picasa ?

          Posté par . Évalué à  1 .

          Oui mais pour Bibble, c'était précisé. Pas pour Picassa dans le commentaire.
          • [^] # Re: et picasa ?

            Posté par (page perso) . Évalué à  5 .

            L'intitulé de la news étant "Linux et la photographie : état des lieux", picasa manque donc à cet état des lieux sans préjuger de son état libre ou propriétaire. La liberté implique aussi celle du choix ...

            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 . Évalué à  4 .

              > multi-plateforme win/lin
              vraiment multi-plateformes ? ça marche sur autre chose que x86 ?
              • [^] # Re: et picasa ?

                Posté par (page perso) . Évalué à  1 .

                bi-plateform alors :-)
                non, x86 only visiblement
              • [^] # Re: et picasa ?

                Posté par (page perso) . Évalué à  2 .

                Une "plate-forme", ça désigne une architecture de processeur, ou un système d'exploitation ? :-)
                Et "multi", on peut le dire à partir de combien ?
    • [^] # Re: et picasa ?

      Posté par . Évalué à  5 .

      Picassa n'est pas dans la liste puisque je ne l'ai tout simplement pas essayé.

      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 (page perso) . Évalué à  1 .

        Grand public ? sans doute. Un peu comme digikam finalement, mais en plus sexy (quelques effets visuels sympas) et avec des possibilité d'ordonnancement des photos plus évoluées (ou que je ne sais pas faire sous digikam).
        • [^] # Re: et picasa ?

          Posté par . Évalué à  1 .

          mouais, pour moi les 2 outils sont tout de même assez différents : picasa est beaucoup plus accessible, et propose finalement moin de choix: la plupart du temps on a droit à des préréglages qu'on ne peut pas modifier... et ce n'est pas obligatoirement un mal pour le photographe débutant tel que moi.

          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 . Évalué à  2 .

    J'utilise avec plaisir Gimp+UFRaw (ou UFRaw seul et Cinepaint) pour le traitement de mes photo.

    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 . Évalué à  2 .

      Pareil + gqiew pour visualiser rapidement les photos rangés à la main.

      "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

  • # Gimp vs Krita

    Posté par . Évalué à  9 .

    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.


    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 . Évalué à  3 .

      recement j'avais une vingtaine d'image a retailler en 640x480, je me dis bon je vais essayer krita:

      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 . Évalué à  5 .

        pas essayé krita pour plusieurs photo, mais dj'ai éja essayé the gimp pour modifier des panorama (assemblages de photos) ... Pas bonne idée du tout. Ca swappait vraiment a mort.

        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 (page perso) . Évalué à  5 .

          Digikam a un truc pour le batch resizing si on veut faire ça dans un clikodrome. De mémoire, c'est un plugin KIPI, donc ça doit être dispo aussi dans Kphotoalbum.
      • [^] # Re: Gimp vs Krita

        Posté par (page perso) . Évalué à  4 .

        Un cilckodrome n'est pas un bon outil pour retailler une collection de photos.
        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 . Évalué à  5 .

          oui oui j'en doute pas, je l'ai deja effectué pour d'autre travaux c'est tres bien, d'ailleurs c'est la fonction crop (-crop geometry cut out a rectangular region of the image) et pas geometry, mais là sur chaque photo c'etait un retaillage different. impossible d'utiliser un joli script. obliger de tous se coltiner a la main avec gimp, d'ou mon experience mauvaise avec krita pour ce travail.

          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 (page perso) . Évalué à  4 .

        Krita n'est pas un logiciel de traitement batch. C'est un logiciel de retouche et de dessin.

        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 . É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 . Évalué à  2 .

            Oui, la ligne droite est toute bête sous gimp.

            Là où ça se corse, c'est pour tracer un rectangle :-D
          • [^] # Re: Gimp vs Krita

            Posté par . Évalué à  3 .

            je soupconne que cela concernait un peu plus le plugin gimp gfig qui est comment dire... une bouse infame!

            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 . Évalué à  5 .

              Oui, la lenteur de développement de GIMP est un gros problème pour ce logiciel.

              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 . Évalué à  3 .

              Gimp devrait normalement passer a Gegl mais combien de temps cela va t'il prendre?
              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 . Évalué à  6 .

                Déjà que le gimp et le CMJN ça fait des années qu'on en parle, et que ça ne va sortir qu'avec la 2.4...

                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 . É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 . Évalué à  5 .


                    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.

                    Gimp sait faire tout ça depuis ses versions de dev. 2.3.x, 2.4-rc .


                    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.


                    Ça va faire bientôt 3 ans que l'on a pas eu de nouvelle version stable de Gimp (depuis Décembre 2004)


                    euh, je suppose que tu voulais dire version "MAJEURE" :

                    13 juillet 2007 : GIMP 2.2.17 Released

                    Ça vaut largement le coup de se le compiler, d'autant que les versions de dev. sont particulierement stable.


                    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 . Évalué à  2 .

                      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.


                      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 . Évalué à  4 .

                        le cmjn n'a pas d'intérêt pour un web designer par exemple


                        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 . Évalué à  1 .

      Certes Krita semble séduisant sur le papier mais dans la pratique c'est moins la joie!
      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 . Évalué à  3 .

    Je sais pas ou tu as vu ca, mais RawTherapee c'est pas libre du tout. Le code source n'est meme pas disponible.
  • # digiKam vs F-Spot

    Posté par . Évalué à  6 .

    Malgré le fait que j'utilise Ubuntu donc GNOME, j'ai fini par retenir digiKam notamment pour sa gestion des données EXIF et IPTC.

    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 . Évalué à  8 .

      j'utilise digiKam que je trouve excellent, rapide, pratique, et effectivement, l'utilisation de exif et iptc le rend très attrayant, notamment parce que l'on ne se sent pas dépendant du logiciel. De plus il utilise une base légère en sqlite, stockées si on veut dans le même répertoire que la racine des images par exemple.
      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 (page perso) . Évalué à  2 .

      f-spot est maintenant capable de lire certains tags iptc et xmp http://f-spot.org/Imported_tags et d'écrire ses metadata dans les images (jpeg uniquement), malheureusement, il semble ne pas encore écrire directement dans les tags iptc/xmp.
  • # Rawstudio

    Posté par (page perso) . Évalué à  3 .

    Un petit dernier qui commence a ressembler a quelque chose de bien:
    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 . Évalué à  4 .

      En effet, je me suis longtemps arraché les cheveux pour trouver un logiciel permettant de travailler agréablement avec le RAW.
      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 (page perso) . Évalué à  1 .

        Ufraw permet de créer des fichiers "ID", qui intègrent les paramètres de dématricage ; ces fichiers peuvent ensuite être appliqués simultanément à un ensemble de photos, via l'outil "ufraw-batch".
  • # jbrout

    Posté par (page perso) . Évalué à  5 .

    Je ne vais pas prêcher pour ma paroisse ou faire de la pub.

    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 (page perso) . Évalué à  3 .

      Fan de jbrout :)

      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 . Évalué à  2 .

        Oui, je suis assez d'accord que l'affichage anti-chronologique (les plus récentes en 1er) est assez troublant.

        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 (page perso) . Évalué à  2 .

          > Sous windows, y'a pas mieux et sous linux je le met presque au même
          > 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 (page perso) . Évalué à  3 .

    Et pour la gestion des couleurs ? Xorg est il capable de gerer des profils ? et cups ?

    Je crois me souvenir que c'etait l'une des forces des Mac mais qu'en est il pour Linux ?
  • # calibrage?

    Posté par . Évalué à  3 .

    Merci pour l'article et les bons liens en commentaires.

    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 . Évalué à  7 .

      Il existe en effet très peu de sondes utilisables avec Linux. Par contre elles peuvent-être toutes utilisés avec Windows, dans une machine virtuelle par exemple.

      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 . Évalué à  6 .

    Il me semble que rawtherapee n'est pas "Libre" comme dis dans l'introduction. Il est "juste" gratuit. La décision sur ça licence ne semble pas encore complètement arrèter.
    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 . Évalué à  4 .

      Oui, la grosse boulette. Comme l'a fait remarqué une autre personne dans son commentaire, Raw Therapee n'est effectivement pas libre. Pitié, pas de lynchage !

      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 . Évalué à  4 .

        Du coup ça m'a cassé le moral, c'est une triste nouvelle.

        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 . Évalué à  2 .

          Oui je sais je dramatise. C'est juste que ça me fait toujours plus plaisir d'utiliser des logiciels libres.

          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 !
  • # Pixel Image Editor

    Posté par . Évalué à  2 .

    Un logiciel de retouche d'images qui fonctionne sour Linux : Pixel Image Editor

    cf. http://www.virusphoto.com/13833-10-ans-de-travail-pour-creer(...)
  • # gestion de collection: kphotoalbum

    Posté par . Évalué à  1 .

    Très intéressante dépêche. Je ne suis pas encore passé au format raw pour mes photos (j'ai peur de manquer de temps pour les travailler correctement), mais je suis content d'apprendre qu'il existe de bons logiciels permettant de traiter le raw sous linux.

    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 . Évalué à  2 .

      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.
      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 . Évalué à  2 .

        au moment de la recherche d'un logiciel de classement de photos, j'hésitais entre kphotoalbum et digikam. J'ai déjà parlé de digikam plus haut, et loin de moi l'idée de vouloir vous détourner de kphotoalbum, en tout cas j'ai remarqué que la plupart des infos dans digikam sont stockées en IPTC (du coup je ne sais pas trop ce que contient la base de données), ainsi j'ai testé sur une photo où il y avait des commentaires, des étiquettes (tags) et une note, j'ai déplacé l'image dans l'arborescence, digikam ne l'a pas retrouvée et a proposé de supprimer l'entrée de l'image dans la base de donnée, ce que j'ai accepté, et en retournant avec digikam dans le nouveau dossier où se trouvait l'image, toutes ces informations se retrouvaient bien dans l'image et il les a affichées correctement.
        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 (page perso) . Évalué à  5 .

          Dans ce que tu décris de Digikam, que je ne connais pas, je ne trouve rien que KPhotoAlbum n'a pas (petit nom KPA, anciennement nommé KimDaBa pour la petite histoire).

          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 . Évalué à  1 .

          farvadin : "Par contre ce que je reproche un peu à digikam c'est qu'il ne semble pas possible de faire des albums virtuels..."
          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 . Évalué à  4 .

    Digikam traite les fichiers RAW, d'ailleurs le moteur DCRAW est commun avec Bibble. Pour ma part, j'utilise Digikam pour tout l'ouverture / téléchargement des photos, leur classement et les exports web. Pour l'impression, je "dérawtise" et j'accentue l'image (l'outil "refocus" est redoutable) puis j'enregistre en PNG que je traite sous toshop (il manque encore la notion de calque sous Digikam, a priori GIMP pourrait faire le truc, mais je le connais moins que toshop auquel j'ai accès assez facilement)).
  • # Photo numérique et écran

    Posté par . Évalué à  5 .

    Tout d'abord merci pour cet état des lieux :)

    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 . Évalué à  3 .

      Obligé de "pertinenter" ce commentaire

      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 . Évalué à  1 .

        ... Velvia50...

        Ah, nostalgie des 30x45 ou on voit les defauts du papier à la loupe...
        • [^] # Re: Photo numérique et écran

          Posté par . Évalué à  0 .

          Nostalgie ? meuh non, c'est encore d'actualité !

          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 . Évalué à  3 .

    Ce n'est pas parce qu'un soft utilise DcRaw que la qualité de décodage est la même partout.

    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 . Évalué à  3 .

    Un truc que je fais systématiquement, c'est renommer mes photos en fonction de la date et l'heure de prise de vue.

    Avec jhead en ligne de commande : jhead -nf%Y_%m_%d_%H%M%S *.JPG
    • [^] # Re: renommage avec jhead

      Posté par . Évalué à  1 .

      moi je le fais avec le numéro de déclenchement de mon boitier (chez nikon c'est une donnée exif)
      • [^] # Re: renommage avec jhead

        Posté par . Évalué à  4 .

        Le faire avec date/heure permet de mettre en ordre un gros tas de photos venant d'appareils différents. Pratique ça.
  • # Un album photo très simple pour le web

    Posté par (page perso) . Évalué à  6 .

    C'est un scipt PHP qui se nomme Squarely : http://www.agmen.fr/squarely/

    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 (page perso) . Évalué à  3 .

    Premièrement, mon appareil photo ne fait pas de raw, je ne fais pas de photos de grande qualité artistique ou de grande qualité tout court. Je n'ai donc que des besoins assez succints en termes de logiciels d'images.

    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 (page perso) . Évalué à  1 .

      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.


      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 . Évalué à  2 .

        un petit script bash que j'ai fait rapidement, tres bete et sans doute pas propre:
        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
        fi
        
        Bon 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 (page perso) . Évalué à  4 .

          Sinon, man exiftool, dans la section Writing des exemples il y en a un qui fait ça en une seule commande.
          • [^] # Re: Comment c'est que je fais moi

            Posté par . Évalué à  3 .

            meme le mkdir puis le mv ?


            /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 . Évalué à  2 .

    Est ce que quelqu'un connaitrait un logiciel sous Linux qui serait un équivalent de Irfanview sous Windows?
    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 . Évalué à  1 .

      Juste un petit ajout, j'ai essayé la version Linux de Xnview, et même si elle fait à peut près le même boulot, l'interface est des plus austères et hideuse.
    • [^] # Re: Irfanview like pour linux ?

      Posté par . Évalué à  3 .

      J'utilisais Irfanview il y a - pfiouuuuuu - longtemps.
      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 (page perso) . Évalué à  2 .

        Question de goût ! Kuickshow est à mon avis plus pratique.
        • [^] # Re: Irfanview like pour linux ?

          Posté par . Évalué à  1 .

          Kuickshow devrait être enterré depuis déjà bien longtemps ! (enfin, il devrait être marqué obsolète dans beaucoup de distribs). Il utilise encore des vieilles libs datant de gtk 1.x (imlib pour ne pas la citer) que même Gnome n'utilise plus !

          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 . Évalué à  1 .

    Etant pro-libre, jusqu'ici, j'ai utilisé UFraw et puis maintenant Digikam qui me permet de rester en 16-bit le temps de faire les ajustements (balances des blancs, contraste, accentuation, suppression du bruit, etc...).
    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 . Évalué à  1 .

      Pour Bibble si tu as un appareil de 10Mpix ou plus, 640Mo de RAM sont insuffisant. Pour 10Mpix sur le site de Bibble ils conseillent un mini de 768Mo de RAM.
      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 (page perso) . Évalué à  0 .

    Je suis un partisan du libre, j'aime bien ne pas être prisonnié d'un logiciel a cause de formats propriétaires. Cependant je dois avouer que après avoir essayé Digikam et F-Spot et quelques autres logiciels moins connu, je me suis résolu à utiliser Picasa.

    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 . Évalué à  1 .

    Bonjour,

    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 (page perso) . Évalué à  4 .

    Etant l'auteur d'un logiciel pour générer des web-album, je m'intéresse personnellement aussi à cette étape supplémentaire curieusement passée sous silence.

    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 . Évalué à  7 .

    Gimp ne sait pas traiter plus de 8 bits de profondeur par canal .
    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 (page perso) . Évalué à  -4 .

      Gimp ne sait pas traiter plus de 8 bits de profondeur par canal .
      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 . Évalué à  6 .

        Une des premieres raisons et d'avoir le plus grand spectre possible .
        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 (page perso) . Évalué à  10 .

        Les raisons qui me viennet à l'esprit:

        - 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 . Évalué à  8 .

        L'oeil est beaucoup plus performant que l'on ne croit. Il suffit de se rendre compte de la dynamique de la luminosité des objets naturels. Un simple test peut par ailleurs montrer à quel point 8 bits est bien trop limité pour l'oeil humain: Un gradient noir->blanc (R=G=B donc il n' y a que 256 niveaux de gris disponibles). Selon la qualité de l'écran, en zoomant, on peut facilement voir la différence entre deux bandes voisines (les écrans LCD ne sont pas top pour ce test, mieux vaut un CRT).
        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 . Évalué à  2 .

          Pour résumer et parler simple , 3 x 14 bits ou 3 x 16 bits permet de mieux représenter les nuances dans les ombres et les hautes lumière.
          Quant aux nombre de couleurs, l'oeil humain peut distinguer "à peine plus" de sept millions de couleurs.


          D'ailleurs, tous les logiciels le font (PS, PSP, Pixel, Krita, Cinepaint...). Tous sauf un.

          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 . Évalué à  6 .

            Parce que, au départ, à la différence de Photoshop, Gimp n'a pas été fait pour la photographie.
            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 . Évalué à  2 .

              En écrivant "Pour la photographie" je sous-entendais "pour la photographie professionnelle", qui est mon domaine d'activité.
              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 . Évalué à  4 .

                Oui, voilà, c'est exactement ça.

                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 . Évalué à  1 .

                Photoshop a aussi pléthore de fonctions dont les photographes n'ont que faire! A la base Photoshop n'a pas été conçu pour la retouche photo. Les scanners étaient hyper rare et la photo num n'existait pas quand Photoshop est sorti. Il a su évoluer et s'adapter à la retouche photo certes, mais le logiciel dédié photo chez Adobe c'est Lightroom
                • [^] # Re: Non gimp n'est pas adapte a la photographie

                  Posté par . Évalué à  2 .


                  A la base Photoshop n'a pas été conçu pour la retouche photo
                  et la photo num n'existait pas quand Photoshop est sorti

                  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 à ceux qui les ont postés. Nous n'en sommes pas responsables.