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

Diapoo® · Décembre 03, 2024, 00:25:43

Bonjour à tous.

Je ne maitrise pas encore toutes les subtilités de PhotoLab et je ne trouve pas la solution dans les menus...
Quand je traite différentes variantes d'un fichier raw donné, j'obtiens différents jpeg renommés par PL : _DXO, _DXO-1, _DXO-2, _DXO-3...
PL ne semble pas mémoriser les réglages de chacune des variantes mais seulement ceux du dernier fichier traité, dans l'exemple le _DXO-3.

Ma question est : existe-t-il un moyen d'enregistrer séparément les réglages de chacune des variantes successives traitées de façon à pouvoir les retrouver ultérieurement si nécessaire ? Merci de vos réponses

P.S.: Dans le menu contextuel "clic droit sur la photo", il existe bien une fonction « Copier les réglages de correction »... mais après j'en fais quoi ? ??

Palomito · Décembre 03, 2024, 07:53:03

Je pense que la solution a ton problème, c'est la copie virtuelle. Tu crées une copie par traitement que tu effaces, ou pas, une fois que tu as trouvé celui qui te convient.

rsp · Décembre 03, 2024, 09:02:09

Attention, on peut effacer les copies virtuelles sans perdre l'image d'origine marquée M pour "Maitre". En revanche, si on efface la M on perd tout y compris le RAW.
Donc le mieux est probablement de ne pas toucher la M en créant autant de CV que de versions, puis une fois qu'on a choisi, copier les réglages de la CV choisie sur la M avant de supprimer les CV.

Samoreen · Décembre 03, 2024, 10:17:37

Citation de: Diapoo® le Décembre 03, 2024, 00:25:43Dans le menu contextuel "clic droit sur la photo", il existe bien une fonction « Copier les réglages de correction »... mais après j'en fais quoi ? ??

Ce qui a été copié a vocation à être collé sur une autre image (ou copie virtuelle).

Palomito a indiqué la bonne réponse au problème posé. Mais effectivement, comme indiqué par rsp, attention au piège qui guette en particulier ceux qui viennent de Lightroom. Comme on ne passe pas, sous Photolab, par un catalogue, la commande suppression correspond bien à la mise à la corbeille du fichier visé. Alors que sous LR, on a le choix entre supprimer dans le catalogue la référence au fichier OU supprimer le fichier lui-même.

Par contre, quand on visualise le contenu d'un projet, la même commande ne fait que retirer l'image du projet sans supprimer le fichier. De même, la suppression d'une copie virtuelle ne fait que supprimer dans le .dop (et/ou la base de données), les paramètres correspondant à la copie virtuelle. Le fichier original reste en vie. Bien sûr, si on supprime l'image originale (M), les copies virtuelles disparaissent également puisqu'elles n'existent que dans le .dop qui disparaît également avec l'original.

rsp · Décembre 03, 2024, 14:39:18

Il y a sur le forum DXO de nombreuses demandes pour que la version M ne soit que la tête de liste, c'est à dire qu'elle soit remplacée par la première copie virtuelle #1 quand on la supprime. Du coup, pour supprimer complètement une image il faudrait sélectionner toutes les versions, y compris la M, et mettre à la corbeille l'ensemble.

Pieloe · Décembre 03, 2024, 17:23:36

Citation de: rsp le Décembre 03, 2024, 14:39:18Il y a sur le forum DXO de nombreuses demandes pour que la version M ne soit que la tête de liste, c'est à dire qu'elle soit remplacée par la première copie virtuelle #1 quand on la supprime. Du coup, pour supprimer complètement une image il faudrait sélectionner toutes les versions, y compris la M, et mettre à la corbeille l'ensemble.

Ah ?
C'était le comportement (version ?) jusqu'à la mise en place de la reconnaissance du master ... suite au problème justement évoqué.
Quoique fasse DxO, ça va jamais

rsp · Décembre 03, 2024, 17:49:56

Citation de: Pieloe le Décembre 03, 2024, 17:23:36Ah ?
C'était le comportement (version ?) jusqu'à la mise en place de la reconnaissance du master ... suite au problème justement évoqué.
Quoique fasse DxO, ça va jamais

