Sortie de PhotoLab 8 : les nouveautés

Démarré par gerarto, Septembre 17, 2024, 15:00:01

« précédent - suivant »
Imprimer
En bas Pages 1 2 3 4 5 6 7 8 9 10
Actions de l'utilisateur

Zaphod

#175
Octobre 01, 2024, 15:16:37
Oui je ne vois pas trop ce qui justifie un format propriétaire ici...
Tout ce qui est métadonnées doit être lisible par tous les autres softs.
Tout ce qui est réglage est mis avec une balise spécifique et ignoré par les autres softs, donc c'est quand même idéal...

gerarto

#176
Octobre 01, 2024, 15:53:03
Citation de: Dub le Octobre 01, 2024, 14:37:00Sauf que le standard (qu'on le veuille ou non  ;D  ), c'est le XMP...

https://www.iptc.org/std/photometadata/specification/IPTC-PhotoMetadata

 ::)

Heu... il y aurait un standard universel pour enregistrer les réglages "propriétaires" d'un logiciel ?
Avec la foultitude de cas possibles, ce serait une belle usine à gaz ! 

Un .dop, c'est fait pour ça en ce qui concerne PhotoLab,
pour les métadonnées, dont les IPTC, DxO utilise la norme en créant un .xmp standard lisible par tout logiciel. 

Dub

#177
Octobre 01, 2024, 16:44:31
Citation de: gerarto le Octobre 01, 2024, 15:53:03Heu... il y aurait un standard universel pour enregistrer les réglages "propriétaires" d'un logiciel ?
Avec la foultitude de cas possibles, ce serait une belle usine à gaz ! 

Et oui, le XMP est fait pour... chaque logiciel peut y écrire ses données...

Exemple, avec Adobe, Iview, Photomechanic, Idimager...:

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
  <rdf:Description rdf:about=""
    xmlns:dc="http://purl.org/dc/elements/1.1/"
    xmlns:aux="http://ns.adobe.com/exif/1.0/aux/"
    xmlns:xmp="http://ns.adobe.com/xap/1.0/"
    xmlns:exif="http://ns.adobe.com/exif/1.0/"
    xmlns:tiff="http://ns.adobe.com/tiff/1.0/"
    xmlns:xmpMM="http://ns.adobe.com/xap/1.0/mm/"
    xmlns:stEvt="http://ns.adobe.com/xap/1.0/sType/ResourceEvent#"
    xmlns:photoshop="http://ns.adobe.com/photoshop/1.0/"
    xmlns:MicrosoftPhoto="http://ns.microsoft.com/photo/1.0"
    xmlns:Iptc4xmpExt="http://iptc.org/std/Iptc4xmpExt/2008-02-29/"
    xmlns:ics="http://ns.idimager.com/ics/1.0/"
    xmlns:expressionmedia="http://ns.microsoft.com/expressionmedia/1.0/"
    xmlns:mediapro="http://ns.iview-multimedia.com/mediapro/1.0/"
    xmlns:photomechanic="http://ns.camerabits.com/photomechanic/1.0/"
    xmlns:crd="http://ns.adobe.com/camera-raw-defaults/1.0/"
    xmlns:xmpRights="http://ns.adobe.com/xap/1.0/rights/"
    xmlns:Iptc4xmpCore="http://iptc.org/std/Iptc4xmpCore/1.0/xmlns/"
    xmlns:xmpDM="http://ns.adobe.com/xmp/1.0/DynamicMedia/"
    xmlns:crs="http://ns.adobe.com/camera-raw-settings/1.0/"
    xmlns:lr="http://ns.adobe.com/lightroom/1.0/"

doppelganger

#178
Octobre 01, 2024, 16:57:11
Citation de: Dub le Octobre 01, 2024, 16:44:31Et oui, le XMP est fait pour... chaque logiciel peut y écrire ses données...

Ben non. Dans le cas de données propriétaires type informations de post-traitement, liées à un logiciel et à lui-seul (ou une suite logiciel), le XMP n'a aucun intérêt voir même, peut être inadapté.

Pieloe

