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.
Sommaire
- Introduction
- Changements majeurs
-
Des petits détails qui peuvent changer la vie
- Possibilité de choisir la couleur de fond de l’interface via CSS
- Curseur « biais d’exposition » dans le mode « fusion d’exposition » du module « courbe de base »
- Amélioration de la fonction « annuler » en chambre noire
- Une brosse transparente
- Mode « absolu » dans la table de correspondance des couleurs
- Profils OpenCL
- Autres changements
- Prise en charge de nouveaux boîtiers et types d’images
- Nouveau site darktable.org
- Nouvelle collection d’échantillons de fichiers RAW
- Et après ?
Introduction
Darktable est un logiciel libre développé depuis 2009 par Johannes Hanika, puis Tobias Ellinghaus et désormais 215 contributeurs, 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), ainsi que la gestion de nombreux formats RAW (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 (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 à partir de mires (type ColorChecker) ou de JPG boîtier, de scripter des modules d’import‐export avancés en Lua (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 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 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 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 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 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. Beaucoup d’utilisateurs de Lightroom cherchent un remplacement (voir ici ou là, par exemple) et darktable a déjà satisfait plus d’un ancien utilisateur de Lightroom. 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. 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, 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 :
@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. 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, 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+Zet il fallait taper plusieurs fois cette combinaison pour avoir un effet ; - la gestion des masques, qui était absente jusqu’ici : un
Ctrl+Zpermet 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 leCtrl+Zest 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 :
@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).
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 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 variableTITLEsi 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.
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 est maintenant triée et omet l’extension.
Le profil XYZ est maintenant disponible dans les options d’épreuvage.
-
Deux nouveaux scripts sont fournis avec darktable :
-
purge_from_cache.shpour supprimer du cache (~/.cache/darktable/mipmaps-*) les images absentes de la base de données ; -
watch_folder.shqui 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, 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
.xmpne 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
1bascule 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, 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
.hdret 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 pour la liste complète.
Nouveau site darktable.org
Le site darktable.org fait peau neuve. L’ancien site, basé sur Wordpress, est remplacé par un site statique généré via Python/Pelican. On peut y contribuer via des pull‐requests sur le projet GitHub 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 pour les détails. Le nouveau site marque aussi un rapprochement avec 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. 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. 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, très active, a lancé un nouveau site pour remplacer le défunt : raw.pixls.us. Une différence est la licence : raw.pixls.us publie les fichiers sous licence CC0 (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, Keep the Raws Coming et Raw Samples Wanted 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 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 sur le forum darktable.fr. Le module possède déjà un prototype fonctionnel (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) par l’algorithme de Richardson‐Lucy. 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 (qui travaille aussi avec Aurélien sur la déconvolution) planche sur la question, il a proposé un morceau de code 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 ou celui‐ci en anglais qui utilise le greffon GIMP Wavelet decompose.
Comme d’habitude, c’est plus le temps que les idées d’améliorations qui manque.
Aller plus loin
- darktable 2.2.0 sur LinuxFr.org (455 clics)
- darktable 2.0.0 sur LinuxFr.org (86 clics)
- darktable 1.6.0 sur LinuxFr.org (82 clics)
- Communauté francophone darktable : darktable.fr (356 clics)
- Site officiel de darktable (807 clics)
- raw.pixls.us, le remplaçant de rawsamples.ch (108 clics)
- Visualisation gource (vidéo) de l’historique de développement entre la 2.2 et la 2.4 (99 clics)
- Les notes de sortie officielles sur GitHub (116 clics)
# Bravo et merci !
Posté par mahikeulbody . Évalué à 10. Dernière modification le 25 décembre 2017 à 15:09.
J'utilise Darktable (sous Linux) depuis deux ou trois ans maintenant (après avoir utilisé un peu Lightroom et DxO) et je n'envisage pas un instant de changer. On a l'impression que ce logiciel a changé de dimension depuis quelque temps (nb de contributeurs, version Windows, apparition/annonce de modules très sophistiqués, citations plus nombreuses dans les medias spécialisés, de plus en plus de tutos, etc…). Mais si cela a été possible c'est sans doute aussi parce que les fondations étaient saines grâce à ses premiers développeurs. Bravo à eux.
Dans le libre, il y a de la place pour tout le monde mais je me pose quand même la question de celle que peut encore avoir Raw Therapee…
J'allais oublier : merci pour cette superbe dépêche !
[^] # Re: Bravo et merci !
Posté par Stinouff . Évalué à 1.
RawTherapee a quelques qualités indéniables et l'ergonomie est bien meilleure. Darktable est franchement brouillon. Mais naturellement, je vais davantage vers lui que vers RT, désormais.
[^] # Re: Bravo et merci !
Posté par Pascal Obry (site web personnel) . Évalué à 1.
Je pense le contraire, difficile d'être objectif lorsqu'il s’agit d'ergonomie, on a chacun ses habitudes je suppose.
[^] # Re: Bravo et merci !
Posté par Stinouff . Évalué à 1.
Je pense quand même qu'il y a des progrès à faire de ce côté-là chez Darktable. Les menus déroulants pas très esthétiques, les curseurs peu précis, le passable entre le mode "table" et "retouches", les sélections, etc.
Je trouve RT plus fluide, plus lisse.
Mais de toute façon, je ne peux qu'approuver l'idée générale, c'est une question d'habitude.
[^] # Re: Bravo et merci !
Posté par ElectronLibre63 . Évalué à 1.
Qu'entends-tu par curseurs peu précis ? Personnellement j’apprécie justement les multiples façons de pouvoir utiliser les curseurs qui permettent aussi bien un usage précis que grossier.
Là je ne comprends même ce que tu veux dire.
[^] # Re: Bravo et merci !
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
Idem ici. Pour préciser, les possibilités avec dt sont :
(J'en oublie peut-être)
Ça me paraît dur de faire mieux en fait ;-).
# Merci pour cet outil de travail vraiment professionnel.
Posté par lviatour . Évalué à 10.
Merci pour cet article très détaillé sur l'évolution de Darktable.
J'utilise Darktable de manière professionnelle depuis maintenant trois ans.
C'est un outil extraordinaire, puissant complet et un outil de production. Il demande un minimum de formation mais après ce n'est que du bonheur de l'utiliser. Cette dernière version affine encore son utilisation. merci aux développeurs pour l’immense travail effectué. L'évolution de Darktable d'année en année est vraiment extraordinaire .
# Émuler les JPEG boîtier ?
Posté par Pieq . Évalué à 4.
Merci pour cet article très détaillé ! Ayant déjà lu les notes de version sur le site officiel, j'y ai quand même appris plein de choses, sans compter les exemples avec captures d'écran.
Est-ce que vous pouvez détailler un peu ce point ?
Je possède un Olympus OM-D qui effectue un gros travail en interne (au niveau de l'appareil) sur les JPEG. Je prends mes photos en RAW+JPEG, et quand je compare le fichier brut à l'ouverture dans Darktable et le fichier JPEG produit par le boîtier, j'ai souvent des surprises et j'ai bien du mal à arriver à l'aspect (couleurs, contrastes) fournis par le JPEG. Cependant, il y a souvent des choses à améliorer dans le JPEG et c'est pourquoi j'enregistre aussi au format brut…
Serait-il possible d'ouvrir le fichier brut et de faire en sorte de partir d'un point a peu près équivalent à ce que propose le JPEG qui sort du boîtier ?
Merci !
[^] # Re: Émuler les JPEG boîtier ?
Posté par mahikeulbody . Évalué à 8.
Appliquer les algorithmes et les paramètres utilisés par le boîtier pour élaborer le jpeg nécessite de connaître ces algorithmes et ces paramètres. Les paramètres sont certes décrits dans le fichier raw mais de façon non documentée, et les algorithmes ne sont pas décrits du tout. Le seul moyen d'obtenir les mêmes jpeg que le boîtier consiste à utiliser le logiciel de développement du fabricant (Olympus Viewer 3 dans ton cas) qui, malheureusement, n'est pas toujours au même niveau d'ergonomie et de fonctionnalités que ses confrères généralistes (Lightroom, Darktable, etc…).
Par ailleurs, il n'est pas pertinent de comparer l'affichage par défaut de Darktable avec le jpeg du boîtier. En effet, Darktable fait le choix d'appliquer le moins de traitements possibles par défaut : dé-rawtisation, balance des blancs et - optionnellement - un réglage émulant la courbe de base du boîtier. Il reste donc par définition du travail à faire. On peut cependant automatiser en partie ce travail via les styles (voir la documentation).
Mon dernier point est pour dire qu'il est très difficile au début de se mettre dans la tête que le jpeg du boîtier n'est pas la référence : des boîtiers de marque différentes équipés du même capteur (cas assez courant) produiront des jpeg différents de la même scène. Est-il crédible de penser que seul l'un d'entre eux a toujours "raison" ?
Le développement doit donc s'effectuer en pensant à l'image qu'on veut obtenir (par rapport à sa mémoire visuelle par exemple) en oubliant l'interprétation qui en a été faite à partir de choix arbitraires du fabricant, choix parfois heureux, parfois moins pertinents selon la scène. Facile à dire mais il m'a fallu beaucoup de temps pour passer cette étape…
[^] # Re: Émuler les JPEG boîtier ?
Posté par Pascal Obry (site web personnel) . Évalué à 6.
La solution pour avoir un jpeg proche de la version boîtier et de se faire un style en utilisant darktable-chart. Cet programme vas créer à partir d'un jpeg dt et un jpeg boîtier un style comportant entre autre un preset pour le module "table correspondance couleurs".
[^] # Re: Émuler les JPEG boîtier ?
Posté par Pieq . Évalué à 1.
Merci ! Je vais jeter un œil à cela.
[^] # Re: Émuler les JPEG boîtier ?
Posté par mahikeulbody . Évalué à 3.
Il serait plus exact de dire "pour avoir un jpeg avec une colorimétrie proche de la version boîtier".
[^] # Re: Émuler les JPEG boîtier ?
Posté par Pascal Obry (site web personnel) . Évalué à 1.
Franchement dans mon ellipse j'ai du mal à comprendre ce qui était ambiguë, bien entendu que je parlais de la colorimétrie. What else?
[^] # Re: Émuler les JPEG boîtier ?
Posté par mahikeulbody . Évalué à 1. Dernière modification le 28 décembre 2017 à 22:52.
Disons que le post de aurelienpierre un peu plus bas qui qualifie mon discours de complètement faux en brandissant darktable-chart alors que je parlais de tous les traitements qui font qu'un raw devient un jpeg (et donc pas seulement la colorimétrie) m'a rendu un peu sensible sur ce point. Mais j'admets que c'est une réponse au mauvais endroit, désolé…
Ceci dit, tu dis "comportant entre autre" : quels autres presets génère daktable-chart ?
[^] # Re: Émuler les JPEG boîtier ?
Posté par Pascal Obry (site web personnel) . Évalué à 3.
Cet outil désactive [courbe de base] et active trois modules [courbe des tonalités], [profil de couleur d'entrée] et [table correspondance couleurs].
[^] # Re: Émuler les JPEG boîtier ?
Posté par Pieq . Évalué à 1.
C'est ce qui me semblait. J'ai essayé Olympus Viewer 3 mais évidemment il n'y a pas de version Linux, et je n'ai pas réussi à lui faire charger un fichier brut depuis Wine (l'interface se lance, mais dès qu'on charge quelque chose ça plante). En outre, comme tu le dis, je pense que niveau fonctionnalités le soft d'Olympus reste très basique.
Je comprends bien ton point de vue, mais pour prendre un exemple concret, j'ai fait un portrait en intérieur l'autre jour (de nuit, donc éclairage artificiel). La teinte du visage sur le fichier JPG du boîtier était correcte, mais comme c'était un peu sombre je voulais utiliser le fichier brut pour modifier ombrages/hautes lumières. Après une demi-heure de bataille, je me suis rendu compte que le visage était super jauni et je n'ai pas réussi à trouver les bons réglages pour corriger cela… Je dois encore travailler pour mieux comprendre les modules de Darktable, mais s'il me faut une demi-heure pour chaque image à gérer, ça va vite devenir l'enfer (oui je sais qu'on peut copier/coller les styles, mais il y a quand même toujours un petit truc à modifier sur chaque image et on finit par y passer des heures :))
[^] # Re: Émuler les JPEG boîtier ?
Posté par mahikeulbody . Évalué à 1.
Un problème de balance des couleurs peut-être (même si par défaut darktable est censé prendre celle du boîtier) ?
[^] # Re: Émuler les JPEG boîtier ?
Posté par Torrone . Évalué à 1.
C'est probablement un problème de balance des blancs ou de réglage des couleurs comme dans le tutoriel suivant :
https://vimeo.com/57328898
[^] # Re: Émuler les JPEG boîtier ?
Posté par Thomas Debesse (site web personnel) . Évalué à 5.
En fait perso je n’ai pas beaucoup de styles que je copie-colle, mais j’ai câblé mon cerveau… Il y a un moment où à force de pratique on sait quel module utiliser et comment pour obtenir le résultat qu’on veux, un peut comme quand on sait retrouver une citation dans un livre qu’on connaît bien, sans aucun marque page, et même si le livre est neuf mais de la même édition (la citation sera au même endroit mais sans les marques) voire même avec un autre livre d’une autre édition parce qu’on sait où on va et où c’est dans l’histoire. Au pire on tâtonne sur quelques pages et pouf on trouve.
C’est pour cette raison que je fais un très grand soin à ne pas utiliser de logiciel propriétaire car je ne veux pas câbler mon cerveau sur un outil qui appartient à un autre et à qui je remettrais tout pouvoir sur ma compétence. J’utilise des logiciels libres parce que je ne veux pas remettre les clés de ma compétence à un tiers qui pourrait décider selon son bon vouloir que je n’ai plus le droit de mettre en œuvre mes compétences. C’est aussi pour cette raison que je fuis les logiciels avec abonnement : je ne veux pas devenir locataire de ma compétence.
Note que je suis un peu perdu quand je change de capteur parce que je ne suis pas câblé, et beaucoup perdu quand le capteur est d’une autre marque. C’est pour cette raison : il faut déjà recâbler son cerveau pour les capteurs (et probablement certains traitements appliqués quand même au raw), c’est donc vraiment très très important que quelque chose ne change jamais : Darktable. Au moins je n’ai qu’à me réajuster selon le capteur.
Apprendre un logiciel, c’est fabriquer des neurones et câbler des neurones, c’est hardcoder son cerveau pour ce logiciel, c’est pourquoi les logiciels doivent être libres car celui qui possède le logiciel a pouvoir sur cette partie du cerveau et peu décider de la rendre inutile à tout moment. C’est le vrai sens de « propriété intellectuelle ».
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Émuler les JPEG boîtier ?
Posté par aurelienpierre . Évalué à 3.
non, c'est complétement faux. On peut s'en sortir en faisant un profil de couleur entrée/sortie, ce qui est géré par darktable avec l'utilitaire
darktable-chart, dont le profil généré peut être utilisé dans le module table de correspondance de couleurs (Look Up Table/LUT en anglais).L'idée est de créer une table de correspondance entre les couleurs du RAW (entrée) et leur interprétation par le logiciel interne du boîtier (sortie). Une fois qu'on a extrait les gains de chaque échantillon de couleur dans l'espace HSL (teinte/saturation/luminosité), on peut reproduire n'importe quel traitement de couleur sans avoir besoin de connaître ses algorithmes internes. Ça marche aussi pour reproduire la colorimétrie de la pellicule. Plus la table comporte un grand nombre d'échantillons, meilleure est la précision du profilage.
L'objectif des gens qui veulent reproduire le rendu des jpg boîtier dans leur dé-raw-tiseur est généralement d'obtenir un résultat visuellement satisfaisant, rapidement et sans avoir à tripoter tous les curseurs du logiciel, mais en conservant une certaine marge de manœuvre dans la récupération des détails (plage dynamique, traitement du bruit, etc.). Leur expliquer que ça ne sert à rien est contre-productif, et c'est de toute façon faux. Toutes les photos ne méritent pas une retouche détaillée (dit le mec qui passe 3h de retouche par photo sur des shootings mode/beauté).
[^] # Re: Émuler les JPEG boîtier ?
Posté par mahikeulbody . Évalué à 4.
Je me retrouve dans cet objectif et après avoir traité l'exposition, les niveaux, le recadrage, etc… j'étais en général satisfait du résultat sans avoir eu à faire de la colorimétrie (hormis parfois via la balance des blancs), heureusement d'ailleurs car ce n'est pas très simple. Sauf que quand je comparais au jpeg du boîtier, oh horreur le vert du gazon n'était pas tout à fait le même, etc… et j'essayais alors de me lancer dans les modules de colorimétrie. Jusqu'au jour où on m'a fait comprendre qu'il n'y avait aucune raison de faire ça si le résultat initial était satisfaisant et pas moins "vrai" que le soi-disant "original" boîtier.
Dans mon histoire à moi, comprendre ça m'a fait gagner du temps, bien au contraire.
En revanche, si pour un boîtier donné Darktable ne produit pas une bonne colorimétrie alors que celle du boîtier est ok (et sans se laisser abuser par "jpeg boîtier = original" !), darktable-chart est une solution et tu as bien fait de la citer.
# 2.4 macOS pas encore dispo?
Posté par Nico7as . Évalué à 1.
Salut à tous,
J'ai essayé de l'installer pour macOS, mais c'est version la version 2.2.4.6 qui est proposée, hors je suis déjà en 2.2.5
Une idée d'un endroit ou je pourrais trouver la 2.4? merci!
[^] # Re: 2.4 macOS pas encore dispo?
Posté par Pascal Obry (site web personnel) . Évalué à 2.
Le mainteneur de la version MacOS n'est pas dispo pendant les vacances. Il te faudra attendre.
[^] # Re: 2.4 macOS pas encore dispo?
Posté par Nico7as . Évalué à 1.
ok merci!
# Bravo !
Posté par bibifric05 . Évalué à 3.
Bravo à tous les développeurs de Darktable pour le travail accompli ces dernières années.
Je suis très heureux de voir arriver enfin une version Windows, qui devrait amener beaucoup d'utilisateurs et contribuer à l'amélioration de l'interface, qui reste pour moi le gros point noir de Darktable.
Vu le changement récent dans le mode de paiement de Lightroom (peu apprécié par pas mal d'utilisateurs), je pense que Darktable a une bonne carte à jouer, à condition que son interface soit améliorée pour être plus intuitive.
Les corrections locales par empilement de modules sont certes puissantes, mais il manque un module permettant la sélection d'une zone et l'application de plusieurs corrections (exposition, teinte, contraste, détail, récupération des hautes lumières, récupération des ombres, etc.) en une seule fois.
Sinon, un petit détail de traduction : tout le monde en technique photo sait ce que fait un module de "correction du voile" (atmosphérique), je pense donc que le terme "correction de la brume" est mal choisi…
[^] # Re: Bravo !
Posté par mahikeulbody . Évalué à 3.
On peut réutiliser un même masque dans différents modules. Ça ne suffit pas ?
[^] # Re: Bravo !
Posté par bibifric05 . Évalué à 2.
Non, ce n'est pas du tout pratique. Il est bien plus logique et efficace de sélectionner une zone et de lui appliquer diverses corrections que de choisir un module, sélectionner une zone, appliquer la correction, puis sélectionner à nouveau un module, rappeler le masque, appliquer la correction, etc.
Quand on traite une photo où l'on a une dizaine de zones locales à retoucher, ça devient vite très lourd…
[^] # Re: Bravo !
Posté par Pascal Obry (site web personnel) . Évalué à 2.
Oui mais là il n'y a aucune chance que cela arrive. Le design de base de darktable est que le module est l'élément initial, puis on choisi si l'effet du module est global ou local. On peut dire que c'est moins ergonomique, mais je pense que c'est différent et que comparer n'est pas une bonne chose. Vaut mieux se faire à la philosophie de l'outil… ou pas :)
[^] # Re: Bravo !
Posté par bibifric05 . Évalué à 0.
Comparer est toujours une bonne chose…
Sinon, je pensais tout simplement rajouter un module regroupant les corrections les plus basiques : exposition, hautes et basses lumières, détail, flou, teinte, etc.
Ensuite, ce module peut être utilisé pour les corrections locales…
Est-ce faisable ?
[^] # Re: Bravo !
Posté par Pascal Obry (site web personnel) . Évalué à 1.
Oui ceci est plus faisable. Maintenant je doute que cela arrive comme cela. Pourquoi pas un méta-module utilisateur qui pourrait regrouper un ensemble d'autres modules sélectionnés. Cela permettrait à chacun de se constituer un module basique. Mais ce n'est pas dans les tuyaux alors ne pas retenir sa respiration en attendant :)
[^] # Re: Bravo !
Posté par Elfir3 . Évalué à 3.
Ne pourrait-on pas imaginer un module (vertical) chargé de la définition des zones, et laisser les autres modules les utiliser pour l'application locale ? La migration se ferait assez aisément, et pourrait même être rétro compatible. On pourrait imagine que si une zone est sélectionnée, les modules nouvellement activés le sont par défaut sur la zone uniquement. Ainsi, l'utilisateur pourrait choisir son flow préféré.
PS: j'ai testé darktable il y a bien longtemps, c'est peut-être déjà comme ça qu'il fonctionne.
[^] # Re: Bravo !
Posté par Letho . Évalué à 4.
Effectivement, tu peux gérer tes masques indépendamment des modules, via l'outil « Gestion des masques », à gauche dans la chambre noire :)
[^] # Re: Bravo !
Posté par Pascal Obry (site web personnel) . Évalué à 2.
Et ensuite sélectionner tes masques dans les modules correspondants. Donc les deux approches sont possibles. C'est déjà très bien car il est assez difficile de trouver un design simple pour supporter deux méthodes de travail dans un logiciel assez complexe.
[^] # Re: Bravo !
Posté par Pascal Obry (site web personnel) . Évalué à 4. Dernière modification le 26 décembre 2017 à 18:48.
Espérons que la contribution ne soit pas uniquement des critiques du type "je n'aime pas cela" :) Puisque l'interface est basée sur CSS il est possible de la changer en profondeur sans recompiler… Mais malgré cela et bien aucune contribution depuis 2 ans :)
[^] # Re: Bravo !
Posté par Matthieu Moy (site web personnel) . Évalué à 6.
Attention, la relation de cause à effet entre la qualité de l'interface et le nombre d'utilisateurs n'est pas si simple que ça. En simplifiant un peu, je dirais qu'il y a 3 catégories de gens liés à un logiciel libre : les développeurs, les utilisateurs passifs, et ce que j'appelle parfois les « utilisateurs coopérants », qui font des rapports de bugs bien faits, participent de manière constructive aux discussions, et pourquoi pas envoient un patch de temps en temps … La version Windows va vraisemblablement augmenter significativement le nombre de personnes de la deuxième catégorie, mais j'ai de gros doutes sur la troisième. Je ne suis pas trop la communauté GIMP, mais les retours que j'ai vu ont l'air de dire que la masse d'utilisateurs sous Windows est plus douée pour râler quand ça ne marche pas que pour être vraiment constructif.
Pour l'instant, j'ai vu beaucoup de monde arriver sur les forums en cherchant plus ou moins à faire pareil avec dt qu'avec LR (ce qui pour moi qui n'ai jamais utilisé LR n'est pas vraiment intéressant).
Oui, tu dis à peu près la même chose à chaque fois qu'on parle de darktable. Perso, je n'ai jamais eu besoin de ça. Quand je veux faire une retouche, je sais quel module je vais utiliser et je commence par là, et je décide après comment je limite l'effet. C'est assez rare que j'utilise exactement le même masque pour plusieurs effets : même si je cible la même zone, pour certains modules je vais avoir une limite un peu tranchée, pour d'autres un affaiblissement plus progressif, … Je ne prétend pas que ma manière de bosser est forcément la bonne, mais inversement quand tu écris « Non, ce n'est pas du tout pratique. Il est bien plus logique et efficace de … », tu généralise trop vite ton cas : c'est plus pratique pour toi, OK (et du coup il y a peu de chance que tu sois heureux sous dt), mais un message qui démarre par une affirmation comme celle-là (avec laquelle tu sais pourtant que les développeurs sont en désaccord) a peu de chance d'être lu de manière constructive.
Ça a été discuté sur darktable.fr avec Pascal, qui contribue à la traduction française. C'est une traduction littérale de « haze removal », et je la trouve plutôt adaptée. OK, ce n'est pas le même nom que sous LR, mais le module de dt est vraiment bon pour supprimer la brume justement, et pas si bon pour enlever la teinte bleutée du voile atmosphérique.
[^] # Re: Bravo !
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10.
Il y a tout de même des rapports de bugs de gens sous Windows, donc dans le sens que tu donnes plus haut, ce sont des "utilisateurs coopérants". Mais ça va rarement au delà de ce niveau de coopération. En particulier, on a quasi aucun développeur Windows. Par périodes, y a quelques développeurs Windows qui font plus de patches que la moyenne et restent dans le coin plus que d'autres (y a un régulier qui a fait quelques patchs en 2017), mais ça reste souvent épisodique et pas de manière suffisamment active pour qu'on puisse dire que GIMP sous Windows soit vraiment stable et maintenu.
Pourtant on fait tout pour les garder! Genre on les enferme gentiment dans la cave avec du pain de qualité, de l'eau propre et un ordi sous Windows avec GIMP! Ils arrivent toujours à s'enfuir au bout d'un moment! :P
Blague à part, je pense que beaucoup plus de gens sous Windows utilisent GIMP que sous Linux (même si on a pas de stats), pourtant au final quasi personne ne développe ou teste GIMP sous Windows. Donc on a plein de bugs parfois super basiques qui traînent des mois/années dans notre gestionnaire de bugs. La plupart des développeurs de GIMP (et en particulier les plus actifs) utilisent essentiellement Linux. Parfois on corrige des bugs Windows, souvent un peu à l'aveuglette. Y a encore quelques jours, j'en ai corrigé un. Pour la petite histoire, c'était le plugin d'export WebP et quand je propose au reporteur de tester un binaire que je cross-compile, il s'étonne que personne ne teste sous Windows. Ma réponse est que ça nous étonne aussi!
Faut bien comprendre que c'est du logiciel libre, qu'on n'est sur aucun "marché" et qu'on n'a aucune obligation de tester ou développer pour Windows. Je pense que certains ne s'en rendent pas compte effectivement et nous considèrent parfois comme un "service après vente" et qu'on leur doit de corriger tous les bugs (je précise que ce n'était pas le cas de cette personne y a quelques jours, laquelle était tout à fait ok; mais parfois c'est vrai qu'on lit des réactions bizarres sur d'autres rapports de bug et c'est pas toujours très agréable).
Au final, je pense que parfois, on devient un peu blasé et qu'on a de moins en moins envie de corriger ces bugs parce qu'on aimerait bien que les gens qui sont sous Windows et veulent y voir GIMP se prennent un peu en charge. En gros, si y avait des très actifs montrant qu'ils tiennent à leur OS, on serait heureux de les aider; mais là on a parfois l'impression qu'ils attendent qu'on leur donne la becquée.
Même moi, je me rends compte que je corrige moins de bugs Windows qu'avant, même si ça m'arrive encore régulièrement (comme y a quelques jours donc), surtout que je finis souvent par lancer une VM Windows et je dois dire que ça m'amuse pas beaucoup.
Notons qu'il n'est même pas forcément besoin d'être développeur (car y a la fameuse remarque du "tout le monde ne peut pas être développeur"). Par exemple parmi nos contributeurs très très actifs, j'en compte au moins trois qui ne sont pas vraiment des développeurs. Mais ils font des recherches, parfois sortent un peu de leur zone de confort en s'essayant à des activités un peu techniques, ont appris à compiler GIMP, ils testent des patchs (pas de la revue de code, mais au moins testent que ça marche bien), ils reproduisent des bugs et font des commentaires explicatifs pour aider les développeurs, ils gèrent les rapports de bugs, cherchent et trouvent les duplicatas, ferment des rapports de bugs simples (par exemple qui ne sont pas des bugs mais des incompréhensions, des erreurs, des duplicatas ou des bugs précédemment corrigés, etc.), ils écrivent des news sur le site, etc. Ils abattent un travail monstre et par cela aident énormément notre travail de développement.
Ces personnes là aussi sont toutes principalement sous Linux (même si 2 d'entre eux utilisent parfois Windows pour le boulot et il arrive donc qu'ils aident là aussi occasionnellement mais ce n'est pas leur OS de prédilection)! Franchement même déjà avoir des gens comme cela avec OS principal Windows serait d'une aide formidable. Mais personne à ce jour ne semble être suffisamment intéressé. :-/
Pour info: c'est pas beaucoup mieux sous macOS. On a aussi quelques réguliers (en fait un surtout, je crois! Et il vient d'agrandir sa famille y a quelques mois donc les bugs macOS s'accumulent dans le gestionnaire de bugs; comme quoi ça tient à rien).
P.S.: des gens qui ne font que demander, voire exiger, et parfois de manière désagréable même, y en a aussi sous Linux. Ou bien ceux qui nous prennent pour un service client et on devrait s'estimer heureux qu'ils utilisent notre logiciel. De même que des gens super compréhensifs, reconnaissants et même qui prennent beaucoup de leur temps pour aider à débugger existent aussi sous Windows/macOS (encore aujourd'hui y a eu une personne sous macOS qui a fait plein de tests pour aider à débugger, sans être développeur lui même!). On a aussi régulièrement des patchs de contributeurs uniques (qui viennent, déposent un patch et disparaissent) pour ces plateformes. Et bien sûr chacun est libre d'utiliser son temps de la manière qu'il veut et nous n'en voulons à personne pour ne pas contribuer sur le long terme!
Je veux pas surtout pas donner l'impression que les gens sous Linux sont des bisounours et que ceux sous les OS proprios sont tous des ingrats malotrus. Soyons clair.
Je parle seulement de ratio final des développeurs actifs et de long terme (ceux qui font qu'on peut considérer un logiciel comme étant "maintenu"). Et on peut clairement dire que GIMP est très bien et activement maintenu sous Linux, alors que pour Windows ou macOS, je pense que ce serait s'avancer un peu…
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Bravo !
Posté par claudex . Évalué à 1.
Gimp ne marche pas avec Wine ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Bravo !
Posté par Matthieu Moy (site web personnel) . Évalué à 5.
Si tu veux vraiment tester (reproduire et/ou vérifier qu'il a disparu) un bug spécifique Windows, tester sous wine a peu de chances d'être suffisant.
[^] # Re: Bravo !
Posté par claudex . Évalué à 2.
Je suis bien d'accord que ça ne marche pas pour tous les bugs, mais ça permet d'en tester une partie tout en évitant de devoir se taper un windows.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Bravo !
Posté par Jehan (site web personnel, Mastodon) . Évalué à 7.
Quand t'as pas le choix, Wine peut servir pour quelques tests. Mais pour une très grande classe de bugs, cela rajoutera juste beaucoup de faux positifs comme de faux négatifs.
Déjà que GIMP est à peine maintenu sous Windows, si en plus les seuls tests étaient fait sous Wine…
Notamment l'un des problèmes de Wine est que ça n'émule pas les librairies Windows mais traduit des appels systèmes en appels locaux (si possible), ou réimplémente les appels qui ne peuvent être simplement traduits. Note que je dis "problème", mais c'est un des grands atoûts aussi, notamment car ça veut dire qu'il n'y a pas besoin de licence Windows pour exécuter un logiciel Windows sous Win car il n'y a aucun binaire Windows dedans; aussi sans cela, Wine ne pourrait probablement pas être fourni dans nos distribs Linux, ou du moins pas "prêt à l'emploi", demandant aux gens de manuellement copier des fichiers Windows, ou faisant d'autres galipettes logiques avant d'être utilisable. Donc de manière générale, c'est en fait un énorme avantage de Wine dans la plupart des cas. Mais pour de l'émulation système et des tests poussés de reproductions de problèmes (surtout ceux spécifiques à Windows et qu'on ne reproduit pas sur Linux, donc exactement ce qui nous intéresse justement), ça devient bien plus problématique.
Tiens, pour l'exemple du bug corrigé y a quelques jours, on ouvrait un fichier en mode "wb+" (lecture, écriture en binaire). Ce mode marche très bien avec le fopen() de Linux. Mais on a donc découvert que pas sous Windows. Par contre, le mode "w+b" (qui est un alias de "wb+" et est donc exactement la même chose) marche parfaitement sur les 2 systèmes. Ce fut donc la correction effectuée.
Ben ce serait intéressant de tester, mais si Wine remplace simplement l'appel fopen() win32 par celui de Linux (comme j'imagine qu'il ferait, après tout cet appel système existe sur tous les OS apparemment et a la même interface), je pense que le bug disparaîtrait sous Wine (sauf si les développeurs de Wine rajoutent du code spécifique pour émuler davantage les limitations de mode dispos sur chaque système, mais y aurait vraiment peu d'avantages de faire cela).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Bravo !
Posté par claudex . Évalué à 3.
Tu aurais un lien vers le binaire Windows qui pose problème ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Bravo !
Posté par Jehan (site web personnel, Mastodon) . Évalué à 6. Dernière modification le 30 décembre 2017 à 16:55.
Tu peux simplement installer GIMP 2.9.8 pour Windows. Le bug s'y trouve (l'export Webp ne marche pas avec Win32, ou en tous cas, sous Windows 10).
Bien plus simplement, tu pourrais juste faire un test avec un programme C minimal qui ouvre un fichier en "wb+". Si ça marche sous Wine, c'est que le comportement est différent qu'avec l'API Win32 de Windows 10 (ou ça ne marche pas) et le bug ne peut donc pas y être reproduit.
Et si ça marche pas, ben ça prouve rien du tout! Le fait est que Wine n'a pas vocation à utiliser le code de Windows (ils le disent eux même, c'est l'acronyme du logiciel: Wine Is Not an Emulator) et donc toute une grande majorité des bugs spécifiques à Windows et qu'on ne peut pas reproduire sous Linux (exactement ceux qui nous intéressent ici) ne seront probablement pas reproduisibles avec Wine non plus.
Et même si c'est reproduit, ça utilise quand même des implémentations systèmes différentes (par définition de ce qu'est Wine) donc c'est peut-être juste du "hasard", pas de la vraie reproduction de bug.
Enfin bon, tu peux t'amuser à tester si tu veux, si vraiment ça t'intéresse et que tu as du temps, et viens nous donner le résultat ici, mais ça ne changera pas le fait que Wine n'est pas de l'émulation de Win32. C'est une réimplémentation + redirection d'appels systèmes. Y aura donc des bugs en moins et beaucoup de bugs en plus.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Bravo !
Posté par Jehan (site web personnel, Mastodon) . Évalué à 4.
En un sens, Wine est un autre système d'exploitation, qui se trouve avoir la même API système que Win32, ainsi que les mêmes formats binaires d'exécutables, et la même organisation des fichiers. Du moins ils essaient. Mais les implémentations sont différentes (ils ne partagent pas une ligne de code, sauf peut-être par hasard pour le code que Microsoft a repris de logiciels libres; Wine n'utilise aucun binaire propriétaire de Microsoft, etc.), et les bugs seront donc différents.
Il y aura donc une classe de bugs testables (ceux notamment en rapport avec l'organisation des fichiers par exemple), mais elle est petite. La grande majorité des bugs qui n'affectent que Windows ne seront vraisemblablement pas reproduisibles. Et inversement un bug rencontré sous Wine ne signifie pas que ce bug existe sous Windows. Ce sont des systèmes distincts, malgré la ressemblance.
Tu ne peux pas donc décemment développer et tester du code Win32 avec Wine.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Bravo !
Posté par claudex . Évalué à -2.
Je trouve que tu es trop limitatif. Le but est que les api soient les mêmes. Tu as donc plein de tests liés à l’utilisation correcte de l’API qui peuvent être testé. Même si évidemment, il y a des bugs qui n’apparaîtront que dans une implémentation. Tu as aussi le cas, dans une moindre mesure, entre les différentes versions de Windows.
Je trouvais juste étrange à la base de lancer une vm Windows plutôt que de d'abord tester avec Wine. Surtout dans le cas du bug en question où tu peux vérifier si tu as le même ou pas.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Bravo !
Posté par Jehan (site web personnel, Mastodon) . Évalué à 6.
Dans le cas du bug en question, j'aurais installé GIMP dans Wine, j'aurais testé et… serait tombé sur le même bug que toi qui m'empêche de pouvoir aller plus loin (et j'aurais donc même pas pu tester le bout de code que je voulais tester, juste comme toi).
Puisque mon but n'est pas de tester GIMP sous Wine (on fournit une version native Linux de GIMP, donc on s'en fiche un peu de si win32 GIMP tourne bien sous Wine), je me serais pas embêté à débugger pourquoi ça marche pas à un autre endroit du code. J'aurais donc au final quand même lancé ma VM Windows et testé GIMP dedans. Donc je me serais juste rajouté plein d'étapes intermédiaires (à peine moins chiante que tester dans une VM soit dit en passant).
Et même si j'avais pu tester ce bout de code sous Wine, ça m'aurait de toutes façons rien dit sur le même code dans Win32 (puisque l'implémentation de fopen() utilisée par Wine n'est pas celle de Win32! Ça utilise à mon avis juste fopen() de Linux). Donc quel que soit le résultat, ce test aurait été inutile et aurait juste pris de mon temps; au final j'aurais dû quand même lancé une VM (ou dû attendre que quelqu'un sous Windows confirme la correction).
Je comprends pas pourquoi tu t'obstines. Wine n'est pas un émulateur et n'utilise pas de code de Windows. Tout bug spécifique à l'implémentation de l'API win32 n'est donc tout simplement pas testable dans Wine. Donc non, tu ne "peux pas vérifier si tu as le même ou pas" dans Wine! C'est juste pas comment Wine marche.
Et en plus tu viens de faire la preuve toi-même que tester sous Wine aurait juste été de la perte de temps dans ce cas concret.
P.S.: c'est dans dernier message sur ce sujet! :P
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Bravo !
Posté par claudex . Évalué à 4.
Du coup, j'ai testé et avec Wine, il n'y a pas moyen d'exporter cela freeze l'interface quand on clique sur « Exporter » dans la boîte de dialogue de sélection du nom de fichier.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Bravo !
Posté par Jehan (site web personnel, Mastodon) . Évalué à 4.
Et ouais, exactement ce que je disais: Wine n'est pas Windows, c'est même pas de l'émulation Win32. Ce qui marche dans l'un ne marche pas forcément dans l'autre (et inversement, ce qui ne marche pas dans l'un peut marcher dans l'autre).
Je dirais presque qu'y aucun rapport, aucun lien, et c'est comme ça que le projet Wine l'a voulu (pour une très bonne raison d'ailleurs, ce qui fait de Wine un logiciel entièrement libre et sans binaire proprio, mais ça a un prix).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Bravo !
Posté par claudex . Évalué à 2.
Non, ce qui marche dans Windows est censé marcher dans Wine. C'est le but du projet. C'est un bug de Wine (ou c'est lié à mon installation).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Bravo !
Posté par Pascal Obry (site web personnel) . Évalué à 6.
Un bug de Wine et c'est bien ce que Jehan dit, lorsque tu veux tester GIMP si tu dois encore analyser les problèmes pour savoir si c'est une bug de l'appli ou de Wine tu perds un temps précieux.
[^] # Re: Bravo !
Posté par claudex . Évalué à -2.
Mais tu gagne le fait de ne pas devoir lancer une VM Windows à chaque fois.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Bravo !
Posté par Pascal Obry (site web personnel) . Évalué à 3.
Non, comme le dit Jehan aussi on perd son temps dans la plupart des cas.
# Encore une dépêche à la hauteur de l'évènement
Posté par carafife . Évalué à 7. Dernière modification le 26 décembre 2017 à 19:43.
Salut à tous,
Les devs de darktable nous ont encore gâté comme chaque noël depuis maintenant plusieurs années! Cette nouvelle mouture prouve encore tout le potentiel et surtout tout le suivi dont nous pouvons être fiers. L'occasion m'est encore donnée pour remercier Mathieu de son super boulot et de son implication dans le projet. Mathieu s'est en effet rapproché de la communauté de darktable.fr afin d'échanger avec elle sur cette dépêche et même de la faire participer.
Rappelons encore comme le signalait en substance Pascal OBRY que darktable n'est pas un clone de LR et que son fonctionnement diffère. Ne pas essayer de le comparer sans cesse est un gage d'apprentissage réussit. Darktable est maintenant porté sous Windows. Il pourra offrir une alternative libre aux copains du "W" piégés par la nouvelle orientation commerciale d'Adobe. J'espère que celles et ceux venant de ce système accrocheront leurs manteaux de "clients" afin de rejoindre notre communauté ouverte et libre sous les meilleurs hospices car dans le libre on exige rien, on participe.
Je souhaite une longue et brillante "carrière" à ce nouvel opus en attendant avec une impatience tout juste contenue, l'implantation des modules d'Aurélien et d'Edgardo qui renforceront de leurs puissances les capacités déjà énormes de darktable.
Un grand merci à Mathieu et un joyeux noël à tous ;-)
[^] # Re: Encore une dépêche à la hauteur de l'évènement
Posté par Pierre Jarillon (site web personnel) . Évalué à 9.
Sous de meilleurs auspices
Je râle contre les fautes d'orthographe et de grammaire, mais ici c'est faux sens.
Désolé de relever cela, mais celui qui a fini d'apprendre a déjà commencé à mourir…
[^] # Re: Encore une dépêche à la hauteur de l'évènement
Posté par eingousef . Évalué à 5.
tu veux l'envoyer à l'auspice ?
*splash!*
[^] # Re: Encore une dépêche à la hauteur de l'évènement
Posté par Matthieu Moy (site web personnel) . Évalué à 4.
Tss tss, et le deuxième « t » à mon prénom ? ;-).
Toujours un plaisir cette désormais tradition de découvrir et d'explorer les nouveautés de dt en écrivant une dépêche sur linuxfr :-).
[^] # Re: Encore une dépêche à la hauteur de l'évènement
Posté par carafife . Évalué à 0.
;-)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.