Il me semblait bien. J'étais favorable à l'ancienne version.
Mais quoi que change un concepteur de logiciel, cela fera toujours des mécontents et des satisfaits. C'est la vie.

Diapoo® · Décembre 03, 2024, 23:53:20

Bonsoir et merci à tous

Il y a des années que je ne suis plus très assidu sur le forum mais je vois qu'il est toujours aussi épatant et réactif qu'au "bon vieux temps" des années 2000

Je viens d'essayer... et ça a marché du premier coup ! Génial, jamais un problème n'a été résolu aussi vite

Personnellement la suppression accidentelle d'un fichier raw ou non ne me pose pas de problème, ça m'arrive de temps en temps et je le retrouve aussitôt dans la corbeille Windows — et idem sur Mac j'imagine ?

Par parenthèse, je ne suis pas fan de Lightroom que j'ai essayé dans le passé mais son ergonomie m'avait rebuté. Et de toute façon, pour mon usage relativement occasionnel, je suis contre l'abonnement.

Si ce n'est pas trop abuser de votre temps, j'aurais une autre question relative cette fois au "projet" DXO dont a parlé Samoreen : pour ceux qui l'utilisent, quel intérêt pratique y trouvez-vous ?

Merci à ceux qui voudront bien répondre

Palomito · Décembre 04, 2024, 09:43:09

pour ma part, j'utilise le Projet à 2 occasions :
1. quand je prépare une expo. Souvent les images se trouvent dans divers dossiers. Cela me permet de regrouper les images au même endroit pour mieux sélectionner celles que je vais retenir.

2. quand je fais un livre (privé), que les images se trouvent dans un ou plusieurs dossiers. Je trouve plus facile que de jouer avec les codes couleurs ou les notations. En gros, je sélectionne Conservé ou Rejeté. Parmi les conservées, je mets une couleur sur celles qui m'intéressent. Je filtre les images avec cette couleur et les insère dans le projet. Et dans le projet, je refais plusieurs passages, effaçant ce qui ne me convient pas.

J'ai réalisé que je tends à suivre le guide de Dxo, ceci de façon intuitive à la base. https://userguides.dxo.com/photolab/fr/gerer-les-images-et-les-metadonnees-dans-longlet-phototheque/

Diapoo® · Décembre 05, 2024, 01:28:27

Merci Palomito, je comprends mieux l'intérêt des projets. On y met les fichiers physiques ou des copies virtuelles ?

Je connaissais le tutoriel DXO, le plus dur est de s'y mettre !!!

rsp · Décembre 05, 2024, 05:46:14

C'est plutôt comme les raccourcis sous Windows. Que ce soient des CV ou M à l'origine, quand tu les supprimes du projet, elles ne sont pas détruites.
J'ai un doute sur les CV créées à partir du projet. J'essayerai la prochaine fois.
J'utilise moi aussi les projets quand je fais un livre photo.

Palomito · Décembre 05, 2024, 09:29:00

Citation de: Diapoo® le Décembre 05, 2024, 01:28:27Merci Palomito, je comprends mieux l'intérêt des projets. On y met les fichiers physiques ou des copies virtuelles ?

Je connaissais le tutoriel DXO, le plus dur est de s'y mettre !!!

Tu peux y mettre les deux. Mais j'ai également un blanc si la copie virtuelle est effacée si tu l'effaces du projet. Logiquement non. Mais... (je fais la sélection en amont habituellement)

Le tuto n'est pas compliqué. il te donne des pistes à suivre pour améliorer ton flux de travail. Le gros avantage, c'est que c'est assez souple. Tu peux utiliser le navigateur Windows, ou des softs comme XnView pour ton tri initial d'images à effacer ou pour copier depuis la carte mémoire. Ou tout faire dans Dxo. j'aime bien cette souplesse, contrairement à LR et son catalogue qui me sortait par les oreilles.

Samoreen · Décembre 05, 2024, 10:49:27

[at] Diapoo

