Bonjour, J’ouvre une nouvelle discussion comme recommandé par ailleurs. Et pour reprendre ce que j’ai écrit dans le fil consacré à filmique :
"Je suis utilisateur de dt depuis un peu plus d’un an sous Windows 10. J’ai installé la version 2.61 et comme j’avais des soucis déjà évoqués dans filmique, j’ai modifié le fichier darktablerc. Et ça fonctionne bien dans filmique. Mais il y a des choses bizarres comme par exemple dans effet Orton la zone de la photo devient entièrement noire dès qu’il est activé, dans renforcer la netteté la zone devient en partie noire si j’utilise un masque dessiné … Je suppose que ça vient de ma machine ? Je vais repasser en version 2.60, à moins que j’ai loupé quelque chose ?
Même si mon message ne le laisse pas supposer, je suis très reconnaissant aux développeurs de cet outil pour ce travail formidable ! "
Il semble que ce problème soit reproduit au moins par l’un d’entre vous. A suivre donc …
Je viens de faire quelques essais sur un PC avec Win10-1809 supportant l’OpenCL
Aucun problème.
Puis à partir d’un PC ne supportant pas l’OpenCL, je n’arrive pas à reproduire ce problème sous Linux, avec :
OS Manjaro Xfce avec dt 2.6.1-1 (du dépôt community d’Archlinux et fichier darktablerc corrigé manuellement)
OS Manjaro Xfce avec dt 2.6.1-2 (compilée par mes soins et patchée de la correction du bug de tassement de l’histogramme)
Mais sur ce même PC dans une session Win10-1809 avec dt 2.6.1 (version téléchargée et fichier darktablerc corrigé manuellement)
J’ai pu effectivement reproduire cette réaction, un gros rectangle noir, à l’activation du module Orton mais pas avec le module renforcer la netteté, masque dessiné ou pas.
Il semblerait donc que ce soit un problème distinct du tassement d’histogramme, néanmoins lié à l’OpenCL mais uniquement sous Win10.
Le module Orton m’a mis sur la piste des modules filtre passe haut et passe bas qui sont aussi affectés par ce soucis.
Je n’ai pas vu d’autres modules impactés.
Sinon il faut qu’il y ait au moins concomitance de filmique + balance couleur + l’un de ceux-ci : orton, filtre passe haut, filtre passe bas.
Pour illustrer le propos… vi encore fakir64… décidément.
Je reviens sur ce sujet, si j’avais pris la photo de fakir64 (extension .nef) pour illustrer ce que je disais, c’est que c’était à priori la seule avec laquelle je pouvais reproduire ce dysfonctionnement sous ma session Win10 sans l’OpenCL, mes photos étant du .raf soit compressé ou non compressé.
Mais non j’ai fini par trouver du .raf lui aussi impacté.
Il semble que ce soit un problème d’affichage lié au niveau de la quantité d’information de l’image, l’export étant correct.
Les zones de rectangle noirs n’apparaissent que pour des affichages compris entre « petit » et « ajusté à l’'écran », au delà tout va bien.
Partant de là dans les préférences de fonctionnement j’ai fait varier d’abord la méthode d’interpolation de dé-matriçage pour la vue en chambre noire… sans effet sur les photos testées, 8 raw d’origine différente. J’ai donc laissé à « complète »
Mais coté algorithme d’interpolation utilisé pour la rotation et correction d’objectif, là j’ai des résultats probants, plus je dégrade l’algo et plus j’ai des affichages corrects… néanmoins pour une .orf j’ai été obligé d’utiliser le plus lent, bilinéaire.
Mais avec ce réglage je n’ai plus le problème sur aucune des photos testées.
Précision : Quand je remet darktablerc en mode « false » les zones noires disparaissent (toute l’image dans effet Norton, une partie dans renforcer la netteté, mais je n’ai pas testé d’autres modules). Bien sûr, je peux utiliser Filmique mais sans cocher la case chrominance et sans utiliser les pré-réglages …
Là il s’agit de zones de l’image non rafraîchies à l’écran, voir l’image que j’ai ajoutée à ma première réponse.
Elles changent de taille ou disparaissent en fonction du % de zoom mais le traitement reste correct, les exports sont bons.
Ça indique clairement un problème lié au PC, sa carte graphique, les choix de préférences pour l’interpolation de l’affichage et bien sûr la présence ou non de l’OpenCL sur la machine.
Si de ton coté c’est un assombrissement d’image alors je pense ça n’a pas de lien avec le sujet traité ici.
Ouvre un fil de discussion avec un titre pertinent concernant ton problème, suit ces recommandations et illustre ton propos avec une capture écran.
@ MGJLOT
Oui c’est clairement un problème lié à la machine.
Tout en conservant le mode codepaths/openmp_simd=true dans darktablerc pour profiter de la chrominance dans filmique essaye de jouer sur les réglages disponibles au sujet de l’affichage dans les préférences.
Principalement :
Méthode de dé-matriçage pour l’affichage de la chambre noire
Algorithme d’interpolation pour la correction d’objectif et rotation
Mathématiquement une interpolation est une opération permettant de remplacer une fonction par une autre plus simple mais qui passe par un nombre fini de valeurs identiques à la fonction initiale (fonction = courbe en math).
Moins précis mais plus rapide à calculer pour le PC.
[hr]
Oui quand l’OpenCL est présent cela facilite le traitement, néanmoins sans l’OpenCL ça peut le faire aussi mais cela dépend de ce que le PC a dans le ventre. Un bon copro, gpu, ram en quantité voire un ssd et ce problème ne doit pas en être un.
MGJLOT
Bonjour,
je viens d’essayer avec darktable 2.6.1 avec windows 10, et effectivement le module Orton pose problème avec « préserver la chrominance » coché dans filmique.
Ça ne vient pas de ton ordi mais je pense du fait que tu sois sous windows.
Par contre je n’ai pas pu reproduire le problème avec renforcer la netteté et masque dessiné. Je ne peux pas en dire plus désolé.
je ne sais pas si quelqu’un pourra trouver une solution pour windows 10 rapidement.
Je remets cette réponse qui était dans l’autre fil qui a été fermé, sur la demande de jpg54
[hr]
Je précise que depuis hier j’ai fait un nouvel essai avec une autre photo et je n’ai pas eu ce problème, mais je n’ai pas trop creusé par manque de temps. d’habitude je suis toujours sous Ubuntu 18.04 et là tout fonctionne !
Justement, j’ai essayé avec la très réussie image de fakir64 sur mes deux PC :
le laptop a un proc i5 7200 assez puissant et un gpu intégré Intel et peu de ram (4 GB)
le desktop a un vieux proc i5 750 peu puissant et un gpu externe radeon HD 7770 et 12 GB de ram.
Donc des configs matérielles opposées. Dans les deux cas, je ne parviens pas à reproduire, avec et sans OpenCL (que le portable accepte).
Oui quoique la ram n’est pas le plus important.
Ton i5-7500 3,40 Ghz est en mesure de se débrouiller seul.
Mais ton i5-750 2,67 Ghz est épaulé par une carte graphique qui va faire le job et le gpu externe compense
Sur mon PC un i5-2430-M 2,40 Ghz qui doit se taper tout le boulot (proche en pref de ton i5-750) Réf des copro ici
Par contre mon PC sous Linux s’en débrouille, pas sous Win10… encore une victoire pour Linux
C’est juste un constat, pas une genèse de troll… off course
Plutôt un i5-7200U à 2,5 GHz, le gpu intégré étant un HD Graphics 620. Et ma vieille radeon n’est pas non plus un foudre de guerre …
Bref, tout ça pour dire que ça me semble être davantage un problème matériel même si la gestion de l’affichage est sûrement différente entre Windows et Linux (et en supposant que les pilotes soient à jour).
Oui mais l’union fait la force, i5-750 + HD 7770 + 12 Go de ram + l’OpenCL et ce PC un peu ancien supporte a priori les derniers développements de dt même avec un OS exigeant en ressources.
Avec l’apparition de filmique pas besoin de mesures, je ressens bien que certains traitements sont plus longs et le ventilateur qui monte dans les tours bien plus souvent qu’avant ne trompent pas.
Ceci en guise de conclusion, pour ceux qui ont le problème décrit ici il faut chercher à le contourner en utilisant les algorithmes d’affichage les moins exigeants, §8.2 du manuel, au besoin lire ou relire le §10 concernant les optimisations de mémoire, surtout avec peu de ram embarquée.
les modules impactés (Orton, passe-haut/bas, renforcer la netteté) utilisent tous un flou gaussien sur le canal L de l’espace Lab. Ce sont aussi des modules qui datent tous de 2011, du même auteur, et n’ont pas été testés avec l’option openmp_simd=true (qui est expérimentale). Le problème rencontré avec cette option activée ressemble à un bug que j’ai déjà réglé pour le module contraste de couleur (https://github.com/darktable-org/darktable/pull/1917), où le canal L n’était pas recopié correctement dans la sortie. Étant donné que, par défaut openmp_simd=false, ces parties du code ne sont en pratique jamais utilisées, donc pas débugguées.
Les problèmes de sections d’image noires ressemblent à des valeurs NaN de pixels qui sont improprement gérées. Ça se produit notamment quand on divise par zéro, le résultat n’est pas un nombre (NaN = Not A Number). Suivant la plateforme et le compilateur, les NaN ne sont pas gérés de la même manière (les joies du développement multi-plateforme). Si l’option « développement de haute qualité » est activée, l’interpolation est réalisée à la toute fin du pipe, donc les erreurs des modules précédents sont propagées aux pixels voisins. Comme l’interpolation est plus ou moins une moyenne des n pixels voisins, elle propage les NaN de proche en proche. L’interpolation bilinéaire utilise les 4 pixels les plus proches, l’interpolation Lanczos 3 utilise les 9 pixels les plus proches, donc le fait que les méthodes les plus simples rendent le problème moins visible est cohérent. De toute façon, je recommande de laisser l’option « développement de haute qualité » désactivée tout le temps, vu qu’elle revient à interpoler des pixels encodés non-linéairement (et n’est pas donc de si haute qualité que ça).
Le fait que l’option openmp_simd=true ralentisse le calcul est normal. L’option par défaut (sse2) utilise des fonctions vectorisées à la main. L’option openmp utilise des fonctions vectorisées automatiquement par le compilateur, qui déduit tout seul ce qu’il peut vectoriser ou pas, et implique donc d’écrire son code d’une certaine manière, pour donner des indices au compilateur (ce qui n’est pas une pratique courante dans le développement de darktable). Donc en pratique, avec openmp_simd, le code n’est pas vectorisé, ou presque pas.
Rapidement, la vectorisation, c’est une façon de tirer parti des processeurs modernes en traitant les pixels de façon jointe. Dans un code non vectorisé (= scalaire), on traite chaque canal RGB de chaque pixel individuellement. Ça veut dire qu’on va chercher la valeur d’une composante RGB dans la RAM, on la copie dans le processeur, le processeur calcule la sortie, recopie le résultat dans la RAM et passe à la composante suivante. C’est lent.
Dans un code vectorisé, on copie un vecteur, c’est à dire 4 (génération SSE/SSE2 ~ 1999 - 2004), 8 (génération SSE3/SS4 ~ 2005 - 2007), voire 16 (génération AVX512 ~ 2013) composantes RGB en une seule fois (donc on traite 1, 2, ou 4 pixels à la fois), de la RAM au processeur, le processeur les calcule d’un seul coup, et recopie tout le monde à la fin. C’est beaucoup plus rapide, mais ça impose que les composantes RGB soient indépendantes les unes des autres (en gros : la valeur G ne dépend ni de la valeur R ou B). Du coup, quand le compilateur détecte une possibilité (même fausse) de dépendance entre les composantes du vecteur RGB, il annule la vectorisation et opte pour l’option scalaire, lente mais sécuritaire pour le calcul.
Tout ça n’a rien à voir avec la quantité de RAM ou les performances « brutes » du processeur (fréquence d’horloge, taille du cache, etc.). C’est vraiment juste au niveau de la capacité du code à tirer partie des possibilités du processeur, qu’on active ou pas, suivant comment le code est écrit et ce que le compilateur comprend.
Encore une super explication Aurélien, c’est sûr que l’on est très loin du temps ou le processeur était composé qu’une mémoire de travail et un accumulateur.
Merci Aurelien pour ces explications détaillées et argumentées toujours très instructives, ma démarche pour essayer de comprendre le problème n’étant pas basée sur une connaissance du code, que je n’ai pas, est forcément plus empirique.
Oui, je plussois, si pascalG n’a pas le soucis c’est probablement que son openmp_simd est à false, tout comme moi avec ma version de dt corrigée pour Linux, pas sous ma WIN10 où il est à true. Bon à savoir pour ces modules, du coup ce serait bien de revisiter leur code avant la 2.6.2.
Quoique pour renforcer la netteté je n’en suis pas sûr, n’ayant pu reproduire ces affichages de zones vides avec lui.
Effectivement ces pixels sont sans valeurs si issus d’une /0 qui sort le résultat du domaine fini et passent NaN.
Eh oui bien sûr c’est normal, mais sur ma version corrigée ce paramètre est à false, il n’empêche que les ressources demandées en calcul ont dû progresser depuis la 2.6.0, « ressenti » de ma part je n’ai pas fait de mesure pour le quantifier mais avec filmique je n’utilise plus certains modules, remplacés par d’autres. Balance couleur ou l’égaliseur, par exemple, qui sollicitent fortement le cpu, ceci expliquant peut-être cela.
A priori si j’interprète bien ce que tu dis le code de dt est « malin », il sait exploiter au mieux soit cpu ou gpu et au besoin passer dans un mode sécuritaire et c’est tant mieux, il n’empêche que mon i5-2430-M pédale à 100% de tous ses « core » pendant de longues secondes pour arriver à bout des calculs avec certains modules. Dt est forcement exigeant en calculs, si l’aspect matériel n’est pas à l’origine du problème décrit ici, et transparent encore une fois pour ceux qui accèdent à l’OpenCL, il n’empêche qu’il respire mieux avec un processeur puissant.
Je monitore attentivement les performances quand je programme, a priori il ne devrait pas y avoir de différence entre dt 2.6.0 et 2.6.1. Si tu peux me fournir des mesures (en lançant darktable -d perf
en console), ça m’aiderait (en particulier pour la balance couleur, chez moi ça tourne entre 35 et 45 ms en résolution 4K sur CPU, je suis surpris - est-ce que tu utilises la fusion avec adoucissement du masque ?).
dt n’est pas vraiment malin, c’est le compilateur qui fait ce qu’il peut en fonction de ce qu’il a. J’ai plusieurs pistes d’optimisation en cours, dont une qui consiste à précompiler les fonctions pour différentes générations de processeur (SSE2/3/4, AVX2/512) de sorte que les paquets précompilés aient des optimisations spécialisées. Pour l’instant, les paquets des dépôts utilisent des optimisations SSE2 basiques (supportées par toutes les architectures), pour bénéficier des optimisations spécifiques pour ton matos, il faut compiler toi même avec le flag -O3 (ou sh build.sh --sudo --build-type Release --install). Du coup, ça veut dire que pour l’essentiel des utilisateurs, dt utilise peut-être 50-75 % du potentiel CPU.
Ah ouais, quand même ! Il faut vraiment que je m’y mette. C’est quand même dommage de ne utiliser dt à plein. Je pensais que la différence entre dépots/compil était plutôt de l’ordre de 10% (précision pifométrique).
