Image clonées et synchronisation

[skurty]

Hello à tous,

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 ?

Merci

[manu]

Bonjour,

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 ?

aaa.xmp, aaa_001.xmp et aaa_002.xmp

[skurty]

Merci manu pour ces explications.

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

[manu]

Un petit requêtage sqlite entre les fichiers .db ? Je vois pas sinon.

[aurelienpierre]

merci d'utiliser les moteurs de recherche avant de poser la même question que celle à laquelle on a déjà répondu la semaine dernière : https://darktable.fr/forum/showthread.php?tid=2622

[skurty]

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 ?

[aurelienpierre]

Es-tu familier avec la logique de Git ou SVN ? Si oui, ça fonctionne dans le même esprit. Sinon, je vais détailler.

[jpg54]

Tu peux détailler, Aurélien, je pense que ça peut servir et peut faire une FAQ ?

[skurty]

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 ?

[aurelienpierre]

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 :
1. au démarrage du logiciel, vérifie la version du XMP serveur des fichiers dans la BDD locale.
2. compare avec la version hôte
a) si versions différentes, demande dans quelle direction synchroniser
b) sinon, passer à 3)
3. Si ajout de nouvelles photos, utiliser le serveur comme répertoire de base
4. télécharger une copie locale des photos à retoucher
5. retoucher (depuis la copie locale, mais c'est transparent)
6. resynchroniser la copie locale vers le serveur à la fin de la retouche.

Sur poste B:
1. au démarrage du logiciel, vérifie la version du XMP serveur des fichiers dans la BDD locale.
2. compare avec la version hôte
a) si versions différentes, demande dans quelle direction synchroniser
b) sinon, passer à 3)
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).
4. télécharger une copie locale des photos à retoucher
5. retoucher (depuis la copie locale, mais c'est transparent)
6. 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 :
1. 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 ?
2. ça suppose d'avoir autant de copies des images que de postes… à voir si c'est rationnel.
3. 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.