Puisque vous êtes dans une phase de prise en main de Photolab, un avertissement à propos d'un piège dans lequel on tombe facilement, surtout quand on vient de Lightroom. Ça me vient à l'esprit car nous sommes encore une fois en train de discuter ce point sur le forum DxO.

Normalement, dans tout logiciel de post-traitement des RAW, l'ordre dans lequel on applique les corrections n'a aucune importance. Dans Photolab, DxO recommande de procéder d'abord aux corrections affectant la géométrie ou la perspective. On peut se demander pourquoi. Eh bien parce que si on procède à une de ces opérations après avoir effectué n'importe quelle correction impliquant un masquage, le masque ne sera pas adapté à la correction appliquée. Si par exemple vous effectuez une rotation, les masques existant ne suivront pas cette rotation. Autant dire qu'il faudra les refaire (sauf s'il s'agit d'un masque luminosité, pour des raisons évidentes).

DxO semble considérer que les corrections affectant la géométrie effectuées en début de traitement n'ont pas vocation à être revues. Ce qui est bien évidemment une erreur profonde. On peut toujours avoir besoin, au moment de la finition, d'ajuster un réglage local, un niveau, une déformation, etc.

En cela, il y a une sorte de rupture du contrat implicite que l'on trouve dans tous les logiciels de post-traitement que je connais : l'ordre des corrections est normalement indifférent. Il y a longtemps que nous avons demandé à DxO de corriger ça mais ça ne vient pas. Ça ne paraît pourtant pas poser de problème technique majeur. Il s'agit d'une simple rotation de figure.

Zaphod · Décembre 05, 2024, 20:30:33

Citation de: Samoreen le Décembre 05, 2024, 10:49:27Eh bien parce que si on procède à une de ces opérations après avoir effectué n'importe quelle correction impliquant un masquage, le masque ne sera pas adapté à la correction appliquée. Si par exemple vous effectuez une rotation, les masques existant ne suivront pas cette rotation. Autant dire qu'il faudra les refaire (sauf s'il s'agit d'un masque luminosité, pour des raisons évidentes).

Wooo...
Je n'aurais même pas imaginé que c'etait possible... avec Lightroom n'importe quel masque ou correction type tampon est adaptée en fonction de la géométrie (même correction de perspective importante).

De base j'aurais même considéré que c'était sans doute encore mieux géré dans Photolab...

Samoreen · Décembre 05, 2024, 23:47:16

En fait, ce problème existe depuis les débuts de Photolab et réémerge régulièrement sur le forum. Ce qui pose 2 questions :

1. Si ce n'est toujours pas corrigé, c'est que le problème n'a pas été vu au départ (2017) et qu'il y a un gros souci de design qui empêche la correction.

2. On peut aussi s'interroger sur la manière dont le produit est utilisé dans le monde réel. Il est surprenant que ce souci soit évoqué aussi peu souvent.

Samoreen · Décembre 05, 2024, 23:50:10

https://support.dxo.com/hc/fr/articles/7031869877149-Pourquoi-la-zone-sélectionnée-pour-les-réglages-locaux-change-t-elle-après-l-application-de-la-correction-géométrique

Cette page n'est pas assez précise car ça ne concerne pas que les réglages locaux.

rsp · Décembre 06, 2024, 00:04:03

Citation de: Samoreen le Décembre 05, 2024, 23:47:16En fait, ce problème existe depuis les débuts de Photolab et réémerge régulièrement sur le forum. Ce qui pose 2 questions :

1. Si ce n'est toujours pas corrigé, c'est que le problème n'a pas été vu au départ (2017) et qu'il y a un gros souci de design qui empêche la correction.

2. On peut aussi s'interroger sur la manière dont le produit est utilisé dans le monde réel. Il est surprenant que ce souci soit évoqué aussi peu souvent.

Absolument...
Toutefois il y a un contournement dans le cas d'un dernier petit peaufinage de perspective par exemple : l'appliquer sur la sortie (JPG ou TIF) au moyen de VP.
Ce n'est pas normal ni satisfaisant.

Diapoo® · Décembre 06, 2024, 02:32:46

Projets : merci pour vos précisions rsp et Palomito. A priori je n'en aurai pas souvent l'utilité pour mon modeste usage principalement familial mais ça peut servir un jour.

Citation de: Samoreen le Décembre 05, 2024, 10:49:27[at] Diapoo

Puisque vous êtes dans une phase de prise en main de Photolab, un avertissement à propos d'un piège dans lequel on tombe facilement, surtout quand on vient de Lightroom. Ça me vient à l'esprit car nous sommes encore une fois en train de discuter ce point sur le forum DxO.

Normalement, dans tout logiciel de post-traitement des RAW, l'ordre dans lequel on applique les corrections n'a aucune importance. Dans Photolab, DxO recommande de procéder d'abord aux corrections affectant la géométrie ou la perspective. On peut se demander pourquoi. Eh bien parce que si on procède à une de ces opérations après avoir effectué n'importe quelle correction impliquant un masquage, le masque ne sera pas adapté à la correction appliquée. Si par exemple vous effectuez une rotation, les masques existant ne suivront pas cette rotation. Autant dire qu'il faudra les refaire (sauf s'il s'agit d'un masque luminosité, pour des raisons évidentes) (...)

