Note de ce sujet :
  • Moyenne : 0 (0 vote(s))
  • 1
  • 2
  • 3
  • 4
  • 5
denoise, denoise, denoise, help help, help
#11
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.
Répondre
#12
Allez encore une fonctionnalité pour la 2.6, je viens de proposer un PR pour le tri par aspect de l'image: https://github.com/darktable-org/darktable/pull/1760

Cette deuxième version apporte en plus du filtre le support dans le module collecte.

ATTENTION: ce PR modifie la base de donnée et on ne peut plus revenir en arrière, du coup : SAUVEGARDEZ library.db avant de tester Smile
--
Pascal - GNU/Debian (sid) - version darktable git/master
http://photos.obry.net
Répondre
#13
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 ?
Répondre
#14
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.
--
Pascal - GNU/Debian (sid) - version darktable git/master
http://photos.obry.net
Répondre
#15
(21-10-18, 22:24)pascal a écrit : 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.

D'accord merci Smile
Pour commencer du coup, la "lourde" traduction pour les modifs des modules de débruitage, 'G' se traduit par 'V' en français  Big Grin
Répondre
#16
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.
--
Pascal - GNU/Debian (sid) - version darktable git/master
http://photos.obry.net
Répondre
#17
(22-10-18, 07:44)pascal a écrit : 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.

Oui. Ah d'accord très bien !
Répondre
#18
Bonjour,

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 ?
Répondre
#19
(27-10-18, 16:19)f2g2 a écrit : Bonjour,

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.
Aurélien, photographe portraitiste, spécialiste calcul.
Développeur de filmique, égaliseur de tons, balance couleur, etc.
darktable est mon métier, pensez à m'aider :
[Image: 2FAd4rc]
Répondre


Atteindre :


Utilisateur(s) parcourant ce sujet : 1 visiteur(s)