#179
Octobre 01, 2024, 20:16:29 Dernière édition: Octobre 01, 2024, 20:22:30 par Pieloe
Citation de: Dub le Octobre 01, 2024, 14:37:00Sauf que le standard (qu'on le veuille ou non  ;D  ), c'est le XMP.

XMP est un conteneur universel dans la forme des champs.
A ma connaissance, seules les balises de méta-données de Lr sont partagées. Elles sont devenues un standard de fait.

Samoreen

#180
Octobre 01, 2024, 22:39:38
Citation de: Pieloe le Octobre 01, 2024, 20:16:29XMP est un conteneur universel dans la forme des champs.

C'est du XML. L'avantage, c'est que ça peut être lu et modifié par n'importe quelle application tierce incluant un parseur XML. Les balises utilisées sont la plupart du temps autodescriptives. On peut donc imaginer des applis tierces permettant de gérer certaines infos depuis l'extérieur.

Mieux. Une application tierce peut stocker ses propres infos dans un fichier XMP, avec ses propres balises, sans que cela gêne le moins du monde le fonctionnement de LR ou de Camera RAW.
Patrick

Zaphod

#181
Octobre 01, 2024, 22:58:20
Citation de: doppelganger le Octobre 01, 2024, 16:57:11Ben non. Dans le cas de données propriétaires type informations de post-traitement, liées à un logiciel et à lui-seul (ou une suite logiciel), le XMP n'a aucun intérêt voir même, peut être inadapté.
L'intérêt c'est d'avoir un seul fichier sidecar lu par plein de logiciels.
Chaque logiciel peut ajouter ses champs (type "exposition +1.0") sans perturber les paramètres des autres logiciels.

D'ailleurs Photolab est tout à fait capable de lire les réglages de Ligthroom, par exemple, et de les réintégrer dans le DNG qu'il génère.
(Il supprime la correction du bruit par exemple, mais reprend quasi tout le reste).
Donc quand tu récupères le dng de dxo dans lightroom les réglages sont conservés.
Photolab n'a pas eu à comprendre les réglages mais juste à les recopier.

Autre avantage : si tu bouges un fichier (ou que tu le renomme) avec n'importe quel soft pas trop con, le xmp bougera avec, alors que le .dop sera oublié.

Verso92

#182
Octobre 01, 2024, 23:33:39
Citation de: Zaphod le Octobre 01, 2024, 22:58:20L'intérêt c'est d'avoir un seul fichier sidecar lu par plein de logiciels.
Chaque logiciel peut ajouter ses champs (type "exposition +1.0") sans perturber les paramètres des autres logiciels.

D'ailleurs Photolab est tout à fait capable de lire les réglages de Ligthroom, par exemple, et de les réintégrer dans le DNG qu'il génère.
(Il supprime la correction du bruit par exemple, mais reprend quasi tout le reste).
Donc quand tu récupères le dng de dxo dans lightroom les réglages sont conservés.
Photolab n'a pas eu à comprendre les réglages mais juste à les recopier.

Autre avantage : si tu bouges un fichier (ou que tu le renomme) avec n'importe quel soft pas trop con, le xmp bougera avec, alors que le .dop sera oublié.

En vous lisant, je constate juste qu'on a chacun notre propre façon de procéder...  ;-)

Phi19

#183
Octobre 02, 2024, 08:25:08
Je viens de passer de la v6 à la v8, quand j'ouvre un raw je trouve une colorimétrie bien différente, moins belle, trop flaschi....avez vous remarqué ça ?

Bjfr137

#184
Octobre 02, 2024, 08:29:00
Je pense que le prêréglage par défaut n'est pas le même.
Jean-François

PBnet2

#185
Octobre 02, 2024, 08:38:44
Citation de: Phi19 le Octobre 02, 2024, 08:25:08Je viens de passer de la v6 à la v8, quand j'ouvre un raw je trouve une colorimétrie bien différente, moins belle, trop flaschi....avez vous remarqué ça ?

oui idem en standart

Phi19

#186
Octobre 02, 2024, 08:46:02
Idem......t'as le même soucis ?
Comment virer ça ?

ccaphotographies

#187
Octobre 02, 2024, 09:21:50
Il faudra que je vérifie car je n'y avais pas preté attention. Il faut dire que par défaut quand j'importe un raw je limite les pré traitements aux modules de correction optiques déformation et flou... donc la colorimetrie n'est pas touchée....

Phi19

#188
Octobre 02, 2024, 09:31:38
Si je regarde mes sujets ils ont les joues roses c'est vraiment laid

Phi19

#189
Octobre 02, 2024, 09:39:48
Je pense avoir trouvé: dans rendu couleur/N&B faut choisir Profil de boîtier DXO (canon eos R3)

gerarto

#190
Octobre 02, 2024, 11:00:20 Dernière édition: Octobre 02, 2024, 11:08:40 par gerarto
Citation de: Dub le Octobre 01, 2024, 16:44:31Et oui, le XMP est fait pour... chaque logiciel peut y écrire ses données...

Exemple, avec Adobe, Iview, Photomechanic, Idimager...:

...

Qu'Adobe y écrive ses données, vu qu'il est partie prenante dans la norme n'est pas un scoop !
Qu'un éditeur tiers puisse y écrire ses propres réglages, c'est possible... mais est-ce souhaitaible pour lui ?

Ceux que tu cites sont plutôt des logiciels de gestion d'actifs, qui utilisent/modifient surtout des métadonnées.

Je vois mal un éditeur majeur de traitement des raw (sauf Adobe...) passer par un processus dont ils ne sont pas maîtres.
Pour les métadonnées, PhotoLab utilise bien la norme xmp en produisant des fichiers .xml lisibles par les autres logiciels. Donc où est le problème ?
Et puis celui qui est contre les fichiers .dop a toujours la solution de ne pas les faire créer et faire confiance à la base de données de DxO ! (bon, à ses risques et périls) 

rsp

#191
Octobre 02, 2024, 11:26:52
Citation de: ccaphotographies le Octobre 02, 2024, 09:21:50Il faudra que je vérifie car je n'y avais pas preté attention. Il faut dire que par défaut quand j'importe un raw je limite les pré traitements aux modules de correction optiques déformation et flou... donc la colorimetrie n'est pas touchée....
Il y a toujours application d'un profil couleur.

ccaphotographies

#192
Octobre 02, 2024, 12:51:46
ben oui mais sur mes écrans tous calibrés aux petits oignons, je n'ai rien qui m'ait sauté aux yeux sur mes derniers traitements.. Suis sur des macs M1 ; un pb avec d'autres cartes graphiques ?

Zaphod

#193
Octobre 02, 2024, 13:34:30
Citation de: gerarto le Octobre 02, 2024, 11:00:20Qu'un éditeur tiers puisse y écrire ses propres réglages, c'est possible... mais est-ce souhaitaible pour lui ?
C'est souhaitable pour l'utilisateur, donc indirectement pour l'éditeur :)

Citation de: gerarto le Octobre 02, 2024, 11:00:20Je vois mal un éditeur majeur de traitement des raw (sauf Adobe...) passer par un processus dont ils ne sont pas maîtres.
Des fichiers XML tu en as partout et pas uniquement en photo... de quoi n'es-tu pas maitre quand tu enregistre des données dans un fichier XML ?

Citation de: gerarto le Octobre 02, 2024, 11:00:20Pour les métadonnées, PhotoLab utilise bien la norme xmp en produisant des fichiers .xml lisibles par les autres logiciels. Donc où est le problème ?
Que devient le DOP si tu renommes le fichier ou que tu le déplaces depuis ton autre logiciel ?

Citation de: gerarto le Octobre 02, 2024, 11:00:20Et puis celui qui est contre les fichiers .dop a toujours la solution de ne pas les faire créer et faire confiance à la base de données de DxO ! (bon, à ses risques et périls)
LOL, c'est pas un truc qui me viendrait à l'esprit.

Après pour Photolab de toute façons les DOP sont des fichiers "jetables".
Si tu changes de versions les réglages ne sont plus appliqués de la même façon, donc ça n'a pas d'intérêt de les garder sur le long terme.

doppelganger

#194
Octobre 02, 2024, 13:37:01
Citation de: Zaphod le Octobre 01, 2024, 22:58:20L'intérêt c'est d'avoir un seul fichier sidecar lu par plein de logiciels.

En avoir un ou deux (ou 15) ne change rien. Dans le cas de la suite DxO, les données contenues dans un .dop n'on pas vocation à être manipuler par un tiers. Ou bien, c'est acté et dans ce cas, ce dernier saura en faire bon usage. Encore faut-il en trouver l'utilité (ou autrement dit, identifier le use case).

Citation de: Zaphod le Octobre 01, 2024, 22:58:20Chaque logiciel peut ajouter ses champs (type "exposition +1.0") sans perturber les paramètres des autres logiciels.

D'ailleurs Photolab est tout à fait capable de lire les réglages de Ligthroom, par exemple, et de les réintégrer dans le DNG qu'il génère.
(Il supprime la correction du bruit par exemple, mais reprend quasi tout le reste).
Donc quand tu récupères le dng de dxo dans lightroom les réglages sont conservés.
Photolab n'a pas eu à comprendre les réglages mais juste à les recopier.

C'est le but du format XMP : permettre l'interopérabilité. En revanche, tout ce qui concerne la tambouille interne d'un logiciel ne devrait pas se retrouver dedans. Autrement, c'est donner la possibilité à un logiciel tiers de les manipuler et d'en faire n'importe quoi, y compris de les supprimer ou de les modifier. Un éditeur (DxO ou un autre) n'a absolument aucun intérêt à agir de la sorte, au contraire.

Et encore une fois, le format XMP n'est pas forcément le plus adapté. Quand je vois ça, par exemple, ça parait évident :


0458 436f 6ec0 4206 beba feca 0002 0454
5950 45c0 000f 4361 7074 7572 654f 6e65
204d 6173 6bfe 1803 5645 5200 0002 0300
fe0a ffff 084d 6173 6b49 6e66 6f00 2200
0348 6472 0022 ff18 0100 0000 4020 0000
8015 0000 0c00 0000 0000 0000 0000 0000
fe21 ffff 094d 6173 6b49 6e64 6578 0022
ffff ff04 0000 0000 0855 7365 7249 6e66
6f00 2200 0449 6e66 6f00 2224 3734 6137
3439 6562 2d33 3565 642d 3462 6239 2d38
3465 332d 3066 3064 6433 3633 3763 6330
fe2d ffff 044e 616d 6500 2200 fe09 fe41
47ff ffff 084d 6173 6b54 7970 6500 2204
0000 0000 fe11 ffff 0943 6f6d 7050 6172
616d 0022 ffff ff10 0100 0000 0000 803f
0000 0000 0000 0000 fe21 fe42 57fe 434a
0342 6c6b 0022 00ff 0348 6472 0022 ff10
0000 0000 0000 0000 0000 0000 0000 0000
fe19 ffff 0349 6478 0022 00fe 0803 6461
7400 0000 fe08 fe37 fe44 79


Citation de: Zaphod le Octobre 01, 2024, 22:58:20Autre avantage : si tu bouges un fichier (ou que tu le renomme) avec n'importe quel soft pas trop con, le xmp bougera avec, alors que le .dop sera oublié.

Il ne me viendrai pas à l'idée de bouger un fichier avec un logiciel autre que celui qui a servi au post-traitement.

doppelganger

#195
Octobre 02, 2024, 13:45:18
Citation de: Zaphod le Octobre 02, 2024, 13:34:30C'est souhaitable pour l'utilisateur, donc indirectement pour l'éditeur :)

Ni pour l'un, ni pour l'autre. Si je prends l'exemple des masques et autres calques dans C1, on n'est plus dans le simple texte lisible par un humain, comme des mots clés, un lieu, ou autres données IPTC.
 
Citation de: Zaphod le Octobre 02, 2024, 13:34:30Que devient le DOP si tu renommes le fichier ou que tu le déplaces depuis ton autre logiciel ?

Quand je déplace un fichier RAW depuis le finder, le XMP ne suit pas comme par magie ;)

