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 Pages1 2 3 Toutes
Actions de l'utilisateur

Bélisaire

Décembre 28, 2019, 12:08:01
Bonjour tous.
Êtes-vous confronté à ce phénomène : il suffit que regarde des photos, sans les modifier, pour que Lightroom signale ensuite ces fichiers comme ayant des métadonnées non à jour. Quelqu'un saurait-il expliquer ce phénomène ? Est-ce que la lecture de photos (on va dire « anciennes ») avec une version récente de LR entraîne une modification des métadonnées ? Merci.

Samoreen

#1
Décembre 28, 2019, 13:52:35
Citation de: Bélisaire le Décembre 28, 2019, 12:08:01
Êtes-vous confronté à ce phénomène : il suffit que regarde des photos, sans les modifier, pour que Lightroom signale ensuite ces fichiers comme ayant des métadonnées non à jour. Quelqu'un saurait-il expliquer ce phénomène ? Est-ce que la lecture de photos (on va dire « anciennes ») avec une version récente de LR entraîne une modification des métadonnées ? Merci.

Ah oui, je peux expliquer. J'ai étudié ce bug aussi vieux que Lightroom lui-même en long, en large et en travers. J'ai complètement caractérisé le problème en traçant l'erreur dans la base de données, j'ai expliqué comment reproduire le problème, j'ai fait un rapport complet expliquant où était l'erreur,... Bref, j'ai donné toutes les infos permettant de corriger ce bug pénible. Ils n'ont pas bougé.

Tout est là : https://feedback.photoshop.com/photoshop_family/topics/wrong-timestamp-stored-in-lightroom-catalog-causing-wrong-metadata-status-all-windows-versions
Patrick

Samoreen

#2
Décembre 28, 2019, 14:05:03
Si la lecture du fil cité plus haut est trop longue, voici une explication plus brève...

Quand on affiche une image qui n'a pas été vue depuis longtemps, l'aperçu a probablement été purgé. Quand LR reconstruit l'aperçu, il inscrit la date et l'heure dans le catalogue et dans le XMP. Problème : le plus souvent, ces valeurs diffèrent que quelques fractions de secondes ou de quelques secondes. Comme c'est la comparaison entre ces 2 valeurs qui indique si le XMP est à jour, en retard sur le catalogue ou bien en avance (cas d'une modification extérieure à LR), l'image est aussitôt marquée comme non à jour.

Faire un Ctrl-S suffit parfois à régler le problème mais le plus souvent, le tag "métadonnées non à jour" revient au bout de quelques secondes. La seule parade connue est la suivante :

- Faire Ctrl-S pour enregistrer le XMP. Il est effectivement écrit, j'ai vérifié (mais il n'a pas nécessairement le bon timestamp.
- Relire les données du XMP soit par le menu Métadonnées, soit par un clic-droit sur l'image | Lire les métadonnées depuis le fichier (traduction approximative, je travaille en anglais).
- Le catalogue contiendra alors le même timestamp que le XMP.
- Le problème est réglé temporairement jusqu'à ce que l'aperçu de l'image soit purgé. Et au prochain visionnage, ça recommencera, ou pas.
Patrick

Bélisaire

#3
Décembre 28, 2019, 16:30:27
Merci pour ces explications. Enfin. Il y a un moment déjà que je me heurtais à ce bug, et je m'étonne que dans le fil de discussion on évoque l'éventualité qu'une poignée seulement d'utilisateurs y soient confrontés. (Ce serait bien d'avoir ici quelques retours).
Ce qui y est décrit correspond exactement à ce que j'ai observé. Plus encore: quand un fichier revient sans arrêt en mode « Métadonnées non à jour » après avoir été pourtant sauvegardé, une lecture « depuis le fichier » ne suffit pas toujours à résoudre le problème: il revient sans arrêt après quelques secondes comme devant être mis à jour. À tel point, parfois, que j'ai cru que le fichier était corrompu. Effacer le xmp correspondant ne suffit pas. Le seul moyen que j'ai trouvé alors était... de supprimer le fichier lui-même (question d'agacement)... après (tout de même) l'avoir converti en jpg (je n'ai pas souvenir que les autres formats --dng, tif -- aient été concluants.
Me voilà informé. Merci encore.

