Le gris moyen

Bonjour, aujourd’hui on va parler de la notion de « gris moyen ». :aupoil:

Nous allons voir que, comme beaucoup de choses liées à la couleur, c’est un concept faussement simple, on essaiera de savoir comment le déterminer et pourquoi on ne se posait pas vraiment la question avant.

Le gris moyen, c’est quoi ?

Ce qu’on appelle couramment le gris moyen est une teinte perçue comme étant à mi-parcours entre le noir et le blanc.

Dans la 3D, cette valeur de gris est souvent utilisé comme intensité de référence (couleur de fond/du sol), pour faire valider ses tournettes ou ses lightings.

Quelle est sa valeur ?

On parle souvent d’un gris à 18 %. Ce pourcentage n’est pas vraiment un standard, mais plutôt une convention.

Si vous faites de la peinture, vous pouvez fabriquer un gris moyen en prenant des pigments noires, des pigments blancs, et en faisant un mélange 18(noir)/72(blanc).

Pourquoi 18 % exactement ? Il semblerait que les « inventeurs » soient Ansel Adams et Fred Archer, deux photographes américains qui l’ont formalisé dans ce qui est appelé le Zone system.

Je ne vais pas rentrer dans les détails. Ce qui est intéressant dans ce système est que le gris moyen est à 18 %, ce qui est très éloigné d’une valeur qu’on pourrait naïvement définir à 50 %, mais pourquoi ?

Expérimentation

Si votre moniteur est calibré en sRGB (80 cd/m2 d’intensité lumineuse) et que vous êtes dans une pièce moyennement éclairée : Si je vous donne l’image ci-dessus et que je vous demande d’y mettre, à l’œil (sans regarder les valeurs), un rectangle dont l’intensité du gris se situerait à mi-parcours entre le noir et le blanc, il est fort probable que vous obteniez quelque chose comme ça :

Pourtant…

Vous pensez que votre gris ainsi trouvé est à mi-chemin entre le blanc et le noir, mais si vous aviez les moyens de mesurer l’intensité lumineuse de ce gris sortant de votre écran (avec un luxmètre), vous vous rendriez compte qu’il n’est pas à 50 % de l’intensité lumineuse du blanc, mais aux alentour des 20 %.

Une autre façon de le dire, c’est que la perception de l’intensité lumineuse par l’œil humain n’est pas linéaire : Pour une dynamique donnée (un range d’intensité minimum, perçu comme, noir et maximum, perçu comme blanc), l’œil semble être à l’aise avec les informations tournant autour des 18-20 % de cette dynamique. C’est la raison pour laquel le Zone system la prend comme référence.

Avec un peu de chance, vous vous êtes déjà jeté sur votre color picker favori pour déterminer la valeur de gris d’un pixel de votre rectangle. Vous trouvez 118 sur 255, ce qui équivaut à peu près à 50 %. Là, vous vous dites que votre pixel est bien à 50 % et que je vous raconte des bêtises, mais si vous être à l’aise avec l’espace colorimétrique sRGB, vous savez surement déjà pourquoi.

La fonction de transfert électro-optique (pixel vers l’écran) sRGB est approximativement une courbe gamma 2.2 :

Ce qui veut dire que quand on donne une valeur de 0.5 à notre moniteur calibré sRGB, il ne renvoie pas 50 % d’intensité lumineuse, mais à peu près 0.22 (22 %, ce qui est très proche de 18 %) :

>>> 0.5**2.2
0.217637640824031

Et on arrive à la raison qui m’a poussé à écrire ce billet :

La raison pour laquelle on ne se prenait pas la tête avec le gris moyen « avant » (en sRGB), c’est parce que qu’une valeur de pixel à 50 % était traduite en 22 % d’intensité lumineuse, ce qui était perçu comme un gris moyen. Donc nos têtes de graphistes ont fait la relation : Gris moyen = pixels à 50 %, mais ça n’est (approximativement) vrai qu’en sRGB. C’est un accident du fait qu’on utilise principalement des moniteurs sRGB.

Petit parenthèse pour chercher la petite bête : Pour avoir un gris 18 % (et non 22 %), il faut faire mettre un pixel à 45.9 %. Ça ne change pas le propos de mon billet.

