Compatibilité : à quel point ça sert ?

[aurelienpierre]

J'ai un avis un peu différent, j'utilise darktable depuis les premières versions, je ne cherche pas à récupérer des traitements anciens mais il faudrait un système qui permet de faire une purge des anciens .xmp pour ne pas se retrouver avec un message d'erreur d'ouverture.

Ouvrir les anciens XMP ne sera jamais un problème.  Au pire, si une entrée XML n'a pas de référence dans dt, on la saute. Le souci se trouve au niveau de l'application des anciens paramètres : si on change les algos, les mêmes réglages n'auront plus les mêmes effets.

Aurélien,

Personnellement, la compatibilité de mes anciennes photos dans une nouvelle version de Darktable  m'importe peu. Je ne retravaille jamais mes anciennes photos. 

Mais si par exemple Filmique impliquerait de supprimer la courbe de base par exemple cela me poserait un problème non pas de retro-compatibilité mais d'automatisation de mon travail. 

Je m'explique, pour des raisons de production, j'ai automatisé des réglages pour certains travaux répétitifs qui m'évites de travailler de grandes quantités de photos. Et avec filmique je n'arrive pas à avoir un pré-réglage commun à une grande série de photos, je suis obligé à chaque fois de configurer filmique.

Donc supprimer certains modules peut-être un problème  en fonction des modules impliqués dans la suppression.

Ça ça m'intéresse, parce que normalement, filmique devrait être reproductible pour peu que l'exposition soit constante.

Après, c'est le souci de la chaîne de traitement de la couleur. Les valeurs RGB vont de 0 à 1. 1 = 100 %. Mais 100 % de quoi ? C'est juste 100 % du seuil de saturation du capteur. Ça ne me donne pas la valeur absolue de la luminosité.

Du coup, filmique suppose que 100 % = blanc diffus (une feuille blanche). C'est sur cette hypothèse que toute la chaîne de couleur ICC est construite. Du coup, le gris moyen (50 % en Lab) est à 18.45 % en XYZ/RGB. 18.45 %, c'est 2.45 EV sous le blanc. Bingo, c'est la valeur par défaut dans filmique.

Si tu exposes à droite, dans ta photo, alors 100 % = source lumineuse (lampe/soleil/nuages etc.). Du coup, le blanc diffus est peut-être à 50 % RGB/XYZ, et le gris se retrouve à 50 % × 18 % = 9 %. Mais filmique n'a aucun moyen de le savoir… lui voit 100 %, il ne sait pas de quoi.

Ce qu'il faudrait, c'est arrêter de normaliser l'encodage entre 0 et 1 la sortie de capteur, et le garder absolu entre 0 et + infini. Alors, on aurait un gris fixe à 18.45 %, un blanc diffus à 100 %, et des valeurs supérieures à 100 % quand même enregistrées. Mais il faudrait abandonner la chaîne ICC en entrée, et modifier les convertisseurs analogique/numérique des appareils.

En attendant, si tu veux automatiser, tu peux utiliser un pré-réglage avec le module exposition en mode auto : mets le centile 50 % à -2.45 EV, avec un niveau de noir à -0.0010 pour être sécuritaire. Puis dans filmique, tu mets le gris moyen à 18 %, le blanc à 2.45 EV, et le noir autour de la valeur de plage dynamique de ton appareil photo - 2.45EV, puis tu ajustes la courbe à ton goût. Puis tu colles ça dans un pré-réglage ou style, comme tu veux. Ça devrait marcher assez bien.

---

Y'a pas une histoire de numéro de version de l'algo qui permet de régler ce problème ? En gros, chaque enregistrement des données d'un module dans les XMP contient un numéro correspondant à une version du traitement dans le module.

Exemple : le module "zone" dont tu dis qu'il fonctionne mal. Dans les XMP les données de "zone" sont ou seraient complétées du numéro 1. Tu changes l'algo de "zone", tu le passes par exemple de L*a*b* en RGB. Évidemment les réglages ne sont plus valables, bien que l'interface n'aie pas changée. Du coup le nouveau code porte un nouveau numéro : 2 et les fichiers XMP qui utilisent ce nouvel algo ont aussi le numéro 2 pour les données de "zone". Du grec ça, pas de problème de réglages inappropriés. Et si on décide de faire disparaître le code d'un vieil algo totalement obsolète, au moment du chargement d'un vieil xmp, soit le module sera activé avec ses réglages par défaut, soit il ne sera pas activé.

J'ai dit une c...erie ?

En effet, chaque module a un numéro de version sauvegardé dans le XMP, mais c'est utilisé juste pour traduire les anciens paramètres dans le nouveau format. Le module en lui-même ne sait pas de quelle version ils sont originaires. Ceci, la courbe des tonalités a un truc comme ça : si les réglages viennent d'une version antérieure, les valeurs hors [0; 1] sont tronquées, sinon il y a un mécanisme pour s'en occuper. Le problème, c'est des algos à branches comme ça (si (vieille version) -> tronque, sinon -> autre chose) ralentissent le programme et rendent le code progressivement illisible.

---

Le parallèle avec python, c'était juste pour savoir si c'est possible d'avoir deux versions de DT sur son ordinateur et de gérer cela simplement comme python.
Pour le reste, tu m'as perdue ?, même si j'imagine bien le problème.
Envoyé de mon ZTE A2017G en utilisant Tapatalk

C'est pas franchement simple, avec Python 2 et 3, les syntaxes ne sont pas compatibles, donc ton code n'est pas réversible. Là, ça serait pareil, darktable prévoit la migration des réglages vieux -> neuf, mais pas dans l'autre sens, et ça serait destructif dans le sens arrière.