Col Hanzaplast

#4
Décembre 28, 2019, 16:45:44
Citation de: Bélisaire le Décembre 28, 2019, 16:30:27Je m'étonne que dans le fil de discussion on évoque l'éventualité qu'une poignée seulement d'utilisateurs y soient confrontés. (Ce serait bien d'avoir ici quelques retours).

Si je comprends bien ceux qui n'utilisent pas les XMP ne sont pas concernés. Je n'ai jamais utilisé les XMP et je ne dois pas être le seul.

Bélisaire

#5
Décembre 28, 2019, 17:03:44
Samoreen te répondra avec certitude. Moi, je vais (hélas) rester dans le flou : il me semble bien avoir eu ce problème avec des dng et, sauf erreur, le dng n'est pas flanqué d'un xmp.

Samoreen

#6
Décembre 28, 2019, 17:52:42
Citation de: Col Hanzaplast le Décembre 28, 2019, 16:45:44
Si je comprends bien ceux qui n'utilisent pas les XMP ne sont pas concernés. Je n'ai jamais utilisé les XMP et je ne dois pas être le seul.

Le problème est directement lié à la comparaison entre le timestamp du XMP et celui de l'image correspondante dans le catalogue. Cependant, je suppose que le même problème peut survenir, et pour les mêmes raisons, avec les fichiers dans lesquels LR écrit des métadonnées et/ou des corrections. Je ne l'ai jamais vérifié mais en toute logique, on devrait observer les mêmes effets. Beaucoup d'utilisateurs ne s'aperçoivent pas du problème soit parce qu'ils n'affichent pas l'icône "statut des métadonnées" dans leurs vignettes, soit parce qu'ils ne s'intéressent pas du tout à l'état de ces métadonnées (ils n'utilisent jamais le filtre correspondant). Mais je n'ai aucun doute sur le fait que le bug est là pour tout le monde.

L'erreur vient du fait que LR n'écrit pas en même temps sur les 2 destinations. La bonne procédure serait de stocker un timestamp unique en mémoire et d'écrire cette même valeur dans le catalogue et dans le XMP (ou le fichier DNG...) même si cela se fait avec quelques secondes de décalage. Il semble que LR ait une approche plus primaire. Il inscrit la date et l'heure correspondant au moment où il écrit dans le fichier. C'est assez idiot. Si le programme n'est pas trop occupé avec d'autres opérations d'entrée/sortie, l'écart peut être très faible et donc considéré comme négligeable par LR. Mais si beaucoup d'opérations disques sont exécutées en parallèle (par exemple, (re)création des aperçus pour tout un dossier), les écritures peuvent être décalées de manière significative. Et la valeur du décalage sera positive ou négative en fonction de quelle opération aura été exécutée en premier. Résultat : petite flèche en haut ou en bas selon les cas.

Tout ça est bien gênant, en particulier pour ceux qui utilisent les XMP comme sauvegarde de leurs réglages ou pour effectuer des transferts vers d'autres machines. Et ça dure a priori depuis que Lightroom existe.

J'ai une petite idée sur le fait que cela n'ait jamais été corrigé. N'oublions pas qu'une bonne partie de l'interface utilisateur est écrite en langage de scripting LUA (un choix dont je persiste à dire qu'il est catastrophique). C'est un langage assez indigent qui ne permet pratiquement aucun contrôle entre tâches : pas de communication inter-processus, pas de communication inter-threads, pas de gestion des exceptions. Il n'est donc pas impossible que l'idée que j'ai émise plus haut (stocker provisoirement une valeur unique du timestamp) ne puisse pas être mise en place facilement ou bien que cela demande trop d'efforts pour la correction d'un bug qu'ils considèrent comme mineur (ce qu'il n'est pas).

Je ne vous laisse aucun espoir sur une correction éventuelle. J'ai eu il y a 2 ou 3 ans un échange un peu vif avec un représentant Adobe sur leur forum de feedback après qu'il ait annoncé que ce bug ne serait pas corrigé parce que ce n'était pas possible. Il s'est ensuite repris mais cela semble confirmer ce que j'ai expliqué ci-dessus.
Patrick

Bélisaire

#7
Décembre 28, 2019, 18:43:51
Cette explication technique (et compréhensible) est la bienvenue. Et je suis content... pour moi aussi : je n'y connais rien en technique, mais j'observe juste  ;).
On fera avec, et je ne penserai plus que mon fichier récalcitrant est corrompu.