Mais alors se pose la question suivante : Quelle valeur de pixel faudrait-il pour avoir une intensité lumineuse à 50 % sur notre moniteur sRGB ?

En inversant la fonction gamma 2.2 :

>>> 0.5**(1/2.2)
0.7297400528407231

Donc pour avoir une intensité lumineuse à 50 %, il faudrait des pixels à 73 %, 186/255. Vous pouvez le vérifier sur la courbe précédente.

Ça nous donne l’image suivante :

Difficile de dire que vous voudriez faire valider vos persos dans un tel gris, pas vrai ?

Vous pouvez picker le gris, vous aurez 186.

Pourquoi on a besoin de savoir ça maintenant ?

Comme vu précédemment, la particularité des moniteurs sRGB faisant qu’on ne se prenait pas vraiment la tête avec ça, mais les choses changent assez vite avec OCIO, ACES et le HDR.

Si vous utilisez OCIO dans un espace sRGB, vous avez peut-être remarqué qu’une valeur de couleur à 0.5 est parfois correctement représenté dans vos logiciels et apparait clair, comme notre seconde image. OCIO définissant un certain nombre de règle pour interpréter les valeurs, il estime qu’une couleur avec des valeurs à 0.5 doit être interprété comme une couleur (et non des données) et la convertira vers l’espace colorimétrique de scène. Vous aurez alors peut-être le réflexe de la diminuer aux alentours des 20 %, ce qui est tout à fait normal.

ACES n’y échappe pas. Sur un moniteur sRGB :

  • Une valeur de 0.31 dans ACES donne l’équivalent du 22 % sur un moniteur sRGB (le « 50 % sRGB »).
  • Une valeur de 0.262 dans ACES donne l’équivalent 18 % sur un moniteur sRGB.

Est-ce que c’est ce qu’il faut utiliser ces valeurs ? La réponse est « ça dépend de votre moniteur de référence ». Si votre moniteur de référence est un moniteur sRGB, alors ces valeurs feront l’affaire. Si c’est un moniteur HDR vous devez vous poser pas mal de questions d’espaces colorimétriques, mais il est possible que 18 % de la valeur maximum soit beaucoup trop claire, tant les moniteurs HDR peuvent monter haut. J’avoue ne pas avoir assez creusé le sujet.

En espérant que ce billet vous aura appris quelques trucs.

:marioCours:

Crash du viewport Maya : L’option Consolidate World

Aujourd’hui on va parler d’une option bien spécifique du viewport de Maya : Consolidate World.

On va d’abord définir ce qu’est la consolidation et comment elle a été mise en place dans le Viewport 2.0. On finira par lister des cas spécifiques d’utilisation avec lesquels cette option est difficilement compatible et où la documentation elle-même propose de le désactiver. :aupoil:

Lire la suite

Les groupes de jobs par utilisateur

…pour sauver ta prod et faire ton bonheur. :siffle:

Dans ce billet, nous allons parler d’un système permettant de résoudre un problème récurent de suivi asynchrone, côté utilisateur.

Bon, une explication aussi générique que ça ne vous avance pas des masses… Donc on va le dire autrement :

Quand un graphiste publie sa scène, il n’est pas rare de vouloir lancer un certain nombre de choses immédiatement après la publication, sans le bloquer. S’ensuit un torrent de propositions plus archaïque les unes que les autres pour ne serait-ce que définir le problème : Bienvenue dans le monde magique de l’asynchronie ! :sauteJoie:

Lire la suite

Récupérer les valeurs par défaut de kick

Aujourd’hui, un petit bout de code très simple pour récupérer les valeurs par défaut que Arnold (ou la ligne de commande kick) donne à ses nœuds quand on ne les lui fournit pas.

Ce type d’information est utile, entre autres, dans un pipeline qui génère ses .ass lui-même. :siffle:

Bonne lecture ! :sauteJoie:

Lire la suite

Objectif Helios, 5D et « bip » de confirmation de mise au point

Canon 5D Mark III et objectif Helios-44

Canon 5D Mark III et objectif Helios-44Je fais ce billet pour partager mes galères dans mes recherches sur le moyen de faire fonctionner le « bip » de confirmation de mise au point de mon boitier 5D Mark III avec un objectif Helios 44. On parlera de l’Helios, mais il est possible que les problèmes soulevés et les solutions (et les erreurs aussi…) puisse vous intéresser.