Samoreen, sauf si tu n'es pas d'accord, on peut se tutoyer, je comprends qu'on est à peu près contemporains !

J'avais découvert cette affaire de géométrie et perspective à faire en premier assez rapidement sur des photos d'architecture pour des travaux à faire sur une maison.
Pour cet usage, les outils de DXO sont assez magiques mais dès qu'on doit pousser les curseurs un peu loin, par exemple pour avoir des verticales toutes parallèles, la photo peut se trouver complètement "chamboulée" avec des triangles noirs qui apparaissent sur la périphérie du cadre (il faut décocher l'outil recadrage pour les voir, ce qui permet aussi de faire une recadrage manuel parfaitement adapté au besoin). Du coup effectivement, j'en ai déduit qu'il fallait impérativement commencer par faire ce recadrage définitif avant de commencer les corrections, locales ou non... Comme je n'ai pratiquement jamais utilisé de logiciel de dématriçage avant DXO, ça ne m'a pas traumatisé

En fait, après un premier essai négatif avec Lightroom il y a longtemps, j'ai dû attendre près de 10 ans que PL 5 dématrice enfin les RAF Fuji

Et encore, il le fait de façon générique comme si on avait un capteur Bayer, on attend toujours le dématriçage X-Trans promis...

Samoreen · Décembre 06, 2024, 10:20:51

Citation de: Diapoo® le Décembre 06, 2024, 02:32:46Samoreen, sauf si tu n'es pas d'accord, on peut se tutoyer, je comprends qu'on est à peu près contemporains !

OK. Pas de problème. Je tutoie assez facilement mais pas tout de suite en général. Effectivement, un réflexe générationnel

.

Concernant DxO, je suis client depuis le début de leur activité, il y a 20 ans. J'étais encore actif à cette époque et je me souviens d'échanges avec un ou deux développeurs à propos de leur utilisation du framework de développement Microsoft .Net. Il se trouve que j'étais à l'époque parmi les rares consultants ayant investi dans cette technologie et l'enseignant (en tant qu'indépendant, je fus pendant 6 ans Microsoft MVP Développement). Et DxO était une des rares boîtes ayant décidé d'utiliser cette technologie pour leurs produits. C'était l'époque où on pouvait parler directement à un développeur chez DxO. Je me souviens d'une discussion téléphonique à propos des problèmes causés par l'utilisation mixte de Microsoft .Net et de la technologie ActiveX/COM (ce n'est plus le cas aujourd'hui dans leurs produits). Les temps ont changé.

Le problème de la non mobilité des masques fait partie des éléments qui me font doucement perdre confiance et patience. Je reste loyal parce que pour une fois qu'une boîte de software française apporte quelque chose de nouveau, j'ai toujours envie de soutenir. Mais l'accumulation des problèmes apparemment mineurs qui ne se règlent pas (probablement à cause d'erreurs dans le design initial) commence à me lasser. Surtout depuis que j'ai quasi complètement basculé dans le monde Fuji (encore un peu d'argentique et de Canon dans certains cas). Comme je l'expliquai récemment dans leur forum, l'empilement de problèmes soi-disant mineurs mais jamais corrigés finit toujours par constituer un seul gros problème majeur.

