J’ai depuis quelques semaine développé, relus et intégré pas mal de chose. Le temps me manque pour tous tester donc je viens ici pour vous encourager à tester ces nouveaux modules si vous compilez darktable depuis les sources. Et donner vos retours sur le GitHub correspondant (lien ci-dessus).
J’en profite aussi pour féliciter Aurélien qui fait un boulot extraordinaire et sur le fond, j’ai intégré son nouveau mode pour le module « balance des couleurs » aujourd’hui!
Assez inquiet en ce moment, car je suis pratiquement le seul core dev sur dt, tous les autres sont absents depuis des mois
Dernière question pour Aurélien, je ne sais pas trop quoi faire avec le module « unbreak profile », je ne l’ai pas pris en main encore. Est-ce important pour la 2.6? Comment faire une relecture et intégration efficace? Je pense (peut-être à tord) que cela sort un peu de mon domaine de compétence
Enfin, rawfiner et Aurélien préparez vous pour écrire la documentation pour ces nouveaux modules. Ulrich Pegelow vous demandera cela. En format texte simple, c’est ensuite Ulrich qui intégrera cela proprement dans les fichiers doc de dt.
En tout cas, la 2.6 sera un très bon cru… et à consommer sans modération.
Merci d’avoir intégrer le mode d’Aurélien de la « balance des couleurs », je dirais pas assez tout le bien que je pense de cette méthode de traitement des couleurs et suis admiratif pour le boulot qu’il a fait là.
C’est la même chose pour là « correction du profil d’entrée », depuis le début ou j’ai compilé cette nouvelle version, ej en suis rendu compte que cette approche permet de récupérer plus rapidement des photos que je considérais comme bonnes pour la poubelle. J’arrive plus rapidement à traiter les RAW qu’avec la « courbe de base » en fusion d’exposition. Je ne comprend pas pourquoi ne pas l’intégrer à la prochaine version surtout qu’il est possible d’utiliser l’ancienne méthode qu’elle ne remplace pas.
Pour le module unbreak color profile, tu as vu le résultat que j’ai montré sur pixls.us : combiné avec la balance des couleurs, c’est un duo de choc pour avoir une exposition parfaite et des couleurs exactes en 3 clics, peu importent les conditions de luminosité (même si c’est surtout fait pour le HDR). On peut demander ce que les autres en pensent sur IRC. Roman est classiquement assez réactionnaire.
Pour la doc, c’est prévu. Comment on fait pour traduire les modules ?
J’ai également testé la modification d’Aurélien de la correction du profil d’entrée, combinée avec la balance des couleurs j’ai pû rattraper facilement des contre-jours complexes.
Pas de soucis pour écrire de la doc
Pour les personnes qui passeraient ici et qui ne sauraient pas comment faire pour compiler et tester sous linux, j’ai fait un guide avec docker : https://drive.google.com/open?id=1Bf-wid1bXxaLja9oGsDZhdR65OCKtRs7
Avec ce guide, vous pourrez compiler la version de la branche « dev » d’Aurélien, qui contient ses dernières modifs ainsi que les miennes.
[hr]
Un test intéressant à faire, qu’il faut essayer sur des images diverses (provenant de plusieurs boitiers) :
Dans le module mixeur des canaux, selectionner « gris », et mettre un canal à 1 et les autres à 0, afin de visualiser un canal particulier.
Par exemple, si on a mis le bleu à 1 et les autres à 0, on ne voit que le canal bleu.
Puis aller dans le module de débruitage, et augmentez ou baissez fortement la courbe du canal rouge, puis celle du canal vert, puis celle du canal bleu. Si tout va bien, l’image ne doit changer fortement que lorsque vous changez la courbe qui correspond au canal que vous voyez. (L’image peut changer très legerement même lorsqu’on débruite un autre canal dans le cas du module de reduction de bruit raw, c’est à cause du dématriçage).
Si vous voyez un comportement anormal, dites le
J’ai corrigé un bug lié à ça il y a qques minutes que j’avais pas vu parce que j’avais pas testé avec suffisamment d’images
Docker installé, dt d’Aurelien compilé et installé.
(bien pratique ce docker pour ne pas abîmer ses fichiers de config)
Je ferai le test proposé par rawfiner demain, ce sera ma modeste contribution.
Merci à tous (Pascal, Rawfiner, Aurelien …) pour ce travail énorme …
Je suis passé par Docker pour compiler DT (Version d’Aurelien) et j’en ai pris plein les yeux. Que ce soit pour les nouveaux modules, ceux qui ont été modifiés mais également l’ergonomie.
Encore Bravo.
Petite question, pour les fichiers de traduction (et en générale, pour les mini modifs), est ce qu’il vaut mieux faire une pull request, envoyer un patch sur la mailing liste développeurs, t’envoyer un patch à toi, ou autre ?
Pas de PR, le fichier de traduction est à chaque fois pas mal modifié par l’outil donc on a de grande chance d’avoir des conflits de merge. Le mieux est d’en discuter ici et je m’occuperais de la traduction. J’échange régulièrement avec Michel Leblond qui s’occupe du manuel par exemple.
Tu veux parler de RGB vs RVB ? Dans tout dt on ne traduit pas se terme qui est globalement plus connu en RGB. Ceci était le cas même bien avant que je reprenne la traduction Française.
Concernant le « unbreak profile » d’Aurélien :
Le mappage sur [L18,L96] est codé en dur dans le code, n’est-ce pas contradictoire avec la chasse aux valeurs codées en dur de ces derniers jours ?
Certaines mires de couleurs (les brillantes notamment) permettent de descendre en dessous de L=18. Il ne faudrait pas limiter ceux qui peuvent de permettre une calibration haut de gamme.
Il eciste plusieurs types de profiles ICC : la matrice 3x3 de base à la 3D LUT, avec différents « intent », voire même le module table de correspondance des couleurs de DT (via darktable-chart). @Aurélien : ton module fonctionne-t’il avec tous ces types de profiles ?
La linéarité de la réponse du capteur joue-t’elle dans l’applicabilité du module ?
le mappage L → [18;96] n’est utilisé que dans l’optimiseur automatique (avec les pipettes, ou avec le bouton « optimiser automatiquement »). Il est débrayable en réglant les curseurs à la main, en s’aidant d’une pipette de contrôle générale (dans le panneau de gauche, tracer une zone de contrôle sur toute l’image et lire de min et max). Pour faire une optimisation automatique, il est obligatoire de faire quelques hypothèses.
18/96 correspondent à des valeurs classiques de chartes IT8 semi-réfléchissantes (20 %). Je n’ai pas connaissance de modèles réfléchissants, et je doute de leur pertinence car leur haute sensibilité aux réflexions parasites les rend inutilisables hors d’un labo de métrologie sous éclairage contrôlé (c’est déjà difficile d’éviter les reflets parasites sur une charte 20 %).
Enfin, le unbreak profile n’a pas besoin de se soucier du profil ICC : il ne fait qu’une correction perfectionnée de l’exposition de façon à comprimer la plage dynamique en évitant les valeurs extrêmes où le profil n’est pas valide. Pour ce faire, il applique la même correction aux 3 canaux RGB. Rien à signaler de ce côté là.
Pour la linéarité, je ne sais pas. En toute rigueur, il faudrait utiliser un espace RGB linéaire en profil d’entrée, puis une LUT réalisée sur une charte encodée avec la même correction logarithmique. Mais avec tous les profils ICC et LUT linéaires que j’ai testé, le profil logarithmique donne de très bons résultats.
