Problème avec la fonction préserver la chrominance lorsqu’elle est cochée.
Elle tasse l’histogramme complètement sur la gauche.
Pour illustrer mon propos, en exemple l’autoportrait de fakir64 dont on trouve le raw et l’xmp ici dans « Éditer mon raw »
Même problème, mais j’ai réussi un développement correct sans cocher « préserver la chrominance » .
Bonjour, idem pour moi.
De plus, il ne semble pas y avoir de possibilité de rattraper ce tassement à gauche quelque soit le module utilisé pour tenter de corriger cela.
pour information j’utilise la version Windows x64. Peut-être est-ce propre à la version Windows…Peut-être allons-nous voir une 2.6.1.1…
Bonne journée à tous
J’ai les deux versions, sur Windows la 2.6.1 et sur Ubuntu la 2.6.1.1 et le même problème, mais comme filmique ne réagit apparemment pas comme dans la version 2.6. Il va falloir modifier nos habitudes je pense…
La version 2.6.1 apporte en effet des améliorations qui changent la pratique de ce module. Quand on les maîtrise, c’est plus efficace que la version 1 sortie avec la 2.6.0. Si tu ne l’as pas encore fait, je te recommande de lire le chapitre « filmique » du manuel de la 2.6 que j’ai publié hier.
Sinon, il peut être bien de mettre un lien pour récupérer ton fichier .xmp. Ton historique ne donne que les modules que tu as activé, et non les réglages. Par contre, de manière générale, la courbe des tonalités n’est pas très adapté à un usage avec filmique. Tu pourras le lire dans le manuel d’ailleurs.
Merci pour la traduction du manuel, oui je l’avais lu et attendais avec impatience de pouvoir tester cette version sous dt 2.6.1.
Je comprends qu’il soit nécessaire de prendre en main cette nouvelle version, néanmoins la fonction « préserver la chrominance » semble totalement inexploitable et comme le disent KOntol, ça ne semble pas rattrapable, ou JMM40 qui a le même pb sous Windows aussi, à priori ça ne viendrait pas de mes binaires compilés pour une Archlinux… ce que je pensais de prime abord.
L’image de mon essai et l’xmp est disponible sur le fil de discussion de cette (belle) photo de fakir64 « Editer mon raw »
Suffit de l’ouvrir avec son xmp pour avoir ce résultat. Ayant un Fuji j’avais cherché une photo à matrice plus courante, pensant que le X-trans Fuji pouvait être une cause de ce problème.
Enfin j’ai constaté que toutes les photos que j’avais antérieurement traitées avec filmique, y compris celles n’utilisant pas « préserver la chrominance », n’ont plus du tout le même rendu… heureusement que j’exporte mes photos une fois satisfait du résultat.
Mais pour les reprendre il faut repartir presque au début du workflow. 
Rebonjour, vu le rendu obtenu et l’impossibilité de rattraper le tassement à gauche de l’histogramme, il y a peu de chance qu’il ne s’agisse pas d’un bug.
@JacoTux, selon moi ton problème de rendu généralisé sur l’ensemble de tes anciens développements (idem pour moi) sera corrigé après correction de ce bug. Tu devrais attendre un peu la suite de cette histoire avant de reprendre les développements réalisés avec des versions de DT <2.6.1
Bonne soirée
En fait, il y a effectivement un résultat que je ne connaissais pas sur la 2.6.1. J’utilise en effet depuis le début de l’année uniquement la version master et le résultat avec le même RAW et le même XMP me donne des résultats différents sur la 2.6.1 et l’une des dernières révisions master. Je pensais qu’il n’y avait pas de différence sur filmique entre la 2.6.1 et la master mais il semble que si (ou alors il y a un lien/impact avec d’autres évolutions ; ou un bug comme l’évoque K0ntol). Bref, c’est bizarre ce résultat sur la 2.6.1…
Voici ce que donne cette image et l’XMP de fakir sur les 2 versions chez moi (et je n’ai fais que charger le RAW avec son XMP à côté, sans rien modifier) :
2.6.1
master (révision 2b0eb6d4)
Aurélien, si tu passes par là, ton avis est le bienvenu.
Oui c’est bien ce que je compte faire avant de réutiliser ou ré-exporter d’anciens clichés traités, ou alors cloner avant même d’aller dans la chambre noire afin de générer un « new » xmp.
[hr]
Ahhh, oui effectivement avec ta version master ça semble tout à fait correct.
Attendons l’avis d’Aurélien.
Je penche effectivement pour un problème. J’ai fait un essai en partant du RAW (sans xmp) donc à neuf, depuis la 2.6.1. Si je fais mes réglages habituels (ceux me donnant un bon résultat sur la version master), c’est-à-dire déjà de base réglage de la balance des blancs, désactivation de la reconstruction des hautes lumières (dans l’absolu, activé ou désactivé, ça ne change rien sur cette image) et l’exposition avec le réglage auto puis filmique en rentrant manuellement les paramètres tels que sur le xmp de fakir, tout va bien jusqu’à ce que j’active « préserver la chrominance ».
J’ai pourtant beaucoup utilisé filmique depuis sa sortie, en version 2.6.0 comme sur les différentes révisions master depuis, je n’ai vraiment pas souvenir avoir eu ce problème (même sur cette image où j’avais fait une proposition). Ça sent le bug ?!
Je n’ai pas testé 2.6.1 mais vos résultats ne sont pas normaux. La version master fonctionne sans problème depuis près de 3 mois, je pencherais pour une erreur à l’intégration de master → 2.6.1
[hr]
Bingo, j’ai trouvé. Le patch https://github.com/darktable-org/darktable/pull/2030/files n’a pas été intégré dans 2.6.1.
[hr]
Bon voilà https://github.com/darktable-org/darktable/issues/2176
Il faut un (hard)core dev pour s’en occuper (Pascal 
)
Pour info, j’ai le même comportement en utilisant les nouveaux préréglages proposés dans la 2.6.1, vraisemblablement parce qu’ils utilisent l’option « préserver la chrominance »
Merci Aurélien et bien vu concernant la détermination de la cause de ce comportement.
Merci d’avance @Pascal
Normal du coup. Comme Aurélien vient de le signaler, un patch (une ligne d’après ce que j’ai vu) manque dans la 2.6.1. C’est donc bien un bug de la 2.6.1, ou plutôt un patch oublié dans son intégration qui fausse complètement les résultats de filmique. En bref, filmique est inopérant en l’état sur la 2.6.1. Ca devrait vite être corrigé avec une mise à jour pour corriger cela. Un peu de patience.
D’autant qu’en usage normal (celui que j’ai avec la version de filmique incluant ce patch donc), le résultat est meilleur avec l’option « préserver la chrominance ». Sans cette option, les images bien réglées via l’exposition et filmique sont plus ternes, les couleurs reprennent vie en quelque sorte avec cette option
En l’état, ne vous fiez surtout pas à ce module dans la version 2.6.1 actuelle.
Module très recommandé, avec l’option « préserver chrominance » autrement sur toute autre version (2.6.0, master ou la prochaine qui inclura le patch).
Je précise que ce bug n’affecte pas la variante OpenCL.
Bonjour Aurelien, je ne comprend peut-être pas bien, mais sous Windows 10 j’utilise l’OpenCL et j’ai le problème.
Arhhhhhhhh, merci de retourner le couteau dans la plaie. 
J’avais déjà le problème des halos de bord à l’affichage avec le laplacien local du contraste local.
Je n’ai plus qu’à changer de PC si je comprends bien.
Il n’est probablement pas actif alors.
[hr]
Personne n’a dit ça, c’est un bug identifié. On a 3 versions du code, la seule sur les 3 qui est impactée est la version CPU SSE2. Tu peux aussi aller dans darktablerc et chercher codepaths/openmp_simd=false et le passer à codepaths/openmp_simd=true, du coup c’est la version pure C (plus lente) qui sera utilisée.
Oui bien sûr personne ne l’a dit… j’étais juste dans l’idée que je cumulais sur les deux dernières versions de dt avec l’OpenCPL qui n’est pas prise en charge sur mon matériel.
Par contre je ne vois pas bien ce que l’Open Multi-Processing et SIMD change pour le coup, false ou true pas vu de différence.
Tenté aussi de basculer pour le jeu d’instruction SSE2, des fois que… mais sans effet.
Filmique ne marche pas comme il devrait avec SSE2=false et SIMD=true ?
C’est bizarre parce que la ligne manquante dans le code, corrigée par le patch en référence plus haut, n’impacte que la fonction SSE2. Les deux autres fonctions (OpenCL et pur C avec SIMD) sont totalement indépendantes.