URL: https://linuxfr.org/news/darktable-2-4-0 Title: darktable 2.4.0 Authors: Matthieu Moy Davy Defaud, teoB, aurelienpierre, Benoît Sibaud, ZeroHeure, jpg54, michelLeblond, BAud, Fabrice Mousset, Anonyme et R. Danell Olivaw Date: 2017年11月08日T21:02:37+01:00 License: CC By-SA Tags: darktable, raw, photo et photographie Score: 76 Le logiciel de développement d’images brutes darktable est sorti en version 2.4.0. Comme chaque année, la liste des changements est considérable : près de 3 000 _commits_ sur darktable et la bibliothèque _rawspeed_ sous-jacente, 244 _pull‐requests_ traitées et plus de 320 bogues fermés.  Dans les nouveautés majeures, on trouve la prise en charge de Windows (introduite dans une section « _Hell Froze Over_ », « l’enfer a gelé », dans les notes de sorties officielles !), un nouveau module « suppression de la brume », et un nouveau mode « filtre laplacien local » dans « contraste local » qui permet non seulement de jouer sur le contraste local, mais aussi de traiter les ombres et lumières avec un rendu très propre et sans halos. Comme d’habitude, pensez à faire une sauvegarde de votre base de données (répertoire `~/.config/darktable`) : les anciennes versions de darktable ne pourront pas ouvrir les images traitées avec la 2.4. Quelques rappels sur ce que permet de faire darktable, et surtout, les détails des nouveautés dans la suite de la dépêche. ---- [darktable 2.2.0 sur LinuxFr.org](https://linuxfr.org/news/darktable-2-2-0) [darktable 2.0.0 sur LinuxFr.org](https://linuxfr.org/news/darktable-2-0-traitement-et-gestion-de-photographies) [darktable 1.6.0 sur LinuxFr.org](https://linuxfr.org/news/darktable-1-6-traitement-de-photos-developpement-d-images-raw) [Communauté francophone darktable : darktable.fr](https://darktable.fr) [Site officiel de darktable](http://www.darktable.org/) [raw.pixls.us, le remplaçant de rawsamples.ch](https://raw.pixls.us/) [Visualisation gource (vidéo) de l’historique de développement entre la 2.2 et la 2.4](https://youtu.be/VNdFenRQWtw) [Les notes de sortie officielles sur GitHub](https://github.com/darktable-org/darktable/releases/tag/release-2.4.0) ---- Introduction ============ Darktable est un logiciel libre développé depuis 2009 par Johannes Hanika, puis Tobias Ellinghaus et désormais [215 contributeurs](https://github.com/darktable-org/darktable/graphs/contributors), auteurs de 20 191 _commits_ à ce jour. Il s’agit d’un logiciel de catalogage et de développement de photos brutes de capteur (RAW), basé sur Rawspeed, qui embarque une gestion complète de la colorimétrie (profils d’entrée, de sortie et d’écran, _softproofing_ et visualisation du _[gamut](https://fr.wikipedia.org/wiki/Gamut)_), ainsi que la gestion de nombreux formats [RAW](https://fr.wikipedia.org/wiki/RAW_(format_d%27image)) (plus de 550 boîtiers gérés, dont les capteurs Fuji X-Trans et Leica Monochrome), la correction des déformations optiques via la bibliothèque [Lensfun](http://wilson.bronger.org/lensfun_coverage.html) (902 objectifs gérés), et le calcul sur processeur graphique via [[OpenCL]]. Au fil du temps, il s’est doté de fonctionnalités périphériques, comme la possibilité de générer ses propres [profils de couleur cLUT](https://jo.dreggn.org/blog/clut/post.html) à partir de mires (type ColorChecker) ou de JPG boîtier, de scripter des modules d’import‐export avancés en [Lua](https://github.com/darktable-org/lua-scripts) (par exemple, fusion HDR via Enfuse, exportation vers Hugin, création automatique de planches‐contacts et de diaporamas). Il comporte aussi un module d’impression permettant d’appliquer des profils de couleur, pour les imprimantes prises en charge par CUPS. Il est également interfaçable avec GIMP en tant que greffon. Peu à peu, il s’enrichit de fonctions qui relèvent davantage de la retouche non destructive que du simple développement de « négatifs » numériques (voir plus bas). Souvent comparé à Adobe Lightroom en raison des similitudes de l’interface, il s’en distingue par : - la possibilité de créer des masques complexes (paramétriques et/ou dessinés, avec opérations booléennes) afin de restreindre la zone d’application des modules ; - la possibilité native d’émuler le rendu couleur de la pellicule ou les JPG boîtier ; - la possibilité de dupliquer, cloner ou empiler la plupart des modules ; - la gestion native du [[HDR]] et de la correspondance des tonalités (à partir d’une ou de plusieurs photos) et la prise en charge en entrée et sortie de formats d’images échantillonnés jusqu’à 32 bits par canal ; - une approche souvent plus « _bare‐metal_ », avec des options plus proches de l’algorithmique sous‐jacente et parfois moins intuitives ; - une communauté de développeurs où la présence significative d’universitaires garantit l’ajout régulier d’algorithmes issus de la recherche récente. Fait rare pour un « dérawtiseur », il comporte également un module _Liquéfier_, qui permet de déplacer des pixels de la même manière que le filtre _Fluidité_ de Photoshop, mais de façon non destructive, en entrant les vecteurs. Son usage est cependant un peu plus complexe et moins réactif que la version Photoshop, qui n’agit pas sur les données brutes. Sous le capot, darktable est codé en C/C++ avec la bibliothèque graphique GTK 3 pour l’interface et publié sous licence GNU GPL v3. Il effectue le traitement interne des images avec des nombres à virgule flottante sur 32 bits. Changements majeurs =================== Nouveau module « suppression de la brume » (*haze removal*) ----------------------------------------------------------- Les photos de paysages sont souvent pâlies par un voile atmosphérique ou de la brume. Parfois, cette brume participe à l’ambiance et l’on peut vouloir l’exploiter dans le traitement, mais on peut aussi vouloir l’éliminer ou au moins l’adoucir. Vu que la brume désature l’image et lui enlève du contraste, les ingrédients pour retrouver manuellement une image bien équilibrée sont « contraste local » (ou « renforcer la netteté » avec un rayon très grand : faire un clic droit sur le curseur de rayon et entrer au clavier par exemple 20, pour dépasser le rayon maximum du curseur) et le curseur de saturation de « contraste lum. saturation ». Le voile atmosphérique ajoute souvent un peu de bleu, en particulier sur les tons sombres, ce qu’on peut rectifier avec le module « balance des couleurs ». Voir par exemple le [tutoriel darktable _Voile atmosphérique_](https://vimeo.com/168679284) de Jean‐Pierre Verrue. Ces traitements manuels posent deux problèmes : d’une part, il faut souvent combiner plusieurs modules et donc passer relativement longtemps sur chaque image et, d’autre part, les paysages brumeux sont souvent composés de plusieurs plans, de plus en plus atteints par la brume au fur et à mesure qu’on s’éloigne du photographe. Inutile de tenter de retrouver du contraste dans un arrière‐plan totalement gris (on ne ferait qu’amplifier les artefacts de l’image), mais masquer les effets sur le premier plan n’est pas forcément évident non plus. C’est là qu’intervient le nouveau module _suppression de la brume_ de cette nouvelle version, écrit par [Heiko Bauke](https://github.com/rabauke/haze_removal) sur la base d’un article de chercheurs de l’université de Hong‐Kong. Le module se trouve dans l’onglet _modules d’amélioration_ :  Il a deux curseurs : - la force permet de contrôler le voile atmosphérique (plus on l’augmente, plus le bruit devient important) ; - la distance permet d’agir plus ou moins sur les différents plans de la photo. Voici le résultat sur une photo, extraite d’une série prise pour tester les algorithmes de suppression de brume :  Et après l’activation de la « suppression de la brume » avec les paramètres par défaut :  Aucune autre correction que celles faites par darktable à l’ouverture d’un fichier RAW n’a été faite sur cet exemple, comme on peut le voir dans l’historique. Regardons maintenant les deux curseurs : - la force permet de contrôler le voile atmosphérique. Comme on peut s’y attendre, la valeur 0 signifie qu’on n’applique pas d’effet, et la valeur 1 tente de supprimer la totalité de la brume, donc de rétablir une image correctement contrastée et colorée. Bien sûr, plus on augmente cette valeur plus on risque d’amplifier les défauts de l’image, en particulier le bruit ; - la distance permet d’agir plus ou moins sur les différents plans de la photo. Par défaut, darktable va tenter de supprimer la brume du premier plan, mais pas de l’arrière‐plan. En jouant sur ce curseur on peut choisir à partir de quelle distance on arrête cet effet. Voici ce que donne ce second curseur sur une autre image de la même série. Le curseur de force est sur 0,6 (sur cette photo, au‐delà, on voit de vilains artefacts) et l’on fait varier la distance :  À distance 0, le module ne modifie pas l’image. En passant de 0 à 0,1, on voit clairement que le premier plan est restauré, mais le curseur a peu d’effet sur l’arrière‐plan et le ciel. Les maisons au fond de l’image sont encore assez pâlies par le brouillard. Sur les tranches suivantes l’effet ne change plus sur l’herbe au premier plan : le module considère qu’il a supprimé la brume et ne cherche pas à enlever plus que ce qu’il a déjà fait. En revanche, les maisons sont de moins en moins pâles. Arrivé à 0,5, le curseur ne change plus beaucoup le paysage mais l’effet s’applique sur le ciel, ce qui n’est pas forcément du meilleur effet : il est sans doute préférable de s’arrêter avant ! La suppression de la brume a réduit la luminosité de l’image (qui était déjà relativement sombre au départ). On peut terminer le travail en rectifiant l’exposition avec les modules _exposition_ et _niveaux_. Au final, on obtient ceci (seul le module _suppression de la brume_ diffère entre les deux côtés) :  En appliquant une force négative, on peut aussi « ajouter » de la brume. Dans ce cas, le curseur de distance est ignoré. Nouveau mode « filtre laplacien local » (*local laplacian filter*) dans « contraste local » ------------------------------------------------------------------------------------------- Le module _contraste local_ se voir doté d’un nouveau mode _filtre laplacien local_ :  Jusqu’à présent, ce module utilisait un filtre bilatéral (toujours disponible, également connu sous le nom de flou de surface) pour créer un masque flou. Le filtrage laplacien donne un résultat plus subtil, en permettant une meilleure récupération des détails sans altérer le contraste local de façon aussi marquée. La possibilité de piloter séparément le contraste dans les hautes et basses lumières le rend aussi intéressant pour ajouter du modelé dans un portrait :   Dans ce contexte, l’effet se rapproche de l’utilisation d’un bol beauté (ou _beauty dish_, modificateur de flash rond de 30 à 45 cm de diamètre qui donne une lumière relativement ponctuelle utilisée pour découper le dessus des joues, l’arrête nasale et marquer le relief du visage). Comme leur nom l’indique, les curseurs _ombres_ et _hautes lumières_ permettent d’augmenter ou de diminuer la luminosité dans les zones sombres et claires, et le curseur _étendue des tons moyens_ permet de décider sur quelle étendue de luminance on veut appliquer l’effet des différents curseurs : 0 revient à désactiver l’effet du curseur _détail_, mais applique les effets des curseurs _ombres_ et _hautes lumières_, respectivement sur la moité d’image la plus sombre et la plus claire (c’est donc équivalent à désactiver le module si l’on laisse ces deux derniers curseurs sur 100 %). La valeur 1 fait l’inverse : les curseurs _ombres_ et _hautes lumières_ n’ont plus d’effet mais le curseur _détails_ modifie l’ensemble de l’image. Les autres valeurs, par exemple 0,5, font un intermédiaire. À l’inverse, en retirant du contraste, on obtient un effet de _tone‐mapping_ (compression de la plage dynamique) très naturel, qui peut se substituer au module _Ombres et hautes lumières_, en retirant du contraste global sans casser le contraste local (donc la sensation de netteté) :   Ce module remplace aussi _Renforcer la netteté_, basé sur un masque flou gaussien, et dont un intérêt est d’inverser l’effet des filtres passe‐bas présents sur les capteurs d’appareils photo afin de limiter le moiré. Les constructeurs faisant progressivement disparaître les filtres passe-bas, ce module devient progressivement moins utile, d’autant qu’il est enclin à créer des halos sur les bords durs contrastés (transitions ciel‐bâtiments, par exemple). Les détails sur ce module (mathématiques sous‐jacentes, exemples d’applications) sont décrits dans l’article de blog [_Local laplacian pyramids_](https://www.darktable.org/2017/11/local-laplacian-pyramids/) sur le site de darktable. Affichage des canaux et des masques en pseudo‐couleurs ------------------------------------------------------ La quasi‐totalité des outils de darktable permettent de cibler des parties d’images (bouton _fusion_ en bas de chaque module). On peut au choix dessiner un masque ou bien construire son masque en sélectionnant les pixels selon la valeur des canaux qui constituent ce pixel (L, a, b, saturation, couleur). Dans le second cas, la méthode classique consiste à utiliser la pipette pour trouver les caractéristiques de la zone à cibler, puis à entourer cette valeur avec les curseurs. Mais cette méthode suppose que l’on sache déjà sur quels canaux il est pertinent de filtrer. Bien souvent, l’encadrement de la valeur cible sera trop précis (et on ne sélectionnera pas toute la zone voulue), ou bien au contraire pas assez et on appliquera le traitement à une zone de l’image qu’on souhaitait exclure. On peut maintenant visualiser non seulement le masque actuel (clic ou contrôle clic sur le bouton en bas à droite de la partie _masque paramétrique_), mais aussi la valeur de chacun des canaux sur lesquels on fait la sélection (`Maj` + clic sur le même bouton). Voyons ceci sur un exemple. Notre objectif est d’appliquer une transformation sur le bleu du ciel (par exemple le rendre un peu plus foncé) :  Vu que l’on cherche à masquer du bleu, un réflexe assez naturel serait de filtrer sur le canal _h_ (*hue*, ou teinte). On peut visualiser ce canal en faisant un `Maj` + clic sur le bouton de visualisation du masque, puis en passant la souris sur la réglette correspondant au canal à visualiser. Voici le résultat :  L’image est affichée uniquement par sa teinte : tous les pixels ont la même saturation (la même « intensité de couleur ») et la même luminance. Cette visualisation fait apparaître une mauvaise nouvelle : il y a du bleu un peu partout dans notre image (mais en général, il est très sombre ou très peu saturé et on ne le voit pas forcément comme du bleu). On peut tout de même encadrer la valeur cible bleue, mais ce n’est pas la peine de chercher à éliminer les autres pixels bleus avec cette réglette : nous venons de voir qu’ils ont la même teinte :  On peut parcourir les autres canaux et les visualiser pour chercher celui qui est le plus discriminant afin d’éliminer nos pixels parasites. Le canal de saturation semble être un bon candidat :  La couleur utilisée dans l’image est la même que celle de la réglette : blanc (ou gris) pour les pixels peu saturés, violet pour les pixels les plus saturés. Clairement, le ciel est plus saturé que le reste de l’image (ce qui n’était pas nécessairement évident à l’œil sur l’image originale). On peut exclure les pixels les moins saturés :  Il reste quelques zones sélectionnées hors du ciel, mais ces zones sont plus sombres que le ciel, on peut facilement les éliminer sur l’un des deux canaux L ou g. On peut aussi afficher les deux informations (masque et canal) en faisant un `Ctrl` + `Maj` + clic sur le bouton :  En résumé : * clic, ou `Ctrl` + clic : affichage du masque ; * `Maj` + clic, puis survol d’une réglette : affichage d’un canal ; * `Ctrl` + `Maj` + clic : affichage combiné. Version Windows --------------- Lors de la sortie de darktable 2.2, on avait déjà parlé en octobre 2016 de la [demande d’intégration de Peter Budai](https://github.com/darktable-org/darktable/pull/1327) qui ajoutait la prise en charge de Windows. Cette _pull request_ a été bien accueillie, longuement discutée (avec 241 commentaires) et après des mois de travail sur l’amélioration du code, intégrée à darktable en avril. En août, darktable annonçait sa [première version Windows](http://www.darktable.org/2017/08/darktable-for-windows/) pré‐alpha, mais déjà utilisable. Cette version 2.4.0 apporte la prise en charge officielle de Windows. Il reste quelques limitations (pas de module d’impression, pilotes spécifiques requis pour pouvoir prendre des photos directement à travers USB, et sans doute encore beaucoup de bogues), mais elle est utilisable et considérée comme une version officielle au même titre que les versions GNU/Linux et macOS. Coïncidence intéressante, la prise en charge de Windows arrive au même moment qu’un [changement de politique de licence pour Adobe Lightroom](https://phototrend.fr/2017/10/dossier-lightroom-cc-cloud-et-lightroom-classic-cc/). Beaucoup d’utilisateurs de Lightroom cherchent un remplacement (voir [_ici_](https://www.ouiouiphoto.fr/Wp/2017/11/alors-vous-voulez-quitter-adobe-et-lightroom/) ou [_là_](https://youtu.be/DWEwch-hFyI), par exemple) et darktable [a déjà satisfait plus d’un ancien utilisateur de Lightroom](https://www.dpreview.com/forums/thread/4134864). On peut donc s’attendre à une explosion du nombre d’utilisateurs de darktable. Avec l’arrivée de nombreux nouveaux utilisateurs sur une version Windows, pas encore aussi stable que la version GNU/Linux, on peut craindre que les forums et les systèmes de suivi de bogues soient inondés de plaintes non constructives. C’est ce que les développeurs redoutaient avec une version Windows. Espérons que les nouveaux venus seront constructifs et permettront au contraire d’agrandir la communauté et au final d’améliorer la qualité du logiciel. Voir par exemple quelques conseils [à l’attention des nouveaux utilisateurs de darktable](https://darktable.fr/forum/showthread.php?tid=2044). Après tout, plusieurs développeurs actuels de darktable sont des anciens utilisateurs de Lightroom ! Des petits détails qui peuvent changer la vie ============================================= Possibilité de choisir la couleur de fond de l’interface via CSS ---------------------------------------------------------------- L’interface de darktable suit le principe « les photos, rien que les photos ». Tout est fait pour éviter d’attirer l’œil vers les autres zones de l’écran. Un point important : il y a très peu de couleurs, ce qui permet à l’œil d’avoir une référence du gris non coloré. Il serait difficile d’ajuster correctement la balance des blancs sur un fond coloré par exemple. Un défaut potentiel de l’interface par défaut, c’est que le gris sombre peut avoir tendance à habituer l’œil aux couleurs sombres, et donc à encourager le photographe à sous‐exposer les images. [Dans une de ses vidéos](https://www.youtube.com/watch?v=VribxpqvtFc), Aurélien Pierre part de ce constat et propose une interface plus claire, correspondant au point gris d’une image. L’interface donne alors non seulement une référence de balance des blancs, mais aussi de luminosité. Malheureusement, pour obtenir ce résultat il fallait non seulement éditer le fichier de configuration `darktable.css`, mais aussi changer quelques valeurs qui étaient restées codées en dur dans le code source de darktable, et le recompiler. Dans la version 2.4, ces valeurs sont devenues configurables et l’on peut donc obtenir le même résultat sans recompilation. Voici un exemple de fichier, à placer dans `~/.config/darktable/darktable.css` : ```css @import '/usr/share/darktable/darktable.css'; @define-color bg_color #7F7F7F; @define-color plugin_bg_color #333; @define-color fg_color #eee; @define-color base_color #444; @define-color text_color #eee; @define-color selected_bg_color #666; @define-color selected_fg_color #eee; @define-color tooltip_bg_color #BEBEBE; @define-color tooltip_fg_color #111; @define-color really_dark_bg_color #595959; @define-color darkroom_bg_color #777777; @define-color darkroom_preview_bg_color shade(@darkroom_bg_color, .8); @define-color lighttable_bg_color @darkroom_bg_color; @define-color lighttable_preview_bg_color shade(@lighttable_bg_color, .8); ``` Et voici le résultat sur l’interface :  Curseur « biais d’exposition » dans le mode « fusion d’exposition » du module « courbe de base » ------------------------------------------------------------------------------------------------ Souvenez‐vous : [la version 2.2 avait vu arriver une option _fusion d’exposition_ dans le module _courbe de base_](http://linuxfr.org/news/darktable-2-2-0#fusion-dexpositions-dans-le-module-courbedebase-pour-diminuer-la-plage-dynamique-dune-image). C’est un des meilleurs moyens de réduire le contraste global d’une image en préservant le contraste local et sans introduire de halo, et cela permet de faire le même genre de traitement qu’en exportant plusieurs images et en les fusionnant avec [_enblend_](http://enblend.sourceforge.net/), mais sans quitter darktable. Mais obtenir les bons réglages n’était pas toujours facile : le seul curseur disponible agissait à la fois sur la force de réduction du contraste et sur l’exposition globale de l’image. On devait donc souvent combiner le module _courbe de base_ et _exposition_, et faire plusieurs allers‐retours entre les deux pour trouver la combinaison gagnante. Fatigué de ces allers‐retours, votre serviteur a ajouté un curseur de « biais » au module _courbe de base_ qui permet de modifier la signification du curseur _décalage d’exposition_. Le principe reste de créer plusieurs images avec une exposition différente et de les fusionner. Par défaut, on crée des images surexposées et on les fusionne avec l’image d’origine. C’est adapté quand on a réglé l’exposition sur les zones les plus claires de l’image : le résultat est de déboucher les zones sombres. Mais bien souvent, le résultat est de surexposer l’ensemble de l’image. Avec le curseur de biais, on peut choisir entre fusionner avec des images surexposées (biais de 1), des images sous‐exposées (biais de -1), ou un intermédiaire, par exemple un biais de 0 avec une fusion de trois expositions fusionnera l’image d’origine avec une version surexposée et une version sous‐exposée. Voyons cela sur un exemple :  L’écart de contraste entre le ciel et les arbres est important. Essayons de le réduire pour que les arbres soient moins bouchés, mais sans surexposer le ciel. Première étape : prendre un instantané et afficher l’image avant/après, cet affichage va servir à régler le curseur de biais. Puis, application de la fusion d’exposition. Avec les paramètres par défaut pour trois expositions, on obtient ceci :  Comme on s’y attendait, le résultat a globalement surexposé l’ensemble de l’image. La photo est prise au lever du soleil, on souhaite garder cette ambiance matinale, donc cette version ne convient pas. On règle maintenant le biais pour retrouver une exposition correcte sur l’ensemble de l’image. Une solution pour faire cela est de prendre une partie de l’image qui était à l’origine dans les tons moyens (ici le ciel en dehors des nuages) et de s’arranger pour que la fusion d’exposition ne modifie pas cette partie de l’image. Avec notre instantané avant/après, c’est assez facile à faire :  Finalement, on se rend compte que le principal effet de la fusion d’exposition a été de surexposer l’image, mais la réduction de dynamique entre les zones claires et les zones sombres n’était pas si forte. Voyons ce qu’il se passe si l’on pousse le curseur « décalage d’exposition » plus loin (sans toucher au curseur de biais) :  Ce n’est pas très joli, mais la bonne nouvelle est que, même en poussant ce curseur au maximum, on n’a ni surexposé ni sous‐exposé l’image : une fois le curseur de biais bien placé, le curseur de décalage d’exposition agit uniquement sur la dynamique de l’image. On peut donc choisir la force de l’effet en agissant sur ce curseur. Par exemple, avec une valeur un peu en dessous de 2, on obtient une image relativement équilibrée :  Le premier plan n’est plus bouché, on retrouve du contraste dans la neige alors qu’il était quasi‐invisible dans l’ombre, mais le ciel reste correctement exposé. Il reste beaucoup de marge de manœuvre pour la suite du traitement, le photographe va pouvoir jouer sur le contraste local sans risquer de surexposer ou sous‐exposer par exemple. Amélioration de la fonction « annuler » en chambre noire -------------------------------------------------------- La version 2.2 avait vu arriver une fonction « annuler » en chambre noire : les raccourcis clavier `Ctrl` + `Z` et `Ctrl` + `Y` permettent d’annuler ou de refaire les dernières actions. Ceci vient en complément de l’historique (dans la barre latérale de gauche) et permet de gérer les actions à annuler avec une granularité plus fine. La version 2.4 apporte les touches finales à cette fonctionnalité : * une meilleure gestion des groupements d’actions : en version 2.2, la granularité était en fait un peu trop fine, certaines actions à annuler correspondaient à des changements internes non pertinents pour l’utilisateur ; le résultat : parfois rien ne se passait sur un `Ctrl` + `Z` et il fallait taper plusieurs fois cette combinaison pour avoir un effet ; * la gestion des masques, qui était absente jusqu’ici : un `Ctrl` + `Z` permet maintenant d’annuler une action sur un masque dessiné (création, déplacement, suppression de formes), ceci est primordial puisque les masques ne sont pas dans l’historique et le `Ctrl` + `Z` est alors la seule manière de revenir sur les accidents de déplacement. Une brosse transparente ----------------------- Beaucoup d’utilisateurs se plaignaient du fait que l’outil _brosse_, pour dessiner un masque à la souris, était opaque : une fois une zone couverte, plus moyen de savoir ce qu’il s’y trouvait, et même le curseur était opaque. Avec la nouvelle version, on a maintenant une légère transparence :  Si ce n’est pas assez transparent, pas de panique : c’est configurable en CSS. Avec ceci dans le fichier `darktable.css` : ```css @import '/usr/share/darktable/darktable.css'; @define-color brush_cursor alpha(white, .5); @define-color brush_trace alpha(black, .4); ``` On obtient ce résultat :  L’opacité du masque est toujours réglable avec la molette de la souris. Pour vous indiquer quand l’opacité du masque atteint 100 %, l’épaisseur du contour du curseur change quand c’est le cas. Mode « absolu » dans la table de correspondance des couleurs ------------------------------------------------------------ La table de correspondance des couleurs permet de modifier sélectivement les couleurs d’une image. Une utilisation type est de prendre en photo une mire dont on connaît la couleur de chacune des pastilles (*patch*). On pouvait régler la couleur cible de chaque pastille avec des curseurs permettant de rendre les pastilles plus vertes, plus rouges, plus bleues, plus jaunes, plus claires ou plus foncées. Mais pour forcer une couleur en particulier (celle attendue pour une pastille donnée), on était obligé de procéder à tâtons en bougeant les curseurs et en regardant la valeur de couleur à l’aide de la pipette. C’est maintenant réparé, on peut entrer directement les valeurs cibles en Lab :  Profils OpenCL -------------- Il est désormais possible de choisir comment répartir la charge de calcul entre le processeur et le processeur graphique, en utilisant plusieurs profils de planification OpenCL. Les trois options proposées sont : - **standard** : le processeur calcule les prévisualisations (version réduite de l’image affichée en haut à gauche), le processeur graphique calcule l’affichage principal et l’exportation ; - **GPU rapide** : tout le calcul est effectué par le processeur graphique, pour une retouche beaucoup plus réactive ; en revanche, exporter une image en arrière‐plan pendant la retouche d’une autre image devient pratiquement impossible ; - **GPU multiples** : prévisualisations et exportations sont réparties entre les différents processeurs graphiques. On peut aussi forcer l’utilisation d’OpenCL en préfixant une entrée d’un `+` dans la variable de configuration `opencl_device_priority`. Autres changements ================== * Dans les modules _courbe de base_ et _courbe des tonalités_, les coordonnées du point courant sont affichées pendant l’édition. On peut faire un clic droit sur un point pour le supprimer (même action que pour supprimer des formes de masques). * On peut maintenant créer une nouvelle instance de module en cliquant avec le bouton du milieu sur l’icône _multi‐instances_ (au lieu de faire un clic gauche et de choisir l’entrée _nouvelle instance_ du menu). [^Comment]: * Le module « balance des blancs » a maintenant des curseurs colorés : * Une recherche dans le module _carte_ affiche un contour autour de la zone au lieu de colorer toute la zone :  * Un clic sur le bouton _réinitialiser les paramètres_ du module _trouver la localisation_ du mode _carte_ efface la liste des résultats et le contenu de champ texte de ce module. * Avec une version d’[osm-gps-map](http://nzjrs.github.io/osm-gps-map/) récente, des informations de copyright sont affichées. * Les variables utilisées par l’exportation et le module _filigrane_ ont maintenant une syntaxe de substitution inspirée de celle de Bash. Par exemple, `$(TITLE-Mon titre par défaut)` sera étendu avec le contenu de la variable `TITLE` si elle est définie, et « Mon titre par défaut » sinon. * Quand on tente d’ouvrir darktable alors qu’une instance tourne déjà, darktable affiche maintenant une boîte de dialogue expliquant la situation :  * Les opérations d’import‐export affichent maintenant une barre de progression dans le dock si l’environnement de bureau le permet :  * Le curseur de détail du module _contraste local_, dans le mode _grille bilatérale_ (l’ancien mode), peut maintenant être poussé plus loin qu’avant. * L’utilisateur peut choisir d’avoir une confirmation avant de supprimer un répertoire vide. * Le module _balance des couleurs_ est maintenant plus rapide grâce à une optimisation utilisant du code [SSE](https://fr.wikipedia.org/wiki/Streaming_SIMD_Extensions "Streaming SIMD Extensions"). * Le niveau de compression des images PNG est maintenant réglable. * Sous macOS, on peut ouvrir des images individuellement en ligne de commande ou via glisser‐déposer. * Une option permet de supprimer la hiérarchie intermédiaire et de n’exporter que le dernier niveau de chaque mot clef. * Dans le module _filigrane_, la liste des fichiers [SVG](https://fr.wikipedia.org/wiki/SVG "Scalable Vector Graphics") est maintenant triée et omet l’extension. * Le [profil XYZ](https://fr.wikipedia.org/wiki/CIE_XYZ) est maintenant disponible dans les options d’épreuvage. * Deux nouveaux scripts sont fournis avec darktable : * `purge_from_cache.sh` pour supprimer du cache (`~/.cache/darktable/mipmaps-*`) les images absentes de la base de données ; * `watch_folder.sh` qui utilise _inotify_ pour surveiller un répertoire et ouvrir les nouveaux fichiers dans darktable. * Un nouvel algorithme de dématriçage (*demosaic*) « chroma de domaine fréquentiel » (*Frequency Domain Chroma*), applicable aux capteurs X-Trans (et seulement à ceux‐là), qui produit moins d’effets de moiré dans certains cas. Attention, il n’est pas toujours meilleur que l’algorithme de Markesteijn utilisé par défaut sur ces capteurs (voir par exemple [_cette discussion_](https://discuss.pixls.us/t/frequency-domain-chroma-interpolation-for-xtrans-sensors-good-enough/5791), comparatifs à l’appui). Une bonne stratégie est d’essayer chaque algorithme pour voir quel algorithme est le meilleur sur les images problématiques et de garder la valeur par défaut dans le cas général. * De nouveaux modes de fusions sont apparus pour fusionner spécifiquement sur un canal (_RGB canal rouge/vert/bleu_ et _Lab canal a/b_). L’exemple qui a justifié cette introduction est celui d’une image bruitée sur un canal et moins sur les autres : on peut maintenant appliquer un « débruitage » violent sur le canal problématique et laisser les autres canaux intacts. Sur le module _courbe de base_, en instanciant le module une fois sur chacun des canaux rouge, vert et bleu, on peut obtenir un réglage par courbes RVB, qui manque à certains sous darktable. * Le module _courbe des tonalités_ a maintenant un mode de mise à l’échelle des canaux a et b _automatique RGB_, qui produit l’équivalent d’un réglage par courbe dans l’espace de couleur ProPhoto RGB. * Les fichiers `.xmp` ne sont maintenant plus écrits sur le disque quand leur contenu n’a pas changé. Ceci évite des sauvegardes inutiles aux outils de sauvegarde incrémentales et permet d’éviter une latence inutile sur des disques réseaux lents par exemple. * Sur un ordinateur disposant de plus de 8 Gio de mémoire vive, la configuration par défaut utilise maintenant la moitié de cette mémoire pour chaque module. * La limite supérieure d’ISO dans l’interface a été remontée (elle était à 51 200 ISO). * Les modules _courbe de base_ et _reconstruire hautes lumières_ peuvent maintenant être instanciés plusieurs fois et peuvent utiliser la fusion. * Dans la table lumineuse, la touche `1` bascule par défaut de zéro à une étoile (appuyer deux fois revient à la situation initiale). Cette fonctionnalité ne plaisait pas à tout le monde et est maintenant configurable (dans _options d’interface_, option _appliquer une étoile deux fois ne supprimera pas l’étoile_). * On peut demander une confirmation avant de réinitialiser l’historique d’une image depuis la table lumineuse. * Le module grain a été modifié pour donner un rendu plus proche de celui des photos argentiques, en appliquant plus de grain dans les tons moyens et moins dans les zones d’ombre et de lumière. * Le module _table correspondance couleurs_ permet maintenant de faire un passage en noir et blanc selon l’[effet Helmholtz‐Kohlrausch](https://fr.wikipedia.org/wiki/Luminosit%C3%A9_(colorim%C3%A9trie)#Ph%C3%A9nom%C3%A8ne_Helmholtz%E2%80%93Kohlrausch), qui tient compte de la sensibilité de l’œil dans les différentes couleurs pour obtenir un rendu le plus naturel possible. * Les traductions ont été mises à jour pour le catalan, le tchèque, le danois, le néerlandais, le français, l’allemand, le grec, l’hébreu, le hongrois, l’italien, le japonais, le russe, le polonais, le slovaque, le slovène, l’espagnol, le suédois et l’ukrainien. * L’API [[Lua]] a reçu quelques modifications mineures (voir les notes de sorties officielles pour les détails). * Il faut maintenant au moins CMake 3.1, GCC 4.9 ou clang 3.4 (GCC 5.0 fortement recommandé) et Lua 5.3 pour compiler darktable. La bibliothèque _zlib_ est maintenant requise. * Les couleurs primaires et le point blanc sont maintenant lus en ouvrant les fichiers `.hdr` et ils sont utilisés dans le profil de couleur d’entrée. Prise en charge de nouveaux boîtiers et types d’images ====================================================== Désormais, darktable est capable de lire les images RAF Fujifilm compressées, les fichiers DNG en virgule flottante produits par HDRMERGE. Et, comme d’habitude, la prise en charge de nouveaux boîtiers se poursuit avec une grosse soixantaine d’appareils en plus : voir [les notes de sorties officielles](https://github.com/darktable-org/darktable/releases/tag/release-2.4.0) pour la liste complète. Nouveau site darktable.org ========================== Le site [_darktable.org_](https://darktable.org) fait peau neuve. L’ancien site, basé sur Wordpress, est remplacé par un site statique généré via Python/[Pelican](https://blog.getpelican.com/). On peut y contribuer via des *pull‐requests* sur [le projet GitHub _dtorg_](https://github.com/darktable-org/dtorg). Un gros intérêt du site statique est qu’il pose beaucoup moins de problèmes de sécurité que les sites dynamiques. Voir l’article [_A new website_](https://www.darktable.org/2017/12/a-new-website/) pour les détails. Le nouveau site marque aussi un rapprochement avec [_pixls.us_](https://pixls.us/), **le** site de la communauté libriste sur la photographie. Les commentaires sont de retour sur _darktable.org_ via une intégration des forums de _pixls.us_. En bref : comme le dit maintenant chaque page du site, « _pixls.us ♡’s darktable_ » ! Nouvelle collection d’échantillons de fichiers RAW ================================================== Aujourd’hui darktable gère [plus de 550 boîtiers](http://www.darktable.org/resources/camera-support/). On peut remercier les développeurs, car même si beaucoup codent sur darktable pour leurs besoins personnels, énormément d’efforts sont faits pour gérer un maximum de boîtiers, y compris ceux qu’aucun développeur ne possède. La mauvaise nouvelle étant que pour chaque boîtier, il peut y avoir des variantes du format de fichier, des paramètres différents, etc. Ajouter la prise en charge d’un boîtier représente du travail et tester que cette prise en charge continue à fonctionner de versions en versions est un travail gigantesque. Un outil indispensable pour le faire est d’avoir une image pour chaque boîtier et pour chaque format d’image RAW possible (par exemple, 12 bits, 14 bits, compressée ou non...). Le site de référence était jusqu’à l’année dernière [_rawsamples.ch_](http://rawsamples.ch/). Le site a été victime d’une attaque (injection SQL), et l’absence de sauvegarde n’a pas aidé à sa remise en route... Heureusement, la communauté [_pixls.us_](http://pixls.us), très active, a lancé un nouveau site pour remplacer le défunt : [_raw.pixls.us_](http://raw.pixls.us/). Une différence est la licence : _raw.pixls.us_ publie les fichiers sous licence [CC0](https://creativecommons.org/publicdomain/zero/1.0/) (qui s’apparente au domaine public) pour éviter les éventuelles incompatibilités de licences entre ces images et les logiciels qui les utilisent. L’ensemble des images des _rawsample.ch_ a servi de point de départ pour _raw.pixls.us_, mais le but est de couvrir un maximum de boîtiers avec des images sous licence CC0. Si vous avez lu jusqu’ici, filez donc sur le site pour vérifier que tous les échantillons sont disponibles pour votre boîtier, et sinon soumettez le vôtre. Pas besoin d’être un artiste, ni un informaticien : n’importe quelle photo convient. Pour plus d’information, lire les articles [_New Year, New Raw Samples Website_](https://discuss.pixls.us/t/new-year-new-raw-samples-website/3057), [_Keep the Raws Coming_](https://discuss.pixls.us/t/keep-the-raws-coming/5223) et [_Raw Samples Wanted_](https://discuss.pixls.us/t/raw-samples-wanted/5420) sur _pixls.us_. Et après ? ========== Rêvons un peu pour la prochaine version. Qui n’a jamais raté une photo (mise au point ratée, flou de bougé...) importante, et qui n’a jamais espéré un module magique qui retrouve l’image nette tout seul ? Un tel module est envisageable, [Aurélien Pierre](https://aurelienpierre.com/) travaille sur une implémentation de plusieurs articles de recherche récents, en cours d’intégration dans darktable. Voir la discussion [_Possible module de déconvolution_](https://darktable.fr/forum/showthread.php?tid=1892) sur le forum _darktable.fr_. Le module possède déjà un [prototype fonctionnel](https://github.com/aurelienpierre/darktable/tree/rlucy) (quoique peu utilisable). Il s’agit d’apprentissage machine supervisé réalisant une optimisation par descente de gradient, basé sur une déconvolution aveugle ([cours en anglais](http://cs.nyu.edu/~fergus/teaching/comp_photo/10-Deblurring.pdf)) par l’[algorithme de Richardson‐Lucy](https://en.wikipedia.org/wiki/Richardson%E2%80%93Lucy_deconvolution "Richardson‐Lucy deconvolution"). Cette déconvolution est connue pour générer des artefacts au niveau des bordures et pour amplifier le bruit, mais ici, elle est régularisée par une méthode statistique et une analyse des gradients (variation totale). Au final, la méthode peut récupérer aussi bien du flou de bougé que d’objectif, à la manière de l’outil _Lens softness_ de DXO, _Netteté optimisée_ de Photoshop ou piccure+. Le vrai défi est la gestion des temps de traitement et donc l’efficacité du code (révisions et contributions bienvenues, notamment sur la partie OpenCL). Voici un exemple, zoomé à 100 % sur une photo originale de 4 Mpx : Image floutée (flou gaussien de 5 px) :  Image défloutée (réglages exagérés pour l’exemple) :  Image source :  Un autre outil très attendu est un outil de suppression des taches plus intelligent. Le module _correction des taches_ actuel fait simplement un clone d’une zone de l’image vers une autre, mais cela suppose qu’il existe une autre zone de l’image ayant les mêmes couleurs (par exemple, il est assez délicat à utiliser dans un ciel dégradé). Bonne nouvelle : [Edgardo Hoszowski](https://github.com/edgardoh) (qui travaille aussi avec Aurélien sur la déconvolution) planche sur la question, il a [proposé un morceau de code]( https://github.com/darktable-org/darktable/pull/1548) qui combine le module actuel de darktable, le greffon _wavelet decompose_ de GIMP, et l’outil _correcteur_ (*heal*) de GIMP dans un module _retouche_. Le module est opérationnel mais pas encore intégré à darktable, il reste du travail de revue et de nettoyage de code. S’il est intégré, le nouveau module permettra par exemple d’effectuer des retouches de portrait avancées de manière non destructrice et sans quitter darktable. Pour l’instant, ce genre de peaufinage demande de passer par GIMP, voir par exemple [_ce tuto_ sur la retouche par séparation de fréquence](https://www.youtube.com/watch?v=dR6-Ygh7gyo) ou [_celui‐ci_ en anglais qui utilise le greffon GIMP _Wavelet decompose_](https://www.youtube.com/watch?v=Zw2CUmfbeHE). Comme d’habitude, c’est plus le temps que les idées d’améliorations qui manque.