ChatOuille

#8
Décembre 28, 2019, 20:02:57
Merci pour tes recherches. Je n'ai pas examiné le problème sous ce point de vue exactement, mais je suis tellement habitué que quand je tape Ctrl+S il me dit que ce n'est pas possible d'enregistrer et je dois répéter l'opération. On connaît la bête et on vit avec.

Bélisaire

#9
Janvier 01, 2020, 17:57:14
Je viens de faire un test avec une photo récalcitrante, en ce sens qu'elle s'inscruste dans « Métadonnées non à jour ».
Enregistrer les métadonnées dans le fichier ou lire les métadonnées depuis le fichier n'aboutit à rien.
Exporter cette même photo (ARW) en DNG ne règle pas le problème (me voilà avec deux images non à jour).
Modifier la photo et sauvegarder à nouveau ne change rien.
Exporter en TIF masque le problème.

Bonne année à tous.

tkosak

#10
Janvier 01, 2020, 20:23:27
Citation de: Bélisaire le Janvier 01, 2020, 17:57:14
Je viens de faire un test avec une photo récalcitrante, en ce sens qu'elle s'inscruste dans « Métadonnées non à jour ».
Enregistrer les métadonnées dans le fichier ou lire les métadonnées depuis le fichier n'aboutit à rien.
Exporter cette même photo (ARW) en DNG ne règle pas le problème (me voilà avec deux images non à jour).
Modifier la photo et sauvegarder à nouveau ne change rien.
Exporter en TIF masque le problème.

