Presets personnalisés et vérification presets appliqués

pixoo · Octobre 15, 2008, 08:52:06

Bonjour,

Nouvel utilisateur de DxO (v 5.2.1), pourriez-vous m'aider à comprendre les points suivants:

1- Presets personnalisés: en mode édition, je vois mal la logique d'activation des actions: est-ce la "coche" dans la marge orange qui active la fonction, ou l'action sur le bouton bleu (genre mise sous tension) à droite, ou faut-il activer les deux

Pas clair ....j'ai pourtant lu doc et livre de JMS!

2- Est-il possible de vérifier quel preset a été appliqué sur une photo déjà traitée, sans passer par le mode projet ? J'ai entendu parler de fichiers "sidecar" qui semblent contenir les données des presets. Comment y accéder et peut-on en tirer quelque chose ?

Merci pour votre contribution

Pat91 · Octobre 15, 2008, 10:08:43

Bonjour,

Point #1
Une fois que l'on a fait un réglage qui convient, en activant ou désactivant certaines fonctions avec les interrupteurs bleus, on sauvegarde ces réglages sous forme de preset en créant un nouveau preset, en passant en mode édition et en cochant dans la zone orange ceux parmi ces réglages qui doivent être sauvegardés dans le preset. Dès que l'on a coché au moins une case dans la zone orange, le bouton Save du panneau Preset est activé et on peut sauvegarder le preset et le renommer. Seuls les réglages cochés dans la zone orange feront partie du preset sauvegardé.

Point #2
À moins que je ne fasse une grossière erreur, la réponse est non. Voici pourquoi...

Quand vous créez un nouveau preset, les réglages qu'il contient sont sauvegardés dans la base de données DxO mais vous pouvez toujours l'exporter dans un fichier .dxo pour voir à quoi cela ressemble. C'est un fichier XML comme un autre exactement équivalent aux fichiers .dxo liés à vos images. Vous constaterez qu'il ne contient même pas son propre nom.

