Métadonnées et mise(s) à jour

Démarré par Bélisaire, Décembre 28, 2019, 12:08:01

« précédent - suivant »
Imprimer
En bas Pages 1 2 3 Toutes
Actions de l'utilisateur

Nikojorj

#25
Janvier 04, 2020, 13:27:33
Suivant ce que tu as dans l'historique (opérations plus ou moins complexes), ça peut me sembler cohérent?

Samoreen

#26
Janvier 04, 2020, 13:36:56
Citation de: Bélisaire le Janvier 04, 2020, 11:21:11
L'historique disparaît mais l'impossibilité de mettre à jour subsiste.

Est-ce que le problème persiste si la mise à jour des XMP est en mode automatique ?
Patrick

Bélisaire

#27
Janvier 04, 2020, 14:43:46
Citation de: Samoreen le Janvier 04, 2020, 13:36:56
Est-ce que le problème persiste si la mise à jour des XMP est en mode automatique ?

Ah ça, c'est bien vu. Je suis passé en mode automatique et les trois fichiers de la même image (arw + xmp + historique; dng; arw + xmp (renommés)) se sont mis à jour. Merci.

Lightroom n'aimerait pas qu'on lui brûle la politesse ?

ChatOuille

#28
Janvier 04, 2020, 18:30:18
Cette discussion est très intéressante et je la suis depuis le début. Les conclusions sont encore plus intéressantes. J'aime bien les gens qui ont l'esprit de recherche. Je vais examiner cela de près car mon LR se trouve sur un autre OS. Normalement je n'ai jamais remarqué des photos éternellement récalcitrantes, mais uniquement au départ et finalement elles cèdent. C'est peut-être lié à la façon de travailler de chacun. Je vais créer une collection des photos avec les métadonnées non à jour (je ne savais même pas que cette possibilité existait). Ce que je retiens de votre recherche est :
1) L'influence de l'historique.
2) Mise à jour des XMP automatique.

Bélisaire

#29
Janvier 04, 2020, 18:41:08
Tiens-nous au courant.
Ce n'est pas tant l'historique que l'évolution de l'image au gré des modifications apportées; la même image, sans historique (avec historique effacé), refusait toujours de se mettre à jour manuellement. Maintenant, ce qui est valable pour moi... ::)

Samoreen

#30
Janvier 04, 2020, 18:48:15
Citation de: Bélisaire le Janvier 04, 2020, 14:43:46Je suis passé en mode automatique et les trois fichiers de la même image (arw + xmp + historique; dng; arw + xmp (renommés)) se sont mis à jour. Merci.

Pas de quoi. C'est intéressant, ça. Avec l'option automatique, la mise à jour se fait à un moment choisi par LR, quand il n'a rien d'autre de plus pressé à faire. En manuel, il y a peut-être des moments où la ressource XMP est mobilisée pour une raison à déterminer et empêche une réouverture du fichier pour écriture. À creuser.
Patrick

tkosak

