Sortie de darktable 4.0.0 : une présentation 100 % subjective

Posté par  (site Web personnel) . Édité par Ysabeau et Benoît Sibaud. Modéré par patrick_g.
61
11
juil.
2022
Graphisme/photo

darktable 4.0.0 est sortie ce 2 juillet 2022. « D’accord, mais pourquoi devrais-je en avoir quelque chose à faire ; et puis c’est quoi, darktable, d’abord ? », me direz-vous ?

Eh bien, vous êtes au bon endroit, parce que c’est le sujet de cette dépêche ! Si vous êtes du genre pressé, à ne lire que les chapeaux des articles, sachez que darktable est un logiciel libre de flux de traitement de photographies et un développeur de fichiers RAW – une table lumineuse et une chambre noire virtuelles pour les photographes. Sa nouvelle version 4.0.0 apporte des évolutions sur la reproductibilité des couleurs et de l’exposition entre des images d’une même série, sur le traitement des couleurs, sur la reconstruction des hautes lumières et sur l’interface utilisateur – entre beaucoup d’autres.

Prêts pour une visite un peu plus approfondie de ce logiciel et de ses changements ? C’est parti !

Sommaire

Où l’on parle un peu de darktable1 lui-même…

Qu’est-ce que darktable ?

D’après la page de présentation officielle :

darktable est un logiciel libre de flux de traitement de photographies et un développeur de fichiers RAW 2. Une table lumineuse et une chambre noire virtuelles pour les photographes. Il gère vos négatifs numériques dans une base de données, vous permet de les visualiser à travers une table lumineuse zoomable et vous permet de développer les images RAW et de les améliorer.

Les deux fonctionnalités principales sont donc :

La table lumineuse qui permet de trier, classer, ranger (et tous les autres synonymes appropriés) vos photographies, soit via les métadonnées (date, vitesse, ouverture, sensibilité, coordonnées géographiques…), soit par les informations saisies par l’utilisateur (notes, « pastilles » de couleur…).

La chambre noire permet d’appliquer moult traitements sur les fichiers RAW2. Ces traitements sont non-destructifs : ils ne sont pas appliqués directement sur les fichiers d’origine, lesquels resteront toujours intacts. Le résultat des traitements doit être exporté dans l’un des très nombreux formats d’image gérés par le logiciel, et tout peut être modifié avant l’export. En ce sens, le flux de traitement est très différent de ce que l’on peut rencontrer dans un logiciel de retouche d’image traditionnel, comme GIMP ou Photoshop.

On le voit, c’est donc un produit à destination des photographes, et en particulier de ceux qui possèdent du matériel dédié à cet usage : aujourd’hui, sans doute un réflex ou un hybride. darktable peut travailler sur des images JPEG (mais ça n’a pratiquement aucun intérêt, sauf pour la partie « tri »), et les RAW des rares smartphones qui en fournissent ne sont pratiquement jamais gérés.

Pourquoi choisir darktable – ou pas, d’ailleurs ?

Pour commencer, parce que vous êtes photographe – débutant, amateur ou professionnel, qu’importe – qui détient à la fois du matériel spécifique et qui a le temps et l’envie de trier et traiter vos images.

Des avantages de darktable

« D’accord, mais pourquoi lui et pas RawTherapee, DigiKam, Lightroom3, DxO PureRAW/PhotoLab ou l’un des logiciels fournis par le constructeur de mon matériel photographique », me direz-vous ? Ce à quoi je vous répondrai que vous aimez bien commencer vos remarques par « D’accord, mais… » – et que la question est pertinente.

D’abord, darktable est libre (sous licence GPL v3.0 pour être exact), ce qui est un argument majeur ici, mais ne le distingue guère de RawTherapee ou DigiKam.

Cela dit, pour moi, son principal atout est que darktable propose une approche moderne et complète de la gestion du matériel et des contraintes colorimétriques. Ce point est très technique, mais très important ; en résumé : les procédés traditionnels de traitement des photographies numériques sont très souvent anciens et partent de postulats obsolètes. Mais comme le milieu de la photographie est très conservateur (beaucoup plus que celui de la vidéo, par exemple, qui traite ces problématiques depuis des années), beaucoup de logiciels supposent encore que l’image a été prise avec un capteur à faible dynamique et sera imprimée… ce qui est généralement faux. Je vous renvoie à la lecture de cet article qui explique très bien le souci.

En parallèle, darktable laisse une totale liberté à l’utilisateur. Il ne décidera jamais automagiquement ce qui est bon pour vous : vous avez toujours le contrôle sur tous les paramètres pour obtenir le résultat exact dont vous rêvez.

Ensuite, darktable est très activement développé. Il y a une version tous les six mois – une en début d’été, l’autre aux alentours de Noël – et, comme on le verra dans la suite, ce ne sont pas des petites versions et encore moins de la simple maintenance. On trouve régulièrement de nouvelles fonctionnalités qui peuvent impliquer des travaux de recherche récents.

Enfin, darktable est performant, entre autres parce qu’il permet d’utiliser la puissance de la carte graphique à l’export, qui se fait en quelques secondes – contre plusieurs minutes par image chez certains concurrents.

Les inconvénients de darktable – parce que rien n’est parfait en ce bas monde

En fait, les inconvénients principaux de darktable découlent directement de certains de ses avantages.

Le premier et sans doute le premier important : si vous usez d’un logiciel « concurrent », vous devez désapprendre toutes vos habitudes et vous faire au flux et à la logique de darktable. Même s’il est possible d’utiliser un flux classique avec darktable, c’est passer à côté de l’un de ses plus gros atouts.

Le second, c’est que beaucoup d’innovations perturbent le flux de travail. C’est intéressant parce que ça permet de nouveaux ou meilleurs résultats, ou d’obtenir la même chose plus simplement, mais il faut accepter d’adapter sa façon de travailler à chaque mise à jour. Si c’est admissible pour un amateur comme moi, je pense que c’est plus gênant pour les professionnels.

Le troisième, mais pas le moindre : comme darktable ne décide rien pour vous, il vous impose de comprendre ce que vous faites – et même de rentrer relativement loin dans les détails pour bien appréhender certains réglages. De même, il y a énormément d’ajustements possibles, dont beaucoup ne servent que dans des cas très particuliers ; la courbe d’apprentissage est donc raide, et il est facile de se perdre dans les options. Heureusement, des travaux en cours améliorent ça – par exemple, avec des présentations « simples » des modules les plus courants, les options avancées restant présentes, mais pas affichées au même niveau.

D’autre part, certains appareils photographiques trop récents, trop anciens ou trop exotiques ne sont pas gérés. Consultez la liste de compatibilité ici. Sous Linux, vous devrez sans doute mettre à jour manuellement la base de données d’objectifs.

Il y en a d’autres, comme le fait que darktable est lent et pénible si vous ne pouvez pas utiliser la carte graphique pour les calculs, mais c’est un point commun à tous les logiciels de ce genre.