Si vous êtes hermétique aux termes liés au matériel photo, passez votre chemin. Les autres, bienvenues chez vous !

Lire la suite

Geler les rigs en production

dessin rig gele

dessin rig geleCe billet aurait pu être sous-titré : « Se tirer une balle dans le pied, mais rester debout ». :trollface:

Le gèle des versions du rig (et du reste, d’une façon générale) est une question qui revient régulièrement au cours d’une production. Nous allons voir en détail  pourquoi est-ce qu’il s’agit d’un problème insoluble (bah ouais… Sinon on en parlerait plus… :baffed: ) et avec de nombreuses ramifications qui nécessitent d’être comprises si on souhaite contenir leurs effets.

Lire la suite

Gérer des caméras sur-samplées dans Nuke

Avez-vous déjà eux des problèmes de rendu dans Nuke en utilisant des caméras ayant des samples entre les frames ? :reflechi:

Non ? Super ! Grace à ce billet, vous allez savoir comment gérer cette situation si un jour ça vous arrive ! :siffle:

On va parler de rendu, de Nuke, de shake cam, d’export Alembic, de sampling temporel, de frame rate, d’expressions, et toutes ses choses qui nous rappellent chaque jour à quel point nos vies sont formidables et méritent d’être vécues ! :petrus:

Lire la suite

Lire les Light Stats dans Guerilla

Depuis la version 2.3.9, Guerilla dispose d’un log de rapport de contributions des lights de vos scènes. Il n’est pas évident d’interpréter correctement ces valeurs : Elles ne sont pas forcément simples à comprendre, et encore moins à mettre en relation avec l’image. :reflechi:

Nous allons donc commencer par expliquer ce qu’elles représentent, puis nous commenterons un petit rendu visant à pousser l’efficacité de ses statistiques dans leur retranchement.

Notez que cette version est sortie ce soir et que je n’ai pas pu m’empêcher de faire un billet… :baffed:

 
 

 

 

Lire la suite

Faire un AOV d’occlusion avec la DiffuseColor dans Guerilla

Il y a plein de façons de faire de l’ambiant occlusion. :hehe: Certains sortent cette passe au moment du lighting pour donner de la flexibilité au compo ; pour assombrir les creux. D’autres sortent cette passe avant l’étape de rendu, au moment de l’animation, voir du layout ; pour du contrôle qualité. Dans chaque situation, le contenu de la passe d’ambiant occlusion est adapté au besoin ; pour du compo il faut qu’elle soit en niveaux de gris, pour du contrôle qualité on peut afficher chaque objet avec une couleur particulière, etc.

Quand le lookdev des assets est (enfin) disponible, il peut être intéressant d’avoir une ambiant occlusion générée avec les textures de lookdev plutôt que des couleurs uniformes. C’est ce que nous allons faire dans ce billet. :bravo:

Lire la suite

Les variations de lookdev par tags dans Guerilla

Dans ce billet, je vous propose une méthode pour gérer les variations de lookdev. Nous allons voir que la notion de « variation » est un concept assez flou tant il peut rapidement impacter tous les départements. En pratique, il peut y avoir plusieurs méthodes, chacune ayant ses spécificités. :sourit:

Cette méthode est une des plus simples à mettre en place. Vous allez voir que la partie dans Guerilla est assez rapide, mais ce sera surtout un prétexte pour réfléchir à comment organiser son travail dans le cadre d’une production. :sauteJoie:

La conclusion restera ouverte…

Lire la suite

Faire un AOV de translucence avec Guerilla

La translucence est un effet couramment utilisé en rendu pour les surfaces fines ; feuilles, papiers, etc. Il permet de récupérer l’illumination et les ombres projetées d’un côté pour les projeter de l’autre.

Si vous utilisez Guerilla (ce que vous devriez faire… :siffle: ) vous avez peut-être remarqué que la translucence n’est présente dans aucun AOV de base.

Lire la suite

Les foules de personnages en volumétriques de Soul chez Pixar