Zaphod

#196
Octobre 02, 2024, 14:13:26
Citation de: doppelganger le Octobre 02, 2024, 13:37:01Il ne me viendrai pas à l'idée de bouger un fichier avec un logiciel autre que celui qui a servi au post-traitement.
Moi ça ne me viendrait pas à l'idée de gérer mes fichiers depuis Photolab  ;D
Déjà il ne gère pas tous les RAW donc ça ne pourrait pas me servir de bibliothèque même si j'abandonnais Ligthroom.

Samoreen

#197
Octobre 02, 2024, 14:43:24
Citation de: gerarto le Octobre 02, 2024, 11:00:20Qu'un éditeur tiers puisse y écrire ses propres réglages, c'est possible... mais est-ce souhaitaible pour lui ?
Je vois mal un éditeur majeur de traitement des raw (sauf Adobe...) passer par un processus dont ils ne sont pas maîtres.

La norme XML est universelle et neutre et offre l'avantage de l'interopérabilité sinon de la performance. Chaque équipe de développement décide en fonction de ses objectifs s'il est intéressant ou pas de l'utiliser. XMP est disons, une sous-norme ou plutôt, pour être rigoureux, un vocabulaire XML orienté photo. Un vocabulaire XML définit le nom des balises, leur hiérarchie et le type du contenu de chaque balise. Il existe des centaines de vocabulaires XML, standardisés ou pas.