Les conseils du renard si vous vous mettez à darktable

  1. Assurez-vous de pouvoir utiliser votre carte graphique – sous Linux ça peut être délicat. Ça se vérifie dans les préférences, traitement : « activer le support d’OpenCL » doit être coché.
  2. Dans les préférences, traitements :
    • Confirmez que « Flux de travail par défaut » est « relatif à la scène ».
    • Passez « appliquer l’adaptation chromatique par défaut » à « moderne ».
    • Décochez « applique automatiquement la netteté » (si besoin, vous pouvez l’ajouter à la main avec des modules plus efficaces que celui utilisé par cette option).
  3. Lisez cette fichue documentation !

« D’accord, mais on n’a toujours pas parlé des nouveautés de la version 4.0.0 », me direz-vous. C’est exact, on y va tout de suite, et ce tic de langage est vraiment étrange.

Les nouveautés de darktable 4.0.0

Cette mouture apporte beaucoup de choses, cette liste n’a pas vocation à être exhaustive – il y a les notes de version pour ça ; mais voici les principales nouveautés et mon avis (totalement subjectif) sur icelles.

Mappage des couleurs et de l’exposition

C’est une fonctionnalité très pratique qui permet de répliquer la balance des blancs, l’étalonnage des couleurs ou l’exposition d’une photo sur d’autres, ce qui permet de garantir l’homogénéité d’une série, et de faire une balance des blancs correcte sur une image où il n’y a pas d’objet gris.

L’avis du renard : c’est une fonction très utile et intéressante, mais dont l’ergonomie, disons… « particulière » mériterait d’être revue.

Filmique v6

« Filmique » est le module qui remplace, en très gros, la courbe de tonalité appliquée par les constructeurs, mais qui fait ça de manière moderne, en embarquant toute une gestion scientifique des couleurs. En particulier, il permet d’éviter des dérives de teintes classiques avec les algorithmes anciens, surtout sur des images à haute dynamique (qui n’étaient pas du tout prises en compte par ces vieux algorithmes).

Les nouveautés sont très techniques et détaillées dans les notes version. En résumé, les cas aux limites sont mieux gérés, les couleurs restituées plus naturelles, et le flux de traitement plus cohérent d’un bout à l’autre.

L’avis du renard : je suis partagé entre l’énervement que cette fonctionnalité ait encore changé – comme tous les ans – et l’admiration du travail effectué. Les cas limites (en particulier les cieux et les hautes lumières) ont un rendu clairement meilleur… là encore à condition de comprendre ce qu’on fait et de passer tout le flux sur les nouvelles versions, sans quoi il est facile d’obtenir des résultats étranges.

Reconstruction des hautes lumières par « laplacien guidé »

C’est une nouvelle méthode de reconstruction des couleurs « grillées ». Quand le capteur a saturé, et donc que les valeurs renvoyées sont au maximum, on perd tous les détails qu’il pouvait y avoir. Et contrairement aux zones « bouchées », aucun curseur ne permet d’aller chercher des informations qui seraient présentes, mais invisibles. Cette méthode novatrice essaie de reconstruire des détails d’une façon plus « logique » que les versions actuelles.

L’avis du renard : c’est efficace sur les petites zones brulées, ça peut devenir excessivement lent sur le reste. Attention, il y a une incompatibilité curieuse entre cette option et Filmique v6 (ci-dessus) : si vous observez des couleurs étranges (souvent du magenta) dans les endroits reconstruits, il faut modifier des options dans le module Filmique. Dans Filmique, Options, passer « préserver chrominance » à « luminance Y » ou « non ». Si ça n’est pas corrigé ou si le résultat est inacceptable, dans Filmique, Options, remettre « science de couleur » à « v5 (2021) ».

Le nouvel espace colorimétrique uniforme de darktable 2022 « UCS 22 »

Encore un truc ultratechnique. Concrètement, cette nouveauté permet une meilleure gestion des couleurs, en particulier lorsqu’on modifie la balance des couleurs dans un but artistique. L’idée est de compenser l’effet Helmholtz–Kohlrausch (lien en anglais) qui fait que des couleurs visuellement de mêmes luminosités n’ont pas la même luminosité en réalité – et inversement.

L’avis du renard : je vous avais parlé du côté technique et moderne de darktable ? Ben voilà. Ce réglage du module de balance couleur est à utiliser idéalement avec Filmique v6.

La visualisation de surexposition RAW fonctionne correctement

Avant elle utilisait les données après correction de la balance des blancs, maintenant elle affiche les pixels réellement écrêtés au niveau du capteur.

L’avis du renard : un point de détail dans la liste, mais qui évite bien des surprises !

Plein d’améliorations d’interface et de performance

Parce que les petites améliorations d’ergonomie, c’est super agréable ! En particulier, plusieurs modules ont une vue avec les réglages de base seulement, ce qui évite de trop se noyer dans les options. De même, un logiciel fluide c’est toujours plus efficace qu’un logiciel qui rame.

L’avis du renard : 99 % de très bon là-dedans… et un point dommage : les cases à cocher sont trop grosses par rapport au reste sous Ubuntu 22.04…

… et plein d’autres trucs…

… que je vous laisse aller lire dans les notes de versions, parce que hein, cette dépêche est déjà beaucoup trop longue ! L’astuce, c’est que si vous ne comprenez pas un élément, c’est probablement parce qu’il ne vous concerne pas :)

L’avis du renard : les développeurs ne chôment pas ! Et tout ça, c’est libre – c’est pas beau la vie ?


En résumé, darktable est un très bon logiciel de tri et de traitement de photographies, en particulier de fichiers RAW. Toutefois, son côté touffu, technique et son fonctionnement spécifique demandent que l’on soit prêt à y passer le temps nécessaire à le comprendre et à le maitriser.

Ses différentes versions, à commencer par la très récente 4.0.0, sont touffues et apportent beaucoup d’améliorations, dont quelques-unes (comme Filmique v6 ici) ont un impact sensible sur le rendu des images et donc sur le flux de travail.

Si vous êtes photographe, débutant, amateur ou professionnel, donnez sa chance à darktable : c’est un excellent logiciel, très souple et performant, et sa difficulté d’accès est compensée par la très bonne documentation et des forums d’entraide francophones actifs.


Cette dépêche est publiée sous la licence Creative Commons Paternité, version 4.0 (licence CC BY 4.0).


  1. Oui, « darktable » sans majuscule. C’est un nom de marque, c’est comme ça même si ça fait bizarre en début de phrase. 

  2. Un fichier RAW – littéralement « brut » est l’enregistrement des données brutes du capteur photographique. Il doit être traité pour obtenir une image exploitable – comme les pellicules doivent être traitées, d’où le recyclage du terme. Employer des fichiers RAW permet de faire des choix techniques et artistiques différents de ceux imposés par l’appareil photographique, ce qui peut être utile, voire indispensable, dans certaines situations. 

  3. Adobe Lightroom est sans doute le poids lourd du genre (en non-libre)… et darktable en tire directement son nom. En effet, les deux fonctionnalités sont la table lumineuse « light table », et la chambre noire « dark room ». Ce qu’Adobe a combiné en « Lightroom »… et donc darktable a pris les deux autres termes. Maintenant, vous savez. 

