DxO présente PhotoLab 5

[Zaphod]

Il y a toujours eu des remises sur les mises à jour au black friday, jusqu'ici.
Remise moindre que sur la version complète, c'est du genre 60 euros au lieu de 89 d'habitude.

[Dub]

Ben c'est là qu'est l'intérêt 
Le codage hiérarchique uttilisé est celui de LR, donc compatibles en lecture / écriture.

Bonjour Pieloe,

Bonne nouvelle les XMP... du coup fini les DOP... ou pas 

Merci 

[fabco]

bonjour,

Les dop continuent d'exister.

[Dub]

bonjour,

Les dop continuent d'exister.

Ok, merci.. 

[gerarto]

Bien sûr que les .dop existent encore.

Les .dop, c'est toujours pour enregistrer les réglages de l'image, ce n'est lisible que par PL.
Les .xmp, c'est pour tout ce qui est métadonnées. Et c'est lisible par tout logiciel... sachant les lire.

Avec toutefois une petite particularité : les .dop peuvent aussi - le cas échéant - contenir les métadonnées des copies virtuelles, lesquelles données seront alors intégrées aux fichiers de sortie correspondants à ces copies virtuelles.

[audio-promo]

Dommage que les projets disparaissent quand on lance PL5 et qu'on ne les retrouve plus non plus si on repart de PL4.
Que PL5 convertisse la BDD de PL4 vers son nouveau format, pourquoi pas, mais pourquoi éliminer les projets qui étaient en cours dans PL4 ?

tu es sûr de ça ?
dommage moi qui commençait à travailler par projets.

[Zaphod]

Bien sûr que les .dop existent encore.

Les .dop, c'est toujours pour enregistrer les réglages de l'image, ce n'est lisible que par PL.
Les .xmp, c'est pour tout ce qui est métadonnées. Et c'est lisible par tout logiciel... sachant les lire.

Avec toutefois une petite particularité : les .dop peuvent aussi - le cas échéant - contenir les métadonnées des copies virtuelles, lesquelles données seront alors intégrées aux fichiers de sortie correspondants à ces copies virtuelles.

C'est un peu dommage, car on peut mettre aussi des réglages dans un XMP, qui ne seront pas touchés par les autres logiciels qui savent lire les XMP.
Et en cas de renommage / déplacement avec un autre logiciel, les XMP sont pris en compte, les DOP sont perdus.

[Dub]

C'est un peu dommage, car on peut mettre aussi des réglages dans un XMP, qui ne seront pas touchés par les autres logiciels qui savent lire les XMP.

Ben oui, y'a un standard le XMP... pourquoi enquiquiner le monde avec le DOP 

Et en cas de renommage / déplacement avec un autre logiciel, les XMP sont pris en compte, les DOP sont perdus.

Ça dépend, certain(s) bon(s) Catalogueur(s) le gère... 

[gerarto]

C'est un peu dommage, car on peut mettre aussi des réglages dans un XMP, qui ne seront pas touchés par les autres logiciels qui savent lire les XMP.
Et en cas de renommage / déplacement avec un autre logiciel, les XMP sont pris en compte, les DOP sont perdus.

Avant que ça ne parte en quenouille, je rappelle que l'inclusion des métadonnées dans les .dop ne concerne QUE les copies virtuelles ! ! ! 

Je pense que tu veux dire qu'il serait préférable de mettre le contenu des .dop dans un xmp.  Vaste débat dont il ressort que très peu y sont favorables, et manifestement en tout cas pas DxO.

Ce que j'ai écrit plus haut ne concerne que les copies virtuelles... qui sont virtuelles par définition jusqu'à ce qu'on en fasse une sortie ! Et qui sont susceptibles d'être supprimées, modifiées, etc..

Le cas de la copie virtuelle est particulier : c'est une solution simple pour faire suivre les métadonnées sans perte via les fichiers de sortie pour ces CV. Le master aura toujours lui son fichier xmp. Et dans la plupart des cas, les métadonnées sont les mêmes entre master et CV. De toute façon un logiciel tiers ne saurait pas quoi faire s'il trouvait des métadonnées liées à des copies virtuelles dans un xmp.