#31
Janvier 04, 2020, 19:16:25
Citation de: Samoreen le Janvier 04, 2020, 18:48:15
Pas de quoi. C'est intéressant, ça. Avec l'option automatique, la mise à jour se fait à un moment choisi par LR, quand il n'a rien d'autre de plus pressé à faire. En manuel, il y a peut-être des moments où la ressource XMP est mobilisée pour une raison à déterminer et empêche une réouverture du fichier pour écriture. À creuser.
J'ai un contrexemple... Mon LR 6.10 est sous ouindoouz 10. J'ai déplacé tous mes fichiers vers un autre disque (pas mal d'heures de copie!...)et depuis j'ai une épidémie de conflits en tous genres (j'ai repéré 3 types différents, ou peut-être 4?) Pour certaines images le conflit disparait au bout de plusieurs synchronisations forcées (au moins temporairement "longtemps") et pour les autres ça revient. J'ai configuré LR pour écriture automatique depuis quelques années... Pas encore constaté que LR fasse sa mise à jour automatique, pourtant je ne le sollicite pas beaucoup, ces jours derniers.

ChatOuille

#32
Janvier 04, 2020, 20:00:30
Ce débat est tellement passionnant que je n'ai pas pu m'empêcher de regarder tout cela en détail. J'ai ouvert le catalogue complet (ce que je fais rarement), j'ai filtré et j'ai trouvé quelques 50 conflits. 2x rien car j'ai presque 58000 photos avec les métadonnées à jour. Je les ai sélectionnées par parties (par précaution) et elles ont toutes disparues sur-le-champ. Mais attention : LR continue à écrire et il fait cela en silence : pas de barre de progression ! Cette écriture a duré quelques longues minutes. Dès lors, si on veut arrêter LR, apparaît le box que je montre. En théorie, si on arrête, l'écriture continue dès qu'on démarre à nouveau, mais en connaissant la bête, je préfère laisser terminer le boulot avant de fermer.
Chez moi l'écriture automatique des XMP est activée. Je préfère aussi avoir le contrôle sur tout, mais ce n'est pas grave de laisser synchroniser les XMP en continu. D'après vos conclusions, il serait mieux de laisser cette option activée. En tout cas, depuis des années j'utilise LR et je n'avais jamais inspecté le catalogue d'une façon exhaustive et pourtant les erreurs étaient minimales.

A coté de ces conflits, j'ai trouvé quelques petites bricoles du genre Has been changed, Unknown, Changed on disk. Je ne m'y suis pas attaché car il s'agissait de photos disparues, des vidéos, et de photos composées, comme des panos.

En tout cas merci car on a appris quelque chose.

Nikojorj

#33
Janvier 04, 2020, 20:42:19
C'est exactement cette boite de dialogue à laquelle je faisais allusion :
Citation de: Nikojorj le Janvier 01, 2020, 23:52:47
Sans utiliser le badge "métadonnées à jour" affiché ni la collection associée, il y a peut-être un autre symptôme : à la fermeture de LR, un message me prévient souvent que LR n'a pas fini d'écrire des métadonnées, alors que je n'ai pas de telle opération en cours.

J'ai l'écriture automatique des XMP mais je la rencontre assez souvent.

Samoreen

#34
Janvier 04, 2020, 22:48:46
Il est normal que le problème apparaisse quand on se met à explorer des zones du catalogue qui n'ont pas été visionnées depuis longtemps. LR se rend compte que les aperçus manquent (ont été purgés), ils les reconstruit, l'incohérence entre le timestamp XMP et le timestamp catalogue apparaît pour de nombreux fichiers et ça fait un maximum de XMP à réécrire si on est en automatique.

Concernant la résolution du problème de Bélisaire après passage en mode auto, je pense que l'écriture des fichiers XMP se fait selon le cas de 2 manières différentes. Je vais raisonner comme si j'avais écrit le programme...

1. En mode non automatique, je n'ai pas besoin du XMP pour les opérations en cours. Celui-ci ne sera donc ouvert qu'au moment de l'écriture (Ctrl-S). LR écrasera le fichier XMP en réécrivant la totalité de l'arborescence des balises (il lui suffit de transformer au format XMP ce qu'il y a dans le catalogue pour le fichier en question - pour ceux qui sont curieux, ce ne sont pas des données binaires mais du texte, très voisin de ce qu'il y a dans le XMP).

2. En mode automatique, il y a un problème de performance à régler. On ne peut pas réécrire en permanence (à chaque action utilisateur) la totalité de la structure, surtout si les retouches locales sont nombreuses et affectent de grandes surfaces. Il faut donc ouvrir le fichier une fois, maintenir la structure en mémoire (on appelle ça le DOM - Document Object Model XML) et à chaque opération à enregistrer, ne toucher que la zone concernée de la structure. Ensuite, si je voulais jouer les choses finement, je mettrais l'opération d'écriture du XMP dans une file d'attente qui se viderait au fur et à mesure pendant les temps de non activité. Cela permettrait également d'accélérer le passage d'un fichier à l'autre et de ne pas avoir à réouvrir un des  XMP précédent si on revient sur une image sur laquelle on vient de passer et si l'opération d'écriture du XMP est toujours présente dans la file d'attente (sinon, il faudrait réouvrir le fichier).

Tout ça devrait pouvoir se vérifier en partie en monitorant les entrées-sorties de LR. Mais là, je n'ai pas trop le temps. Il n'est donc pas incohérent que le problème apparaisse dans un cas (écriture non automatique) et pas dans l'autre, les processus et le timing étant différents.

Une à suivre concernant l'impossibilité d'écrire le XMP en mode non automatique : comme je ne vois pas a priori de raison pour que LR garde ouvert en mode exclusif un fichier XMP de manière permanente, il faudrait regarder s'il n'y a pas un plugin actif qui garde ouvert le XMP correspondant à la photo en cours d'édition. Là, il y aurait une possibilité assez évidente de conflit. En mode automatique, l'écriture du XMP étant décalée à un moment où la photo n'est probablement plus en cours d'édition, le plugin ne serait plus actif et n'empêcherait pas l'écriture, le XMP étant "libéré".

Test : S'ils existent, désactiver tous les plugins éventuels, désactiver le mode automatique d'écriture des XMP, relancer LR et vérifier si le problème est toujours présent. Sinon, réactiver les plugins un par un jusqu'à trouver le coupable.
Patrick

ChatOuille

#35
Janvier 04, 2020, 23:41:56
Citation de: Nikojorj le Janvier 04, 2020, 20:42:19
C'est exactement cette boite de dialogue à laquelle je faisais allusion :
Oui, je sais. En général ce n'est pas une faute mais LR est vraiment occupé à enregistrer, bien que malheureusement il le fait en cachette. Samoreen l'a largement expliqué.
Je suis en écriture automatique des XMP, mais j'utilise en parallèle Ctrl+S pour forcer l'écriture lorsque le traitement de la photo est terminé. Cette fonction n'écrit pas seulement les XMP, mais il modifie aussi les métadonnées des fichiers JPEG, s'il y en a. Pour le reste, je laisse gérer l'écriture des XMP par LR. Je ne me suis jamais posé la question de quel moment est choisi pour le faire.

Je n'ai donc pas ce problème de refus permanent. Souvent lorsque je tape Ctrl+S après traitement, il refuse d'écrire, mais si j'insiste c'est fait. Je ne sais pas d'où peut venir ce problème de fichiers récalcitrants. Des plug-ins, peut-être, mais je ne sais pas. J'ai pas mal de plugins mais je ne peux pas dresser la liste car LR se trouve sur une autre partition. J'utilise les plugins de passage vers DxO 9 et 10, mais il y en a un tas d'autres que je n'utilise jamais sur LR, mais uniquement sur PS. Mais lors de l'installation je demande aussi de l'installer sur LR. Ils ne sont jamais activés, mais ils sont là. Je ne comprends pas pourquoi je n'ai pas ce problème car avec presque 58000 photos il y a certainement eu des traitements de toutes sortes. Ce que je vais dire c'est idiot, mais regardez quand-même que le fichier XMP n'est pas protégé en écriture. On ne sait jamais.

ChatOuille

#36
Janvier 05, 2020, 17:44:54
Je suis à nouveau là car j'essais de chercher un peu de lumière afin de savoir pourquoi je n'ai pas ce problème. Je précise que ma version de LR est la 5.6 et tourne sous Win7 SP1 64bits. J'ai rouvert LR et vérifié que les corrections des métadonnées que j'avais apporté hier, elles étaient bien maintenues. C'était bien le cas : aucun fichier avec conflit de métadonnées. Je me suis occupé des autres status comme inconnu, changé sur disque etc. et j'ai effacé des photos qui n'existaient plus car il ne s'agissait pas de mes prises de vue, mais des photos utilisées à un certain moment pour des tests qui étaient restées dans le catalogue. Finalement il ne restent que quelques MP4 et un panorama sans métadonnées. Je les ai laissés car cela n'a pas d'importance.

J'ai réfléchi sur la possibilité que ça soit certaines corrections qui bloquent la MaJ des métadonnées comme cela a été évoqué. J'avoue que j'utilise LR uniquement pour le développement de base, le reste je le fais avec PS. Je n'utilise jamais ni les effets ni le split toning ni camera calibration. Le N&B je le fais avec Silver Efex Pro via PS. J'utilise bien les corrections locales (essentiellement le pinceau), tampon des poussières au cas échéant, bruit/accentuation, modification de la courbe, des couleurs etc. Le recadrage est plus rare mais j'ai certainement quelques photos recadrées. Ma conclusion est que toutes ses corrections ne bloquent pas l'enregistrement des métadonnées (en tout cas chez moi). Ça serait uniquement la séparation des couleurs ou les effets qui pourraient bloquer, mais pas sûr.

Puis j'ai examiné le coté plugins. J'en ai pas mal et ils étaient tous activés. J'en ai désactivé quelques-uns mais je vais poursuivre et ne laisser que les DxO. Je ne savais pas ce que c'était Behance mais j'ai vu que c'est encore une histoire de Cloud qui ne m'intéresse pas. Cela ne va pas vous éclairer beaucoup, mais ce sont mes constatations.

Bélisaire

#37
Janvier 06, 2020, 16:35:03
Citation de: ChatOuille le Janvier 05, 2020, 17:44:54
Je suis à nouveau là car j'essais de chercher un peu de lumière afin de savoir pourquoi je n'ai pas ce problème.

Tu cherches les problèmes ? Tu trouves qu'il n'y en a pas suffisamment comme ça ? ;)
Bon courage, parce que ça ne m'a pas l'air simple.
(J'ai cinq modules dont quatre qui me semblent être installés par défaut, Adobe stock, Facebook, Flickr, Mode connecté Nikon).

patrickj

#38
Janvier 06, 2020, 17:03:59
Est-ce que le problème décrit ici concerne uniquement Windows ? Car je suis sur Mac, j'ai un catalogue avec plus de 42 000 photos, et je n'ai jamais constaté que les fichiers XMP étaient modifiés quand je visualise d'anciennes photos. J'ai activé la mise à jour automatique des XMP, et mon mécanisme de backup me signalerait immédiatement si les fichiers XMP avaient été modifiés.

Bélisaire

#39
Janvier 06, 2020, 17:21:52
Citation de: patrickj le Janvier 06, 2020, 17:03:59
Est-ce que le problème décrit ici concerne uniquement Windows ? Car je suis sur Mac, j'ai un catalogue avec plus de 42 000 photos, et je n'ai jamais constaté que les fichiers XMP étaient modifiés quand je visualise d'anciennes photos. J'ai activé la mise à jour automatique des XMP, et mon mécanisme de backup me signalerait immédiatement si les fichiers XMP avaient été modifiés.

Pour Mac, je n'en sais rien. Mais, d'après ce qui a été décrit plus haut, avec la mise à jour automatique, il n'y a pas de problème (sous Windows).

ChatOuille

#40
Janvier 06, 2020, 18:25:03
Citation de: Bélisaire le Janvier 06, 2020, 16:35:03
Tu cherches les problèmes ? Tu trouves qu'il n'y en a pas suffisamment comme ça ? ;)
Je n'ai pas de problème et je n'en cherche pas. J'essaye uniquement de vous aider parce que vous en avez. J'essaye d'expliquer comment je travaille et ce que j'ai afin de comparer et trouver la cause. J'ai bien plus de modules que toi et pourtant pas de problème. Cela ne doit donc pas en être la cause.

Bélisaire

#41
Janvier 06, 2020, 18:50:09
Mon intervention était une boutade, à prendre au second degré.

ChatOuille

#42
Janvier 06, 2020, 19:04:10
Pas grave!  :D

Samoreen

#43
Janvier 06, 2020, 23:10:56
Citation de: patrickj le Janvier 06, 2020, 17:03:59
Est-ce que le problème décrit ici concerne uniquement Windows ?

Le problème est également observé sur le Mac. Je n'ai peut-être pas été assez précis dans mes descriptions précédentes (pas facile de résumer le fil du site de feedback que j'ai cité au début de ce fil). Le lire ou le relire peut permettre d'approfondir les choses. Tentons de résumer :

