Travailler sur une version compilée de darktable

Cet article est une réédition mise à jour d’un précédent article publié sur mon blog personnel il y a maintenant presque un an. Suite à de récentes demandes de plusieurs utilisateurs sur la communauté Framateam à ce sujet, j’ai proposé aux administrateurs du blog de le republier ici afin d’améliorer la visibilité de celui-ci et de permettre d’accompagner le plus grand nombre d’utilisateurs de darktable souhaitant compiler le logiciel. Merci à eux pour me permettre de l’écrire ici et j’espère que cet article vous sera utile.

Introduction

Vu que cet article est mon premier sur ce blog, je suppose que peu de lecteurs me connaissent. Pour me présenter en quelques mots, je pratique la photographe en amateur depuis environ 10 ans, et étant fervent défenseurs du logiciel libre, le traitement de mes photos via un logiciel libre est vite devenu une évidence. J’ai longtemps travaillé sur Rawtherapee pour passer sur darktable à partir de la version 2.0. Bien que je ne maîtrise pas encore totalement le logiciel, loin de là même, je l’utilise tout de même sérieusement depuis environ la version 2.4 au moment où j’ai décidé de repartir sur une base saine. Je n’ai au final que quelques années de recul de son utilisation. Depuis la version 2.6, l’arrivée d’Aurélien dans l’équipe de développement et la création de la communauté sur Framateam, j’ai été amené à discuter beaucoup plus régulièrement avec l’équipe de dev francophone et même à en rencontrer certains en dehors d’Internet. Petit à petit, la tentation d’utiliser une version compilée du logiciel et de commencer à donner un coup de main à mon humble échelle a été de plus en plus forte. Finalement, c’est à partir de la sortie de la version 2.6 que j’ai franchis le pas en compilant pour la première fois ma propre version.

À l’heure actuelle, j’utilise exclusivement la version master de darktable (3.1.0) pour traiter mes photos afin de profiter des dernières évolutions et améliorations du logiciel, les bénéfices liés aux améliorations techniques du logiciel étant bien supérieurs aux risques liés à l’utilisation d’une version en cours de développement. Il m’arrive aussi de compiler d’autres versions plus spécifiques du logiciel pour faire un retour des bugs ou problèmes sur les toutes dernières nouveautés.

Faute d’avoir de bonnes connaissances techniques sur le fonctionnement de Github et plus généralement sur la façon dont on compile un logiciel sur Linux, je me suis fait aidé par les développeurs du logiciel pour mes premiers pas. Pour en faire profiter la communauté, j’ai décidé de rapporter et d’expliquer précisément la méthode sur mon blog personnel.

Ce présent article est donc une synthèse sur la façon dont on compile et installe ses propres versions de darktable sur sa machine Linux (désolé, n’utilisant pas Windows, je ne peux pas expliquer la méthodologie sur ce système d’exploitation), ainsi que les différentes mesures de sécurité que j’ai mises en place afin d’éviter de mélanger les versions et perdre des traitements de photos ou casser ma version de production.

/!\ Attention /!\

Installer plusieurs versions de darktable sur un même ordinateur et travailler sur des versions en cours de développement peut comporter certains risques. Même si je présente ici une méthode permettant de travailler en toute sécurité, faites bien attention à ce que vous faite au risque de perdre des données.

Pourquoi utiliser des versions compilées ?

Avant même de commencer à compiler darktable sur son ordinateur, il est intéressant de se demander pourquoi. Avec du recul, j’y vois plusieurs avantages.

Tout d’abord, comme je l’ai dit plus haut, il est possible d’installer la version en cours de développement (qu’on appelle la version master) afin de pouvoir la tester et rapporter aux développeurs les éventuels bugs pour aider leur travail. Très souvent, ces retours leur sont d’une très grande aide pour améliorer le logiciel et éviter des bugs inattendus à la sortie d’une version stable.