Quand vous chargez une image en mode édition ou pendant l'édition, vous spécifiez quel preset doit être appliqué. L'application de ce preset consiste à lire les réglages dans le preset spécifié et à les copier dans les réglages courants de l'image en question. Une fois cette opération réalisée, la référence au preset utilisé est perdue. Elle n'apparaît pas dans le fichier sidecar correspondant à l'image (j'ai vérifié). Idem si vous appliquez un second preset par-dessus le premier. Le fichier sidecar (et donc, je suppose, la base de données, ne contiennent que le résultat global de l'application du preset initial, des presetrs complémentaires appliqués après coup et des réglages personnalisés qui ont suivi. Aucune notion d'historique là-dedans. Le schéma XML des fichiers .dxo est extrêmement simpliste et n'autorise aucune souplesse en la matière. Il ignore totalement la notion de référence externe.

À mon humble avis (et je vais encore me faire incendier), c'est une erreur de design.

En effet, le fichier sidecar (ou l'équivalent dans la base de données DxO) devrait contenir uniquement la référence aux presets utilisés et leur ordre d'application. Pas les réglages eux-mêmes. Seuls les réglages complémentaires appliqués en plus des presets devraient être stockés dans le fichier sidecar et/ou la base de données.

De cette manière, on pourrait éditer un preset et les modifications seraient automatiquement appliquées à toutes les images utilisant ce preset quand on les développerait car le fichier sidecar (ou l'équivalent dans la base de données DxO) ne contiendrait que la référence aux presets qu'il irait donc relire à chaque rechargement du projet en appliquant automatiquement (sur option éventuelle) de nouveaux réglages si le ou les presets ont été modifiés.

Cela présenterait également l'avantage d'alléger la base de données puisqu'on ne dupliquerait plus les réglages en question car ils seraient stockés dans un endroit unique: le preset.

pixoo · Octobre 15, 2008, 16:32:16

Merci beaucoup Patrick d'avoir pris le temps pour cette longue réponse claire et argumentée. Je comprends mieux la logique du système.

Si j'ai bien compris, la base de données ne fait pas référence à un preset mais comporte exclusivement les paramètres de chaque réglage possible. Comment accéder à cette base de données (format des fichiers, répertoires de stockage par défaut ...)

Merci encore pour votre contribution

Pat91 · Octobre 15, 2008, 16:53:34

Citation de: pixoo le Octobre 15, 2008, 16:32:16Si j'ai bien compris, la base de données ne fait pas référence à un preset mais comporte exclusivement les paramètres de chaque réglage possible. Comment accéder à cette base de données (format des fichiers, répertoires de stockage par défaut ...)

Pour être précis: la base de données contient les presets (qui ne sont qu'un jeu de réglages associés à un nom et qu'on peut exporter sous forme de fichier XML - .dxo) et elle contient les réglages associés à chaque image qui ont été construits à partir d'un ou plusieurs presets + des modifications personnalisées. Ces réglages propres à chaque image ne contiennent aucune référence au(x) preset(s) qui ont servi à les générer. C'est ce que je considère comme une erreur ou un manque mais tout le monde ne sera pas d'accord avec moi sur ce coup.

La base de données elle-même est une base SQLite. On peut donc y accéder via n'importe quelle autre application. On ouvre très facilement le fichier avec n'importe quel bon outil SQLite3. C'est une base de données simplissime qui ne contient que des tables (ni index, ni vues, ni trigger, ni requête stockées). On peut donc supposer que les performances sont améliorables.

On peut aussi certainement bricoler un petit peu

. Par exemple, les presets "built-in" de DOP sont tout simplement marqué read-only dans la table. Une case à décocher et ils deviennent éditables.

C:\Documents and Settings\<utilisateur>\Application Data\DxO Labs\DxO Optics Pro\Storage\OpticsProDBv5.opdb

pereguilou · Octobre 16, 2008, 09:35:13

Citation de: Pat91 le Octobre 15, 2008, 10:08:43

À mon humble avis (et je vais encore me faire incendier), c'est une erreur de design.

En effet, le fichier sidecar (ou l'équivalent dans la base de données DxO) devrait contenir uniquement la référence aux presets utilisés et leur ordre d'application. Pas les réglages eux-mêmes. Seuls les réglages complémentaires appliqués en plus des presets devraient être stockés dans le fichier sidecar et/ou la base de données.

De cette manière, on pourrait éditer un preset et les modifications seraient automatiquement appliquées à toutes les images utilisant ce preset quand on les développerait car le fichier sidecar (ou l'équivalent dans la base de données DxO) ne contiendrait que la référence aux presets qu'il irait donc relire à chaque rechargement du projet en appliquant automatiquement (sur option éventuelle) de nouveaux réglages si le ou les presets ont été modifiés.

Cela présenterait également l'avantage d'alléger la base de données puisqu'on ne dupliquerait plus les réglages en question car ils seraient stockés dans un endroit unique: le preset.

En effet ton opinion est très discutable : à mon avis c'est une erreur. En effet elle ne pourrait s'appliquer que si l'on n'a pas modifié les réglages d'un preset, sinon la modification d'un set entrainerait de facto une altération de l'image, ce que chacun apprécierait je n'en doute pas. Si tu veux appliquer un tel principe, il faut aussi être capable de retrouver l'ancien preset non ? Je te l'accorde cela ne serait pas trop difficile !
Pour moi il est essentiel de conserver ce qui a conduit a une image donnée, certains te diront seulement l'image puisque toute réouverture d'un RAW implique une reconception, pardon un nouveau traitement, et peu importe que cela porte un nom ou pas.
Dans une autre vie j'ai eu à traiter de conception de matériel dont la durée de vie est très grande : dans ce cas sont archivées toutes les données d'origine et en particulier les normes. Personne n'imaginerait de remplacer toutes ces normes par leur nouvelle version et même si des mises à niveau sont effectuées, tant qu'une partie même infime d'un norme est appliquée, elle est conservée. Voilà ce qui me semble être un bon "design" et l'analogie avec le traitement photo ne me semble pas si déplacée.

Pat91 · Octobre 16, 2008, 11:56:40

Bonjour,

Citation de: pereguilou le Octobre 16, 2008, 09:35:13Pour moi il est essentiel de conserver ce qui a conduit a une image donnée

Donc, nous sommes d'accord

. C'est justement l'objet de ma proposition et c'est ce que DOP ne fait pas actuellement. Quelques remarques...

1. D'après un représentant de DxO, il semble qu'il y ait eu débat interne sur la tratégie actuelle versus le stockage de références sur les presets utilisés comme je le propose. La première solution l'a emporté mais je n'ai pas été convaincu par les arguments de celui qui l'a emporté. Voir forum DxO anglophone Général.

2. J'ai bien précisé que la propagation automatique des modifications des presets utilisés aux images déjà corrigées devrait être optionnelle. Cela permettrait à chacun de choisir la méthode qui l'intéresse le plus, si possible par projet.

3. Puisque DOP implémente un Undo, cela veut dire qu'ils conservent la trace chronologique des opérations appliquées (preset, réglage séparé,...). Répercuter cette trace dans la BD ou dans les fichiers sidecar n'est pas plus compliqué que de stocker le résultat global (final) des réglages. Si vous tenez pour essentiel de "conserver ce qui a conduit a une image donnée", il faut justement ne pas faire ce que DOP fait actuellement: stocker uniquement le réglage final sans aucune référence au cheminement qui a conduit à ce résultat.

4. Le stockage chronologique des commandes (pile de commandes) est la base même des logiciels implémentant des traitements non destructifs. C'est exactement ce que fait Lightzone (que je commence d'ailleurs à trouver de plus en plus sympa et intelligent). Il stocke consciencieusement et dans l'ordre chaque application d'outil ou de preset. À tout moment, je sais exactement comment je suis arrivé au résultat courant. Ma démarche n'est pas perdue et je peux en tester une autre si ça me fait plaisir.

L'approche que je propose pour DOP permettrait soit de continuer à fonctionner comme actuellement, soit de bénéficier d'un fonctionnement plus souple et plus riche. Et tout ça pour pas cher.