Import XMP intégré au fichier

[manu]

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.

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.

[zakfm]

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.

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.

[Cobert]

Bonjour,
Si le souci est la correction de tache, chronophage, on peut peut-être exporter dans Lr la photo traitée dans un format sans perte (tiff 16, png), et continuer sur dt avec le fichier ?
cdlt

[manu]

Pour qui serait concerné⋅e par une migration Lr - dt (bienvenue !) et dispose de RAWs et d'XMPs Lr (ce qui n'est pas le cas ici puisque TIFF), la porte n'est pas fermée et l'auteur du code de migration dans dt indique sur l'issue :

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.

À ce stade, je passe la main et ça se passe donc directement ici. 

[fjoncour]

Bonsoir à toutes et à tous,
Je suis ravi de voir que d'autres personnes se jointes à la discussion. DT est un choix de cœur que j'ai fait depuis des années déjà même si je ne l'adopte que maintenant. Je n'ai pas choisi DT par défaut, faute de mieux, non, c'est un vrai choix que j'ai fait, sur des considérations techniques (et éthiques aussi).
Passer de Lr à DT est vraie une joie pour moi, mais aussi je ne peux le nier, une source de stress parce que je ne peux m'arrêter de produire des images pour prendre le temps de le maîtriser à minima (pour le catalogage c'est ok).
Concernant la récupération de mes réglages de dév de Lr -> DT, je me suis fié à ce qui est écrit dans la doc DT 3.8 (en français). J'aurai dû savoir que certains de ces modules étaient dépréciés, mais je ne le savais pas...
J'ai une série de photographies n/b qui est en cours, je vais la finir tranquillement avec Lr. Comme je reviens sans cesse sur mes créations, celle-ci va rester dans mon vieil iMac dans un premier temps. Tout le reste passe sous DT (nouveau PC) parce que oui, j'ai bien remarqué les qualités intrinsèques de DT et qu'il me tarde de me sentir plus à l'aise avec cet outil.

@Manu, je vais te glisser une capture d'écran pour que tu comprennes de quoi il ressort à propos du champ IPTC "Identifiant de la fonction". Si ça peut être implémenté c'est génial, sinon je me débrouillerai.
Sur ta capture d'écran des mots-clés que tu as glissé dans un précédent message, le mot-clé "photographic" est un synonyme de "photographie", il n'a rien à faire à la racine des mots-clés. Je suppose que c'est l'export Lr qui merde ou que d'une manière ou d'une autre tout fini par se mélanger. Normalement, le mot-clé "photographic" devrait apparaître dans le champ "synonymes" du mot-clé "photographie" quand tu l'édites et pas à la racine avec les autres mots-clés. Là aussi c'est un détail, mais c'est un détail qui tue pour un certain nombre de mes images. Pareil, ces dernières vont rester dans Lr dans un premier temps.

Demain matin j'ai une longue série de reproduction de peintures (photographiées aujourd'hui pour un Musée) à traiter dans DT. La nuit va être agitée, parce qu'ils m'ont mis une sacrée pression pour le résultat (à rendre pour midi) et qu'en plus cela conditionne sérieusement mes revenus du mois de février (je fais pas mal de catalogues d'expos)...

Bonne soirée à toutes et à tous et merci de votre aide.
Frédéric

---

Voilà pour le champ IPTC "Identifiant de la fonction". "ho mon bateau" c'est de l'humour, je n'ai pas de série intitulée ainsi
Bonne soirée

[manu]

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

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

J'ai identifié que "Identifiant de la fonction" est le champ IPTC "Original Transmission Reference". Rien trouvé sur ce champs concernant dt. Là aussi, il faudra éventuellement poser la question aux devs...

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.
Par exemple :

Code :

  <dc:subject>
    <rdf:Bag>
    <rdf:li>photo</rdf:li>
    <rdf:li>photographic</rdf:li>
    <rdf:li>photographie</rdf:li>
    <rdf:li>photographique</rdf:li>
    <rdf:li>photography</rdf:li>
    <rdf:li>prise de vue</rdf:li>
    <rdf:li>prise de vue photo</rdf:li>
    <rdf:li>shooting</rdf:li>
    <rdf:li>shooting photo</rdf:li>
    <rdf:li>visual</rdf:li>
    <rdf:li>visuel</rdf:li>
    </rdf:Bag>
  </dc:subject>

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

(*) dans certains logiciels il existe un lien permanent sur la dernière doc, par exemple Nextcloud : https://docs.nextcloud.com/server/latest...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.

[fjoncour]

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

[manu]

Attention, répondre dans la zone de texte du précédent interlocuteur n'est pas pratique pour la lecture et pour la suite des échanges...