Messages

31

Catalogage et gestion des images / Re : gestion des versions travails et originales

« le: 09 novembre 2011 à 18:55 »

Idem avec Capture NX. Par contre Lr préserve les RAW. Silkypix et Capture One créent un dossier dans le même répertoire que les RAW corrigés. C1 peut aussi les inclure dans un format propriétaire (un zip!) qui inclus RAW et données de traitement. Le format est alors en .eip.

32

Module Développement / Re : Passage en N&B bizarre...

« le: 09 novembre 2011 à 18:23 »

@Lawre51,

Pas de problème

33

Module Développement / Re : Passage en N&B bizarre...

« le: 09 novembre 2011 à 18:22 »

Certain non. C'est issu des discussions que nous avons eu avec Gilles. En tout cas, pour moi Canon ne cherche pas à lire des XMP de traitement sur un Jpeg. Surtout qu'il n'y écrit rien. En tout cas pas avec ses logiciels. Peut être avec les APN qui intègrent des options de retouche...

À vérifier.

Pour Capture One il ne lis rien non plus. C'est certain.

34

Module Développement / Re : Re : Passage en N&B bizarre...

« le: 09 novembre 2011 à 17:58 »

Mais ce qui est intéressante de savoir , c'est pourquoi chez Adobe ça pose problème.

Relis mon intervention. Adobe est le seul à chercher à lire les données XMP de traitement dans l'entête du jpeg. Ce qui pourrait valider la thèse d'une corruption. Des infos s'y trouvent de manière incohérente.

C'est une hypothèse.

35

Catalogage et gestion des images / Re : gestion des versions travails et originales

« le: 09 novembre 2011 à 17:53 »

Oui. Mais c'est vrai avec tous les logiciels sur ce point. C'est aussi logique car chacun possède ses propres algorithmes.

36

Catalogage et gestion des images / Re : gestion des versions travails et originales

« le: 09 novembre 2011 à 17:17 »

Pour le format XMP plus le temps passe plus tout le monde s'accorde à dire qu'il est en passe de devenir un standard...

Concernant ce format il est tt de même reconnu. IView Média Pro le prenait en charge, Bibble aussi. De nombreuses applications de georeferencement y font appel. C'est pas forcément une sauce interne.

37

Catalogage et gestion des images / Re : gestion des versions travails et originales

« le: 09 novembre 2011 à 16:29 »

Enfin, si j'ai bien compris...

38

Catalogage et gestion des images / Re : Re : gestion des versions travails et originales

« le: 09 novembre 2011 à 16:28 »

Je sais même pas ce que sont les fichiers side car.
L'intérêt, c'est que l'aspect visuel de l'image d'origine n'est pas modifié. Et c'est, je crois, le principe de base de LR. Ne pas modifier l'original...

Oui, mais...

Là où vous n'êtes pas sur la même longueur d'onde, c'est que pour que le Jpeg ne soit pas modifié physiquement, c'est à dire qu'il n'y ait aucune nouvelle sauvegarde du Jpeg, il faut décocher la case Inclure les données de développement... dans le panneau des préférences du catalogue. Si tu ne fais pas ça, Lr sauvegarde les XMp correspondant aux développement dans la partie du Jpeg réservé à cet effet. Il y a donc bien une nouvelle sauvegarde. Ce que craint lawre51 c'est que cette opération vienne à corrompre le Jpeg d'origine. Toi, tu penses qu'il ne touche à rien car la date que tu vois dans ton explorateur correspond à la date de création du fichier et non pas à la date de la dernière modification.

Pour Adobe :
 - un fichier original est un Raw. Là, jamais Lr n'y touche. Soit il écrit les données de développement dans le catalogue, soit il le fait en plus (en plus ou à la place ? me souviens plus) dans un fichier supplémentaire en .xmp.
 - un fichiir Jpeg, Tif... n'est pas considéré à proprement parlé comme un original. Soit Lr écrit les données dans le catalogue, soit en Xmp. A la différence du Raw, il ne crée pas un nouveau fichier mais se sert de l'entête du Jpeg (ou tiff) prévu à cet effet. Donc, il y a bien un nouvel enregistrement. C'est là, que lawre51 se demande si justement ce n'est pas risqué et voudrait qu'un Jpeg soit traité comme un RAW avec un fichier Xmp annexé et non pas des données embarquées.

