Est-ce que le mappage de tonalité peut faire varier les couleurs ?
Il faudrait préciser ta question : qu’entends tu par “mappage des tonalités” (plusieurs modules le font de manière différente) et par “faire varier les couleurs”.
Je crois certains (tous ?) modules de mappage des tonalités affectent au minimum la saturation des couleurs, avec plus ou moins de contrôle dessus.
De mémoire je crois que le module “sigmoid” offre aussi des curseurs pour modifier les couleurs d’une certaine manière.
Cette question ‘anodine’ est une partie du cœur du système. Si l’utilisateur ne comprends pas a minima ce qui se passe (au delà des mathématiques) on arrive à des imbroglios, des discussions qui mettent en cause d’autres processus. On trouve des palliatifs avec d’autres produits – qui ne sont pas faits spécifiquement pour cela, mais qui ‘rattrapent’.
Pour répondre à la question (tout dépend de ce tu entends par couleur) :
* oui dans tous les cas il y a un effet sur la saturation et le contraste local, car quelque soit le TM - Tone-mapper , il comprime les montagnes et rempli les vallées. Pour cela il dilate et compresse. Dans les zones de dilatation la saturation et le contraste local sont réduits et l’inverse pour la compression. Il est assez facile de le corriger (au moins essayer).
* la teinte (hue), si le TM est bon, il ne doit pas induire de dérives de couleurs – ce n’est généralement pas le cas, on peut même dire que c’est très souvent le cas. Dans le cas de dérives, provoquées par le TM, certains mettent en place des correctifs…(primaires ou autres). IL vaut mieux que le TM n’apporte pas de dérives.
Avant de parler de dérives du TM, il faut être sûr que ce qui est ‘avant’ n’en introduise pas. Je parle ici de balance des blancs, de matrice de couleurs, de points noirs Raw, mais aussi de récupération des basses et hautes lumières souvent hors gamut.
L’autre point essentiel, est qu’est-ce qu’on donne ‘à manger’ au TM. J’entends par là la plage de données qu’on lui donne à traiter. Si le(s) point(s) noir de l’image réelle ne sont pas proches de zéro, alors n’importe quel TM laissera des images grises, sans contraste… Si le(s) point(s) blanc pour le calcul des TM ne correspondent pas à la réalité, et si la fin du TM n’est pas asymptotique vis-à-vis des vrais points blancs, alors soit les HL restent cramées ou avec des désordres, soit elles sont mal traitées (avec des magentas, des artefacts, etc.).
L’autre question anodine est, une fois qu’on est conscient de ce problème – qui est LE problème. Quelles valeurs donnent on au TM, et est-ce que les 3 canaux RGB (ou autres) sont traités ‘ensemble’, ‘séparément’, ou avec un équivalent pour évaluer la luminance (que se passe-t-il lorsque les données sont 4 à 10 fois supérieures aux limites normale?), qu’est-ce qu’on en fait ? Que fait-on des couleurs imaginaires soit présentes, soit qu’on génère avec le TM (un comble puisque son rôle est de les supprimer ou les réduire).
Une fois cela fait, si le TM n’a pas l’ambition de ‘tout faire’, il faut (enfin) affiner la colorimétrie, soit selon des références normées (ex ColorChecker), soit par goût ou simuler des effets (coucher de soleil, effet dramatique, films, etc.). Mais là c’est une autre affaire, qui n’est pas le sujet évoqué. Il existe diverses techniques. Mais, si c’est à ce stade, qu’on récupère un point noir mal fagoté au démarrage, c’est qu’il y a quelque chose qui ne va pas avec la conception ou l’utilisation du logiciel.
Jacques
Je vous donne un lien vers mon google drive pour télécharger une très courte vidéo qui vous montrera mon problème de dérive de couleur sur une image que je n’arrive pas à modifier avec la balance des blancs. Je dois rester en Courbes Tonales et ne pas utiliser le Mappage des tonalités. Merci de ne pas diffuser, je n’ai pas de permission de la personne sur cette vidéo.
Très difficile à dire.
L’histogramme dans ce mode, ne permet pas de voir vraiment ce qui se passe.
Toujours préférer le mode classique qui permet de voir les débordements dans les BL et HL. Les autres modes pour moi sont des ‘gadgets’…
Actuellement je suis sous Windows, et mon ART ne fonctionne plus… Et sous Linux, mal…du fait des CTL et des LUT…Cela marchait il y un mois… maintenant après mise à jour de Linux…pas terrible.
Je ne sais pa si ART à la possibilité de passer l’histogramme en mode ‘linéaire Working profile” sans gamma… Je vais voir après sous Linux…
Manifestement le ‘Log encoding’ corrige mal (très mal) les blancs. As-tu activé Color Propagation ? Highlight attenuation… (ou son appallation sous ART…). Rappel je ne me sers pas de ART, c’est juste ‘pour voir’…
Comment avec l’histogramme normal sont en mode linéaire, les BP et WP. Est-ce que cela “déborde” des 2 côtés, où est le point noir (BP), où est le WP ?
As-tu activé le Soft Proofing ? et que dis-t-il ?
Que dit, l’histogramme Raw ?
Log encoding (ou son nom dans ART, alias Filmic) ne sait pas traiter les asymptotes HL, sinon de lui demander (il doit y avoir un curseur pour “attenuer” les HL ou quelque chose qui y ressemble - il active une fonction hyperbolique ‘tanh’ - du moins c’était avant…). Dans ART le calcul des WP et BP est fait ‘avant’ le traitement Log. As-tu fait des traitements intermédaires avant ?
Bref, je donne des pistes “à l’aveugle”…
Dans RawTherapee, je recommande de partir de ‘Neutral’, ne pas se servir des Tones Curves, ne pas se servir des Exposures et consort…D’activer Color Propagation (rien que pour voir). Travailler en mode Linéaire. Ne pas utiliser (sauf exception) les Filmic et équivalent. Maîtriser ‘avant’ les BP et WP, etc. Mais nous sommes sous ART - donc à prendre avec des pincettes.
Jacques
Imperceptiblement j’ai l’impression que de développeur arrive à un point haut de son affaire. Peut-être sera t-il difficile pour une seule personne de faire beaucoup mieux que l’existant qui est déjà bien. Je ne suis vraiment pas fan (c’est personnel) des scripts et autres haldcluts qui me semble être présents pour éviter une grosse évolution du logiciel. Pour ma part je pressens un retour vers Darktable qui continue d’évoluer plus sensiblement. On verra …
Bonjour Jacques,
As-tu essayé de réinstaller ART sous ton Linux ? Tu as 2 possibilités qui devraient fonctionner toutes les deux :
- une version AppImage
- une version en .tar.xz à décompresser et lancer directement
Ce qui ne fait pas de mal quand ça plante, c’est souvent d’effacer tout ou partie du cache.
Le meilleur moyen de le constater serait de mettre à disposition un RAW qui aboutit à un tel phénomène.
La façon dont tu utilises le MTL ne me semble pas appropriée. Si tu n’actives pas préalablement les courbes tonales, avec le MTL, ton image plate va être encore plus aplatie et affadie, pour ce qui concerne les couleurs. Dans le module “exposition”, j’active la reconstruction équilibrée des HL et je déconseille de toucher ici à l’exposition car tu as tout ce qu’il faut dans le module MTL : le “gain” (=exposition) et ne pas avoir peur de déplacer éventuellement le “point gris”. Si les couleurs sont trop étalées, déplace à gauche le curseur “blanc exposition relative”. Je ne rentre pas plus avant dans le détails. Mais, personnellement, je ne touche pratiquement jamais à “égaliseur tonal”.
Tout cela est inclus dans mon profil de travail de sorte que, dès qu’il est chargé, mon image est déjà très bonne.
Sans prétention, j’expose ici ma façon d’utiliser ce module en espérant que cela puisse te servir.
Sache que Jacques, qui nous fait l’amitié d’intervenir ici, est actuellement -presque- (pour ne pas froisser sa modestie) le seul développeur de RT. Je ne suis pas sûr qu’ils soient une ribambelle pour DT, ni même pour certains logiciels non-libres…De toutes les façons, malheureusement le nombre s’accompagne souvent de dissensions et de code disparate (cf DT) ! Alors remercions ces développeurs isolés et inspirés.
Les conseils de chacun me sont toujours utiles.
Oui, ça c’est vrai pour avoir vécu en spectateur une mauvaise passe de DT. Mais de là à être tout seul … Bon, attendre et voir.
En fait ma question est la suivante : pourquoi veux-tu utiliser le mappage des tonalités log sur cette photo ?
Je n’ai pas l’impression que tu en aies besoin, ça semble être l’outil le moins approprié pour cette photo-ci.
Honnêtement si tu ressens plus d’attrait vers DT, je pense que tu devrais aller vers DT. Chaque personne a des affinités différentes, pour des outils différents.
Merci, mais pas de problèmes réels. Je tiens aussi bien pour ART que DT a avoir les versions compilées…Pour regarder le code. Mais je ne m’en sers pas à proprement parler.
Non je ne suis pas ‘seul’… Nous sommes maintenant 4 pour RT et quelques contributions via des Pull-Request. On peut décomposer le travail de DT/ART/RT en gros en 3 paquets (qui bien sûr se chevauchent).
- 1 - l’administration du site, les droits d’accès, les nouvelles versions, la création des fichiers exécutables, etc. les relations avec GitHub, etc.
- 2 - l’optimisation du code, le respects des normes C++ (ou autre …), les bugs ou insuffisances (par exemple le ‘Crop’ ne fonctionne pas, le dernier boitier Canon n’est pas supporté,…), les nouvelles versions de GUI, les incompatibilités entre versions Windows / Linux / MacOS, la documentation, etc.
- 3 - les nouveaux algorithmes.
Je suis clairement dans le 3, et quasiment seul…Mais les 3 autres ‘vérifient’ que je ne fais pas (trop) de con..ries en C++
Il ne faut pas négliger le travail des contributeurs comme par exemple Sebastien, qui vérifent que cela fonctionne, ou propose des améliorations, ou suggestions sur les Labels et Tooltips. A titre d’anecdote, cela ne présage en rien de la qualité du traitement: regardez les labels de DT, tout est en minuscules (ils ne s’embêtent pas …), dans RT tout est calibré selon les normes anglo-saxones (c’est je pense plus cohérent et lisible…, mais je dois admettre avoir du mal avec la syntaxe et la gammaire des britishs…mon franglais fait furreur !)
Dans DT, ils sont beucoup plus nombreux…Je n’ai pas recensé, mais au moins le double de RT. De plus ils ont le ‘vent portant’ actuellement, ils communiquent bien, la doc est à jour, les vidéos pleuvent…Comme RT il y a 8 ans…Mais ils ont fait des biais cognitifs importants…et DT devient un peu illisible… tellement il ya de fonctions…
ART, Alberto est seul pour tout assurer. C’est remarquable. Pas de problèmes (sauf avec lui même lorsqu’il se rase le matin..) pour savoir si il va développer ceci ou cela. Il a fait le choix des CTL et des LUT. En termes informatique je tire mon chapeau, je ne sais pas faire. L’énorme avantage ‘on peut tester facilement’. Par contre 2 inconvénients majeurs : a) le code est ‘isolé’ et on ne peut passer facilement des paramètres d’autres process. ( J’ai choisi pour RT - 3 CTL, les ai modifiés en profondeur (euphémisme), intégré au code C++, et bien sûr elles se mettent à jour avec une nouvelle version et prennent en compte tous le code de RT si nécessaire); b) ces CTL, LUT,… supposent une installation et des compétences pour celui qui veut s’en servir, d’où des problèmes de portabilité entre utilisateurs, et de compatibilité dans le temps…Mais cela ne retire rien au fait de l’avoir fait (chapeau).
Parmi les questions essentielles:
- contrairement aux logiciels payants, il n’y a pas de chef de projet, ni d’équipe de projet. La coopération se fait ou ne fait pas au coup par coup. Comme nous avons tous ‘nos’ problèmes, notre personnalité, cela se passe plus ou moins bien. Il y a des hauts, des bas…
- la plupart des acteurs (au moins moi) faisons cela par passion, par défi, ou comme passe-temps…Certes cela fait plaisir de recevoir des ‘like’ ou des félicitations (l’inverse est vrai aussi), mais dans mon cas je n’en ai pas grand chose à faire de ‘la gloire’…
Le choix d’un logiciel est difficile, car les logiques, les doctrines… sont différentes. ART / DT / RT sont de bons produits…Ce que je peux affirmer c’est que le plus novateur (au sens innovation et non adaptation de ce qu’il y a ailleurs - ce qui ne veut pas dire que c’est facile…) c’est RT….Essayez de trouver ailleurs : a) WB auto temperature correlation (un monument de mathématiques 100% création personnelle); b) CIECAM la Rolls de la colorimétrie, je pense le seul logiciel au monde à l’avoir ‘en complet’; c) Selective Editing - seulement inspiré par les U-points de NX2 en 2006; d) Abstract profile (aller loger un profile ICC en plein mileu de code…m’a valu des injures…), etc.
Merci, mais pour rappel, je ne suis qu’un invité (pas jeune, et pas terrible pour la santé..).
Jacques
Oui, tu as sûrement raison.
Un grand merci pour ton travail sur RT. Pourquoi, à ton avis, les utilisateurs ont glissé de RT vers DT depuis quelques années ? Ressemblance avec LR ? Curiosité ce 1:1 ou sa petite fenêtre pour voir la netteté ? Pourquoi un fork de RT ?
(pas de volonté de polénique dans ce propos)
C’est pour l’essentiel du, cette ‘disgrace’ - et j’en avais discuté avec Sebastien (je pense qu’il se le rappelle) à la Guadeloupe, il y a 10 ans, au manager (le rôle 1 que j’évoques)… Nous venons avec la même personne d’avoir exactement les mêmes problèmes pour la documentation de RT.
Pour la fork de Rawtherapee… donc ART. Je ne conteste en rien les compétences de Alberto, c’est un mec super… Ultra compétent en informatique (et mathématiques…)… Simplement je pense que RT a été un tramplin pour lui. Je m’étais opposé à ce chisme. Mais la majorité a dit OK. Il aurait été de mon point de vue, et cela n’aurait rien changé au résultat, garder une équipe unie (plus on est nombreux, plus il y a d’idées…mais aussi de risques de conflits). On aurait facilement pu faire 2 produits comme Photoshop et Lightroom… à la fois complémentaires et différents, mais communicants entre eux. L’histoire en a décidé autrement.
Ce chisme a aboutit peu à peu à une fuite des compétences…Comme la nature à horreur du vide…Le vide s’est rempli avec DT…Qui est un très beau produit, même si à titre personnel, je trouve (mais ce n’est pas le lieu ici) certains algorithmes ‘curieux’ (euphémisme).
Bonne soirée à tous.
Jacques
Illustration parfaite, ce qui s’est passé ces dernières semaines : l’auteur de Spectral Film Simulation a modifié son code, modifications qui ont cassé le module dans ART pour les nouvelles (ré)installations. Mais Alberto ne l’a pas vu, moi je me suis cassé ne le nez sur ce problème, heureusement un utilisateur a eu plus de courage que moi et est allé voir dans le code de l’auteur originel pour voir d’où venait le problème, et a pu faire remonter l’info précise à Alberto, qui a fixé la compatibilité dans ART il y a 2 jours.