- Le timestamp "Windows/Mac" du XMP et le champ xmp:MetadataDate à l'intérieur du XMP sont toujours synchrones.

- Le flag "métadonnées non à jour peut être activé pour 2 raisons :

1) Lors de la mise à jour du XMP le timestamp du catalogue (colonne touchtime de la table Adobe_images de la base de données) n'est pas écrit en même temps que les 2 autres timestamps cités plus haut. Au lieu de définir une valeur unique avant ces 2 écritures et de la stocker dans les 2 destinations, LR calcule 2 timestamps différents à la volée. Ce qui a pour conséquence d'activer le flag.

2) Le fait que le problème apparaisse quand on revisite des images anciennes dont l'aperçu a été purgé est probablement causé par une confusion interne au XMP qui contient en fait 3 timestamps différents :

   xmp:ModifyDate="2013-05-04T22:40:19"
   xmp:CreateDate="2013-05-04T22:40:19"
   xmp:MetadataDate="2019-05-26T17:56:25+02:00"

L'incohérence peut donc survenir alors que le timestamp Windows/Mac du fichier XMP n'a pas bougé. Ce qui n'empêche pas la valeur du champ touchtime de la database d'être incohérent avec au moins un des 2 autres timestamps du XMP :  xmp:ModifyDate ou xmp:CreateDate (je penche pour le premier). Lors de la re-création de l'aperçu, le nom cryptique de l'aperçu change (genre 3AB7F0AE-28C9-4C3F-9386-D2B93E47864F-73c1fddd9000318c9ab67ab38b91ae22). Or je ne vois pas cet identifiant repris dans le XMP qu'il n'y a donc pas lieu de modifier. Je ne vois aucune raison de changer quoi que ce soit d'autre dans les métadonnées.

