Note de ce sujet :
  • Moyenne : 0 (0 vote(s))
  • 1
  • 2
  • 3
  • 4
  • 5
exposition et filmique
#11
C'est toujours un peu frustrant ..  Quand on pose une question concrète, de terrain, les réponses sont toujours ... excellentes
Lille. Hauts de France
Site web : http://www.philippedeletree.fr
Youtube : Darktable
Linux Solus

Répondre
#12
Citation :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 %. 

Et quand on utilise des profils de sortie dont la TRC n'est pas un gamma, que se passe t-il ?
Windows 10 Pro 2004 - dt 3.2.1
Répondre
#13
(21-03-19, 08:15)pascalG a écrit :
Citation :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 %. 

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.
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
#14
(21-03-19, 09:03)aurelienpierre a écrit : 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.

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.
Windows 10 Pro 2004 - dt 3.2.1
Répondre
#15
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).
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
#16
(21-03-19, 10:37)aurelienpierre a écrit : 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) !
Windows 10 Pro 2004 - dt 3.2.1
Répondre
#17
> 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é).
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
#18
Citation :Quels espaces ? Pour moi, ACES P0 et ProPhoto sont déjà les plus larges, avec une large portion de couleur imaginaires.

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 :

[Image: Hassy-vs-Pro-Photo.jpg]

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.
Windows 10 Pro 2004 - dt 3.2.1
Répondre
#19
Si tu as moyen de me sortir la table de conversion RGB -> XYZ, je pourrais l'intégrer.
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
#20
(21-03-19, 13:27)aurelienpierre a écrit : 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.

Le résultat du dump du profil Hasselblad est ici.
Windows 10 Pro 2004 - dt 3.2.1
Répondre


Atteindre :


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