Si tu veux "figer" une copie virtuelle dans l'hypothétique idée d'en faire un raw à part entière, il suffit de copier l'ensemble des réglages de corrections et de métadonnées, de faire une copie du fichier raw (avec un nom différent) et d'y coller toutes les corrections et métadonnées. C'est tout simple... mais toutefois bien compliqué par rapport à la facilité de gestion d'un raw avec des copies virtuelles.

Il faut rappeler que tous les exports PL intègrent l'ensemble des métadonnées dans le fichier de sortie (sauf si on a demandé l'inverse). Donc si tu fais une sortie en dng par exemple pour être reprise dans LR, l'ensemble des métadonnées sera dans le dng et LR les retrouvera toutes sans avoir besoin de xmp.

[nicolas-p]

Peut-être une première étape de dxo avant ultérieurement une intégration totale  dans le xmp?

Bon j'ai fait un peu joujou avec cette version et comparativement à la 4 pour un non utilisateur  de fuji comme moi, les différences sont assez anecdotiques .
Le masque réglable en luminosité ou couleurs est un petit plus mais ne révolutionne pas les choses.

Pour la vitesse  que ce soit traitement ou export étant équipé d'un vieux i5 et 8giga de ram je n'ai vu aucune différence mais ma configuration est trop modeste   pour montrer quoi que ce soit.

Je confirme pour ma part le maintien de la version 4. Position qui sera revue si dxo sort en cours d'année d'autres choses dans des versions intermédiaires (peu probable ).

Une bonne version interressante pour un primo acquérant mais nécessitant  toujours un logiciel de gestion d'images associé (lr 6.14 pour ma part toujours nickel pour cela ).

[Zaphod]

Avant que ça ne parte en quenouille, je rappelle que l'inclusion des métadonnées dans les .dop ne concerne QUE les copies virtuelles ! ! !

Les réglages d'une photo ne sont pas dans les .dop ?

Il faut rappeler que tous les exports PL intègrent l'ensemble des métadonnées dans le fichier de sortie (sauf si on a demandé l'inverse). Donc si tu fais une sortie en dng par exemple pour être reprise dans LR, l'ensemble des métadonnées sera dans le dng et LR les retrouvera toutes sans avoir besoin de xmp.

Oui c'est un DNG donc le .xmp est intégré au DNG.
Mais il y aura toujours le .dop avec les réglages de la photo d'origine.
Alors qu'on aurait pu mettre ça dans le .xmp (toujours de la photo d'origine).

[Zaphod]

Je confirme pour ma part le maintien de la version 4. Position qui sera revue si dxo sort en cours d'année d'autres choses dans des versions intermédiaires (peu probable ).

Après 1 année sur 2 c'est aussi un bon rythme pour les mises à jour.
(à part si changement de boitier etc...)
L'année dernière était un peu spécial car DeepPrime était quand même un "game changer".

Mais c'est bien aussi d'avoir des améliorations un peu moins impressionnantes mais sur des choses qui améliorent aussi l'utilisation du soft par petites touches.

[gerarto]

Avant que ça ne parte en quenouille, je rappelle que l'inclusion des métadonnées dans les .dop ne concerne QUE les copies virtuelles ! ! ! 

Les réglages d'une photo ne sont pas dans les .dop ?
...
Oui c'est un DNG donc le .xmp est intégré au DNG.
Mais il y aura toujours le .dop avec les réglages de la photo d'origine.
Alors qu'on aurait pu mettre ça dans le .xmp (toujours de la photo d'origine).

Pour que les choses soient bien claires :

- Le .dop contient depuis toujours ou presque tous les réglages propres à PhotoLab (synchronisés avec la base de données). C'est à dire : les réglages du raw (ou autre) et ceux des copies virtuelles s'il en existe.

- Le .xmp contient toutes les métadonnées du fichier d'origine : IPTC, mots clés, notes, coordonnées GPS... Il est accessible en lecture et écriture à tout logiciel sachant les gérer (DAM).

