TIFF, JPEG et .xmp

[lac]

Bonjour,

Y a t'il un moyen de forcer lightroom 3 a écrire des fichiers XMP pour les TIFF, PSD et JPG comme pour les fichier RAW.

Cordialement

[Olivier Chauvignat]

Bonjour,

Y a t'il un moyen de forcer lightroom 3 a écrire des fichiers XMP pour les TIFF, PSD et JPG comme pour les fichier RAW.

Cordialement

Non.

[Pat91]

Non.

Mais on peut demander à Lightroom via les Préférences du catalogue, d'insérer systématiquement les réglages de développement dans les métadonnées du TIFF, du JPEG ou du PSD. Ce n'est pas tout à fait la même chose mais cela signifie que l'on peut transporter le fichier en question vers une autre machine tournant Lightroom et récupérer les réglages.

[THG]

Mais on peut demander à Lightroom via les Préférences du catalogue, d'insérer systématiquement les réglages de développement dans les métadonnées du TIFF, du JPEG ou du PSD. Ce n'est pas tout à fait la même chose mais cela signifie que l'on peut transporter le fichier en question vers une autre machine tournant Lightroom et récupérer les réglages.

Très juste.

[Olivier Chauvignat]

comme il parlait bien de fichiers xmp et non de métadonnées, j'ai répondu en conséquence

[THG]

comme il parlait bien de fichiers xmp et non de métadonnées, j'ai répondu en conséquence

en fait, le problème c'est qu'on assimile le XMP à un fichier, alors qu'il s'agit d'un format.

[Olivier Chauvignat]

en fait, le problème c'est qu'on assimile le XMP à un fichier, alors qu'il s'agit d'un format.

Oui sauf lorsque tu spécifies bien "fichier" (fichier au format xmp), auquel cas on parle bien de l'objet informatique

[lac]

Effectivement, je cherche a synchroniser deux catalogue lightroom car j'ai perdu quelques mot clefs entre deux sauvegardes.

pour les RAW, c'est simple : il suffit de générer les fichiers avec l'extension .xmp et de les recopiers.

Pour les TIFF, JPEG,... et j'espérais pouvoir utiliser la même procédure sans avoir à modifier toutes mes images ce qui peut s'avérer assez lourd car je devrais resynchroniser toutes les sauvegardes.

Cordialement

[Pat91]

en fait, le problème c'est qu'on assimile le XMP à un fichier, alors qu'il s'agit d'un format.

