déplacement de dossier

Bonjour,

Débutant sur darktable, je fais des essais.
Certains sont positifs et d’autres ne marchent pas.

Voici mon problème.
J’ai un dossier contenant des photos, j’importe ces photos et fais des modifications, notamment des clonages de photos.

Par la suite je déplace mon dossier. En fait je veux tester si des photos traitées sur un PC peuvent être déplacées sur un autre PC et retrouver les modifications faites. Dans Darktable, la pellicule des photos du dossier est barrée. Je la supprime et importe à nouveau les photos de mon dossier déplacé.
Dans la nouvelle pellicule je retrouve tout sauf les photos clonées.
Que dois je faire pour tout retrouver à l’identique?
Je suis sous W10.

Merci pour votre aide

Bonjour. Il faut aussi déplacer la base de données de DT d’un PC sur l’autre dans ce cas. Tu dois pouvoir trouver des sujets qui en parlent sur ce forum…

voir ma réponse dans un autre sujet, tu dois importer le dossier et tu récupères les photos clonées.

C’est bien ce que je fais.
J’importe le dossier, mais je ne vois pas les miniatures des photos clonées.

Aucune idée alors!

Le problème a été confirmé par un autre utilisateur sous W10.
Comment faut il faire pour le faire remonter aux développeurs?
Merci

Bonjour, je confirme le problème sous Windows 10. Lorsqu’on importe un répertoire contenant des xmp créés avec la fonction clone, ceux-ci ne sont pas importer. Uniquement le xmp de base. J’ai fait le test en important un répertoire et une image.

Le clonage crée un xmp indicé 01, mais ne clone pas l’image. je viens de refaire un essai, le nouveau dossier importé contient l’image, le xmp origine de l’image, le xmp cloné qui peut contenir des traitements complémentaires. Par contre on ne peut ouvrir que l’image initiale avec son xmp origine. Pour voir les modification du xmp cloné, il faut renommer l’image originale ou la dupliquée en lui donnant le même nom que le xmp cloné. C’est sur c’est pas bien clean tout ça. Bug je ne sais pas puisque l’image n’est pas clonée.

Oui, c’est bien ce qui est décrit dans la doc. :smiley:

Ce que j’ai constaté c’est qu’après avoir créé un clone, puis l’avoir enlevé, le xxx_01.XMP reste sur le DD. En créant un nouveau clone, un xxx_02.XMP est créé.

Je me dis qu’il doit bien y avoir une info dans la BD DT pour associer le ou les clones actifs (donc les _NN.XMP) à la photo elle-même…

Si on fait des sauvegardes de ses répertoires et qu’on ne puisse pas restaurer les images clonées c’est quand même étonnant.
Il doit bien y avoir une façon de faire qui m’échappe.
Il semblerait que ce problème soit spécifique à W10. Personne d’autre en parle.

En faisant une recherche rapide, on peut voir que la colonne version de la table images de la base library.db correspond au numéro de version/de clone de la photo.

Par exemple, j’ai cloné et enlevé à deux reprises une photo particulière, puis re-cloné une 3ème fois la photo. J’ai 4 XMP pour cette photo dans le dossier, mais seulement deux versions de la même photo, l’originale et un clone.

Quand je requête la table image de la base library.db pour cette photo par son nom (FileName), je liste deux entrées, l’une avec la colonne version à 0 (originale), une autre avec version à 3 (dernier clone).

C’est donc a priori bien dans la base qu’est l’info comme je le mentionnais dans ma première réponse à la question. :stuck_out_tongue:

Sur ma machine Linux, library.db est dans .config/darktable, pour Windows je ne sais pas mais voir du côté d’AppData... Ça a déjà été évoqué quelque part ici.

Ensuite, si on s’en tient à la documentation utilisateur, on voit qu’on peut lancer darktable avec l’option --library

On peut donc imaginer mettre library.db ailleurs, par exemple à la racine des dossiers où sont stockées les photos, ou tout autre endroit facilement « sauvegardable » et lancer darktable avec cette option.

Sauf que je crois que ça marche pas (encore) sous Windows…

Il semblerait que ce problème soit spécifique à W10. Personne d’autre en parle.

Oui c’est spécifique à W10. J’ai déjà dit deux fois ici que cela marche parfaitement bien sous GNU/Linux, mais visiblement on a beaucoup de messages et plus de mal à tout lire :slight_smile:
[hr]

C’est donc a priori bien dans la base qu’est l’info comme je le mentionnais dans ma première réponse à la question.

Non, car ça marche sous GNU/Linux comme déjà dit plusieurs fois :frowning:

Si tu importes un répertoire avec:

xxx.NEF
xxx.NEF.xmp
xxx_01.NEF.xmp
xxx_02.NEF.xmp

Tu obtiens 3 images dans la collection.
[hr]
Pour être certain j’ai refait le test, ça fonctionne.

===>>>>> c’est un problème W10
[hr]
Avec toutes les manips discutées j’ai bien peur que certains se retrouvent perdus :frowning: désolé mais il y a beaucoup de fausses informations ici. Je préfère laisser tomber ce thread.

Non non, tu as bien raison @Pascal, ça marche pas (encore) sur Windows comme tu le décris, alors que sur Linux oui.
(Et en passant, je décèle un bug puisqu’un clone enlevé réapparaît au nouvel import, puisqu’ à l’enlèvement sur la source le fichier _NN.XMP n’est pas supprimé du DD et qu’il est re-importé sur la cible…)

Je viens de faire un autre test sur Linux, pour voir quand même par rapport à ce que j’ai trouvé dans library.db : recopier le dossier des photos et des XMP sur une arborescence strictement identique sur une autre machine ET le dossier darktable dans .config.

Et là pour la pellicule correspondante dans dt sur la nouvelle machine, j’ai le nombre de clones qu’il faut, c’est à dire que le XMP « résiduel » n’est pas pris en compte (et il est bien dans le dossier).

Mais bon, que des têtes de mort…
Donc c’est pas vraiment une solution alternative pour les windowsiens. :confused:
La double peine quoi. (pas la tête !!!)