DxO a fini par adopter une attitude qui a longtemps nuit au développement du software français : à partir du moment où on est les seuls à maîtriser une technologie donnée, inutile de perdre du temps et d'investir sur la finition. Ça ira comme ça. C'est une grave erreur. Ajoutons à ça des banques qui refusent quasi systématiquement de suivre et qui n'ont aucune idée de ce que veut dire "capital risque" et on finit toujours dans la même impasse (je connais, j'ai également été créateur/éditeur de logiciels).

Voilà pour la petite histoire... Revenons au sujet.

Noir Foncé · Décembre 06, 2024, 10:38:49

Citation de: Diapoo® le Décembre 06, 2024, 02:32:46[...]
j'ai dû attendre près de 10 ans que PL 5 dématrice enfin les RAF Fuji Et encore, il le fait de façon générique comme si on avait un capteur Bayer, on attend toujours le dématriçage X-Trans promis...

Bonjour,
En quoi le dématriçage des X-trans Fuji est défaillant actuellement ? Sur quels exemples de photos peut-on le mettre en évidence ?

J'avais fait des tests entre les développements Photolab, Lightroom, Capture One, Fuji lui-même sur des fichiers de X-Pro 1 et au contraire, j'avais trouvé que Photolab + DeepPRIME donnait toujours un meilleur résultat, y compris dans la restitution de l'herbe ou de feuillages.
Il est vrai que DeepPRIME XD/XD2/XD2s n'est pas encore disponible avec les Fuji X-trans, mais ça me parait peu pénalisant au quotidien.

Samoreen · Décembre 06, 2024, 11:45:55

Citation de: Noir Foncé le Décembre 06, 2024, 10:38:49En quoi le dématriçage des X-trans Fuji est défaillant actuellement ? Sur quels exemples de photos peut-on le mettre en évidence ?

Je crois qu'il faut regarder séparément débruitage et dématriçage.

D'une manière générale, le dématriçage des X-Trans est plus précis avec Photolab (notamment sur le feuillage, cas toujours problématique). Il y a parfois quelques cas limites mais globalement Photolab est meilleur.

Au niveau débruitage, Photolab est toujours meilleur dans les cas standard mais dans les situations très bruitées où DeepPrime XD pourrait être utile, il y a trop souvent génération d'artefacts acceptables sur des tirages petit format mais rédhibitoires sur des formats plus conséquents. DxO l'a implicitement reconnu et XD2/s est censé régler ça. Pour moi, c'est l'absence de support de XD2 pour les fichiers X-Trans qui est le problème principal actuellement parce que justement, j'ai un projet assez lourd où ce serait vraiment utile.

Diapoo® · Décembre 19, 2024, 01:48:58

Bonjour, désolé de mon absence... prolongée !

Noir Foncé et Samoreen, merci pour vos indications.

D'abord à propos de l'affaire des masques DXO : je comprends mieux ta grogne, Samoreen. J'ai voulu enregistrer un préréglage perso que j'ai renommé comme je le souhaitais : super ! Mais j'ai déchanté à sa première utilisation : en voulant le réutiliser, je me suis aperçu que les deux points de contrôles traités dans la première photo étaient intégrés dans l'enregistrement du préréglage et donc recopiés à la même place géométrique et avec le même traitement dans la nouvelle photo !!! C'est effectivement du grand n'importe quoi

A propos du dématriçage X-Trans, je vous dis ce que j'ai compris de mes demandes d'explications successives à DXO.
Mai 2012, j'achète mon premier FUJI, le X-PRO 1. J'interroge DXO par leur formulaire de contact pour savoir s'ils travaillent sur le dématriçage des capteurs X-Trans. La réponse, que je n'ai malheureusement pas conservée, m'explique que le dématriçage d'un X-Trans est extrêmement compliqué, que les algorithmes pour capteurs Bayer ne leur sont d'aucune utilité, que leur souci Nº1 est la qualité et qu'ils doivent reprendre l'entièreté du travail à zéro... Accessoirement, on croit devoir comprendre entre les lignes qu'Adobe, qui n'a eu aucun problème pour dématricer les X-Trans, a fait un travail approximatif en extrapolant pour X-Trans les algorithmes des capteurs Bayer...

