Le flux de travail relatif à la scène

Dans cet article, vous apprendrez ce qu’est le flux de travail relatif à la scène, comment Ansel l’utilise et en quoi il profite au traitement d’image numérique en général.

Introduction

Le flux de travail relatif à la scène est la colonne vertébrale du pipeline d’imagerie d’Ansel. Il s’agit d’une logique de travail qui vient de l’industrie du cinéma car c’est la seule façon d’obtenir un compositing (aussi nommé fusion alpha) de calques graphiques robuste et sans raccords visibles. Pour les photographes, c’est surtout pour les scènes à haute plage dynamique (HDR) (sujets en contre-jour, couchers de soleil, etc.) qu’il montre son intérêt.

Si vous avez déjà utilisé n’importe quel type de logiciel de traitement d’image jusqu’à présent, vous devriez être déjà familiarisé avec le flux de travail relatif à l’affichage, mais sans savoir ni son nom ni ses hypothèses internes de travail. Expliquer en quoi le flux relatif à la scène diffère de ce relatif à l’affichage dont personne ne prononce le nom va être une gageure si l’on n’explique pas aussi ce que le flux relatif à l’affichage a été avant.

Faire une image

Quand vous prenez une photo d’une scène, le capteur de votre appareil transforme un spectre lumineux en 3 signaux électriques, de façon très semblable à ce que font les cellules cône de la rétine avant d’envoyer des influx électriques sur le nerf optique. Les détails sont hors du champ de cet article, mais prétendons que le spectre lumineux est découpé en 3 intensités R, V, B de sorte que les proportions de R, V, et B dans chaque pixel soient une assez bonne représentation de la forme du spectre.

graph TD;
	O[fa:fa-bulb Source de lumière] --> A;
    A[] --> B["fa:fa-camera Capteur (Nikon D5100)"];
    B --> C[Capteur RGB
];
    A --> D["fa:fa-eye Œil humain"];
    D --> E[Cônes LMS
];
    E ------> F["fa:fa-brain Cerveau humain"];
    F --> G[Stimulus de couleur
];

    C --> H["fa:fa-laptop Beaucoup de travail numérique"];
    H --> HH[sRGB
];
    HH --> I[fa:fa-desktop Écran];
    I --> J[];
    J --> K["fa:fa-eye Œil humain / fa:fa-brain Cerveau humain"];
    K --> L[Stimulus de couleur
];

Nous devons noter que le début et la fin du pipeline graphique sont un spectre de lumière qui, s’il est identique, produira le même stimulus de couleur pour l’observateur¹. Mais les spectres de lumière sont en réalité assez différents : les grands pics de l’illuminant FL1 ont été lissés une fois affichés sur un écran sRGB. La différence entre la scène originale et sa restitution à l’écran est due aux pertes de signal inévitables lors de la réduction d’un spectre à RGB, conçu pour fonctionner uniquement avec des spectres de type lumière du jour (lisses). Cette hypothèse est souvent oubliée, et le problème que nous voyons ici n’est pas surprenant, étant donné que l’illuminant FL1 a un CRI  de 76 %. En fait, nous pouvons prédire comment un tel illuminant, bien que techniquement équilibré pour D65, affectera le rendu des couleurs :

Ainsi, cet illuminant rendra les surfaces rouges et violettes moins saturées qu’elles ne devraient l’être, comparées aux autres surfaces colorées, et décalera également leurs teintes. Les surfaces bleues et vertes apparaîtront majoritairement non affectées. Cependant, nous pouvons noter que la couleur perçue réelle d’un tel illuminant (c’est-à-dire, “la nuance de blanc”) ne montre pas de décalage visible malgré la différence de spectres. La déviation de couleur relative est en effet inférieure à 0,001 % dans les coordonnées chromatiques u’v’. Tout ceci pour montrer que les intrications entre les spectres (de l’illuminant ainsi que de la lumière réfléchie par des surfaces matérielles et colorées) et la perception des couleurs sont loin d’être intuitives et clairement pas faciles à prévoir.

De même, les organes technologiques impliqués dans la capture du signal et sa restitution fonctionnent en RGB. Cependant, aucun des espaces RVB impliqués ne correspond en réalité aux cônes LMS. Si nous voulons que l’image numérique ressemble vaguement à la perception humaine de la scène, il nous faudra travailler dur pour y arriver, en manipulant numériquement le signal RGB brut, mais sans nécessairement nous soucier de la perception dans le processus. Il suffira d’assurer la cohérence du spectre lumineux aux deux extrémités.

