Darktable : entrevue avec Johannes Hanika

Posté par  (site web personnel) . Édité par ZeroHeure, palm123, Nils Ratusznik et Benoît Sibaud. Modéré par tuiu pol. Licence CC By‑SA.
46
4
déc.
2014
Graphisme/photo

Darktable est un logiciel de développement de négatifs numériques d'images photographiques sous licence GPLv3. C'est une « table lumineuse » et une « chambre noire » pour photographes. Il permet également de gérer vos négatifs numériques dans une base de données.

Il y a deux ans, je vous proposais une entrevue avec le créateur de la police Linux Libertine, Philipp H. Poll, et je voudrais vous proposer aujourd'hui une entrevue avec le créateur de Darktable : Johannes Hanika.

Sommaire

Cette entrevue a été menée en anglais par courriels. La version ci-dessous a été traduite en français par mes soins. Néanmoins, la version originelle se trouve dans les commentaires de cette dépêche.

— Pourrais-tu te présenter s'il-te-plaît ?

Salut, je m'appelle Jo (Johannes Hanika), le créateur du projet Darktable. J'ai étudié l'informatique multimédia en me concentrant plus particulièrement sur l'informatique graphique, et je suis actuellement chercheur pour Weta Digital (à Wellington) et Kit (à Karlsruhe).

— Qu'est-ce qui t'a poussé à créer Darktable ? Dans le dépôt officiel, on peut voir que le premier changement archivé date du 5 avril 2009 ; y travaillais-tu avant cette date ?

J'ai commencé à travailler sur ce projet juste après la nouvelle année 2008/2009. J'essayais alors de mettre en place un flux de travail de traitement d'images brutes sur ma machine Linux, et je ne trouvais rien qui fonctionnait de manière satisfaisante pour moi. En ce temps-là, Rawtherapee n'était pas open source, et ma version personalisée de glibc ne me permettait pas de lancer l'exécutable ; UFraw produisait de superbes résultats, mais il était limité au traitement d'une seule image à un instant donné ; enfin, Rawstudio n'était pas raffiné comme il l'est aujourd'hui. Ainsi, je ne pouvais pas faire ce que je voulais, du moins pas pour un millier d'images.

— L'équipe principale travaillant sur ce logiciel est composée d'environ 15 membres. Que penses-tu de l'aide du reste de la communauté ?

Je dois dire que j'adore notre communauté. Tout le monde est sympa et construtif ; il y a de grand photographes, des utilisateurs braves qui se battent pour tester toutes les fonctionnalités que nous produisons, et, bien sûr, quelques codeurs très intelligents. Nous avons tous des priorités différentes sur ce que nous pensons qui est important pour Darktable, mais chacun est animé par son propre entousiasme de créer quelque chose de super. Je pense que l'on est plutôt doués pour combiner toutes ces approches hétéroclites.

— Darktable n'est pas disponible sous Windows. Penses-tu qu'il conviendrait aux utilisateurs d'Adobe Lightroom s'il l'était ?

Je ne suis pas sûr de comprendre. Je ne connais quasiment rien sur Windows. Et, bien entendu, tout le monde est libre d'utiliser Darktable ou quelques autres logiciels qu'ils préfèrent : ça n'a pas d'importance. La seule chose qui m'importe c'est de maintenir une communauté sympathique pour que ça reste amusant de travailler sur Darktable.

— Darktable ne semble pas avoir de feuille de route périodique. Y a-t-il des règles pour connaître ce qui va se retrouver dans la prochaine sortie majeure ?

Tel que je l'ai mentionné, nous sommes tous animés par ce que nous pensons être bien pour Darktable. Malheureusement, nous avons également une vie, donc chacun contribue avec une nouvelle fonctionnalité quand elle est prête.

— Darktable a participé au Google Summer of Code en 2011. Comment cela s'est-il passé ? Penses-tu que cette expérience sera renouvelée dans le futur ?