Je répète ma demande l'année suivante puis en 2015 après l'achat de mon X-T1 et j'ai toujours la même réponse, et toujours sans date... Je suis persuadé que je perds mon temps et je me fais une raison. Quand j'étais chez Pentax avec un K5 puis K3, j'ai attendu en vain pendant des années sans jamais l'avoir le module optique de mon zoom standard Sigma 17-70 mm, qui était pourtant sorti pour les boîtiers Canikon...

Et puis, novembre 2021, MIRACLE, le dématriçage pour capteurs FUJI est enfin disponible dans PL 5 !!! Oui, mais pas tout à fait... Une note qu'on ne trouve plus aujourd'hui sur le site indique que le dématriçage spécifique X-TRANS est en phase bêta et sera intégré dans un proche avenir... Et depuis plus rien; PL 6 puis 7 et 8 sont sortis sans nouvelle du dématriçage X-Trans promis... Voici leur réponse à ma nouvelle demande du 19 novembre dernier :
« Merci pour votre intérêt pour DxO PhotoLab 8. Nous comprenons votre préoccupation concernant la compatibilité avec les fichiers Fujifilm X-Trans. Actuellement, nous travaillons activement à intégrer cette compatibilité avec DeepPRIME XD2, et nous espérons la rendre disponible dans un avenir proche. Cependant, nous ne pouvons pas fournir de date précise pour le moment.
Actuellement, DeepPRIME XD sera appliqué sur les fichiers Fuji à la place de DeepPRIME XD2.».
Ils ne répondent donc pas clairement à ma demande sur le dématriçage X-Trans promis à la sortie de PL5 en se focalisant sur le débruitage DeepPRIME. Ça laisse l'impression qu'ils noient le poisson et que le dématriçage spécifique X-Trans promis est passé à la trappe... Ce qui pourrait expliquer les difficultés persistantes avec DeepPRIME XD2

gerarto · Décembre 19, 2024, 12:02:47

Citation de: Diapoo® le Décembre 19, 2024, 01:48:58...
Actuellement, DeepPRIME XD sera appliqué sur les fichiers Fuji à la place de DeepPRIME XD2.[/i]».
Ils ne répondent donc pas clairement à ma demande sur le dématriçage X-Trans promis à la sortie de PL5 en se focalisant sur le débruitage DeepPRIME. Ça laisse l'impression qu'ils noient le poisson et que le dématriçage spécifique X-Trans promis est passé à la trappe... Ce qui pourrait expliquer les difficultés persistantes avec DeepPRIME XD2

? ? ?

J'avoue avoir du mal à comprendre !
Le "dématriçage X-Trans" est disponible depuis belle lurette (ok, ça dépend de la longueur de la lurette)...

En d'autres termes, les fichiers raw Fujifilm X-Trans sont bien traités par PhotoLab et PureRaw avec le dématriçage spécifique à cette matrice.
Ce qui n'est pas encore disponible, c'est le traitement de bruit DeepPRIME XD2s : c'est pour l'instant "limité" au traitement DeepPRIME XD... ce qui est déjà un traitement de bruit très qualitatif.
Je viens de faire un comparatif de traitement entre PL8 (DeepPRIME XD) et ACR/LR/PS (traitement du bruit avec avec accentuation via dng)) d'un fichier de XT-3 à 1250 iso, et PL est pour moi meilleur qu'ACR. Je ne peux pas montrer le résultat car c'est un fichier récupéré qui ne m'appartient pas, mais je suis prêt à faire la même démo avec un fichier "public".

Noir Foncé · Décembre 19, 2024, 16:10:06

Citation de: Diapoo® le Décembre 19, 2024, 01:48:58Bonjour, désolé de mon absence... prolongée !
Noir Foncé et Samoreen, merci pour vos indications.