DxO pourrait certes ajouter le contenu des .dop dans les .xmp, mais ça ne se fera probablement jamais.
- D'abord très probablement parce que DxO veut rester maître de ce qu'il met dans les .dop et de la manière dont il le code,
- ensuite parce que ça serait complètement inutile pour toute autre application, et alourdirait les xmp inutilement,
- et enfin parce que les spécialistes du DAM (dont je ne fais pas partie) semblent être assez d'accord pour dire que l'architecture des xmp et l'interopérabilité entre diverses applications de gestion est déjà assez sujette à problèmes pour ne pas en rajouter.

Je le répète, le seul cas où PL ajoute des données xmp  dans les .dop, c'est pour les copies virtuelles puisqu'il n'existe pas de fichier physique correspondant, et qu'on peut pour ces CV ajouter ou modifier des valeurs IPTC ou autres. Le fichier maître ayant son propre .xmp avec les métadonnées le concernant. C'est manifestement un fonctionnement qui semble satisfaire les "sachants" de la gestion.     
 

[Bélisaire]

Je viens de procéder au test DeepPrime, à propos de la vélocité accrue de PL5.
Image Raw de 117 Mo (ARW), non traitée par ailleurs, 20 000 isos. DeepPrime curseur à 40.
Export vers TIF 16 bits DPL4 : 46 secondes.
                                   DPL5 : 44 secondes.

Export vers JPG, qualité 95. DPL4 : 44 secondes.
                                          DPL5 : 41 secondes.

Mon ordinateur (portable) : I9 10e génération. Mémoire 32Go. CG 4 Go. Programme sur SSD. Images sur DD externe en USB-C.

Si ce test unique a valeur évangélique, je gagne que dalle.

[phoenixf50]

merci pour les réponses a mes questions je vais donc partir sur le pack premium. De plus merci pour les diffèrent explication sur les .DOP et les .XMP fort bien interessant.

[nikili]

vu dans les prérequis pour une install de la V5 sur Mac OS :

"macOS 10.15.7 (Catalina), 11.0 (Big Sur) ou 12.0 (Monterey)"

ca devient tendu pour une install sur Mojave alors que mon MacPro 2010 boosté avec une carte graphique compatible métal ne peut aller au delà de Mojave 

Non, si tu as une carte compatible metal, ton MacPro 2010 tournera comme une horloge sous Catalina 10.15, je l'ai fait sur le mien et tout fonctionne : Bluetooth, Wifi, réseau, imprimantes... aucune différence avec Mojave.

Pour cela, tu te rends à cette adresse http://dosdude1.com/catalina/ et tu télécharges le patch.
Je l'ai fait directement sur mon disque système parce qu'avec ma carte vidéo Radeon RX 560 pour PC, je démarre en aveugle jusqu'à l'apparition du Finder, donc appuyer sur la touche alt pour choisir la clé usb au démarrage ce n'est pas gagné.

Bien entendu, j'avais ma Time machine à jour + un clone de mon DD au cas où...
Mais il n'y a pas eu de cas où !

La mise à jour est plus facile que de 10.12 à 10.13 et de 10.13 à 10.14.

En faisant ça, tu gagnes encore 1 an et on peut également installer 11 BigSur, mais je n'ai pas encore tenté l'expérience...

À toi de voir.

[LRafale]

Merci pour tes infos Nikili
Je ne suis pas du tout chaud pour installer catalina.
En plus je comprends qu'avec une Radeon 5xxx on a plus d'accélération.
Vu le peu de fonctionnalités intéressantes pour moi dans V5, je vais rester sagement sur Mojave qui tourne parfaitement
Envoyé de mon iPad en utilisant Tapatalk

[fabco]

Pour information:

temps de traitement
dpl4 9s
dpl5 6s
raw a7 III 47Mo
pc fixe ryzen 3700 16 go de memoire cg 5500xt 4go

deepprime

J'ai bien le rapport 1.6

[ricoco]

Merci pour tes infos Nikili
Je ne suis pas du tout chaud pour installer catalina.
En plus je comprends qu'avec une on a plus d'accélération.
Vu le peu de fonctionnalités intéressantes pour moi dans V5, je vais rester sagement sur Mojave qui tourne parfaitement
Envoyé de mon iPad en utilisant Tapatalk

Hello,

C'est quoi ta Radeon 5xxx , c'est un eGPU?