C’est un aspect mal compris de la photographie numérique où la manipulation numérique est souvent considérée par les puristes comme un faux semblant ou une altération du contenu, et l’image brute est souvent vue comme une sorte de “vérité neutre” ou “objective” parce qu’elle a été créée par une machine. L’image produite par la machine est en fait assez fausse et la manipulation numérique est absolument nécessaire pour la faire ressembler à la scène originale malgré toutes les distorsions optiques qui se sont produites dans la caméra.

Corriger le RGB brut pour qu’il ressemble quelque peu à ce que le spectateur a expérimenté sur la scène nécessite de manipuler les couleurs, en utilisant au moins un profil de couleur d’entrée et un ajustement de la balance des blancs. Malheureusement, ceux-ci sont inexacts et ne correspondront toujours pas exactement à la vision humaine, en particulier lorsque la source de lumière de la scène n’est pas une lumière du jour naturelle (avec un spectre “complet”). Dans l’exemple ci-dessus, l’ampoule fluorescente montre un spectre en pics qui rendra certaines couleurs très particulières plus saturées et lumineuses que le reste d’entre elles, ce qui sera difficile à corriger².

La propriété de ce signal RGB brut est d’être de scène-linéaire : les valeurs de code RGB sont à peu près proportionnelles à l’énergie de l’émission lumineuse. C’est la représentation la plus proche que nous puissions prendre d’un spectre lumineux, en attendant un pipeline entièrement spectral (comme dans Manuka ).

Malheureusement, dans la plupart des cas, nous ne pouvons pas simplement envoyer ce RGB linéaire à l’écran de l’ordinateur, même après avoir corrigé les couleurs pour correspondre à la vision humaine, généralement parce que :

1. la plage dynamique que les capteurs peuvent capturer est beaucoup plus large que ce que les écrans peuvent rendre,
2. pour mieux utiliser cette plage dynamique, les fabricants d’appareils photo “sous-exposent” la scène d’environ 2/3 EV, ce qui rendra le RGB brut assez sombre.

Par conséquent, nous devons au moins éclaircir les tons moyens et généralement comprimer les hautes lumières, ce qui est le travail de la transformation d’affichage.

Dans les firmwares des caméras et dans les applications typiques de retouche d’images, cette transformation d’affichage est généralement réalisée à travers une “courbe” (bien que la courbe ne soit que la représentation graphique de la transformation, pas la transformation elle-même) ressemblant à ceci :

Après

Avant

La pente de cette courbe détermine le contraste global. De nombreuses applications propriétaires appliqueront une telle courbe sans vous le dire et sans vous laisser la désactiver, si bien que vous n’avez aucune idée de ce qui se passe en arrière-plan. Certaines applications ne vous laissent choisir qu’une apparence de base entre “par défaut”, “neutre”, “portrait”, “intense”, “HDR”, etc. qui chargera une courbe différente. Certaines applications intègrent même la courbe dans le profil de couleur d’entrée.

Travailler sur une image

Dans la section précédente, nous avons appris que nous devrions travailler non seulement pour reconstruire un rendu couleur crédible à partir du RGB brut, mais aussi pour repositionner correctement la plage dynamique de la scène pour le dispositif d’affichage cible. Ici, nous verrons comment ce travail est réellement effectué, en étudiant plus spécifiquement l’étape “Beaucoup de travail numérique” du flux de travail de la section précédente.

Si nous généralisons comment n’importe quel logiciel de traitement d’image fonctionne, qu’il s’agisse d’éditeurs de bureau typiques, de firmware interne à une caméra, d’applications mobiles, peu importe le flux de travail qu’ils utilisent, nous arrivons à ce diagramme de flux :

