Forum darktable FR
Problème avec les xmp - Version imprimable

+- Forum darktable FR (https://forums.darktable.fr)
+-- Forum : Utilisation de darktable (https://forums.darktable.fr/forumdisplay.php?fid=97)
+--- Forum : Module Table Lumineuse (https://forums.darktable.fr/forumdisplay.php?fid=74)
+--- Sujet : Problème avec les xmp (/showthread.php?tid=1556)

Pages : 1 2

Problème avec les xmp - tolemak - 02-01-17

Bonjour,

Je rencontre un problème avec DT 2.2.1 installé sur une Mint 18 depuis le ppa de pmjdebruijn.

Les fichiers xmp ne sont pas créés automatiquement et un clic sur le bouton "sauver en xmp" ne fait rien. L'option de création automatique des xmp est bien activée, j'ai essayé de décocher et recocher, pas mieux. Je n'ai rien vu dans le darktablerc qui ressemblerait à cette option.

Le bouton "charger" ouvre bien la boite de dialogue de chargement.

Si l'un de vous a une idée, je suis preneur. Merci d'avance.

Problème avec les xmp - jpverrue - 02-01-17

Peut être un problème de droits d'accès en écriture sur le répertoire ?

Problème avec les xmp - tolemak - 02-01-17

C'est effectivement le premier truc auquel j'avais pensé, mais même pas.

Du coup je viens de faire des tests :
  • pour les dossiers que je n'avais jamais importé, les xmp se crééent à l'importation, si je les supprime je peux les recréer avec le bouton "sauver en xmp"
  • pour les dossiers déjà importés et présents dans la bibliothèque, les xmp n'ont pas a été créés (sauf pour 1 dossier) et pas moyen de recréer les xmp à partir du bouton.
Donc la création automatique fonctionne pour les nouveaux dossiers. A part le bouton "sauver en xmp", existe il un autre moyen d'extraire les données de la db et de les écrire dans un xmp ?

Problème avec les xmp - tolemak - 02-01-17

Pour préciser, parce que c'est un peu confus -y compris pour moi.

Les dossiers avec les xmp présents ont été importés avec la version de DT qui était packagée dans Mint 17.3. C'était surtout pour faire des tests sur quelques lots de photos. J'ai décidé de basculer complétement vers DT aux alentours de Noël (merci la news sur linuxfr), donc upgrade vers Mint 18, suppression du .config/darktable pour repartir de zéro et installation de la version de DT packagée dans le ppa de pmjdebruijn, refonte de ma façon d'importer / trier / classer / backuper... Trop de modifs en trop peu de temps pour vraiment savoir ce qu'il s'est passé.

J'ai l'impression que le problème de non création des xmp s'est posé avec la version 2.2.0 qui a très vite été mise à jour en 2.2.1. Entre deux j'ai commencé à traiter sérieusement un certain nombre de photos, et en cas de problème ça m’embêterait de perdre l'historique. Rien d'insurmontable, à peu près une cinquantaine de photos, mais si un moyen existe, je suis preneur !

Surtout avant de continuer plus avant je veux m'assurer que le problème est réglé, donc si vous avez des idées de tests complémentaires à effectuer.

 

Problème avec les xmp - jpverrue - 03-01-17

À tout hasard, est-ce que l'option "écrire un fichier xmp redondant pour chaque image" (préférences --> onglet fonctionnement) est bien cochée ?

RE: Problème avec les xmp - tolemak - 08-01-17

(03-01-17, 11:00)jpverrue a écrit : À tout hasard, est-ce que l'option "écrire un fichier xmp redondant pour chaque image" (préférences --> onglet fonctionnement) est bien cochée ?

L'option est belle et bien cochée, ce que je ne comprends vraiment pas c'est que cela fonctionne pour les dossiers jamais encore importés, mais pour ceux que j'ai déjà importé.

RE: Problème avec les xmp - jpverrue - 09-01-17

Je n'ai pas vraiment d'idée... Je cherche un peu au hasard : est-ce que tu utilises les copies locales ?
Extrait du manuel : 
Citation :Une copie locale est identifiée sur la vue table lumi-
neuse par une marque blanche à la droite de la minia-
ture. De plus toutes les copies locales possèdent le
mot-clé darktable|local-copy pour pouvoir être sélec-
tionnées rapidement.

Si c'est le cas, les copies locales manipulent les fichiers XMP ; c'est peut être une piste. Voir le manuel § 2.2.9
... Et aussi § 2.3.6.1, resync copie locale

RE: Problème avec les xmp - tolemak - 18-01-17

(09-01-17, 11:40)jpverrue a écrit : Je n'ai pas vraiment d'idée... Je cherche un peu au hasard : est-ce que tu utilises les copies locales ?
Extrait du manuel : 
Citation :Une copie locale est identifiée sur la vue table lumi-
neuse par une marque blanche à la droite de la minia-
ture. De plus toutes les copies locales possèdent le
mot-clé darktable|local-copy pour pouvoir être sélec-
tionnées rapidement.

Si c'est le cas, les copies locales manipulent les fichiers XMP ; c'est peut être une piste. Voir le manuel § 2.2.9
... Et aussi § 2.3.6.1, resync copie locale

Désolé pour la réponse tardive, mais non je n'utilise pas les copies locales.

RE: Problème avec les xmp - pascal - 19-01-17

Je viens de tester avec la version "master" et je n'ai pas ce problème. J'ai ouvert une image non modifiée depuis 2014, j'ai édité l'image et après avoir quitté darkroom mon .xmp est mis à jours.

RE: Problème avec les xmp - jpverrue - 19-01-17

Alors là... vraiment aucune idée :-(

Un test à faire : exporter en jpeg (peu importe la taille et la qualité du jpeg) et vérifier que le xmp est bien embarqué dans le jpeg :

Code :
exiftool -XMP:\* <fichier jpeg>
Tu dois récupérer quelque chose qui ressemble à ça :
Code :
XMP Toolkit                     : XMP Core 4.4.0-Exiv2
Rating                          : 0
Derived From                    : IMG_20161227_154641.dng
Xmp version                     : 2
Raw params                      : 0
Auto presets applied            : 1
History end                     : 9
Creator                         : JP Verrue <contact@jpverrue.fr>
Publisher                       : JP Verrue <contact@jpverrue.fr>
Rights                          : Tous droits réservés © 2016 <contact@jpverrue.fr>
Mask id                         :
Mask type                       :
Mask name                       :
Mask version                    :
Mask                            :
Mask nb                         :
Mask src                        :
History Operation               : denoiseprofile
History Enabled                 : 1
History Modversion              : 3
History Params                  : 0000803f9a99993e17b7d13817b7d13817b7d13800000000000000000000000001000000
History Multi name              :
History Multi priority          : 1
History Blendop version         : 7
History Blendop params          : 010000001d0000000000c842000000000000000000000000000000000000000000000000000000000000000000000000000000000000803f0000803f00000000000000000000803f0000803f00000000000000000000803f0000803f00000000000000000000803f0000803f00000000000000000000803f0000803f00000000000000000000803f0000803f00000000000000000000803f0000803f00000000000000000000803f0000803f00000000000000000000803f0000803f00000000000000000000803f0000803f00000000000000000000803f0000803f00000000000000000000803f0000803f00000000000000000000803f0000803f00000000000000000000803f0000803f00000000000000000000803f0000803f00000000000000000000803f0000803f
Si c'est le cas, c'est que les données de développement sont sauvées dans le jpeg. Donc, tu peux sans problème enlever les photos de la BdD (module "images sélectionnées->enlever. Attention ! pas poubelle ;-))

Ensuite tu peux tenter de réimporter les photos (fais un A/M de darktable avant pour forcer l'écriture et la fermeture/ouverture de la BdD). Ensuite tu peux faire un test d'enregistrement d'un XMP et si tout va bien tu peux recharger les informations de traitement à partir des fichiers jpeg.

J'ai pas mieux à te proposer. C'est juste du bricolage pour sauver les meubles, mais ça ne solutionne pas le bug : on n'a pas trouvé la cause.