N’ayant plus beaucoup de temps pour lire des publications, je suis passé à côté d’un papier de Pixar sorti en juillet 2020 : Rasterizing Volumes and Surfaces for Crowds on Soul. De la rastérisation dans un papier de 2020 ? Intéressant… :reflechi:

Quand j’ai ouvert le papier, je m’attendais à trouver des équations mathématiques sur une nouvelle méthode ou que sais-je, mais c’est en fait la description détaillée d’un problème précis sur un plan. Tout ce que j’aime ! :baffed:

Vous allez voir que la situation que Pixar a rencontré sur ce plan a pas mal de similitude avec les problèmes qu’on peut rencontrer, dès qu’un plan un peu complexe se pointe. La différence c’est que Pixar n’est pas aussi limité que nous dans ses méthodes. Et c’est là où ce genre de document prend de la valeur : Quand on se retrouve face à des choses difficiles à sortir, on peut parfois se laisser aller à de la pensée magique comme : « À Pixar, ils auraient tout envoyé en farm ! » (mais bien sûr…). Ce papier nous prouve que non, et surtout, qu’ils n’ont pas peur de revenir sur des vieux paradigmes pour sortir leurs plans quand la contrainte (ici technique) l’impose. :redface:

Ce billet sera donc l’occasion de râler comme un vieux con, puis on va essayer de comprendre comment Pixar a géré ce plan. :banaeyouhou:

Lire la suite

Guerilla, Hair, et Back specular

Aujourd’hui un billet inutile et vraiment spécifique pour vous parler d’un problème que vous ne rencontrerez sûrement jamais. :laClasse: En fait il est probable que vous ne rencontriez ce problème que sur de la série, où la contrainte de la puissance de calcul est importante. :pafOrdi:

Quand on rend des poils avec le shader Hair de Guerilla (et je suppose avec n’importe quel autre moteur de rendu) il peut être intéressant de supprimer les-dit poils du trace set « Diffuse » pour économiser leur coût de calcul dans l’indirect (BIM ! Direct dans le bain sans politesse ni respect pour son lecteur :grenadelauncher: ), mais dans ce cas précis, on risque d’obtenir un effet bizarre, presque esthétique, et je vous propose de voir ce dont il s’agit. :hehe:

Lire la suite

Convertir des primaires sRGB en primaires ACES

Bonjour à tous, dans ce petit billet nous allons voir comment convertir des primaires sRGB en primaire ACEScg. :reflechi:

Ceci vous sera peut-être utile pour convertir des lookdevs historiquement créés en sRGB, vers votre workflow l’ACES. Pour les textures, il suffit de changer la transformation d’entrée (« input device transform »), mais les couleurs stockées en dur dans les attributs de vos logiciels et matériaux n’ont pas d’espace qui leur soit assigné, donc pour conserver le même résultat visuel, il faut les convertir « manuellement ».

Ce sera surtout un prétexte à un quelques explications sur ce qu’est une primaire, la différence entre celles de sRGB et ACEScg, dans quel cas précis on doit le faire et quand ne surtout pas le faire. :tuComprendRien:

Notez qu’il y aura du Python à la fin, toutefois le code est très simple et je pense que la première partie du billet est suffisamment intéressante pour être lu par tout le monde. :hehe:

Lire la suite

LOD, suite et fin (automatique VS manuel)

Je me suis rendu compte que j’ai oublié de parler de deux-trois choses dans mon billet précédent et je suis parfois passé trop rapidement sur certains points.

Je vous propose un billet d’appoint pour corriger le tire, ce sujet aux branchements infinis le mérite bien. :sourit:

Aujourd’hui, je comparerai l’approche automatique et semi-manuelle pour gérer les LOD géométriques, j’aborderai la relation entre le département de modeling et de lookdev puis on finira par les poils.

Lire la suite

Aperçu du concept de LOD

lod_jeu_de_mot

lod_jeu_de_motBonjours, dans ce billet je vous propose de faire le tour de ce qu’on entend par LOD (Level Of Detail), en quoi ça consiste, à quoi ça sert, quand faut-il l’utiliser et quand vaut-il mieux s’en éloigner.

Vous vous rendrez compte que derrière ce concept simple se cache des réalités techniques assez nuancées. :reflechi:

Lire la suite

Haut de page