Ensuite, il est courant que les versions de darktable dans les dépôts des distributions Linux arrivent bien après la sortie officielle d’une nouvelle version, utiliser une version compilée chez soi permet par conséquent de profiter immédiatement des dernières versions stables. Par exemple, la version 3.0.0 de darktable est sortie le 25 décembre 2019 et beaucoup de distributions basées sur Debian (Ubuntu, Mint, etc.) sont encore sur la version 2.6.x à ce jour, voire 2.4.x sur les versions LTS… Sur Fedora, bien qu’elles arrivent assez rapidement, il faut tout de même attendre quelques semaines avant d’avoir la nouvelle version proposée dans les dépôts officiels.

Un autre aspect qui est intéressant quand on compile sa propre version d’un logiciel, c’est que celle-ci est optimisée pour la machine et donc plus rapide. Je n’ai cependant pas senti une très grosse différence à ce sujet.

Enfin, simplement par curiosité si vous voulez « jouer » sur les derniers modules en cours de développement avant tout le monde. 🙂

Prérequis de sécurité

Afin de pouvoir travailler sur différentes versions de darktable sur une même machine, il est nécessaire de respecter quelques points très importants :

  • n’utilisez pas les mêmes dossiers de photos pour plusieurs versions, en effet, les fichiers .xmp liés aux traitements des photos ne sont pas toujours compatibles entre les versions de développement (3.1.x) et stables (3.0.x actuellement), vous risquerez donc de perdre définitivement vos traitements.

solution : lorsque je travaille sur différentes versions de darktable, chaque version a son propre dossier de photos afin d’éviter de mélanger les fichiers xmp. Ma version de production utilise mon dossier principal de photos et les versions parallèles (pour tester les nouvelles fonctionnalités) utilisent un dossier où est présent un échantillon un peu représentatif de photos pour pouvoir tester différents modules dessus : forte plage dynamique, haut ISO, paysage, portrait, etc.

  • utilisez des dossiers de configuration du logiciel différents pour chaque version, cela vous évitera de bousiller votre version de production (stable ou non) en utilisant le même dossier de configuration avec celle d’une version instable.

solution : sur mon ordinateur, j’ai un dossier ~/.config/darktable_master/ pour ma version de production (où sont toutes mes photos) et des dossiers ~/.config/darktable_<nom>/ pour les versions de développement : par exemple ~/.config/darktable_pascal/ pour une version du code de Pascal Aubry, ~/.config/darktable_aurelien/ pour une version d’Aurélien Pierre, etc. Cela permet de m’y retrouver plus facilement dans mes dossiers si un jour je devais avoir plusieurs versions installées. Nous verrons plus loin comment spécifier à darktable quel dossier de configuration utiliser lors de son lancement.

  • faites des sauvegardes, toujours, tout le temps, partout, plein de fois… On ne le dira jamais assez, mais faites des sauvegardes. 🙂

solution : lorsque je compile une version instable ou des gros ajouts de code dans la version master, je fais des sauvegardes de mon dossier ~/.config/darktable_master/ qui contient les base de données de ma table lumineuse. Cela me permet de faire machine arrière en cas de gros problème.

Installation des dépendances

Avant de télécharger et compiler darktable, il faut tout d’abord s’assurer à avoir toutes les dépendances nécessaires à la compilation du logiciel.

  • Sur Fedora (et CentOS) la liste des packages à installer est la suivante :
# dnf install git make cmake gcc-c++ intltool gtk3-devel libxml2-devel lensfun-devel librsvg2-devel sqlite-devel libcurl-devel libjpeg-turbo-devel libtiff-devel lcms2-devel json-glib-devel exiv2-devel pugixml-devel libxslt osm-gps-map-devel libsoup-devel libgphoto2-devel OpenEXR-devel libwebp-devel flickcurl-devel openjpeg-devel libsecret-devel GraphicsMagick-devel osm-gps-map-devel colord-devel colord-gtk-devel cups-devel SDL-devel lua-devel
  • Sur Debian (et Linux Mint et Ubuntu), la liste est la suivante :