Bonne année à tous.
Une suggestion de manip à faire : en dehors de LR, tu vas renommer le .xmp de ton raw "récalcitrant". Logiquement, LR va couiner pour la mise à jour des métadonnées. Tu lui dis de mettre à jour, logiquement il recrée le .xmp. Là, suspens insoutenable, LR cessera-t'il de faire l'imbécile? (et tu n'oublies pas de faire le ménage : supprimer le .xmp en trop...)
Une variante à ce tester : ouvrir le .xmp, supprimer tout son contenu, refermer (en sauvegardant, bien sûr).

Nikojorj

#11
Janvier 01, 2020, 23:52:47
Citation de: Samoreen le Décembre 28, 2019, 17:52:42
Beaucoup d'utilisateurs ne s'aperçoivent pas du problème soit parce qu'ils n'affichent pas l'icône "statut des métadonnées" dans leurs vignettes, soit parce qu'ils ne s'intéressent pas du tout à l'état de ces métadonnées (ils n'utilisent jamais le filtre correspondant). Mais je n'ai aucun doute sur le fait que le bug est là pour tout le monde.
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.
Ça collerait avec le bug discuté ici, je pense.

tkosak

#12
Janvier 02, 2020, 08:55:33
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.
Ça collerait avec le bug discuté ici, je pense.
J'ai parfois ce message alors que j'ai aussi l'affichage du badge...

Autre manifestation du bug : là je viens de déplacer mes photos sur un autre disque, et pour des images qui n'ont pas changé depuis plusieurs années, je me retrouve avec une foultitude de photos avec un pb de métadonnées. Une fois les mises à jour faites, comme une mauvaise épidémie, ce maudit badge revient, de façon erratique, pas toujours les mêmes images (en fait je n'ai rien repéré...), et toujours à partir de la page écran affichée dans le module bibliothèque (dans la logique de LR, c'est normal).
J'ai même fait un ctrl+S pour la totalité du catalogue (quand même pas loin de 60000 images), le job de copie sur disque a tourné plusieurs heures, je reviens ce matin et j'ai encore (ou à nouveau) quelques conflits... Ptêt'ben que j'va ignorer cette merdouille...

Ah oui, une fois les photos à conflit sélectionnées, il m'a semblé que LR était plus efficace en cliquant sur le pitit bouton du panneau de droite (cf capture d'écran) mais ça n'a aucune logique a priori : sans un doute une vue de mon esprit embrumé.
Pour info, LR 6.10 sur windoouz 10

Samoreen

#13
Janvier 02, 2020, 10:58:20
Pour répondre en partie aux remarques ci-dessus :

- Plus le nombre de photos sur lesquelles on essaie de corriger simultanément le problème en faisant un Ctrl-S est grand, plus les chances de provoquer à nouveau le bug sont élevées. En effet, en multipliant le nombre d'opérations disque menées en parallèle, on augmente la probabilité d'avoir un écart significatif entre le timestamp de l'image dans le catalogue  et le timestamp de son XMP. Je pense qu'il vaut mieux procéder par petits lots ou bien corriger plus fréquemment. Personnellement, j'ai créé une collection dynamique qui contient toutes les images ayant le badge "métadonnées non à jour". Je la visite régulièrement. Un Ctrl-A suivi d'un Ctrl-S élimine une bonne partie des images. Pour les cas réfractaires, un Ctrl-A suivi d'un Ctrl-S (par sécurité pour s'assurer que tout est bien écrit dans le XMP) ) puis suivi d'une lecture des métadonnées depuis le fichier corrige le problème. En général, et jusqu'à la prochaine apparition du bug.

- Pour les cas où la manip de lecture depuis le fichier ne suffit pas, je ne sais pas. J'ai déjà eu ce cas quelquefois ainsi que le problème décrit par Nikojorj mais je ne l'ai pas encore caractérisé. Pour ce dernier problème, il se peut que LR "pense" que des opérations soient effectivement en cours sans que cela soit visible via les barres de progression habituelles. On en revient probablement à des soucis liés au langage LUA et à l'absence d'outils de synchronisation dans ce langage. Il doit y avoir des circonstances où un fil d'exécution n'a pas les moyens de vérifier si une opération d'entrée-sortie lancée par un autre fil d'exécution est ou non terminée. Pour faire une comparaison simpliste, c'est un peu comme si le "dirty flag" d'un document Word n'était pas remis à 0 après que l'on ait enregistré le document. Word refusera toujours de se fermer car il pensera que le document n'est pas enregistré.