graph TD
    A((fa:fa-sun Scène)) --> B([Lecture brute du capteur]);
    B --> C;

    subgraph Logiciel;
      C["Profilage des couleurs (Linéaire) "];
      C --> D[Traitement relatif à la scène];
      D --> E["Transformation d'affichage (Non-linéaire) "];
      E --> I[Traitement relatif à l'affichage];
      I --> G[Système de gestion de la couleur];
    end;

    G --> H([Buffer d'affichage]);
    H --> J((fa:fa-lightbulb Affichage));

    style D fill:#BAFFD2;
    style I fill:#FFB7B5;

Les applications d’image typiques n’utilisent pas du tout le traitement faisant référence à la scène, ou seulement pour certains filtres de reconstruction d’image technique, donc elles passent directement du profilage des couleurs à la transformation d’affichage. La manipulation numérique se produit uniquement dans l’espace d’affichage, où “blanc” est forcé à 100% (ou la valeur de code 255 lors du travail en 8 bits RGB), “noir” est forcé à 0% (ou la valeur de code 0 en 8 bits RGB), et le gris moyen est généralement au milieu à 45-50% (voir plus de détails ci-dessous).

Le problème de cette logique réside dans le cycle de vie de l’image :

graph LR;
	A[fa:fa-tree Scène] --> B[fa:fa-camera Appareil photo];
	B --> C[__FLUX DE TRAVAIL__];
	C --> D[fa:fa-poop Système de gestion de la couleur];
	D --> E[fa:fa-desktop Écran SDR];
	D --> F[fa:fa-sun Écran HDR];
	D --> G[fa:fa-print Impression fine-art];
	D --> H[fa:fa-book Livres/Magazines];
	D --> I[fa:fa-tshirt Merchandising];
	D --> J[fa:fa-save Archives];

Parce que le support d’affichage cible peut maintenant être n’importe quoi, d’un T-shirt à un écran HDR, et tout ce qui se trouve entre, nous devons utiliser différentes transformations d’affichage pour tenir compte des propriétés du support cible. Mais si nous utilisons la transformation d’affichage comme première étape de notre montage, la changement de celle-ci annulera souvent le montage suivant, surtout si elle utilise des masques paramétriques. Cela signifie pratiquement que vous devez refaire votre montage pour chaque support de sortie, ce qui est fastidieux.

Travailler dans la partie du pipeline référée à la scène signifie que nous travaillons avant la transformation d’affichage et que notre montage sera immunisé contre les différences de supports de sortie. C’est comme travailler sur un “montage maître” qui restera le même, peu importe le support de sortie, puis traiter les spécificités de la sortie lors de l’exportation du maître. Éliminer la partie du flux de travail référée à l’affichage permet de faire fusionner la transformation d’affichage et les étapes de gestion de la couleur, ce qui est très souhaitable car elles traitent toutes de la même tâche : mapper le “montage maître” à ce que soit le support de sortie que nous avons, en corrigeant ses particularités pour essayer de préserver la couleur d’apparence intentionnelle pour le public.

Le défi de travailler dans la partie du pipeline référée à la scène est que “blanc” ne peut plus être supposé être ancré à une valeur spécifique, mais peut être n’importe quoi de positif jusqu’à l’infini. Pour contourner ce manque de référence, nous passons d’un pipeline “centré sur le blanc” à un pipeline “centré sur le gris”, où le gris moyen réfléchi (celui des cartes grises) est censé être ancré à 0.18-0.20. Puisque le “blanc” HDR peut être 4 fois plus lumineux que le blanc SDR, tout ce que nous savons, c’est que tous les appareils auront un gris moyen autour de 0.20 et que tous les appareils pourront l’afficher, peu importe leur plage dynamique. Il s’avère également que les images de scènes naturelles ont la plupart de leur histogramme centré autour de cette valeur.

Nous pouvons résumer l’hypothèse de chaque flux de travail ci-dessous :

Les encodages RGB sont la représentation numérique de l’image à l’intérieur de l’ordinateur. Ils ne sont pas directement connectés à la luminance du monde réel, soit enregistrée sur la scène originale, soit sur l’affichage final. Par exemple, la luminance des pixels noirs mesurée sur les affichages physiques sera autour de 0.1 Cd/m², alors que cela sera encodé 0 en RGB. Dans le flux de travail référé à la scène, nous devons souvent décaler le noir à des valeurs RGB non nulles pour reconnecter avec sa signification lumineuse, sur laquelle nous nous appuyons.

Quand on travaille dans des espaces RGB encodés avec une OETF  (à tort appelée “gamma”), comme sRGB, Adobe RGB ou Prophoto RGB, le gris moyen est attendu autour de 45 % de la plage d’encodage. ³ Les applications ayant un pipeline entier de 8 bits doivent utiliser des RGB encodés en OETF pour éviter la postérisation dans les dégradés. Les applications ayant un pipeline entier de 16 bits choisissent souvent de faire de même pour la cohérence, bien que ce ne soit pas une exigence technique dans ce cas. Le gris moyen sera encodé à 18 % de la plage d’encodage dans les flux de travail référés à l’affichage qui utilisent du RGB linéaire, c’est-à-dire les espaces RGB dépouillés de leur OETF/gamma.

Nous pouvons maintenant faire correspondre les hypothèses de chaque flux de travail sur les valeurs de code RGB à leur signification en termes de luminance de la vie réelle :

Les valeurs Cd/m² dans la colonne référée à l’affichage proviennent des normes ISO habituelles pour l’impression prédéfinie. La luminance du point noir de l’affichage peut éventuellement être définie dans le profil ICC du support, ce qui est souvent le cas pour les profils d’imprimante réalisés professionnellement, afin de permettre la compensation du point noir . Puisque l’OETF est décodée à l’intérieur de l’écran, la valeur de luminance du gris moyen est connectée à la valeur de code RVB linéaire et sera trouvée à 18-20 % de la luminance du blanc de l’écran.

Pour le flux de travail référé à la scène, les luminances des points noir et blanc correspondent aux luminances minimales et maximales trouvées sur la scène. La référence du gris moyen est le patch de gris moyen d’une charte de couleurs (ou d’une carte grise) éclairée dans les mêmes conditions que le sujet de l’image. Il est donc possible de définir le gris moyen directement en échantillonnant la luminance d’une carte grise dans une photo test.

Avantages pratiques du flux de travail référé à la scène

Nous avons vu dans la section précédente que le flux de travail référé à la scène vous permet de travailler votre montage maître indépendamment de tout support cible fixe. Les avantages ne s’arrêtent pas là.

D’abord, parce que le flux de travail référé à la scène est conçu autour de l’idée que “blanc” n’a pas de valeur fixe particulière, il peut s’adapter à n’importe quelle plage dynamique d’entrée, ce qui signifie que les mêmes outils et flux de travail peuvent être utilisés pour traiter des photographies numériques, des rendus synthétiques ou n’importe quel type de composition HDR.

Ensuite, là où il brille vraiment, c’est pour tous les filtres numériques définis optiquement essayant de simuler des effets réels, comme le flou, le débruitage, la suppression du bruit ou la reconstruction des signaux. L’exemple ci-dessous montre la différence que cela fait d’appliquer un filtre de bokeh numérique, simulant un diaphragme d’objectif, avant ou après la transformation d’affichage.

Après

Avant

Étant donné que le flou de l’objectif se produit avec la lumière, et que le RVB linéaire de scène est la représentation numérique la plus proche que nous puissions avoir de la lumière réelle, il est logique d’appliquer les filtres numériques définis optiquement dans la partie linéaire du pipeline, mais l’exemple ci-dessus confirme visuellement la validité du raisonnement.

Des effets similaires seront observés lors du travail avec des masques et de la composition alpha, lorsqu’on souhaite adoucir et lisser les bords des masques pour mieux les intégrer avec l’environnement (ce qui, encore une fois, est un flou).

Comment est-il implémenté dans Ansel ?

Ansel est capable d’utiliser à la fois les flux de travail référés à l’affichage et à la scène, car il hérite de certains modules hérités de darktable. La plupart des modules référés à l’affichage ont été remplacés par des homologues référés à la scène, et les restants devraient suivre en 2023.

Bientôt, Ansel sera entièrement référé à la scène, ce qui permettra des transformations d’affichage plus intelligentes combinées avec le mappage de gamut et les extractions de profils ICC.

Il n’est généralement pas possible d’utiliser des modules référés à l’affichage dans la partie du pipeline référée à la scène, car ils s’attendent à un point blanc à 100 %, et généralement vont couper les valeurs RGB au-dessus de 100 % (certains doivent le faire pour éviter les instabilités numériques dans les algorithmes). Certains attendent même un point gris à 50 %, comme les modes de fusion  écran, lumière douce, lumière dure, superposition, éclaircir, assombrir qui traitent différemment les pixels dont les valeurs sont supérieures ou inférieures au seuil de 50 %.