En ce qui me concerne la rétro compatibilité n’est pas un must. En passant de Lr à darktable je l’ai perdue pour une large part et en fait lorsque je dois revenir sur une ancienne photo je préfère recommencer l’ensemble du traitement. Ceci dit, je conçois que ce puisse être très différent en fonction de la pratique photo des uns et des autres (et notamment des photographes professionnels)
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.
Il faut voir cependant que dt est compilé, en C, avec du code optimisé bas niveau. Non seulement l’interface C de GTK est une merde immonde, le code est dégueu, et on a plein de soucis de performances avec, mais aussi la majorité des bugs qu’on ramasse sont des problèmes liés à des architectures particulières ou à Mac et Windows, sur lequels ça compile pas pareil et où on a 1 dev pour chacun.
Du coup, il y a des tas de fonctionnalités à tiroir, au cas par cas, qui me prendraient une journée à coder sous Python, qui prennent des semaines de tests parce CLANG plante mais pas GCC, ou le code OpenCL ne se comporte pas pareil entre Win et Nux, et il faut recoder 3 fois chaque fonctionnalité (C + SSE + OpenCL)… Bref, je préfère éviter les spaghettis et rester aussi systématique que possible.
Dans ma ligne de mire immédiate, il y a la courbe des tonalités en mode XYZ. Ça n’a aucun sens de travailler dans cet espace, et la preuve c’est que ça va jaunir les couleurs. Par contre, le mode xyY permet ce que la fonctionnalité dit : corriger la luminance sans toucher à la chrominance. Là, on est sur une erreur d’implémentation. Du coup, je serais bien tenté de changer l’espace de couleur de façon silencieuse.
En gros, le canal Y de XYZ ou de xyY, c’est le même (la luminance), mais x = X / (X+Y+Z) et y = Y / (X+Y+Z), donc on modifie Y puis on corrige les canaux de façon proportionnelle pour garder la chrominance. En l’état actuel, on applique la même transformation à X, Y et Z.
[hr]
Alors, dE… lequel ? 
(Il y en a au moins 5)
Dans l’idée, je suis d’accord. Sauf qu’en pratique, il faut voir si on parle du dE à la sortie du module impacté, ou à l’issue du pipe. Et dans les deux cas, c’est compliqué à prévoir, et une simple mesure sur les cas pratiques n’est pas un garantie.
Et puis, après, il y aura les fâcheux qui vont retourner l’argument du dE : à quoi ça sert de faire le changement si au final on ne voit pas la différence ? C’est ce que Parafin avait sorti quand j’avais essayé de bouger de module de correction des objos, dont le profil de vignettage devient complètement invalide dès qu’on touche au noir de l’exposition.
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
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 Lab* 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 ?
Ç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.
[hr]
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.
[hr]
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.
C’est quoi dE et lesquels 5 ?
DE ça doit être delta E et 5, la valeur du delta E. Le delta E permet de mesurer le décalage entre deux couleurs. Une valeur inférieure à 2 est indiscernable par l’œil humain.
Merci Jean-Pierre.
Peut-on imaginer peut-être qu’à la mise à jour fatale, un script génére un tiff automatiquement groupé au raw?
Ou quelque chose du genre?
S’en exposer les motivations (j’ai essayé cela fait un long post), voilà ma situation:
[list]
[]dt est mon catalogueur d’images raw-xmp
[]j’exporte uniquement au besoin
[/list]
J’ai « besoin » et j’apprécie de cataloguer en raw car quand je le consulte il m’arrive de reprendre-continuer le traitement.
C’est du « vrai » traitement et aussi du fignolage parfois long et fastidieux dans mon cas avec le « module retouche »
Et quand je dois fournir des photos j’exploire tout mon catalogue. Je n’ai pas forcèment besoin de shooter pour une demande.
Donc oui j’aimerai bien continuer ainsi 
Peut-on imaginer peut-être qu’à la mise à jour fatale, un script génére un tiff automatiquement groupé au raw?
Ou quelque chose du genre?
Non, impossible de demander à l’utilisateur d’attendre deux ou trois jours J’ai 52k images, certains plus de 100k!
Bonjour,
Je crains de ne pas totalement d’accord avec l’avis majoritaire ici… Pour mon utilisation, la perte de la compatibilité serait en effet un très gros problème :
[list=1]
[]J’ai certains fichiers avec beaucoup de tampons, avec des masques parfois très complexes, travail qui a demandé un temps certain… A l’heure ou le module « retouche » remplace avec brio celui de « correction des tâches », on pourrait qualifier ce dernier d’obsolète (pas de problème) voire le supprimer (arghhhh) Ceci n’étant qu’un exemple, mais reproductible avec d’autres modules dès lors que l’on dépasse les réglages basiques (masques, plusieurs instances, …)
[]Mes post traitements sont « anarchiques » (comme beaucoup d’amateurs je suppose), je zappe d’un dossier à l’autre au gré de mes envies, je dégrossis souvent pas mal de photos, mais n’en affine que certaines par manque de temps/envie… Et quand je dois montrer à la famille qui passe les photos du dernier voyage en Islande, j’ouvre dt, filtre par image travaillées et zou (même si toutes ne sont pas finies à mon goût cela convient parfaitement) Et là si on perd la retro-compatibilité ben j’ai plus rien, les photos non « finies » n’étant pas exportées !
[*]D’un point de vue plus général, je pense que cela saperait grandement la confiance que les gens ont dans ce logiciel qui gagnerait une étiquette « non-finalisé » qu’on le veuille ou non !
[/list]
Si gros changements il doit y avoir, je plaiderais plutôt pour faire comme avec l’ancien module egaliseur (voir post de Pascal) : marquer le module obsolète pour qu’il ne s’affiche que pour des anciens traitements ayant utilisé ce module. (et tant pis pour moi si il est instable/vilain : je n’ai qu’à utiliser le nouveau !)
(On peut même faire la même manip à l’intérieur même d’un module : c’est ce qui c’est passé dans le module recadrage quand l’ancien système de « keystone » a été remplacé par un nouvel outil de perspective. Mais là ça met vraiment le boxon dans le code !!!)
Voilà, c’était « my 2 cents » comme qu’ils disent là-bas !
Bonne soirée
Ça c’est le delta E 1976. Il y aussi le delta E 1993, 1997, 2002, 2010 (de mémoire)… Et des delta E qui tiennent compte de la luminance, d’autres seulement de la couleur…
Et puis en fait, (delta E < 2) == indiscernable à l’œil, ça dépend où dans le spectre… Autour des bleus, ça n’est pas vrai. Le delta E se base sur l’espace de couleur Lab (1976), qui a une discontinuité autour du bleu.
Et puis aussi… Je me tape pas mal de papiers « scientifiques » autour de la couleur, depuis 3 mois… Toutes les recherches sont faites sur des groupes test de 14-18 personnes, généralement des étudiants du prof qui publie le papier (comprendre : des américains blancs, jeunes et riches). Ça serait un scandale si on testait des médicaments comme ça, mais dans le monde des sciences de la couleur, il semble que ça soit un échantillon statistiquement représentatif. (WTF ?)
Il y a aussi très peu d’études qui comparent comment les pros de l’image et le public général voient les couleurs, et celles qui prennent le temps de le faire montrent de sacrée différences. Bizarrement, les pros ont l’œil (beaucoup) plus affûté.
Je n’ai vu aucune étude qui compare différents peuples non plus, parce que la couleur est une donnée culturelle (par exemple, les japonais utilisent le même mot pour dire vert et bleu → est-ce qu’on peut distinguer une couleur qui n’a pas de nom ?).
Bref… Dans le petit monde de la colorimétrie, y a juste les membres de la Sainte Église Apostolique du ICC qui pensent que c’est une science, et le grand public qui se pense hors de danger dès qu’il a foutu un profil d’étalonnage bancal sur son écran. Dès que tu grattes la surface, ça fait peur.
Je remets mon avis déjà donné dans un autre fil.
Pour compléter cela, après avoir lu les messages de ce fil : j’ai cru comprendre qu’il était possible de 1) marquer des modules comme obsolètes ; 2) conserver ces modules dans le pipeline, même si pas affichés (??). Dans ce cas, pourquoi ne pas partir avec une nouvelle version majeure avec :
- la duplication de tous les « module » en « module_ng » ;
- l’affichage par défaut de seulement les « module_ng » dans l’interface ;
- la concentration du développement uniquement sur les « ng »
Ainsi, darktable serait toujours capable de charger les vieux « module » de vieux XMP, avec des réglages qui fonctionnent toujours, et des exports possibles et identiques (pour les photographes ayant besoin de recharger/réexporter des images déjà traitées) ; mais par défaut les nouveaux modules sont ceux où les améliorations continues seront faites. On pourrait imaginer une option dans les préférences de darktable permettant de n’afficher que les modules « ng », ou d’afficher les modules « legacy » pour les personnes qui ont absolument besoin de traiter des anciens développements.
Je pense que ça implique des efforts au départ, avec des doublons qui vont être extrêmement casse-noisettes à gérer, mais ça permettrait un virage progressif vers des nouveaux modules pour tous ceux que ça ne dérange pas. Quitte à un jour déprécier totalement les « legacy ».
Il serait aussi envisageable (sur une base volontaire, bien entendu), de sonder les modules utilisés en scannant les fichiers XMP de la bibliothèque, et voir quels modules sont réellement utilisés, à quelles fréquences etc. Je pense que certains modules apparaitraient alors sous un jour différent (très utilisés ou alors totalement abandonnés, cela donnerait des arguments en faveur d’une dépréciation ou d’un effort de développement).
Merci Aurélien d’avoir précisé dE. 
@techexo : pourquoi ne pas partir comme cela?
Car comme l’a expliqué Aurélien dans une précédent post le problème n’est pas que dans les modules mais aussi dans du code générique qui gère le flux des pixels et tout particulièrement dans la gestion des espaces couleurs. Et ce changement ne peut pas être fait aussi simplement. Faire un second pipe complet ne serait que complexifier le code énormément.
Une solution est de se dire : tant que mes pixels sont modifiés en dessous d’un certain seuil on y va.
Pour cela il nous faudrait d’abord des mesures. J’aimerais bien voir des tests ajoutés dans dt pour vérifier ces écarts. Cela permettrait aussi de détecter des gros bugs.
Voilà, et tout cela va demander beaucoup d’énergie… le nerf de la guerre
Les bretons aussi . Parce que quand tu sors par force 10, les deux se mélangent un peu 
.
Et pour une histoire culturelle des couleurs (Européenne en tous cas) → Michel Pastoureau
Je ne stocke mes photos qu’en RAW depuis quelques années … La non rétro-compatibilité signifierai pour moi je le suppose la perte de tous mes traitements ! Je suis le seul dans ce cas ?
@nca000: non on est plusieurs à penser comme toi. regardes les messages plus haut.