- Pour le dire de manière plus technique, l'interface utilisateur de LR n'est pas gérée comme une machine à états finis parce que le langage utilisé ne le permet pas. Ce qui veut dire qu'il n'y pas de "centre de contrôle" qui permet d'assurer la cohérence des actions utilisateurs ainsi que celle de l'état des éléments de l'UI (menus, boutons, commandes diverses,...). À mon humble avis, c'est ce qui explique la plupart des bugs de l'UI et la difficulté qu'ils ont à tracer et à caractériser les bugs. Un bon exemple de cet état de fait (et pour moi quasiment une preuve - ce comportement est typique de ce genre d'erreur) est ce bug lui aussi assez ancien : https://feedback.photoshop.com/photoshop_family/topics/folder-favorite-setting-cannot-be-changed . J'ai décrit le moyen de le reproduire mais ils n'arrivent pas à le corriger. Le choix de LUA est une erreur majeure et je crois que les utilisateurs auront à en subir les conséquences ad vitam eternam.

- La probabilité d'apparition du bug est directement liée à la fréquence de purge définie dans les préférences du catalogue. Je pense que ceux qui ont choisi "Jamais" voient le bug beaucoup moins souvent que ceux qui ont choisi une purge quotidienne.
Patrick

Bélisaire

#14
Janvier 02, 2020, 11:24:28
Pour tkosak #10 : comme indiqué dans mon message #3, renommer ou supprimer le xmp reste sans effet. J'ai essayé le clic sur l'icône, sans succès.

Pour Nikojorj # 11 : J'ai la certitude que ce n'est pas la cause du dysfonctionnement dans la mesure où, ces temps-ci, je laisse LR ouvert toute la journée (à moins qu'il ne s'arrête jamais d'écrire). Par ailleurs, les métadonnées, je ne laisse pas LR les écrire quand il le veut: c'est moi qui décide (enfin, j'espère) à partir d'une collection dynamique créée pour l'occasion. Je suis également maître du temps. Je n'ai encore jamais reçu d'avertissement d'écriture de la part de Lightroom.

Pour Samoreen # 13 : je fais partie de ceux qui ont choisi « jamais » dans les paramètres du catalogue (si on parle bien de la suppression des aperçus). Si oui, je puis donc m'estimer heureux.

Merci à tous pour vos retours.

Bélisaire

#15
Janvier 02, 2020, 11:31:42 Dernière édition: Janvier 02, 2020, 11:36:56 par Bélisaire
J'ajoute (plutôt que de modifier le message précédent), l'info le vaut bien: je viens de procéder à l'astuce proposée par tkosak : ouvrir le xmp, supprimer le contenu, sauvegarder. De retour dans LR, l'image a un nouveau badge (connu): avec « importer les métadonnées depuis le fichier », l'image est à jour et disparaît de ma vue. Belle astuce. Bravo :). - J'espère ne pas déchanter dans quelques minutes...).

A la réflexion, c'est curieux dans la mesure où la suppression du xmp et sa recréation par LR n'ont pas d'effet.

tkosak

#16
Janvier 02, 2020, 13:45:56
Je viens de trouver une méthode PARFAITE pour ne pas avoir de problèmes de mise à jour des métadonnées : il suffit de ne pas traiter ses images. Simple, non?
OK, je retourne me coucher...

Bélisaire

#17
Janvier 03, 2020, 12:23:56
Juste pour dire (et je pense que ce sera bon), j'ai une fois de plus appliqué (avec succès) la « méthode à tkosak » sur une (autre) image dont les métadonnées refusaient de se mettre à jour. L'intitulé exact est Importer les paramètres depuis le disque.

Bélisaire