D'abord à propos de l'affaire des masques DXO : je comprends mieux ta grogne, Samoreen. J'ai voulu enregistrer un préréglage perso que j'ai renommé comme je le souhaitais : super ! Mais j'ai déchanté à sa première utilisation : en voulant le réutiliser, je me suis aperçu que les deux points de contrôles traités dans la première photo étaient intégrés dans l'enregistrement du préréglage et donc recopiés à la même place géométrique et avec le même traitement dans la nouvelle photo !!! C'est effectivement du grand n'importe quoi

[...]

Non, ce n'est pas n'importe quoi. C'est simplement que tu n'as pas créé correctement le préréglage.
Quand on génère un préréglage à partir d'une photo traitée, il faut décocher tous les outils qu'on ne veut pas intégrer dans le préréglage. Notamment les masques et réglages locaux sauf si on veut les appliquer avec le préréglage.
Tout est expliqué ici, chapitre "Préréglage partiel" :
https://tutodxo.com/les-prereglages/

Citation de: Diapoo® le Décembre 19, 2024, 01:48:58[...]
Ça laisse l'impression qu'ils noient le poisson et que le dématriçage spécifique X-Trans promis est passé à la trappe... Ce qui pourrait expliquer les difficultés persistantes avec DeepPRIME XD2

Je rejoins ici gerarto : PhotoLab dématrice bien les RAW Fuji X-Trans depuis PL5, y compris ceux du X-Pro 1 depuis 2022.

Le seul algorithme qui n'est pas encore disponible pour les Fuji X-Trans est le débruitage DeepPRIME XD2/XD2s, dont l'usage ne se justifie que sur des fichiers à très hauts ISO et à la mise au point parfaite.
Et à nouveau, le dématriçage des Fuji X-Trans associé au débruitage DeepPRIME est le meilleur présent sur le marché, y compris pour des photos non bruitées.

Diapoo® · Décembre 23, 2024, 01:52:25

Citation de: Noir Foncé le Décembre 19, 2024, 16:10:06(...)
Je rejoins ici gerarto : PhotoLab dématrice bien les RAW Fuji X-Trans depuis PL5, y compris ceux du X-Pro 1 depuis 2022. (...)

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 !

A propos de l'enregistrement des préréglages :

Citation de: Noir Foncé le Décembre 19, 2024, 16:10:06Non, ce n'est pas n'importe quoi. C'est simplement que tu n'as pas créé correctement le préréglage.
Quand on génère un préréglage à partir d'une photo traitée, il faut décocher tous les outils qu'on ne veut pas intégrer dans le préréglage. Notamment les masques et réglages locaux sauf si on veut les appliquer avec le préréglage.
Tout est expliqué ici, chapitre "Préréglage partiel" :
https://tutodxo.com/les-prereglages/ (...)

J'ai bien compris et c'est ce que je ferai la prochaine fois ! Ce que je ne comprends pas, c'est l'intérêt qu'il y aurait à conserver des retouches locales quand on en fait un enregistrement de préréglages. Selon moi leur décochage systématique devrait être automatique...

Verso92 · Décembre 23, 2024, 09:43:51

Citation de: Samoreen le Décembre 05, 2024, 10:49:27Normalement, 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 · Décembre 23, 2024, 12:13:55

Citation de: Verso92 le Décembre 23, 2024, 09:43:51Dans 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 · Décembre 23, 2024, 22:06:51

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 · Décembre 24, 2024, 15:41:30

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 · Décembre 24, 2024, 21:15:12

Citation de: Diapoo® le Décembre 23, 2024, 01:52:25Je 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® · Décembre 25, 2024, 23:58:30

Citation de: gerarto le Décembre 24, 2024, 21:15:12Je 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 · Décembre 26, 2024, 15:18:01

Citation de: Diapoo® le Décembre 25, 2024, 23:58:30OK, 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)

Citation de: gerarto le Octobre 13, 2024, 18:02:58De 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® · Décembre 28, 2024, 01:12:43

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 !!!