Pour être très précis, XMP est un des très nombreux "vocabulaires XML". XML est la norme générique permettant de définir des fichiers de données texte auto-descriptifs via un langage à balises (comme XHTML par exemple - HTML n'étant pas conforme à la norme XML). Ce langage à balises doit répondre à certaines normes générales. Mais XML ne décrit pas les balises elles-mêmes. C'est le rôle des "vocabulaires" XML qui décrivent chacun un jeu de balises spécifiques à un type de données particulier :

- XMP décrit les balises spécifiques à la description d'une image et des traitements qui lui sont appliqués
- XHTML définit les balises à utiliser dans une page Web
- SVG définit les balises décrivant une image vectorielle 2D
- etc.

Tous ces vocabulaires sont conformes à la norme XML mais chacun décrit des types de données particuliers. Cependant, comme il s'agit toujours de texte, on ne parle pas vraiment de format, appellation qui est plutôt réservée aux fichiers binaires.

Un des gros avantages de cette approche, c'est que quel que soit le vocabulaire XML utilisé, les outils de manipulation des fichiers XML restent les mêmes. Un programmeur utilisera les mêmes outils pour aller chercher ou écrire des données dans un fichier XMP, dans un fichier XHTML ou SVG. De même, l'absence de notion de format (tous les fichiers XML sont structurés de la même manière) permet à n'importe quelle application d'aller chercher des infos (ou d'en insérer) dans un fichier XML sans avoir besoin d'obtenir la description d'un format particulier. Les balises portant en général des noms suffisamment explicites, n'importe qui peut aller chercher des infos dans un fichier XML quel que soit son type.

Notons enfin que si la norme XML est maintenant largement adoptée (lisibilité, universalité, portabilité,...) pour de nombreux types de données, elle présente un inconvénient majeur : l'insertion, la récupération, l'analyse et la recherche de données dans un fichier texte de type XML est de loin beaucoup plus lente que dans un fichier binaire. Ce qui explique que dans LR, si la mise à jour automatique des fichiers XMP est activée et si on multiplie les retouches locales avec des masques de taille importante, l'impact sur les performances est immédiat. Il n'y a qu'à ouvrir avec Notepad un fichier XMP correspondant à une image ayant subi de nombreuses retouches locales dans LR pour se rendre compte des dégâts.

[Zaphod]

Mais on peut demander à Lightroom via les Préférences du catalogue, d'insérer systématiquement les réglages de développement dans les métadonnées du TIFF, du JPEG ou du PSD. Ce n'est pas tout à fait la même chose mais cela signifie que l'on peut transporter le fichier en question vers une autre machine tournant Lightroom et récupérer les réglages.

Avec comme d'hab les limitations d'usage :
- les copies virtuelles ne sont pas dans les données XMP
- l'historique et les instantanés non plus

Attention donc, le XMP a un aspect pratique et peut servir de sauvetage mais ça ne remplace pas une sauvegarde de catalogue.

[SimCI]

Ca peut toujours servir (cas d'archivage contractuel ou ...maniaque):

on peut exporter chaque copie virtuelle en mode "original"

A ma connaissance
cette copie se comporte comme un original traite par LR.
Pas besoin du catalogue associe.

Je ne crois pas qu'on puisse les recoller a nouveau.

[THG]

Attention donc, le XMP a un aspect pratique et peut servir de sauvetage mais ça ne remplace pas une sauvegarde de catalogue.

Moi je présente ça comme un 2e étage de sauvegarde en plus de la sauvegarde du catalogue. Et c'est bien pour cela que je préconise d'activer l'écriture automatique.

Le fait de sauvegarder l'historique dans le fichier annexe ne présente à mes yeux guère d'intérêt, sachant que les réglages sont réversibles dans une autre session de Lr, et les copies virtuelles sont liées au catalogue. D'autre part, les copies virtuelles sont exportables comme des fichiers normaux, en conservant la réversibilité des réglages, je ne vois donc aucune raison d'encombrer le sidecar.

[THG]

Eh bien, post vu 282 fois et seulement une demie-douzaine d'entre vous ont accepté de mouiller la chemise.

Il s'agit tout simplement de l'avertissement de texte trop long dans une cellule texte du livre photo !

[at] + pour un autre Kouize :-)

[Eric01]

Eh bien, post vu 282 fois et seulement une demie-douzaine d'entre vous ont accepté de mouiller la chemise.

Il s'agit tout simplement de l'avertissement de texte trop long dans une cellule texte du livre photo !

[at] + pour un autre Kouize :-)

Tu t'es pas trompé de post là ?

[THG]

Tu t'es pas trompé de post là ?

ouch, toutes mes excuses

[Zaphod]

Le fait de sauvegarder l'historique dans le fichier annexe ne présente à mes yeux guère d'intérêt, sachant que les réglages sont réversibles dans une autre session de Lr

Je ne dis pas que ça manque, je dis que c'est absent.
C'est juste pour clarifier que le catalogue est beaucoup plus que la somme des XMP.

D'autre part, les copies virtuelles sont exportables comme des fichiers normaux, en conservant la réversibilité des réglages, je ne vois donc aucune raison d'encombrer le sidecar.

Là par contre, ça devrait y être.
L'intérêt des copies virtuelles c'est justement ne de pas dupliquer les fichiers.
S'il faut exporter le fichier normal plusieurs fois... c'est quand même dommage.