# apt-get install gcc g++ git cmake intltool xsltproc libgtk-3-dev libxml2-utils libxml2-dev liblensfun-dev librsvg2-dev libsqlite3-dev libcurl4-gnutls-dev libjpeg-dev libtiff5-dev liblcms2-dev libjson-glib-dev libexiv2-dev libpugixml-dev libcolord-dev libcolord-gtk-dev libcups2-dev libgphoto2-dev libsoup2.4-dev libopenexr-dev libwebp-dev libosmgpsmap-1.0-dev libflickcurl-dev libsecret-1-dev libgraphicsmagick1-dev llvm clang liblua5.3-dev

Installation de la version master (version 3.1.0 de développement)

La version master de darktable correspond à la version en cours de développement où les développeurs ajoutent les dernières évolutions du logiciel au fur et à mesure. En moyenne, il y a une nouvelle version disponible tous les jours.

Téléchargement du dépôt git de darktable

Maintenant que tout est bien installé, il faut aller chercher le code source de darktable sur Github. Dans mon cas, j’ai opté de télécharger le code dans ~/.darktable_master/. Vous pouvez choisir de les placer ailleurs ceci dit.

$ cd /home/nicolas/
$ git clone https://github.com/darktable-org/darktable.git .darktable_master/
$ cd .darktable_master/

Compilation de la version master

Pour initier la compilation voilà les commandes à faire :

$ git submodule init
$ git submodule update

En ouvrant le fichier build.sh présent dans le dossier téléchargé, on voit que la compilation va placer les fichiers du logiciel dans /opt/darktable/ par défaut. Ayant plusieurs versions dans /opt/ sur ma machine, j’ai décidé de reprendre la même notation que pour le code source pour éviter de me mélanger les pinceaux. L’option --prefix permet de personnaliser la destination de la compilation.

La compilation se fait donc par cette commande :

$ ./build.sh --prefix /opt/darktable_master/ --build-type Release

Selon votre machine, la compilation devrait durer plus ou moins longtemps, environ une minute. Une fois terminée, elle devrait vous proposer la commande suivante à taper :

# cmake --build "/home/nicolas/.darktable_master/build" --target install -- -j12

Notez que celle-ci se fait via le compte root (sauf si le préfixe d’installation passé en paramètre de build.sh est un préfixe correspondant à un dossier qui ne nécessite pas d’accès root).

Lancement de la version compilée

Désormais, vous avez la version compilée de darktable 3.1 (développement), pour la lancer il faut taper la commande suivante :

$ /opt/darktable_master/bin/darktable --configdir /home/nicolas/.config/darktable_master/

Attention Ici il est très important de bien définir un --configdir ici, et ce à chaque démarrage, sinon le logiciel utilisera par défaut le dossier ~/.config/darktable/ et possiblement remplacer la base de données d’une autre version déjà installée et tout casser, ce qui pourrait être problématique.

Pour plus de sécurité sur mon ordinateur et éviter tout problème, j’ai créé un lanceur spécifique dans KDE avec un logo différent qui lance automatiquement cette commande.

Installation d’une version stable (3.0.0 ici)

Il vous est parfaitement possible de compiler la dernière version stable de darktable et donc profiter des dernières évolutions immédiatement après publication sans risque.

La démarche est quasiment la même que pour la version de développement, à quelques différences près que je vais présenter ici.

Avant de compiler la version, choisissez des dossiers correspondant comme ce qui a été fait pour la version master, par exemple :

/home/nicolas/.darktable_stable/
/home/nicolas/.config/darktable_stable/
/opt/darktable_stable/

Évitez de donner des numéros de versions dans ces dossiers, ceux-ci conservant le même nom tout le temps ils ne correspondront rapidement plus aux versions qu’ils contiennent vraiment.

Compilation de la version

Le téléchargement se fait de la même façon que précédemment :

$ cd /home/nicolas/
$ git clone https://github.com/darktable-org/darktable.git .darktable_stable/ $ cd .darktable_stable/

Une fois dans le dossier du code source, il est possible de voir toutes les versions stables disponibles par la commande suivante :

$ git tag

