Compatibilité : à quel point ça sert ?

[aurelienpierre]

Je crois me souvenir que quelqu'un avait fait le parallèle avec python et la possibilité d'avoir plusieurs versions d'installées et de choisir laquelle utiliser. C'est peu-être trop compliqué pour dt ?

Je sais que cela rajoute du taf et que vous en faites déjà beaucoup.
Brider des devs bénévoles, c'est pas bon non plus.

Aurélien, tu comptes reprendre vraiment beaucoup de modules et donc n'avoir aucune compatibilité ?
Est-il possible d'avoir une version de dt ou plutôt un script juste pour faire l'inventaire de ce qui ne sera pas compatible pour aider les personnes concernées à faire un choix ?
(pour le script, je peux aider, pour le c, trop dur pour moi)

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.

---

@Aurélien: un autre point, pour en avoir déjà discuter avec toi. Si tu parles ici plus de flux interne qui si on le change risque de modifier le résultat final de quelques % (dE 2? 5?) sur les couleurs alors je m'en moque aussi. Si le résultat final est plus "cohérent" alors je suis pour. Comme tout le bruit que le changement du module de recadrage à fait car ça risquait de modifier quelques pixels de l'ordre de 0,01% !!!

Pour être précis ce qui est un grand NON pour moi c'est:
- de supprimer un module
- de changer un module qui fait qu'une image traitée avec perd tous les réglages et on doit recommencer
- de changer un module qui ferait des modifications de plus de 5 dE sur les pixels.

Pourquoi 5 ? Avec un dE de 2 on ne voit pas la différence, avec un dE de 5 on est dans l'acceptable. Donc je pense que cette limite de 5 est à garder en tête.

Aurélien, es-tu en phase avec ça?

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.