PLab : Enregistrer les paramètres des variantes de traitement d'un fichier raw ?

[Verso92]

Normalement, dans tout logiciel de post-traitement des RAW, l'ordre dans lequel on applique les corrections n'a aucune importance.

Dans PhotoLab, je ne sais pas.

Dans Capture One, par contre, il semblerait qu'il soit préférable de faire les corrections dans le même ordre que le pipeline interne du logiciel...

https://alexonraw.com/applying-capture-one-tools-in-the-right-order/

[Samoreen]

Dans Capture One, par contre, il semblerait qu'il soit préférable de faire les corrections dans le même ordre que le pipeline interne du logiciel...

À la base, s'agissant d'un post-traitement paramétrique, l'ordre des réglages ne devrait pas influer sur le résultat. Tout changement de réglage implique logiquement un recalcul (re-dématriçage).

Cependant, cela pose immédiatement un problème pratique d'optimisation, un recalcul complet prenant trop de temps dans le cas de certaines modifications ou manipulations. Chaque moteur de dématriçage va donc avoir ses spécificités en implémentant des mécanismes d'optimisation (caches, calques,, tampons...) évitant un recalcul complet (et une nouvelle conversion dans l'espace couleur de l'écran) tout en restant dans la philosophie du "non destructif". Pas facile.

L'exemple que tu donnes dans C1 est déjà limite mais on trouve l'équivalent dans LR. Par exemple, je n'ai jamais réussi à obtenir des infos officielles sur l'interaction entre le curseur Contraste, le Réglage des Tons et la courbe de Tonalité. Parfois, un ordre précis est uniquement une question de visualisation : il n'est pas très pertinent de régler l'accentuation avant d'avoir débruité (mais ça n'influera pas sur le résultat final).

Dans le cas que je cite pour Photolab, on est carrément dans l'inacceptable. Et pourtant, ça persiste. Comme je l'ai suggéré, c'est probablement à cause d'un problème de conception initiale qui se pose à chaque fois que l'on n'a pas anticipé l'ajout d'une fonctionnalité qui ne peut pas entrer dans le schéma de départ. Ce qui tend à démontrer qu'au bout d'une certaine durée de vie, une réécriture des mécanismes de base d'un logiciel s'impose. En général ça ne plaît pas aux financiers. Et plus on tarde, plus ça empire.

Tout ça impacte également un problème évoqué ailleurs : les prérequis hardware sont fatalement destinés à devenir plus importants. C'est la solution facile pour éviter la modification du design de base. Mais ça affecte directement le budget informatique. Pour les pros, c'est négligeable. Pour de nombreux amateurs, ça peut devenir un problème.

[rsp]

Tout ce qu'on peut espérer c'est qu'ils fassent le même effort pour DPL que pour Nik collection : réécriture complète...

[ccaphotographies]

quand on shoote une série de 2000 photos avec quasi la même exposition, il y a un intérêt à conserver les préréglages, je te le garantie

[gerarto]

Je ne demande qu'à vous croire et c'est vrai que je ne me plains pas de la qualité actuelle du dématriçage. Mais à la sortie de PL5, DXO faisait une distinction entre un dématriçage « compatible X-TRANS » disponible dès la sortie de cette version et une évolution promise dans un futur proche pour un dématriçage « spécifique X-Trans » qui était sensé améliorer le premier... Tant mieux si vous avez raison !
...

Je peux certifier que le dématriçage pour les X-Trans n'est pas "compatible", mais complètement dédié à cette matrice !
D'ailleurs, il l'a toujours été depuis le version 5, sauf que c'était alors une version Beta : fonctionnelle mais avec la possibilité qu'un bug survienne vu la multiplicité des boîtiers pris en charge d'un coup pour cette matrice. 

Joyeux Noêl !

[Diapoo®]

Je peux certifier que le dématriçage pour les X-Trans n'est pas "compatible", mais complètement dédié à cette matrice ! (...)

OK, tant mieux. Reste quand même l'os DeepPRIME XD2 qui ne pose pas de problème pour les capteurs Bayer.
Selon mon expérience de DXO, le sujet pourrait... s'éterniser !!! 

[gerarto]

OK, tant mieux. Reste quand même l'os DeepPRIME XD2 qui ne pose pas de problème pour les capteurs Bayer.
Selon mon expérience de DXO, le sujet pourrait... s'éterniser !!! 

DeepPRIME XD2(s) ne pose évidemment pas de problème pour les capteurs Bayer... vu qu'il a été conçu sur la base de cette matrice.
Pour le portage sur les capteurs X-Trans, voilà ce que j'écrivais suite aux questions que j'avais posées à un responsable de DxO au dernier salon de la photo :
(je n'ai pas eu vent d'autres infos depuis)

De source sûre, la prise en charge par DeepPRIME XD2 des X-Trans Fujifilm n'a jamais été aussi proche*...
(* = c'est un joke, pas une promesse perso)
Cela ne signifie pas que c'est pour demain : tout dépend de l'horizon de l'avenir !

Les ressources de DxO sont ce quelles sont, et si j'ai bien retenu les réponses à ma question sur ce sujet :
- la part de marché des Fujifilm pour DxO serait de l'ordre de 8% des utilisateurs. Même si ce chiffre n'est pas négligeable, cela relativise l'ordre de priorité.
- La prise en charge des fichiers X-Trans pour DeepPRIME XD a été également assez longue, DxO va faire son maximum pour que le délai soit inférieur pour XD2
- Et pour cela, DxO a recruté. 
 

[Diapoo®]

Merci gerarto.
Effectivement, 8% de clients Fuji chez DXO, ça ne pèse pas très lourd... Ceux qui utilisent Lightroom ne savent pas ce qu'ils perdent !!!