(28-01-24, 17:10)manu a écrit : Issue ouverte. À suivre.

Citation :Je vais vous donner mon avis. Avoir un code qui essaie de lire ce que Lightroom Processing a fait et de le faire correspondre à certains modules de dt est à mon avis incorrect. Cela nuit à l'utilisateur final au lieu de l'aider. L'utilisateur n'apprend pas à utiliser darktable et il est possible qu'il utilise des modules plus anciens.

J'ai quelques vieilles images que j'ai traitées dans Lightroom il y a plus de 8 ans. J'ai les données xmp pour elles, mais j'ai aussi l'image exportée. Si j'ai besoin d'utiliser cette image immédiatement, j'utilise la version exportée car elle est entièrement traitée. Mais la plupart du temps, je repars de zéro sur dt en utilisant les données brutes. Le résultat final est de loin supérieur, non seulement parce que j'utilise un module/flux de travail plus moderne, mais aussi parce que j'ai acquis beaucoup plus de connaissances sur la façon de traiter les images. Cela me prend très peu de temps. Je recommande donc cette approche (partir de zéro).

(29-01-24, 15:42)manu a écrit :

(28-01-24, 17:10)manu a écrit : Issue ouverte. À suivre.

Je poste ici la traduction de la réponse qui m'a été faite sur cette issue, et qui me semble très pertinente.

Citation :Je vais vous donner mon avis. Avoir un code qui essaie de lire ce que Lightroom Processing a fait et de le faire correspondre à certains modules de dt est à mon avis incorrect. Cela nuit à l'utilisateur final au lieu de l'aider. L'utilisateur n'apprend pas à utiliser darktable et il est possible qu'il utilise des modules plus anciens.

J'ai quelques vieilles images que j'ai traitées dans Lightroom il y a plus de 8 ans. J'ai les données xmp pour elles, mais j'ai aussi l'image exportée. Si j'ai besoin d'utiliser cette image immédiatement, j'utilise la version exportée car elle est entièrement traitée. Mais la plupart du temps, je repars de zéro sur dt en utilisant les données brutes. Le résultat final est de loin supérieur, non seulement parce que j'utilise un module/flux de travail plus moderne, mais aussi parce que j'ai acquis beaucoup plus de connaissances sur la façon de traiter les images. Cela me prend très peu de temps. Je recommande donc cette approche (partir de zéro).

Cette réponse, qui pour moi met pratiquement un point final à la question de l'importation des traitements Lr dans dt, fait suite à d'autres précédentes dans lesquels les contributeurs expliquaient que cette partie de code dans dt est ancienne (crop and rotate étant obsolète depuis 2 ans maintenant) et qu'il faut alors se poser la question de la pertinence de maintenir ce code dans la mesure où il faut un abonnement Adobe pour travailler sur les XMPs. J'ai un peu argumenter pour une extraction du code dans une appli externe et un process à la lensfun, les utilisateurs fournissant leurs RAW+XMP Lr, sans grande conviction pour être honnête.

La conclusion me paraît d'autant plus pertinente que c'est ce que j'avais fait en quittant bibble/After Shot Pro pour dt il y a... un bon moment maintenant. 

Aujourd'hui, ayant pris en main dt, quand je revois certains jpeg de l'époque c'est : poubelle direct parce que je ferai bien mieux sans difficulté avec dt. Et pour les quelques épreuves encore acceptables, le JPEG fera la maille.

Citation :Depuis longtemps, je me suis éloigné de Lr et je n'ai pas une grande motivation pour soutenir ce projet, d'autant plus que je ne peux pas expérimenter car je n'ai plus Lr. Mais si quelqu'un vient avec des corrections / améliorations avec le RAW, le Lr XMP et l'aspect qu'il devrait avoir dans Lr, je serai heureux de revoir et d'intégrer les correctifs.

(30-01-24, 10:19)manu a écrit : Bonjour,

Il est plutôt conseillé de s'appuyer sur la documentation la plus récente (*), et quand bien même elle n'est pas encore traduite il est possible de la traduire avec l'excellent deepl.com qui propose même une extension pour les navigateurs Web les plus courants...

Je me méfie des traducteurs automatiques quand il s'agit de textes techniques, mais pourquoi pas, je veux bien réessayer

Concernant Identifiant de la fonction
On est d'accord que la capture d'écran pour illustrer l'IPTC "Identifiant de la fonction" n'est pas prise sur dt ? Je ne connais pas cet affichage...

Oui effectivement, il s'agit d'une capture Lr pour te montrer où je renseigne cette info. Là aussi, si ça pose problème je me débrouillerai autrement, c'est une nouvelle habitude à prendre, c'est tout.

Concernant les synonymes
Dans l'XMP Lr, tous les mots-clés sont du même ordre, rien n'y indique que l'un est un synonyme d'un autre.
Dans dt, les synonymes ne sont pas enregistrés dans l'XMP mais en base...
À ce stade, je ne vois pas comment il serait possible d'automatiser l'import en base de synonymes qu'on ne sait pas identifier dans un XMP Lr source...

J'imagine aisément la complexité sous-jacente de la chose... Je vais me débrouiller autrement. Les collections d'images dans lesquelles j'ai fait un usage abondant de synonymes vont rester dans Lr dans un premier temps. J'avais prévu de remplacer macos 10.13 par une Ubuntu Studio dans mon vieil iMac, ça attendra encore un peu

J'avais déjà poster une réponse à ce message, mais je ne sais pourquoi, elle a disparue. désolé si toutefois elle devait s'afficher en double...

Bonne journée

(*) dans certains logiciels il existe un lien permanent sur la dernière doc, par exemple Nextcloud : https://docs.nextcloud.com/server/latest/user_manual/fr/
Ce lien "latest" est la garantie qu'on tombe bien sur une doc non obsolète. Ce serait bien de faire pareil pour dt.

Citation :En passant, je suis l'auteur de l'aide à la migration vers Lr. Depuis longtemps, je me suis éloigné de Lr et je n'ai pas une grande motivation pour soutenir ce projet, d'autant plus que je ne peux pas expérimenter car je n'ai plus Lr. Mais si quelqu'un vient avec des corrections / améliorations avec le RAW, le Lr XMP et l'aspect qu'il devrait avoir dans Lr, je serai heureux de revoir et d'intégrer les correctifs.