Il y a donc en fait 2 causes différentes à un même problème et l'apparition de celui-ci n'implique pas nécessairement que le timestamp Windows/mac du XMP ait été modifié.

Une personne ayant des compétences en bases de données, en XML, en développement et ayant beaucoup de loisirs pourrait faire un traçage encore plus précis de tous ces timestamps. De mon côté, je pense que j'ai déjà passé beaucoup trop de temps là-dessus (et j'en connais une qui est du même avis). C'est le boulot des développeurs d'Adobe et moi, je les paie. S'ils veulent faire quelque chose, ils ont assez d'infos pour corriger ce code. Mais comme on le craignait au moment de l'apparition du modèle "abonnement", celui-ci n'encourage ni l'innovation, ni la chasse aux bugs.
Patrick

Bélisaire

#44
Janvier 07, 2020, 14:05:45
Je ne crois pas m'avancer beaucoup en écrivant que tous, ici, nous sommes admiratifs devant le temps et l'énergie que vous consacrez à ce fil. Merci.

Samoreen

#45
Janvier 07, 2020, 14:36:46
Citation de: Bélisaire le Janvier 07, 2020, 14:05:45
Je ne crois pas m'avancer beaucoup en écrivant que tous, ici, nous sommes admiratifs devant le temps et l'énergie que vous consacrez à ce fil. Merci.