il faut Catalina? J'ai acheté car j'ai un X-E3 comme second boitier mais je suis sous Mojave
j'avais l'accélération avec mon hackintosh et Radeon 580 et sur mon mbp avec Radeon 450

EDIT : en effet WTF !!!    Catalina et Big Sur, y a eu des avis mitigés et négatifs notamment les ressources qui s'envolent pour un process de sécurité ... Y a des gens qui sont revenu en arrière

    Minimum system configuration:
            Any CPU
            8 GB RAM
            4 GB available disk space
            macOS 10.15.7 (Catalina), 11.0 (Big Sur) or 12.0 (Monterey)
            Graphics card with 512 MB of video memory for handling GPU acceleration

    Recommended system configuration:
            Intel® Core™ i7 4th generation or higher, or Apple Silicon
            16 GB RAM
            6 GB available disk space
            AMD Radeon™ Pro 580X or better for Intel® Macs

[nicolas-p]

 [at]  pieloe:
la prise en charge des fuji étant non totalement aboutie , Dxo va donc prévoir des mises à jour.
vous qui semblez les connaitre, avez vous des infos sur d'éventuels mise à jour d'outils existant ou nouveaux outils prévus? ou faut il plutot tabler sur une version 6...

[Pieloe]

la prise en charge des fuji étant non totalement aboutie , Dxo va donc prévoir des mises à jour.
vous qui semblez les connaitre, avez vous des infos sur d'éventuels mise à jour d'outils existant ou nouveaux outils prévus? ou faut il plutot tabler sur une version 6...

La prise en charge des X-trans est définitive et absolue.
Le faible panel de testeurs n'a pas permis de débugguer (s'il le fallait) toutes les configurations.
Des mises à jour intermédiaires vont arranger les choses constatées avec l'expérience.

J'ignore le sens du terme béta. Peut-être un engagement implicite au remboursement si ça marche pas sur TA machine.

[egtegt²]

A mon avis ils ont mis beta juste par précaution pour que les utilisateurs ne s'attendent pas a une version stable et totalement débuggée. De toute façon c'est juste un mot, qu'ils l'aient mis ou pas, ce qui importe c'est de savoir si le logiciel marche ou pas

[nicolas-p]

La prise en charge des X-trans est définitive et absolue.
Le faible panel de testeurs n'a pas permis de débugguer (s'il le fallait) toutes les configurations.
Des mises à jour intermédiaires vont arranger les choses constatées avec l'expérience.

J'ignore le sens du terme béta. Peut-être un engagement implicite au remboursement si ça marche pas sur TA machine.

pas de méprise!
je ne critiquai pas le mot "béta" et je n'ai pas de x-trans. je voulais savoir si vu l'énergie et les moyens déployés pour le x-trans (algorithme...) il y avait (ou non) des infos sur des choses à venir en version 5 ou si il faut plutot patienter jusqu'à la 6.

[Pieloe]

La prise en charge des X-trans est définitive et absolue.
Le faible panel de testeurs n'a pas permis de débugguer (s'il le fallait) toutes les configurations.
Des mises à jour intermédiaires vont arranger les choses constatées avec l'expérience.

J'ignore le sens du terme béta. Peut-être un engagement implicite au remboursement si ça marche pas sur TA machine.

pas de méprise!
je ne critiquai pas le mot "béta" et je n'ai pas de x-trans. je voulais savoir si vu l'énergie et les moyens déployés pour le x-trans (algorithme...) il y avait (ou non) des infos sur des choses à venir en version 5 ou si il faut plutot patienter jusqu'à la 6.

Pas de méprise 
Je croyais avoir été clair.
Il y aura des mises à jour gratuites 5.1, etc... pour gérer tous les bugs rapportés au support.

[nicolas-p]

pas de méprise!
je ne critiquai pas le mot "béta" et je n'ai pas de x-trans. je voulais savoir si vu l'énergie et les moyens déployés pour le x-trans (algorithme...) il y avait (ou non) des infos sur des choses à venir en version 5 ou si il faut plutot patienter jusqu'à la 6.

Pas de méprise 
Je croyais avoir été clair.
Il y aura des mises à jour gratuites 5.1, etc... pour gérer tous les bugs rapportés au support.

ok c'est clair!
merci