En résumé, non. Parce que nous sommes à court de mentors, et que l'on ne peut pas utiliser l'argent reçu.
Le mentorat est la source de deux problèmes. Le premier, puisque la plupart d'entre nous a une vie très chargée, c'est qu'on ne peut pas assurer un temps minimum de mentorat de manière fiable sur une période donnée. Le deuxième, c'est que l'on implémenterait la fonctionnalité nous-même bien plus rapidement que n'importe quel étudiant (parce que l'on connait déjà bien notre code), peut-être même en moins de temps que le mentorat lui-même.

Le souci avec l'argent (ce qui est également vrai pour les donations), c'est que nous n'avons pas, aujourd'hui, d'organisation à but non lucratif associée avec Darktable, donc accepter de l'argent est un cauchemar au niveau des impôts. En outre, la somme que l'on pourrait espérer récolter serait probablement équivalente à un ticket de cinéma mensuel pour chaque développeur, à peu de choses près.

— D'après toi, quelle partie de Darktable nécessite un peu plus de soins, et sur laquelle l'aide de la communauté serait la bienvenue ?

Nous sommes toujours heureux d'ajouter une meilleure gestion pour les modèles d'appareils photo les plus récents, ce qui nécessite des images de tests de plusieurs sortes de la part des utilisateurs (distorsion des lentilles, pré-configurations de la balance des blancs, profils de bruits, courbes de base, etc.). En outre, traduire Darktable et le manuel utilisateur demande beaucoup de travail, et nous avons besoin d'aide. Enfin, créer des tutoriels (vidéos) et des styles (dtstyle.net) constituent des ressources inestimables pour les nouveaux utilisateurs.

— Darktable est sous licence GPLv3. Cette version de la GPL est connue pour diviser au sein de la communauté de logiciels libres. Aujourd'hui, que penses-tu de ce choix ? Referais-tu le même choix si tu en avais la possibilité ?

Je pense que je peux parler pour la plupart d'entre nous dans l'équipe, et je peux dire que les histoires de licences ne nous intéressent pas vraiment. À l'époque, nous utilisions du code sous GPLv3, qui a été presque totalement enlevé aujourd'hui, donc Darktable était forcé d'utiliser cette licence également. Quant à ma partie, je ne verrais pas d'inconvénient à changer de licence s'il y en a le besoin.

— Qu'as-tu en tête quant au (long) futur de Darktable ? As-tu une muse d'inspiration secrête ?

Comme je l'ai dit, c'est un effort communautaire. En ce qui me concerne, Darktable a toutes les fonctionnalités nécessaires depuis quelques temps déjà. Mais de nouveaux développeurs arrivent avec de nouvelles idées, et ils implémentent des choses qui s'avèrent utiles dans mon flux de travail également.

Je tiens à remercier chaleureusement Johannes Hanika pour le temps qu’il a passé a créer ce logiciel de qualité, mais aussi pour le temps qu’il a bien voulu consacrer à mes questions.

Aller plus loin

  • # Ce logiciel est magnifique!

    Posté par  . Évalué à 4. Dernière modification le 04 décembre 2014 à 16:57.

    Pour ce que je l'ai utilisé en tout cas. Je l'ai compilé et installé sous Gentoo. L'interface est attirante (j'ai un petit faible pour les thèmes sombres) et les fonctions sont innombrables. Je me suis retrouvé à farfouiller dans l'interface et à découvrir des effets, bon, dont je ne comprenais pas toujours le sens d'après le nom mais le tout est relativement intuitif. La pile annuler/refaire, aussi, c'est le "détail" qui sauve. Les fonctions de retouche globale sont époustouflantes de simplicité comparé à d'autres logiciels (je rame parfois dans Gimp, par exemple).

    Y a juste un truc que j'ai pas compris. Après tout ce temps d'utilisation (et au risque de passer pour Perceval), je n'ai toujours pas trouvé de menu pour "enregistrer" (j'ai peur de faire «Ctrl+S» car je n'ai pas envie de modifier l'image de base) ni pour "enregistrer sous"…

    • [^] # Re: Ce logiciel est magnifique!

      Posté par  (site web personnel) . Évalué à 7.

      Il n'y a rien à "enregister" donc normal! Toutes tes actions sont systématiquement enregistrés dans une base de données et un .xmp. Pour créer l'image avec tes modifications tu dois "exporter" depuis la "Table lumineuse" ton image en jpeg, tif…

    • [^] # Re: Ce logiciel est magnifique!

      Posté par  . Évalué à 4.

      Les transformations sont non destructrices. L'image originale (typiquement une image RAW) n'est jamais détruite. DT se contente de mémoriser les modification appliquées à chaque image. Il est possible de dupliquer les images (voir le menu 'selected image[s]' du mode Lighttable. Désolé pour l'anglais mais je ne suis pas en locale Fr) pour obtenir des variantes de la même image.

      Pour obtenir la version finale en JPG, PNG TIFF … il faut utiliser la fonction "export selection" du mode Lighttable. Les images exportées sont controlées par un 'pattern' de nommage. Il faut juste s'assurer que l'export n'écrase pas les originaux (ce qui n'est pas censé arriver par défaut).

      La partie que je ne trouve pas très intuitive est la classification des images. On s'y perd vite entre les 'films rolls', les couleur, les stars, les tags et les groupes. En général, je me contente de marquer les images qui m'intéressent avec une couleur (c'est visuel et c'est facile avec F1, F2, F3, …) avant de tagger l'ensemble de la couleur (via le menu tagging).
      ```

  • # négatif numérique

    Posté par  . Évalué à 7.

    Pour l'inculte que je suis dans le domaine de la photographie, un négatif c'est une pellicule argentique sur laquelle les couleurs sont "inversées".
    Une exploitation basique de mes capacités cérébrales m'amène à imaginer qu'un négatif numérique serait un scan de cette pellicule.

    Et du coup s'il s'agit simplement d'inverser les couleurs entre la photo finale et le négatif, quel est l'intérêt de «gérer vos négatifs numériques dans une base de données» par rapport à gérer vos photos dans une base de données ?

    • [^] # Re: négatif numérique

      Posté par  . Évalué à 9.

      Abusivement, on parle de « négatif » pour le fichier RAW (c’est à dire le fichier « brut de capteur », sans aucun post-traitement).

      Darktable est un outil dédié au traitement de ces fichiers raw.

      Sinon, pour répondre au commentaire du dessus, darktable est « non-destructif », dans le sens où il ne modifie pas le fichier d’origine. Il n’y a pas de bouton « sauvegarder », mais il y a un bouton « exporter en jpeg ».

      C’est un super logiciel de part ses capacités, mais il n’est pas « tout public ». Malgré sa relative simplicité d’utilisation, c’est un logiciel qui s’adresse avant tout à un public qui souhaite passer du temps à traiter ses photos pour en tirer le meilleur. La courbe d’apprentissage peut rebuter les moins motivés.

      Il y a quand même de supers tutos dispos sur le net.

      Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0

    • [^] # Re: négatif numérique

      Posté par  . Évalué à 4.

      je pense qu'il parle du format RAW

      • [^] # Re: négatif numérique

        Posté par  (site web personnel) . Évalué à 3. Dernière modification le 04 décembre 2014 à 18:27.

        Oui, le RAW. Et même si c'est un peu un abus d'appeler un RAW un "négatif numerique" ce n'est pas si faux que cela. Un RAW n'est pas une image et nécessite une balance des blancs et un espace de couleur pour donner vie aux informations brutes du capteur. Sans parler de la courbe de réponse qui caractérise chaque capteur.

    • [^] # Re: négatif numérique

      Posté par  . Évalué à 3.

      Ce que l'on appelle "négatif numérique" est en réalité un fichier de type "RAW". En réalité cette appellation n'a rien à voir avec les caractéristiques physiques d'un négatif argentique (pellicule), mais plutôt avec sa fonction et sa place dans la chaîne de développement.

      Je m'explique :
      Un négatif n'est pas exploitable en soi, il faut le développer pour obtenir la photographie finale. Pour les fichiers RAW, c'est pareil. Il s'agit des données brut du capteur qu'il faut "dématricer", dans le but d'obtenir une image exploitable.

      • [^] # Re: négatif numérique

        Posté par  . Évalué à 2.

        il faut le développer pour obtenir la photographie finale

        Le film négatif est déjà développé. Il faut tirer l'image, c'est à dire mettre le film négatif dans l'agrandisseur pour projeter l'image sur un papier sensible et ainsi obtenir un tirage papier. Par ailleurs, je suis entièrement d'accord sur le fait que le terme 'négatif numérique' pour désigner le raw est un abus de langage.

        Poster une information ne signifie pas nécessairement adhésion

    • [^] # Re: négatif numérique

      Posté par  (site web personnel) . Évalué à 4.

      Une pellicule n'est pas forcement inversée au niveau des couleurs. Il l'est pour les tirages papiers (on parle de effectivement de négatif), mais pas pour les diapositives (on parle de film inversible). C'est d’ailleurs directement le morceau de pellicule qui se trouve dans une diapo (après développement).

  • # LightZone

    Posté par  (Mastodon) . Évalué à 2.

    Je ne connaissais pas.

    A installer et à comparer en face de LightZone.
    http://lightzoneproject.org

    • [^] # Re: LightZone

      Posté par  . Évalué à 2.

      Pour avoir testé Darktable, venant de LightZone (que j'avais même acheté en son temps), c'est le jour et la nuit. Je ne doute pas que Darktable soit in-fine plus puissant que LZ, mais c'est au prix d'une complexité hallucinante…quand on connais la simplicité de LZ.

      • [^] # Re: LightZone

        Posté par  . Évalué à 1.

        Je ne connais pas LightZone. En revanche, je connais pas trop mal Darktable, pour l’utiliser régulièrement.

        Peux-tu détailler un peu les points qui te font dire que Lightzone est beaucoup plus simple à utiliser que Darktable ?

        J’ai l’impression que c’est principalement quelques détails d’interface qui feraient la différence, mais le diable se cache effectivement dans les détails.

        Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0

        • [^] # Re: LightZone

          Posté par  . Évalué à 2.

          L'interface est effectivement le point d'entrée dans un logiciel, donc oui, tout est là.

          1. Les outils : il y en a une petite dizaine sur LZ, et c'est tout. Quelques dizaines sur DT ? C'est très fouilli, il y en a beaucoup trop, on ne sait pas bien ce qu'ils font, certains sont visibles de base, d'autres non,…

          2. La retouche sélective : LZ a été le premier logiciel à implémenter la retouche sélective, et c'est fait très intuitivement avec les "régions". Je sais qu'avec DT c'est possible, mais de mémoire (cela a peut être changé), c'est très alambiqué.

          Après, j'ai laissé tomber DT quand je suis passé chez Fuji, donc j'ai pas trop suivi, et puis j'ai mes marques avec LZ, qui me convient bien. Cela dit, il est loin d'être parfait aussi, et n'évolue quasiment plus, c'est bien dommage.

  • # Darktable

    Posté par  . Évalué à 2.

    Essayé plusieurs fois, mais rebuté par l'interface "à la machinshop". Une icône a toujours un sens évident, pour celui qui l'a dessinée! et quand en plus elle est minuscule…
    A quand une interface à la Gimp, et la possibilité d'ouvrir directement une image avec Gimp (aucun logiciel ne sait tout bien faire !!!)

    • [^] # Re: Darktable

      Posté par  (site web personnel, Mastodon) . Évalué à 3.

      GIMP n'est en effet pas vraiment adapté par le "développement" des RAW (même s'il me semble qu'il y a un plugin pour la prise en charge de l'ouverture de certains formats RAW), de même que Darktable ne fera pas tout ce que fait GIMP. Une possibilité d'ouvrir une image directement dans GIMP est donc un besoin réel. Et d'après leur blog, il y a eu un essai d'implémentation en passant par GEGL, mais cette branche de développement est toujours en standby, sauf erreur.

      Pour résumer, le problème évoqué dans ce lien est que GIMP est destructif, à l'heure actuelle, alors que Darktable est uniquement non destructif. Cela signifie que si vous avez une image dans Darktable, vous l'envoyez dans GIMP, puis elle revient dans Darktable, vous avez perdu des données au passage. C'est très faisable, puisque les RAW sont en général en très haute résolution, donc la perte peut être très raisonnable (même dans un contexte pro avec envoi à l'impression), mais ce n'est pas "parfait". Et apparemment les dévs de Darktable veulent la perfection. Et cette perfection n'est atteinte qu'avec un workflow 100% non destructif et un export unique, à la toute fin du traitement. Il faudrait pour cela donc pouvoir passer de Darktable à GIMP, puis Darktable encore, puis GIMP, et boucler ainsi sans jamais faire le moindre export dans un format intermédiaire (même pas un format dit "non destructif" comme PNG, puisque c'est en fait destructif, si par exemple on travaille sur plus de 16 bits par canaux, et plus simplement parce que cela implique un merge des "effets", filtres et autres étapes de travail dans l'image).

      Malheureusement cela ne sera probablement pas possible avant GIMP 3.0.
      GIMP 2.10 aura la prise en charge interne de GEGL complète, mais sans l'interface. Ce qui signifie un potentiel de travail non-destructif, mais dans les faits sera toujours destructive.

      Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

      • [^] # Re: Darktable

        Posté par  . Évalué à 3.

        Je pense que Gimp et DT sont complémentaires. DT est parfait pour effectuer le développement des RAWs avec des transformations globales. Gimp peut venir dans un second temps pour toutes les retouches qui s'appliquent à des petites parties de l'image.

        Il est vrai que le fait que Gimp ne prenne pas bien en charge les images avec plus de 8bit par canal peut être gênant mais, a moins de vouloir faire du HRD, on s'en sort généralement assez bien car les opérations qui exploitent ces bits supplémentaires sont surtout du ressort de DT. Je pense par exemple à toute la gestion des brightness/contrast/exposure/highlights/shadows qui bénéficie grandement des bits supplémentaires fournis par les fichiers RAWs.

        Quand à GIMP 3.0, j'ai 45 ans et je doute de le voir avant ma retraite :-)

        • [^] # Re: Darktable

          Posté par  . Évalué à 3.

          je suis complètement d'accord avec ton commentaire, le gimp et darktable ont des objectifs différents, mais complémentaires.

          de mon côté, j'ai installé mon premier linux (une redhat 5.2 de mémoire défaillante) A CAUSE DE gimp. J'étais en début de carrière dans un labo photo. J'étais tellement enthousiaste que j'ai participé à la traduction du manuel (gum) sur les calques.

          Le temps passe (je n'ai cinq ans de moins que toi), et je constate que le portage vers GEGL est chronophage, certes, mais qu'il avance. Comme dit alex666 : y'a qu'à compiler.

          Bref, j'espère que tu verras gimp 3.0 avant ta retraite !

          En tous cas, merci à Jiehong pour ses interviews pertinentes, et à Johannes pour s'être prêté au jeu !

        • [^] # Re: Darktable

          Posté par  (site web personnel) . Évalué à 1.

          DT est parfait pour effectuer le développement des RAWs avec des transformations globales. Gimp peut venir dans un second temps pour toutes les retouches qui s'appliquent à des petites parties de l'image.

          C'était le cas avant la version 1.4 de DT. Depuis, il est possible de créer des masques et d'appliquer des filtres sur certains masques, voire appliquer plusieurs instances d'un filtre aux réglages différents, chacun sur un masque spécifique. C'est surpuissant ! Je n'ai plus besoin de Gimp depuis.

        • [^] # Re: Darktable

          Posté par  . Évalué à 1.

          Je pense que Gimp et DT sont complémentaires.

          Pour ceux qui connaissent, DT c'est l'équivalent le Lightroom (Adobe) et Gimp l'équivalent de Photoshop. Les premiers ont un rôle historique bien distinct des seconds. Cependant, tout comme dans une suite bureautique, il y a au fur et à mesure des versions des recouvrements fonctionnels qui brouillent un peu les pistes pour les non initiés (surtout dans un sens en fait : outils de développement raw qui acquièrent des capacités de retouche ; dans l'autre sens il s'agit plus de plugin ajoutant le développement raw dans le logiciel de retouche que de véritable intégration).

          • [^] # Re: Darktable

            Posté par  . Évalué à -9.

            DT c'est l'équivalent le Lightroom (Adobe) et Gimp l'équivalent de Photoshop

            ou le contraire

            • [^] # Re: Darktable

              Posté par  . Évalué à 1. Dernière modification le 05 décembre 2014 à 11:09.

              Je ne comprends pas ce qu'apporte cette remarque (c'est une vraie question). En plus elle est ambiguë par rapport à l'affirmation concernée : on peut ainsi penser que DT est plutôt l’équivalent de Photoshop et Gimp l'équivalent de Lightroom (même si je soupçonne que ce n'est pas ça que tu voulais dire).

              • [^] # Re: Darktable

                Posté par  (site web personnel) . Évalué à 2.

                100% d'accord avec toi, la remarque n'apporte rien bien au contraire. Et oui dt = Lightroom et Gimp = Photoshop au niveau du but recherché et du type de travail supporté.

        • [^] # Re: Darktable

          Posté par  (site web personnel, Mastodon) . Évalué à 4.

          Il est vrai que le fait que Gimp ne prenne pas bien en charge les images avec plus de 8bit

          Pour info, la version 2.10 à venir prendra en charge plus de 8 bits. Et quand je dis ça, c'est pas juste 16. La version de dév actuelle va même jusqu'à 64 bits par canal (ensuite pour qui cela est-il réellement utile d'aller si haut? Probablement presque personne à l'heure actuelle, mais au moins on ne pourra plus accuser GIMP de ne pas prendre en charge de hautes précisions de couleur, ahahah).

          Quand à GIMP 3.0, j'ai 45 ans et je doute de le voir avant ma retraite :-)

          C'est mérité! Il est vrai que le temps entre 2 versions majeures est terrible à l'heure actuelle. :-)

          Mais perso j'espère que nous verrons une amélioration de ce problème. On y travaille!

          Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

      • [^] # Re: Darktable

        Posté par  . Évalué à 1.

        Pour le prétraitement des raw, j'utilise gimp-ufraw, qui existe et fonctionne! et dans les cas difficiles, nécessitant de passer en 16 bits, il y a Gimp 2.9… yaka compiler!
        Tout ceci n'a strictement RIEN à voir avec la résolution.
        Pour le non destructif, en attendant "mieux" (???), je sauvegarde mes fichiers raw…

      • [^] # Re: Darktable

        Posté par  (site web personnel) . Évalué à 9.

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

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

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

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

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

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

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

        • [^] # Re: Darktable

          Posté par  (site web personnel, Mastodon) . Évalué à 4.

          Oui et non. Le problème n'est pas tellement d'être destructif ou non, c'est d'être répétable.

          C'est exactement ce que signifie "non destructif" dans ce contexte. Ou pour être plus précis: on doit toujours pouvoir revenir aux données d'origine, au bit près, quoi qu'on fasse dans l'image.
          D'où ma remarque sur les formats d'image dits "non destructifs" ("non lossy" en anglais), comme png, qui — bien qu'utilisant le même terme — ont en réalité un sens différent dans ce contexte et sont destructifs pour le coup.

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

          C'est exactement de ce dont on parle, et ce dont parle le blog post de Darktable que j'ai donné en lien.
          Avoir une pile d'opérations au dessus de l'image plutôt que de modifier les pixels eux-même est en effet la technique employée à l'heure actuelle pour avoir un flot de travail non destructif. Surtout que même si l'opération était théoriquement bijective, dans les faits si c'est une opération mathématique, l'imprécision sur les nombres peut rendre la bijectivité caduque. Ensuite la haute précision des canaux de travail aide, mais cela reste toujours plus sûr de ne jamais toucher à l'image d'origine.
          Ensuite quand est-ce que cela arrivera? Espérons avec la 3.0, si on développe l'UI nécessaire pour cela.

          Pour info, GEGL doit permettre de pouvoir partager des "buffers GEGL", c'est à dire en gros l'image en cours de travail, donc 2 programmes sont théoriquement capables de travailler en même temps sur la même image, de manière non destructive, ce qui sera d'une grande aide pour le flot de travail souhaité.

          Cela posé, je reviens sur une de tes phrases précédentes:

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

          Donc si dans ce contexte, ça a du sens de lancer GIMP dans le flot de Darktable. Que se passe-t-il si tu changes les réglages côté Darktable? Ben dans le workflow idéal qu'on veut tous faire: tu verrais les modifications dans GIMP aussi. Ces modifications auront la forme d'une opération GEGL (un "nœud" dans le graphe des opérations, comme dans le node éditor de Blender en gros). Si GIMP a l'UI adaptée, il serait même capable de modifier les paramètres de l'opération ajoutée par Darktable (et dans tous les cas, il est capable d'en voir le résultat qui passe à travers le moteur GEGL).
          Et inversement en modifiant dans GIMP, dans Darktable, cela sera juste une opération supplémentaire que Darktable pourrait être capable de modifier, ou au moins supprimer si l'utilisateur le voulait.

          Et donc jusque là, on est tous les deux entièrement d'accord. :-)

          La perte d'information, ce n'est pas sur la résolution (l'export en .png la conserve sans problème par exemple), mais sur la profondeur des pixels.

          Ben les deux quoi. Et pas seulement d'ailleurs comme je disais, puisque c'est surtout sur le graphe même des opérations effectuées qu'on veut sauvegarder (sans jamais toucher aux pixels d'origine), comme je disais plus haut. Ce que signifiait ma phrase, c'est que si tu travailles sur de la très haute résolution, faire 2 opérations destructives similaires sauvera un peu tes billes. Ensuite cela dépendra des opérations.

          Certaines opérations font des calculs sur la valeur des pixels, et dans beaucoup de cas ces calculs sont destructifs. Ex: 3/2 = 1 et 2/2 = 1 dans une précision en entier (et ce même si tu avais une précision super haute!). En faisant ce calcul, on a perdu des données (en faisant l'opération inverse, 1 * 2 = 2, on ne peut être sûr qu'on retombe sur le bon nombre d'origine. Ça se trouve, c'était 3). Dans ce cas, une haute précision des canaux aide beaucoup en effet car la très haute précision signifie que la différence entre 2 et 3 est suffisamment minime pour que l'œil humain ne fasse pas la différence. Donc la perte est toujours réelle, mais acceptable.

          D'autres opérations ne font pas de calculs sur la valeur des pixels, mais peuvent par exemple les déplacer. C'est le cas de la rotation dont je parlais tout à l'heure. Pour la rotation, la précision des canaux impacte beaucoup moins. Tu peux avoir une précision de canal aussi haute que tu veux, ça ne change pas grand chose. À certains angles (cad hors 90/180/270°), tes pixels qui étaient bien alignés vont se retrouver non alignés, avec certains pixels qui peuvent sauter et d'autres creés (en moyenne des canaux de pixels limitrophes), etc. Avoir une très haute résolution est ce qui te sauve tes billes dans ce cas, puisque t'as tellement de pixels que les pertes peuvent passer inaperçu. C'est en ce sens que travailler en haute résolution peut produire des pertes raisonnables.
          C'est donc tout aussi important, cela dépend vraiment du type d'opération appliquée sur ton image.

          Mais au final, encore une fois, ce n'est pas la vraie solution. La solution est de ne jamais toucher l'image d'origine du tout, et donc de ne modifier ni leur valeur, ni leur position. C'est là ce qu'on appelle "non destructif" dans le contexte de cette discussion.

          Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

          • [^] # Re: Darktable

            Posté par  (site web personnel) . Évalué à 2.

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

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

            • [^] # Re: Darktable

              Posté par  (site web personnel, Mastodon) . Évalué à 3.

              Bah justement non. L'outil « spot removal » ou le retaillage avec « crop and rotate » ne sont pas du tout non-desctructif au sens « bijectif » par exemple.

              Non c'est pas bijectif en tant qu'opération mathématique, mais c'est non destructif dans le sens où on peut revenir à l'image d'origine au pixel près si c'est fait comme une opération "rejouable", c'est à dire au dessus de l'image d'origine, qui elle reste intouchée. Donc à tout moment, on peut juste annuler le crop (ou en changer les paramètres). On ne détruit donc jamais les données d'origine.

              En tous cas, c'est ainsi que cela fonctionne avec GEGL (et à ce que j'ai compris aussi dans Darktable?). Donc c'est non destructif. C'est là le sens qui est donné à "non destructif" quand les équipes de GIMP ou de Darktable le mentionne dans ce contexte.

              Disclaimer: je suis un des dévs de GIMP.

              Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

  • # Version originale en anglais

    Posté par  (site web personnel) . Évalué à 5. Dernière modification le 05 décembre 2014 à 02:43.

    J'ai un peu de retard, ce qui fait que ceci n'est pas le premier commentaire de la dépêche, excusez-m'en.

    Avec l'accord de Johannes Hanika, la version originale, donc ce commentaire, sont sous licence CC-BY-SA 4.0.


    — Could you please introduce yourself and your background?

    hi, i'm jo, the project founder of darktable. i studied media informatics with emphasis on computer graphics, and am currently working as researcher for weta digital (wellington) and kit (karlsruhe).

    — What pushed you to create Darktable in the first place? On the official repository, we can see that the first commit appeared around the 5 April 2009; did you actually worked on it before that time?

    i started to work on this just after new years 2008/2009. i was trying to set up a raw workflow on my machine on linux and there was simply nothing there that worked satisfactorily for me. at the time rawtherapee wasn't open source and my custom compiled glibc wouldn't allow to run the binary, ufraw produced great results but would just work on one single image at a time, and rawstudio didn't have the refined pipeline it has today. so i simply couldn't produce the results i was after, at least not for 1000s of images.

    — The main team working on the software is composed of about 15 members. What do you think about the help from the rest of the community?

    i have to say i really love our community. everybody is nice and constructive, there are great photographers, hardcore users who battle-test every feature we release, and of course a couple of very clever coders. we all have different priorities of what we think is important for darktable, but everybody is driven by their own enthusiasm to create something great. and i think we do a good job at combining all those different approaches.

    — Darktable is not available on Windows. Do you think it would directly face Adobe Lightroom users if it were?

    i'm not sure i understand. i know next to nothing about windows. and of course everybody is welcome to use darktable or any other software they like better, it doesn't really matter. the only thing i care about is maintaining a nice community, so it stays fun working on dt.

    — Darktable does not seem to have a time-based release. Are there any rules to know what should make it to the next major release, and when?

    as i mentioned, we're all driven by what we think would be a great addition to darktable. unfortunately we also have lives, so everybody contributes their new feature by the time it is done.

    — Darktable participated to the Google Summer of Code in 2011. How did this experience go? Do you think Darktable will renew this experience in the future?

    quick answer: no, because we're short in mentors, and we can't use the money. the mentoring thing has two issues. first, since most of us have very busy lives, we can't reliably contribute mentoring time over a certain period. second, we would probably implement the gsoc feature ourselves a lot faster than any student could possibly do it (because we already know our way around in the code), maybe even in less time than the mentoring would take. the issue with the money (also true for donations) is that we don't currently have any not-for-profit organisation associated with darktable, so accepting money is a taxation nightmare. also the amount we could hope to raise would probably be as much as one ticket for the movies for every developer per month or so.

    — According to you, what part of Darktable needs more polishing and on which the help of the community would be welcomed?

    we're always happy to include better support for newer camera models, which requires test shots of various sorts from users (lens distortions, white balance presets, noise profiles, base curves, etc). also translating dt and the user manual is a lot of work and could need help. creating (video) tutorials and styles (dtstyle.net) are great resources to teach new users.

    — Darktable is licenced under the GPLv3. This version of the GPL is known to divide people amongst the free software community. Today, what do you think about this choice? Would you choose the same licence if you could?

    i think i can speak for most people in the team and say that we don't really care about licensing. at the time we were using some GPLv3 code which mostly got removed now, so dt was forced to use that licence, too. for my part i'm happy to relicense to whatever if there is a need for it.

    — What do you have in mind for the (long) future of Darktable? Do you have any secret inspiration muse for that?

    as i said, it's a community effort. for my part, dt has been feature complete for quite some time now. but new devs come with new ideas and implement things which turn out to be useful for my workflow, too.

  • # Typos dans la depeche

    Posté par  . Évalué à 5.

    cauchemard

    => cauchemar

    Par ailleurs, le lien sur dtstyle.net devrait pointer vers "http://dtstyle.net" et pas "http://linuxfr.org/news/dtstyle.net"

    Merci pour l'interview!!!

  • # Digikam traite également les fichiers raw

    Posté par  . Évalué à 0.

    Pour info
    http://scribblesandsnaps.com/2011/05/04/process-raw-files-in-digikam/

    Poster une information ne signifie pas nécessairement adhésion

  • # Dérawrisation et commentaires

    Posté par  (site web personnel) . Évalué à 4.

    J'utilise de plus en plus darktable pour traiter mon flux de photos et encore plus depuis que je suis passé au tout RAW. Après une prise en main un peu difficile mais grâce à ces vidéos je comprends mieux le fonctionnement : https://www.youtube.com/watch?v=3Kh3YB3LbNc&list=PLZOdZMT41b7W0IBntprxOOqlw54iiKRMb .

    Ce matin en ouvrant les photos de la séance d'hier juste pour regarder sans volonté de traiter je me disais "Alors sur celle-la il faudrait faire ça, et puis elle ça…". Mais mince y a pas de module pour mettre un commentaire genre "note pour plus tard". Je pourrais détourner le champ description des meta mais comme ça n'a pas volonté de suivre la photo après traitement ça ajouterais une étape supplémentaire de devoir penser à enlever le commentaire pour la version final.

    Ca pourrait être d'autant plus intéressant si on est plusieurs à travailler sur les mêmes photos.

    Qu'en pensez-vous ?

    Born to Kill EndUser !

  • # Interface

    Posté par  . Évalué à 2.

    Petite question :

    Est-ce qu’il y a moyen d’avoir une interface claire ? Ça pète moins à l’écran, mais je pense que ce serait plus représentatif de ce qu’on peut obtenir au tirage…

    • [^] # Re: Interface

      Posté par  (site web personnel, Mastodon) . Évalué à 6. Dernière modification le 06 décembre 2014 à 22:03.

      La tendance à l'heure actuelle pour les software graphiques est de revenir aux interfaces sombres. Ils sont tous en train d'y venir progressivement (même GIMP aura bientôt une variante sombre qui devrait être le défaut si le thème utilisé a une variante sombre).

      Apparemment il semblerait que les UIs sombres soient justement meilleures au niveau restitution des couleurs et distraient moins l'œil. Ou qqch comme cela. En particulier les couleurs grises. Apparemment certaines personnes travaillant dans le graphisme/cinéma ont l'habitude de travailler dans des salles aux murs gris et sans fenêtre. Et c'est donc la raison aussi pour laquelle les logicielles se tournent vers une UI similaire.

      Ensuite je suis pas expert. Au début aussi je me demandais s'il s'agissait pas d'une lubie type "les couleurs sombres, c'est classe", mais apparemment non. Y a des recherches sur le sujet, paraît-il.

      Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.