Citation de: gerarto le Octobre 02, 2024, 11:00:20Pour les métadonnées, PhotoLab utilise bien la norme xmp en produisant des fichiers .xml lisibles par les autres logiciels.

Photolab produit des fichiers XMP uniquement si l'option de synchronisation XMP est activée. Les fichiers DOP ne sont pas des fichiers XML mais des fichiers JSON (enfin presque parce qu'ils ne passent jamais les tests de validation, ce qui peut empêcher une application tierce de les lire). JSON est une spécification ayant des objectifs similaires à la spécification XML. On peut s'interroger sur ce choix alors que le format XML est plutôt la norme en matière de photo. Il aurait été plus souple de définir un sous-vocabulaire XMP spécifique à Photolab.

======================

Par ailleurs, je crois qu'il y a une confusion qui persiste chez certains entre la notion de format et la notion d'interprétation du contenu.

Entre 2 balises XML (balise d'ouvertue et balise de clôture), on peut mettre des données de toutes natures, y compris du binaire, à condition que ce soit sous forme de texte (voir exemple ci-dessus). Ce que la norme garantit, c'est que n'importe quelle application peut lire et récupérer contenu et attributs d'une balise donnée. Les développeurs n'ont pas à développer de code pour lire ou écrire dans un fichier XML : des bibliothèques implémentant des parseurs XML sont disponibles dans à peu près tous les langages.

Par contre, le sens du contenu de cette balise ou de ses attributs et la manière dont ils peuvent être interprétés ne sont pas documentés dans le fichier XML mais dans la spécification du vocabulaire XML utilisé (si elle existe, publique ou pas). Pour certaines balises auto-explicatives, la signification du contenu est évidente (encore faut-il se méfier) : par exemple l'attribut exif:ExposureTime="1/125" est auto-explicatif, pour d'autres balises ou attributs, seule l'application qui l'a créée sait ce que le contenu signifie. Par exemple seul Lightroom sait ce que crs:Shadows2012="+82" représente exactement et comment utiliser cette valeur pendant le traitement.
Patrick

doppelganger

#198
Octobre 02, 2024, 15:50:09
Citation de: Zaphod le Octobre 02, 2024, 14:13:26Moi ça ne me viendrait pas à l'idée de gérer mes fichiers depuis Photolab  ;D
Déjà il ne gère pas tous les RAW donc ça ne pourrait pas me servir de bibliothèque même si j'abandonnais Ligthroom.

Ok dans un contexte comme celui-là. Pour ma part, avec C1, j'ai tout intérêt à manipuler les fichiers depuis C1. Un glissé / déplacé d'un RAW et tout le reste suit avec.

doppelganger

#199
Octobre 02, 2024, 15:56:07
Citation de: Samoreen le Octobre 02, 2024, 14:43:24Photolab produit des fichiers XMP uniquement si l'option de synchronisation XMP est activée. Les fichiers DOP ne sont pas des fichiers XML mais des fichiers JSON (enfin presque parce qu'ils ne passent jamais les tests de validation, ce qui peut empêcher une application tierce de les lire). JSON est une spécification ayant des objectifs similaires à la spécification XML. On peut s'interroger sur ce choix alors que le format XML est plutôt la norme en matière de photo. Il aurait été plus souple de définir un sous-vocabulaire XMP spécifique à Photolab.

Le monde de la photo est ce qu'il est. Le fait est que dans l'industrie logiciel, le XML est abandonné au profit du format JSON, qui n'a que des avantages, face au premier. On ne peut que se réjouir de ce choix.
Imprimer
En haut Pages 1 2 3 4 5 6 7 8 9 10
Actions de l'utilisateur