Merci. Pas de quoi  :) . Je n'ai pas de mérite : 1) l'ingénierie logicielle a quand même été mon métier pendant une bonne partie de ma carrière et 2) quand un problème m'énerve, je ne lâche pas. Le travail d'analyse a donc déjà été fait. Mais il pourrait être approfondi, ce qui est difficile sans le code source. J'ai cependant promis à mon épouse préférée, il y a 10 ans lorsque j'ai pris ma retraite, que je ne coderai plus. Je tiens bon avec quelques écarts mineurs de temps en temps.

Quant à l'énergie dépensée, j'ai bien peur que ce soit en vain. Quand j'étais en activité et qu'un de mes clients me rapportait une difficulté ou un bug, je n'étais pas couché avant que ça soit réglé. Question de conscience professionnelle et d'amour-propre. De nos jours, le problème est plutôt de faire réagir les développeurs aux problèmes de leurs clients. Les raisons en sont bien connues mais ça n'est pas une excuse.
Patrick

Comtois91

#46
Janvier 07, 2020, 17:05:12
Bonjour,
Citation de: Samoreen le Janvier 07, 2020, 14:36:46
.... De nos jours, le problème est plutôt de faire réagir les développeurs aux problèmes de leurs clients....
De nos jours, je crois que les développeurs n'ont plus la main, C'est le financier qui compte combien ça coûte aujourd'hui et combien ça pourra peut-être rapporter demain ou après-demain.

cordialement
Comtois91

Nikojorj

#47
Janvier 07, 2020, 17:15:46
Après-demain? T'es fou toi, tu prends le pognon et tu te barres dans la nuit! ;D

Et oui, kudos à Samoreen pour son analyse de bug.

Comtois91

#48
Janvier 08, 2020, 09:16:18
Bonjour,
Citation de: Nikojorj le Janvier 07, 2020, 17:15:46
Après-demain? T'es fou toi, tu prends le pognon et tu te barres dans la nuit! ;D

Et oui, kudos à Samoreen pour son analyse de bug.

Je me suis mal expliqué, je voulais dire que, entre la certitude de coût de correction des bugs et l'incertitude de gains futurs liés à cette correction, l'arbitrage est évident.
Bonne journée
Comtois91

Dub

#49
Janvier 08, 2020, 12:25:11
Pour relativiser, sur Mac avec la MAJ auto des XMP, de LR1 à LR6.14 je n'ai jamais eu de problèmes de métadonnées...
Pour ce qui est de l'écoute des utilisateurs, c'est vrai que le passage à Photo Mechanic vous fait découvrir un autre monde !!!
Disponibilité, écoute, prise en compte, ou du moins réponse, à des demandes invraisemblables, patience ( ;D )... aux antipodes d'Adobe...
Imprimer
En haut Pages 1 2 3 Toutes
Actions de l'utilisateur