39

Module Développement / Re : Re : Passage en N&B bizarre...

« le: 09 novembre 2011 à 11:13 »

Oui c'est la seule du lot. Celles juste avant ou juste après ne présente pas ce défaut.

Ceci dit, je veux bien croire à une corruption des métadonnées (je pense plutôt que ce ne sont pas les métadonnées qui sont corrompues mais plutôt les données de l'image elle-même) mais cela n'explique pas complètement pourquoi lors du passage en N&B par Lr, toutes les informations de couleur ne disparaissent pas.

Ben, on en a discuté avec Gilles, sa théorie n'est pas fausse. Lr enregistre (selon les préférences) les corrections du module développement dans l'entête des Jpeg réservé aux XMP. Cela a pour avantage de pouvoir lire les corrections faites avec Lr à partir d'un autre ordinateur ou ACR (selon la compatibilité).

Là, il faudrait voir dans ces méta si le fichier n'est pas corrompu ou si Canon n'utiliserait pas un tag équivalent à celui d'Adobe concernant la balance des blancs...

Comme me le rappelait Gilles, Lr lit ces données ; pas forcément les autres softs puisqu’ils n'en n'ont pas besoin.

En y réfléchissant, je ne pense pas à un champs commun entre Canon et Lr, mais effectivement à une corruption des métas (comme le relève brillament Gilles), surtout si ce n'est pas reproductible avec un autre Jpeg issu de la même série.

Que quelqu'un m'arrête si je fais fausse route

40

Module Développement / Re : Re : Passage en N&B bizarre...

« le: 09 novembre 2011 à 11:05 »

La 3.6 ne risque pas de corriger le problème vu qu'il n'y a pas de changements au niveau lecture des Métadonnées de développement.

Il y a visiblement un problème de corruption des métadonnées, mais cette image est-elle la seule a être affectée ?

Pas évident à savoir à la lecture de la fiche technique de la release

41

Module Développement / Re : Passage en N&B bizarre...

« le: 09 novembre 2011 à 08:00 »

Bon, la 3.6 ne règle pas le problème. 

42

Actualités Lightroom / Re : Lightroom 3.6 et ACR en Release

« le: 09 novembre 2011 à 07:55 »

Bien ça

43

Actualités Lightroom / Lightroom 3.6 et ACR en Release

« le: 09 novembre 2011 à 06:44 »

Voilà, l'info est ici et bientôt traduite sur Ulr.

http://blogs.adobe.com/lightroomjournal/2011/11/lightroom-3-6-and-camera-raw-6-6-available-on-adobe-labsoe.html

44

Module Développement / Re : Passage en N&B bizarre...

« le: 06 novembre 2011 à 11:59 »

Héhé, un petit bug pour Gilles alors

C'est comme s'i on avait à faire a une balance des blancs sélective. Bon, sur un Raw, on se dirait que c'est de la bidouille du constructeur, mais là, sur un Jpeg... On a véritablement l'impression d'avoir à faire à un filtre.

Testé aussi avec Capture One : c'est OK. Pas de dominante.

Donc, Lr est capable ou cherche à lire quelque chose sans arriver à l'interpréter correctement.

Quelqu'un a cherché à explorer les métas avec iDimager (il semble en lire beaucoup !) ?

45

Module Développement / Re : De Capturenx à Lightroom, migration presque faite mais...

« le: 21 octobre 2011 à 14:59 »

@ Rapetout,

Attention aussi à ne pas te faire leurrer par l'affichage de Nx. Le visualiseur de Lightroom est beaucoup moins piqué que Nx. A la différence de Nx, Lightroom apporte une accentuation finale lors de l'exportation.

Cet ajout de netteté se fait en tout dernier et en fonction du support et de la taille de l'image finale. En conclusion, il ne faut pas comparer la netteté des 2 rendus via leur propre table lumineuse, mais effectuer la comparaison dans un logiciel neutre. Alors, bien souvent on se trouve vraiment très proche. tellement proche que ça ne justifie pas de perdre trop de temps sur ce point.

A voir comment tu pratiques