J’utilise Darktable sur plusieurs PC dont un sous Linux et 2 autres sous Windows. Je travaille sur les mêmes images que je synchronise via mon NAS et Synology Cloud Station. J’utilise la version 2.4.4 sur mes 3 machines.
J’ai travaillé sous linux en notant et en retouchant mes photos. Je retrouve bien ce travail là quand je vais sous Windows et que je réimporte le dossier. Par contre, j’avais cloné des images pour les mettre en noir et blanc (et avoir les 2 versions en même temps) mais sous Windows je ne retrouve pas ces clones et je vois uniquement les originaux (bien notés et retouchés).
Comment cela se fait-il ?
Suis-je obligé de faire une importation à chaque fois quand j’ai travaillé sur un autre PC ? La fonction « resync copie locale » permettrait-elle d’éviter cela ?
De mémoire, ce que j’ai constaté à propos des clones : un fichier blabla_NN.xmp (NN = 01, puis 02, etc…) est créé à chaque clonage. Ils contiennent les traitements réalisés sur les clones correspondants. OK.
Mais c’est la base library.db qui indique quel(s) clone(s) est ou sont « actif(s) ».
Si ta base n’est pas partagée, il te faut (re)importer sur une/les autres machines les dossiers sur lesquels tu as créé des clones.
On s’en rend compte en créant sur une machine mettons 2 clones d’un original, disons aaa_01 et aaa_02. Puis en en supprimant un dans la table lumineuse, par exemple aaa_01. Et qu’y a-t-il toujours dans le dossier sur disque ?
Je pensais donc partager et synchroniser le fichier library.db entre mes différents PC mais ce fichier contient une base de données avec des chemins absolus vers les fichiers. Comment faire pour partager ce fichier entre Windows et Linux si les chemins sont différents (C:... et /home/…) ?
Entre le même OS, je devrais pouvoir résoudre ça avec des liens symboliques mais entre 2 systèmes d’exploitation différents, je ne vois pas
Merci Aurélien pour ce topic que je n’avais pas trouvé. Peut-être serait-il intéressant de rajouter ces explications dans la FAQ ?
Pour mon problème, je n’avais pas l’option de rafraîchissement des XMP au démarrage du logiciel mais le fait d’utiliser une copie locale va-t-il vraiment me permettre de retrouver les clones ? J’ai du mal à voir pour ça marcherait et pas avec une synchronisation complète des RAW + XMP en local avec Synology Cloud Station/Dropbox/Google Drive… Parce qu’au final, les fichiers XMP se retrouvent sur tous les ordinateurs donc comment darktable détecte les clones créés sur un autre ordinateur ?
Oui je connais le système de versioning mais j’ai un peu de mal avec mon cas puisque mes fichiers RAW + XMP sont synchronisés entre les différents PC. J’ai activé l’option de vérification des fichiers XMP au démarrage et maintenant il me demande ce qu’il doit faire des fichiers modifiés sur une autre machine (j’accepte les modifications du fichier XMP). Suis-je quand même obligé de passer par une copie locale + resynchronisation copie locale dans ce cas ?
Tes fichiers ne sont pas synchronisés entre différents PC, ils sont synchronisés entre les PC (hôtes) et le stockage centralisé distant (serveur, qui peut être un simple disque externe, un NAS, un espace de cloud…).
Le schéma est le suivant :
Sur poste A :
au démarrage du logiciel, vérifie la version du XMP serveur des fichiers dans la BDD locale.
compare avec la version hôte
a) si versions différentes, demande dans quelle direction synchroniser
b) sinon, passer à 3)
Si ajout de nouvelles photos, utiliser le serveur comme répertoire de base
télécharger une copie locale des photos à retoucher
retoucher (depuis la copie locale, mais c’est transparent)
resynchroniser la copie locale vers le serveur à la fin de la retouche.
Sur poste B:
au démarrage du logiciel, vérifie la version du XMP serveur des fichiers dans la BDD locale.
compare avec la version hôte
a) si versions différentes, demande dans quelle direction synchroniser
b) sinon, passer à 3)
Si réutilisation des photos importées depuis A, réimporter le dossier/la pellicule dans la base de données locale de B (c’est la partie pénible).
télécharger une copie locale des photos à retoucher
retoucher (depuis la copie locale, mais c’est transparent)
resynchroniser la copie locale vers le serveur à la fin de la retouche.
Synchroniser entre les PC en court-circuitant le serveur me paraît tendu :
darktable ne sait pas le faire, ce qui suppose passer par une synchronisation bidirectionnelle par un outil externe… qui ne sait pas comment dt est structuré. Donc il copie à l’aveugle la version la plus récente sans vérifier la compatibilité des modifications (l’équivalent d’un diff sous git). Donc à la fin c’est la surprise du chef sur ce que tu vas trouver, surtout si tu fais des retouches à moitié sur un ordi, puis rouvre la photo sur un autre… Comment on gère les versions en conflit ?
ça suppose d’avoir autant de copies des images que de postes… à voir si c’est rationnel.
faire transiter des RAW sur le réseau en permanence (sans backup) augmente le risque de corruptions de données. Moi j’ai des RAW de 2009 illisibles aujourd’hui, après 3 changements de disque dur, à cause des corruptions. Pour cette raison, une version maîtresse versionnée/sauvegardée qu’on ne touche pas me semble plus sécuritaire à long terme.
L’avantage de la copie locale est que l’étape de lecture et l’étape d’écriture sur le serveur sont différées : en cas de corruption au passage dans le réseau, tu peux récupérer un version intègre dans le dernier poste utilisé. Sans copie locale, tu lis/écris en temps réel à travers le réseau. En cas de souci réseau, darktable ne vérifie pas l’intégrité des fichiers transmis et ne les sauvegarde pas.
Les RAW serveur sont en lecture seule. La resynchronisation d’une copie locale devient alors l’équivalent d’un commit push sur le XMP. Ça demande plus de vérification humaines, mais c’est moins de pleurs en cas de pépin.
Je pense qu’il n’y a pas moyen de jouer au plus fin avec dt en faisant de la sychronisation automatique externe, il faudrait l’introduire en interne dans dt avec des diffs sur les entrées XMP pour valider les modules au cas par cas sur conflit de versions, et un versionnage locale et distant. sinon, on fait le même genre d’horreur que dropbox où tout est synchronisé de façon bidirectionnelle, et il faut appeler tes collaborateurs pour leur dire de ne pas éditer les fichiers partagés pendant que tu bosses dessus.
Je viens d’essayer le workflow que tu préconisais en enlevant la synchronisation avec Synology Cloud Station. Sur l’un de mes PC, je suis sous Ubuntu et j’accède à mon NAS via un partage Webdav avec davfs2 en passant par internet. Mais le partage webdav semble être vraiment lent et l’importation des fichiers prend énormément de temps (plus de 20 min pour 240 fichiers). Je vais essayer de voir comment améliorer ça.
Edit : je viens d’essayer en FTP (il faudra que je passe en SFTP après) mais ça semble déjà plus rapide que Webdav, est-ce la meilleure solution pour accéder au fichiers de mon NAS en WAN ?
WebDAV, Samba, FTP… la meilleure façon, c’est celle qui marche sFTP n’apportera pas grand chose si tu es sur ton réseau domestique.
Ton WebDAV lent, il passe par le réseau local (IP du style 192.168.x.X) ou il sort par internet (genre en passant par un DNS) ? Il n’y a pas de raison pour que ça soit plus lent qu’un autre protocole, c’est la vitesse du réseau qui limite. À moins que la lib davfs2 soit bugguée.
Sur mon réseau local, j’utilise Samba sans aucun problème de performances donc la question du protocole ne se pose pas vraiment.
Par contre en passant par internet (si je travaille à l’extérieur de mon domicile), j’ai des lenteurs avec davfs2 parce qu’il y avait déjà une différence de vitesse en parcourant un dossier monté avec davfs2 et via l’option « Connexion à un serveur » d’Ubuntu.
Je viens d’essayer en SFTP et cela a pris environ 6 min pour importer 3000 fichiers dans la bibliothèque et 4 min pour copier localement 120 images, c’est déjà mieux
Après quelques essais, je trouve le montage du NAS en disque réseau trop contraignant :
performances assez mauvaises, il faut pas mal de temps pour importer, afficher les miniatures et copier les raw localement
les fichiers ne sont pas en local donc pas très pratique pour les ouvrir dans gimp par exemple (j’ai aussi des JPEG)
cela ne résout pas mon problème initial de clones
En relisant tes explications, j’ai l’impression d’avoir mal formulé ma façon de fonctionner avec le NAS. J’indiquais utiliser Synology Cloud Station pour synchroniser mes fichiers ce qui implique que tous les fichiers passent par le NAS. Le partage de fichiers reste donc centralisé (comme Git/SVN) mais j’ai les copies des fichiers sur chacun de mes PC.
Ceci étant, mon problème de clones reste présent et est indépendant de la méthode de synchronisation ou l’utilisation de copies locales. Pour preuve, si tu crées des clones manuellement en ajoutant des fichiers XXX_01.xmp, XXX_02.xmp à la main avec le contenu du fichier xmp original, darktable ne les détecte pas (même avec l’option de relecture des xmp au démarrage), ce qui est normal puisque ce sont des fichiers séparés. Il n’y a donc que la base de données qui pourrait être au courant d’un quelconque clone et le fait d’utiliser des copies locales ne change pas le problème.
Et comme partager une base de données est n’est pas envisageable (problèmes de corruption et différences entre les systèmes d’exploitation), je ne vois pas trop comment darktable peut détecter des clones créés sur un autre PC
Là je sais pas trop quoi te dire. Le processus de travail avec les copies locales marche très bien quand tu passes par un disque dur externe et que tu veux embarquer des photos à retoucher en déplacement sur ton portable. C’est surtout pour ça que ça avait été pensé.
Je sais que Pascal Obry utilise un NAS pour ses photos, il faudrait voir comment il se débrouille.
Sinon, investiguer sur les causes de la lenteur des accès au NAS… Ce n’est pas normal que ça soit si lent en réseau local.
Voici le test que j’ai fait en utilisant le NAS en disque réseau et les copies locales mais où le problème de clone est toujours présent :
PC A :
monter le NAS comme disque réseau
lancer darktable et importer un dossier du NAS contenant un fichier RAW
PC B :
monter le NAS comme disque réseau
lancer darktable et importer le dossier du NAS
fermer darktable
PC A :
faire une copie locale du RAW
cloner l’image
modifier l’image
modifier le clone
resynchroniser les copies locales des 2 images
PC B :
lancer darktable
accepter les changements du fichier XMP
=> le fichier RAW est bien présent avec les modifications effectuées mais le clone n’est pas là
=> même en réimportant le dossier du NAS, le clone n’est pas affiché dans darktable
Sur un 3ème ordinateur, j’ai essayé d’importer le dossier pour la première fois et le fichier RAW et son clone sont bien affichés dans darktable.
Pour ces tests, il n’y avait aucune configuration de darktable (dossiers .config/darktable ou AppData/Local/darktable supprimés) et l’option de relecture des XMP était bien activée.
Il y a donc bien un problème au niveau des images clonées sur d’autres machines avec la base de données de darktable qui n’arrive pas à détecter de nouveaux clones. Le seul cas où le clone est bien détecté c’est avec une nouvelle bdd et un import du dossier.
Petite rectification : en important de nouveau un dossier, les clones créés sont bien détectés mais si l’on supprime un clone sur le PC A, le PC B va toujours garder le clone dans sa bibliothèque même si le fichier XMP n’existe plus. Le plus drôle c’est qu’en faisant une copie locale et une resynchronisation de la copie locale, il va recréer le fichier XMP
sFTP n’apportera pas grand chose si tu es sur ton réseau domestique.