release-2.0.0
release-2.0.1
release-2.0.2
release-2.0.3
release-2.0.4
release-2.0.5
release-2.0.6
release-2.0.7
release-2.0rc1
release-2.0rc2
release-2.0rc3
release-2.0rc4
release-2.1.0
release-2.2.0
release-2.2.0rc0
release-2.2.0rc1
release-2.2.0rc2
release-2.2.0rc3
release-2.2.1
release-2.2.2
release-2.2.3
release-2.2.4
release-2.2.5
release-2.3.0
release-2.4.0
release-2.4.0rc0
release-2.4.0rc1
release-2.4.0rc2
release-2.4.1
release-2.4.2
release-2.4.3
release-2.4.4
release-2.5.0
release-2.6.0
release-2.6.0rc0
release-2.6.0rc1
release-2.6.0rc2
release-2.6.1
release-2.6.2
release-2.6.3
release-2.7.0
release-3.0.0
release-3.0.0rc0
release-3.0.0rc1
release-3.0.0rc2
release-3.1.0
release0.4

Note : la liste étant très longue, j’ai retiré volontairement toutes les versions inférieures à la 2.0.0, celles-ci n’étant pas particulièrement utiles pour la quasi-totalité des gens.

Le choix de la dernière version stable à compiler se fait alors par la commande suivante :

$ git checkout release-3.0.0

La suite est la même que pour la version master, en veillant bien à vérifier les noms de dossiers :

$ git submodule init
$ git submodule update
$ ./build.sh --prefix /opt/darktable_stable/ --build-type Release
# cmake --build "/home/nicolas/.darktable_stable/build" --target install -- -j12

Mises à jour des versions compilées

Dans les deux cas de figure, la méthode à suivre pour mettre à jour une version compilée est la même, voilà les commandes pour la version master :

$ cd /home/nicolas/.darktable_master/
$ git pull
$ git submodule update
$ ./build.sh --prefix /opt/darktable_master/ --build-type Release
# cmake --build "/home/nicolas/.darktable_master/build" --target install -- -j12

Avant la compilation il peut être fortement recommandé de supprimer le dossier build/ et le dossier correspondant dans /opt/ (ici /opt/darktable_master/) pour être certain de partir sur une compilation fraiche.

Il suffit alors de relancer votre logiciel pour tourner sur la dernière version. 🙂

Il est possible qu’au lancement, darktable vous prévienne que la base de données a été mise à jour et vous propose de faire une sauvegarde de celle-ci avant de l’ouvrir. À vous de choisir, depuis que j’utilise la version master en production je sauvegarde mon dossier dans ~/.config/ au cas où, même si la plupart du temps cela se passe bien.

Activation de OpenCL pour darktable

Si votre ordinateur a une carte graphique Intel, vous pouvez profiter de OpenCL dans darktable pour améliorer considérablement la rapidité du traitement ou des exports de photos. Pour cela, il suffit d’installer le package NEO permettant de prendre en charge le GPU. Ce logiciel reste cependant compatible qu’à partir des générations 8 des cartes Intel.

Les commandes à taper pour Fedora sont les suivantes :

# dnf install dnf-plugins-core
# dnf copr enable jdanecki/intel-opencl
# dnf install intel-opencl

Et dans le cas d’une distribution Ubuntu :

# add-apt-repository ppa:intel-opencl/intel-opencl
# apt-get update
# apt-get install intel-opencl-icd

Une fois intel-opencl installé, il vous suffit de recompiler darktable pour que le support OpenCL soit intégré. Pour l’activer, rendez-vous dans les paramètres de darktable et dans l’onglet Fonctionnement pour cocher la case du support OpenCL.

Sources et remerciements

Pour plus de détails, je vous invite à voir les wikis de darktable sur sa compilation :

La documentation pour installer Neo est disponible via ce lien : https://github.com/intel/compute-runtime/blob/master/documentation/Neo_in_distributions.md

Merci aux développeurs pour votre travail formidable et votre aide sur Framateam pour m’avoir permis de compiler chez moi le logiciel et merci à Rawfiner pour la relecture et les quelques corrections.

 Si vous avez des remarques ou des questions, n’hésitez pas à en faire part en commentaire, je ne suis pas vraiment expert de Github, mais j’essayerai de faire de mon mieux pour répondre à vos questions. J’espère que des développeurs pourront me venir en aide en cas de problèmes trop techniques pour moi.