#18
Janvier 03, 2020, 13:20:05
En fait, non. La « méthode à tkosak », elle est pas bonne  :(. En procédant ainsi, il y a réinitialisation des paramètres et toutes les modifications effectuées sur l'image dans LR disparaissent. On retrouve donc la photo RAW issue de l'appareil. Et quand on retourne dans l'historique pour revenir à l'état précédent (modifications prises en compte), c'est toujours la galère pour mettre à jour les métadonnées.

Samoreen

#19
Janvier 03, 2020, 16:36:28
Citation de: Bélisaire le Janvier 03, 2020, 13:20:05
En fait, non. La « méthode à tkosak », elle est pas bonne  :(. En procédant ainsi, il y a réinitialisation des paramètres et toutes les modifications effectuées sur l'image dans LR disparaissent. On retrouve donc la photo RAW issue de l'appareil.

Oui, pas de surprise. À mon avis, il y a 2 causes possibles au refus d'enregistrement des métadonnées :

1. Il y a un problème d'écriture ou de permission à cet endroit du disque mais c'est assez peu probable.

2. Le fichier XMP est corrompu et LR n'arrive pas à reconstituer l'arborescence des balises. Si c'est ça, je peux le confirmer, voire le corriger. Il suffit de m'envoyer le XMP en question.
Patrick

tkosak

#20
Janvier 03, 2020, 17:23:59
Citation de: Bélisaire le Janvier 03, 2020, 13:20:05
En fait, non. La « méthode à tkosak », elle est pas bonne  :(. En procédant ainsi, il y a réinitialisation des paramètres et toutes les modifications effectuées sur l'image dans LR disparaissent. On retrouve donc la photo RAW issue de l'appareil. Et quand on retourne dans l'historique pour revenir à l'état précédent (modifications prises en compte), c'est toujours la galère pour mettre à jour les métadonnées.
Euh... en copiant les métadonnées à partir d'un fichier vide, c'est normal que tu annules tout dans LR... J'espère que les dégâts se limitent à un ou deux fichiers de test!... Sinon, peut-être aurais-tu intérêt à repartir de la dernière sauvegarde du catalogue, si elle n'est pas trop ancienne...

Bélisaire

#21
Janvier 03, 2020, 21:32:05 Dernière édition: Janvier 03, 2020, 21:47:34 par Bélisaire
Citation de: Samoreen le Janvier 03, 2020, 16:36:28
Oui, pas de surprise. À mon avis, il y a 2 causes possibles au refus d'enregistrement des métadonnées :

1. Il y a un problème d'écriture ou de permission à cet endroit du disque mais c'est assez peu probable.

2. Le fichier XMP est corrompu et LR n'arrive pas à reconstituer l'arborescence des balises. Si c'est ça, je peux le confirmer, voire le corriger. Il suffit de m'envoyer le XMP en question.

À mon sens, ni l'un ni l'autre.
Pour le (1), difficile à vérifier, mais effectivement, c'est peu probable, en ce sens que c'est un phénomène qui dure depuis des années, pour de nombreux fichiers. Alors, toujours au même endroit ?... D'autant qu'entre-temps, j'ai changé de PC, de disque dur, etc.
Pour le (2), je dis « impossible » dans la mesure où je supprime physiquement le XMP dans l'explorateur de Windows. LR le crée à nouveau ensuite. Cela ferait beaucoup trop de fichiers corrompus.

Citation de: tkosak le Janvier 03, 2020, 17:23:59
Euh... en copiant les métadonnées à partir d'un fichier vide, c'est normal que tu annules tout dans LR... J'espère que les dégâts se limitent à un ou deux fichiers de test!... Sinon, peut-être aurais-tu intérêt à repartir de la dernière sauvegarde du catalogue, si elle n'est pas trop ancienne...

Il n'y a pas de dégâts. Le XMP n'est pas nécessaire à LR. Il a une copie de ce qui est écrit dans ses données du catalogue. Je suis allé dans l'historique, j'ai annulé la dernière commande, à savoir la réinitialisation, et mon image est revenue comme je l'avais modifiée avant effacement du XMP. (Pour l'anecdote : avant de savoir ce qu'était un XMP, il m'est arrivé de les supprimer TOUS (des milliers); LR n'a eu aucun mal à reconstituer mes images).


Ajout : J'ai dupliqué le fichier dans un autre endroit (disque dur différent, avec et sans xmp): le problème demeure. Je me demande si LR ne réagit pas à une sorte de modification.

Bélisaire

#22
Janvier 04, 2020, 11:21:11
Nouveau test. De ma photo récalcitrante à la mise à jour des métadonnées, j'ai suivi l'historique; je suis revenu en arrière en ôtant des modifications tout en mettant à jour à chaque étape. Après la cinquante-septième étape (après « ajouter un contour » et à « Ombres »), le fichier accepte de se mettre à jour. Tout cela m'avance à quoi ? A rien. Sauf à me conforter dans l'idée que la difficulté de se mettre à jour est en relation avec certaines modifications apportées à l'image, mais pas avec l'historique proprement dit : j'ai fait une copie de cette photo et du XMP, j'ai renommé les deux fichiers et j'ai importé l'image dans Lightroom. L'historique disparaît mais l'impossibilité de mettre à jour subsiste.

(Mais non, je ne suis pas obsédé).

Nikojorj

#23
Janvier 04, 2020, 12:01:29
Bélisaire, as-tu lu les explications de Samoreen? Il explique de manière très convaincante le bug...

Citation de: Samoreen le Décembre 28, 2019, 17:52:42
Le problème est directement lié à la comparaison entre le timestamp du XMP et celui de l'image correspondante dans le catalogue.
[...]
L'erreur vient du fait que LR n'écrit pas en même temps sur les 2 destinations. La bonne procédure serait de stocker un timestamp unique en mémoire et d'écrire cette même valeur dans le catalogue et dans le XMP (ou le fichier DNG...) même si cela se fait avec quelques secondes de décalage. Il semble que LR ait une approche plus primaire. Il inscrit la date et l'heure correspondant au moment où il écrit dans le fichier. C'est assez idiot. Si le programme n'est pas trop occupé avec d'autres opérations d'entrée/sortie, l'écart peut être très faible et donc considéré comme négligeable par LR. Mais si beaucoup d'opérations disques sont exécutées en parallèle (par exemple, (re)création des aperçus pour tout un dossier), les écritures peuvent être décalées de manière significative. Et la valeur du décalage sera positive ou négative en fonction de quelle opération aura été exécutée en premier. Résultat : petite flèche en haut ou en bas selon les cas.

Bélisaire

#24
Janvier 04, 2020, 13:15:13
Citation de: Nikojorj le Janvier 04, 2020, 12:01:29
Bélisaire, as-tu lu les explications de Samoreen? Il explique de manière très convaincante le bug...

J'ai lu, j'ai compris. L'explication... n'explique cependant pas qu'un fichier (ou plusieurs) ne puisse(nt) jamais être mis à jour. Comment comprendre, par exemple, qu'en cliquant sur une étape de l'historique, le fichier se met à jour sans problème; qu'en cliquant sur l'étape précédente, la mise à jour ne se fait pas. Cette manipulation (après/avant*) est reproductible à souhait avec toujours la même conséquence (maj/pas de maj). Le décalage d'écriture, dont parle Samoreen, ne tient pas ici.

après/avant = par ordre d'apparition dans l'historique; après = modif plus ancienne.

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...

Zaphod

#50
Janvier 08, 2020, 13:42:22
Citation de: Dub le 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...
Yep, après à l'usage un catalogueur seul et un logiciel qui permet de cataloguer / visualiser / traiter les photos en même temps (comme LR ou C1), c'est totalement différent.

Dub

#51
Janvier 08, 2020, 13:51:26
Citation de: Zaphod le Janvier 08, 2020, 13:42:22
Yep, après à l'usage un catalogueur seul et un logiciel qui permet de cataloguer / visualiser / traiter les photos en même temps (comme LR ou C1), c'est totalement différent.

M'oui...  ;D
Mieux vaut faire une chose bien que plusieurs à moitié...  ;D
Le couple Photo Mechanic 6+/CameraRaw(photoshop) est redoutable d'efficacité...

;)

Zaphod

#52
Janvier 08, 2020, 19:16:38
Citation de: Dub le Janvier 08, 2020, 13:51:26
Mieux vaut faire une chose bien que plusieurs à moitié...  ;D
Ca dépend, car moi c'est l'ensemble qui m'intéresse.
Un catalogueur, aussi bon soit-il, dans lequel je ne peux trier mes photos qu'avec la vignette JPEG, et pas visualiser mes RAW dernier traitement compris ni faire 2/3 modifs à la volée sans ouvrir un autre logiciel, ça ne m'interesse pas.
Après je ne suis pas un mordu du catalogage : je me contente du tri, quelques mot clés, reco des visages, recherches rapides, transfert auto sur tablette d'une sélection... c'est basique mais ça me suffit.

Tout ça pour dire que l'intégration des fonctions n'est pas forcément juste un petit plus, parfois c'est un critère éliminatoire.

nicolas-p

#53
Janvier 08, 2020, 20:06:20
Citation de: Zaphod le Janvier 08, 2020, 19:16:38
Ca dépend, car moi c'est l'ensemble qui m'intéresse.
Un catalogueur, aussi bon soit-il, dans lequel je ne peux trier mes photos qu'avec la vignette JPEG, et pas visualiser mes RAW dernier traitement compris ni faire 2/3 modifs à la volée sans ouvrir un autre logiciel, ça ne m'interesse pas.
Après je ne suis pas un mordu du catalogage : je me contente du tri, quelques mot clés, reco des visages, recherches rapides, transfert auto sur tablette d'une sélection... c'est basique mais ça me suffit.

Tout ça pour dire que l'intégration des fonctions n'est pas forcément juste un petit plus, parfois c'est un critère éliminatoire.
+1!
C'est la force de lr.
Je passe à  photolab 3 +lr 6 en ce moment,  le combo est top mais le tout en 1 me manque...pour ces mêmes raisons.

J'exporte systématiquement un jpeg de dxo empilé  sur le raw dans lr mais c'est un pis aller car il faut y retourner si besoin de changement....

Dub

#54
Janvier 08, 2020, 20:31:36
Citation de: Zaphod le Janvier 08, 2020, 19:16:38
Ca dépend, car moi c'est l'ensemble qui m'intéresse.

Si l'ensemble est assez performant pour toi, alors, oui, c'est l'idéal...

;)

Zaphod

#55
Janvier 08, 2020, 20:43:27
Citation de: Dub le Janvier 08, 2020, 20:31:36
Si l'ensemble est assez performant pour toi, alors, oui, c'est l'idéal... ;)
Oui c'est nettement plus performant pour moi que des logiciels séparés avec des allers/retours continuels.
Ca dépend évidemment de manière de travailler, moi j'aime régulièrement mettre à jour mes images... parfois quand je les regarde paf. je fais une petite modif ni vu ni connu et je retourne au regardage :)

Dub

#56
Janvier 08, 2020, 20:54:14
Citation de: Zaphod le Janvier 08, 2020, 20:43:27
Oui c'est nettement plus performant pour moi que des logiciels séparés avec des allers/retours continuels.
Ca dépend évidemment de manière de travailler, moi j'aime régulièrement mettre à jour mes images... parfois quand je les regarde paf. je fais une petite modif ni vu ni connu et je retourne au regardage :)

Pour avoir pratiqué LR pendant 10 ans (LR1 le 27 mars 2007... le temps passe vite), je connais bien les avantages et inconvénient des deux systèmes...  8)
LR ne gérant pas les X3F Sigma, il m'a bien fallut trouver un autre moyen pour gérer mes photos, après quelques tâtonnements, Photo Mechanic
c'est imposé comme un excellent remplaçant... bien plus efficace que LR...

Zaphod

#57
Janvier 08, 2020, 21:25:45
Différemment effiace plutôt, ça n'est pas du tout le même scope de fonctions.
Par exemple, je n'ai pas de mal à croire que les outils de tri/comparaison soient meilleurs que ceux de Ligthroom qui sont basiques, mais ils me seraient à peu près inutiles vu qu'ils travaillent à partir d'une "mauvaise" interprétation du fichier.

Bélisaire

#58
Janvier 31, 2020, 22:04:29
Citation de: Samoreen le Janvier 04, 2020, 18:48:15
(...) 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 (...).

Juste pour dire... Après un mois d'« option automatique », je suis revenu en mode manuel (conscient que si j'ai un problème de maj, je passerai en auto). Le mode auto ralentit beaucoup la machine quand on traite simultanément plusieurs centaines de fichiers. LR n'en finit pas d'écrire en tâche de fond. Je préfère lancer moi-même l'écriture des données et aller boire un café pendant ce temps.
Imprimer
En haut Pages1 2 3 Toutes
Actions de l'utilisateur