Aller plus loin

  • # r-darktable

    Posté par  (site Web personnel) . Évalué à 8 (+9/-2). Dernière modification le 11/07/22 à 09:58.

    Et que penses tu du fork d'Aurélien Pierre de darktable, r-darktable, en réponse à la lourdeur de l'ergonomie de darktable, en particulier de la table lumineuse ?

    Selon ses dires, si j'ai bien compris, l'IHM est actuellement et principalement développé par des personnes qui ne comprennent pas les besoins des photographes et en particulier professionnels (qu'elles semblent même mépriser d'après lui). Elles codent des trucs que personne ne demande ou qui n'adresse aucun pb réel. Or ceci, avec le fait que Gtk est un toolkit d'un âge révolu (mono CPU, pas GPU), + avec une base de données qui est utilisée pour stocker toutes les informations des RAW ainsi que leur catégorisation (alors qu'elle ne devrait être utilisée à la rigueur que comme cache), aboutit à une lourdeur excessive de l'IHM. Par exemple, Aurélien cite qu'à chaque déplacement de souris sur une image, de multiples requêtes SQL ont lieu sur la base de données !

    Des liens :
    - son coup de gueule sur le dév actuel de l'IHM de darktable : https://www.youtube.com/watch?v=56e5Yc-IQ84
    - l'explication de pourquoi son fork : https://github.com/aurelienpierre/R-Darktable/wiki/Why-a-fork-%3F

    • [^] # Re: r-darktable

      Posté par  (site Web personnel) . Évalué à 7 (+5/-0).

      Je n’était pas au courant donc, pas grand-chose.

      Cela dit, j’ai regardé vite fait le pourquoi du comment, et les mécanismes qu’il décrit qui ont conduit aux problèmes en question (notamment, des décisions collégiales là où ça n’a pas de sens) sont un problème hélas classique des projets libres – en tous cas de ceux qui sont développés par plus de une personne.

      J’espère que son fork va pouvoir montrer des choses intéressantes qui pourront être remontées dans le projet principal.

      Je crois aussi que c’est lui qui est principalement derrière les modules Filmique et la modernisation du pipeline graphique, j’espère que ça ne va pas le dégouter de continuer à contribuer sur ces points.

      La connaissance libre : https://zestedesavoir.com

      • [^] # Re: r-darktable

        Posté par  (site Web personnel) . Évalué à 7 (+5/-0). Dernière modification le 11/07/22 à 10:59.

        Après avoir vu sa vidéo, je le trouve un peu raide quand même dans ses commentaires. Il y a plein de points sur lesquels il a raison, mais je pense qu’il surestime les problèmes posés à l’utilisateur final, parce qu’il y a certaines modifications qu’il juge gênantes qui sont en fait pratiquement invisibles. Je pense en particulier à la possibilité de réorganiser les modules, aux filtres de collections (pliés par défaut chez moi, je n’avais même pas vu qu’ils existaient alors qu’il râle plusieurs fois sur le fait que ça prendrait « un tiers de la colonne de gauche »…), au sélecteur d’étoiles qu’il trouve peu ergonomique alors que je le trouve beaucoup plus pratique que la solution précédente, ou encore au palanquées d’options que l’immense majorité des gens se contenteront d’ignorer. Ah, et aussi les lenteurs de l’interface, qui est quelque chose que je n’ai jamais constaté – même si je veux bien croire que d’un point de vue technique, on pourrait faire beaucoup mieux.

        (Digression : c’est un truc de développeur, ça, les options par tombereaux. Ça peut se justifier pour certains types d’utilisateurs qui ont besoin/envie – beaucoup « envie » en fait – de configurer chaque pixel et chaque comportement de leur outil, mais pour l’immense majorité des gens dans l’immense majorité des utilisations, l’immense majorité des options n’est que du bruit. C’est quelque chose dont les développeurs feraient bien de se rappeler, tout comme ils feraient bien de se rappeler qu’une option, c’est aussi du code pour la gérer, et plein de possibilité d’interactions imprévues qui viennent avec).

        Ce qui m’inquiète surtout, c’est que ce qu’il explique et la position des développeurs upstream ne présagent rien de bon pour le futur de darktable…

        La connaissance libre : https://zestedesavoir.com

        • [^] # Re: r-darktable

          Posté par  . Évalué à 6 (+4/-0).

          Pour pondérer ta dernière phrase, Aurélien a bien précisé (dans un commentaire sous sa vidéo polémique) que sa version n'était pas un fork a proprement parler. Enfin si, mais seulement de l'UI de la table lumineuse et ce fork repartira à chaque fois du reste de darktable auquel il continue donc de contribuer.

          Pour avoir vu d'autres vidéos d'Aurélien dans lesquels il s'insurge sur d'autres sujets, c'est un peu son tempérament. Quand il a introduit Filmique, petite révolution dans le traitement d'images de darktable (au cœur de la modernisation dont parle la dépêche), Aurélien s'est attiré énormément de commentaires parfois haineux d'utilisateurs qui n'arrivaient plus à développer leurs photos. Sa réaction a été à la hauteur… (surtout qu'il avait pris la peine de faire de longues vidéos pour expliquer le truc).

        • [^] # Re: r-darktable

          Posté par  . Évalué à 10 (+11/-0).

          Merci SpaceFox pour cet excellent article.

          Concernant le futur de darktable, ça n'est que la position d'Aurélien. Il a apporté parmi les toutes meilleures évolutions de darktable depuis près de 4 ans. Malheureusement, il a en effet le défaut d'être souvent raide et excessif dès qu'il est en désaccord. il faut donc relativiser aussi ses propos, surtout quand ils sont excessifs. Quand bien même il a souvent raison sur le fond (pas tout le temps tout de même, comme tout le monde). Pour le moment, de nombreux développeurs restent actifs. Par contre, les améliorations sur le processus de traitement devraient maintenant être minimes tant les progrès ont été énormes ces 3-4 dernières années (essentiellement grâce à Aurélien).

          Il reste maintenant de nombreuses améliorations à faire sur l'interface (dont les nouveaux filtres, qui vont dans la bonne direction mais restent encore perfectibles) et les autres parties. Et il y a des choses en cours ou prévues. Le boulot sur l'interface va continuer. Ravi de lire que tu apprécie l'amélioration de l'ergonomie.

          Je suis le principal contributeur CSS de l'interface de darktable et j'avais remarqué que les cases à cocher étaient un peu grosses, avant que mon PC me lâche complètement et parte en SAV en mai. C'est ensuite passer à la trappe. Donc, merci du rappel, je vais corriger ça pour la 4.0.1 !

          • [^] # Re: r-darktable

            Posté par  (site Web personnel) . Évalué à 8 (+7/-1). Dernière modification le 11/07/22 à 21:26.

            Merci à vous deux pour vos commentaires !

            Ma dernière phrase sur le futur de darktable, c’était plutôt à prendre dans le sens : les deux points de vue (et façon de faire) n’ont pas l’air conciliable, et je trouverais très dommage pour le projet que vous vous engueuliez au point que l’upstream ne profite plus des améliorations d’Aurélien sur la partie colorimétrique.

            Concernant ses positions, sa façon de les présenter est clairement excessive et peu productive, et de mon point de vue il fait des montagnes de trucs qui n’en valent clairement pas la peine.

            Cela dit, je pense qu’il y a un fond de vérité dans ce qu’il dit : l’interface de darktable est extrêmement touffue et pas toujours adaptée aux photographes. Certain détails et fonctionnement sont clairement des « trucs de développeur » (comme les icônes « et/ou » du nouveau filtre de couleur). Plus généralement, les deux difficultés d’accès que je trouve à darktable d’un point de vue ergonomie1 sont :

            1. La profusion de modules dont beaucoup fond doublons (notamment à cause du double fonctionnement relatif à l’affichage ou à la scène). Il y a bien les réglages pour sélectionner des ensembles cohérents de modules, mais ça reste quand même très facile de mélanger (cf d’autres commentaires sous cette même dépêche, par exemple).
            2. Le mélange complet, dans l’interface des modules, des options « généralement utiles » et des options « on l’a mis parce que ça peut servir mais normalement vous n’avez pas à y toucher.

            Je détaille le point 2 avec un exemple. Si j’ai besoin d’utiliser l’égaliseur de ton, en traitement relatif à la scène, j’aurai sans doute besoin d’aller régler les compensations d’exposition et de contraste du masque pour avoir un masque cohérent. Mais ça, c’est les options n°6 et 7 de l’onglet « masque ». Les deux premières, c’est le choix de l’estimateur de luminance et la méthode de préservation des détails, qui sont deux options d’usage franchement rare.

            Ça peut même provoquer facilement des problèmes : dans le module d’exposition, il y a en accès direct une « correction du niveau du noir » qui donne très envie de s’en servir pour augmenter la densité… ce qu’il ne faut surtout pas faire parce que ça pose plein de problèmes ensuite. En fait, un usage « légitime » de cette option est rare, est-ce qu’elle a besoin d’être aussi visible ? (Il y a bien un avertissement, mais encore faut-il y faire attention… ou même le voir : je peux jouer avec ce curseur en le survolant et en actionnant la molette sans que la popup apparaisse).

            D’une manière générale, il y a de grosses avancées (le thème gris neutre apparu il y a quelques versions est beaucoup plus propre que ce qu’il y avait avant), il y a beaucoup d’aides de partout, mais on a encore beaucoup besoin de lire des tooltips ou la doc pour des trucs qui ne devraient pas en avoir besoin.

            Il y a aussi des fonctionnalités qui sont développées d’une façon qui me fait dire qu’elles n’ont pas été testées par des non-développeurs, ou que les retours n’ont pas (encore) été intégrés. Dans les fonctionnalités de la v4.0.0 que je range là-dedans, il y a le mapping d’exposition/colorimétrie (soyons clairs : pour moi la fonctionnalité est géniale, et totalement inutilisable), ou à plus petite échelle, la très bonne idée du nom de couleur qui ne s’affiche pas au survol du patch qui montre la couleur sélectionnée (elle ne s’affiche qu’au survol des chiffres à côté, le survol du patch ne montre que la tooltip « cacher/montrer le grand patch de couleur », idem pour ledit grand patch).

            PS : j’ai l’impression qu’il y a un début de travail en ce sens avec des options de module planquées dans un sous-menu déroulant – comme « coefficients des canaux » dans « balance des blancs », mais ça mériterait d’être généralisé.

            Ce genre de retour m’a été confirmé par ma mère, photographe professionnelle de 60 ans, qui a testé darktable et s’est retrouvée noyée dans les boutons, menus et tout. Outre l’apprentissage du système de couleur, sa principale difficulté était de retrouver les réglages pour faire ce qu’elle voulait, même quand elle savait quel module et en gros quels curseurs utiliser pour arriver à ses fins. Et du coup elle reste sur l’outil de « dérawtisation » fourni par son fournisseur de matériel photographique2.


            En résumé : beaucoup de mauvaise communication dans tout ça j’ai l’impression, et c’est dommage : il y a pour moi de vrais axes d’amélioration ergonomique pour darktable, et pour transformer son côté « jouet pour développeur » sur certains aspect en « outil pour photographe ».


            1. Je mets de côté le choix de montrer tous les traitements et de pouvoir les activer/désactiver/modifier, parce que c’est le choix du logiciel ; et le fait de devoir (ré)apprendre le fonctionnement des traitements de couleur, parce que ces traitements sont pour moi la plus grande force de darktable. Et aucun de ces deux points ne se règle complètement ou même principalement par l’ergonomie. 

            2. Qui, d’un point de vue ergonomie et performances, est une bouse absolue qu’il faut qu’Aurélien ne voie jamais sous peine de faire une crise cardiaque :D Sans déconner, je ne sais pas comment ils font pour avoir un outil activement développé et aussi inefficace. Non, je ne donnerai pas la marque. 

            La connaissance libre : https://zestedesavoir.com

            • [^] # Re: r-darktable

              Posté par  . Évalué à 10 (+9/-0).

              Les deux points de vue ne sont en effet probablement pas conciliables malheureusement. Par contre, même sans ça, Aurélien avait déjà prévu (il l'avait évoqué il y a quelques mois) qu'il prévoyait dans les prochains mois de rejoindre le projet vkdt et quitter le projet darktable.
              Et suite à ce schisme récent, il a annoncé qu'il continuerait à apporter ces contributions à darktable jusqu'à la fin de l'année (donc pour darktable 4.2) et qu'ensuite il rejoindrait le projet vkdt.
              Donc concrètement, sur ce point, ça ne change rien (ou au pire - il n'avait pas donné de délai avant le "schisme" - il aurait quitté darktable l'année prochaine.
              Bref, le changement n'est pas énorme, il avait déjà prévu de partir !

              Concernant les critiques de l'interface, elles sont connues mais elles sont aussi le revers (tu l'évoque d'ailleurs dans ton article très bien, du choix de darktable : apporter des traitements puissants et à la main de l'utilisateur de bout en bout.

              Ce qui est intéressant aussi est que tous les exemples que tu donnes et qui ne vont pas, sont les apports d'Aurélien. Donc les défauts d'interface que tu soulèves dans ton commentaire est son travail. Et que le schisme de sa part vient du fait qu'il trouve l'interface des nouveaux filtres mauvaise. Comme quoi !
              Ceci étant dit, ça n'est pas simple non plus de trouver une interface abordable et permettre un traitement plus poussé et plus à la main de l'utilisateur. Aurélien avait fait un parallèle intéressant il y a quelques années : darktable est comme un avion (puissant mais du coup avec plein de commandes à connaître/comprendre) et peut donc difficilement être aussi simple à piloter qu'une voiture classique. Évidemment, ça n'empêche qu'il doit y avoir sûrement quelques améliorations possibles.

              Quant à la question communication, malheureusement on a essayé mais c'est compliqué de communiquer avec Aurélien quand il est en désaccord. J'aimerais qu'il en soit autrement, il a apporté tellement à darktable et à ses utilisateurs (moi le premier).

              En dehors de tout ça, ravi que mon travail sur le thème gris te plaise. La version 1.0 que j'avais fait (sur la base de la refonte de l'interface d'Aurélien) pour darktable 3.0 était intéressante mais comme toute version 1.0, perfectible. J'ai beaucoup remanié de choses depuis (pratiquement tout le code CSS et pas que du thème gris) et je pense en effet que cette version 4.0 est bien plus aboutie. J'ai appris aussi au fur et à mesure (et réappris certains points de CSS que je n'avais pas pratiqué depuis près de 10 ans quand je me suis mis à la version 1.0 il y a plus de 3 ans. Il y a en plus déjà quelques correctifs mineurs ajoutés en vue de la 4.0.1 (intégré en master aujourd'hui). Et suite à ton rappel : le correctif des cases à cocher est fait : https://github.com/darktable-org/darktable/pull/12164

              • [^] # Re: r-darktable

                Posté par  (site Web personnel) . Évalué à 8 (+7/-1). Dernière modification le 11/07/22 à 23:47.

                Bref, le changement n'est pas énorme, il avait déjà prévu de partir !

                De mon point de vue, perdre le contributeur principal de la fonctionnalité clé du produit, c’est énorme. Même si s’il a déjà prévu de partir – surtout s’il a déjà prévu de partir, en fait, parce que ça veut dire qu’il n’y a même plus tellement d’espoir que la communication reprenne.

                Ce qui est intéressant aussi est que tous les exemples que tu donnes et qui ne vont pas, sont les apports d'Aurélien. Donc les défauts d'interface que tu soulèves dans ton commentaire est son travail.

                Soyons sérieux deux minutes : ça n’est pas le cas. Je veux bien croire que la profusion de modules soit une conséquence de son travail, mais il propose une solution dans son fork pour la corriger au moins en partie (PS : et que l’organisation des options de ses propres modules ne soit pas meilleure que les autres). Par contre, les options en vrac au sein des modules, c’est comme ça depuis très longtemps ; cf par exemple le manuel de darktable 2.0 (décembre 2015) dans lequel on retrouve pléthore de ces cas, dont l’exemple du module d’exposition que j’ai cité.

                Enfin, sur ce point :

                Concernant les critiques de l'interface, elles sont connues mais elles sont aussi le revers (tu l'évoque d'ailleurs dans ton article très bien, du choix de darktable : apporter des traitements puissants et à la main de l'utilisateur de bout en bout.

                La métaphore de l’avion est intéressante et pertinente : contrairement à une voiture, un avion laisse l’accès à énormément de paramètres – même s’il y a beaucoup, beaucoup d’automatismes en sous-main. Ça veut dire qu’effectivement, l’interface de pilotage des avions est chargée d’énormément de fonctionnalités. Par contre, ça ne veut absolument pas dire que tout est en vrac. Au contraire : les avions font l’objet d’études ergonomiques assez poussées pour que ce qui est le plus important et le plus utile au quotidien soit le plus accessible possible, tout comme les éléments de sécurité. Et ça peut aller loin : par exemple, les commandes de volets – primordiales pour l’atterrissage – sont souvent d’une forme spécifique reconnaissable au toucher dans un cockpit enfumé, et cette commande peut être munie de sûretés physiques qui empêchent de faire par mégarde certaines manœuvres qui seraient dangereuses.

                Et donc, oui, la philosophie de darktable impose que l’utilisateur ait accès à beaucoup de contrôles. Ça n’implique pas que tous ces contrôles doivent avoir la même priorité et la même facilité d’accès.

                Le design de darktable a été énormément amélioré avec le thème gris – en plus de résoudre des problèmes de risques quant à la luminosité perçue des photos traitées, et ça c’est une excellente chose. Par contre, d’un point de vue utilisateur, son ergonomie est encore très perfectible. Pour moi, on est très loin de « quelques rugosités restantes ».

                Je pense très honnêtement que le prochain axe d’amélioration de darktable est là-dessus. Le problème, c’est que les ergonomes dans le monde open-source, c’est rarissime – et ça demande d’être assez résistant pour se prendre les déluges de commentaires de powerusers qui ne supportent pas qu’on supprime ou même qu’on rende un peu plus difficile d’accès des options qu’ils sont les seuls à utiliser, cf le cas de Gnome par exemple. De même, un des outils très pratiques pour savoir quelles sont les fonctionnalités réellement utilisées (et donc détecter celles qui sont importantes, ou détecter les échecs de découvert de fonctionnalité) c’est de tracer tout ça et d’envoyer les données dans un outil centralisé… ce qui est quelque chose qui est généralement très mal vu dans le monde du libre. Ça impose donc de passer par des sondages, des retours d’expériences en corrigeant le fait que c’est pas ceux qui crient le plus fort qui sont majoritaires, etc. qui sont des choses longues et complexes à faire, et qu’à peu près personne n’est prêt à faire de façon bénévole pour un projet libre.

                Bref, j’espère tout de même un futur radieux à darktable malgré ces problèmes internes au projet, et que les prochaines versions seront aussi de grande qualité, et que vous pourrez progresser sur l’ergonomie.

                Je vous aiderais bien sur tout ça, mais d’une part mes connaissances en ergonomie sont limitées, et d’autre part je n’ai déjà pas le temps de réaliser le quart de mes projets actuels.

                La connaissance libre : https://zestedesavoir.com

                • [^] # Re: r-darktable

                  Posté par  (site Web personnel) . Évalué à 7 (+6/-0).

                  Je pense très honnêtement que le prochain axe d’amélioration de darktable est là-dessus. Le problème, c’est que les ergonomes dans le monde open-source, c’est rarissime – et ça demande d’être assez résistant pour se prendre les déluges de commentaires de powerusers qui ne supportent pas qu’on supprime ou même qu’on rende un peu plus difficile d’accès des options qu’ils sont les seuls à utiliser, cf le cas de Gnome par exemple.

                  Ton exemple est intéressant. J'ai un collègue qui est passé de Windows à GNU/Linux (bon ok j'y suis pour quelque chose). Il a essayé différents desktops dont KDE. Je pensais, bidouilleur qu'il est (c'est un power user en puissance), qu'il allait l'adorer avec toutes les capacités et options de cet environnement de bureau … ben non, c'est Cinnamon qui a eu son cœur. Il a préféré, dans le cadre de son boulot, d'avoir un environnement qui lui permet de faire son boulot efficacement et surtout sans fioritures.

                  Pour aller dans le sens de tes propos, dans les boites où je suis passé, les ergonomes et concepteur d'interfaces étaient plutôt rare et c'était souvent les dev qui bossaient là dessus … avec le résultat que l'on peut imaginer ; on ne s'invente pas designeur comme ça. Et lorsqu'il y en avait, en général leurs travaux étaient peu estimés aussi bien par leur hiérarchie que par les autres dev. Et ils étaient en général mal payés. Donc, je ne suis pas surpris que l'on trouve difficilement des ergonomes ou designeurs dans les projets open-source. N'empêche que c'est par leur contact que j'ai pris connaissance que designeur est un métier à part entière qui ne s'improvise pas … j'ai pu voir à quel point aussi j'avais des goût de chiottes.

                  Je pense que le soucis de comm' entre Aurélien et certains autres dev de darktable vient ppeut être d'un manque d'organisation structurelle formalisée. Les gros projets ou fondations en open-source ont, pour palier à ce que semble vivre l'équipe darktable, mis en place une organisation afin de faciliter les échanges, les modifs et surtout l'arrivée des nouveaux venus. On peut citer celle de la fondation Apache. Et comme pour tout, une organisation n'est jamais figée dans le marbre, elle change et vit au fur et à mesure qu'un projet ou fondation grossit.

                  • [^] # Re: r-darktable

                    Posté par  . Évalué à 5 (+4/-0).

                    Je pense que le soucis de comm' entre Aurélien et certains autres dev de darktable vient ppeut être d'un manque d'organisation structurelle formalisée.

                    Pas que. En effet, et c'est fréquent sur les projets bénévoles (pas que sur les logiciels libres mais on retrouve ça assez souvent dans nombre d'associations de bénévoles).
                    La communication est dans l'ensemble très bonne entre tous les développeurs, même lorsqu'il y a des désaccords. Il y a eu cette exception, qui est aussi lié au style très raide/rude d'Aurélien lorsqu'il est en désaccord. Et là, la communication devient très vite impossible, sauf pour les gens qui sont d'accord avec lui. Dans tous les cas, ça a en effet aussi reposer qu'il pourrait y avoir un peu plus de structuration/organisation. Dans la pratique ça n'est pas facile à faire, quand on parle de personnes bénévoles, vivant dans plusieurs pays différents, des horaires parfois incompatibles, des préférences de communication qui sont parfois divergentes (Matrix, Github, IRC…) mais aussi tout simplement des vies à côté et un temps limité.

                    Bref, c'est plus facile d'organiser une structure géré par quelques salariés (comme la fondation Apache) qu'avec des personnes qui font ça sur leur temps libre, selon leurs envies et disponibilités. Bien sûr, une structuration est toujours possible, mais plus difficile.

                • [^] # Re: r-darktable

                  Posté par  . Évalué à 10 (+10/-0).

                  De mon point de vue, perdre le contributeur principal de la fonctionnalité clé du produit, c’est énorme. Même si s’il a déjà prévu de partir – surtout s’il a déjà prévu de partir, en fait, parce que ça veut dire qu’il n’y a même plus tellement d’espoir que la communication reprenne.

                  Ce que je soulignais est que le "schisme" intervenu suite à l'instauration des nouveaux filtres ne change pas grand chose puisqu'il avait déjà décidé de partir. En gros, même s'il n'y avait eu aucun désaccord, Aurélien partait de toute façon. Et sa première raison est lié à GTK et les limites qu'il y voit et l'avantage de Vulkan (pour le projet vkdt) notamment pour la vitesse et le traitement d'images. Je lui fais confiance là-dessus, même si vkdt est à mon avis encore très loin d'être utilisable par beaucoup d'utilisateurs. Mais c'est un projet prometteur (dans quelques années)

                  Soyons sérieux deux minutes : ça n’est pas le cas. Je veux bien croire que la profusion de modules soit une conséquence de son travail, mais il propose une solution dans son fork pour la corriger au moins en partie (PS : et que l’organisation des options de ses propres modules ne soit pas meilleure que les autres). Par contre, les options en vrac au sein des modules, c’est comme ça depuis très longtemps ; cf par exemple le manuel de darktable 2.0 (décembre 2015) dans lequel on retrouve pléthore de ces cas, dont l’exemple du module d’exposition que j’ai cité.

                  Je parle des défauts des exemples que tu précise (les modules de la chambre noire que tu cites). Pour ton commentaire ci-dessus, je partage complètement (excepté le "soyons sérieux 2 minutes" vu que ce n'était pas mon propos ! Les modules que tu cites sont des modules fait par Aurélien. La complexité est liée aussi à la multitude d'options. Après, oui, ça pourrait être clairement ergonomique. Il y a même eu pour certains points des propositions, rejetées par Aurélien, souvent de manière rude. Dans son fork, il n'a rien changé aux modules ni même à quoi que ce soit à la vue chambre noire. Il a fait le ménage sur les autres vues, surtout en fonction de ce qu'il estime suffisant (donc à ses yeux et pas en prenant en compte les workflow différents possibles). Enfin, sur les options en vrac au sein des modules, le plus souvent elles semblent l'être mais ont un sens (pas toujours ceci dit) et Aurélien a souvent expliqué ces choix ergonomiques et montré qu'ils étaient réfléchis. Tu as souligné dans tes exemples les problèmes que tu voyais (et que je partage). J'espère que mes propos sont plus clairs.

                  Et la profusion de modules n'est pas la conséquence de son travail, je ne parlais pas de ce point. Il a même plutôt œuvré au contraire (et tant mieux) : les réduire et orienter les utilisateurs vers ces nouveaux modules qui sont réellement plus efficaces, plus simples assez souvent et plus fiables aussi sur le traitement des images. Et en lien avec d'autres développeurs a déprécié d'anciens modules.

                  Ça veut dire qu’effectivement, l’interface de pilotage des avions est chargée d’énormément de fonctionnalités. Par contre, ça ne veut absolument pas dire que tout est en vrac.

                  Tout à fait d'accord. Ce n'est qu'une illustration. Bien sûr que ça n'empêche pas l'amélioration de l'ergonomie. Par contre, il faut aussi se rendre compte que c'est beaucoup plus difficile que sur des options simples et limitées. Ce qui est logique. Il est quand même plus facile pour des ingénieurs ou designer de travailler l'ergonomie d'un tableau de bord de voiture (même si ça n'est déjà pas toujours simple) que de travailler celle d'un avion.

                  Je l'ai exprimé sur l'un de mes commentaires et j'ai aussi rejoins l'équipe de darktable pour améliorer cette interface. Je ne suis ni ergonome ni designer mais je pense avoir apporté beaucoup déjà à cette interface mais mes limites sont aussi et surtout (par rapport à certaines idées que j'ai) sur mes compétences en codage. Je suis arrivé parce que j'avais des compétences en codage CSS et donc ai surtout travaillé sur le CSS. Cette année et pour la 4.0, j'ai appris un peu de codage Gtk/Cairo pour aller plus loin. Mais ça reste limité et j'ai d'autres projets/priorités dans ma vie que de passer du temps à apprendre à coder plus.

                  Je pense très honnêtement que le prochain axe d’amélioration de darktable est là-dessus. Le problème, c’est que les ergonomes dans le monde open-source, c’est rarissime – et ça demande d’être assez résistant pour se prendre les déluges de commentaires de powerusers qui ne supportent pas qu’on supprime ou même qu’on rende un peu plus difficile d’accès des options qu’ils sont les seuls à utiliser

                  C'est en effet un problème mais ça n'est pas que ça. Comme beaucoup de logiciels libres (darktable en fait partie) sont fait par des bénévoles, il faut aussi des développeurs compétences prêt à passer du temps à coder les évolutions et être ok à coder les évolutions proposées.

                  Ça impose donc de passer par des sondages, des retours d’expériences en corrigeant le fait que c’est pas ceux qui crient le plus fort qui sont majoritaires, etc. qui sont des choses longues et complexes à faire, et qu’à peu près personne n’est prêt à faire de façon bénévole pour un projet libre.

                  Les réticences sont surtout sur le temps et l'énergie que ça prends. J'ajouterais aussi (et là, c'est un aspect de mon boulot où j'accompagne des créateurs d'entreprise) que ça, c'est une étude de marché et des besoins. Et pour qu'elle soit efficace, il faut non seulement mettre ça en place mais réfléchir les questions (qu'elles soient claires, adaptées, etc.) mais aussi cibler le panel d'utilisateurs, s'assurer le plus possible que ça reflète la majorité des usages et utilisateurs (parce que tout le monde ne répondra pas, qu'on peut vite avoir le biais de power users qui répondent plus). Bref, c'est énergivore, chronophage à faire et si c'est mal fait, les résultats peuvent aussi se retrouver à côté de la plaque.

                  Bref, j’espère tout de même un futur radieux à darktable malgré ces problèmes internes au projet, et que les prochaines versions seront aussi de grande qualité, et que vous pourrez progresser sur l’ergonomie.

                  Je l'espère aussi. Sur la premier point, je suis confiant. Au moins pour la 4.2 et dans l'absolu, les autres développeurs restent toujours aussi actifs, il y a même 2-3 nouveaux avec des apports intéressants (un qui a même amélioré quelques points de filmique (bébé d'Aurélien). Après, évidemment remplacer Aurélien n'est pas possible mais le traitement de l'image est franchement aujourd'hui déjà à un très haut niveau. Le gros des améliorations reste sur des points sur lesquels Aurélien n'intervenait pas ou peu. Son truc, c'est le traitement d'image avant tout. Bref, pour le reste, il y a des très bons développeurs et des envies. Les limites pour l'ergonomie reste pour le moment celles que tu cites et que je complète ci-dessus. Mais il y a déjà eu de très belles améliorations comme tu le soulignes (et comme d'autres avis, articles ont souligné). L'ergonomie/interface est clairement dans la bonne réduction. Et j'espère aussi (j'apporterai pour ma part mes suggestions et contributions possibles à mon avis et dans la limite de mes compétences) qu'on continuera à améliorer cette partie. Le travail fait en particulier avec darktable 3.0 et depuis est énorme déjà. Rouvrir un darktable 2.4 (ma première version) et l'interface d'aujourd'hui est un excellent moyen de se rendre compte des progrès énormes faits. Et de ceux qu'il reste à faire…

                  En tout cas, merci beaucoup à toi pour ton article comme tes commentaires posés, réfléchis et de grande qualité. Ca apporte aussi des éclairages/réflexions utiles.

    • [^] # Re: r-darktable

      Posté par  (site Web personnel) . Évalué à 10 (+14/-0).

      Oui enfin, Gtk "d'un âge révolu" et "multiples requêtes SQL" probablement dû à son gestionnaire de fenêtre qui est bugué car pour le moment aucun autre dev n'a reproduit le problème. Le mépris des pros… une attaque sans fondement car ce n'est vraiment pas le cas. Aurélien à une vue bien à lui et refuse les compromis, pourquoi pas mais faut pas non plus en rajouter.

      Sur l'UI et les améliorations je vois des tas de commentaires qui prouvent le contraire, beaucoup sont super content et apprécient les nouveautés. C'est difficile de contenter tout le monde, mais ses commentaires durs et grossiers ne servent pas la bonne cause.

      Pour information, je suis l'intégrateur actuel de darktable, donc on ne peut pas dire que je ne sais pas de quoi il retourne.

      A la fin la polémique ne sert à rien, les retours très positifs sur différents forums sont encourageants et on va s'efforcer de gommer les quelques rugosités restantes.

  • # La solution propre au problème de la reconstruction des couleurs qui donne du magenta avec Filmique

    Posté par  (site Web personnel) . Évalué à 6 (+4/-0).

    Voici la solution propre au problème de la reconstruction des couleurs qui donne du magenta avec Filmique (vidéo Youtube en anglais avec un accent français).

    La « solution » que je donne dans la dépêche est en fait la version « simple et sale qui consiste à planquer la poussière sous le tapis ».

    La connaissance libre : https://zestedesavoir.com

  • # merci. Anglicisme ?

    Posté par  . Évalué à 4 (+3/-1).

    celui de la vidéo, par exemple, qui adresse ces problématiques depuis des années)

    qui "adresse": qui s'occupe de, qui répond aux besoins, qui s'attelle… ?

    Merci pour la dépêche !

  • # Mon retour

    Posté par  (site Web personnel) . Évalué à 10 (+11/-0).

    J’utilise Darktable depuis un moment. C’est un excellent logiciel. Je travaille en image de synthèse donc assez familier avec les notions de colorimétrie que Darktable expose. C’est en effet assez pointu.

    Je suis toutefois content que Darktable propose des outils à l’ancienne pour améliorer rapidement des photos (via « color balance rgb » : chroma/saturation/brillance dans les shadow/middle/highlight). Faire ça à la main est très chronophage.

    Concernant le module Filmic. Je suis content qu’il soit là, mais je ne l’utilise que pour la dynamique/contraste, mais pour travailler ma couleur.

    Je mets systématiquement « Highlight Reconstruction » en LCh (« color » uniquement pour les portraits). Il est à « clip » par défaut et je trouve que c’est une mauvaise option.

    Le système de masque est vraiment extra. Proposer un détecteur d’yeux/visage/peau, premier plan/arrière plan permettrait d’aller encore plus vite.

    Le débruitage profilé fonctionne à merveille.

    Le « raw denoise » threshold est trop haut par défaut. De même que le « coarse/fine curves » mériterait un moyen de sélectionner sur l’image la zone de grain posant problème (genre un mur uniforme) et de laisser Darktable choisir quelle fréquence il doit diminuer depuis la sélection.

    « rotate and perspective » est génial !

    Mon workflow:

    • Recadrage (« rotate and perspective » + « crop »).
    • « Highlight Reconstruction » en LCh (« color » uniquement pour les portraits).
    • Denoise profiled + Très faible RAW denoiser (suivant le bruit de l’image).
    • Souvent je rehausse un peu l’exposition.
    • Balance des blancs en « as source ».
    • Neutralisation de l’image via « color calibration ».
    • Dynamique/contraste via « Film RGB ».

    À partir d’ici je commence à jouer avec les intentions artistiques via « color balance rgb », « color correction » + masques, « color zones » + masques.

    Parfois « local contrast » ou « contrast equalizer ».

    Donc voilà, c’est un très bon logiciel, tourné vers le contrôle.

    • [^] # Re: Mon retour

      Posté par  (site Web personnel) . Évalué à 7 (+5/-0).

      L’un des problèmes de darktable actuellement, c’est qu’il y a des modules qui traitent l’image par rapport à la scène (le flux « moderne ») et d’autres par rapport à l’image (dans Lab, le flux « ancien »). Or, mélanger ces deux types de modules, c’est risquer des résultats imprévus, en particulier dans la gestion des couleurs.

      Les modules suivant fonctionnent dans Lab et ne devraient pas être utilisés si votre flux de travail est basé sur la scène :

      • bloom,
      • raw chromatic aberrations,
      • contrast, lightness, saturation,
      • colorize,
      • color mapping,
      • high-pass,
      • low light,
      • low-pass,
      • raw denoise,
      • shadows and highlights,
      • sharpen
      • soften,
      • split-toning,
      • velvia

      La connaissance libre : https://zestedesavoir.com

      • [^] # Re: Mon retour

        Posté par  . Évalué à 6 (+4/-0). Dernière modification le 11/07/22 à 17:17.

        Il me semble qu'il y a des presets qui sélectionnent les modules pertinents de chacun de ces flux (les autres modules restent disponibles mais n'apparaissent plus par défaut dans l'interface).

      • [^] # Re: Mon retour

        Posté par  (site Web personnel) . Évalué à 3 (+2/-0).

        Intéressant.

        La documentation de certains modules ne spécifient pas s’ils sont en scène ou image.

        Ou as-tu eu cette liste ?

  • # Si on ne comprend pas c'est que

    Posté par  (site Web personnel) . Évalué à 9 (+7/-1).

    L’astuce, c’est que si vous ne comprenez pas un élément, c’est probablement parce qu’il ne vous concerne pas :)

    Cette phrase, en sus du reste de la dépêche, m’a donné envie d’essayer de jouer avec darktable. Bien vu !

    En passant, un très grand merci pour le soin apporté à la rédaction et à la mise en forme, notamment à la typographie. Ça fait vraiment du bien de relire une dépêche de cette qualité sans être importuné par les apostrophes façon « chiure de mouche » (oui c’est appelé ainsi par les typographes) : ' ou les bidules que je n’ose appeler des guillemets " et d’avoir à la place de vraies apostrophes typographiques et de vrais guillemets fermants et ouvrants « » et donc sans avoir à tout corriger.

    Et j’aime beaucoup l’angle que tu as pris.

    « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

    • [^] # Re: Si on ne comprend pas c'est que

      Posté par  (site Web personnel) . Évalué à 9 (+7/-0).

      Le pouvoir du BÉPO :)

      La connaissance libre : https://zestedesavoir.com

    • [^] # Re: Si on ne comprend pas c'est que

      Posté par  . Évalué à 2 (+2/-1).

      Sérieusement, je ne vois pas quelle est la différence (en terme de confort de lecture par exemple) entre la "chiure de mouche" et l'apostrophe typographie et de même pour les "vrais" guillemets ?

      Je ne cherche pas à troller, juste j'ai du mal à comprendre en quoi c'est si important pour certaines personne ?
      C'est au niveau esthétique ? C'est par amour des règles de typographies Françaises ?
      Ou c'est que vous êtes sensible à ce détail un peu à la manière de personnes qui tiquent sur toutes les fautes d'orthographes qu'elles voient ?

      Perso, ça me fait ce genre de réaction plus sur les images genre quand une image n'est pas au bon ratio (ce qui est vraiment la base). C'est le même genre d'inconfort chez vous ?

  • # Base de données & écran

    Posté par  . Évalué à 2 (+1/-0).

    Merci pour la dépêche, j'ai toujours plaisir à lire celles sur darktable.

    Deux petites questions au cas où il y aurait des spécialistes dans le coin.

    Depuis quelques années, j'avais mis de côté la photographie, mais je m'y suis remis il y a peu de temps. Du coup, je suis resté à une ancienne version de darktable (2.6 de mémoire). J'imagine qu'il y a dû y avoir des modifications dans la base de données, donc darktable est-il capable de convertir une base aussi ancienne, ou vaut-il mieux installer les version successives pour avoir une chance de conserver ma base ?

    J'ai de plus un vieil écran 4/3 de plus de 15 ans, & j'envisage de me racheter un écran, plus agréable avec des interfaces graphiques qui utilisent des panneaux latéraux, sans passer mon temps à les masquer/afficher. Or, à l'ère du 10 bits, du BT2020, du HDR, des capteurs avec des plages dynamiques de plus en plus grandes, est-ce que ça vaut la peine encore aujourd'hui d'investir dans un écran 8 bits sRGB qui est une norme des années 90. Surtout si darktable propose une approche moderne et complète de la gestion du matériel et des contraintes colorimétriques ? Mais le problème est peut-être de savoir si Linux est prêt pour ces technologies, plutôt que de savoir si darktable (ou d'autres) est prêt.

    • [^] # Re: Base de données & écran

      Posté par  (site Web personnel) . Évalué à 3 (+2/-0).

      J'imagine qu'il y a dû y avoir des modifications dans la base de données, donc darktable
      est-il capable de convertir une base aussi ancienne, ou vaut-il mieux installer les
      version successives pour avoir une chance de conserver ma base ?

      Oui, darktable est capable de faire la mise à jour de la base de donnée. Fait une sauvegarde avant, en 2.6 il n'y avait pas de sauvegarde automatique si mes souvenirs sont bons.

    • [^] # Re: Base de données & écran

      Posté par  . Évalué à 3 (+3/-0).

      Non, non il te fait a absolument un écran 120Hz à 16 bits, car tes yeux ont les capacités de Superman. C'est comme pour l'audio hi-res…. ;)

      (Bon plus sérieusement, 8bits c'est limite et ça peut se voit MAIS ça ne devrait en rien impacter le développement photo.)

      Pour l'écran je te conseille de partir sur quelque chose de standard et de veiller plutôt au respect des couleurs, du gamma, etc. Et tu verras déjà qu'une dalle de qualité c'est pas donné…

      Mais ceci n'engage que moi.

  • # Another RawTherapee (ART)

    Posté par  . Évalué à 7 (+6/-0).

    Merci pour l'article. Je suis passé de macOS à Linux l'année dernière et j'ai passé pas mal de temps à replacer Lightroom. Pour la gestion, DigiKam était un choix facile, mais pour le développement, il est trop limité. Darktable et RawTherapee ne m'ont pas convaincu: trop complexes, trop lourds. Je suis tombé un peu par hasard sur ART, "Another RawTherapee", qui est rarement cité mais vaut un coup d’œil. Pour un amateur comme moi, l'interface est plus simple, plus épurée et je suis tout simplement plus productif qu'avec tous les autres logiciels. Je l'utilise depuis un an, et j'en suis très content. Voilà le lien du projet: https://bitbucket.org/agriggio/art/wiki/Home

  • # Retour d'expérience

    Posté par  (site Web personnel) . Évalué à 7 (+5/-0).

    J'ai un peu utilisé Darktable il y a quelques années, mais jamais pour beaucoup de photos, jamais complètement à l'aise avec ses très nombreux modules et toutes les possibilités offertes, et jamais complètement satisfait des résultats obtenus. Ce malgré pas mal d'efforts pour me documenter et apprendre ce logiciel.

    J'y suis revenu plus récemment, avec la version 3.8. J'ai découvert que tout un nouveau workflow relatif à la scène avait été mis en place, avec beaucoup de choses à réapprendre, mais aussi plus de cohérence et au final nettement moins de modules à utiliser et maîtriser pour obtenir un résultat satisfaisant.

    J'ai dû prendre le temps de bien me renseigner, non seulement avec la documentation de Darktable mais surtout avec quelques posts très importants sur le forum Darktable (fournis en lien dans la doc officielle) ainsi que quelques billets de blog fort bienvenus pour clarifier les principales étapes de ce workflow.

    J'ai donc bénéficié principalement du travail d'Aurélien Pierre ces dernières années, mais également de l'excellent travail fait sur le thème gris neutre. C'est fou de se rendre compte à quel point l'interface d'un logiciel peut impacter la perception des couleurs !

    Grâce à cela j'ai pu développer une bonne centaine de photos de manière très satisfaisante, avec notamment une bonne maîtrise de la couleur obtenue et une vraie cohérence dans toutes les images de la série. Pour la première fois je me suis senti vraiment à l'aise avec le process (beaucoup plus qu'avec l'ancien), et s'il me reste bien sûr plein de marge de progression, je ne me sens plus débutant, mais vraiment utilisateur. L'activité reste laborieuse et chronophage, mais le résultat vaut l'investissement de temps.

Envoyer un commentaire

Suivre le flux des commentaires

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