21 thoughts to “Travailler sur une version compilée de darktable”

  1. Bravo et merci Nicolas pour ce travail. Avec ces explications je pense que je vais sauter le pas et essayer moi aussi d’apporter mes retours d’utilisation aux développeurs (un grand merci à eux également pour leur travail).

  2. Merci pour cet article qui peut inciter à franchir le cap.
    À titre personnel je songe à compiler essentiellement pour une question d’optimisation des performances, notamment sur les traitements les plus lourds (débruitage, etc.).
    Question aux plus rodés : quel est le gain que l’on peut espérer avec une tour déjà efficace, avec une carte graphique dédiée mais qui reste modeste (Nvidia 1050), un i7 quadri-cœur et plein de ram ?

    1. Depuis plus 4 ans que je compile, je n’ai pas vu un gain transcendantal de temps d’exécution, peut-être sur les modules les plus gourmands après je n’ai jamais fait de mesure. Mais tu seras prêt pour le prochain module d’Aurélien qui s’annonce très gourmand.

      1. Je viens de faire un essai entre la version packagée de darktable (3.0.0) et celle compilée stable (3.0.0) pour voir s’il y avait une différence réelle. Sur une photo traitée avec le module de bruit de profil activé (un bon client de la carte graphique), et dans le cas d’un export en TIFF 16 bits non compressé sur une photo de 24 Mpx, voilà les mesures de temps calculées par darktable (pour info : il faut rajouter l’option `-d perf` lors du lancement en console du logiciel) :
        — version packagée sans GPU : pixel pipeline processing took 36,446 secs (373,554 CPU)
        — version packagée avec GPU : pixel pipeline processing took 31,386 secs (14,652 CPU)
        — version compilée sans GPU : pixel pipeline processing took 36,439 secs (388,159 CPU)
        — version compilée avec GPU : pixel pipeline processing took 30,326 secs (15,140 CPU)
        On peut voir que la différence n’est pas énorme mais est tout de même légèrement meilleure. Je n’ai ceci dit pas de carte graphique proprement dite, mais une intégrée à mon processeur. La même expérience pourrait être faite dans une configuration plus performante en termes de GPU.

        Affaire à suivre. 🙂

        1. Merci pour ton test, c’est top ! Le résultat me suffit pour décider de rester simple utilisateur 😉
          Je ne suis pas à la journée près vis-à-vis des nouvelles fonctionnalités, je préfère me concentrer sur les photos et la maîtrise du logiciel plutôt que sur la compilation pour gagner 2% de performance.

  3. Bonsoir à tous,
    Merci pour ce partage en espérant qu’il aidera le plus grand nombre à compiler la version stable et/ou master.
    Au delà d’une éventuelle différence de performance par rapport à la version packagée, personnellement l’avantage premier est que l’on profite de la correction des bugs et des améliorations au fur et à mesure des commits surtout pour la version stable qui ne sera pas re-packagée avant la publication de la 3.0.1.
    Petite remarque de fainéant: personnellement je lance l’installation en suivant de la compilation sur la même ligne de commande.
    Exemple pour la master: $ ./build.sh –sudo –prefix /opt/darktable-master –build-type Release –install
    Et pour la stable qui s’installera par défaut dans /opt/darktable: $ ./build.sh –sudo –build-type Release –install

    J’en profite pour remercier encore et encore le travail des développeurs et de toutes les personnes qui œuvre sur ce beau logiciel qu’est darktable.

    1. Bonsoir,
      Oui, c’est le plaisir de la version master de suivre tout ça, en faisant attention aux évolutions (personnellement je jette rapidement un oeil afin de voir les évolutions histoire de faire gaffe qu’une nouvelle compilation ne foute pas trop le bordel ; ça reste une version de développement).

      Je compile aussi avec une seule ligne, celle que tu présente. On en a d’ailleurs discuté avec Nicolas sur framateam, ce jour. Il n’y a pas une seule manière de faire.

      1. En effet, le --install est possible aussi. Dans ma configuration je ne peux pas vu que le /opt/ n’est pas accessible à mon compte utilisateur et je n’ai pas envie de lancer la compilation en root. Du coup je sépare les commandes.
        Sinon, en ce qui concerne les évolutions du logiciel, je regarde quand y’a beaucoup de modifications sur beaucoup de fichiers sur le git pull, si c’est le cas je me dis qu’il y a probablement un ajout d’un gros morceau et je sauvegarde tout dans le doute.

        1. Bonjour Nicolas,
          Avec l’installation associée à la compilation sur la même commande, la compilation se fait en environnement utilisateur exactement comme dans la commande de compilation que tu as présenté.
          Il n’y a que l’installation qui se fait en environnement root avec l’option –sudo car effectivement on en a besoin pour écrire dans le dossier /opt/
          Encore merci pour ton excellent article.

  4. Hello,
    Très utile,
    je suis passé de la 2.4.2 version de ma distrib Ubuntu à la version 3.0.0 en compilant et j’ai un peu galéré. Si on prend le “targz” il manque submodule , après utilisation de git submodule, j’ai résolu les pb de dépendances en interprétant les erreurs du build, mais c’est long et pas toujours très clair. Surpris de voir la compile dans /opt ? conflit avec ancienne version au niveauBDD …. version 3.1.0 erreur gcc…
    Cet article est le bienvenu et peut permettre des installations plus facile et de promouvoir le libre.
    cdlt

  5. Bonjour
    Cet article tombe juste à point. Je suis avec Linux Mint 19.3 et effectivement nous ne sommes pas encore à 3.0 dans cette distribution.
    Ce qui me fâche c’est qu’avec Window 10 c’est tellement simple et ils ont les nouvelles versions rapidement. J’aime bien Linux mais cette situation n’aide pas le libre

    Si possible il faudrait tenir cette procédure à jour et y aurait t il une façon de la simplifier au moins pour Ubuntu et Mint.
    Il y a aussi les versions flatpak et snapcraft et autres mais les ”updates” prennent aussi un certain temps à nous parvenir

    Donc merci pour cette super information
    Jocelyn

  6. Bonjour.
    Je me présente : Daniel Berenblit, 59 ans.
    En informatique, je connais bien Windows, mais j’ai voulu me mettre à l’environnement Linux pour plusieurs raisons que je détaillerai pas ici. Et je suis donc d’un niveau débutant en Linux.
    Je me suis installé Linux Mint 19.3.
    En photographie, j’ai quelques années d’argentique derrière moi, et je suis passé au numérique l’année dernière.
    J’ai un Nikon D750, avec des optiques Tamron.
    Je me suis mis à Darktable en version 2.6.2 sous Windows.
    Depuis quelques jours, j’ai voulu passer en 3.0.0 sur un autre PC sous Linux.
    Après quelques galères, notamment avec des PPA qui me ramenaient toujours sur pmjdebruijn, et qui me réinstallaient systématiquement une version 2.6.2, je me suis jeté à l’eau et j’ai suivi la documentation de Nicolas Tissot, ci-dessus.
    Déjà, un grand bravo à Nicolas pour la qualité de cette doc. C’est complet et très clair, même pour un débutant en Linux comme moi, et je m’en suis très bien sorti : j’ai compilé et installé la version 3.0.0 de Darktable.
    Deux ou trois petites questions quand même :

    – la dernière commande, cmake…, est avec le paramètre -j12 dans la doc, or moi, il me proposait le paramètre -j4. J’espère que cela n’a pas eu de mauvaise conséquence ?

    – De plus, dans mon Linux Mint, je programme Darktable ne semble pas être installé comme un autre programme, du style la suite LibreOffice. On ne le voit pas quand on clique sur le bouton Menu en bas à gauche. Cela m’a semblé normal, vu qu’on a compilé un programme et que l’on a à priori simplement « déposé » l’exécutable dans /opt/. Est-ce le cas ? N’est-il pas nécessaire de l’installer, comme quand on exécute un install.exe sous Windows par exemple ?

    Et enfin, une dernière question :

    – comme avec la version 2.6.2 de Darktable, sous Windows, mon Nikon D750 n’est pas reconnu lorsque je cherche à importer des photos depuis un appareil.
    Sous Windows, j’avais téléchargé et lancé ZADIG 2.4 puis j’ai connecté mon Nikon D750 en USB via son câble USB fourni avec. Là il a détecté mon boîtier NIKON DSC D750, et j’ai remplacé le driver WinUSB par celui que ZADIG a téléchargé. Ensuite, après reboot, j’ai connecté mon boîtier D750, j’ai lancé DarkTable, et le boîtier a enfin été reconnu.
    Comment faut-il procéder, si c’est possible, pour que ce boîtier soit reconnu ?
    Daniel
    PS : Encore un grand merci pour cette documentation.

    1. Bonjour Daniel.
      Merci pour ton retour. Pour reprendre tes quelques questions :
      — le -j12 ou -j4 correspond juste au nombre de cœur présent dans ton processeur pour compiler le logiciel : dans mon cas 12 et chez toi 4. Du coup rien de mal, il faut juste utiliser la commande qu’il te propose.
      — En effet, une fois compilé le logiciel n’est pas réellement intégré dans l’environnement graphique. Dans mon cas sur KDE j’ai créé un nouveau lanceur dans mon menu de logiciel. Selon ta configuration (quel environnement), il faut que tu regardes comment l’ajouter sur le tien. Un article sur ubuntu-fr.org devrait répondre à la majorité des situations je pense.
      — pour le boîtier non reconnu sur Linux c’est assez étonnant. J’ai le même boîtier dans mon cas et sur Fedora et cela ne m’a jamais posé de problème particulier. Si tu cliques sur « rechercher un appareil » dans l’onglet d’import il ne le trouve pas ? (quelques détails dans la doc à ce sujet) Côté Windows, je n’ai aucune idée de comment cela devrait se passer par contre, ni quel driver utiliser, désolé.
      J’espère avoir répondu au mieux à tes questions.

      Nicolas

      1. Merci beaucoup pour ces réponses.
        Je vais creuser un peu pour le boîtier non reconnu.
        J’avais fini par trouver pour Windows, je devrais y arriver pour Linux.
        Bonne journée.
        Daniel

        1. – Sur Ubuntu, tu as le programme “alacarte” pour ajuster les menus/applications affichées et créer un lanceur. Un programme simple et efficace qui s’affichera en menu sous le nom de “Menu principal”.
          – Pour le problème d’import et reconnaissance de ton boîtier, c’est lié à la librairie Gphoto mais déjà il faut voir si ton boîtier est bien reconnu sur Linux. Pour qu’il soit reconnu, il faut bien allumer le boîtier et sélection l’option USB et/ou PPTP selon la caméra. Si reconnu par le système (un lecteur externe ouvert), darktable doit normalement le reconnaître si reconnu par la librairie Gphoto (la version que tu as). Pour aller plus loin, il y a déjà eu des discussions à ce sujet sur le forum. Tu y trouveras des réponses complémentaires et ensuite, si nécessaire le forum est plus adapté aux échanges que les commentaires.

  7. Bonjour,

    Petite question, pour éviter les écritures intempestives sur mon SSD, ne serait-il pas préférable d’utiliser une partition /tmp (/tmpfs) en RAM pour y placer le build de darktable ?
    Il faut donc dans ce cas modifier le dossier de clonage du build de darktable ?
    git clone https://github.com/darktable-org/darktable.git .darktable_master/
    Je ne sais comment la modifier cette ligne ?

    Cordialement.

  8. Bonjour
    Pas évident cette compilation pour moi ………….
    Question: Ou trouve t on les dépôts ”repository” requis avant l’installation de darktable?

    Est ce que ces dépôts sont en relation avec la distribution de Linux que l’on utilise?

    Si j’utilise Mint 20 ou 19? Y a t il une différence?

    Un gros merci à l’avance
    Jocelyn

    1. Bonjour,

      Normalement, les dépendances sont disponibles sur les dépôts de la distribution. Donc il suffit de lancer la commande indiquée dans la rubrique “Installation des dépendances” de l’article.

      Si problème persistant, le forum est à privilégier plutôt que les commentaires pour être aidé.

Répondre à Nicolas Tissot Annuler la réponse

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.