Dans mon club photo, en réglant l’exposition et en réglant ensuite filmique, tout le monde a l’impression qu’on fait pratiquement deux fois la même chose. Voir qu’un module sur les deux est de trop. Curieuse impression …
Généralement, je n’ai pas besoin d’« exposition » avec filmique et je l’utilise qu’exceptionnellement. Après, je suis moins intégriste par rapport aux hautes lumières et ombres. Je ne cherche pas toujours à les faire entrer dans l’histogramme.
il y a un vrai problème de compréhension de l’exposition…
Tout comme la courbe de base avant la version 2.6.0 et filmique.
Si cette courbe de base n’avait pas été activée par défaut, il y aurait eu ce même sentiment.
En fait filmique se substitue à la courbe de base, en traitant l’image d’une autre façon, mais n’a pas pour objet de corriger un décalage d’exposition… qui lui agit sur la totalité des pixels.
Filmique n’agit pas sur « la totalité des pixels » ?
Pourtant on règle (comme on peut) les tons moyens et ensuite les noirs et les blancs.
Pour être honnête je montre comment utiliser filmique sans vraiment pouvoir expliquer simplement son mode d’action réel et surtout sans pouvoir donner des repères fiables aux adhérents pour le réglage précis de la luminance du gris. Entre 6 et 18% … A peu près … regardez la courbe si elle n’est pas trop bizarre … Sinon faites au mieux.
Alors que filmique est très bien, j’ai un petit regret pour la facile compréhension des réglages précédents : Exposition, le point noir, le point blanc, et un petit coup sur les hautes lumières et les ombres. Ca c’était parlant pour tout le monde.
Je n’arrive pas à trouver le moyen de faciliter l’utilisation de ce module. Et je me désole un peu de voir des adhérents faire un peu du sur place dans l’apprentissage basique de darktable à cause du passage obligé « exposition-filmique » et appropriation de filmique.
Oui bien sûr filmique agit aussi sur l’ensemble des pixels mais de façon différenciée, il agit avant tout sur la plage tonale.
Les pré-réglages depuis la 2.6.1, aident beaucoup à ce (comme on peut) des débuts, je démarre souvent avec le 11EV ou 12EV.
Les curseurs pour les noirs et les blancs proposent une exposition relative du noir et blanc purs par rapport au gris moyen 18%… qui peut être décalé en fonction de la scène par le curseur de luminance du gris moyen, le premier à définir.
Coté module exposition (qui n’a pas de réglage de point blanc, réglable dans ombres et ht lumières), il y a juste un ajustement du niveau de noir, à manier avec précaution car il tronque des valeurs qui ne seront plus dispo par la suite. N’a pour objet que de corriger une sur/sous exposition, locale au besoin avec un masque. Dit autrement il va rendre l’image plus claire ou plus sombre de façon globale selon réglage, c’est en ce sens que je voulais l’exprimer.
Autre différence notable les deux interviennent à des stades très différents, expo est au tout début du pixel-pipe, flimique quasi à la fin.
En fait démarre avec filmique sur son pré-réglage par exemple à 12EV et tu n’auras pas plus qu’avant la sensation de faire deux fois la même chose quand courbe de base était activée par défaut.
Certes filmique est un peu « technique » et a utiliser et à comprendre, mais me semble que les devs sont en train de concocter un module « ajustement basique » pour une approche plus intuitive.
.
« Ajustement basique » est un module sorti il y a quelques jours en version de développement. Il n’a rien à voir avec filmique, c’est une sorte de fourre-tout de réglages de base, franchement utile uniquement pour un débutant. Et encore, ça peut aussi être un piège pour rester sur du basique et ne pas explorer le potentiel de darktable. Pour compléter, voir ce fil et les critiques de Pascal & Aurélien sur ce module : https://forums.darktable.fr/showthread.php?tid=3440
Personnellement, je l’ai testé par curiosité et vite retiré.
Filmique est très bien construit je trouve, mais forcément vu sa puissance et son approche très différente de ce qui était connu jusque là, il questionne. Mais franchement, une fois sorti des habitudes (mauvaises ?!, c’est en fait un module simple et bien construit, tout à fait logique. Les pré-réglages sont un bon indicateur ainsi que les vidéos.
Tout à fait d’accord il n’a rien à voir, visant un aspect de démarrage façon courbe de base, mon info venait de là et aussi d’avoir testé le dit module… que j’ai rapidement aussi mis dans les modules non activé de ma master.
Mais nous avons tous été débutants de filmique, moi le premier j’ai eu du mal à m’y faire au début, un peu perdu face à une image sans sa courbe de base, j’ai fait un fil à ce sujet dans « Editer mon raw »
Oui filmique est un super outil, mais attention aux habitudes anciennes il faut aussi lui associer des modules cohérents avec son approche et abandonner ou du moins éviter d’autres modules, Aurélien dans un fil sur l’aspect chronophage du workflow y cite les principaux.
J’avais enregistré une vidéo pour expliquer l’exposition en détail, il y a 2-3 semaines, mais je n’étais pas satisfait du résultat, il faudra que je la refasse.
Filmique fait du mappage de tonalités entre un espace linéaire « physique » (le capteur compte des photons) et un espace logarithmique « perceptuel » en ajustant le point gris à la valeur que l’écran attend (incluant le gamma). Ce faisant, il gère le passage du « mur de la non-linéarité » d’une manière contrôlée, qui n’est pas optimale avec le mode actuel de préservation de la chrominance (il faudrait un moyen de débrayer de profil ICC de sortie et de le gérer à la main), mais mieux que rien. Et ça va évoluer maintenant qu’on a un pipe RGB optionnel dans 2.7.
Mathématiquement, ajuster le point gris ou l’exposition du module éponyme, c’est pareil (c’est la même opération).
MAIS… dans filmique, le point gris est lié à sa position dans la plage dynamique. La gestion de la couleur en mode ICC se base sur des hypothèses qui datent des années 1970 (l’espace Lab date de 1976). L’hypothèse fondamentale, c’est que le 100 % de luminance correspond à la luminance d’un blanc diffus à 20 % de réflectance (imaginez une carte blanche légèrement satinée). Dans l’espace écran, ce 100 % de luminance correspond à une lumière émise de 100 Cd/m².
Toujours dans ce système d’hypothèses, on attend donc le gris moyen (perçu comme 50 % par l’humain) à 18 % de la luminance du blanc moyen (mesuré par le capteur), c’est à dire 2.45 EV sous le blanc. Tout ça suppose qu’on ait une plage dynamique « faible », car rappelons que la pellicule couleur ne dépasse pas 6-7 EV, donc on exposait pour les tons moyens, en sacrifiant les extrêmités. C’était moins moche qu’en numérique parce que le film comprime les extrémités de la plage dynamique de façon progressive (comme filmique, avec une courbe en S).
Maintenant, en numérique, on dispose de 12-14 EV de plage dynamique, ce qui dispense en partie du sacrifice des hautes lumières. Mais la plupart des posemètres sont toujours conçus pour exposer le gris moyen : l’appareil calcul la moyenne de la luminance sur son capteur, suppose que c’est un gris 18 %, suppose donc que le blanc est 2.45 EV plus haut, et il ajuste l’exposition comme ça (à part de rares appareils avec une mesure spot en priorité hautes lumières). C’est pour cette raison que les modes d’exposition auto ont beaucoup de mal avec les high-key/low-key. Et les réglages par défaut de filmique représentent ce standard (gris = 18%, blanc = 2.45 EV, et noir = 10 - 2.45 EV).
Donc, le photographe numérique, pour protéger les hautes lumières, sous-expose. Donc la valeur de 100 % ne représente plus la luminance du blanc diffus, mais peut représenter la luminance d’une source de lumière primaire (lampe, soleil). Donc on n’a plus le gris moyen à 18 % non plus. Enfin, si, le gris est toujours à 18 % du blanc diffus, mais la valeur du blanc diffus n’est plus connue et a de fortes chances de se trouver sous 100 %. Le problème, c’est que, lorsqu’on ouvre la photo dans le logiciel, on a des valeurs RGB, mais plus moyen de savoir ce que représentent 100 % ou 18 %. Du coup, à la différence du constucteur du boîtier (qui a toute l’info nécessaire via un accès direct à son capteur), on ne peut pas appliquer une courbe de base pré-réglée, il faut en paramétrer une sur mesure.
Filmique permet de faire la culbute, sans se prendre la tête (enfin, quand on l’a en main), entre la réalité du cliché et ces hypothèses de référence historiques, qui sont désormais fausses, en redimensionnant la plage dynamique et en repositionnant le vrai gris (défini par l’utilisateur) là où l’écran l’attend.
Pour utiliser filmique au mieux, il faut donc se placer au plus proche des conditions standard, c’est à dire, avec le module exposition, placer les blancs à 100 % de luminance (s’il y a des blancs). Ensuite, à partir des réglages par défaut de filmique, dégrader la valeur du gris jusqu’à trouver un compromis acceptable (ou utiliser la pipette). A ce stade, le blanc se sera ajusté tout seul, donc pas besoin de le toucher. C’est juste le point noir qu’il faudra éventuellement corriger pour piloter la densité du noir (autrement dit, à quel point on veut récupérer des détails dans les ombres) en sachant qu’il est inutile d’excéder la plage dynamique réelle du capteur (qui diminue quand on monte dans les ISO), autrement on va juste faire ressortir le bruit.
Ensuite, le réglage du contraste est en fait fortement corrélé à la plage dynamique elle-même. C’est rare que je touche ce paramètre, je suis toujours entre 1.5 et 1.6. C’est plutôt les réglages de latitude et la balance qui vont permettre d’ajuster la courbe pour éviter de « l’asseoir » sur ses fesses dans les ombres, en les bouchant. Dans la prochaine version, la latitude sera exprimée en % de la plage dynamique, parce que par expérience, elle est toujours entre 20 et 33 % de la plage dynamique, et ça sera plus simple d’avoir une latitude qui s’ajuste automatiquement.
La partie largement perfectible, c’est la préservation de chrominance. Elle se passerait bien s’il y avait moyen de copier la sortie de filmique directement dans le fichier de sortie, en court-circuitant la correction gamma du profil de sortie, parce que le point gris en sortie de filmique est déjà à la bonne place. Comme ça n’est pas possible, je fais une compression gamma à la sortie de filmique pour remettre le gris à 18 %, de façon à ce que le gamma de sortie le replace à 45 %. Évidemment, ça comprime les ratios de couleur de façon non-linéaire, et j’aurais dû penser à ajouter un autre paramètre pour dilater les ratios avant de les envoyer se faire comprimer dans la correction gamma (pour qu’ils ressortent non affectés).
Mais comme je suis stupide, ça sera pour filmique v3.
Merci pour l’intervention et l’explication.
Mais pas stupide, il faut bien se garder une marge de progression… hein, si filmique avait été parfait « one shot » nous aurions déjà la release finale de DT 
C’est toujours un peu frustrant .. Quand on pose une question concrète, de terrain, les réponses sont toujours … excellentes
Et quand on utilise des profils de sortie dont la TRC n’est pas un gamma, que se passe t-il ?
Je parle ici d’un encodage gamma, pas d’une TRC. La TRC, c’est la fonction dont l’inverse permet de linéariser les défauts de l’écran. L’encodage gamma permet d’éviter la postérisation due aux erreurs d’arrondis dans les fichiers encodés en entiers, en redistribuant la plage dynamique de façon plus homogène entre les bits d’encodage. Cet encodage est inversé dans le convertisseur numérique/analogique de l’écran, car les écrans LED/LCD sont à présent à peu près linéaires (en émission lumineuse), donc il est neutre sur le plan mathématique.
Il y a toujours un encodage gamma dans les espaces de sortie, car ce sont des formats encodés en entiers 8/16 bits (TIFF/JPEG/PNG) ou 8/10 bits (sortie vidéo → écran).
L’enfer du monde ICC, c’est que tu exportes ton pipe couleur vers un fichier dont l’espace RGB est encodé en gamma (genre sRGB). La carte graphique prend l’espace RGB du fichier, inverse le gamma sRGB (donc linéarise), applique la TRC inverse de l’écran (si étalonné), ré-encode avec le gamma de l’écran (2.2, si tu as étalonné, sRGB sinon), puis l’électronique interne de l’écran décode à nouveau le signal vidéo (donc relinéarise) pour finir avec un truc linéaire.
Dans l’histoire, le standard ICC ne fait rien pour s’assurer de la concordance entre les couleurs d’origine (telles que capturées par l’appareil) et les couleurs de destination (écran, imprimante) mais s’assure seulement que ce que tu vois sur ton écran va être identique à ce que verra le voisin sur son écran ou son imprimante. C’est radicalement différent. ICC fait correspondre les sorties entre elles, pas l’entrée et la sortie.
Ça implique que les conversions de profil à profil ICC (d’espace à espace RGB) autorisent des virages de teintes (notamment comme effet secondaire des ajustements de gamut), et donc risquent de flinguer ton travail sur la couleur de façon subtile et tordue. Par exemple, imagine que tu pousses la saturation du cyan dans ta retouche, mais que la conversion vers l’espace écran dégrade le cyan vers le vert : non seulement, ton réglage n’a plus l’effet escompté intuitivement, mais en plus il faut rajouter une seconde étape de correction de la teinte. Et c’est un cas qui se produit fréquemment, sur les écrans moyen-bas de gamme, qui ont souvent des soucis de cassure du gamut dans les couleurs secondaires.
Pour éviter ça, il faudrait court-circuiter toute la chaîne ICC pour contrôler directement les valeurs utilisées par l’écran, et passer par des options de preservation de la chrominance, c’est à dire que l’énergie lumineuse du pixel soit corrigée en fonction de la réponse de l’écran, mais que le spectre lumineux soit conservé identique entre l’entrée et la sortie. Mais ça n’est pas possible sur les OS actuels, qui intègrent la chaîne ICC par défaut (s’ils sont gérés en couleur), donc il faut user d’artifices mathématiques pour simuler la déviation dûe aux conversions, et la pré-corriger en amont, avec les hypothèses sales et les approximations/erreurs/compromis que ça suppose.
C’est ici, en fait, que ne pas étalonner son écran est presque mieux : certes, on perd la cohérence d’un écran à l’autre (ou de l’écran au tirage), mais la retouche est d’avantage What You See Is What You Get. Si tu satures le cyan, tu voies le cyan se saturer, pas virer vers le vert. Par contre, ça risque de ne pas être le même cyan que sur l’écran du voisin.
Et c’est entre autres une des raisons pour lesquels l’industrie du cinéma n’utilise pas ICC mais OpenColorIO. Sauf que le petit monde de la photo est tellement occupé à se demander ce que ferait Adobe qu’il a en oublié de se tourner vers l’avenir.
Non, il n’y a pas toujours d’encodage gamma dans les espaces de sortie ! Et sRGB n’est justement pas encodé en gamma 1/2.2 …
Je souhaite juste être sûr que le passage du module filmique dans ProPhoto n’induise pas de dérive colorimétrique car ProPhoto est assez fort pour ça …
Quant à l’industrie du cinéma, elle d’autres contraintes de perception visuelle que la photo. Raison pour laquelle l’adoption du DCI-P3 par Apple n’est pas une réussite pour les photographes.
Fatalement, si c’est codé en entiers, il y a un gamma. Imagine, sans gamma, en 8 bits entier, ça veut dire que ton premier EV sous le blanc est codé entre 255 et 128, le deuxième entre 128 et 64, le troisième entre 64 et 32, le troisième entre 32 et 16, le quatrième entre 16 et 8, le cinquième entre 8 et 4, etc. 5 EV sous le blanc (2.6 EV sous le gris moyen), tu n’as que 4 valeurs disponibles pour coder tes dégradés, tu imagines la postérisation ?
Le seul moment où tu peux te dispenser de l’encodage gamma, c’est si tu exportes en flottants 32 bits (EXR, PFM, TIFF 32, etc.). Mais à ce moment là, filmique est totalement capable de passer en « gamma » 1.0. D’ailleurs, tu peux voir ce que ça donne en utilisant un profil écran REC 709 linéaire dans darktable.
Pour sRGB, le gamma est défini avec une partie linéaire et une partie exponentielle, mais c’est ajusté de sorte que le gris moyen se cale à peu près sur un gamma 2.2 pur (sRGB : 46.4 %, gamma 2.2 : 46.7 %). Dans filmique, c’est tout ce qui nous intéresse. On remappe le blanc, le gris et le noir, et on interpole au milieu.
Par contre, en effet, je soupçonne ProPhotoRGB d’être en partie responsable du virage vers le rouge de filmique. Pour dt 2.8, l’espace RGB sera au choix de l’utilisateur (espace de sortie linéarisé ou espace de travail : ACES P0, REC2020, REC709).
Je ne dis pas qu’il n’y a pas d’encodage, je dis qu’il y a des encodages différents d’un gamma …
Pour le sRGB précisément, le pied de courbe est relevé par rapport au gamma 2.2 ce qui améliore les basses lumières. Ce qui se trouve d’ailleurs être un choix assez judicieux pour Mélissa (oui, encore Adobe même s’il est très loin d’être le meilleur en la matière). Ce n’est donc pas un gamma 2.2 même si une partie se cale dessus.
Pour la 2.8, il serait bon que l’utilisateur puisse faire son propre choix plutôt qu’un choix figé, c’est à dire autre qu’un rec2020 ou pire un rec709. En repro d’art, on utilise des espaces plus grands que ProPhotoRGB (et a fortiori que le rec2020) !
Pour la 2.8, il serait bon que l’utilisateur puisse faire son propre choix plutôt qu’un choix figé, c’est à dire autre qu’un rec2020 ou pire un rec709. En repro d’art, on utilise des espaces plus grands que ProPhotoRGB (et a fortiori que le rec2020) !
Quels espaces ? Pour moi, ACES P0 et ProPhoto sont déjà les plus larges, avec une large portion de couleur imaginaires.
L’avantage du choix « figé », c’est que c’est bibi qu les programme et que je peux m’arranger pour que ça soit assez optimisé (et avoir une version OpenCL) pour que tu ne te rendes même pas compte qu’il y a une conversion. Un choix « ouvert » suppose de passer par des profils ICC, donc potentiellement LittleCMS (on oublie OpenCL et toute optimisation), et les performances vont chuter drastiquement (de l’ordre de 250 ms, contre 10 ms si c’est codé en interne et optimisé).
Qu’il y ait des couleurs imaginaires importe peu, ce qui compte est qu’il intègre au mieux le spectrum locus. Et comme un espace est toujours matriciel, il y a forcément des couleurs relevant du pur calcul.
Un espace large facile à obtenir est celui fourni par Hasselblad depuis déjà quelques années :
Il s’est avéré limite dans de rares cas … Il s’installe en même temps que Phocus et a un petit défaut facile à corriger : on ne sait pourquoi Hasselblad l’a doté d’une mauvaise « device class » qui empêche de l’utiliser en profil de sortie …
Il y a en a de plus larges encore.
Si tu as moyen de me sortir la table de conversion RGB → XYZ, je pourrais l’intégrer.
Je n’ai pas ce qu’il faut sur mon portable, mais je pense qu’on peut le faire avec iccdump d’ArgyllCMS.
Je peux fournir le fichier icc.
Par contre, je conviens que ACES linéaire (encore plus large) fasse l’affaire du moment que ce soit bien neutre en sortie de filmique.
[hr]
Le résultat du dump du profil Hasselblad est ici.